[MITgcm-devel] gchem / dic logic

[Oliver Jahn]

I tend to agree with Steph here.  I am not that familiar with the inner 
workings of exf, but if it is possible to keep it in gchem, it would also
make it easier to add more fields later.

Oliver

On Mon, 7 Apr 2008, Stephanie Dutkiewicz wrote:

>
> 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
>