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.

[tsybinae]

Bus numbers have to be unique, bus names can be not unique, because they carry the names of towns or cities, and if two different states have a town called “Gainesville”, then you can have bus 123456 “Gainesville” and 678901 “Gainesville”, suggest to remove the check for unique bus names.

[PhilipFackler]

Sounds good. It looks like other components can refer to buses by name ("extended bus id") rather than number. That's why I had that requirement. So should I assume that all bus references in the file will use the bus number?

[pelesh]

I believe that "extended bus id" is used mainly for output. For computations, I would assume that bus number is used as a unique bus id.

CC @abhyshr

[tsybinae]

If a bus has more than one fixed shunt, it is ok. They have sh.id, so “SH1”, “SH2”.

[PhilipFackler]

OK I carried this check from the original parser. I'll move it to the convert function as a warning.

[pelesh]

Physically, it is okay to have more than one shunt, we need to verify that the model supports multiple shunts. I think producing warning when multiple shunts are connected to a bus is a good solution for now.

[tsybinae]

Generator voltage setpoint does not match bus voltage, this is normal.

[PhilipFackler]

This check was in the original parser. Should I remove it altogether?

[pelesh]

Perhaps turn this into a warning instead of an error for now? We need to verify that the current model supports this.