[MITgcm-support] GM-Redi question

Wed Feb 20 07:58:01 EST 2019

Hi Dhruv,

That makes sense. Thanks for the clarification!

Cheers,

Kaitlin

Dr Kaitlin Naughten
British Antarctic Survey

________________________________
From: MITgcm-support <mitgcm-support-bounces at mitgcm.org> on behalf of Dhruv Balwada <db194 at nyu.edu>
Sent: 20 February 2019 12:43:35
To: mitgcm-support at mitgcm.org
Subject: Re: [MITgcm-support] GM-Redi question

Hi Kaitlin,

I believe, and maybe this is what Julian was also alluding to is, that you can have only Redi and no GM if you make a choice of parameters like:
'
GM_background_K    = 0.,
GM_isopycK         = 200.,'

GM_background_K is K_gm and GM_isopyckK is K_redi. In default if you set only one the other is taken to be equal, otherwise you set them individually. This is probably what Martin meant by turning off GM and only keeping Redi, please correct me if I am wrong. They are 2 different parameterization, which cleanly combine in a single tensor.

Best,
Dhruv

On Wed, Feb 20, 2019 at 7:05 AM Naughten, Kaitlin A. <kaight at bas.ac.uk<mailto:kaight at bas.ac.uk>> wrote:

Hi Julian,

Thanks for your reply, and for pointing me towards the streamfunction calculation. It looks like since I have GM_AdvForm=.false. (the default) I'm using the skew-flux form even though GM_BOLUS_ADVEC is defined. This means the streamfunction doesn't actually get calculated. I guess a lot of the variables which are zero in my output only relate to the bolus advective form.

According to the documentation (https://mitgcm.readthedocs.io/en/latest/phys_pkgs/gmredi.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__mitgcm.readthedocs.io_en_latest_phys-5Fpkgs_gmredi.html&d=DwMFAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=3huS5z96YHlUbTqcqC5pEg&m=qMZixtwdhH-XWepZS7WdMJSmyBQjqdFvnY1NLjtajCo&s=3X0aqIiRYHqFu8bdd2ajIGPQlkZvpPiQmndEjZWqEVQ&e=>), the skew-flux form can achieve the "GM" part of GM-Redi just by modifying two elements of the Redi tensor, and doesn't need to calculate streamfunctions or bolus velocities or anything like that. So it appears I do have both parts of the scheme turned on, even though many variables are zero.

I don't see how it's possible to only have the Redi part, given the MITgcm options, but it sounds like Martin has done that? Maybe it was an older version of the code.

All the best,

Kaitlin

Dr Kaitlin Naughten
British Antarctic Survey

________________________________
From: MITgcm-support <mitgcm-support-bounces at mitgcm.org<mailto:mitgcm-support-bounces at mitgcm.org>> on behalf of Julian Mak <julian.mak at physics.ox.ac.uk<mailto:julian.mak at physics.ox.ac.uk>>
Sent: 20 February 2019 11:24:59
To: MITgcm Support
Subject: Re: [MITgcm-support] GM-Redi question

I think it's "GM_isopycK" which is the Redi part? By default if that is not specified I think it takes on the value of GM (although I don't know if this would be "GM_background_K" or whatever the kGM value that the Visbeck scheme spits out in this case).

