Open nickrobinson251 opened 2 years ago
Hi! As a follow up to our discussion, we have tried to implement a generic parser, supporting both MATPOWER and PSSE files. The idea is:
PowerFlowData
for the PSSE file Our demo exports the dataset as a PowerFlowData.Network
structure. The code can be found here:
https://github.com/exanauts/PowerParsers.jl
The question is: would it make sense to integrate this in PowerFlowData.jl? The motives are:
Overall, we have found PowerFlowData.jl convenient to use, and well implemented. The only default (for us) is that the structures have a lot of attributes, and sometimes it's hard to figure out the naming without referring to the documentation. For example these attributes. The structures specifying the ownership (Owner
) are also hard to understand, with vectors mixing Float64
and missing
values. In the end, we get a lot of boilerplate code, just to import the dataset properly in a Network
structure... But this may be related to our implementation itself, which is far from being optimized.
Prompted by discussion in https://discourse.julialang.org/t/ann-powerflowdata-jl-a-parser-for-pss-e-format-raw-power-flow-data-files/71722
Turns out power systems research has more than one very silly data format to deal with 😂 ðŸ˜
We could consider broadening the scope of the package to also parse matpower data... I think this only makes sense in this package (rather than its own package) if we can re-use a decent amount of what we have here, and broadly take the same approach (parsing the files byte-by-byte, having sections described by their own struct, etc).
Some specific ways in which matpower data is even more gross than PSS/E:
foo.bus = ...
?mpc.*
but i think that's convention only, and not actually required.Vector{Vector{Float64}}
andpush!
new columns if/when we encounter them... but it'll mena custom parsing code, not just a custom typeProbably other ways too... I'd never looked at this format before, so likely there's more to discover!
I think worth investigating further