[MITgcm-devel] Bug in KPP

Tue Jun 23 06:13:50 EDT 2009

David, sorry for delay in getting back to you on KPP problem.

Are there any salinity variations in your channel set-up or is  
salinity held constant?

What is the thickness of the surface level in your channel experiment?

To play devil's advocate, how do you know that the bottom panel in  
your figure is overall more realistic than the top panel?

Assuming that salinity is held constant, I notice that even your  
bottom panel has some static instabilities northward of the 120-km  
latitude.

Before changing KPP formulation, there are other adjustable parameters  
in KPP parameterization that could help get rid of static  
instabilities in top panel.  Two that immediately come to mind are:

1) adjustment of the critical bulk Richardson number Ri_c and

2) adjustment of the thickness of the surface level.

Regarding second parameter above, what I am specifically concerned  
about is that bulk Richardson number is computed based on shear  
relative to level-1 velocity and that as you increase the thickness of  
level 1, the surface level velocity deviation from geostrophy would  
tend to decrease.

Dimitris

On May 28, 2009, at 7:41 PM, David Ferreira wrote:

> Chris Hill wrote:
>> David,
>>
>> Is this equivalent to having a complete convective mixing step in
>> addition to KPP?
> No, I don't think so. This really has to do with the determination of
> the bl depth.
> There can still be statically unstable points inside the water column
> and below levels
> where the bulk Richardson number was higher than the critical value.
> But KPP has a kind of enhanced vertical mixing for convectively  
> unstable
> situations.
> The default coeff is 0.1 m2/s, I tried to pump it up to 10., more like
> ivdc_kappa, but it
> didn't help much with my problem.
>
> BTW, in this Danabasoglu et al. paper, they suggest that this enhanced
> mixing be done
> at the end of KPP (now it's at the very beginning), so it doesn't  
> enter
> the matching
> conditions of diffusivites at the interior/bl interface. In practice,
> sounds like what you
> are talking about: do KPP and then add a layer of ivdc_kappa on top  
> (in
> the interior
> only).
>
> cheers,
> david
>
>> Chris
>>
>> David Ferreira wrote:
>>> 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
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel