[MITgcm-devel] Bug in KPP

[David Ferreira]

Dimitris,
While we are talking about KPP, I found a very nasty behavior in it and
you may be interested.
In attachment, I put a figure of the zonal and time averaged temperature 
and hbl
in a channel run (it is eddy-esolving with a constant sinusoidal zonal 
wind and a restoring
to a linear SST profile). The top panel is the default behavior of KPP. 
The hbl is very
different from south to north with a sharp transition in the middle, it 
reflects the
heating/cooling pattern at the surface. But, more worrying are the 
static instabilities
in the middle of the channel near 150 m depth (it's a 2000 days average 
!). Again, it is
because of the heating at the surface. In such case, KPP says it is 
stable and the hbl is
limited by the minimum of the Ekman and Momin-Obukhov depth. So even if 
Ekman
currents are overturning the isotherms and the critical bulk Richardson 
is not reached
before 200 or 300 m depth, the bl is very shallow with static 
instabilities below. BTW,
even, boosting the convective coefficients in the interior doesn't not 
remove the
instabilities.

The bottom panel is without limit on the hbl under stable conditions. It 
looks much nicer.
Danabasoglu et al. (2005) mentioned they don't apply those limits in 
CCSM. They didn't
say why but I can imagine. You might think that the channel is a weird 
set up, but basically
this problem is going to arise each time Ekman currents are in the same 
direction as the
SST gradient under stable conditions.

Anyway, I'm going to put a run-time flag to be able to choose to apply 
those limits or not.
david


Dimitris Menemenlis wrote:
> David, thank you for taking another look at vertical KPP profiles and forfinding and fixing the riwmix bug.
>
> The ghat term is supposed to be active in convectively unstable mixed layers but, if I remember correctly, turned off for purely wind-driven mixing.
>
> Dimitris Menemenlis
> 818-625-6498
> -----Original Message-----
> From: David Ferreira <dfer at mit.edu>
> Date: Wednesday, May 27, 2009 7:06 am
> Subject: Re: [MITgcm-devel] Bug in KPP
> To: "MITgcm-devel at mitgcm.org" <MITgcm-devel at mitgcm.org>Reply-To: "MITgcm-devel at mitgcm.org" <MITgcm-devel at mitgcm.org>
>
> Hi Dimitris,
> I looked into the code and did some tests with a 1d set-up. The shape of 
> the visc/diff
> are consistent with the kpphbl, the shear/convective instabilities also 
> look fine to me
> in terms of vertical location. I still have a small doubt about the 
> position of ghat, but I
> need to reread the Large et al. to be sure.
> Anyway, I'm going to check in the fix for the vertical indices in ri_iwmix.
> cheers,
> david
>
> Dimitris Menemenlis wrote:
>   
>> David, I agree that change below will work and that, assuming KPP code 
>> was bug-free before kpp_routines.F version 1.21, this is the correct 
>> fix.  If it's not too much trouble, as a further sanity check for 
>> vertical mismatch prior to 1.21, could you also check to see that 
>> convective or shear instabilities trigger increase in K at the right 
>> level and that mixed layer depth increase in K is consistent with hbl 
>> depth.
>>
>> For mixed layer depth, I would run your configuration forward for a 
>> few time steps, set KPPwriteState=.true. in data.kpp, dumpfreq=deltat 
>> in data, and I would compare the vertical profiles of KPPdiffkz and 
>> KPPviscAz to KPPhbl.
>>
>> For shear or convective instabilities in the interior, as you are 
>> unlikely to have any of those in your model configuration after 
>> spin-up, I would generate instabilities artificially by adding a bit 
>> of salt or cooling a few random points, and then checking that 
>> KPPdiffkz and KPPviscAz kick in at the correct level to remove these 
>> instabilities.
>>
>> The above tests are probably (hopefully) superfluous but if they are 
>> not too much trouble to run, it would not hurt to have a fresh pair of 
>> eyes looking at this issue one more time.
>>
>> Did Hong get back to you regarding your horizontal viscosity question?
>>
>> Cheers, Dimitris
>>
>> On May 26, 2009, at 7:08 AM, David Ferreira wrote:
>>
>>     
>>> I think the problem is in ri_iwmix. vddiff is defined at the 
>>> interface (with
>>> k=0 corresponding to the air-sea interface), so the lines in ri_iwmix
>>> should be changed from:
>>> diffus(i,ki,3) = diffusKzT(i,ki)+fcon*diftcon+fRi*dift0
>>> to
>>> diffus(i,ki,3) = diffusKzT(i,ki+1)+fcon*diftcon+fRi*dift0
>>>       
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>     
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mi
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fig_KPP_b.png
Type: image/png
Size: 69864 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20090528/57e8fffc/attachment.png>