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

[PhilipFackler]

From the docs:

1.2. Extended Bus Names
On its Bus Data record, each bus is assigned a bus number and a 12 character alphanumeric name. When the bus names input option of activity READ is enabled, data fields designating buses on load, fixed shunt, generator, non-transformer branch, transformer, area, two-terminal dc line, VSC dc line, multi-terminal dc line, multi-section line, FACTS device, switched shunt, GNE device, and induction machine, data records may be specified as either extended bus names enclosed in single quotes or as bus numbers.

What I hear you both saying is we should not allow this. All the listed component types should designate buses by integer id. Am I correct?

[pelesh]

I think this is correct.

@abhyshr, do you want to chime in?

[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.