The goal of MultiPoint is to facilitate optimization problems that contain may different computations, all occurring in parallel, each of which may be parallel. MultiPoint effectively hides the required MPI communication from the user which results in more readable, more robust and easier to understand optimization scripts.

For our simple example, lets assume we have two parallel codes, A and B that we want to run at the same time for an optimization. The computations of A and B do not directly depend on each other; that is they can be executed in an embarrassingly parallel fashion. Lets say we need to run 2 copies of code A, and one copy of code B. The analysis path would look like:

               /------------\ Funcs
           /---|   Code A   |--->----\             User supplied objcon
           |   \------------/        |               /---------------\
Optimizer  |   /------------\ Funcs  |  Combine      | Combine funcs |  Return to
----->---- +---|   Code A   |--->--- +------>--------+ to get final  |----->------
Input      |   \------------/        |  all funcs    | obj/con       |  optimizer
           |   /------------\ Funcs  |               \---------------/
           \---|   Code B   |--->----/

Lets also assume, that the first copy of code A requires 3 processors, the second copy of code A requires 2 processors and the copy of code B requires 4 processors. For this case, we would require 3 + 2 + 4 = 9 total processors. Scripts using MultiPointSparse must be called with precisely the correct number of processors.

>>> from mpi4py import MPI
>>> from multipoint import multiPointSparse
>>> MP = multiPointSparse(MPI.COMM_WORLD)
>>> MP.addProcessorSet('codeA', 2, [3, 2])
>>> MP.addProcessorSet('codeB', 1, 4)
>>> comm, setComm, setFlags, groupFlags, ptID = MP.createCommunicators()
>>> setName = MP.getSetName()

At this point, you should have the following if you executed the code with 9 processors:

>>> print("setName={}, comm.rank={}, comm.size={}, setComm.rank={}, setComm.size={}, setFlags={}, ptID={}".format(setName, comm.rank, comm.size, setComm.rank, setComm.size, setFlags, ptID))
setName=codeA, comm.rank=0, comm.size=3, setComm.rank=0, setComm.size=5, setFlags={'codeA': True, 'codeB': False}, ptID=0
setName=codeA, comm.rank=1, comm.size=3, setComm.rank=1, setComm.size=5, setFlags={'codeA': True, 'codeB': False}, ptID=0
setName=codeA, comm.rank=2, comm.size=3, setComm.rank=2, setComm.size=5, setFlags={'codeA': True, 'codeB': False}, ptID=0
setName=codeA, comm.rank=0, comm.size=2, setComm.rank=3, setComm.size=5, setFlags={'codeA': True, 'codeB': False}, ptID=1
setName=codeA, comm.rank=1, comm.size=2, setComm.rank=4, setComm.size=5, setFlags={'codeA': True, 'codeB': False}, ptID=1
setName=codeB, comm.rank=0, comm.size=4, setComm.rank=0, setComm.size=4, setFlags={'codeA': False, 'codeB': True}, ptID=0
setName=codeB, comm.rank=1, comm.size=4, setComm.rank=1, setComm.size=4, setFlags={'codeA': False, 'codeB': True}, ptID=0
setName=codeB, comm.rank=2, comm.size=4, setComm.rank=2, setComm.size=4, setFlags={'codeA': False, 'codeB': True}, ptID=0
setName=codeB, comm.rank=3, comm.size=4, setComm.rank=3, setComm.size=4, setFlags={'codeA': False, 'codeB': True}, ptID=0

The input to each of the Objective Functions is the (unmodified) dictionary of optimization variables from pyOptSparse. Each code is then required to use the optimization variables as it requires.

The output from each of Objective functions funcs is a Python dictionary of computed values. For computed values that are different for each member in a processorSet or between processorSets it is necessary to use unique keys. It is therefore necessary for the user to use an appropriate name mangling scheme.

In the example above we have two copies of Code A. In typical usage, these two instances will produce the same number and type of quantities but at different operating conditions or other similar variation. Since we need these quantities for either the optimization objective or constraints, these values must be given a unique name.

A simple name-mangling scheme is to simply use the ptID variable that is returned from the call to createCommunicators:

def objA(x):
    funcs['A_%d'%ptID] = function_of_x()

    return funcs

A similar thing can be done for B:

def objB(x):
    funcs['B_%d'%ptID] = function_of_x()

    return funcs

A processorSet is characterized by a single “objective” and “sensitivity” function. For each processorSet we must supply Python functions for the objective and sensitivity evaluation.

>>> MP.setProcSetObjFunc('codeA', objA)
>>> MP.setProcSetObjFunc('codeB', objB)
>>> MP.setProcSetSensFunc('codeA', sensA)
>>> MP.setProcSetSensFunc('cdoeB', sensB)

The functions sensA and sensB must compute derivatives of the functionals with respect to the design variables defined in the optProb Optimization problem class. Derivatives use the dictionary sensitivity return format described in pyOptSparse documentation.

multiPointSparse will then automatically communicate the values and call the user supplied objcon function with the total set of functions. The purpose of objcon is to combine functions from the individual objective functions to form the final objective and constraint dictionary for pyOptSparse. A schematic of this process is given below:

                     Pass-through keys
  all funcs    |                                |   output to pyOptSparse
------->------ + input     /--------\ output    |------------->----
               \-------->--+ objcon | ----------/
                 keys      \--------/ keys

multiPointSparse analyzes the optimization object and determine if any of the required constraint keys are already present in all funcs, these keys are flagged as “pass-through”…that is they “by-pass” entirely the objcon function. The purpose therefore of objcon is to use the remaining functions in all funcs (the input keys) to compute the remainder of the required constraints (output keys) and objective. For example:

def objcon(funcs):
    fobj = 0.0
    for i in range(2):
        fobj += funcs['A_%d'%i]

    fobj /= funcs[B_0]
    fcon['B_con'] = funcs[B_0]/funcs[A_0]
    return fobj, fcon

There all three values contribute to the objective, while A_0 and B_0 combine to form the constraint B_con. This example has no pass-though keys.

Generally speaking, the computations in objcon should be simple and not overly computationally intensive. The sensitivity of the output keys with respect to the input keys is computed automatically by multiPointSparse using the complex step method.


Pass-through keys cannot be used in objcon.


Computations in objcon must be able to use complex number. Generally this will mean if numpy arrays are used, the dtype=complex keyword argument is used.

The objcon function is set using the call:

>>> MP.setObjCon(objCon)

As noted earlier, multiPointSparse uses the optimization problem to determine which keys are already constraints and which need to be combined in objcon. This is done using:

>>> optProb = Optimization('opt', MP.obj)
>>> # Setup optimization problem
>>> # MP needs the optProb after everything is setup.
>>> MP.setOptProb(optProb)
>>> # Create optimizer and use MP.sens for the sensitivity function on opt call
>>> snopt(optProb, sens=MP.sens, ...)