[MITgcm-devel] gchem / dic logic

Mon Apr 7 17:46:29 EDT 2008

Hi all,

some of your discussion echoed issues I had when I recently
started playing with these packages (e.g. to simulate CFCs).

I needed a hack to make pkg/cfc work for me, as the pieces of code
(in cfc_fields_load.F) that compute month record numbers failed
(giving 13&2 as a result) for my choice of time step and periodicity.
I simply used exf_GetFFieldRec.F instead.
I have the same issue with pkg/rbcs by the way and use the same fix.

I would vote for relying on exf+cal in the sub-pkg
(rbcs, cfc, dic, ...).

Note that pkg/cal may be sufficient to handle dates/record
numbers (e.g. my issue), but it may make most sense to go one
step further and use pkg/exf (spatial interpolation capability etc.).

Gael

David Ferreira wrote:
> Hi  all,
> 
> What about the following rules:
> - keep it specific: a forcing field which is specific to
> the sub-package stays in its sub-package (file names
> arrays and reading), typically silicate in dic or atmopsheric CFC in cfc
> - a handfull of multi-used fields could remain in gchem (file names and 
> reading, the arrays being passed when necessary to the sub-packages), 
> typically wind speed, sea-ice fraction, and Atmosp pressure.
> 
> I guess that both readings (at the gchem level or at the
> sub-package level) could call exf if preferred.
> david
> 
> 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
>>
> 
> 