[MITgcm-support] advective and diffusive diagnostics
Jean-Michel Campin
jmc at mit.edu
Thu Jan 26 10:20:01 EST 2017
Hi Dimitris and others,
For any tracer, when using pkg/gmredi, it adds to vertical fluxes
two diffusive components that are proportional to horizontal tracer gradient
(Kwx & Kwy components of the GM-Redi tensor) and these components are always
evaluated explicitly (i.e., forward in time) since an implicit implementation
would be far too complicated and expensive.
These terms (Kwx & Kwy) are due to the Redi tensor but are increased by some GM
contributions when using the Skew-flux form (GM_AdvForm = .FALSE., i.e, the default).
The vertical flux 3rd component from GM-Redi is due to Kwz tensor component
and is easy to process implicitly (vertical flux function of vertical gradient)
like any vertical diffusivity contribution; this is the case when implicitDiffusion=.TRUE.
In term of diagnostics, with useGMRedi=TRUE,
1) the first 2 components (from Kwx & Kwy) are accounted for in diagnostics "DFrE_???";
2) the 3rd component (from Kwz) is either
added to "DFrE_???" when using implicitDiffusion=.False. (i.e., the default)
or
accounted for in diagnostics "DFrI_???" when using implicitDiffusion=.True.
The diagnostics are consistent with tracer time-stepping ( forward / backward
time-stepping = explicit / implicit ).
Cheers,
Jean-Michel
On Thu, Jan 26, 2017 at 02:17:51PM +0100, Stefano Querin wrote:
> Hi Dimitris, hi everybody,
>
> I also use KPP (with implicit vertical diffusion) but NOT GMRedi and I can close the heat and salt budget, without considering explicit vertical diffusion.
> In fact, I usually comment that term in my data.diagnostics:
>
> # frequency(112) = 86400,
> # fields(1,112) = 'DFrE_TH',
> # filename(112) = 'DFrE_TH',
>
> # frequency(120) = 86400,
> # fields(1,120) = 'DFrE_SLT',
> # filename(120) = 'DFrE_SLT',
>
> If I enable the diagnostics for explicit vertical diffusion, I get this warning in my STDERR file:
>
> (PID.TID 0189.0001) - WARNING - from DIAGNOSTICS_OUT at iter= 432
> (PID.TID 0189.0001) - WARNING - diag.# 111 : DFrE_TH (# 1 ) in outp.Stream: DFrE_TH
> (PID.TID 0189.0001) - WARNING - has not been filled (ndiag= 0 )
> (PID.TID 0189.0001) WARNING DIAGNOSTICS_OUT => write ZEROS instead
> (PID.TID 0189.0001) - WARNING - from DIAGNOSTICS_OUT at iter= 432
> (PID.TID 0189.0001) - WARNING - diag.# 128 : DFrE_SLT (# 1 ) in outp.Stream: DFrE_SLT
> (PID.TID 0189.0001) - WARNING - has not been filled (ndiag= 0 )
> (PID.TID 0189.0001) WARNING DIAGNOSTICS_OUT => write ZEROS instead
>
> So, things seem to be consistent in my configuration (I am using the checkpoint64v version of the code): only implicit vertical diffusion, no explicit term, heat and salt budget OK. Most likely the problem is in GMRedi, but I never used that package...
> To whom it might concern, here is also a link to a very nice and clear technical report on heat and salt budget in MITgcm by Abhisek Chakraborty and Jean-Michel Campin:
>
> http://wwwcvs.mitgcm.org/viewvc/MITgcm/MITgcm/doc/Heat_Salt_Budget_MITgcm.pdf?revision=1.1&view=co
>
> Hope this helps somehow...
>
> Cheers,
>
> SQ
>
>
> On 25 Jan 2017, at 23:59:35, Dimitris Menemenlis wrote:
>
> > Hi Martin, Zhan Su and I were puzzled by exactly the same question
> > and came across your MITgcm question, but no answer :-(
> >
> > Ou points out that DFrE_TH contains the GM contribution to vertical
> > diffusivity computed ?explicitly? in gmredi_rtransport.F, even when
> > implicitDiffusion=.TRUE.
> >
> > Dimitris Menemenlis
> >
> >> On Mar 2, 2007, at 12:45 AM, Martin Losch <Martin.Losch at awi.de> wrote:
> >>
> >> Hi,
> >> let me add a related question:
> >>
> >> for vertical diffusive flux there are two fields:
> >> 1. DFrI_TH, implicit diffusive flux of theta
> >> 2. DFrE_TH, explicit diffusive flux of theta
> >>
> >> when I use a vertical mixing scheme that require implicit vertical diffusion such as KPP (in conjunction with GMredi), I expect that all diffusive flux is in DFrI_TH. But I still get a small contribution in DFrE_TH (explicit diffusive flux). Why is that so?
> >>
> >> (Actually I have tried this only with passive tracers, so DFrITR01 and DFrETR01, but from looking a the code I don't see, why it should be different for theta).
> >>
> >> Martin
> >>
> >> On 1 Mar 2007, at 20:29, Patrick Heimbach wrote:
> >>
> >>>
> >>> To add to Baylor's description at the thread
> >>> http://forge.csail.mit.edu/pipermail/mitgcm-support/2007-February/004605.html
> >>>
> >>> Quoting:
> >>> 1) UVELTH is just the correlation between U and T.
> >>> 2) UTHMASS is the correlation between U and T, weighted by 'mass', or
> >>> HFac, which gives free-surface corrections.
> >>> 3) ADVx_TH is the 'effect of advection'. It includes flux-limiting
> >>> and diffusion from the numerical scheme.
> >>>
> >>> there is a fourth diagnostic
> >>> 4) DFxE_TH
> >>> which could be termed "diffusive", i.e. it contains all
> >>> non-advective components in the dT/dt sum, such as diffusion due to
> >>> Laplacian or biharmonic diffusion (diffKh, diffK4) and due to GM/Redi.
> >>>
> >>> The fields 3) and 4) (ADVx_TH, DFxE_TH) are mass-weighted as well
> >>> (yes, it's the mass of water in the grid cell),
> >>> so you don't have to worry about cell area, thickness or surface corrections
> >>> when computing sums or budgets.
> >>>
> >>>
> >>> -p.
> >>>
> >>>
> >>>
> >>> On Mar 1, 2007, at 1:54 PM, Valerie Benesh wrote:
> >>>
> >>>> I am currently trying to understand the units of the advective and diffusive fluxes in the available diagnostics. What is the difference between mass-weighted transport of a tracer and the advective flux of the tracer? Does the mass transport include diffusion? I take it mass-weighting involves the mass of water in the grid cell? How exactly are the units (kg/kg)*(m/s) come by for mass-weighted transport? How are the units (kg/kg)*(m^3/s) achieved for fluxes of the tracer? Are these the fluxes themselves at each cell boundary? Any help understanding these units is appreciated. Thanks,
> >>>>
> >>>> Val
> >>>>
> >>>>
> >>>>
> >>>> ***************************************************
> >>>> Val Bennington
> >>>> Graduate Student
> >>>> Atmospheric and Oceanic Sciences
> >>>> University of Wisconsin-Madison
> >>>> benesh at wisc.edu
> >>>> ***************************************************
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> MITgcm-support mailing list
> >>>> MITgcm-support at mitgcm.org
> >>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> >>>
> >>> ---
> >>> Dr Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
> >>> MIT | EAPS, 54-1518 | 77 Massachusetts Ave | Cambridge, MA 02139, USA
> >>> FON: +1-617-253-5259 | FAX: +1-617-253-4464 | SKYPE: patrick.heimbach
> >>>
> >>>
> >>> _______________________________________________
> >>> MITgcm-support mailing list
> >>> MITgcm-support at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> >>
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-support
> >>
> >
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
More information about the MITgcm-support
mailing list