[MITgcm-devel] gchem / dic logic

[David Ferreira]

Looks like we might be converging.
Everybody agrees on solution 1).
So let's go for it.
david


Martin Losch wrote:
> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 


-- 
Ferreira David                           Tel : 617 253 7967
EAPS Room 54-1515,                       Fax : 617 253 4464
Massachusetts Institute of Technology,
77 Massachusetts Avenue
Cambridge, MA, 02139