[mpas-developers] consistent number of time levels

Doug Jacobsen jacobsen.douglas at gmail.com
Fri Jan 6 18:46:40 MST 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20120106/b5230aef/attachment.html 


More information about the mpas-developers mailing list