[mpas-developers] registry structures and operator modules

[Michael Duda]

Hi, All.

While re-organizing fields in the non-hydrostatic atmosphere registry,
we've run into something of a compatibility issue with modules in the
shared operators. Essentially, by having shared operator modules accept
higher-level structures (e.g., mesh, state) as subroutine arguments, we
preclude the re-location of fields in these structures to other
structures in the registry files of individual cores.

In the specific case that we've run into,
uReconstruct{X,Y,Z,Zonal,Meridional} were re-located in the registry
file to a new structure named 'diag', which has just one time-level. In
order to fill in the uReconstruct* fields in the reconstruct() routine,
then, it was necessary in our atmos_nonhydrostatic branch to pass not
only the 'state' and 'grid' structures as arguments to reconstruct() in
module_vector_reconstrution.F, but to also pass the new 'diag'
structure. Consequently, I've moved the uReconstruct* fields into a new
'diag' structure in each of the hydrostatic, ocean, and shallow water
registry files in our branch as well.

I had just begun trying to think of ways to resolve this issue, but I
wanted to get thoughts and feedback from other developers as well, since
any solution will almost certainly affect shared code. One possibility
might be to simply pass fields individually to shared operator code; in
the case of vector reconstruction, this may not be too bad (making
certain assumptions, which I can elaborate on if anyone is interested),
but for something like a global diagnostics module, the argument lists
may become unreasonably long. Another solution might be to pass a
module-specific structure to subroutines in operator modules, with the
responsiblity of packing individual fields into these structures falling
on the calling routines; of course, the work of packing and unpacking
fields might be even more onerous than passing long argument lists. 
A third solution might be to just have all cores organize fields into the
same structures -- or, at least, any fields passed to operator modules
-- but in general, especially as more operator modules are added, this
may be too restrictive. Borrowing ideas from object-oriented design, one
can imagine solutions that involve defining more generic, 'superclass'
structures that could be passed to operator code, with generic routines
to retrieve pointers to specific fields from these structures.

I'll be giving the issue more thought, but, as always, any comments or
ideas would be much appreciated!

Cheers,
Michael