Scheduler domain¶

momotor.options.domain.scheduler.preflight.create_preflight_result(providers, trigger, action, status)¶

Create a ResultsBundle with a pre-flight result for the given action

Return type:: ResultsBundle | None

momotor.options.domain.scheduler.preflight.preflight_check(providers)¶

Evaluate a preflight@scheduler option in the given providers and return a ResultsBundle with a result as defined by the preflight option for the task with id task_id if any pre-flight options activated.

Parameters:: providers (Providers) – the providers to use for resolving the pre-flight option
Return type:: ResultsBundle | None
Returns:: a ResultsBundle with a result as defined by the preflight option, or None if no pre-flight action should be taken.

momotor.options.domain.scheduler.preflight.PREFLIGHT_OPTION¶

The preflight@scheduler option allows recipes to indicate situations in which the checklet does not have to be executed.

preflight@scheduler option¶

A preflight check handled by the scheduler. This allows recipes to indicate situations in which the step does not have to be executed.

See Scheduler preflight option for the documentation of this option.

Type:: string
Required:: False
Multiple:: True
All:: True
Location:: config, recipe, step
Default:: No default

momotor.options.domain.scheduler.tasks.get_scheduler_tasks_option(recipe, config, step_id)¶

Get the tasks@scheduler option for a single step from the step, recipe or config.

Parameters:

recipe (RecipeBundle) – the recipe bundle
config (ConfigBundle | None) – (optional) the config bundle
step_id (str) – the id of the step

Return type:

Sequence[int] | None

Returns:

the tasks option, parsed into a tuple of ints

momotor.options.domain.scheduler.tasks.TASKS_OPTION¶

The tasks@scheduler option defines the number of sub-tasks for a step.

tasks@scheduler option¶

Enable multiple tasks for this step. If not provided, a single task is generated for this step.

See Scheduler tasks option for the documentation of this option.

Type:: string
Required:: False
Multiple:: False
Location:: config, recipe, step
Default:: No default

momotor.options.domain.scheduler.tools.get_scheduler_tools_option(recipe, config, results, *, task_id)¶

Evaluate the tool requirements by parsing the tools@scheduler option for a single step in the given bundles.

This gets the value of the tools@scheduler option for the step, and subsequently gets the specific tool version requirements (if any) from the options in the tools domain.

A step requiring tools must define the tools@scheduler in the recipe. The tool version options are defined in the tools domain in the normal locations: config, recipe, step.

Example of a step defining some tool requirements:

<recipe ...>
  ...
  <step ...>
    ...
    <options domain="scheduler">
      <option name="tools" value="anaconda3" />
    </options>
    <options domain="tools">
      <option name="anaconda3" value="anaconda3/_/momotor anaconda3" />
    </options>
    ...
  </step>
  ...
</recipe>

This indicates to the scheduler that this step requires the anaconda3 tool. It also indicates to both the scheduler and to the checklet that will execute this step that the anaconda3/_/momotor version is preferred, but if not available any anaconda3 will do.

For the format of the tool version requirements, see Tool registry.

Parameters:

recipe (RecipeBundle) – The recipe bundle.
config (ConfigBundle | None) – The config bundle.
results (ResultsBundle | None) – The results bundle.
task_id (StepTaskId) – The task id.

Return type:

ToolRequirements

Returns:

The tool requirements for the requested step and task.

momotor.options.domain.scheduler.tools.TOOLS_OPTION¶

The tools@scheduler option defines the tools required for a step.

tools@scheduler option¶

List of tools required for the step. Can only be provided by <step> nodes.

Multiple tools can be provided by using multiple tools@scheduler options, or using a single tools@scheduler option with multiple tool names. Multiple tool names on a single option should be space or comma separated.

The list of tools should only contain tool names. Any detailed version requirements should be defined with options in the tools domain.

See the tool registry documentation on how this option is used to resolve a tool.

Type:: string
Required:: False
Multiple:: True
All:: False
Location:: step
Default:: No default