Batching and Parallelization

[PardhavMaradani]

Hi @orbeckst, @jeremyleung521, @amruthesht, @HeydenLabASU,

Given there were a few questions about how batching and parallelization work during yesterday's sync-up, here is a brief writeup on how they are currently implemented:

Each analysis widget has two attributes that specify it's 'run frequency' and 'run mode' respectively.

_run_frequency specifies how often the widget is run. It takes one of two values: every-frame or batch.

_run_mode specifies how the widget code is run. It takes one of two values: serial or parallel.

Both the attributes are mutually exclusive.

Here are the defaults as specified in the WidgetBase class:

    _run_frequency = "every-frame"
    _run_mode = "serial"

A widget class can make these attributes dynamically changeable at runtime as well by making them as inputs, which then show corresponding options in the GUI. ROG and DSSP widgets are current examples where both of these are configurable at runtime from the GUI.

_run_frequency

As the name indicates, this specifies how often the widget is run.

When _run_frequency is every-frame, a method is invoked for every frame of the trajectory iteration.

When _run_frequency is batch, a method is invoked when a new batch of timesteps is full. A global 'Batch size' under 'Settings > Universe Configuration' controls the size of the timesteps buffer.

The method that is invoked depends on the _run_mode.

If the _run_mode is parallel, see the next section to see what gets invoked.

If the _run_mode is serial:

When _run_frequency is every-frame a run_every_frame method is invoked.

When _run_frequency is batch, a run_batch method is invoked.

_run_mode

This attribute specifies how the widget analysis code is run.

If the _run_mode is parallel for a given widget instance, a get_parallel_job method is invoked to retrieve the parallel job (a joblib.delayed tuple). A global 'Parallel Jobs' under 'Settings > Dashboard Configuration' controls the total number of jobs run in parallel during each iteration (n_jobs param of joblib.Parallel call).

If a widget has _run_mode as parallel, after the parallel job is completed, a apply_parallel_results method is invoked where the results from the parallel job are passed back to the instance. The instance can apply the results back to its data structures (like updating it's values deque etc).

If a widget has _run_mode as serial, one of the methods described in the previous section are invoked.

Timesteps buffer

Irrespective of when or how they are invoked, all the methods described above have access to the full timesteps buffer - last 'n' frames including the current frame (The size of this buffer is the 'Batch size') and can use regular indexing to access them.

The ROG analysis widget shows an example of how this buffer is manually iterated in batch mode. The DSSP analysis widgets shows an example of how to invoke the AnalysisBase-run() in both batch / every-frame mode.

Hopefully this info will help with how we add new analysis widgets.

Thanks

ps. The implementation above closely follows what was discussed in Execution of Dashboard widgets