New Coarse Global Tutorial Setup

[jrscott]

Among the development team and collaborators, there is general agreement the coarse global setup used in verification and tutorial experiments would benefit from an overhaul. To start, specifically we want to begin with a redo of the 2.8 lat-lon setup (80S-80N), hopefully some aspects might carry over to a new LLC90 setup verification (or tutorial). The new 2.8 setup would be used not only for the main global experiments, but also for updates of the biogeo/tracer and adjoint runs. And, ideally we would include several different verification setup variations using different parms/parameterizations (e.g. a variation which uses Visbeck to calculate Kgm is one suggestion)

Specific objectives:

1. improve the bathy using a high-res topo product, include marginal seas
2. use new forcing fields generated from widely used data/bulk formula approach
3. improve parameter/parameterization/model scheme choices employed in the run
4. improve the model solution

Step 1 was fairly straightforward; noteworthy changes include adding the Med Sea, and a related change was a slight increase in the grid vertical resolution (18 vs. 15 levels).

For Step 2, we ran the setup with pkg EXF and ~prescribed SST, using the standard (normal year) CORE forcing data/bulk formulae to generate forcing data files (monthly). (Note, seaice is not included in the tutorial 2.8 setup, but is used (thsice)in the EXF run)

Step 3 and 4 is where difficulties arise. Parms and parameterizations choices reflect both generally favored/physically justified choices and schemes, but also can be used to some extent for tuning purposes. Some I'd consider the most relevant to mention here (ie typically solution exhibits some sensitivity to this choice):

• GM/Redi background Kgm decrease to low background value at depth, advform=T, dm95 tapering
• vertical diffusivity uses a BryanLewis increase with depth
• a 3D viscosity file with a large value at the Med Sea sill location. Sill depth affects deepwater properties, can be used to tune.
• asynchronous time stepping, tracer step 12 hrs (this integrates 2000 yrs in several hours using a small mpi config)
• Tests show the output is very sensitive to the advective scheme choice, especially related to Med Sea outflow, which has a large impact on deep water properties. As tested thus far, Prather (80) is giving by far the best solution, which is not really an ideal choice for the basic setup.

"Tuning" involves two steps:

• how does the output look with almost prescribed SSS and SST (5-day restoring) in the model run?
• how much does the model drift away when 60/90 day SST/SSS restoring is used?

An important question however: what are the main metrics to use in judging the solution? As a first step, I considered:

• global mean T(z) and S(z) vs. obs
• MOC/AMOC pattern and max
• ACC strength

S(z) has a complex shape, a fn of different water mass properties, and in practice is what I'd consider the main metric to tune, very difficult to get right. For unknown reasons, AMOC is mitgcm always seems to come in a bit on the low side, no change here, and I've yet to find a justifiable/reasonable way to noticeably bump it up. ACC typically seems reasonable, albeit I've looked at the tuning sensitivity here less than AMOC and S(z).

At this point, I think my solution with ~prescribed SSS, SST, using Prather and a Med Sea sill of 260m, is remarkably close to obs T(z) and S(z). A second pass at metrics would be more regionally focused, and here however the soln would start to show some warts. But, with 60/90 day restoring, I drift away quite a bit, which suggests some issues with the CORE-generated files. My approach thus far was to consider this second problem separately, but one could of course try to tune up the 60/90 day rest run and skip the prescribed SST/SSS run.

At this point, I wanted to document the objectives and process, and open the general procedure to any comments, thoughts, or suggestions.

I can attach some links/plots of my metrics above, for both the old and new setups. I do seem to have made the tuning much more difficult by including the Med Sea, and its outflow influence seems extremely sensitive to many modeling choices, dominating the model's deep water properties.

[jrscott]

[mjlosch]

@jrscott thanks for starting this discussion. I am currently trying to run an llc90 configuration with gmredi, ggl90, seaice. The forcing is JRA55-do-v1.4.0 (strong winds) with Large and Yeager (2004, 2009) bulk formulae (in pkg/exf). There is no salinity restoring underneath sea ice.
I find many issues that I will report here; the main being:

• Atlantic overturning dies unless I use very strong salinity restoring (60 days/10m)
• the Drake passage transport drops from 150 to 110 within 80 years or so.
• very strong salinity bias. I haven't yet compared to observations, but I compare the first 80 years of the simulation to the first year (which should still be close to the initial conditions/climatoloty)
  Especially in the South I expect this to be one of the main problems of the simulation as the bottom water formation is way too low in this simulation, see next point:
