[MITgcm-support] advection of passive AND active tracers

Jean-Michel Campin jmc at ocean.mit.edu
Mon Sep 22 14:39:34 EDT 2003


On Mon, 22 Sep 2003, Martin Losch wrote:

Hi,

I look to the history of this "tempAdvection=.false." problem,
and looks like I did it wrong when I tried to put it back (was
disactivated for a while).
I propose to simplify the things and use Martin's solution
(set to zero in thermodynamics and not in gad_calc_rhs).
Any objection ?

Jean-Michel

> Chris,
> 
> I don't think that there's an interaction with AUTODIFF. True, If you 
> enable AUTODIFF, then everything should work, because gT, gS, etc are 
> initialized to zero in thermodynamics. If AUTODIFF is disabled, then 
> there is no initialization and everything relies on the lines 475-476 
> in gad_advection (last lines in last do-loop block):
>           gTracer=(localTij-tracer)/deltaTtracer (this works when 
> advection is on)
> or lines 134-140 in gad_calc_rhs:
>        IF (calcAdvection) THEN
>         DO j=1-Oly,sNy+Oly
>          DO i=1-Olx,sNx+Olx
>           gTracer(i,j,k,bi,bj)=0. _d 0
>          ENDDO
>         ENDDO
>        ENDIF
> which does the job in case of .NOT.multiDimAdvection
> I run into the problem after a few time steps (order 5), so you should 
> see it, too. But unfortunately I have add so many new things to my copy 
> that it is hard for me to claim, that I have not introduced the mess 
> myself, although I am quite sure that my changes do not have anything 
> to do with the advection.
> 
> While we are at it, I have observed strange behavior of the DST3 
> scheme: It mixed my stratified water column throroughly and I don't 
> know why. I have talked to JMC about it, and I'll probably set up an 
> example to demonstrate this.
> 
> Martin
> 
> On Monday, September 22, 2003, at 03:28 PM, Chris Hill wrote:
> 
> > 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
> >>
> >
> >
> > _______________________________________________
> > 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