[MITgcm-devel] more seaice

Jinlun Zhang zhang at apl.washington.edu
Fri Mar 10 11:56:33 EST 2006


Hi Martin,

I see. The clipping was left in the code because I forget commenting 
them out. They were there because of some sensitivity tests I made. 
Dimitris, we need to comment them. They are not needed. So if you mark 
URT and VRT for the purpose of replacing clipping, you don't have to. 
The idea of this particular ice dynamics is that it has to be solved 
throughout the whole model domain, with ice or without ice, to avoid 
velocity discontinuity.

I have tried all sorts of schemes for calculating surface stress, all 
would blow up the code, unless spatial averaging is used, which I don't 
want to. I am still working on it......
Jinlun

Martin Losch wrote:

> Forgot to say what I mean by "clipping":
> at the end of dynsolver (and seaice_dynsolver) you have:
> uIce = min(0.40,uIce)
> uIce = max(-0.40,uIce)
> That's what I call clipping.
>
> The next plan is to look into the stress coupling of Hibler and Bryan  
> (1987, JPO): Instead of applying ice-ocean to the ocean model, use  
> the internal stress of the ice (div sigma). It sounds plausible. Do  
> have any experience with that?
>
> Martin
>
> On Mar 10, 2006, at 9:14 AM, Martin Losch wrote:
>
>> Hi Jinlun,
>>
>> first, a quick update on the AWI sea-ice model: the solver is  
>> basically the original Hibler(1979) solver, with some small  
>> modifications (I checked again with Ralph Timmermann, he said that  
>> the Belgian group that he worked in for some time uses or used to  
>> use your code, but they had problems porting it to the ORCA grid of  
>> OPA).
>>
>> Clippling vs. Masking:
>> I understand LSR as follows: it sets up and solvers a linear system  
>> of equations equation:
>> CoefficientMatrix*UICE(k+1) = URT(UICE(k)) and the same for VICE.  So 
>> if I mask the URT with the "area mask" (seaiceMaskU(I,J) = 1, if  
>> AREA(I,J)+AREA(I-1,J) > 0 otherwise = 0), there is no forcing  
>> outside the ice-area and thus the ice velocities go to zero (in  
>> fact, since it is a global solver to very small numbers) in regions  
>> where there is no ice. The ice regions are probably affected by  this 
>> near the ice boundaries, but according to my quick  tests not  very 
>> much, but I need to check that more thoroughly. This way you  will 
>> not advect zero ice thickness around with large velocities and  thus 
>> avoid numerical problems. I can get away without clipping (in  terms 
>> of numerical stability, I still don't like the solution, not  enough 
>> ice )o: )
>>
>> Martin
>>
>> On Mar 10, 2006, at 1:25 AM, Jinlun Zhang wrote:
>>
>>> Hi Martin,
>>>
>>> Thanks for the info about AWI ice modeling.
>>> I haven't looked at  mitgcm ice part for a while, but wow, you  have 
>>> done lots of work. And good you can run it on a cubed sphere  with C 
>>> grid. But I am not sure why you have to mark out URT and  VRT with 
>>> AREA. You said it is because velocity clipping. What is it?
>>>
>>> Cheers, Jinlun
>>>
>>> Martin Losch wrote:
>>>
>>>> Hello Jinlun,
>>>>
>>>> Thanks for your reply.
>>>> Stresses: I talked to Ralph Timmermann who is currently probably  
>>>> the  one who knows most about "the" AWI ice model (there are by  
>>>> now many  flavors around, one coupled to SPEM, one coupled to  
>>>> MOM2, and a stand  alone version which is basically a handy-down  
>>>> over many generations  of PhD students so that the current  
>>>> students do not really now too  much about the details of it. The  
>>>> basis of all of this is a model by  Harder and Lempke:
>>>> Harder, M.(1996). Roughness and drift trajectories of sea ice in   
>>>> large-scale simulations and their use in model verifications,  Ann  
>>>> Glaciol,25.
>>>> Kreyscher, M., Harder, M., Lemke, P.(1997). First results of the  
>>>> Sea  Ice Model Intercomparison Project (SIMIP), Annals of  
>>>> Glaciology , 25,  8-11.
>>>> And as far as I can see it does not use the LSR solver but  
>>>> something  different which has been changed by members of our  
>>>> computer  department and other. Do you know the term "electronic  
>>>> archeology"?  One would need to do a immense amount of that to  
>>>> figure this things  out (o:.
>>>> And NO, it is not parallel, something that hampers the thrive  for  
>>>> efficiency in the coupled ocean-ice models. Plus there is a  
>>>> hibler- type model on finite elements which will become the new  
>>>> "state of the  art"!)
>>>>
>>>> I don't know if you get the CVS-email notification (and if you  
>>>> do,  pay any attention to it), but I have now written and checked  
>>>> in new  versions of dynsolver, lrs and ostres. They are called   
>>>> seaice_dynsolver.F, seaice_lsr.F, and seaice_ocean_stress.F. They  
>>>> can  be called as an alternative to the original code (which is  
>>>> not  original anymore, since I did all these modifications to the  
>>>> grid  information). The main feature of the new code is that it  is 
>>>> on a C- grid for a cartesian and a spherical grid (still NOT  
>>>> fully  curvilinear). I did that because I want to run the seaice  
>>>> model on a  cubed sphere, where the ice is allowed to move across  
>>>> into other  faces of the cube (which was not possible with the  
>>>> "old version").  Along with this I made a few other changes:
>>>> 1. formulated the ice stress in a way that I find consistent:
>>>>     tau_air-ice = cdair*sqrt([wind]^2)*wind (without averaging  
>>>> over  the entire grid cell)
>>>>     tau_ice-ocean = cdiceocean*sqrt([rel vel]^2)*[rel vel]
>>>>     the ocean feels a weighted average (according to ice cover)  
>>>> of  ice-ocean stress and air-ocean stress
>>>> Because uice and u (vice and v) are now on the same grid there is  
>>>> no  averaging involved (between C and B-grid variables) except  for 
>>>> the  Coriols terms and terms involving this turning angle  (which 
>>>> is zero  by default); and of course, the wind field is on  tracer 
>>>> points, so  there some averaging there, but much less  compared to 
>>>> before!
>>>> 2. I have tried masking *NOT* the velocity field, but the rhs of  
>>>> the  solver, that is, URT and VRT with AREA. That way the  
>>>> velocities are  not discontinuous at all. This solution runs  
>>>> stably (at least for  100yrs in a 2x2 degree run and the coarse  
>>>> cubed sphere with 200km  resolution) and I can even get rid of  the 
>>>> velocity clipping in  seaice_dynsolver.F. What do you think  of 
>>>> that? In fact the solutions  are not that different, but it works
>>>> 3. I have substituted the implementation of the tilt by the real  
>>>> tile  (-gravity*gradient(ssh)).
>>>> 4. I have moved parts of the repeated computations in  
>>>> seaice_dysolver  of E11, etc, FORCEX/Y etc into seaice_lsr.F in  
>>>> order to save code  lines and simplify potential future  
>>>> modifications. I realize that  seaice_lsr is now much more than  
>>>> just the lsr solver, but it was more  than that anyway.
>>>> 5. small changes in handling the parameters (moved previously  
>>>> hard  code values into name lists)
>>>>
>>>> As for lsr.F, as long as the new seaice_lsr.F works so well for  
>>>> me, I  am fine with the currently checked-in version of lsr.F.
>>>>
>>>> Martin
>>>>
>>>> On Mar 8, 2006, at 2:20 AM, Jinlun Zhang wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> Sorry for the delayed reply for your emails. Cool you have been   
>>>>> able to run the version with new indexing and other modifications.
>>>>>
>>>>> As for the calculation of surface stress, as Dimitris  mentioned,  
>>>>> the one implemented right now is a temporary fix. As  a temporary  
>>>>> fix, I prefer the existing treatment. I have been  trying to find 
>>>>> a  permanent solution that would get real stress  at the 
>>>>> ice-ocean  interface into the system, but it is tough to  do.  I 
>>>>> don't know how  AWI ice models calculate stress. I  remember one 
>>>>> AWI paper published  some years back says that some  spatial 
>>>>> average is needed in  calc'ing stress, otherwise, the  code would 
>>>>> blow up. If it is true,  then it is the same problem  we have 
>>>>> here, but I would not want to  use spatial average. By  the way, 
>>>>> would you mind checking AWI ice  models to see if they  use the 
>>>>> LSR solver or use the  Hibler (1979)  solver? I sent out  LSR 
>>>>> model (rectangular version) to some European  groups more  than 10 
>>>>> years ago, I hope it did not lost in  translation (-:.  And I hope 
>>>>> they can use a parallel LSR, if not  already using  some other 
>>>>> parallel code.
>>>>>
>>>>> As for the mask in the LSR solver, better not use AREA=0 as  
>>>>> mask.  This is because it would create velocity discontinuities  
>>>>> between  areas with and without ice.
>>>>>
>>>>> I haven't got deep into the new LSR routine, since you have run  
>>>>> the  code for many years, it is probably ok except that the  
>>>>> metric terms  have not been included, as you mentioned.
>>>>>
>>>>> Cheers, Jinlun
>>>>>
>>>>>
>>>>>
>>>>> Martin Losch wrote:
>>>>>
>>>>>> Hello Dimitris,
>>>>>>
>>>>>> FORCEX/Y at that point are air-ice-stress interactions, the    
>>>>>> coefficient ist call DAIRN. The ice-ocean stresses are put in   
>>>>>> later  after the computation ETA,ZETA,Eij with the coefficent   
>>>>>> DWATN. So I  think that at this point averaging does not make  
>>>>>> much  sense: It would  mean that the ice is driven both by wind  
>>>>>> over ice  and wind over open  water.
>>>>>>
>>>>>> I think in the c-grid version I'll try to do it the way I find  
>>>>>> it   intuitive: separate wind stress over ocean and ice and  
>>>>>> compute  stress  on ocean as the average of ice-ocean stress  and 
>>>>>> wind  stress (on the  ocean). This is how it is done in the  
>>>>>> various  coupled AWI ice models.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> On Mar 6, 2006, at 7:54 PM, Dimitris Menemenlis wrote:
>>>>>>
>>>>>>>> The way I understand this is that the stress on the ice is  
>>>>>>>> an   average over ocean stress and ice stress ( the statement  
>>>>>>>> before   FORCEX(I,J,bi,bj) = ...), whereas the stress over  the 
>>>>>>>> ocean is   just the ocean stress not weighted at all. I  find 
>>>>>>>> this a little   inconsistent if not wrong. I would think  that 
>>>>>>>> these
>>>>>>>>  terms should be treated separately, with only the ice  
>>>>>>>> stress   driving the
>>>>>>>> ice, right?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Martin, yes it is inconsistent.  As Jinlun mentioned in an   
>>>>>>> earlier  message, the
>>>>>>> original formulation for ocean stress, the one marked by CPP flag
>>>>>>> SEAICE_ORIGINAL_BAD_ICE_STRESS in ostres.F caused model    
>>>>>>> instabilities.  As a
>>>>>>> temporary fix, the presence of ice is ignored in the  
>>>>>>> computation  of  ocean
>>>>>>> surface stress, variables WINDX and WINDY.
>>>>>>>
>>>>>>> Regarding ocean stress at bottom of ice, variables FORCEX  and   
>>>>>>> FORCEY, my understanding is that dynsolver assumes that  thin 
>>>>>>> ice   covers the open ocean everywhere, hence the  weighted sum 
>>>>>>> of ice-  covered and ice-free components in the  computation of 
>>>>>>> FORCEX and   FORCEY.  But I do not know whether  and why this 
>>>>>>> thin-ice  assumption  is required nor what would  be impact of 
>>>>>>> setting the  URT/VRT mask to  zero where AREA=0.
>>>>>>>
>>>>>>> Dimitris
>>>>>>



More information about the MITgcm-devel mailing list