[ANN] PowerFlowData.jl: a parser for PSS/E-format `.raw` power flow data files

npr · November 19, 2021, 12:35am

It would be interesting to move the MATPOWER parser of PowerModels.jl in PowerflowData.jl

I think adding support for MATPOWER data is an interesting idea, and one i hadn’t considered before.

We’d need to investigate if the same approach would be suitable, otherwise it would make more sense as it’s own package, i think.

I opened an issue to track it

github.com/nickrobinson251/PowerFlowData.jl

Add ability to parse MATPOWER data?!

opened 12:27AM - 19 Nov 21 UTC

nickrobinson251

idea

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: * it's not even its own file format, it's a matlab file. * I _think_ there's something approaching [a specification for the _matrices_ in the file which contain the actual data](https://matpower.app/manual/matpower/DataFileFormat.html) (if there's not then we're sunk) * but the file itself just has to be a valid matlab file (i think), so actually finding the matrices amongst the rest of the file sounds very painful. 😈 * since it's a matlab file, we have to deal with all types of comments, including end-of-line comments * and not sure if this will be harder because whitespace is the delimiter * we can probably give up on mid-line comments appearing in the data (is that a thing in matlab?), because something are just too silly. * I don't think there's any requirement on the order in which different categories of data appear, meaning we'd have to somehow identify what data * possibly the (second part of) _names_ are meaningful? e.g. bus data has to be `foo.bus = ...`? * the first part of this name isn't meaningful. convention seems to be `mpc.*` but i think that's convention only, and not actually required. * the "Generator Cost Data" doesn't not have a fixed number of columns 😒 * on a quick look i think we could have the last column be a `Vector{Vector{Float64}}` and `push!` new columns if/when we encounter them... but it'll mena custom parsing code, not just a custom type Probably other ways too... I'd never looked at this format before, so likely there's more to discover! I think worth investigating further