[mpas-developers] question about EXPAND_LEVELS

[Todd Ringler]

Hi Michael,

I was able to download and "svn diff" the individual files.

It looks like a nice improvement. I would like to get a better idea of  
how we can use the ability to set dimensions in the namelist on the  
ocean side.

I would go ahead and commit and we can follow up on the phone or I can  
follow your lead on changes made on the atmos side.

Cheers,
Todd

On Sep 30, 2010, at 11:44 AM, Michael Duda wrote:

> 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
>>
> _______________________________________________
> mpas-developers mailing list
> mpas-developers at mailman.ucar.edu
> http://mailman.ucar.edu/mailman/listinfo/mpas-developers