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

Mon Aug 3 11:02:27 EDT 2009

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