[MITgcm-devel] gchem

[Martin Losch]

Hi Steph,
On Oct 27, 2004, at 3:21 PM, Stephanie Dutkiewicz wrote:

> On Tue, 26 Oct 2004, Martin Losch wrote:
>
>> Hi,
>>
>> here comes my share of (hopefully not stupid) suggestions for this 
>> week.
>>
>> I have several questions and suggestions about the GCHEM package:
>> 1. There is one experiment dic_example, but testreport probably does
>> not check the values of the passive tracers. Is there a way to check,
>> whether I broke this experiment by my modifications other than
>> acutually comparing the output fields?
>
> I believe there was talk of using the monitor output
> %MON
> to check that such experiments were still working.
> Has anyone done that yet?
The monitor output is used for the "standard" variables, but the 
trcstat_ptracer?? etc are not used for that so far. I'm not familiar 
enough with genmake2 to include that check, whenever 
trcstat_ptracer??_* are present (I did this once with the old genmake 
and it was a pain for me to figure it out)
>
>>
>> 2. the place of the call gchem_forcing_sep in forward_step doesn't 
>> make
>> sense to me. Why isn't it called before do_fields_blocking_exchanges? 
>> I
>> would like to change that, and then iMin,iMax,jMin,jMax could be set 
>> to
>> 1,sNx,1,sNy (instead of 1-Olx,sNx+Olx, etc) in gchem_forcing_sep and 
>> we
>> wouldn't have to compute the expensive bio-forcing on the halos at all
>> (I think, this causes problem with my open boundary set-up), the 
>> fields
>> are exchanged anyway. This change doesn't require any work and I am
>> willing to do that, but I don't know if it will break dic_example
>> (probably not).
>> [The more complicated solution is to call gchem_forcing_sep much
>> earlier, eg. after call seaice, but I am not even suggesting that,
>> because it will require changing the way the time step is handled in
>> all bgc_forcing.F files.]
>
> I have no problems if you want to make this change. Just make sure
> that all diagnostics etc are still working correctly.
> I had not done so because I thought it cleaner to pass the ptracers
> rather than remembering to use the gPtr ...
OK, so I will soon move the call of gchem_forcing_sep before 
do_fields_blocking exchanges and adjust iMin, etc in gchem_forcing_sep. 
The other thing is a lot more involved...
>
>>
>> 3. gchem_fields_load calls subroutines
>> (dic_fields_load/cfc_fields_load, and whatever I added in my local
>> copy), but in these subroutines, files are read whose names are 
>> defined
>> in GCHEM.h (WindFile, AtmospFile, etc.). Wouldn't it make more sense 
>> to
>> read those files in gchem_fields_load directly? Parts of
>> cfc_fields_load and dic_fields_load are identical (and for every
>> bgc-model I have, I have to duplicate these files again. Also I makes
>> it hard to interface gchem_fields_load with the exf-package (I am
>> probably the only one who wants to do that).
>
> The problem with doing is this way, is that not all package use all
> the files. For instance feinput files are only used in the
> DIC package - and so InputFe
> (which is bWght*feinput0(i,j,bi,bj)
>      &                          +aWght*feinput1(i,j,bi,bj) )
>
> is defined in DIC_LOAD.h -- a file which the gchem pkg doesn't
> see.

This was probably the stupid part of the my suggestion. But still, the 
way it is done now is inconsistent: part of the input parameters 
(filenames) are defined in GCHEM.h, other parameters (the fields 
themselves) are not. I would suggest to either
- declare all input file related stuff  in one header (GCHEM.h) and 
read files in gchem_fields_load independent of individual bgc-models at 
at the cost of having declared superfluous fields (maybe use CPP-flags 
to get rid off them)
or
- declare all input related stuff for each package seperately, so that 
e.g. DIC would have it's own data.dic etc. That's complicated, too.
It's a question of what gchem is supposed to represent: just a wrapper, 
then the file name declarations should not be in GCHEM, or should it 
provide the environment for different bgc-models. In the latter case 
gchem should provide all surface fields, even insolation (which 
shouldn't be different for different models).
But I'll give in to the fact that doing it this way implies a lot of 
extra work that probably no-one is willing to do?

Martin