• most disturbing: The Pacific overturning circulation reverses after about 150 years. This may be related to the GMredi parameters, but first tests with larger (constant vs. Visbeck) GM_background_K=850 did not really change anything (just reduced AMOC and Drake Passage transport even further).

Here are some of my parameter files:

 # GM+Redi package parameters:
 &GM_PARM01
  GM_background_K    = 10.,
  GM_taper_scheme    = 'ldd97',
  GM_maxSlope        = 1.e-2,
  GM_Kmin_horiz      = 50.,
  GM_Scrit           = 4.e-3,
  GM_Sd              = 1.e-3,
# parameters taken from Gnanadesikan et al 2006, JCL
  GM_Visbeck_alpha   = 0.07,
  GM_Visbeck_length  = 50.e+3,
  GM_Visbeck_depth   = 2000.,
  GM_Visbeck_maxval_K= 600.,
 &end

# SEAICE parameters
 &SEAICE_PARM01
  SEAICE_no_slip     = .TRUE.,
  SEAICEadvScheme    = 33,
  SEAICE_drag        = 0.001,
  SEAICE_drag_south  = 0.002,
  SEAICE_wetAlbTemp  = 0.0,
  SEAICE_salt0       = 4.0,
  LSR_ERROR = 1.e-5,
# just too expensive to have 10 iterations
  SEAICEnonLinIterMax = 2,
# this value should be default for the McPhee parameterization
  SEAICE_mcPheeTaper=0.92,
  SEAICE_mcPheePiston= 7.291666666666666E-05,
  SEAICE_frazilFrac  = 0.,
  SEAICE_saltFrac    = 0.30,
  SEAICE_area_reg    = 0.15,
  SEAICE_hice_reg    = 0.10,
  IMAX_TICE = 6,
# Depending on vertical resolution this angle should have a value
# > 0 (e.g., 25deg for drF(1)=10m,)
  SEAICE_waterTurnAngle = 25.0,
  HO        = 0.5,
  SEAICE_multDim = 7,
  SEAICE_useMultDimSnow = .TRUE.,
  SEAICEpressReplFac = 0.,
  SEAICE_strength = 27.5e3,
  SEAICE_cStar    = 15.,
 &

# =====================================================================
# | Parameters for Gaspar et al. (1990)'s TKE vertical mixing scheme  |
# =====================================================================
 &GGL90_PARM01
 GGL90diffTKEh=0.e3,
 GGL90m2 = 3.0,
# default in NEMO
 GGL90TKEmin = 1.e-06,
 GGL90TKEbottom=4.e-6,
 calcMeanVertShear = .TRUE.,
 mxlMaxFlag=2,
 GGL90viscMax=1.e2,
 GGL90diffMax=1.e2,
 GGL90_dirichlet=.FALSE.,
 &

[jrscott]

&PARM01
tRef=1520.,
sRef=1535.,
viscAr=1.E-3,
diffKrBL79surf= 3.E-5,
diffKrBL79deep= 13.E-5,
diffKrBL79Ho = -2000.,
diffKrBL79scl = 150.,
gravity=9.81,
rhoConst=1035.,
rhoConstFresh=1000.,
implicitFreeSurface=.TRUE.,
eosType='JMD95Z',
implicitDiffusion=.TRUE.,
implicitViscosity=.TRUE.,
ivdc_kappa=1.,
tempAdvScheme = 80,
saltAdvScheme = 80,
allowFreezing=.FALSE.,
hFacMin=.1,
hFacMinDr=50.,
staggerTimeStep=.TRUE.,
useSingleCpuIO=.TRUE.,
&

&PARM02
cg2dMaxIters=1000,
cg2dTargetResidual=1.E-13,
&

&PARM03
nIter0=0,
nTimeSteps = 1440000,
deltaTmom = 900.,
deltaTtracer= 43200.,
deltaTClock = 43200.,
abEps = 0.1,
pChkptFreq = 3110400000.,
chkptFreq = 3110400000.,
dumpFreq = 31104000000.,
tauThetaClimRelax = 432000.,
tauSaltClimRelax = 432000.,
periodicExternalForcing=.TRUE.,
externForcingPeriod=2592000.,
externForcingCycle=31104000.,
monitorFreq= 31104000.,
momDissip_In_AB=.FALSE.,
&

