brainstorming for dakota input file

[fnrizzi]

environment,
  tabular_data

method,
  model_pointer = 'NONHIER'
  bayes_calibration muq
  mlmcmc # ** MSE: Let's use "multilevel_mcmc" as the start of a new XML group (see "ENTITY" specifications) **
  seed = 34784
  proposal_covariance
    diagonal
      values 1.0e16
  # ------------------
  # params for mlmcmc
  # ------------------
  initial_chain_samples = 500

  # the target variance that needs to be achieved
  mlmcmc_target_variance 0.05  # ** MSE: group with multilevel_mcmc in XML so prepend can be dropped **

  mlmcmc_num_levels = 4 # ** MSE: this can likely be inferred from the model specification**

  # the subsampling step is the # of steps to take on the coarse before using for the next higher level 
  # here we can have one value for each level 
  mlmcmc_subsampling_steps 5 3 1 0 # ** MSE: group with multilevel_mcmc in XML so prepend can be dropped **

model,
    id_model = 'NONHIER'
    surrogate ensemble
      truth_model = 'HF'

model,
    id_model = 'HF'
    simulation
      solution_level_control = 'mesh_size'
      solution_level_cost = 1 4 16 64

variables,
  uniform_uncertain 2
    descriptors 'a' 'b'
    lower_bounds 0.0 0.0
    upper_bounds  100.0 200.0
    initial_point 1.0 2.0
 discrete_state_set
   integer = 1
         set_values = 11 22 44 88
         descriptors = 'mesh_size'

interface,
  analysis_drivers 'muq_mlmcmc_correctness_test.py'
    fork
    parameters_file 'params.in'
    results_file 'results.out'

responses,
  calibration_terms = 2 # **MSE: changed from response_functions**
  no_gradients
  no_hessians

[mseldre]

Above, I suggested a bit more verbosity on mlmcmc --> multilevel_mcmc. Within the NonDMUQBayesCalibration iterator, one can query the model for the number of solution levels, so I don't think this needs to be a separate specification. W.r.t. other subordinate specifications like target_variance and subsamplingsteps, these can be grouped within the XML, so the mlmcmc prepend can be dropped for brevity.

The model and variables sections above look correct to me. The uniform random variables will be active in the inference and the state variable is carried along for the ride (it affects the simulation but is not visible to the MCMC). I made a change to the response type (calibration_terms) and there is a lot more that could be added here w.r.t. experimental data, observational uncertainty, etc. In the current minimalist spec, it would be assumed that the QoI mismatches are already embedded in the calibration terms by the user's driver.