[MITgcm-devel] possible problem in seaice_solve4temp iteration

Martin Losch Martin.Losch at awi.de
Wed Dec 1 09:02:02 EST 2010 

Hi Jean-Michel,

comments below
On Nov 30, 2010, at 7:03 PM, Jean-Michel Campin wrote:

> Hi Martin,
> 
> I have few comments:
> 1) I did not look at the non legacy part; I interpreted your modification
> as just to remove the resetting of tsurf inside the loop. 
> I did not understand that this would also imply to add a recomputation of 
> the surface fluxes after the iteration loop and after resetting tsurf
> (as done in the non-legacy part). And Frank message was vague on this
> subject. This is the reason for my previous answer.
Obviously I made this error, too, initially. I think we can agree that NOT resetting tsurf to zero in the iteration and then NOT recomputing the fluxes after the iteration is clearly wrong. I do think that resetting tsurf in the iteration has an impact on the Newton algorithm (in the worst case it basically breaks it), but this impact is not so large (in contrast to what I said in the beginning).

> 2) a fair comparison would be to test:
> a = present legacy code
> b = keeping the resetting of tsurf in the iteration loop, and just add
>    the recomputation of surface fluxes at the end.
> c = b but removing the resetting of tsurf in iteration loop.
I have done a and c, I can do b now.
> 
> 3) I remember vaguely (but need to think a little about this)
> cases where we don't want to recompute fluxes at the end.
That would be interesting to recall!
> 
> 4) the difference beetween b and c can be due to the type of 
> situation you draw in the sketch. The non-trivial question
> is to know the shape/dependence of the fluxes vs tsurf: 
> Does this case (the sketch) really happen ?
I am attaching a short matlab script that shows, that the general shape of the function is not as I sketched, but much better behaved. Once you can play with the parameters, it will be quite clear that making this change in the code (including or excluding the min(tsurf,tmelt) will not really change the results, except for the recomputation of the fluxes (so if you always recompute the fluxes after the iteration, there will no difference between "b" and "c").

So, if we have a problem in the legacy part of seaice_solve4temp, then it's about not recomputing the fluxes after the iteration (basically we do an iteration less, because we use the fluxes computed with tsurfloc before updating it.)

Martin


> 
> On Tue, Nov 30, 2010 at 09:27:08AM +0100, Martin Losch wrote:
>> 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
>> 
>> 
>> _______________________________________________
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: solve4temp.m
Type: application/octet-stream
Size: 1181 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20101201/ba64b7ad/attachment-0001.obj>

More information about the MITgcm-devel mailing list