[MITgcm-devel] switching seaice_obcs from legacy to devel

[Gael Forget]

Dimitris,

I concur with Martin on both points. I had already taken the time 
to search for the cause. The different is due to the second term in
          tmpscal2 = MAX(-HEFF(I,J,bi,bj),r_QbyATM_cover(I,J)+
     &        AREApreTH(I,J) * r_QbyOCN(I,J))
that "limit ice growth by potential melt by ocean". That term helps getting 
rid of such a film of ice. It is one of Ian's improvements to the model. 

In case you want to also resolve the issue at the initiation of the run,
I attach modified initial conditions with 0s where h<0.01m. The
open boundaries may also feed very thin ice, but may be that is fine.
Up to you.

Gael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: HSNOW.seaice_obcs
Type: application/octet-stream
Size: 320 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20121215/8e031b86/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HSALT.seaice_obcs
Type: application/octet-stream
Size: 320 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20121215/8e031b86/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HEFF.seaice_obcs
Type: application/octet-stream
Size: 320 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20121215/8e031b86/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AREA.seaice_obcs
Type: application/octet-stream
Size: 320 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20121215/8e031b86/attachment-0003.obj>
-------------- next part --------------


On Dec 15, 2012, at 12:16 PM, Menemenlis, Dimitris (3248) wrote:

> Sounds good. I agree. I will go ahead and check in later today.
> 
> I am trying to remember if An's experiment warmed or cooled with new code. This behavior would certainly explain a warming with newer code and we would need to readjust albedos accordingly.
> 
> Wish I was in Cambridge with u guys.
> 
> Dimitris Menemenlis
> 
> On Dec 15, 2012, at 8:46 AM, "Martin Losch" <Martin.Losch at awi.de> wrote:
> 
>> Hi Dimitris,
>> 
>> sitting vis a vis with Jean-Michel at his kitchen table, here's my (really: our) take on this:
>> 1. we don't want to use the legacy code anymore and in fact most (all) of us don't, so it's better to test the code that is being used.
>> 2. having very small ice thicknesses (10e-3) with 100% does not appear very physical, so searching for this would mean searching for a problem in code that we actually want to get rid off.
>> 
>> So let's go ahead and use the non-legacy code in this experiment without further worrying about the differences.
>> 
>> Martin
>> 
>> On Dec 15, 2012, at 12:41 AM, "Menemenlis, Dimitris (3248)" <Dimitris.Menemenlis at jpl.nasa.gov> wrote:
>> 
>>> Dear MITgcm sea ice developers, as requested I am working on switching
>>> verification/seaice_obcs from legacy to devel code.
>>> 
>>> With #undef SEAICE_GROWTH_LEGACY
>>> I get some rather large differences in the output of the 3 experiments:
>>> 
>>> Y Y Y Y> 2< 2  7  5  5  5  9  7  4  1  1  2  2 16  2  3  2  0  2  0  0  0  4  3  3 FAIL  seaice_obcs
>>> Y Y Y Y> 2< 2  7  5  4  5  9  7  4  1  1  3  2 16  1  3  2  0  2  0  0  0  3  3  3 FAIL  seaice_obcs.seaiceSponge
>>> Y Y Y Y> 3< 2  7  5  5  5 10  7  4  2  1  3  3  1  3  3  3  0  2  0  0  0  4  3  3 FAIL  seaice_obcs.tides
>>> 
>>> I have traced this difference back to large differences in "AREA" between legacy and devel branches.
>>> In attached figure I plot AREA, HEFF, and Qsw after 6 model time steps for the legacy
>>> and devel branches an for the difference.
>>> Note that in region of very thin ice (lower right quadrant of panels),
>>> the legacy code gives ~100% ice cover, while the devel code give ~0% ice cover.
>>> This has big consequence for shortwave radiation.
>>> 
>>> I have following questions:
>>> 
>>> - Do you know what is causing this difference?
>>> 
>>> - Are there compile-time or run-time flag options that can reduce this difference?
>>> 
>>> - Shall we just check in the new output.txt as is?
>>> For the things that are being tested in seaice_obcs, this difference is probably not important,
>>> and the devel treatment is probably more realistic in terms of shortwave forcing.
>>> 
>>> Dimitris Menemenlis
>>> 
>>> <legacy.jpeg>
>>> _______________________________________________
>>> 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