Support Component Status + Enrich Branch Model

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.

Start by reviewing the system model and input format, then compare how Bus and existing branch models are represented. Determine how component status should be represented for inactive lines and generators, how branch categories should be organized, and how imported inactive elements should be preserved. Done means the model and file format have an agreed status representation that supports the proposed future Open/Close events.