[MITgcm-devel] Re: [MITgcm-support] L4rdt

Mon Aug 3 11:36:19 EDT 2009

Martin,
The kpp bug fix is unlikely to cause a blow-up. It only matters if the 
background diffusivity
in not uniform vertically, and even then (for example using Brian-Lewis) 
it's only a
shift of the profile by one level.
cheers,
david

Martin Losch wrote:
> Hi Jean-Michel,
>
> again my mistake: small changes between 61q and 61p (not 61o and 61p, 
> typo), but these changes are tiny (1e-9) compared to my ke-increase 
> (5e-4). Most likely my fix for free slip boundary conditions affected 
> no slip as well (not tested in any verification experiment, as I just 
> noticed); but I had this fix in my local version of the code long 
> before I checked it in so this is most likely not the cause of my 
> troubles (plus the small changes between 61p and q are very small). 
> Otherwise there is nothing in 61q that can make things change so much. 
> It must be something completely different. Probably an interaction 
> between a small change in the code and something that I have done 
> locally. It's going to be difficult to track down ...
>
> Martin
>
>
> On Aug 3, 2009, at 4:05 PM, Jean-Michel Campin wrote:
>
>> Hi Martin,
>>
>> The changes I made in cg2d (between checkpoint61s & checkpoint61t)
>> could (with some compiler and with optimisation) change the results
>> at the truncation level. But unlikely make your set-up blowing up.
>>
>> Between checkpoint61o and checkpoint61p, could you add back the
>> KPP bugs ?
>>
>> Cheers,
>> Jean-Michel
>>
>> On Mon, Aug 03, 2009 at 02:37:50PM +0200, Martin Losch wrote:
>>> Hi there,
>>>
>>> I need help (not that this is anything new): I cannot reproduce my
>>> experiments after a recent update and I cannot figure out why. The new
>>> runs are substatially more energetic (factor 2), especially way below
>>> the surface and near the topography; eventually they blow up after
>>> 15months of integration with a CFL violation near the bottom/tile-egde-
>>> corner/open boundaries. As an illustration I have attached the monitor
>>> variable ke_mean for kemean_run06.png (the old run) and
>>> kemean_run06_new.png (with new code). I use adv-scheme 33 (no explicit
>>> diffusion), viscA4grid, no_slip_bottom and sides, kpp, seaice, obcs.
>>>
>>> I still have my old exectuables, but I need some new functionality
>>> (pseudo-timestepping for LSOR), so I need the new code. Plus I have 
>>> made
>>> a few changes (new types of OBCS) so that makes tracking down the
>>> problem (or simply reverting to old code) even more difficult.
>>>
>>> My first candiate was this 4times lower L4rdt, but this does not help
>>> much; it reduces the monitored kemean a little: see attached files
>>> kemean_run06.png (the old run) and kemean_run06a.png (the new run but
>>> with old L4rdt).
>>> I noticed (very) small differences in my results between checkpoint61o
>>> and checkpoint61p (with mom_calc_visc.F still held at 61o) which I
>>> cannot explain (but they seem to be small, maybe this KPP fix in 61p?),
>>> but all later checkpoints give the same results as 61p. My old runs are
>>> close to checkpoint61m.
>>>
>>> Now my question: In the list of changes in doc/tag-index I cannot find
>>> anything that I would expect to make my integrations more energetic,
>>> except for this L4rdt business in mom_calc_visc.F (and I have kept this
>>> routine at checkpoint61o). Does anyone have an idea what might have
>>> changed that causes so drastic differences.
>>>
>>> Martin
>>>
>>>
>>
>>
>>
>>
>>>
>>> On Aug 3, 2009, at 9:41 AM, Martin Losch wrote:
>>>
>>>> Sorry for the confusion,
>>>>
>>>> 1. I was talking about L4rdt (I was just omitting the 1/deltatmom
>>>> part, because it's always the same), which applies only when you use
>>>> viscA4grid and/or viscA4max, as far as I can see.
>>>> 2. Reverting to old code does not fix my problem, so it's something
>>>> else.
>>>> 3. I do not think that anybody other than us reads the doc/tag-index
>>>> (also the  comment in there just says "fix L4rdt", but not with what
>>>> effect)
>>>>
>>>> I'll keep searching ...
>>>>
>>>> Martin
>>>>
>>>> On Aug 3, 2009, at 2:04 AM, David Ferreira wrote:
>>>>
>>>>> Dimitris Menemenlis wrote:
>>>>>> David, does necessity to pump up viscA4grid also carry over to
>>>>>> viscA4GridMax?
>>>>>>
>>>>>> Specifically, for the CS510 configuration we use
>>>>>> viscC4Leith=1.5,
>>>>>> viscC4Leithd=1.5,
>>>>>> viscA4GridMax=0.5,
>>>>>>
>>>>>> Recently I have noticed a little more grid scale noise than before
>>>>>> but it is hard
>>>>>> to separate this from other modifications to code and model
>>>>>> configuration
>>>>>>
>>>>>> Do I need to increase  viscA4GridMax by about 30%, as per Martin's
>>>>>> email,
>>>>>> to recover previous set up?
>>>>> Dimitri,
>>>>> looks like the changes in L4rdt also apply to viscA4GridMax.
>>>>> But I'm not sure about those 30% of Martin: he was talking about L4,
>>>>> not L4rdt.
>>>>> In fact, I'm not even sure that L4 is used in mom_cal_visc.F.
>>>>> david
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks, Dimitris
>>>>>>
>>>>>> On Jul 31, 2009, at 1:02 PM, David Ferreira wrote:
>>>>>>
>>>>>>> Martin,
>>>>>>> I put a note in the tag-index about the L4rdt fix !
>>>>>>> Surely, everybody reads it regularly...
>>>>>>> Anyway, the viscosity at the corner points were 4 times those at
>>>>>>> the
>>>>>>> center points, so
>>>>>>> the "effective" viscosity was larger than intended. And indeed,
>>>>>>> with the
>>>>>>> new code, it will
>>>>>>> probably be necessary to pump up a bit viscA4grid.
>>>>>>> That said, I don't think that L4 was changed by the code
>>>>>>> modification,
>>>>>>> only L4rdt.
>>>>>>> Are you sure there is not something else going on ?
>>>>>>> Cheers,
>>>>>>> david
>>>>>>
>>>>>> _______________________________________________
>>>>>> MITgcm-support mailing list
>>>>>> MITgcm-support at mitgcm.org
>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>>>
>>>>> _______________________________________________
>>>>> MITgcm-support mailing list
>>>>> MITgcm-support at mitgcm.org
>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>>
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> 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