kwschultz
commented
8 years ago See the next issue on setting constants in the parameter file.
Open markyoder opened 9 years ago
kwschultz
commented
8 years ago See the next issue on setting constants in the parameter file.
summary of objecctives: 1) clean up the run-time parameter file workflow, eliminate redundancies. for example: a) if an output file is specified as "*.h5", assume hdf5 format. b) permit a generic "sim.greens.inputoutput" file that acts universally as an input/output based on the sim.greens.method = {file, standard, etc.} value.
the basic idea is to simplify the input logic tree to be more user friendly, still very flexible (aka, sim.file-output_event_type=text && sim.file.output_event=blah_blah.h5 will still write a text file, but sim.file.output_event=blah_blah.h5 by itself will default to hdf5).
2) add constants, scaling exponents, etc. (optionally) to the input parameter file. we can use the same, standard params.d file (regular run-time parameters), or we can use a separate text/hdf5 file (which might be a better idea, since we might want to move around these parameterizations differently). example parameters are: UpdateBlockStress.cpp:UpdateBlockStress::init(): double rho = 5.515e3; // density of rock in kg m^-3 double g = 9.81; // force of gravity in m s^-2 double depth = 0.0; (though what we might do is add a depth_default=0.0 run-time parameter). there are also instances in rupture length, area, etc. calculations where constants and scaling exponents are specified.
what we'd like to see is a framework whereby, going forward, these values can be easily removed from hard-coding and added to the parameter file. supplying default values will, of course, be critical. maybe a SimParameters() class? or maybe just a simple map/dict object. presumably, we want a workflow like (for a case where we're assigning a variable that might be found in the parameters file): double default_rho = 5.51e3; double rho = sim->get_var("rho", default_rho); where get_var will either retrieve the variable "rho" or assign the default_rho value.
3) can we (optionally?) integrate the fault model + greens_functions files? the motivation for this is simple: a set of greens_functions is compatible only with a very specific fault model. this may simply be a matter of combining the salient components from the greens_functions (greens_normal, greens_shear) and the fault_model hdf5 files into a single file and pointing both the 'greens input' and 'fault input' (not naming them correctly here), in the input parameters file, to that file. referencing syntax like "my_h5_file['my_table']['my_col'] will not be concerned about which other tables we've stuffed into the file.