Implement system model data structure and system composer

[pelesh]

Description

Create system composer that assembles and instantiates system model from system data.

@reid-g @alexander-novo @abdourahmanbarry @Steven-Roberts

Proposed changes

This is in preparation for implementing file I/O. Features added:

• SystemModelData structure that encapsulates containers for different component models data.
• Bus factory.
• Constructor for SystemModel that takes SystemModelData as the input, instantiates all the components, and assembles the system based on the connectivity information in the system data.

SystemModelData stores system's meta model. The meta model is used to abstract I/O from the actual code and to allow system preprocessing before instantiating component models.

Checklist

• All tests pass.
• Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
• The new code follows GridKit™ style guidelines.
• There are unit tests for the new code.
• The new code is documented.
• The feature branch is rebased with respect to the target branch.

Further comments

• Factories other than bus factory will likely be needed.

[abirchfield]

My opinion on this "meta model" architecture:

Good things

• We need a better way to interface with various methods of I/O, which will of course include the text format but also a future GUI, custom scripts, etc. Ideally this would be a library anybody could interface with.
• It helps provide a layer with the "factory" concept where we can later implement validation, checking parameter bounds, and default values. We need this or catching data errors is going to get harder and harder.
• It would potentially help with preprocessing techniques, like partitioning. The "meta model" could be searched like a graph to find what buses are connected to what components
• The way it is currently set up for buses is pretty good, where there is one bus data type that handles data for any type of bus. (I'll explain why I think components should be done the same way.)

Not good things

• The "src/Model/PhasorDynamics" directory needs some cleanup (this is kind of a separate but related issue). Some folders like "Bus" have multiple components inside (Bus, BusInfinite), others have just a folder with one model inside (Load, which we may in the future have multiple load models), and category folders with multiple model subfolders (Synchronous Machine). The Bus-Component distinction kind of breaks down. Instead I suggest the following structure

    Buses/
        BaseBus.hpp
        BusData.hpp
        BusFactory.hpp
        Bus/
            Bus.hpp
            Bus.cpp
        BusInfinite/
            BusInfinite.hpp
            BusInfinite.cpp
        SignalBus/
            SignalBus.hpp
            SignalBus.cpp
    Components/
        BaseComponent.hpp
        ComponentData.hpp
        ComponentFactory.hpp
        SynchronousMachines/
            Genrou/
                Genrou.hpp
                Genrou.cpp
            Gensal/
                Gensal.hpp
                Gensal.cpp
            GenClassical/
                GenClassical.hpp
                GenClassical.cpp
        Loads/
            LoadZ/
                LoadZ.hpp
                LoadZ.cpp
        Branches/
            PiBranch/
                PiBranch.hpp
                PiBranch.cpp
        Exciters/
            IeeeT1/
                IeeeT1.hpp
                IeeeT1.cpp
            Esst4a/
                Esst4a.hpp
                Esst4a.cpp
        Events/
            BusFault/
                BusFault.hpp
                BusFault.cpp

Here I set it up with Buses and Components separate, and then components further divided into categories, and then one folder per bus class or component class. Of course I left out all the cmake and doc files.

• With the current setup each new component class is going to have huge overhead to implement. For example, we would need to do (1) the model code itself [listing all parameters] (2) the model header [listing all parameters] (3) the model data header [listing all parameters] (4) the code within the factory to create the model [listing all parameters] (5) the code in the file parser to create the data object [listing all parameters]. Instead, we should just keep the parameters as generic (string, double) pairs until we are ready to create the model component. The file parser does not need to know anything about the parameters. For each component it just needs to save a std::string class_name, std::vector<int> terminal_bus_numbers, and std::map<std::string, double> params (kind of like the file format). Then the ComponentFactory will map the class_name to the correct object, find the buses referenced by terminal_bus_numbers to connect it to, and then initialize the object with the params argument. The code for validating and correcting the parameters, and putting them into class variables, could then live inside the component itself. I am just thinking forward to having hundreds of component classes to support and having component-specific code all over the place.

[pelesh]

My opinion on this "meta model" architecture:

This is excellent feedback but it goes way beyond the scope of this PR. I created a separate issue to follow up on this: #140.

The purpose of this PR is to provide initial draft for metamodels to enable development of file I/O.

[superwhiskers]

this seems fine to me. the only thing i'd suggest is places to write

• variables to monitor
• overridden va_base and freq_base values
• disambiguation strings for devices (as in the specification)