New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#1180 (Bottom grid points with unrealistically cold temperature in ORCA2_LIM) – NEMO

Opened 10 years ago

Last modified 3 years ago

#1180 reopened Bug

Bottom grid points with unrealistically cold temperature in ORCA2_LIM

Reported by: fabien.roquet Owned by: gm
Priority: low Milestone: Unscheduled
Component: OCE Version:
Severity: minor Keywords:
Cc:

Description

I just realized that ORCA2 features a few bottom grid points with unrealistically cold properties (<-2degC). I checked outputs from nemo trunk (v3_5) revision 3856 (in http://dodsp.idris.fr/rfry154/reference_trunk_v35_Output/) to verify that the problem is not due to my own setup, and I indeed found bottom grid point colder than -2degC in several year-mean output files:

  • ORL2PISV35_00000101_00001231_1Y_grid_T.nc : no problem
  • ORL2PISV35_01000101_01001231_1Y_grid_T.nc : no problem
  • ORL2PISV35_02000101_02001231_1Y_grid_T.nc : -2.03845
  • ORL2PISV35_03000101_03001231_1Y_grid_T.nc : -2.57319
  • ORL2PISV35_04000101_04001231_1Y_grid_T.nc : -2.7857
  • ORL2PISV35_05000101_05001231_1Y_grid_T.nc : -2.88635

From my limited analysis, it seems that this situation always happens only in partial cell grid points, and can happen at around any depth. There is a clear tendency of cold drift through time, + spatial spreading of the phenomenon.
I have checked quickly on ORCA1, and didn't find any such anomalous cold grid points, but that doesn't mean that the problem does not exist for other configurations than ORCA2.
I did a run without bbl (namelist nn_bbl_ldf and nn_bbl_adv set to 0), and the problem still persists so it seems bbl is not the source of this problem.
Does anyone know what is going on?

Commit History (1)

ChangesetAuthorTimeChangeLog
12196smasson2019-12-11T18:13:20+01:00

trunk: limit bottom slope to 1/2*e3/e1 in ldf_slp, see #1180

Change History (10)

comment:1 Changed 10 years ago by dupontf

Bonjour Fabien,

I am running a much older version (3.1-drakkar), but I found something very similar in a subset of ORCA1 over the Arctic. I traced it (in my case) back to horizontal isoneutral diffusion and iso-neutral slope calculation at to the bottom. If this is also experienced by other users, shall we consider switching off the isoneutral diffusion for the bottom cells?

Not being able to spend more time on this (and decide), I applied a very awful fix which is to partition some of the lateral diffusivity into the isoneutral and the levelled one (the background diffusivity ahtb0), something in the order of 4:1 was sufficient for removing those spurious minimums.

Fred.

comment:2 Changed 10 years ago by beppe

I'm investigating the same issue and I can confirm that it happens also in the dev_v3_4_STABLE_2012 .
Moreover I used to run an older version (based on NEMO 3.3) and the ORCA2 configuration reaches even more unrealistic temperatures on the bottom, as low as -17 degC after 3-4 months. Again no apparent problems with the ORCA1 configuration.

I'm wondering if it can be related to the following note in the NEMO documentation (chap. 5.9 Horizontal Derivative in zps-coordinate (zpshde.F90)):

Note that in almost all the advection schemes presented in this Chapter,
both averaging and differencing operators appear. Yet (5.30) has not been
used in these schemes : in contrast to diffusion and pressure gradient
computations, no correction for partial steps is applied for advection.
The main motivation is to preserve the domain averaged mean variance of the
advected field when using the 2nd order centred scheme. Sensitivity of the
advection schemes to the way horizontal averages are performed in the vicinity
of partial cells should be further investigated in the near future.

comment:3 Changed 10 years ago by sallen@…

We are getting unrealistic near-bottom salinities and temperatures probably due to the same problem. We are running dev_v3_4_STABLE_2012 with vvl, partial z cells, tvd advection. (Running for the Salish Sea in Western Canada)

The advection scheme is not taking into account the partial cells, as shown in Fig 5.5, but the Laplacian diffusion is. If we turn off the partial cell correction in Laplacian diffusion we improve things by about a factor of 10, but do not eliminate the problem.

For other places in the model, we cannot run without the partial cell correction in the diffusion. Our plan is just to keep an eye on those salinities as we go through a year of spin-up.

comment:4 Changed 10 years ago by clevy

  • Owner changed from NEMO team to gm

comment:5 Changed 9 years ago by clevy

  • Resolution set to fixed
  • Status changed from new to closed

comment:6 Changed 6 years ago by dupontf

  • Resolution fixed deleted
  • Severity set to minor
  • Status changed from closed to reopened

Bonjour,

I am re-opening the ticket since we found the problem occurring again in NEMO3.6 in ORCA025 configuration, specifically in the bottom Arctic Ocean. I went to the bottom of it this time, and my earlier hunch stands.

Basically, any time the slope of the tracer is flatter than that of density, the normal diffusive flux can be reversed and enhances local differences (our very problem) instead of diffusing them (depending on some signs). This can occur not only at bottom but throughout the water column as one of the 2 tracer slope is likely to be flatter that of density (since density can be approximated locally as a linear combination of temperature and salinity). This is particularly true in the Arctic which is a beta ocean (density is driven by salinity and temperature does anything). If there is some rationale to explain this "backward" diffusion, then the correction should only apply to the bottom cells.

I am suggesting two excluding fixes:

1) limit the horizontal diffuse flux directly so it is never backward => modifications to traldf_iso.F90:

