[Mitgcm-support] Re: call of gchem_forcing

[mitgcm-support at dev.mitgcm.org]

Steph,

you are right about the ptracers_forcing. That is difficult to used 
because it is both in an itracer and a k-loop. If you want to include 
sinking velocities for some of your fields (e.g., detritus) things get 
really messy.

I guess the only real advantage to call gchem_forcing before 
the_correction_step and do_fields_blocking_exchanges, is the fact that 
then you wouldn't have to call the expensive biogeochemistry for the 
halo/overlap-regions, because they would get updated in 
do_fields_blocking_exchanges. And yes, the disadvantage is that you'd 
have to update gPtr = gPtr + deltaT*(whatevergchemreturns), which 
appears a little counterintuitive. The results are the same in my case.

Touch`e

Martin

Stephanie Dutkiewicz wrote:
> 
>>What is the reason for calling gchem_forcing after the_correction_step 
>>and do_fields_blocking_exchanges? By doing this, the passive tracers are 
>>first cycled/updated and then the halos are updated and then the sources 
>>are computed in gchem_forcing and the stracers are time-stepped again!
> 
> 
> That was my plan. I double timestepping setup. First take care of
> all the advection/diffusion etc, and then the chemical changes.
> It is still possible to include the bio-geo tendancies in the
> initial timestepping. #undef ALLOW_SEPERATE_FORCING in 
> GCHEM_OPTIONS.h, this then uses the subroutine PTRACERS_FORCING
> which you will have to change to deal with your biogeochem.
> 
> Since my tracers were dependent on each other, I thought it
> cleaner to step them all forward in time due to adv/diff
> (and therefore all the exchanges etc). I wanted to work with
> ptracer*, not gptr*. I think the options are really only
> to do something in ptracers_intergrate (in place of ptracers_forcing,
> which is within a itracer loop), or wait until after everything
> is done and then do a seperate stepping forward for just the
> biogeo tendency. I think it might just be messier to do
> things before the exchange and correction_step part. (And I
> was worried messing with the code gptr=ptracer etc).
> But either way should work. Just that if you do anything
> after ptracer_integrate, you will have to do a "second"
> forward step.
> 
> steph
> 
> 


-- 
Martin Losch
Alfred Wegener Institute for Polar and Marine Research
Postfach 120161, 27515 Bremerhaven, Germany;
Tel./Fax: ++49(0471)4831-1872/1797