[mpas-developers] Changes to field storage types in MPAS

[Michael Duda]

Hello, Developers.

Several of us (Todd, Bill, Phil, and I) have been considering ways to better
organize fields defined in the registry; from the perspective of the
non-hydrostatic atmosphere core, the motivation has been a need to reduce
the amount of storage that is allocated by registry-generated code, plus a
desire to more logically organize fields in the model (i.e., to distinguish
better between prognostic, diagnostic, tendency, physics, and other fields).

I've created a branch in branches/registry_reorg that implements (with the
exception of 'scratch' arrays) the design proposed in the attached document.
After implementing the design in the framework code and converting the sw,
ocean, and hyd_atmos cores to make use of the new data structures, it
appears that the impact of the changes can be quite small (though ideally
will be larger in a positive way if the full capability to logically group
fields into derived types is utilized by a core). About the only
complication that I encountered was the lack of any mechanism to specify
multiple instantiations of the same derived type in the MPAS block type. To
explain a bit further, the new registry syntax allows a developer to specify
the derived type that each field belongs to, with a single instantiation of
each type automatically defined in the block type by the registry. In some
cases, though, it could be helpful to have two instances of a 'state' type,
which would be interchangeable in argument lists; the provisional state is
the example that I encountered, though I worked around this in the sw and
ocean cores by defining a variable local to the solver of type 'state', and
which is allocated and deallocated in each call to timestep(). 

If anyone would like to have a look at the changes, to see the impact on the
dynamical cores, and to try out the updated code, I'd be glad to receive any
comments, suggestions, or general observations. Once we're all comfortable
with the changes, I'd like to merge this branch back into the trunk.

Thanks very much in advance!
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: registry_reorganization.doc
Type: application/octet-stream
Size: 57856 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/mpas-developers/attachments/20100917/18157c5c/attachment-0001.obj