[MITgcm-devel] heff_max...more sea ice issues

Martin Losch Martin.Losch at awi.de
Fri Dec 22 04:09:46 EST 2006 

Hi Matt,

I am sorry, but I will now make life more difficult for you:

1. LSR is an implicit scheme, BUT is does not treat the Coriolis term  
implicitly (so it is different from the alogoritm described in  
Jinlun's paper Zhang+Hibler (1998), or rather it uses only the first  
two parts of that algorithm). From my experience with explicit  
Coriolis terms, I would guess that you are limited by approximately  
1h (at least that's true for the ocean) for SEAICE_deltaTdyn (I  
usually set this to deltaTmom for asynchronos time stepping). I am  
not sure that I can take 12h time steps, but see next point:

2. I don't see why changing the time step should save you any time  
anyway: The seaice model (including the lsr or evp solver) is called  
at every time step and changing the time step can only affect the  
stability (if you do an asynchonous time stepping scheme). We have  
not (yet) implemented a scheme that calls the seaice model or parts  
of it only every so often (depending on the time step). This is  
commonly done in other models and seems to be good way of reducing  
the computational cost (if the ice model is slow, why is the ice  
model slow? It's a 2D model? I don't get it!).

3. the EVP solver requires a very short time step. For example, for  
my 2deg model I use SEAICE_deltaTevp=60s which is a 20th of the  
deltaTmom=SEAICE_deltaTdyn. According to the manual of CICE (Hunke's  
ice model) one should use something like a 30th to a 20th of the  
physical time step. Now EVP steps forward the stress evolution  
equations n-times (in my case 20 times) within on SEAICE_deltaTdyn  
time step. For a large domain (and high resolution), this is usually  
still faster than LSR, because in LSR call the routine lsr (or  
seaice_lsr) twice and in each call you do two iterations, one for  
Uice and one for Vice, so you have 4 iterations and if one is only 5  
steps, then you still have 20 steps, which are more complicated than  
the seaice_evp dynamics.

4. metric terms: the dynamics include only the metric terms for the  
spherical grid. I know that this is not exact for a general  
orthogonal coordinate system, but as far as I know Matt is using a  
spherical grid anyway. Including all metric terms (or finding a  
"vector invariant" formulation of the stress) is still a "to do".

Without knowing the details of your configuration I would recommend  
these experiments:
Use SEAICE_deltaTdyn = deltaT(mom) and SEAICE_deltaTtherm = deltaT 
(tracer) in any case (your deltaT is probably on the order 600-900sec  
isn't it?).
1. try the B-grid code (I expect that is will be even worse, but if  
not that's a lot of help for me in terms of debugging. I am praying  
that this experiment will not help you (o:)
2. Try LSR with higher precision maybe even better than 1e-4 (will  
make you model even slower, but maybe stable)
3. Try EVP with SEAICE_deltaTevp = deltaT(mom)/20
4. with C-grid: turn off the ice-ocean stress, for that you'll have  
to edit seaice_ocean_stress: comment out the lines that say fu=(1- 
areaw)*fu + areaw*fuice etc. (But note: Dimitris has found in his  
high res cubed sphere experiments that using ice-ocean stress in the  
C-grid is stable, while on the B-grid it's not, so I personally don't  
think that turning off the stress will help).
5. with C-grid: try the Hibler and Bryan stress, that's could even  
more stable (and is more physical too, but I have in the back of my  
mind that Dimitris had problems with this in his high res runs).

Martin

On 22 Dec 2006, at 01:30, Jinlun Zhang wrote:

> Matt,
> This is a paper that gives a clue about EVP time step.
> http://www.mrcc.uqam.ca/V_f/Publications/articles/ 
> Saucier2004_ClimDyn.pdf.
> Jinlun
>
> Matthew Mazloff wrote:
>
>> Dimitris and Jinlun,
>>
>> Thank you very much for the info.  I will try some runs (in early   
>> January) and let you know how how things work out.
>>
>> -Matt
>>
>> On Dec 21, 2006, at 6:47 PM, Jinlun Zhang wrote:
>>
>>>
>>>
>>> Matthew Mazloff wrote:
>>>
>>>> Thanks for the help...but I am a bit confused.  Two things
>>>>
>>>> 1) Re model efficiency and time stepping...I see there are 3    
>>>> parameters.  I am guessing  SEAICE_deltaTtherm should be the   
>>>> ocean  dynamics time-step as the forcing comes from this.  The   
>>>> other time  stepping parameters are  SEAICE_deltaTdyn  and   
>>>> SEAICE_deltaTevp which  I assume are the timesteps for each   
>>>> dynamic solver (LSR and EVP)  respectively.  And as I  
>>>> understand  it LSR can use the "large"  timestep, but the EVP  
>>>> should use the  "small" timestep...is this  correct?  And I am  
>>>> not using both at  the same time obviously, but you  are saying  
>>>> I should try both  independently because it is not obvious   
>>>> which is faster.
>>>
>>>
>>> Correct.
>>>
>>>>
>>>> 2)More important than efficiency (right now anyway) is   
>>>> stability.   Jinlun, your first email seemed to suggest I try  
>>>> LSR  with a half day  time step and LSR_ERROR=1e-4, or try EVP  
>>>> with  "small" timestep.  Are  either of these methods likely to  
>>>> be more  stable?
>>>
>>>
>>> Although we may use half day time step for LSR, but it is better  
>>> to  use the same ocean dynamics time step for LSR for  
>>> consistency, and  particularly when the code blows up. And using  
>>> 1e-4. I would think,  from the heff_max figure, that the problem  
>>> is most likely due to  the surface ocean stress calculation that  
>>> causes instability.  However, you might also want to try EVP. I  
>>> don't have much  experience with EVP, but people have been  
>>> telling me that very  small time steps should be used for  
>>> stability and for getting rid  of unphysical elastic waves. I  
>>> read one paper about high-res.  (~10km) Hudson Bay simulation,  
>>> the time step is as small as a few  seconds.
>>>
>>> Jinlun
>>>
>>> _______________________________________________
>>> 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
>
>
> -- 
>
> Jinlun Zhang
> Polar Science Center, Applied Physics Laboratory
> University of Washington, 1013 NE 40th St, Seattle, WA 98105-6698
>
> Phone: (206)-543-5569;  Fax: (206)-616-3142
> zhang at apl.washington.edu
> http://psc.apl.washington.edu/pscweb2002/Staff/zhang/zhang.html
>
>
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list