KPP_OBLdepth becomes too small ~ 1 cm

[nikizadehgfdl]

commit 4a0c1b2a7d16a085e76f2877f4ebb0632b8d840c Author: Robert Hallberg Robert.Hallberg@noaa.gov Date: Wed Mar 18 18:18:49 2015 -0400

Investigating a testcase crash I found that the diagnostic called KPP_OBLdepth becomes too low (1.2cm) at some points on the map. Alistair says this should never happen.

More about the test: I ran an experiment to test the capability for DT_THERM = 2* dt_cpld and the model crashed on the 3rd day with SST suddenly hiking up to 30C at an isolated point in high latitudes (-5E,82N) (Greenland Sea) . Looking for the reasons I noticed KPP_OBLdepth becomes suspiciously low (1.2cm) at the same point. Thinking (mistakenly) that this would be the depth of the grid box that would accept the heat fluxes and heat up, I set KPP%MINIMUM_OBL_DEPTH = 10.0 and the test ran for at least a month.

The history file is too large to transfer to gfdl (since it's every timestep) but here it is on gaea:

/lustre/f1/unswept/Niki.Zadeh/archive/safe/KPP_OBL_DEPTH_going_1cm/19000101.ocean_month.nc

[adcroft]

Good spot, @nikizadehgfdl . Not sure how this leads to extreme temperatures but the code does have a max with the top level thickness (2m in your case) so the data and code are clearly at odds.

[StephenGriffies]

There is a problem with the time stepping.

Take a look at any field, such as temp, salt, kpp_obldepth, etc. The fields are identically zero until time step 10, at which time they are reasonable. Thereafter, the fields are nonzero only for time steps 16, 22, 28, 34, 40, 46, etc.

This does not appear to be a problem with KPP. Rather, there is zero ocean except for the time steps noted above. That is, there appears to be a problem transferring information between MOM and the coupler...

[StephenGriffies]

Alistair informed me the problem I noted above is likely related to diagnostic manager issues, not with time stepping in MOM/coupler. It would be nice to confirm this.

Why do we have such a problem with diag manager. This file has 210 time steps. There are nonzero values in only about 1/6 of the times saved in this file. That is a huge overload on file size to do debugging.

[StephenGriffies]

The following file saves the thickness array, h, for each time step

/lustre/f1/Niki.Zadeh/work/ulm_mom6_20150331/OM4_SIS_DT_THERM_7200_1x0m2d_512pe7.o7036899/output.stager/lustre/f1/Niki.Zadeh/ulm_mom6_20150331/OM4_SIS_DT_THERM_7200/ncrc2.intel-prod/1x0m2d_512pe7/history/19000101.nc/19000101.ocean_month.nc

Starting around timestep 190, the thickness field, h, at k=1 to west of Svalbard exhibits values close to zero and up to 5m. The very small values found in turn lead to very small values for the KPP boundary layer depth. Surprisingly, these unphysical values for h are NOT accompanied by strange values of SSH.

Here is my understanding of z* vertical coordinate:

dz = (1+eta/H) dz*

where dz* is the static grid cell thickness set by the initial conditions, eta=SSH, and H=bottom topography. Strange values in dz=h should thus be accompanied by strange values in eta=SSH. Furthermore, I observe dz=h at early times in the simulation is "spotty", exhibiting patterns that are not seen in the SSH or H fields, at least not naively.

I am not in Kansas anymore...

One possibility is that problems with sea ice are impressed onto ocean thickness, but for some reason are not seen in SSH diagnosed in MOM6. This could be the case if "SSH" in MOM6 incorporates the inverse barometer loading from sea ice. However, a quick check in the code does not suggest that SSH incorporates the inverse barometer.

[StephenGriffies]

LMD1994 proposed to use the M-O depth as a maximum BL depth under stable buoyancy forcing. Namely, the OBL should be no deeper than the M-O depth. It is a sensible constraint in principle, although in practice it leads to problems which motivated NCAR to abandon the constraint.

Regardless, our needs are not met, as we wish a constraint setting the minimum OBL depth.

[Hallberg-NOAA]

If this is still a problem, it should be raised via NCAR.