#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 eschnett):
Roland: We tried storing parameters as attributes, and found that this has a large size and time overhead. This was unacceptable, and we thus had to revert this change. We also used to output much more information about the grid structure, but also had to remove this output again, for the same reasons.
Mapping to the respective HDF5 types is trivial; the respective functionality exists in Carpet, based on C++ templates.
We can certainly change the format of multi-line strings in Formaline. The current format is similar to the one used in Cactus parameter files.
Cactus generates parameter files in the output directory. If there is no option to generate all parameter values (including the defaults), then we should add this. I would like to add that having the original parameter file around is also important, since it often contains comments that are useful to know later on, even if they are not usable in visualization scripts.
Instead of parsing parameters, would it make sense to output more information regarding the grid structure? The grid structure should be easier to parse (or can be modified to be so), and is the only authoritative information anyway. The influence of parameters on run-time decisions is often very indirect, e.g. they may be ignored after recovering. In particular for post-processing or visualization, I think you should be looking at other sources of information, and we should add these to make this possible.
Ian: The config-format does not easily handle multi-line strings, or strings with beginning/trailing white space. I designed the parameter storage format to be similar to Cactus parameter files. If we want to be able to use the config-file format, then we should probably at the same time design a parameter file format for it. I am not particularly fond of multi-line strings or leading/trailing white space, so we may just do away with them at the same time, and design better mechanisms to handle long lists (of thorns or variables) in parameter files.