data.gmredi
&GM_PARM01
GM_background_K = 1.0e+3,
GM_taper_scheme = 'dm95',
GM_maxSlope = 4.e-3,
GM_Kmin_horiz = 5.,
GM_Scrit = 4.e-2,
GM_Sd = 1.e-2,
GM_AdvForm = .TRUE.,
GM_Small_Number = 1.D-20,
GM_slopeSqCutoff = 1.D+08,
GM_iso1dFile = 'K_bol_1d.bin',
GM_bol1dFile = 'K_bol_1d.bin',
GM_Visbeck_alpha = 0.00,
&

[jrscott]

Thanks @mjlosch for the comments and plots.

I too have worked with a llc90 setup, forced by CORE. In my case I used exf again to diagnose fluxes (thsice w/advection), then did experiments with fixed applied fluxes and some temp restoring. However, we took the opposite approach on S restoring under seaice (this wasn't entirely my approach of choice...): under seaice we restored 10x faster than the weaker S restoring in mid and tropical latitudes. I appreciate this is not so wonderful to do this under seaice however, but it did keep the AMOC/MOC on track. Of course the diagnosed full EmP forcing field is a bit outrageous, and one might question climate change experiments when the model is accustomed to such unrealistic EmP forcing, indeed. FWIW in my 2.8 exf diagnostic run (and the forward run) I'm restoring similarly globally (80S to 80N).

What you are attempting is more difficult than my 2.8 setup, ergo your problems are a bit more significant. In my case I have exf always using "perfect" SSTs whereas as you drift away from observed SSTs your exf fluxes likely become even more problematic.
I've even gone one step more restrictive in my tuning procedure, doing the fast restoring (holding SSS, SST correct) run even though my (non-restore) fluxes don't change.

Our S errors seem about the same order of magnitude, albeit your integration time is quite short (I'm going out 2000 yrs). But certainly helpful to compare here, even a bit apples and oranges. Getting the bottom water close to obs is very tough, as I don't think the reanalysis and forcing is well constrained at high latitudes, and it seems this needs to be close and/or we lack good modeling of high-latitude ocean processes.

I forgot to mention that I'm cheating a bit to boost my AMOC to ~17 Sv by multiplying the Large and Yeager 2004 derived taux,tauy by 1.2x (globally). Actually this produces something that isn't that unreasonable if you do a survey of wind stress products, just puts me on the higher side of the spread. Not much else (that was reasonable) significantly boosted my AMOC max (but I was still hoping to cut this boost in half or so for the final setup, being a bit ad hoc here :) ). And fwiw, my DP transport is high, about 170 Sv.

Are you using exf to compute atm_rho? If not, this values varies by a large amount from tropics to poles, and since it is front of the bulk formula eqns, you will have large errors unless it is turned on.

[mjlosch]

Even though it may not help with this new coarse tutorial setup, I would like to report that I finally found the (main) culprit for my weird reversed overturning circulation in the Pacific Ocean: Needless to say, I am the main culprit. I made a mistake when I specified precipitation and snow precipitation (that's what you get from JRA55) separately. pkg/exf expects rain+snow precipitation to be in precip in "m/s of liquid water" and snow precipitation in snowprecip, also in "m/s of equivalent liquid water". JRA55 provides both in kg/m^2/s (which is much better, I think), so I converted precip by dividing by 1000kg/m^3 (exf_inscal_precip = 1.e-03,) and then I thought I should divide the snow precipitation by density of snow (330 kg/m^3), (exf_inscal_snowprecip = 3.030303030303e-03,). Of course, this is wrong and leads to 3 times too much snow. Instead, I should have divided by 1000 and doing this fixes my problem of reversed Pacific overturning (and, not surprisingly, the way too thick sea ice especially in the southern ocean, that prohibited sufficient heat exchange, which lead to too warm bottom water with ensuing problems).

[antnguyen13]

@mjlosch a nature paper on future reversal of Pacific circ due to warming leading to more snow in polar region?

[mjlosch]

I wish I was as creative as you!

[mjlosch]

The simulations are ready to be analysed (o: