[MITgcm-support] advection of passive AND active tracers

Chris Hill cnh at mit.edu
Mon Sep 22 09:28:59 EDT 2003


Hi Martin,

 Thanks for getting up so early to track this down!

 Is it just that the gTracer terms don't get reset or is there an
interaction with the AUTODIFF parts or something? I do turn off the
tracer advection every now and then when debugging setups. I have never
run into the problem, but usually I am doing short (100 time steps or
so) tests so maybe I don't run into this bug.

 Any thoughts? ( I will read the code too and see what is going on ).

Thanks

Chris

> -----Original Message-----
> From: mitgcm-support-bounces at mitgcm.org 
> [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of Martin Losch
> Sent: Monday, September 22, 2003 9:02 AM
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] advection of passive AND active tracers
> 
> 
> Hi once more,
> 
> because I am alwayes 6 hours ahead of you (o:, (and because this 
> problem was really burning under my fingernails), I impatiently found 
> the problem with turning off the tracer advection:
> with temp/saltAdvection=.false. the routine gad_advection 
> where gTracer 
> is reset, or equivalently in gad_calc_rhs gTracer is not 
> reset, so that 
> gTracer accumulates tracer+deltat*gTracer, which of course make the 
> model blow up.
> 
> Remedy:
> In thermodynamics one could move
>             gT(i,j,k,bi,bj)   = 0. _d 0
>             gS(i,j,k,bi,bj)   = 0. _d 0
> out of the #ifdef ALLOW_AUTODIFF_TAMC block
> The same for gPtr, but here one has to include PTRACERS.h as 
> well (also 
> in a ALLOW_AUTODIFF_TAMC block).
> 
> I won't check this in, because appearently nobody ever turn off the 
> advection, but maybe that something to keep in mind the next time 
> thermodynamics is updated.
> 
> Martin
> 
> On Monday, September 22, 2003, at 11:06 AM, Martin Losch wrote:
> 
> > Hi again,
> > I have made an interesting discovery while trying to turn off
> > advection for the passive tracers package:
> > When I include a runtime flag, analogous to tempAdvection or 
> > saltAdvection, for passive tracers, the tracer model 
> explodes after a 
> > few time steps. With advection turned on (the default) 
> everything is 
> > okay. I couldn't find the place where the passive tracer gets 
> > corrupted (it doesn't happen in ptracers_integrate, 
> > ptracers_advection, nor in ptracers_forcing. cycle_tracer and 
> > timestep_tracer are not the source of error either.)
> > But now this:
> > I turned off tempAdvection and saltAdvection (linear 
> equation of state 
> > so that salt is passive as well), and you know what, the model 
> > explodes, too.
> >
> > advection schemes are 2 (cented 2nd order) for theta and salt and 33
> > (DST3FL) for the passive tracer package, but that shouldn't matter, 
> > should it?
> >
> > Any idea, what's going on?
> >
> > Martin
> >
> > Martin Losch // mailto:mlosch at awi-bremerhaven.de 
> > Alfred-Wegener-Institut für Polar- und Meeresforschung Postfach 
> > 120161, 27515 Bremerhaven, Germany
> > Tel./Fax: ++49(471)4831-1872
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org 
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org 
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-> support
> 





More information about the MITgcm-support mailing list