# DAKOTA INPUT FILE: dakota-matlab.in for parallel Case 1 (Massively Serial)

environment
  tabular_data
  tabular_data_file = 'table_out.dat'


method
 vector_parameter_study
 step_vector = 1 10
 num_steps = 12

variables
   continuous_design = 2
   initial_point = 1 10
   descriptors  'p1' 'p2'


# Case 1 (Massively Serial): Run Dakota in parallel and launch M-1 serial
#         analysis jobs at once.  Do not specify any evaluation concurrency
#         (handled by parallel scheduler)
#         fork interface is recommended
interface,
        fork
# In an M processor allocation, by default Dakota will configure with
# a master scheduler with M-1 slave analysis processes.  Overriding
# this with evaluation_scheduling peer static will avoid this dedicated 
# master and use all M processors, but then each batch of M analyses will 
# have to complete before the next M are scheduled.  This may be useful if 
# all evaluations are known to take the same processor time:

#         evaluation_scheduling peer static

# Dynamic scheduling may also be specified. In this mode, the first peer will
# attempt to act as both a master scheduler and an evaluation server. 
# Consequently, all M processors will be used as in the static case. Unlike the
# static case, evaluations are delegated to servers on the fly, making dynamic
# scheduling the better choice when evaluations may be of varying duration.

          evaluation_scheduling peer dynamic

          analysis_drivers = 'driver-matlab.sh'                       # For Linux/Mac
          parameters_file = 'params.in'
          results_file    = 'results.out'
          file_tag
          file_save
          work_directory
          named 'workdir'
          directory_tag
          directory_save
          copy_files = 'myfact.m' 'mymfile.template'


responses
      num_objective_functions = 2
      descriptors = 'p1_factorial'
                    'p2_factorial'
      no_gradients
      no_hessians

