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

Martin Losch Martin.Losch at awi.de
Tue Aug 4 09:09:27 EDT 2009 

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

More information about the MITgcm-devel mailing list