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

Martin Losch Martin.Losch at awi.de
Wed Aug 5 04:54:41 EDT 2009 

Hi David,
thanks for the consolation; I do feel much more comfortable with the  
new value of viscA4grid and as I said in the beginning, your  
modifications to mom_visc_calc make absolutely sense. I just cannot  
believe that I have been so sloppy (again) with my experiments.

M.

On Aug 4, 2009, at 10:11 PM, David Ferreira wrote:

> 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
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list