A data.gmredi I used is given below; ignore the MMB stuff which is our GEOMETRIC implementation where we hijacked the existing Visbeck scheme in a rather disgusting fashion (I haven't tried very hard tidying it up...)

Best wishes,
Julian

%%%%%%%%%%%%%%%%%%%%

&GM_PARM01
  GM_AdvForm         = .FALSE.
  GM_background_K    = 0.,
  GM_isopycK         = 200.,
  GM_taper_scheme    = 'gkw91',
  GM_maxSlope        = 5.e-3,
  GM_Kmin_horiz      = 0.,
  GM_Scrit           = 4.e-3,
  GM_Sd              = 1.e-3,
  GM_Visbeck_alpha   = 0.016,
  GM_Visbeck_minval_K= 50.,
  GM_Visbeck_maxval_K= 1.e+4,
# MMB params
  MMB_lambda         = 1.e-7,
  MMB_alpha          = 0.04,
  MMB_minval_K       = 50.,
  MMB_maxval_K       = 1.e+4,
#  MMB_minval_K       = 1155,
#  MMB_maxval_K       = 1155,
  energy_init        = 1.e-2,
  energy_kappa       = 0,
  energy_local       = .false.,

%%%%%%%%%%%%%%%%%%%%

On 20/02/2019 10:34, Naughten, Kaitlin A. wrote:

Hello everyone,

I am a bit confused about the GM-Redi scheme, and how to turn on the "GM" part (bolus or skew fluxes) versus just the "Redi" part (tracer diffusion along isentropes). An old message from Martin (http://mailman.mitgcm.org/pipermail/mitgcm-support/2016-March/010355.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.mitgcm.org_pipermail_mitgcm-2Dsupport_2016-2DMarch_010355.html&d=DwMFAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=3huS5z96YHlUbTqcqC5pEg&m=qMZixtwdhH-XWepZS7WdMJSmyBQjqdFvnY1NLjtajCo&s=MRoT3cqh1pVjTcv9E0n5wsOVplrjIe6CK9QGiWF59mE&e=>) said that he only used the Redi part, but I'm not sure what options control this.

I switched on all the GM-Redi diagnostics in my configuration and discovered that many variables are zero everywhere (GM_PsiX, GM_PsiY, GM_ubT, GM_vbT, GM_hTrsl, GM_baseS, GM_rLamb, plus two components of the Redi tensor which I think are supposed to be zero: GM_Kuz and GM_Kvz). Does this mean that I only have the Redi part switched on? And if so, why is the GM part not on?

Here are the active lines of my data.gmredi:

 &GM_PARM01
 GM_background_K=10.,
 GM_taper_scheme='ldd97',
 GM_Kmin_horiz=50.,
 GM_Visbeck_alpha=0.07,
 GM_Visbeck_length=50.E3,
 GM_Visbeck_depth=2000.,
 GM_Visbeck_maxVal_K=300.,

And here are the active lines of my GM_REDI_OPTIONS.h:

#ifndef GMREDI_OPTIONS_H

#define GMREDI_OPTIONS_H
#include "PACKAGES_CONFIG.h"
#include "CPP_OPTIONS.h"
#ifdef ALLOW_GMREDI
#define GM_VISBECK_VARIABLE_K
#undef OLD_VISBECK_CALC
#undef GM_K3D
#undef GM_K3D_PASSIVE
#define GM_NON_UNITY_DIAGONAL
#define GM_EXTRA_DIAGONAL
#define GM_BOLUS_ADVEC
#undef GM_BOLUS_BVP
#endif /* ALLOW_GMREDI */
#endif /* GMREDI_OPTIONS_H */

This is probably a stupid question but hopefully that means it has a quick and easy answer!

Many thanks,
Kaitlin

Dr Kaitlin Naughten
British Antarctic Survey

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UK Research and Innovation does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.
Opinions, conclusions or other information in this message and attachments that are not related directly to UK Research and Innovation business are solely those of the author and do not represent the views of UK Research and Innovation.

_______________________________________________
MITgcm-support mailing list
MITgcm-support at mitgcm.org<mailto:MITgcm-support at mitgcm.org>
http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support<https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.mitgcm.org_mailman_listinfo_mitgcm-2Dsupport&d=DwMFAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=3huS5z96YHlUbTqcqC5pEg&m=qMZixtwdhH-XWepZS7WdMJSmyBQjqdFvnY1NLjtajCo&s=rJAyt1xstYmTTDfN02t-tWC90c-srw-K0EGi6DtIb34&e=>

--
Julian Mak,
Department of Physics,
University of Oxford,
Clarendon Laboratory, Parks Road
Oxford, OX1 3PU
e-mail: julian.mak at physics.ox.ac.uk<mailto:julian.mak at physics.ox.ac.uk>
www: https://sites.google.com/site/julianclmak/home<https://urldefense.proofpoint.com/v2/url?u=https-3A__sites.google.com_site_julianclmak_home&d=DwMFAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=3huS5z96YHlUbTqcqC5pEg&m=qMZixtwdhH-XWepZS7WdMJSmyBQjqdFvnY1NLjtajCo&s=E1OXDc28ZD97AQY00ipa6TKTD-N-vyxoskTTdNi4yAE&e=>

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UK Research and Innovation does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.
Opinions, conclusions or other information in this message and attachments that are not related directly to UK Research and Innovation business are solely those of the author and do not represent the views of UK Research and Innovation.

_______________________________________________
MITgcm-support mailing list
MITgcm-support at mitgcm.org<mailto:MITgcm-support at mitgcm.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.mitgcm.org_mailman_listinfo_mitgcm-2Dsupport&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=3huS5z96YHlUbTqcqC5pEg&m=qMZixtwdhH-XWepZS7WdMJSmyBQjqdFvnY1NLjtajCo&s=rJAyt1xstYmTTDfN02t-tWC90c-srw-K0EGi6DtIb34&e=

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UK Research and Innovation does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.
Opinions, conclusions or other information in this message and attachments that are not related directly to UK Research and Innovation business are solely those of the author and do not represent the views of UK Research and Innovation.

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