[MITgcm-devel] gchem / dic logic

[Martin Losch]

Dear fellow-gchem users/abusers,

Yet another question/suggestion:

I would like to be able to read ecosystem relevant surface forcing  
fields (e.g. iron/dust input, atmospheric pCO2, etc.) via the exf  
packages. I have implemented a hack for that my personal use, but it  
would be much nicer/better and less error prone, if I could do that  
in a more systematic way.

The exf-package allows/requires a lot  of additional parameters: for  
each field there is a startime/endtime/period, and if you want to use  
on the fly interpolation there is even more, lat0, lon0, dlat, dlon  
to specify the data grid, etc. In my current hack I put these  
parameters into data.gchem and have them defined the specific  
packages, but everytime something changes in gchem_readparms I have  
to painfully merge the stuff.

To my mind there are two options:
1. define a list of potential input fields for gchem and put them  
into the exf pkg, data.exf
2. define a list of potential input fields (as already done in GCHEM.h:
>       CHARACTER*(MAX_LEN_FNAM) WindFile
>       CHARACTER*(MAX_LEN_FNAM) AtmospFile
>       CHARACTER*(MAX_LEN_FNAM) IceFile
>       CHARACTER*(MAX_LEN_FNAM) IronFile
>       CHARACTER*(MAX_LEN_FNAM) SilicaFile
and have all the relevant parameters for exf in that package as well  
(within #ifdef ALLOW_EXF) and read from data.gchem (gchem_readparms.F)

What does make more sense to you?

Furthermore, I would even go so far to read these files in  
gchem_fields_load instead of having yet another routine for each eco  
system (I currently have three routines that are basically the same,  
except that they are called recom_fields_load, bimap_fields_load and  
fgm_fields_load). What's your opinion on that?

Martin

On 4 Apr 2008, at 22:28, Jean-Michel Campin wrote:
> Hi Martin,
>
> We did not forget your suggestion:
> Stephanie, David and I had a short discussion today and
> agree with your point.
> Also suggest to have (in the futur) a useDIC & useCFC
> stored in "GCHEM.h" and read from "data.gchem"
> (this will make clear that interface of DIC & CFC are all
>  handle through gchem).
> Will try to clean-up the DIC_OPTIONS.h / GCHEM_OPTIONS.h
> so that we can compile those 2 pkgs with default OPTIONS files.
>
> Cheers,
> Jean-Michel
>
>
> On Wed, Mar 12, 2008 at 01:01:10AM +0100, Martin.Losch at awi.de wrote:
>> David,
>>
>> wouldn't it be better to have a gchem_write_pickup?
>> now you start mixing the package levels (packages_* calls gchem_*  
>> which calls dic_*).
>> I actually did the same thing as you did (call a recom_write/ 
>> read_pickup and call it from packages_*), but it's problably not a  
>> good idea to do that. I would much rather have  
>> gchem_write_pickup.F which will be interface for bgc packages, as  
>> it is done for other parts of gchem.
>>
>> Martin
>>
>>
>> Martin Losch
>> Alfred Wegener Institute
>> Postfach 120161, 27515 Bremerhaven, Germany;
>> Tel./Fax: ++49(0471)4831-1872/1797
>>
>>
>>
>> ----- Original Message -----
>> From: David Ferreira <dfer at mitgcm.org>
>> Date: Tuesday, March 11, 2008 9:57 pm
>> Subject: [MITgcm-cvs] MITgcm/model/src CVS Commit
>>
>>> Update of /u/gcmpack/MITgcm/model/src
>>> In directory forge:/tmp/cvs-serv13299
>>>
>>> Modified Files:
>>> 	packages_write_pickup.F
>>> Log Message:
>>> Pieces of code for pickup file for pH in dic (to fix the restart
>>> problem).Not yet active as not backward compatible.
>>>
>>> _______________________________________________
>>> MITgcm-cvs mailing list
>>> MITgcm-cvs at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
>>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel