[MITgcm-devel] another bug in growth.F ?

Martin Losch Martin.Losch at awi.de
Thu Nov 30 02:43:03 EST 2006 

And right he is!
However, thsice+seaice does not work stably either (at least not for  
me). The question is, what's faster to sort out. I seem to be swamped  
with other things so that I have only about 15min a day to think  
about seaice, so I am inclined to go with the quick fixes to growth  
and do it right when I get time to breathe, but in principle I am  
"d'accord" with the beer suggestion, even without beer (meaning that  
I am already convinced).

Will JM let us in to the secrets of snow in thsice (it's not that  
easy to understand either)? (o:

Maybe we should talk about this soon.

M.

On 30 Nov 2006, at 01:51, Patrick Heimbach wrote:

>
> Hi Guys,
>
> J.M. just steps in my office. And guess what he says?
> "Will take some strong beer to convince them
> that there is a pkg that has those snow issues solved?
> (and we had planned to switch to it)"
> Well, it's not exactly what he said, but...
>
> -p.
>
>
>
> On Nov 29, 2006, at 11:59 AM, Martin Losch wrote:
>
>> Hi Dimitris,
>> I have tried this:
>>> CML          IF(FICE(I,J,bi,bj).GT.ZERO) THEN
>>>           IF ( AREA(i,j,2,bi,bj).GT.0. _d 0
>>>      &        .AND. atemp(i,j,bi,bj).LE.273.16 _d 0 )  THEN
>>> C FREEZING, PRECIP ADDED AS SNOW
>>>            HSNOW(I,J,bi,bj)=HSNOW(I,J,bi,bj)+SEAICE_deltaTtherm*
>>>      &            PRECIP(I,J,bi,bj)*AREA(I,J,2,bi,bj)*SDF
>>>           ELSE
>>> C ADD PRECIP AS RAIN, WATER CONVERTED INTO equivalent m of ICE BY  
>>> 1/ICE_DENS
>>>              SEAICE_SALT(I,J,bi,bj)=SEAICE_SALT(I,J,bi,bj)
>>>      &            -PRECIP(I,J,bi,bj)*AREA(I,J,2,bi,bj)*
>>>      &            SEAICE_deltaTtherm/ICE_DENS
>>>           ENDIF
>> to make snow a function of air temperature instead of FICE (ice  
>> growth rate?), but that does not change the results very much.  
>> (after 10 years, more tomorrow)
>>
>> However, what seems to be more important is my little flooding  
>> algorithm. Turning that off decreases HEFF by almost a a factor of  
>> 2 at the cost of a having too much snow (>5m in 10years) in  
>> isolated places again (all without advection of snow).
>>
>> I don't know what to say. I'll wait until tomorrow to have a  
>> closer look after 100years of integration, but a first look  
>> implies that the snow alogithm is still not working the way we  
>> expect it to work and the flooding algorithm takes all the snow  
>> and converts it into ice. Which leads us back to the original  
>> problem of too much snow in the first place. (I am using the  
>> latest code).
>>
>> M.
>>
>> On 28 Nov 2006, at 20:29, Martin Losch wrote:
>>
>>> Hi Dimitris,
>>>
>>> since I have been doing all this sort of "by the way" I am no  
>>> longer absolutely sure, what exactly run34 is. But most likely it  
>>> is with growth.F pre 1.29, and with flooding turned on, but NO  
>>> advection of snow (the last two I know for sure). So the flooding  
>>> algorithm takes care of the snow over open water, but in a pretty  
>>> simple way, thermodynamically speaking. run38 is the same with  
>>> growth.F 1.34
>>>
>>> This forward sensitivity is frightening. I am not sure if I am as  
>>> optimistic about it as you are, but I have nothing to offer in  
>>> terms of explanations. I observe in my 100y runs that the ice  
>>> thickness builds up within the first 10years and then stays  
>>> nearly stationary (with seasonal cycle of course). The ice cover  
>>> does not retreat very far in summer. Does the non-linear effect  
>>> that you describe explain such an "equilibrium" at higher mean  
>>> ice thicknesses?
>>>
>>> I have not had the time to get my head around the thermodynamics  
>>> in growth, but your suggestion (making snow/rain depend on  
>>> forcing fields) sounds good to me. Currently I have not time to  
>>> play with this (maybe starting again next Friday)
>>>
>>> Martin
>>>
>>> On 28 Nov 2006, at 17:08, Dimitris Menemenlis wrote:
>>>
>>>> Martin, I also notice increased ice thickness around Antarctica  
>>>> in the high-res cubed sphere integration and increased sea-ice  
>>>> extent, much more summer ice extent than observed.
>>>>
>>>> What is you run34?  In terms of CVS repository,
>>>> http://mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/pkg/seaice/growth.F
>>>> which version of growth.F did you use: pre 1.29, 1.29 with  
>>>> flooding and advection turned on, 1.30, or 1.34?  So far as I  
>>>> have looked in my own tests, results from 1.30 and 1.34 are not  
>>>> that different.  But then your run34 does not have snow over  
>>>> open water, so it cannot be pre 1.29?
>>>>
>>>> Optimistically, the too-much ice in run38 may be a bug in the  
>>>> NCEP/CORE forcing fields rather than in growth.F.  That is, too  
>>>> much precipitation is converted into snow, which extracts heat  
>>>> from ocean when it melts.  The effect would be highly non-linear  
>>>> since more ice/snow extent means higher albedo, which leads to  
>>>> cooler ice/ocean surface temperature, which in turn leads to  
>>>> more precipitation being converted to snow, since in present  
>>>> treatment of precipitation, rain to snow conversion depends on  
>>>> thermodynamic ice growth (rain) or melt (snow).
>>>>
>>>> Optimistically again, the high tangent linear sensitivity noted  
>>>> by Patrick and also in the verification experiments that you  
>>>> report is also due to above effect.  Incidentally, with growth.F  
>>>> prior to 1.30, the verification/lab_sea domain is at all times  
>>>> 100% covered with snow (but not ice).  So low forward  
>>>> sensitivities prior to 1.30 are almost certainly for wrong reason.
>>>>
>>>> One possible way of reducing the forward sensitivity (I have not  
>>>> yet tried it) would be to remove the snow/rain dependence on ice  
>>>> growth rate and instead make it depend on forcing field, e.g.,  
>>>> surface air temperature and fresh water freezing point, as is  
>>>> done in pkg/thice.  Should I give this a try?
>>>>
>>>> Dimitris
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
> Dr Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
> MIT | EAPS, 54-1518 | 77 Massachusetts Ave | Cambridge, MA 02139, USA
> FON: +1-617-253-5259 | FAX: +1-617-253-4464 | SKYPE: patrick.heimbach
>
>
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel

More information about the MITgcm-devel mailing list