One-line File and/or GIS Parameters for Network

[lukelowry]

Summary

A designated file format for oneline diagrams in GridKit.

Rationale

This would permit GridKit cases to be faithfully ported. This would also allow us to create a consistent and in-house style for case documentation.

Description

A dedicated file for GIS data and/or layout of the circuit. Some options:

• *.oneline.json
• *.diagram.json
• *.geo.json

Additional information

I do have a personal tool which plots one-line diagrams of GridKit, and currently stores longitude and latitude in the extensions section of Bus in the INPUT_FORMAT. I am quite fond of the *.solver.json and *.case.json pattern and am curious to hear if this might be of interest as well.

@pelesh

[pelesh]

This is certainly of interest. See, for example ExaGO visualizer. We would eventually want similar visualization capability in GridKit.

My suggestion would be to have latitude/longitude info in our JSON input file format, because that information is part of the model.

For single-line diagram editing we would likely need separate configuration file to store configuration of graphics widgets, etc.

[lukelowry]

That ExaGO visualizer is quite impressive. And I agree that graphics should be in a separate config file.

I think that GIS data should go in the JSON input file format, as you said, for two reasons:

• GIS data is a modeling concern used for weather-integrated models (wind, solar, geomagnetic disturbances, etc)
• Not necessarily used for visualization (tho thats why I want it at this point in time!)

One possible format:

 "buses": [
     { 
       "number": 1, 
       "class": "bus", 
       "name": "Bus 1", 
       "init": {....}, 
       "mon": [...],
       "geo":{
           "longitude": 89.000,
           "latitude": -30.000,
           "altitude": 0,
        }
    },
    { 
       "number": 2, 
       "class": "bus", 
       "name": "Bus 2", 
       "init": {....}, 
       "mon": [...],
       "geo":{
           "longitude": 90.000,
           "latitude": -31.000,
           "altitude": 0,
        }
    }
]

I am particularly in favor of a path-specified GIS data format for branches not only for richer one-line diagrams, but also because if we ever support geomagnetic disturbance modeling, we would need to support specifying the transmission line path in space:

{
 "class": "Branch", 
"ports": {"bus1":1, "bus2":2}, 
"id": "BR1", 
"params": {"R":0.0, "X":0.1, "G":0.0, "B":0.0},
"geo":
  {
       "longitude": [x1, x2, ..., xN],
       "latitude": [y1, y2, ...., yN],
       "altitude": [z1, z2, ...., zN]
   }
}

This could be added as a no-op in the parser, thoughts? I'd love feedback on the proposed syntax, or anything you learned from the ExaGO project.