Run Time_Architecture - nasa/gunns GitHub Wiki

{{>toc}}

Run-Time Architecture

Class Diagram

This class diagram shows the relationship between the main components of an example Basic network and the Trick sim object it resides in. Most of the individual class attributes are omitted for clarity:

Classes

This describes the classes in the above diagram.

SimObject

This is the top-level object in the Trick sim. This derives from TrickSimObject (not shown) and contains the Network and defines the Trick jobs (initialize, run, etc) that tells Trick when to call what methods in the Network.

The SimObject can contain multiple networks and other objects besides GUNNS networks.

Network

This is the top-level GUNNS-specific object in the Trick sim. It and everything in it is usually entirely auto-generated by a design GUI such as GunnsDraw. It owns all of the other objects.

Gunns (the Solver)

There is always one solver in any network. The solver holds arrays of pointers to all of the nodes and links in the network, which it loops over during its step to build & solve the system of equations and propagate the network’s state. The nodes & links main step methods are only called by the solver, thus we say the solver orchestrates the nodes & links.

The solver doesn’t know about spotters and can’t update them during its step.

GunnsBasicNode

There are always at minimum 2 nodes in any network: 1 Ground node and 1 or more normal nodes. The Ground node is always the last node in the container. The nodes are the only objects that don’t know about any other objects, but almost all other types of objects know about the nodes. Because of this, GunnsBasicNode.hh is included in almost all other classes, so it is a convenient place to implement generic functions common to all GUNNS objects, such as the Health & Status interface macro’s, etc. Someday we may clean this up and factor out the macro’s to their own include file.

GunnsNodeList

GunnsNodeList is actually a struct. There is always one node list in any network. Its purpose is mainly as a convenient place to group the node array and its size.

GunnsBasicLink

There are zero or more links in any network, although a network with no links in it would not be very interesting. GunnsBasicLink is never directly instantiated. Instead, it provides the abstract interface to the other objects, and real links always ultimately derive from GunnsBasicLink.

GunnsBasicConductor

This is an example of a derived link type that would be used in a network. The example diagram above shows the network containing 3 GunnsBasicConductors. Networks can contain any number of links in any combination of types, because through polymorphism they all have the same interface with the network, solver & nodes.

GunnsNetworkSpotter

There are zero or more spotters in any network. Like GunnsBasicLink, this is an abstract interface class that can’t be directly instantiated. Rather, derived classes are instantiated in the network as needed. This class creates the abstract interface to the network. Unlike the nodes & links, which are updated by the solver, the spotters are updated by the network itself.

GunnsBasicIslandAnalyzer

This is an example of a derived spotter that would be used in a network. These derived spotter classes can interface with any other object in the network, depending on their design. This particular example is designed to interface with the network’s GunnsNodeList, but spotters can also directly interface with the solver, links, nodes or other spotter as needed.

Config & Input Data

Links & Spotter Pattern

This describes the design pattern used for the config & input data of Links & Spotters. Below is a UML class diagram of the relationships between a Link or Spotter base class, its config & input data classes, and the derived classes of each. Note that the Link & Spotter base class constructor is protected so the base class can never be directly used — only derived classes can be used in a network.

The class “Base” in the drawing represents the actual Link & Spotter base classes: GunnsBasicLink and GunnsNetworkSpotter, respectively.

Network Pattern

This describes the design pattern for the config & input data of a GunnsDraw-generated Network (which includes the config & input data of the contained Links & Spotters). Below is the class diagram of the Network and its config & input data objects. This pattern is slightly different than used by the Links & Spotters:

⚠️ **GitHub.com Fallback** ⚠️