|
|
### System Layout
|
|
|
|
|
|
In this section we will discuss how to extend a [system](https://pulse.kitware.com/_system_methodology.html) by describing how to encapsulate or extend functionality in a system. We will discuss how to access data from other [systems](https://pulse.kitware.com/physeng.html#SystemsInterface), a [circuit](https://pulse.kitware.com/_circuit_methodology.html), and [compartments](https://pulse.kitware.com/physeng.html#CompartmentsInterface). It is important to read the linked references as well as be familiar with the [Pulse Common Data Model](https://pulse.kitware.com/_c_d_m.html) when extending a system.
|
|
|
|
|
|
#### Functionality Encapsulation
|
|
|
|
|
|
As discussed in the [system](https://pulse.kitware.com/_system_methodology.html) documentation, a system's functionality is encapsulated and referenced by several high level methods: Preprocess, Process, and Post Process. Functionality methods are always called during the PreProcess stage. Unless you are creating a new system with a new circuit, you will not need to add any functionality to Process or PostProcess. If you have created a new or extended an existing algorithm to compute new system data, you should add code to push data to the CDM in the systems `CalculateVitalSigns` (or similarly named) method called in the Process method.
|
|
|
|
|
|
System should strive to encapsulate a model in a single function that is called from the system preprocess function. You may need to just add code to an existing function, or create a whole new function if this is completely new functionality.
|
|
|
|
|
|
##### Adding new member variables
|
|
|
|
|
|
##### System Initialization/Setup
|
|
|
|
|
|
#### Accessing Data from the CDM
|
|
|
|
|
|
##### Other Systems
|
|
|
|
|
|
##### Compartments
|
|
|
##### Compartments and Circuits
|
|
|
|
|
|
#### Testing Functionality
|
|
|
|
|
|
##### Adding a new Scenario
|
|
|
|
|
|
##### Validation
|
|
|
|
|
|
|
|
|
|
|
|
##### Circuits
|
|
|
|
|
|
|