Experiment Handler¶

The experiment_handler package contains a single module, experiment_handler, that is a standalone program.

experiment_handler process¶

This program runs a given experiment. It will use the experiment’s build_scans method to create the iterable InterfaceClassBase objects that will be used by the radar_control block, then it will pass the experiment to the radar_control block to run.

It will be passed some data to use in its update method at the end of every integration time. This has yet to be implemented but will allow experiment_prototype to modify itself based on received data as feedback.

copyright: 2018 SuperDARN Canada
author: Marci Detwiller

src.experiment_handler.experiment_handler(semaphore, args)[source]¶

Run the experiment. This is the main process when this program is called.

This process runs the experiment from the module that was passed in as an argument. It currently does not exit unless killed. It may be updated in the future to exit if provided with an error flag.

This process begins with setup of sockets and retrieving the experiment class from the module. It then waits for a message of type RadarStatus to come in from the radar_control block. If the status is ‘EXPNEEDED’, meaning an experiment is needed, experiment_handler will build the scan iterable objects (of class InterfaceClassBase) and will pass them to radar_control. Other statuses will be implemented in the future.

In the future, the update method will be implemented where the experiment can be modified by the incoming data.

Parameters

semaphore (threading.Semaphore) – Semaphore to protect operations on the experiment
args (argparse.Namespace) – Command line provided arguments

src.experiment_handler.experiment_parser()[source]¶

Creates the parser to retrieve the experiment module.

Returns: parser, the argument parser for the experiment_handler.
Return type: argparse.ArgumentParser

src.experiment_handler.main(sys_args)[source]¶

src.experiment_handler.retrieve_experiment(experiment_module_name)[source]¶

Retrieve the experiment class from the provided module given as an argument.

Parameters: experiment_module_name (str) – The name of the experiment module to run from the Borealis project’s experiments directory.
Raises: ExperimentException – if the experiment module provided as an argument does not contain a single class that inherits from ExperimentPrototype class.
Returns: The found experiment that inherits from ExperimentPrototype
Return type: ExperimentPrototype

src.experiment_handler.send_experiment(exp_handler_to_radar_control, iden, serialized_exp)[source]¶

Send the experiment to radar_control module.

Parameters

exp_handler_to_radar_control (ZMQ socket) – socket to send the experiment on
iden (str) – ZMQ identity
serialized_exp (bytes) – Either a pickled experiment or a None.

src.experiment_handler.usage_msg()[source]¶

Return the usage message for this process.

This is used if a -h flag or invalid arguments are provided.

Returns: the usage message
Return type: str

Usage¶

experiment_handler.py¶

usage:  experiment_handler.py [-h] experiment_module scheduling_mode_type

    Pass the module containing the experiment to the experiment handler as a required
    argument. It will search for the module in the BOREALISPATH/experiment_prototype
    package. It will retrieve the class from within the module (your experiment).

    It will use the experiment's build_scans method to create the iterable InterfaceClassBase
    objects that will be used by the radar_control block, then it will pass the
    experiment to the radar_control block to run.

    It will be passed some data to use in its .update() method at the end of every
    integration time. This has yet to be implemented but will allow experiments to
    modify themselves based on received data as feedback. This is not a necessary method
    for all experiments and if there is no update method experiment updates will not
    occur.

experiment_module¶: The name of the module in the experiment_prototype package that contains your Experiment class, e.g. normalscan

scheduling_mode_type¶: The type of scheduling time for this experiment run, e.g. common, special, or discretionary.

-h, --help¶: show this help message and exit

--embargo¶: Embargo the file (makes the CPID negative)

--kwargs <kwargs>¶: Keyword arguments for the experiment. Each must be formatted as kw=val