[MITgcm-devel] Re: [MITgcm-cvs] MITgcm/pkg/gchem CVS Commit

[Martin Losch]

Hi Steph,

I have a suggestion, that is more general:
remove all i/jmin/max from the argument list of DIC_BIOTIC_FORCING and 
set them *in* DIC_BIOTIC_FORCING. This way other models can compute the 
overlaps or leave as they like. (in fact, as far as I can see DIC is 
not using the i/jmin/max's consistently anyway, e.g. 
alk/dic_surfforcing.F are not using them although they are passed and 
o2_surfforcing.F is using them). Is that a solution? I don't know.
I would really like to have the old ranges of i/jmin/max, but then 
again, I could do that in a similar manner within my model.

Martin
On Dec 13, 2005, at 4:36 PM, Stephanie Dutkiewicz wrote:

>
> Martin -
> You are correct that these aren't needed, and I can change
> it back in gchem.
> (The reason I did this was it was the cause of Hezi's problems
> on the alpha -- they are some parts of the pkg/dic that calculated
> on the overlaps, and it was blowing up when some other parts
> didn't: it was easier to make everything on the overlaps than
> not...so I took the short cut).
> steph
>
>
> On Tue, 13 Dec 2005, Martin Losch wrote:
>
>> Hi Steph,
>>
>> On Dec 12, 2005, at 8:08 PM, Stephanie Dutkiewicz wrote:
>>
>>> Update of /u/gcmpack/MITgcm/pkg/gchem
>>> In directory forge:/tmp/cvs-serv24517/pkg/gchem
>>> Modified Files:
>>> 	gchem_forcing_sep.F
>>> Log Message:
>>> o set imin,imax,jmin,jmax to include overlap points
>> why is it necessary to include the overlap regions? I think we had 
>> this discussion long ago, and I could convince you that they weren't 
>> necessary.
>> As far as I can see there are no horizontal averages or gradients 
>> involved in any of the bgc-models that I know of (I don't know too 
>> many, I have to admit), and right after gchem_forcing_sep, we call 
>> do_blocking_exchanges, so the calculating the bgc-fluxes/tendencies 
>> on the overlaps is just a waste of computer time (not a big waste, 
>> but unecessary, and these bgc-models can become expensive, at least 
>> mine is). I would prefer a solution, in which the overlaps, should 
>> they really be needed, are hardwired in the corresponding subroutines 
>> (as you did, e.g. in dic/carbon_chem.F and dic/fe_chem.F, although I 
>> don't see why: I couldn't find any instances of i-1,i+1,j-1,j+1 or 
>> the like in the directory dic), or included in model-specfic ifdef's.
>>
>> What have I overlooked?
>>
>> Martin
>>
>>
>> _______________________________________________
>> 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