This page describes the simulation packages that are provided with the EarthCARE Simulator. The simulation packages are available (wrapped as HLA Federates) from a centralized repository.

In the EODiSP terminogy, a simulation package is a piece of software that implements part of the functionalities required for an end-to-end simulation and that is delivered as a single unit. Prior to integration with the EODiSP, simulation packages may have to be wrapped to be transformed into HLA Federates. The federates that wrap the simulation EarthCARE Simulator packages are described in a dedicated page.

KNMI Simulation Packages

The KNMI simulation packages are Linux binary executables that implement the KNMI models. They are fully described in their user guide. No further documentation is provided here.

Simulation Controller

The simulation controller (or sim_controller) is implemented as two excel spreadsheets gathered together in the same excel workbook. The excel workbook is called sim_controller.xls. The two excel spreadsheets are called Model_Configuration and Simulation_Overview.

The Model_Configuration spredsheet lists the configuration parameters of the EarthCARE Federates. Its function is to display the values of the configuration parameters and to allow the user to update these values.

After start-up, the Model_Configuration spredsheet (see screenshot below) displays the default values of the configuration parameters (this is indicated by the status field that contains the string 'DEFAULT'). The user can update this value by editing the excel cell where the value is displayed. A new value only becomes effective when the update field is set to 'DO'. After the update operation has been completed (i.e. after other federates have been notified of the change in value of the parameter), the content of the status field changes to 'UPDATE n' where 'n' is an integer that counts the number of updates.

The mechanism described in the previous paragraph allows parameters to be updated individually one by one. If the value of the 'update all' field is changed to 'YES', then all configuration values are updated simultaneously. This is the option that will normally be used to start a simulation (see the description of the simulator synchronization points).

If the simulation is intended to run as part of a simulation experiment, then the option 'automatic update' should be set to 'YES'. This implies that all configuration values will be sent to the simulation federates as soon as the simulation has started (i.e. immediately after the EODiSP_START synchronization point has been reached).

The update of simulation parameters can also be done while a simulation is running. In this case, however, there is no guarantee that the new value will be used since a federate might already have read in and used the previous value.

The Simulation_Overview spredsheet (see screeshot below) displays the status of a running simulation and allows the user to change the status of a running simulation. For each federate, three information items are displayed: the federate version, the federate execution status, and the federate failure mode. All three information items come from the federate info object class that all federates (except, of course, the sim_controller) publish. The first two items are read-only items that are read from the other federates as soon as a simulation starts. The failure mode can instead be changed by the user. The change can be done either at initialization, or while a simulation is running to simulate a fault in a running model.

Orbit Propagator

The orbit propagator (or orbit_propagator) is implemented as a single Java class called orbit_propagator.java.

The orbit_propagator class only provides the solar position angles as an output since this is the only orbital information that is required as an input by the KNMI models. The value of the two angles are read in as input parameters. Thus, the orbit propagator model simply passes on the values of the solar position angles which it receives as an input.

The orbit_propagator class only implements a dummy orbit model. Its purpose is to show how source code can be integrated into an EODiSP simulation rather than to provide a realistic orbit model.

Simulation Code

All the code implementing the EarthCARE Simulator is accessible from the download page. For each federate - and hence for each simulation package - a dedicated subdirectory is defined. The federate subdirectories can be found in the federates directory. The code for both the wrappers and the simulation packages they wrap is stored in dedicated subdirectories.