[MITgcm-devel] possible problem in seaice_solve4temp iteration

Tue Nov 30 03:27:08 EST 2010

Hi Jean-Michel (and others),

after fixing numerous mistakes that I made in my first attempt, I am now comparing a run where tsurfloc is reset to 0 (if >0) in each iteration, and on where it is only reset after the end of the iteration, and then the fluxes are recomputed using tsurf = min(tsurf,tmelt). This gives differences in the runs, but mostly near the ice edge. In the interior the thickness differences and TICE temperature differences are very small. So in contrast to my previous statements, I cannot reproduce the results of Frank Kauker, who finds that this code change has a large impact on ice volume.

I concede that it does not matter very much, but I still think the iteration without resetting to tmelt would be cleaner. As I said before, Ian's code never reset this variable during the iteration. Since we think that the "LEGACY" code is on it's way out, we should probably not change this bit anymore.

Martin

On Nov 25, 2010, at 4:55 PM, Martin Losch wrote:

> Hi Jean-Michel,
> 
> I'll try to illustrate a case in which it might be good to NOT reset tsurfloc=0 within the iteration. Have a look at the attached sketch. For the function that I drew, the step m+1 would lead to a t(m+1) that is larger than 0. In step m+2, t would then go back below 0 closer towards the solution (the intersection with horizontal). If you truncate t<=0, then t can never reach the zero-crossing. In solve4temp (and maybe also in the thsice equivalent), the function in question is A*t^4+B*t = C, so that local minima as in the sketch are possible.
> 
> My observation is that without truncating tsurfloc in each iteration, the ice thickness/volume increases a lot (also seen by Frank), also there are indications (so far only for January), that TICE (tsurfLoc) is always lower in this case by a few degrees (consistent with thicker ice, right?).
> 
> What do you think? (after the iteration tsurfloc must be reset, but I am not sure about the steps within the iteration).
> 
> Martin
> 
> On Nov 24, 2010, at 9:58 PM, Martin Losch wrote:
> 
>> Hi Jean-Michel,
>> 
>> I was joking, I'm not going to check in anything tomorrow, until you've made your checkpoint.
>> 
>> About tsurfloc: I am torn a little, and need to rethink. In any case, the "new" branch does not contain this resetting.
>> 
>> Martin
>> 
>> On 24.11.10, Jean-Michel Campin  <jmc at ocean.mit.edu> wrote:
>> 
>>> Hi Martin,
>>> 
>>> Regarding timing, 8am Eastern time is little early (it means
>>> I would have to make the checkpoint before 8.am after
>>> checking that most of the testreport results are OK; I generally
>>> check between 9 and 10.am). 
>>> Let's pick 10.30 am EST for tomorrow. Hope it's OK with you.
>>> 
>>> regarding solve4temp, I tend to disagree:
>>> 2 cases:
>>> a) it does not matter because flux calculations depend
>>> linearly on Tsurf (but in this case, we don't need to iterate,
>>> can just solve for Tsurf directly);
>>> b) it matters, because flux dependence on Tsurf is non-linear, 
>>> and then it's better to evaluate those fluxes using the right 
>>> Tsurf (=0) rather than using a wrong Tsurf (>0). 
>>> This requires to reset Tsurf to zero (if > 0) within the loop, 
>>> to get a chance, at the next iteration, to evaluate the fluxes 
>>> with the right Tsurf=0.
>>> 
>>> Cheers,
>>> Jean-Michel
>>> 
>>> On Wed, Nov 24, 2010 at 04:58:45PM +0100, Martin Losch wrote:
>>>> Hi Jean-Michel,
>>>> 
>>>> I promise to not make any changes until afternoon (after 2pm my time, 8am your time), OK?
>>>> 
>>>> solve4temp: The problem is that tsurfloc is reset to tmelt (=0degC) within the iteration, this might modify the convergence properties of the iteration. I'll check if this has any effect in a longer integration.
>>>> 
>>>> Martin
>>>> 
>>>> On Nov 24, 2010, at 4:53 PM, Jean-Michel Campin wrote:
>>>> 
>>>>> Hi Martin,
>>>>> 
>>>>> Gael and me were looking at this part of the code yesterday.
>>>>> But it's still not completely clear to me.
>>>>> I think that thsice_solve4temp is OK (+ I understand it).
>>>>> 
>>>>> Nothing to do with that: I was planning to make checkpoint62o
>>>>> and would prefer to do it on a tested version (after most of the
>>>>> daily testreport output are done) and before any new morning change.
>>>>> Could I try tomorrow ?
>>>>> 
>>>>> Cheers,
>>>>> Jean-Michel
>>>>> 
>>>>> On Wed, Nov 24, 2010 at 04:35:48PM +0100, Martin Losch wrote:
>>>>>> Hi there,
>>>>>> 
>>>>>> the problem described below also exists in our seaice_solve4temp.F, the "legacy" branch.
>>>>>> 
>>>>>> For some reason, the (forward-) verifications experiments are not affected (haven't checked the adjoint ones yet), but I still need to do a longer run to see, if this has a similar effect than for Frank Kauker (NAOSIM).
>>>>>> 
>>>>>> Do you think that we should correct this "bug". Our code tends to have too little ice in the Arctic, ...
>>>>>> 
>>>>>> M.
>>>>>> 
>>>>>> Begin forwarded message:
>>>>>> 
>>>>>>> From: Frank Kauker <Frank.Kauker at awi.de>
>>>>>>> Date: April 1, 2009 2:03:00 PM GMT+02:00
>>>>>>> To: Wolfgang.Dorn at awi.de
>>>>>>> Cc: Qiang.Wang at awi.de, Martin.Losch at awi.de, Cornelia.Koeberle at awi.de, Ruediger.Gerdes at awi.de, Michael.Karcher at awi.de
>>>>>>> Subject: NAOSIM: error in skin temperature calculation
>>>>>>> 
>>>>>>> Dear All,
>>>>>>> 
>>>>>>> we detected an error in the calculation of the skin temperature over sea ice in NAOSIM. Within each iteration of the solver for the heat conduction the temperature was set to zero if the temperature exceeds 0C. We moved that statement after the end of the iterative solver.
>>>>>>> 
>>>>>>> This has dramatic influence on the ice extent and ice volume. The icevolume increases by about 10000km2 in the yearly mean. I added two figures showing the domain-wide monthly extent and volume from 1948 to 2008 (ncep forced) for the corrected code and a lead closing parameter h0 of 1m (red lines). To get rid of the too high ice volume (at least we think it is too high) and to get more realistic ice extent (observed 2007 September = 4.3 10**6 km**2) we adjusted h0 to 0.5m (which is the value suggested by Bill Hibler).
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Frank
>>>>>> 
>>>>> 
>>>>>> _______________________________________________
>>>>>> MITgcm-devel mailing list
>>>>>> MITgcm-devel at mitgcm.org
>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel (http://mitgcm.org/mailman/listinfo/mitgcm-devel)
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> MITgcm-devel mailing list
>>>>> MITgcm-devel at mitgcm.org
>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel (http://mitgcm.org/mailman/listinfo/mitgcm-devel)
>>>> 
>>>> 
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel (http://mitgcm.org/mailman/listinfo/mitgcm-devel)
>>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel (http://mitgcm.org/mailman/listinfo/mitgcm-devel)
>>> 
>>> 
>> -- 
>> Martin Losch
>> Alfred Wegener Institute 
>> Postfach 120161, 27515 Bremerhaven, Germany; 
>> Tel./Fax: ++49(0471)4831-1872/1797
>> 
>> 
>> 
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> <3131_001.tif>_______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel