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

Tue Aug 4 16:11:26 EDT 2009

Martin,
If it is any consolation, I understand that viscA4grid should be 
strictly inferior
to one for stability but of order one. Your value of viscA4grid looks 
more reasonable
now.
david

Martin Losch wrote:
> I have given up. I could not identify the difference. It looks like it 
> does not have anything to do with mom_calc_visc.F (the differences 
> remain with the old executable less energetic than the new one, even 
> when I turn off viscosity altogether for a few time steps).
>
> However, I restarted the experiment with new code and an almost 6 fold 
> increased viscA4grid (from 0.04211 to 0.25), and the run appears to be 
> stable. So somehow I must have had something hardwired in the old 
> executable (something I *never* do, but it must have been that), that 
> already mimics the new behavior. I'm still puzzled ...
>
> Martin
>
>
>
>
> On Aug 3, 2009, at 6:37 PM, Martin Losch wrote:
>
>> David,
>>
>> you are right, the KPP fix actually makes no diffierence in my 
>> situation. It's really a complicate riddle. I wish I could recover 
>> the fortran code from the exectuable. I have now gone back as much as 
>> 61i (with mom_calc_visc.F of checkpoint61o) and there is no 
>> fundamental difference in the ke_mean variable (too high compared to 
>> the results of my old executable). It does not make sense to go 
>> further back, because I am already beyond the point of all the big 
>> seaice changes, and I am positive that the old executable does 
>> contain these changes already (although it is formally checkpoint61i, 
>> I don't know how that happened, I probably did not update my makefile 
>> in due time) ... the search goes on ...
>>
>> Martin
>>
>> On Aug 3, 2009, at 5:36 PM, David Ferreira wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> 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