[MITgcm-devel] problem with 59c

[Jinlun Zhang]

Hi Martin,

I am not sure either what is happening here since I never had any 
problem with zmin=0. Given that setting zmin > 0 screws up the ocean, I 
would think that zmin > 0 would only delay the blow-up. When the ocean 
is fully developed, blow up is still likely. So I wonder how long 
Dimitris can run the model without blowup when zmin > 0. If no blowup 
whatsoever, then the ocean circulation is likely to suck.

Jinlun


Martin.Losch at awi.de wrote:

>Hi Jinlun,
>
>we are talking about the LSR solver on the C-grid. As far as I can see, the EVP solver has not been used for the high 
>resolution cubed sphere yet. In one of her paper Elizabeth (J.Comp.Phys.,2001) claims that the EVP solver does not 
>need zmin = 4.e8 as opposed to other methods, and then she cites you, as personal communication, that zmin=0 works 
>too for other solvers, (yours?). So far I have used zmin = 0 for all my evp runs.
>
>Dimitris has actually isolated the problem in the cs510 and it is zmin=0, with zmin=4e8 (the old value, that I removed 
>recently from the code) it works.
>
>So we are puzzled, oh well.
>
>Martin
>
>Martin Losch
>Alfred Wegener Institute 
>Postfach 120161, 27515 Bremerhaven, Germany; 
>Tel./Fax: ++49(0471)4831-1872/1797
>
>
>
>----- Original Message -----
>From: Jinlun Zhang <zhang at apl.washington.edu>
>Date: Tuesday, July 3, 2007 5:46 pm
>Subject: Re: [MITgcm-devel] problem with 59c
>
>  
>
>>I am not sure what sea ice model is used here. If it is EVP, I 
>>don't 
>>really know. But if it is LSR, zmin has to be set to zero all the 
>>time. 
>>And if things blow up, zmin=0 is unlikely the problem. Something else.
>>Jinlun
>>
>>Martin Losch wrote:
>>
>>    
>>
>>>I propose the following: introduce a runtime parameter "zetaMin" 
>>>      
>>>
>>that  
>>    
>>
>>>defaults to zero (because I think it's a good idea to have zero  
>>>limiting/regularizing by default) that you set to 4e8 in your 
>>>      
>>>
>>runs.  
>>    
>>
>>>zmin>0 is not needed by the EVP solver (according to Elizabeth)
>>>
>>>If you want to experiment with zmin = 0, why don't you try  
>>>seaiceadvscheme = 33 with diff1 = 0, but I don't see why this 
>>>      
>>>
>>should  
>>    
>>
>>>affect the stability, also you try to increase the accuracy of 
>>>      
>>>
>>the  
>>    
>>
>>>solver (although you probably don't want that because of cpu 
>>>      
>>>
>>time,  
>>    
>>
>>>right?)
>>>
>>>in general, setting zmin = 0 should have an effect on the 
>>>      
>>>
>>velocities  
>>    
>>
>>>and only after that on HEFF. (btw, can't find your pdf).
>>>
>>>Jinlun, you once recommened setting zmin = 0 (and I agree with 
>>>      
>>>
>>your  
>>    
>>
>>>recommendation). What's your opinion on this problem?
>>>
>>>Martin
>>>
>>>On 2 Jul 2007, at 23:53, Dimitris Menemenlis wrote:
>>>
>>>      
>>>
>>>>Martin, more on the 59c problem:
>>>>
>>>>The "SEAICEuseDynamics=.false." problem is not "directly" 
>>>>        
>>>>
>>related  to 
>>    
>>
>>>>the 59c crash.  That is, "SEAICEuseDynamics=.false." crashes in  
>>>>Arctic Ocean even with pre-59c code.
>>>>
>>>>What causes trouble in 59c is the change from ZMIN=4e8 to ZMIN=0.
>>>>
>>>>Figure http://ecco2.jpl.nasa.gov/data1/cube/cube66/crash.pdf
>>>>shows sea ice thickness around Antarctica right before crash.  
>>>>        
>>>>
>>If  
>>    
>>
>>>>you blow up the pdf file, you will see that there are several  
>>>>regions with grid-scale noise in HEFF.  Also shown are time 
>>>>        
>>>>
>>series  
>>    
>>
>>>>of HEFF at and near region of maximum thickness showing that  
>>>>thickness reaches 2500 m before model crashes.
>>>>
>>>>So what to do?  Go back to ZMIN=4e8?  Change sea ice advection  
>>>>scheme or diffusivity?  (I am using default advection scheme and 
>>>>        
>>>>
>>>>diffusivity.) Artificially impose a limit on HEFF?  Something else?
>>>>
>>>>D.
>>>>        
>>>>
>>_______________________________________________
>>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
>  
>