Summary
Many power system cases come preconfigured with lines that are out of service. We need to support this and add a field to indicate whether, for example, a branch is open or closed, or whether a generator is in service.
Additionally, we might consider treating Branch as a special category, much like Bus is treated in the input format.
Rationale
This is a precursor to support a new event type Open/Close or something similarly named to indicate component status. This will also allow us to fully import case data without omitting inactive elements.
Regarding the second suggestion, there are quite a few branch models that are needed and should be completed before we push for more models, IMHO.
Description
The system model should compose and support a status field that takes a component out of service, in addition to a field in the file format that is standard and well-named to communicate intent
The branch model class in the input format could be like:
"buses": [
{ "class": "bus", ... },
{ "class": "infinite_bus",... }
],
"branches": [
{
"class": "xfmr",
"ports": [1, 2],
"name": "...",
"status": "active",
"init": {...},
"params": {...}
},
{
"class": "xfmrtertiary", // three-winding transformer
"ports": [4, 5, 6] ,
"name": "...",
"status:" "active",
"init": {...},
"params": {...}
},
{
"class": "hvdc",
"ports": [4, 5] ,
"name": "...",
"status": "active",
"init": {...},
"params": {...}
},
{
"class": "line",
"ports": [4, 5] ,
"name": "...",
"status": "active",
"init": {...},
"params": {...}
},
],
Additional information
(regarding status as a field) If this requires changing the system model's dimension at runtime, it should be noted.
Summary
Many power system cases come preconfigured with lines that are out of service. We need to support this and add a field to indicate whether, for example, a branch is open or closed, or whether a generator is in service.
Additionally, we might consider treating
Branchas a special category, much likeBusis treated in the input format.Rationale
This is a precursor to support a new event type
Open/Closeor something similarly named to indicate component status. This will also allow us to fully import case data without omitting inactive elements.Regarding the second suggestion, there are quite a few branch models that are needed and should be completed before we push for more models, IMHO.
Description
The system model should compose and support a status field that takes a component out of service, in addition to a field in the file format that is standard and well-named to communicate intent
The branch model class in the input format could be like:
Additional information
(regarding status as a field) If this requires changing the system model's dimension at runtime, it should be noted.