Iterations on PSSE parser

[PhilipFackler]

Merge request type

• New feature
• Resolves bug
• Documentation
• Other

Relates to

• OPFLOW
• SOPFLOW
• SCOPFLOW
• TCOPFLOW
• CMake build system
• Spack configuration
• Manual
• Web docs
• Other

This MR updates

• Header files
• Source code
• CMake build system
• Spack configuration
• Web docs
• Manual
• Other

Summary

Multiple improvements to PSSE parser:

• Initial v34 support with caveats
  • "system-wide data" block is skipped for now
  • Still not parsing every record type
• Use more consistent messages for errors and logging (including warning for elements not supported by PS)
• Handle record items that are optional in the specification
• Resolve defaults that depend on data in other record types (e.g., load.area defaults to area of bus referenced by load.i)

Linked Issue(s)

• Finish PSSE parser #188

[tsybinae]

Applied ./pflow -netfile for three different files, including Hawaii 40 https://electricgrids.engr.tamu.edu/hawaii40/.
Produces this error message.

 ~/lib/ExaGO/build/applications$ ./pflow -netfile Hawaii40_20231026.RAW
terminate called after throwing an instance of 'std::runtime_error'
  what():  Cannot resolve bus id
[LAP136650:03927] *** Process received signal ***
[LAP136650:03927] Signal: Aborted (6)
[LAP136650:03927] Signal code:  (-6)
[LAP136650:03927] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x7333d6845330]
[LAP136650:03927] [ 1] /lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x11c)[0x7333d689eb2c]
[LAP136650:03927] [ 2] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x1e)[0x7333d684527e]
[LAP136650:03927] [ 3] /lib/x86_64-linux-gnu/libc.so.6(abort+0xdf)[0x7333d68288ff]
[LAP136650:03927] [ 4] /lib/x86_64-linux-gnu/libstdc++.so.6(+0xa5ff5)[0x7333d6ca5ff5]
[LAP136650:03927] [ 5] /lib/x86_64-linux-gnu/libstdc++.so.6(+0xbb0da)[0x7333d6cbb0da]
[LAP136650:03927] [ 6] /lib/x86_64-linux-gnu/libstdc++.so.6(_ZSt10unexpectedv+0x0)[0x7333d6ca5a55]
[LAP136650:03927] [ 7] /lib/x86_64-linux-gnu/libstdc++.so.6(+0xbb391)[0x7333d6cbb391]
[LAP136650:03927] [ 8] ./pflow(+0x108f2)[0x5b632f2b88f2]
[LAP136650:03927] [ 9] ./pflow(+0x2a342)[0x5b632f2d2342]
[LAP136650:03927] [10] ./pflow(+0x2aa86)[0x5b632f2d2a86]
[LAP136650:03927] [11] ./pflow(+0x2ad92)[0x5b632f2d2d92]
[LAP136650:03927] [12] ./pflow(+0x2b539)[0x5b632f2d3539]
[LAP136650:03927] [13] ./pflow(+0x1693e)[0x5b632f2be93e]
[LAP136650:03927] [14] ./pflow(+0x1248f)[0x5b632f2ba48f]
[LAP136650:03927] [15] /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x7333d682a1ca]
[LAP136650:03927] [16] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x7333d682a28b]
[LAP136650:03927] [17] ./pflow(+0x15065)[0x5b632f2bd065]
[LAP136650:03927] *** End of error message ***
Aborted (core dumped)

[pelesh]

Here is what I am getting with the updated PSSE parser.

The case Hawaii40_20231026.RAW should be parsed correctly but it returns an error:

$ ./pflow -netfile Hawaii40_20231026.RAW 
[ExaGO] Parsing PSS(R)E raw data file: 'Hawaii40_20231026.RAW'
[ExaGO] Generator at bus : voltage setpoint (1) different from bus voltage magnitude (0.991225)
terminate called after throwing an instance of 'ExaGOError'
  what():  Generator at bus : voltage setpoint (1) different from bus voltage magnitude (0.991225)
Aborted (core dumped)

The file that should trigger failure, bench.raw, does that and the parser correctly recognizes unsupported format:

$ ./pflow -netfile bench.raw 
[ExaGO] Parsing PSS(R)E raw data file: 'bench.raw'
[ExaGO] PSS(R)E Power Flow Raw Data Files are supported only for versions 32, 33 and 34. This file is tagged version 31
terminate called after throwing an instance of 'ExaGOError'
  what():  PSS(R)E Power Flow Raw Data Files are supported only for versions 32, 33 and 34. This file is tagged version 31
Aborted (core dumped)

Question: Why are we throwing an exception after reading poorly structured input? We could just return.

[tsybinae]

A few questions not specific to changes:

1. Why did you use bus name as an equal identifier to bus number? In principle, only bus number is used as reference. Bus name does not have to exist and somewhere in the code you also assume that it can copy from bus number.
2. dgen.pgs = (dgen.pb + dgen.pt) / 2.0; Midpoint start?
3. auto configure_line = [&nw](auto &line). Suggest to check if tap, r, x <>0, because then you have Z and tap2, which should be > 0.

[PhilipFackler]

@tsybinae :

2. dgen.pgs = (dgen.pb + dgen.pt) / 2.0; Midpoint start?

I copied this logic from here.

3. auto configure_line = [&nw](auto &line). Suggest to check if tap, r, x <>0, because then you have Z and tap2, which should be > 0.

This was also copied from the original reader. It combines the logic used for both branches and transformers here. I see that Zm and tap2 will always be >= 0 since they use squares. I'm not understanding what you're suggesting I check with tapratio, R, and X. Can you clarify?

My goal has been to reproduce the result of the original reader. Any changes needed will be for you experts to decide. 😺 And I'll be happy to implement them.

[hambrickjc]

Hawaii40 case successfully loads in pflow in both psse and matpower format. Application converges in same number of iterations but with slight differences between psse and matpower cases.

Hawaii40 case also successfully loads in opflow in both psse and matpower format, but does not converge in psse format which is expected due to lack cost information

Vmax and Vmin appear to be reversed when importing from raw files (see below...formatting is worse in a code block) but output correctly when importing from m files.

%% bus data
% bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax Vmin mult_Pmis mult_Qmis Pslack Qslack
mpc.bus = [
1 1 0 0 0 0 1 0.995064419 -1.20921355 138 1 0.9 1.1 0 0 0 0;
2 2 60.7 0 0 0 1 1 -4.10106918 69 1 0.9 1.1 0 0 0 0;
3 1 59.39 0 0 0 1 0.985795367 -4.73782564 69 1 0.9 1.1 0 0 0 0;
4 1 22.47 0 0 0 1 0.982837787 -5.78191733 69 1 0.9 1.1 0 0 0 0;
5 1 0 0 0 0 1 0.990705392 -2.14830164 138 1 0.9 1.1 0 0 0 0;
6 1 27.46 0 0 0 1 0.984085723 -5.5620905 69 1 0.9 1.1 0 0 0 0;

[PhilipFackler]

Vmax and Vmin appear to be reversed when importing from raw files

@hambrickjc These were indeed swapped in my code. I fixed that just now.

I also removed the test comparing these values, because they were also swapped in the original parser:
Setting them here then swapping them here.

[hambrickjc]

concerns have been addressed and the updated parser has been successfully tested against sample RAW files.