[MITgcm-devel] gchem / dic logic

[Martin Losch]

Hi all,

clearly, the combination of a highly variable and often changing pkg  
such as gchem + sub-pkgs with a (I admit:) at first incomprehensible  
pkg such as pkg/cal+pkg/exf opens a tin of worms.

To my mind there are two standpoints on this (and I am sure that Jean- 
Michel will come up with at least one more that I haven't thought of):
1. As far as I can see the gchem-pkg is intended as an interface to  
bgc- and ecosystem-pkgs (whatever the difference is) and nothing  
more. Unfortunately, the way it's programmed is not entirely clean so  
that it supplies some names etc. but as far as I can see David's  
ongoing(?) efforts are going to resolve that.
The idea is that you only need to put in a few hook to couple your  
personal ecosystem model to the MITgcm. From this point of view each  
sub-pkgs (e.g. dic, cfc) needs to have it's own data.$pkg,  
$pkg_readparms.F, $pkg_load_fields.F, etc and that's not the case  
(neither cfc not dic have their own name list files, but use separate  
forcing field loading S/R, which are in principle very similar).
In that case pkg/gchem should only contain "empty" subroutines  
gchem_forcing, gchem_readparms, gchem_write_pickup, etc. , from  
which, say, dic_forcing, dic_readparms, dic_write_pickup, etc is  
called. The only use interface would be a namelist in data.gchem,  
that contains only useDIC, useCFC, useMYPERSONALMODEL. Currently all  
sorts of forcing periods and files are read from data.gchem which is  
very inconsistent with this viewpoint of a pure interface.

2. You can view gchem-pkg as an interface that provides a certain  
infrastructure for ecosystem models. That infrastructure would  
provide places where you put your hooks (see above), but also provide  
forcing and input fields. That way, you'd only need one  
gchem_fields_load.F which provides forcing fields for everyone. That  
requires gchem_fields_load to be quite complicated and also requires  
some memory overhead, as it needs to serve each "possible" package.  
In this case data.gchem can and should contain all sorts of  
parameters that control the forcing and in put fields.

Personally, I'd prefer viewpoint 1, if it's done right (which is not  
quite the case at the moment, but I am waiting for David to finish  
before I complain (o:).
Then the exf/cal-capabilities (parameter and reading) would have to  
be included in each sub-pkg (as I have done it now for myself) at the  
cost of having to change many different files, if anything serious  
changes in exf/cal (which has happened in the near past: the  
parameter list of exf_set_gen changed and broke all my runs, because  
I did not remember to fix my reading routines.). Also this means that  
there is a lot of potential for duplication (many ecosystem models  
need atmospheric pCO2, wind, etc), but that's what you have to pay  
for the increased flexibility.

Martin