[mpas-developers] question about EXPAND_LEVELS

[Michael Duda]

Hi, Todd.

Thanks for the information -- it's good to know that the ocean model
isn't relying on EXPAND_LEVELS.

All: I'd like to propose a set of changes to the MPAS repository that
would do what I've described in my earlier e-mail, namely, allow us to
specify any dimension, including decomposed dimensions, in the namelist.
The proposed changes would also remove any EXPAND_LEVELS logic from the
code, and would also fix a bit of unsound logic in how we generated
indices for super-arrays (these changes are around line 372 in
src/registry/gen_inc.c, and require the addition of a routine
sort_group_vars() in parse.c).

I've placed a tar file of the code as I'd like to commit it in
http://www.mmm.ucar.edu/people/duda/files/mpas/mpas_nl_dims.tar.gz; it
should be possible to do 'svn status' to see the changed files. Without
explicitly making changes to the Registry file to make a dimension be
namelist-specified, the modifications should have no effect beyond
removing EXPAND_LEVELS. Please let me know if you have any comments or
suggestions, or if you uncover any problems with the proposed
modifications.

Cheers,
Michael


On Wed, Sep 29, 2010 at 10:53:31PM -0600, Todd Ringler wrote:
> 
> Hi Michael,
> 
> On the ocean side we would prefer to eliminate the EXPAND_LEVELS. We  
> do not use it on the ocean side and it sometimes causes confusion.
> 
> Also, we (on the ocean side) would benefit from a more streamlined  
> init process. Let us know if we can help specify or test your ideas  
> related to producing init files.
> 
> Cheers,
> Todd
> 
> On Sep 29, 2010, at 11:36 AM, Michael Duda wrote:
> 
> >Hi, All.
> >
> >I'm finishing up some changes to the WPS infrastructure that will make
> >it possible to specify any field dimension in the namelist (recall  
> >that
> >we are currently able to specify any non-decomposed dimension in the
> >namelist, i.e., any dimension other than nCells, nEdges, nVertices,  
> >and
> >nVertLevels); the primary application of this new functionality  
> >would be
> >in separate initialization executable, where we read in a grid file,
> >create a set of vertical levels at run-time, and write out an IC file
> >for the model.
> >
> >In the process of making these changes, I thought we might now be able
> >to remove the EXPAND_LEVELS hack from the code; we currently use
> >EXPAND_LEVELS in the hydrostatic and non-hydrostatic cores, but we can
> >switch to defining the vertical dimension in a new namelist  
> >variable. My
> >question, then, was whether the ocean core relied on the use of
> >EXPAND_LEVELS in any critical way, or whether anyone was still
> >interested in using EXPAND_LEVELS with the shallow water core to test
> >with duplicated levels?
> >
> >After a bit more testing, I think I'll be ready to propose the changes
> >this afternoon for review. Depending on any interest in keeping
> >EXPAND_LEVELS, I can either remove that code in my proposal, or keep  
> >it
> >intact.
> >
> >Cheers,
> >Michael
> >_______________________________________________
> >mpas-developers mailing list
> >mpas-developers at mailman.ucar.edu
> >http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>