<div dir="ltr">Hey Michael,<div><br></div><div>Thanks for the comments. I had originally thought about putting the variables in a new module that was something like "mpas_model_variables.F", but I didn't see the value in doing that when we had mpas_constant.F already. I had also thought about putting them in the domain structure, so maybe I'll give that a try and see how it works out.</div>
<div><br></div><div style>I think it's perfectly fine to change version to modelVersion. The only real value I saw with having the core_name attribute separate was that it would be easier to determine the core. Also, in the case you describe with the history attribute overflowing, this would prevent that from removing the core name from the output files. For example, if someone used several nco operations on the input file before running it, it might not work with the fixed sizes I declared.</div>
<div style><br></div><div style>I don't know if this is possible, but something that might be better would be to copy the history attribute from the input file, and then create a new history attribute that is the command used to run MPAS. As you said, this would be more appropriate with the definition of the history attribute. I don't think we should go down the route of using Fortran 2003 features, since it could introduce portability issues that we probably don't want to deal with. Especially since the history attribute is not necessarily important by itself (what we add to it at least).</div>
<div style><br></div><div style>We can talk some more about how to migrate history information from the old mesh to the new mesh. I think one way where the history attribute might be useful is if we could somehow input some run information (testcase name/resolution/etc) into it when running.</div>
<div style><br></div><div style>Thanks!</div><div style>Doug</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 4:26 PM, Michael Duda <span dir="ltr"><<a href="mailto:duda@ucar.edu" target="_blank">duda@ucar.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Doug.<br>
<br>
I'm testing out the branch now, and I have a few initial comments.<br>
<br>
I noticed that the variables to hold the version, model name, and core<br>
name have been added to the mpas_constants.F module. This module is<br>
currently used for physical constants, so I'd suggest we move these<br>
attribute variables elsewhere. Currently, we keep the attributes<br>
on_a_sphere and sphere_radius in the mesh type; but perhaps a better<br>
place for modelName, coreName, version, and history would be inside the<br>
domain type. If at some point in the future we add the ability to<br>
instantiate multiple models in the same MPAS executable, I think it<br>
would make sense to have attributes like modelName in the individual<br>
instances of the domain_type, which is supposed to encapsulate the<br>
complete computational state of the model.<br>
<br>
Regarding the naming of these attributes, perhaps we could rename<br>
'version' to 'model_version' to be less ambiguous. Also, given that the<br>
run command in the history attribute already includes the name of the<br>
specific executable, is there real value in including the attribute<br>
'core_name'?<br>
<br>
As you pointed out, dealing with the history string can get messy.<br>
Declaring local variables as StrKIND*2 and StrKIND*4 should work in most<br>
instances, but we might want to give a little more thought to whether<br>
this couldn't be handled in a more robust way. For example in cycling<br>
experiments or for longer runs that periodically restart, the history<br>
attribute could easily overflow with repetitions of "mpirun -n 128<br>
nhyd_atmos_model.exe". Fortran 2003 does support allocatable character<br>
strings, and recent versions of ifort and pgf90 have implemented support<br>
for this, but correct support in gfortran appears to require version<br>
4.8.0; and, I've not yet checked the BG/Q and xlf compilers. This also<br>
raises the question of whether running the model constitutes<br>
"modifications to the original data" (as the CF conventions describe the<br>
"history attribute").<br>
<br>
Thanks for all of your work on this so far, and I'll let you know how it<br>
goes with my testing.<br>
<br>
Cheers,<br>
Michael<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, Apr 02, 2013 at 02:49:48PM -0600, Doug Jacobsen wrote:<br>
> Hi Everyone,<br>
><br>
> I spent part of this morning trying to add some provenance information to<br>
> the output files that MPAS creates. Currently I have it adding model name,<br>
> core name, and a version string to each output file, and adding the command<br>
> that was used to run the model to the history attribute.<br>
><br>
> You can preview the changes in the following branch.<br>
> branches/history_attribute<br>
><br>
> The current way to define this information is to modify Registry.xml with<br>
> the following syntax.<br>
> <registry model="mpas" core="core_name" version="version_string"><br>
> ...<br>
> </registry><br>
><br>
> Then when the model is built, there are parameters created in<br>
> src/framework/mpas_constants.F named<br>
> modelName<br>
> coreName<br>
> version<br>
> history<br>
><br>
> History is read in from the input grid upon runtime, and written to all<br>
> output files with the additional information describing how MPAS was run.<br>
> Currently it's hard coded to be "mpirun -n ${PROCS} ${CORE}_model.exe"<br>
> since we require MPI at build time.<br>
><br>
> If the model, core, and version strings are missing from Registry.xml<br>
> currently it replaces their values with "MISSING", and writes those to the<br>
> output files so there is no negative consequences.<br>
><br>
> I've tested this branch with the ocean model and it doesn't change results<br>
> in the current trunk. I also tested building with the shallow water core,<br>
> when the Registry.xml information is missing.<br>
><br>
> I would like to merge this branch back onto the trunk within the next few<br>
> days unless anyone has any objections, as I think this additional<br>
> information will be important to have in the future.<br>
><br>
> Any comments/questions are welcome.<br>
><br>
> Thanks<br>
> Doug<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> mpas-developers mailing list<br>
> <a href="mailto:mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a><br>
> <a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers" target="_blank">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
<br>
</div></div></blockquote></div><br></div>