Single input file for stochastic tools runs

[zachmprince]

Reason

To streamline the syntax for common and simple STM runs, it would be beneficial to allow a syntax to run a stochastic simulation within one input file. This would improve user-friendliness for these common or simple runs. The idea is not to allow all of STM features with this, only the most primal ones like a parameter study.

Design

Here is an example input I think I would like to see for this problem:

[ParameterStudy]
  sampling_type = lhs
  num_rows = 5000

  distributions = 'uniform weibull normal normal'
  uniform_lower_bound = '0.5'
  uniform_upper_bound = '2.5'
  weibull_location = '-110'
  weibull_scale = '20'
  weibull_shape = '1'
  normal_mean = '300 100'
  normal_standard_deviation = '45 25'

  parameters = 'Materials/constant/prop_values Kernels/source/value BCs/right/value BCs/left/value'
  postprocessors = 'T_avg q_left'
  statistics = 'mean stddev'
[]

# All the physics stuff ###########################
[Mesh]
  type = GeneratedMesh
  dim = 2
  nx = 10
  ny = 10
[]

[Variables/T]
  initial_condition = 300
[]

[Kernels]
  [time]
    type = ADTimeDerivative
    variable = T
  []
  [diff]
    type = ADMatDiffusion
    variable = T
    diffusivity = diffusivity
  []
  [source]
    type = ADBodyForce
    variable = T
    value = 100
    function = 1
  []
[]

[BCs]
  [left]
    type = ADDirichletBC
    variable = T
    boundary = left
    value = 300
  []
  [right]
    type = ADNeumannBC
    variable = T
    boundary = right
    value = -100
  []
[]

[Materials/constant]
  type = ADGenericConstantMaterial
  prop_names = 'diffusivity'
  prop_values = 1
[]

[Executioner]
  type = Transient
  solve_type = NEWTON
  num_steps = 4
  dt = 0.25
[]

[Postprocessors]
  [T_avg]
    type = ElementAverageValue
    variable = T
    execute_on = 'initial timestep_end'
  []
  [q_left]
    type = ADSideDiffusiveFluxAverage
    variable = T
    boundary = left
    diffusivity = diffusivity
    execute_on = 'initial timestep_end'
  []
[]

[Outputs]
[]

The list of distributions that should be supported:

• Normal
• Uniform
• Weibull
• Lognormal
• TruncatedNormal

The list of samplers that should be supported:

• MonteCarlo
• LatinHypercube
• CartesianProduct
• CSVSampler
• A new sampler where users simply provide the matrix at input.

There are two big hurdles with this approach that I see:

1. Being able to build the stochastic multiapps without the second input file. I think this can be accomplished by giving the input itself as the multiapp input and giving a command-line argument ParameterStudy/enable=false.
2. Disabling all the physics for the stochastic main app. This part I don't have any good ideas for. Maybe we can tell the parser to ignore everything except what's under the ParameterStudy block, but I'm not sure if that is possible or if we made it possible how it can be abused.

Impact

User-friendly stochastic tools. This can also pave the way for applications to provide a similar syntax for specific types of stochastic runs.

[GiudGiud]

Controversial idea: Specify the MultiApp input in a block:

[MultiAppInput]
  [app1]
     [variables]
     ..
     []
     [kernels]
     ..
     []
  []
[]

You could also re-use blocks from the main app like:

[MultiAppInput]
  [app1]
    reuse_main_app_mesh_block = true
    reuse_main_app_executioner_block = true
    [variables]
    ..
    []
    [kernels]
    ..
    []
  []
[]

Then there are two paths to deal with this:

• write the subapp input to a file and parse it as usual. This would be real easy. Then you would need to control through CLI or have controls in the subapp to receive parameters. With this method of control, we could control ALL input parameters
• run all the actions from the subapp with the input that is encapsulated. This might require some duplicate code to engage the right train of actions in this other context. You could control input parameters (that are controllable) likely a little more directly

[somu15]

Will this effect any of the adaptive and active learning schemes?

[zachmprince]

Will this effect any of the adaptive and active learning schemes?

@somu15 This will not. We can work on that later maybe, this will be a first step for simple parameter studies.

[YaqiWang]

I like this syntax. Because we will have an action for [ParameterStudy], we can check the level of app with MooseApp::multiAppLevel in its act function. For a subapp, we skip, for the main-app we perform something like adding the subapp with the same input file. It can also be used to inform MOOSE to skip other actions. A crazy idea is to do something in the main.C, i.e. built the driver directly like constructing a sampler, etc. But that is possibly not doable. Will the parameters need to be controllable?

[YaqiWang]

Controversial idea:

Yeah, some people want more input files, some want one single input file ;-) I actually like this idea. It is irrelevant with this issue though. You might suggesting wrap the entire physics related inputs in MultiAppInput? That is less appealing.

[zachmprince]

Will the parameters need to be controllable?

No they will not. My idea is to change the type of STM simulation done by either checking if the parameters are controllable or adding another parameter for this.

[GiudGiud]

@YaqiWang I dont think it s irrelevant at all. It s moving the whole multiapp input from "in the main app input file, same input as the parameter study" to "within MultiAppInput block". It should be exactly the same capability as Zach is laying down in the first post, just with a more encapsulated syntax.

It would also benefit the wider community, not just stochastic tools