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

Matthew Mazloff mmazloff at MIT.EDU
Sun Dec 17 14:33:26 EST 2006


Hello,

My upper layer is 10m thick.  When heff_max > 5m the model crashes.   
(This only happens with dynamics on (LSR_ERROR = 1e-3 in my  
calculations so not very accurate).  With dynamics off the ice never  
reaches this thickness.)  I am modeling the Southern Ocean, I am sure  
Arctic modelers must have this problem to an even greater degree.   
What is other people's experiences with thick ice and stability?   
Should an effective thickness capping be implemented?

Thanks
-Matt


fyi:  I tried the free drift sea ice hack (i.e. setting uc ~ uvel in  
seaice_advdiff.F) and the model crashed.  The results were  
odd....lots of numerical noise in AREA and, it appeared, no  
significant advection.




On Dec 6, 2006, at 3:45 PM, Martin Losch wrote:

> Hi Jinlun,
>
> in the end, we want to be able to use a flux-limited 3rd order  
> advection scheme, it's just not yet possible.
>
> Unfortunately my model stops at 80degN. I really need to set up a  
> truly global ocean model. I do assume though, that there is  
> something fishy with the precipitation in the CORE data set. Would  
> be interesting to see if some-one else has a similar experience.
>
> In general, though, the ice extend is too large in winter (in  
> particular in the Drake Passage, isn't it?). That 's the only thing  
> that's still worrying me.
>
> XKI: I am only playing with this parameter to find out how the model 
> (s) behave(s). In practice I will always use something around 2.  
> XKI only appears in the denominator in budget.F, so I don't quite  
> see what it does. I guess I have to dig up Hibler79/80 and have a  
> look at the thermodynamics, right?
>
> M.
>
> On 6 Dec 2006, at 18:34, Jinlun Zhang wrote:
>
>>
>>
>> Martin Losch wrote:
>>
>>> Hi Jinlun,
>>> thanks for you input. I really enjoy this discussion!
>>>
>>> For clarification: I use the same advection for HEFF, HSNOW, and   
>>> AREA. That is run47 has 1st order upwind for all three  
>>> variables,  while run41 has 2nd order central differences scheme  
>>> (and not  flooding algorithm). All runs use a little bit of  
>>> diffusion (the  default values of DIFF1=0.004), which is probably  
>>> not good for run47.
>>
>> Hi Martin,
>>
>> Good the ice and snow advection is consistent. When you use 1st  
>> order upwind, perhaps you do not have to use any diffusion (if you  
>> have used any) since it is quite diffusive.
>>
>>>
>>>
>>> run48 uses only 10% of the snow precipitation, but uses flooding   
>>> (it's just like 45). Are you saying that this should not reduce  
>>> the  ice amount? One source of the ice is flooded snow in the  
>>> flooding  algorithm in the current version of growth.F (http:// 
>>> dev.mitgcm.org/ cgi-bin/viewcvs.cgi/MITgcm/pkg/seaice/growth.F?  
>>> rev=1.34&only_with_tag=MAIN&content-type=text/vnd.viewcvs- 
>>> markup).  One of my problems was, that the huge amounts of snow  
>>> that you see in  run40 (160m in some places, no flooding, no  
>>> advection) are turned  into ice by flooding and lead to ice  
>>> thicknesses beyond my  expectation. Either there is too much snow  
>>> to begin with, or  something is wrong in the handling of snow and  
>>> not enough snow is  melted.
>>
>> I was looking at wrong figure and had mistakenly thought that when  
>> you reduced snow, ice was pretty much gone. But actually ice was  
>> only slight reduced with run48, not really bad. Sorry for the  
>> mistake.
>> I don't know what is wrong with run40, but I wonder if this huge  
>> snow depth also occurs in the Arctic. If that is the case in  
>> Arctic also, then definitely something is really wrong with the  
>> model.
>>
>>>
>>> 1D tests: As far as I understand the physics of ice formation:  
>>> Ice  forms because the atmospheric heat flux cools the ocean  
>>> surface below  freezing. Ice continues to grow as long a the  
>>> atmospheric surface  flux continues to cool the ocean. In the  
>>> presence of ice this  atmospheric heat is "diffused" (conducted)  
>>> through the ice according  to the net conductivity. In the  
>>> absense of snow this conductivity  should be SEAICE_iceConduct  
>>> (XKI in budget.F). If the ocean provides  heat from below by  
>>> upward transport of warmer waters (by vertical  convection), then  
>>> this heat flux can balance the atmospheric heat  flux and stop  
>>> the ice from growing. When you equate these fluxes  roughly at  
>>> equilibrium: Qocean = conductivity*(Tair-Tsurfocean)/hice  you  
>>> get the ice thickness that follows form this balance hice =   
>>> conductivity*(Tair-Tsurfocean)/Qocean.
>>> Hypothetically I should be able to modify this "equilibrium   
>>> thickness" by playing with the conductivity (or Qocean or the   
>>> temperature difference). However I find that the model parameter   
>>> XKI=SEAICE_iceConduct has no impact on hice (I use 1e-6 instead  
>>> of  2!). That's puzzling, isn't? For the thsice package, the   
>>> corresponding parameter does have an impact.
>>
>> Your reasoning sounds ok. But I am not sure why ice is so  
>> insensitive to XKI in equilibrium. It does not make sense. Note  
>> that XKI is a physical term that is likely determined by lad  
>> experiments. Better not use a different number. Would be  
>> interesting to see how sensitive ice thickness/extent is to XKI in  
>> real simulations.
>> Jinlun
>>
>>>
>>> Martin
>>>
>>>
>>> On 5 Dec 2006, at 18:17, Jinlun Zhang wrote:
>>>
>>>>
>>>> Martin Losch wrote:
>>>>
>>>>> Jinlun,
>>>>> thanks for your opinion. The thsice thermodynamics are  
>>>>> basically   Winton's (2000) model, but we have not yet fully  
>>>>> sorted out the   advection part.
>>>>> I have now a run47 with SEAICEadvScheme = 1 (1st order upwind,   
>>>>> too  smooth) and no flooding, and and another one (run48) which  
>>>>> is  just  like run45 but with only a 1/10th of the snow fall,  
>>>>> just to  see what  happens, see
>>>>> http://mitgcm.org/~mlosch/run47.png
>>>>> http://mitgcm.org/~mlosch/run48.png
>>>>> As expected is run47 closest to what we expect. But run48 is  
>>>>> not  too  bad either, too little snow (of course) and as a  
>>>>> consequence  too  little ice. So either there is too much snow/ 
>>>>> precip in the   atmospheric forcing, or there is something not  
>>>>> kosher in the snow   parameterizations. As the problems are  
>>>>> similar with thsice I  would  agree that the forcing may be the  
>>>>> problem ... I have to try  and find  different precipitation  
>>>>> fields.
>>>>
>>>>
>>>> Marin,
>>>> Yeah run47.png looks pretty good. The advection works ok. But I   
>>>> wonder what ice advction you are using, 2nd order or 1st order?  
>>>> The  one I installed is 2nd order. Ideally, the snow advection  
>>>> should be  exactly the same as the ice advection so ice and snow  
>>>> won't devorce  with each other.
>>>> It is not right with run48 that when the snow is turned off, ice  
>>>> is  gone. Some thing is wrong here.
>>>>
>>>>>
>>>>>
>>>>> I have also made another observation: I tried to run the   
>>>>> different  thermodynamics without any dynamics in a 1D case. I   
>>>>> expect (and JMC  agrees with me) that for constant air  
>>>>> temperature  (say -30degC), ice  thickness should grow until  
>>>>> there is some  equilibrium thickness, when  the remaining heat  
>>>>> flux out of the  ocean is balanced by the diffusive  flux of  
>>>>> heat through the ice.  I assume that the diffusion is   
>>>>> controlled by "SEAICE_iceConduct"  for seaice and kice for  
>>>>> thsice. The  equilibrium thickness can  roughly be estimated by  
>>>>> hequil =  conductivity*(Tair-Twater)/ heatflux.
>>>>> I have only succeded yet in reaching some equilibrium  
>>>>> thickness  with  thsice (with an unrealistic value of kice=1e-6  
>>>>> instead of  2). For  growth, this only works if I turn on some  
>>>>> precipitation  (snow).  Without snow HEFF is completely  
>>>>> independent of  SEAICE_iceConduct,  which I don't think is right.
>>>>
>>>>
>>>> I don't understand this equil. ice thickness )-:. As said  
>>>> above,  without snow-without ice thing or ice not working right  
>>>> without  snow does not make sense to me.You might want to check  
>>>> with  Thorndike (199?) for a toy model of equil. ice thickness.
>>>> Jinlun
>>>>
>>>>>
>>>>> M.
>>>>>
>>>>> On 5 Dec 2006, at 03:39, Jinlun Zhang wrote:
>>>>>
>>>>>> Martin,
>>>>>>
>>>>>> I would vote run45.png for best performance except that the   
>>>>>> summer  ice is slightly overestimated. I would not vote  
>>>>>> run41.png  because  of its weird snow distribution. The snow  
>>>>>> pattern should  generally  follow the ice pattern (could mean  
>>>>>> a problem with ice  advection). I  don't know why the snow  
>>>>>> gets so thick with  run40.png, the precip  forcing could be  
>>>>>> way off. But obviously  snow advection helps a lot.  Snow  
>>>>>> flooding, if it overestimates  ice, then turn it off, not big   
>>>>>> deal (since what we do is to make  the fields look like   
>>>>>> observations). As for thsice, I don't know  what is going on.  
>>>>>> But  for any ice thermodynamics that involves  ice salinity  
>>>>>> (if thsice  uses ice salinity), there might be a  singularity  
>>>>>> in the formulation  (I had such feeling before, but I  could  
>>>>>> be wrong).
>>>>>>
>>>>>> Jinlun
>>>>>
>>>
>>> _______________________________________________
>>> 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




More information about the MITgcm-devel mailing list