The Task
class defined in C++ provides the base implementation for tasks, which are simple events that execute periodically or as scheduled. Derived classes should implement specific functionality within the start
and execute
functions. This guide provides an overview of how to interact with the Task
class and its derived classes: Model
, Monitor
, and Event
.
The Task
Class
Description and Naming
The Task
class defines a base task with parameters, inputs, and outputs. Derived classes should implement the start
and execute
functions to define specific task behavior. The Task
class should not be used on its own.
For a complete guide on interacting with the Task
and Model
classes, refer to the Doxygen documentation:
Task Doxygen
Model Doxygen
Models vs. Tasks
Note that the Model class can do everything that a task can do. Model vs. Task really indicates intent — is the object a model? Or is it a software task? All of the task documentation here applies equally to model.
The only noteworthy code difference between models and tasks is that models are designed for simulation, and work with the simulation executive (rather than a generic executive, as is the case with Task). This means models have access to powerful features offered only by the simulation executive, but should not be used for any embedded applications.
Activation and Deactivation
Models and Tasks can (and should) be deactivated when they are not being used. Each is provided a default deactivate function which may be overridden.
Debugging
Models and Tasks may be set to a specific logging level independent of the simulation by setting the log level.
C++
task.logLevel(DEBUG); // Valid choices are DEBUG, INFO, WARNING, ERROR, NONE -- default is WARNING
Python
task.logLevel(DEBUG) # Valid choices are DEBUG, INFO, WARNING, ERROR, NONE -- default is WARNING
A Note on Scheduling
Tasks are created as standalone objects, but can be integrated or "scheduled" by the simulation executive. This is how they are typically handled, although special circumstances may require that they are not.
The simulation posesses three steps which are executed every time the simulation steps forward in time:
-
START_STEP, which runs a single time at the beginning of the sim step
-
DERIVATIVE, which runs every time derivatives are calculated in the integrator (once per step for Forward Euler integration, four times for RK4)
-
END_STEP, which runs a single time at the end of the sim step.
When tasks and models are created and made a child of the simulation executive, they are by default scheduled to run at all the above. However, they may be scheduled to run at one of the following options:
-
NOT_SCHEDULED Run only manually when called within another model or individually
-
STARTUP_ONLY Run only on simulation startup (the task start step) and not afterwards unless called within another model or individually
-
ALL Run every simulation step
-
START_STEP, run a single time at the beginning of the sim step
-
DERIVATIVE, run every time derivatives are calculated in the integrator (once per step for Forward Euler integration, four times for RK4)
-
END_STEP, run a single time at the end of the sim step.
Creating a Task
Description | C++ Example | Python Example |
---|---|---|
Default Constructor - Creates a default |
|
|
Executive Constructor - Creates a default |
|
|
Child Constructor - Creates a default |
|
|
Constructor with Parent Task - Creates a default |
|
|
Running a Task
Description | C++ Example | Python Example |
---|---|---|
Starting Up a Task - Performs startup activities for the task. |
|
|
Running a Task - Runs the task periodically. |
|
|
Activating and Deactivating a Task
Description | C++ Example | Python Example |
---|---|---|
Activating a Task - Activates the task. |
|
|
Deactivating a Task - Deactivates the task. |
|
|
The Model
Class
The Model
class is a derived class of Task
designed around the "black box" design of models. It should be implemented in derived classes via class inheritance.
Creating a Model
Description | C++ Example | Python Example |
---|---|---|
Default Constructor - Creates a default |
|
|
Constructor with Parent Task - Creates a |
|
|
Constructor with Executive - Creates a |
|
|
The Monitor
Class
The Monitor
class is a simplified model that checks one or multiple conditions and sets a flag when triggered. It should be implemented in derived classes to define specific monitoring behavior.
Creating a Monitor
Description | C++ Example | Python Example |
---|---|---|
Default Constructor - Creates a default |
|
|
Constructor with Parent Task - Creates a |
|
|
Constructor with Executive - Creates a |
|
|
Running a Monitor
Description | C++ Example | Python Example |
---|---|---|
Running a Monitor - Runs the monitor and checks conditions. |
|
|
Resetting a Monitor - Resets the monitor’s trigger to false. |
|
|
The Event
Class
The Event
class is designed to run only when triggered by an external flag, typically tied to the Monitor
class. Derived classes should implement specific event behavior.
Creating an Event
Description | C++ Example | Python Example |
---|---|---|
Default Constructor - Creates a default |
|
|
Constructor with Parent Task - Creates an |
|
|
Constructor with Executive - Creates an |
|
|
Running an Event
Description | C++ Example | Python Example |
---|---|---|
Running an Event - Runs the event when triggered. |
|
|