[mpas-developers] Restructuring high-level MPAS driver

[Michael Duda]

Hi, Developers.

I've been working to restructure the higher levels of the MPAS software
(driver and subdriver) to enable us to separate the test case
initialization from the model proper, among other things, and I've
settled on what I think is a set of changes that will take us in the
proper direction.

Currently, in the current top-level code (mpas.F and module_subdriver.F), 
the setup_test_cases() routine is called directly, which precludes the
separation of this from the model. I view the initialization code that 
is currently in module_test_cases.F as something of its own "core" that
uses the MPAS software infrastructure in the same way that the sw,
nhyd_atmos, and ocean cores use this infrastructure. Consequently, I'd
like to generalize both mpas.F and module_subdriver.F by removing any
core-specific code, where the definition of "core" now includes
initialization, post-processing, etc. Under this generalization, the
content of mpas.F would be a main program that simply calls init(),
run(), and finalize() routines in the subdriver module, and the
subdriver module's init() implementation would be responsible for
initializing the framework (infrastructure) and then the core; to 
further abstract the details of the infrastructure and core, I'm also
proposing that we provide main modules for each of these, which would
implement their own init, run, and finalize routines. Calls to 
setup_test_cases() could still exist within either the init() or run() 
routines implemented by the core's main module, if at all; however,
with a separated initialization, the initialization would exist as 
its own core, whose run() routine would perform the work currently 
done in setup_test_cases().

I've placed a tar file to illustrate what these changes look like
in http://www.mmm.ucar.edu/people/duda/files/mpas/mpas_newdriver.tar.gz.
This code is an svn working copy, so it should be possible to 'svn 
status' and 'svn diff' to see what files have changed. During the
restructuring, I found that the mpas_query() routine is no longer
needed, since number of time levels can be determined for fields purely
in the registry, so I also removed code related to this, too.

One side effect in the currently reorganization is that both the output
and restart files are always opened at the start of MPAS execution,
regardless of whether a core intends to write a restart file at all.
This raises the question of whether control over output (and perhpas
even input) streams should be given to the individual MPAS cores. Would
assuming that a core always writes at least an output stream, but may
not write a restart stream be reasonable for now? If so, we could
probably relocate code to open/write/close the restart file down to the
core-specific code, for example.

On the upside, the restructuring that I've proposed has very little
impact on the actual solver code in the MPAS cores; and, I've found 
that the high-level code is lightweight enough that it should be easy 
to make further changes as we move forward with future development.

I apologize for the lengthy e-mail, but if anyone has any comments,
particularly concerning other requirements besides separating 
initialization from model integration, I'd be very glad to hear them. 
Assuming no objections that cannot be remedied, I'd like to commit 
the proposed changes to the repository trunk fairly soon.

Cheers,
Michael