Intelligent Parallel Multiple Run (PMR-I)

Intelligent Parallel Multiple Run (PMR-I) was first released as part of the PSCAD v4.5 minor upgrade. PMR-I allows for one master project, to control multiple slave projects, where both master and slaves must be part of the same Simulation Set. The idea behind the development of PMR-I was to support both parameter sweep, as well as optimization-based, multiple-run studies.

Like the simulation sets, PMR-I is an inherent part of the workspace, which enables inter-project communication within a single simulation set. This is accomplished using the already well defined Radio Link transmitter and receiver components, which were extended in v4.5 to include a provision field for a foreign namespace (that is, another project within the workspace). This instructs the link to collect its value from a foreign source, and thus allows for a more sophisticated means of multiple run control.

The image above illustrates an example simulation set containing three projects: One configured as a master and two configured as slaves. Each slave project communicates with the master via radio link transmitters and receivers. The master also communicates with the slaves in the same way. Communication between projects is performed only between runs; that is, following the end of one run and before the start of the next. In this way, the master project distributes the control parameters to the slaves, and the slaves send result data back to the master (via radio links). The master uses the results data from the slaves to generate input data before the next run starts.

To configure a project as master or slave, change the Run Configuration field under the Runtime tab in the project settings.

NOTE: Radio links possess an additional facility for the purpose of plotting its value for each run, within the master project.

EXAMPLE A (Non-Volley):

Consider the Robust Optimization example workspace in the PSCAD examples folder under ...\Examples\Parallel_and_HP_Computing\PMR-I (start PSCAD and load this workspace if desired to better follow along with this example explanation). This workspace is composed of four projects, one configured as a master (chopper_optimization) and the other three as slaves.

In this example, we focus on the simultaneous simulation set (non-volley), where three slave projects containing a chopper circuit are run in parallel for each multiple run. Before the start of each run, the master project (called chopper_optimization), which contains the Optimum Run component, provides each slave project with unique, initial data. The data provided to the slave projects is the DC parallel capacitor value Cdc, the DC series inductor value Ldc, and the proportional and integral gain values (I_gain and P_Gain) for the PI controller component. All four of these values are transmitted from the master to each slave project using radio links.

NOTE: The rank number specified in each of the radio links is 0. This signifies that the signal is being transmitted to all simulation instances. In this example, there is only one simulation instance for each project.

Each chopper project is unique, in that the input constant tags in each control circuit are slightly different.

The differing inputs to the control circuit result in a unique output quantity from each slave. A single output signal, being the objective function (Objective) is transmitted back to the master via radio links.

NOTE: The rank number specified in each of the radio links in the master is 1. This is because this is a non-volley simulation and so there is only one unique instance of each simulation.

The master project in this example contains a plot of the three, unique objective functions coming back from each slave case, where the x-axis is the multiple run number. See Running Simulations Sets for more.

PMR-I with Volley Launch

PMR-I can also be used in combination with volley launch. Making use of volley launch will reduce the number of slave projects you need to maintain, down to just one. The volley rank number is then utilized to provide differentiation between simulation instances.

EXAMPLE B (Volley):

Consider again the Robust Optimization example workspace described above.

In this example, we focus on the volley simulation set, where a single slave project containing a chopper circuit is launched as a volley of three for each multiple run. As in EXAMPLE A, before the start of each run the master project (called chopper_optimization2), which contains the Optimum Run component, provides the slave project initial data. The data provided is the DC parallel capacitor value Cdc, the DC series inductor value Ldc, and the proportional and integral gain values (I_gain and P_Gain) for the PI controller component. All four of these values are transmitted from the master to the slave project using radio links.

NOTE: The rank number specified in each of the radio links is 0. This signifies that the same signal is being transmitted to all simulation instances in the volley. In this case, all three simulation instances will receive the same data values from the master.

The chopper slave project is being launched as a volley and so all simulation instances will be identical. As such, we must rely on the simulation rank number in order to provide each simulation instance with unique values. The input constant tags that were made unique in each slave project in EXAMPLE A, have been moved to the master project in this example, and then the data transmitted to each simulation instance via the rank number.

NOTE: A unique set of three values needed by each simulation instance are transmitted from the master, given a specific rank number. A rank number of 0 is specified in the slave to indicate that it should only receive transmitted data matching it's rank number.

A single output signal, being the objective function (Objective) is transmitted back to the master via a radio link.

NOTE: The rank number is specified in each of the radio links in the master.