since the diffusive flux can be expressed as ahm * ( dT/dx - uslope * dT/dz ), the problem arises because dT/dx - uslope * dT/dz < 0 (I am assuming here that all terms are > 0) which translates into the condition:

(dT/dx) / (dT/dz) < uslope <==> slope(T) < slope(rho). The solution is to reduce the term uslope * dT/dz so that it does not exceed dT/dx (same in y-direction).

This does the job very well. It is just a question to figure if the fix is to be applied to the whole column or just the bottom.

2) limit the density slope in ldfslp.F90 assuming some safety factor that translates density slope to tracer slope. In this case, the constrain is to make sure that the slope is flatter that allowed by local resolution, assuming that diT~dkT: uslope < safety_factor * e3u/e1u, or terms of gradients:

drho/dz < - | drho/dx | e1u / e3u / safety_factor < 0.

I translated that in fortran as:

zbu = MIN(  zbu, -100._wp* ABS( zau ) , - invalpslp * e1u(ji,jj) / fse3u(ji,jj,jk) * ABS( zau )  )
zbv = MIN(  zbv, -100._wp* ABS( zav ) , - invalpslp * e2v(ji,jj) / fse3v(ji,jj,jk) * ABS( zav )  )

Hence, the limitation will be even more stringent for thinner grid cells in the vertical, which is the case with partial steps at the bottom. [yes, the overshoot problem is more acute with thinner partial cells]

This works in my case with safety factor of 0.1 or 0.5, even when the limitation is only applied to the bottom cells. It would be more numerically rigorous to make sure that the slope is lower than any of the tracers, but that would involve a lot more computations and the spirit of the density slope would be lost...

[Note: I am not sure I get the rationale for the limiter "-7.e+3_wp/fse3u(ji,jj,jk)* ABS( zau )". it seems to be based on some fixed ratio of ah to horizontal resolution, but dt varies also with the resolution, not clear that it is universal... Anyway it does not kick in in my case, so not stringent enough]

I leave you decide what is the best approaches...

Fred.

Last edited 6 years ago by nemo (previous) (diff)

comment:7 Changed 4 years ago by smasson

In 12196:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:8 Changed 4 years ago by smasson

following email exchange with fred, we implemented solution 2 but only at the bottom and ln_zps. We fixed the maximum slope to 1 / 2 * e3 / e1.

Further possible improvments:
-> apply this change even if ln_zps = F ?
-> define a better value than -7.e+3_wp in the default case (the whole water column)? i.e something corresponding to a slope 5 * e3 / e1 as in ldf_slp_triad.

==> need tests to check the effets of these potential changes before implementation

comment:9 Changed 4 years ago by smasson

  • Milestone set to 2020 WP

comment:10 Changed 3 years ago by nemo

  • Milestone changed from 2020 WP to Unscheduled
  • Version v3.6 deleted
Note: See TracTickets for help on using tickets.