Add a flag to export only the matpower spec and not extra PowerModels data

[frederikgeth]

Right now, if there is supplementary data in the PM data dictionary, it is written out by default through the _export_extra_data data function. An option to suppress this would be convenient.

[ccoffrin]

The default semantics is that if you write the internal data to ".m" and then read it back to PowerModels you will get the same internal data. I think that is a suitable default setting. Adding a flag to omit the extra data upon request seems reasonable.

A work around for the current version would be to delete the extra data from the data dict before calling export_matpower.

[ccoffrin]

@frederikgeth I was looking into this a bit more. What were you thinking for components like storage and switches, which do not require an extensions table but also are not part of the Matpower format?

[frederikgeth]

Sorry for the delay and lack of detail. So the problem I ran into originally is that _export_extra_data fails relatively easily when there is data in the data dict that isn't expected or complete. The use case is being able to write out m files without _export_extra_data failing. But because it's done through function handles in

PowerModels.jl/src/io/matpower.jl

Line 657 in 43ae4d0

return sprint(export_matpower, data)

, I coulnd't just add a keyword argument. Currently, in some internal packages, I short-circuit _export_extra_data to work around this.

[ccoffrin]

I see in that case, I would just propose to fix _export_extra_data so that it is more resilient. Can you give some examples of the kind of data that has issues with export?

For example, in _export_extra_data if I filter to only export extra values that are subtypes of Real do you think that would resolve the issue?

[frederikgeth]

So we tend to have failures here

PowerModels.jl/src/io/matpower.jl

Line 1088 in 43ae4d0

for (key, value) in c

, e.g. BoundsError: attempt to access Float64 when there is a vector instead of a dict where it isn't expected.

[ccoffrin]

Ok let me try to make this more robust and get back to you.