Clunky input for parameter studies.

[rrsettgast]

I have noticed that running scaling studies (or parameter studies) by splitting up xml files is still quite clunky. For instance if we wanted to run 4 meshes, we could take the mesh block and place each of them in a file (mesh0.xml, mesh1.xml...), then we include the meshX.xml in another file (problem.xml) with the rest of the specifications....however the include statement explicitly contains the name of the meshX.xml so then you need 4 variants of problem.xml.

Of course, you could play some games with subdirectories and symbolic links (i.e. always include mesh.xml in run0/problem.xml, but have run0/mesh.xml--> mesh0.xml) but this could get a little clunky as well.

Another solution would be to create a third file (run0.xml) that includes some combination of meshX.xml and problem.xml where the latter does't include the former. This does explicitly keep a record of the files used for a run....which is nice.

One other solution would be to allow two xml files be read from the command line, with the xml nodes combined when read. this might be the most flexible.

@cssherman @francoishamon @mquanbui thoughts?

[cssherman]

@rrsettgast - The strategy that I prefer for this is to use Parameters and the Include strategy that are implemented in the python xml preprocessor (these can be built and placed into the bin directory using make geosx_xml_tools). The pre-processing command (preprocess_xml input.xml -o output.xml) creates a static/permanent xml file that can be read by GEOSX. Here's an example of a file that I have developed for some modeling:

<Problem>
  <Parameters>
    <Parameter
      name="mesh_root"
      value="/usr/workspace/uwisc/WHOLESCALE/mesh_development/large_scale_all_faults"/>
    <Parameter name="table_root"
      value="/usr/workspace/uwisc/WHOLESCALE/geologic_model/derived_from_poisson_ratio"/>

    <Parameter name="pressure_init_time" value="5 [day]"/>
    <Parameter name="pump_start" value="200 [day]"/>
    <Parameter name="pump_shutdown" value="1000 [day]"/>
    <Parameter name="shutdown_time" value="20 [hour]"/>
    <Parameter name="post_shutdown" value="3 [day]"/>
    <Parameter name="init_dt" value="1 [day]"/>
    <Parameter name="max_dt" value="20 [day]"/>
    <Parameter name="shutdown_dt" value="1 [hour]"/>
  </Parameters>

  <Included>'
    <File name="/usr/WS1/uwisc/WHOLESCALE/numerical_models/geosx/large_scale_poroelastic_all_faults/poroelastic_problem.xml"/>
    <File name="/usr/WS1/uwisc/WHOLESCALE/numerical_models/geosx/large_scale_poroelastic_all_faults/2016_wells.xml"/>
    <File name="/usr/WS1/uwisc/WHOLESCALE/numerical_models/geosx/large_scale_poroelastic_all_faults/well_nodesets.xml"/>
    <File name="/usr/WS1/uwisc/WHOLESCALE/numerical_models/geosx/large_scale_poroelastic_all_faults/microseismic.xml"/>
  </Included>
</Problem>

The parameters (which can be strings, floats, etc.) are used throughout the included xml files. The string parameters here define a root path for the different meshes and tables. A major benefit for this approach is that it isolates things that you may want to modify, and would allow a non-super user to run a sensitivity analysis. They can also help to clean up sections of an xml file where strings are re-used a lot, for example:

<Functions>
    <TableFunction
      name="bulk_modulus"
      inputVarNames="{ elementCenter }"
      coordinateFiles="{ $table_root$/x.csv, $table_root$/y.csv, $table_root$/z.csv }"
      voxelFile="$table_root$/bulkModulus$table_modifier$.csv"/>
</Functions>

In this example, I am also testing some configurations with different wells/pumping. These can be swapped in/out by including different files.

[rrsettgast]

Yes. I forgot about the other option which is the use of parameters...but this still requires extra intermediate files.

[cssherman]

I imagine that we could eventually pass these as command line arguments (geosx -i input.xml -p x0 1.0 -p x1 2.0 ...). However, this would not be as useful when distributing to others, and could be quite cumbersome for problems with a large number of parameters.

[rrsettgast]

yeah, but including multiple xml files wouldn't be so cumbersome

[cssherman]

Sounds reasonable to me. This would be pretty easy to implement in the pre-processor as well

[rrsettgast]

Of course...we run the risk of having too many ways a user can hang themselves.

[rrsettgast]

@cssherman Do you have the time to implement this?

[cssherman]

@rrsettgast - sure, I can give this a try