Job Dictionary

A Job dictionary is maintained by each worker during execution of the codes list (defined in the the configuration file. The purpose of the Job dictionary is to provide a mutable object that user’s can read from and write to if they are using preprocessing or postprocessing functions to make modifications between simulations in the code list. The Job dictionary is also passed to the objective function to provide information about the final state of the job.

The Job dictionary will always contain several pre-populated fields containing information about the state of the job. These can be read from or even overwritten by the pre/postprocess functions. However, in the latter case caution is advised as this can certainly break the rsopt run if not done properly. Pre-populated fields are:

  • inputs: This is a dictionary of parameters and settings for the job being run. This is populated for each job before preprocess is called. Because any inputs files are written after preprocess is called this allows users to make modifications or additions to the inputs dictionary. This is useful setting covariables in particular. An example of covariable setting is shown below:

     1   def my_preprocess(J):
 2      # Let's say we want a linear relationship between the variable 'x' which is being set by
 3      #  rsopt directly and another input variable in the simulation 'y'. This can't be written
 4      #  into the rsopt configuration file but we can enforce it here. If we write a value for 'y'
 5      #  into J['inputs'] it will be passed to the simulation function.
 6
 7      # Current value of x
 8      x = J['inputs']['x']
 9      # Set y based on a linear relationship with x
10      y = 3 * x
11      # Create an entry for y in the Job dictionary inputs field
12      J['inputs']['y'] = y
13
14      # No return value needs to be set for pre/postprocess functions

  • rand_stream: Holds a numpy.Generator (Generators) object for each worker. This can allow processes on the worker to generate unique, random numbers. See seed under Options<options for instructions on how to control the seeding of the Generators.

  • sim_status: This is an integer code that is set after a simulation has finished that details whether the simulation finished successfully or not; or if something else happened. It is only available for use with postprocess functions and objective functions. This status is actually being set and used by the libEnsemble library that rsopt uses. For a list of statuses and their descriptions see calc_status. This can be useful for instance to check if a Job failed to complete fully. The state can be checked in the objective function and used to invoke alternate calculation routines if a penalty function needs to be evaluated.