[MITgcm-support] advection of passive AND active tracers

[Martin Losch]

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