[MITgcm-devel] gchem / dic logic
David Ferreira
dfer at mit.edu
Mon Apr 7 16:16:51 EDT 2008
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
>
--
Ferreira David Tel : 617 253 7967
EAPS Room 54-1515, Fax : 617 253 4464
Massachusetts Institute of Technology,
77 Massachusetts Avenue
Cambridge, MA, 02139
More information about the MITgcm-devel
mailing list