standard for code meta data

I'm playing around with the Maestro/BoxLib frontend. Maestro (and Castro) plotfiles contain a file called job_info that stores a lot of metadata, including the values of all runtime parameters and the git hashes corresponding to which versions of the various codes were used to build the executable. Currently we have all of the runtime parameters stored in the parameters dictionary. I'd like to add the version control hashes in a dictionary as well. I can add them to the same parameters file, but I am wondering if other codes use a standard place for this. Ultimately I'd like to save some of this information (especially the code hashes) in the output files that yt generates: i.e. as png metadata, simple postscript comments for eps files, or pdf metadata for pdf files. This will help complete the link toward reproducibility in that it will preserve the chain of information from code to output to plot. Mike -- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

Hi Mike, On Sun, Apr 13, 2014 at 9:11 PM, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
I'm playing around with the Maestro/BoxLib frontend. Maestro (and Castro) plotfiles contain a file called job_info that stores a lot of metadata, including the values of all runtime parameters and the git hashes corresponding to which versions of the various codes were used to build the executable. Currently we have all of the runtime parameters stored in the parameters dictionary. I'd like to add the version control hashes in a dictionary as well. I can add them to the same parameters file, but I am wondering if other codes use a standard place for this.
Well, no, for the most part "parameters" is a pretty overloaded place where we dump things that (in 3.0) yt does *not* rely on. Individual frontends might, but we are attempting to stamp out all queries of "parameters" outside of the frontend specific code. There's also the contents of "minimal representation" (._mrep on a Dataset) which are specified as: _attr_list = ("dimensionality", "refine_by", "domain_dimensions", "current_time", "domain_left_edge", "domain_right_edge", "unique_identifier", "current_redshift", "output_hash", "cosmological_simulation", "omega_matter", "omega_lambda", "hubble_constant", "name") Now, these are up for grabs and are only used for the (currently down) hub upload, but they do cover the various things that yt expects to have accessible.
Ultimately I'd like to save some of this information (especially the code hashes) in the output files that yt generates: i.e. as png metadata, simple postscript comments for eps files, or pdf metadata for pdf files. This will help complete the link toward reproducibility in that it will preserve the chain of information from code to output to plot.
This would be quite amazing.
Mike
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Matthew Turk
-
Michael Zingale