Hi Michael,<br><br>I&#39;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&#39;s registry definition. State appears to have xtime&#39;s time_levs defined regardless of what you set in the line. <br>

<br>I can go through and fix the definitions so they are all consistent, but it appears to not really make a difference. I don&#39;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.<br>

<br>I don&#39;t know if there&#39;s a more informative fix for this or if we should just stick with this, but it was just an observation I made earlier.<br><br>Doug<br><br><div class="gmail_quote">On Fri, Jan 6, 2012 at 6:29 PM, Michael Duda <span dir="ltr">&lt;<a href="mailto:duda@ucar.edu">duda@ucar.edu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Folks.<br>
<br>
While doing some registry-related work, I noticed that in the nhyd_atmos<br>
and ocean registries, we have fields belonging to the same group (e.g.,<br>
diag or state) that have different numbers of time levels; however, the<br>
registry requires all fields in the same group to have the same number<br>
of time levels. I&#39;ve corrected this in the nhyd_atmos core, but thought<br>
I&#39;d leave it to someone in a better position to test the ocean model to<br>
make the changes there. In the ocean core, the fields in question are:<br>
<br>
   FBtr<br>
   GBtrForcing<br>
   circulationBtr<br>
   divergenceBtr<br>
   vorticityBtr<br>
   u_diffusionBtr<br>
<br>
which I think should be given two time levels to match other state<br>
variables.<br>
<br>
Cheers,<br>
Michael<br>
_______________________________________________<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>
</blockquote></div><br>