DOE Drivers - Running a Design of Experiments (DOE)¶
Drivers that run a design of experiments (DOE) all inherit from the PredeterminedRunsDriver class. Some examples are FullFactorialDriver, UniformDriver, and the subject of this tutorial, OptimizedLatinHypercubeDriver.
The Latin Hypercube Driver¶
The Latin Hypercube (LHC) method of randomization generates samples across an entire range of desired design variables. The Optimized Latin Hypercube (OLHC) is an improvement on the LHC method in which samples generated by the LHC are adjusted to ensure an expansive distribution.
Below is an example using the component from the Paraboloid Tutorial - Simple Optimization Problem.
from openmdao.api import IndepVarComp, Group, Problem, ScipyOptimizer, ExecComp, DumpRecorder
from openmdao.test.paraboloid import Paraboloid
from openmdao.drivers.latinhypercube_driver import OptimizedLatinHypercubeDriver
top = Problem()
root = top.root = Group()
root.add('p1', IndepVarComp('x', 50.0), promotes=['x'])
root.add('p2', IndepVarComp('y', 50.0), promotes=['y'])
root.add('comp', Paraboloid(), promotes=['x', 'y', 'f_xy'])
top.driver = OptimizedLatinHypercubeDriver(num_samples=4, seed=0, population=20, generations=4, norm_method=2)
top.driver.add_desvar('x', lower=-50.0, upper=50.0)
top.driver.add_desvar('y', lower=-50.0, upper=50.0)
top.driver.add_objective('f_xy')
recorder = DumpRecorder('paraboloid')
recorder.options['record_params'] = True
recorder.options['record_unknowns'] = False
recorder.options['record_resids'] = False
top.driver.add_recorder(recorder)
top.setup()
top.run()
top.cleanup()
Here we will explain the code statements that pertain to using an Optimized Latin Hypercube (OLHC).
from openmdao.drivers.latinhypercube_driver import OptimizedLatinHypercubeDriver
In order to setup a model to utilize the OLHC, we need to import OptimizedLatinHypercubeDriver.
root.add('p1', IndepVarComp('x', 50.0), promotes=['x'])
root.add('p2', IndepVarComp('y', 50.0), promotes=['y'])
root.add('comp', Paraboloid(), promotes=['x', 'y', 'f_xy'])
By promoting the variables x and y to the group level, no connect statement is needed for the paraboloid component to receive these as input variables. Similarly, when we define the OLHC design variables, we can simply call the same x and y without any additional code.
The next three lines will initialize and add design variables to the OLHC.
top.driver = OptimizedLatinHypercubeDriver(num_samples=4, seed=0, population=20, generations=4, norm_method=2)
top.driver.add_desvar('x', lower=-50.0, upper=50.0)
top.driver.add_desvar('y', lower=-50.0, upper=50.0)
The first line initializes the driver. The ‘num_samples’ argument determines how many samples each design variable will cycle through. By default, the ‘seed’ argument itself is a random value. However, by choosing a seed value, we can easily duplicate a sample set for a repeatable testing environment.
The next two lines define the ranges of the design variables on which the OLHC will operate.
Now we are ready to record data. The four intervals of [-50, 50) are: [-50,-25), [-25,0), [0,25), [25,50). The LHC will ensure there is an x and y value in each interval.
The recorded output is shown below. It’s been filtered to show only the generated input values.
Timestamp: 1446745425.935
Iteration Coordinate: Driver/0
Params:
comp.x: -34.5655676503
comp.y: -37.7665306197
Timestamp: 1446745425.936
Iteration Coordinate: Driver/0
Params:
comp.x: 47.7779475273
comp.y: 14.7245403548
Timestamp: 1446745425.936
Iteration Coordinate: Driver/0
Params:
comp.x: -7.77803623101
comp.y: 34.1373674836
Timestamp: 1446745425.936
Iteration Coordinate: Driver/0
Params:
comp.x: 1.49637359158
comp.y: -14.9422886231
As you can see, there is an ‘x’ and ‘y’ value in each interval. The OLHC was able to set up 3 of the 4 input combinations to be in different intervals from each other, ensuring better coverage of the parameter space.
Running a DOE Driver in Parallel¶
All drivers inheriting from PredeterminedRunsDriver take an initialization argument named num_par_doe. This is used to specify the desired number of cases to be performed concurrently. The default value is 1, but you can set it to a higher value and run your model in parallel.
If you have mpi4py and petsc4py installed, you can run your model using mpirun and your DOE cases will be run in parallel using MPI. To learn how to properly install all of the dependencies needed to run in parallel, see MPI on Linux or MPI on Windows.
If you don’t have mpi4py or petsc4py, your cases will be run concurrently using the multiprocessing library.
When running parallel DOEs, it’s important to be aware of which variables you are saving in your recorders. Parallel DOE cases run in separate processes and the recorder variables have to be transferred back to the master process. By default, recorders record every parameter and unknown, so if you don’t actually need to know every variable value, you can specify which variables you want as follows:
recorder.options['includes'] = ['x', 'y', 'f_xy']
Also, when doing parallel DOEs with multiprocessing, you should avoid using recorders anywhere other than in the top level driver. Recorders in solvers, even at the top level, will not function properly. The reason for this is that when running under multiprocessing, there is only one transfer of data from a worker process back to the master process, and that happens only at the top level after the call to root.solve_nonlinear() completes.
Finally, when using multiprocessing on a Windows machine, your entire model must be picklable, because multiprocessing on Windows uses pickle to create a copy of your model in each new process. On linux and OS X, picking isn’t necessary because fork() is used to duplicate the parent process.