1. Overview and configuration

The LOVE-simulator is part of the LSST Operation and Visualization Environment (L.O.V.E.) project and it is written in Python. The LOVE-simulator defines a set of CSC simulation tools to be used for development/demonstration purposes. Therefore, it is only used in development deployment stacks and not in real operations.

In short, the LOVE-simulator is used to simulate some of the CSCs of the LSST, enabling the LOVE-producer to get simulated data through SAL:

As shown in the figure above, there are different software instances interacting with SAL:

Simulator: defines a set of remotes that send commands through SAL to simulated (or real) instances of different CSCs

ScriptQueue sim: defines a set of controllers that simulate instances of ScriptQueues (can be more than 1 instance with different salindexes

ATDome sim: defines a set of controllers that simulate instances of the ATDome

ATMCS sim: defines a set of controllers that simulate instances of the ATMCS

TestCSC sim: defines a set of controllers that simulate instances of the TestCSC

Watcher sim: defines a set of controllers that simulate instances of the Watcher

In a typical deployment, there is an instance of the LOVE-simulator (built from, the simulator module) and 1 instance of each (simulated) CSC defined in the csc-sim module. Some of the CSC simulators have been developed in separate repositories by LSST staff and repackaged/tweaked in this repository. This is done in order to fit LOVE’s development and deployment strategies for easier usage.

The config.json gives information of which CSCs and in which SAL topics (and their indices) to simulate. Environment variables are also read to configure other parameters.

1.1. Defining simulated CSCs with `config.json`

The LOVE-simulator and simulated CSC instances read a config.json file (located in the simulator/config/ folder) to create the instances of the simulation tools. This file specifies for each CSC the SAL index and a “source” for the data. The “source” can be either:

command_sim: specifies that the data will be sent by a simulated CSC
emitter specifies that the data will be simulated with random values by the simulator itself.

For example:

{
    "Test": [
        { "index": 1, "source": "command_sim" },
        { "index": 2, "source": "emitter" },
    ],
    "ScriptQueue": [
        { "index": 1, "source": "command_sim" },
        { "index": 2, "source": "command_sim" }
    ],
    "ATDome": [
      { "index": 1, "source": "command_sim" }
    ],
}

configures the following instances:

1 instance of a “Test” CSC with salindex 1 that will be simulated using a CSC simulator
1 instance of a “Test” CSC with salindex 2 that will be simulated with random values by the simulator itself.
2 instance of “ScriptQueue”s, with salindexes 1 and 2, that will be simulated using a ScriptQueue simulator
1 instance of an “ATDome” CSC with salindex 1 that will be simulated using an ATDome simulator

1.2. Environment variables

Two environment variables must be set to configure the simulators:

LSST_DDS_DOMAIN: Used by salobj to filter SAL messages in the network.
OSPL_URI: Location of the ospl.xml file that defines the network configuration.

1. Overview and configuration

1.1. Defining simulated CSCs with config.json

1.2. Environment variables

1.1. Defining simulated CSCs with `config.json`