This tutorial provides an example of using batch evaluations and parallel processing in an optimization workflow.
This tutorial requires an existing Tutorials project. If you have not created this project yet, see Tutorial Project first.
- Open the Tutorials project.
- Open OptimizationIntegrated (OptimizationIntegrated.p7wf).
- Select File ‣ Save Workflow As... to create a copy of the workflow. Save the workflow as OptimizationBatch.
- Verify that you are editing OptimizationBatch and continue with the tutorial.
When searching for optimum, Optimizer usually generates more than one set of variable values at each optimization step. For example, multiple solutions have to be evaluated in order to estimate objective and constraint gradients at the current point. By default, Optimizer outputs these points in a sequence and generates a new batch of points after it receives all needed function values. In the batch optimization mode it outputs the whole batch of variables at once and receives a batch of responses. This mode, in particular, allows to take advantage of parallel processing on modern multi-core CPUs, if the blocks that evaluate problem functions are configured to perform calculations in parallel.
This tutorial is based on the OptimizationIntegrated workflow that uses a simple external solver to evaluate objective functions (see Integrated Component Optimization). The task here is to reconfigure the Optimizer and Model blocks in this workflow to enable the batch optimization mode and perform parallel processing of point batches generated by Optimizer.
Briefly, required changes in block configuration are:
- Enable the batch mode in Optimizer and specify the maximum batch size (note that it is 1 by default).
- Enable parallel input processing in the Model block. Note that it is also possible to process the input batch sequentially using a Map block to create a loop, similarly to the Sampling Loop tutorial. However, in the current case parallelization is actually simpler, not to mention that it is more effective than sequential processing.
For comparison purposes, it is also suggested to add a workflow parameter that controls the batch size, as explained below. This will allow you to quickly adjust parallelization settings and study changes in workflow behavior.
To enable the batch mode, open Optimizer configuration and tick the “Batch mode” checkbox on the Problem definition tab.
Also verify that the “Noisy problem” option preset is selected. This is required because the Model block in this workflow can return NaN values (imitating solver failures).
Note that enabling the batch mode changes types of variable and objective ports to List (see the Ports tab). However it does not automatically increase the batch size: corresponding limit is set by GTOpt/BatchSize which is 1 by default, so all batches will contain one point only (see section Batch Mode for details). You can change this value on the Options tab in Optimizer configuration or add a workflow parameter to enable changing the batch size in Run.
If you choose to add GTOpt/BatchSize to parameters, click in the Optimizer configuration dialog without changing the option value and switch to the workflow configuration tool.
Click on the edit toolbar to open the Workflow configuration dialog.
Select the Parameters tab. Currently it is empty because no workflow parameters were added yet.
Click on the parameters pane or select Add parameter... from the pane’s context menu to open the Add parameter dialog.
In the Add parameter dialog, select “Optimizer” on the left pane, then select the GTOpt/BatchSize option on the right pane.
Click to create the parameter and close the Add parameter dialog. The new parameter appears on the pane. Specify some alias for readability — for example, name it “Batch Size”.
Click in the Workflow configuration dialog to confirm changes and return to the workflow.
The “Batch Size” parameter should now appear on the Configuration tab in Run.
You can verify that it exists and has a default value of 1. This default is the option value specified in Optimizer configuration; if you specify another value here, it will override the option value when you start the workflow.
- Open Model configuration.
- On the Configuration tab, select “Enable Parallel Execution”.
- Select the x port from the drop-down list. The parallelization ratio can be left default (4).
The input and output ports (Model.x and Model.f) change their type to List when you enable parallel execution. Optimizer in the batch mode also has ports of the List type, so there is no need to configure port types manually.
Note that the parallelization ratio does not have to be equal to the GTOpt/BatchSize value. It limits the number of parallel processes Model is allowed to create, but if the batch size is greater than the ratio, Model will automatically distribute input points between processes and accumulate responses to the output batch. A general recommendation would be to set the parallelization ratio equal to the number of CPU cores, while batch size an be an arbitrary value greater than the ratio.
General workflow structure remains the same. Note that parallel processing is enabled in the Model block.
The key change is that now Model receives point batches from Optimizer (samples containing multiple points to evaluate) and processes them in parallel in the same way as it was done in the Parallelization tutorial (see section Workflow there).
To test the workflow, you can run it with different batch size settings and compare the block startup statistics output in the Statistics pane.
Begin with the default batch size 1. Generally this is the same as running optimization without enabling the batch mode.
Next, set the batch size to 4.
Note that Launcher started the same number of times as with batch size 1: optimization trajectory in variable space remains the same (hence the same total number of evaluations), and pSeven counts the total number of Launcher startups in all parallel processes created by Model. However, the number of Model startups is now less: this block starts only once for each batch received from Optimizer. Note also that the number of Launcher startups is not equal to 4 times the number of Model startups. It means that not every batch contains exactly 4 points: actual size may be less than GTOpt/BatchSize, since this option sets only the upper batch size limit.
Finally, try running the workflow with batch size 10.
Note that the block startup statistics is the same as in the previous case (with batch size 4). Despite the size limit was increased, Optimizer did not utilize it — this is normal, as the current optimization mode does not benefit much from batch calculations. A significant increase in effectiveness can be seen in other cases — in particular, robust optimization and surrogate-based optimization.