[MITgcm-support] [EXTERNAL] Spurious mixing with internal tides

[Jody Klymak]

I agree with Dimitris, and usually use 7 or 77, but note that then you will have spurious energy dissipation, as in \nu nabla^2 u < dE/dt, where as the second order scheme does a better job of preserving energy (you can always tune that away by increasing the lateral viscosity, but…)

After trying to get this all to work consistently, I think the best approach I generally take is to do an external budget (either energy or tracer) and assume the the residual relative to the dissipation terms in numerical dissipation.  I believe that it is generally true that the advection schemes tend to develop numerical instability where you would expect physical instability anyway, so if you track it with an external budget you should be reflecting the model’s reality.  

This is all assuming you are not trying to do a DNS.  If you are doing a DNS, you should increase the viscosity and diffusivities to the point where this stop being a problem.  But from your description it doesn’t sound like you are trying to do a DNS.

Cheers,   Jody

> On 2 Feb 2021, at 10:49, Dimitris Menemenlis <menemenlis at jpl.nasa.gov> wrote:
> 
> Dear Xiaozhou, did anybody respond to your question?
> 
> It is possible to reduce (but not completely eliminate) spurious mixing by choosing a different advection scheme.
> I am partial to:
> 
> C ENUM_OS7MP :: 7th Order One Step method with Monotonicity Preserving Limiter
>       INTEGER ENUM_OS7MP
>       PARAMETER(ENUM_OS7MP=7)
> 
> which you set in the “data” runtime parameter file using: 
>  tempAdvScheme=7,
>  saltAdvScheme=7,
> 
> Prather advection:
> 
> C ENUM_SOM_PRATHER :: 2nd Order-Moment Advection Scheme, Prather, 1986
>       INTEGER ENUM_SOM_PRATHER
>       PARAMETER(ENUM_SOM_PRATHER=80)
> 
> C ENUM_SOM_LIMITER :: 2nd Order-Moment Advection Scheme, Prather Limiter
>       INTEGER ENUM_SOM_LIMITER
>       PARAMETER(ENUM_SOM_LIMITER=81)
> 
> is supposed to be even less diffusive but more expensive to compute.
> 
> There is a nice discussion on advection schemes in the MITgcm user manual:
> http://mitgcm.org/sealion/online_documents/node71.html <http://mitgcm.org/sealion/online_documents/node71.html>
> http://mitgcm.org/sealion/online_documents/node76.html <http://mitgcm.org/sealion/online_documents/node76.html>
> http://mitgcm.org/sealion/online_documents/node81.html <http://mitgcm.org/sealion/online_documents/node81.html>
> 
> Cheers, Dimitris
> 
> 
>> On Jan 29, 2021, at 9:58 AM, Ruan Xiaozhou <saberruan at hotmail.com <mailto:saberruan at hotmail.com>> wrote:
>> 
>> Dear MITgcm users,
>> 
>> Hope this message finds you well. I’ve been running simple 2D simulations with internal tides driven by oscillatory mean flows over rough bathymetry. When diagnosing the volume-integrated tracer variance budget, although the l.h.s. (time-tendency) and r.h.s (advection + diffusion) terms balance exactly, I found some extra destruction of variance coming from the volume integral of the advection term using nonlinear advection schemes (scheme 33) which is as large as the diffusion term. Theoretically this volume integral of variance advection should vanish... Switching to a centered 2nd order scheme (scheme 2) kills this contribution but the total variance destruction rate becomes about twice as large which, according to the output, can be explained by the noisy tracer field and thus a larger gradient term.
>> 
>> I was wondering if anyone had experience beating down this *spurious* contribution from the advection term? I noticed this contribution not only in the variance budget but also other 2nd order budgets involving a volume integral.
>> 
>> Cheers,
>> Xiaozhou
>> --
>> Xiaozhou Ruan
>> Postdoctoral researcher
>> Department of Earth, Atmospheric and Planetary Sciences
>> Massachusetts Institute of Technology
>> 54-1622
>> Cambridge, MA  02139
>> 
>> email: xruan at mit.edu <mailto:xiaozhour at caltech.edu>
>> web:   http://www.mit.edu/~xruan <https://urldefense.us/v3/__http://www.its.caltech.edu/*xruan__;fg!!PvBDto6Hs4WbVuu7!YRuAOFjbX-Ud-ObyNQx3QCA_mHxkdrR9q1gbhLpGtf0UsoeYre8nvFKMppLmQdKyrxkxhE2anEU$>
>> 
>> 
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org <mailto:MITgcm-support at mitgcm.org>
>> https://urldefense.us/v3/__http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support__;!!PvBDto6Hs4WbVuu7!YRuAOFjbX-Ud-ObyNQx3QCA_mHxkdrR9q1gbhLpGtf0UsoeYre8nvFKMppLmQdKyrxkxXSPnbl0$ 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support

--
Jody Klymak    
http://ocean-physics.seos.uvic.ca/~jklymak/






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20210202/b9a125c8/attachment-0001.html>