[MITgcm-devel] heff_max...more sea ice issues
Patrick Heimbach
heimbach at MIT.EDU
Fri Dec 22 05:38:55 EST 2006
HI there,
since Matt is burning up 600 procs at a time,
there's not too much room for experimenting,
so I would skip all the stuff having to do with LSR
and B-grid (i.e. 1 and 2 in Martin's list) and jump
right to C-Grid plus EVP.
I think Matt has tried SEAICE_deltaTevp = 60 sec
which might be too big given his timestep of
around 1200 sec.
-p.
Quoting Martin Losch <Martin.Losch at awi.de>:
> 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
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
--------------------------------------------------------
Patrick Heimbach Massachusetts Institute of Technology
FON: +1/617/253-5259 EAPS, Room 54-1518
FAX: +1/617/253-4464 77 Massachusetts Avenue
mailto:heimbach at mit.edu Cambridge MA 02139
http://www.mit.edu/~heimbach/ USA
More information about the MITgcm-devel
mailing list