[mpas-developers] namelist-defined dimensions

[Michael Duda]

Hi, Todd.

The primary application of this capability is essentially what
you've described: in an initialization 'core', we expect to generate
vertical grid information at run-time, including the number of vertical
levels. Consequently, we need some way to dimension a field according
to run-time values rather than values coming from the input netCDF
file (i.e., the grid.nc file). I think we should also be able to use
this capability to replace the -DEXPAND_LEVELS switch with only minor
modifications to the code in module_io_input.F, too, though I admit 
I've not looked into this possiblity in detail.

I'll wait until later this afternoon to commit the changes just in 
case there are others who might have any suggestions, though.

Cheers,
Michael


On Wed, May 26, 2010 at 09:42:27PM -0600, Todd Ringler wrote:
> 
> Hi Michael,
> 
> I am guessing that you have thought this through much more than I  
> have. I am having a hard time figuring out how this run time  
> specification will help us. Is it that we can then build the "init  
> core" to produce an initial condition netCDF file easier? i.e.  
> config_nx would be useful to build the init file, but would not be  
> needed when running the dynamical core?
> 
> If this is the case, then I say go ahead with it. At some point (maybe  
> sooner rather than later) we might want to discuss the idea of  
> removing the -DEXPAND_LEVELS; this is useful for the built-in test  
> cases but causes problems in the sw, ocean (and maybe hyd_atmos) when  
> taking the initial conditions from the grid.nc files.
> 
> I will be away with limited email access until June 7th. I will try to  
> catch up on this when I get back.
> 
> Cheers,
> Todd
> 
> 
> On May 24, 2010, at 2:43 PM, Michael Duda wrote:
> 
> >Hi, Developers.
> >
> >Toward our goal of moving the initialization step out of the model
> >and into a separate program (still possibly a 'core' within the
> >MPAS framework), we'll need to be able to allocate fields
> >according dimension sizes specified at run-time.  For example, if
> >we have an initialization program that reads only horizontal grid
> >information, but fills in 3d atmospheric or oceanic fields, we
> >might like the number of vertical levels to be specifiable in the
> >namelist. Currently, however, dimensions must be defined in the
> >netCDF input file (with the special exception of nVertLevels,
> >which can be expanded to a size specifiable at compile time using
> >the -DEXPAND_LEVELS flag in the Makefile).
> >
> >I've modified a copy of MPAS that allows one to dimension fields
> >according to namlist parameters; as is currently the case, though,
> >the outer-most (least quickly varying) dimension must be one of
> >nCells, nEdges, nVertices, nVertLevels, or nVertLevelsP1. With the
> >modified code, one can specify in the Registry file, for example:
> >
> >  namelist integer   dimensions     config_nx        10
> >
> >  dim nx namelist:config_nx
> >
> >  var real    foo ( nx nCells ) ro foo - -
> >
> >where the dimension nx will take on whatever value is specified by
> >the namelist parameter config_nx, which has a default value of 10.
> >This is accomplished with the addition of the prefix 'namelist:'
> >to the registry syntax for dimension specifications.
> >
> >The changes to enable this functionality are contained within the
> >files registry_types.h, gen_inc.c, and parse.c in the src/registry
> >directory. I've placed a checked out copy of the MPAS code with
> >these changes in
> >http://www.mmm.ucar.edu/people/duda/files/mpas/new_code/mpas_nldim.tar.gz
> >for review. If anyone has any comments or suggestions for
> >improvement, please let me know. If the changes look good and are
> >working for others, I'll add them back into the repository trunk.
> >
> >Cheers,
> >Michael
> >_______________________________________________
> >mpas-developers mailing list
> >mpas-developers at mailman.ucar.edu
> >http://mailman.ucar.edu/mailman/listinfo/mpas-developers
>