[mpas-developers] consistent number of time levels

[Michael Duda]

Hi, Doug.

You're right in that, currently, the number of time levels for a field
in the registry doesn't usually make a difference -- most of the code in
the registry program makes the assumption that all fields of a group
have the same number of time levels, that number being determined by
(probably) the first field in the group. The new code that I'd been
working on in the registry doesn't make this assumption, and therefore
breaks when some registry-generated code assumes a differing number of
time levels from what is actually specified in the registry. For a bit
of background, the registry program has a parser, which reads the
registry file into a set of data structures, and then many bits of
essentially independent code -- one for each .inc file that is included
somewhere in the framework -- that generate code based on the registry
data structures.

In practice, there's no reason why we couldn't allow different fields in
a group to have different numbers of time levels, but the cost in terms
of complexity of this extra flexibility seemed a bit high back when much
of the registry code was written. So, it's probably best practice for
now to keep the number of time levels within a field group consistent;
to enforce this, I suppose we could even add a "registry validation"
step right after parsing, but before code generation.

Cheers,
Michael


On Fri, Jan 06, 2012 at 06:46:40PM -0700, Doug Jacobsen wrote:
> Hi Michael,
> 
> I've actually explored this today too, since I made a field in a branch
> that I just committed to the trunk today with only 1 time_lev (that was in
> state). It appears that nothing within state actually makes use of the
> time_levs option in it's registry definition. State appears to have xtime's
> time_levs defined regardless of what you set in the line.
> 
> I can go through and fix the definitions so they are all consistent, but it
> appears to not really make a difference. I don't know if diag fields have
> the same property (that their tiime levels are defined by xtime). I guess
> having it in the registry file explicitly at least gives an answer to
> anyone who is curious about it, but it can also be misleading where you
> might want to change a specific field and have it have a time_levs of 1 to
> save space.
> 
> I don't know if there's a more informative fix for this or if we should
> just stick with this, but it was just an observation I made earlier.
> 
> Doug
> 
> On Fri, Jan 6, 2012 at 6:29 PM, Michael Duda <duda at ucar.edu> wrote:
> 
> > Hi, Folks.
> >
> > While doing some registry-related work, I noticed that in the nhyd_atmos
> > and ocean registries, we have fields belonging to the same group (e.g.,
> > diag or state) that have different numbers of time levels; however, the
> > registry requires all fields in the same group to have the same number
> > of time levels. I've corrected this in the nhyd_atmos core, but thought
> > I'd leave it to someone in a better position to test the ocean model to
> > make the changes there. In the ocean core, the fields in question are:
> >
> >   FBtr
> >   GBtrForcing
> >   circulationBtr
> >   divergenceBtr
> >   vorticityBtr
> >   u_diffusionBtr
> >
> > which I think should be given two time levels to match other state
> > variables.
> >
> > Cheers,
> > Michael
> > _______________________________________________
> > mpas-developers mailing list
> > mpas-developers at mailman.ucar.edu
> > http://mailman.ucar.edu/mailman/listinfo/mpas-developers
> >