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

Mon Aug 3 12:37:28 EDT 2009

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