[MITgcm-devel] gchem / dic logic

[Stephanie Dutkiewicz]

Martin, Oliver -

Option 2 seems to make more sense to me. Keeping
gchem together - and exf cleaner.
You could have a special gchem_exf namelist set
within the #ifdef ALLOW_EXF.

Oliver - you've been running exf with the gchem/darwin
code - does this option seem the best to you too?

steph


On Mon, 7 Apr 2008, Martin Losch wrote:

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