[MITgcm-devel] gchem / dic logic

Mon Apr 7 15:41:15 EDT 2008

Hi all,

it might be a good time to start thinking about
whether many of the exf-related parameter
(file name, forcing field, etc for each field)
could become run-time parameter, just as in diagnostics package.
That would make exf much more flexible.

-p.

On Apr 7, 2008, at 3:34 PM, Jean-Michel Campin wrote:
> Hi Martin,
>
> David is in the process of moving things around
> between DIC & GCHEM, so will tell you when it's done.
> One thing on the plan was to move few file names
> (e.g.: SilicaFile, currently in GCHEM.h) into the same header
> file where the field (i.e. the array) is hold, and to read it
> from data.dic.
> So that when you add/remove 1 field, you only have to
> change 1 header file (instead of 2 currently).
>
> Regarding the EXF interface, don't know what is the best solution,
> but it seems to me that we are going to have to change
> quiet often gchem pkg if all the exf-[sub-package]-parameters
> are put there.
> This would be an argument to add those EXF related thing not
> in exf pkg, nor in gchem but in the sub-pkg (dic,cfc ...) ?
>
> Jean-Michel
>
> On Mon, Apr 07, 2008 at 10:05:10AM +0200, 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

---
Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach