#1565: change default of IOUtil::out_save_parameters to true --------------------------+------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: review Priority: optional | Milestone: Component: Cactus | Version: development version Resolution: | Keywords: --------------------------+-------------------------------------------------
Comment (by rhaas):
The hdf5 files (checkpoint as well as regular hdf5 output) already all contain a dataset "/Parameters and Global Attributes/All Parameters". For example the yt reader would use this information to present it to the user or to construct units or the grid structure. It may also be useful to obtain the equation of state information that way or minimum temperature or atmosphere density. Right now only some information is present in the hdf5 files (namely only those parameters that were steered) by default. I am not sure if Ian's Mathematica based postprocessing system parses parfiles or not. If it does it may benefit from being able to parse the better formatted "/Parameters and Global Attributes/All Parameters" dataset instead (since it already has all substitutions performed, comments removed, special characters escaped).
Right now the parameters dataset is output each time a dataset is written to the file, overwriting the previous "/Parameters and Global Attributes/All Parameters" dataset. It would be better (as indicated in the ticket) to actually save the history of parameter changes.
I do not know on top of my head if (or which) of our hdf5 manipulation tools copy this dataset. I would expect that hdf5_extract likely does (since it copies datasets recursively) but eg hdf5_slicer may not.
All the information that characterizes a run should (I think) be in the parameters (since they are the only thing that initially describes the simulation to the code). Tabulated initial data and equation of state tables are separate files but the file names are mentioned in the parfiles.
The HTTP thorn can steer parameters based on user input which would show up as a regular parameter change.
It may not be possible to exactly reproduce the state of the parameters at each moment in the simulation if eg a parameter is steered more than once during the same iteration or steered (for identical iteration number) after some refinement levels are already processed. This situation is similar to other Cactus output however.
We will need some discipline to prevent users from using parameters as evolving quantities since with these changes a parameter that is steered at each iteration effectively becomes a grid scalar.