[MITgcm-devel] seaice code beyond checkoint61j blows for ECCO-GODAE

[Martin Losch]

Hong,
I know I keep repeating myself:
unless SEAICE_noslip=.true. (data.seaice), the CPP-flag in  
SEAICE_OPTIONS.h
#define SEAICE_OLD_AND_BAD_DISCRETIZATION
should reproduce your old results if you make sure that parameter have  
the same values (as the defaults have changed), in particular
SEAICE_clipVelocities = .TRUE.,
But this is only true for non lat/lon grids, so for cartesian grids,  
CS-grids and general orthogonal curvilinear grids. Patrick will *not*  
be able to recover old results, even with this CPP-flag, as I fixed  
obvious bugs in the metric terms of the LSR solver.

Patrick, did you really do the earlier ecco-godae runs with these  
parameter settings (in other words you didn't change the then stoopid  
defaults)?
      SEAICEadvSnow = .FALSE.,
      SEAICEadvSalt = .FALSE.,
      SEAICEadvAge  = .FALSE.,
In particular not advecting snow should give you strange snow  
distributions over open water (and thus screwed up radiation  
balances): snow just accumulates and melts according to precipation  
and thermodynamics and the ice moves away beneath it; in a 100y-run I  
was able to accumulate order 100m snow somewhere in the Weddell Sea;  
that was before the advection of snow was even implemented, and how I  
found out about it.

I would be very interested to know if you can run the ecco simulation  
at iteration 0 with the new default code (and be awfully disappointed  
if the even the forward part breaks).
Also, if you have not turned on advection of snow in the runs with the  
pre-checkpoint61j-code, it would be interesting to turn on advection  
of snow in the old code in iteration 73 and see what happens.

Further I found that turning on the flooding algorithm actually does  
stabilize the code, because it removes residual snow if ice is melting  
from below.

What a mess ...

Martin

On Apr 16, 2009, at 9:54 PM, Patrick Heimbach wrote:

>
> Hong,
>
> just f.y.i.,
> a run just completed successfully with latest code
> (as of ~3 days ago), but following settings:
>
> in SEAICE_OPTIONS.h
> #define SEAICE_OLD_AND_BAD_DISCRETIZATION
>
> in data.seaice
>      SEAICEadvSnow = .FALSE.,
>      SEAICEadvSalt = .FALSE.,
>      SEAICEadvAge  = .FALSE.,
>      SEAICE_clipVelocities = .TRUE.,
>
> I'll now try to narrow down which of these is/are the culprits.
>
> Cheers
> -Patrick
>
> On Apr 14, 2009, at 12:47 PM, Patrick Heimbach wrote:
>
>>
>> Hong,
>>
>> (at least) one more thing.
>> The following recommendations for new defaults
>> from tag-index are wrong:
>>  - SEAICE_advSnow = .true. is now the default
>>  - SEAICE_advSalt = .true. is now the default
>>  - SEAICE_advAge  = .true. is now the default
>>  - SEAICE_clipVelocities  = .false. is now the default
>> None of these flags exist in latest code
>> (hence my job on columbia just blew again).
>>
>> Instead, they are called
>>  - SEAICEadvSnow = .true. is now the default
>>  - SEAICEadvSalt = .true. is now the default
>>  - SEAICEadvAge  = .true. is now the default
>>  - SEAICE_clipVelocities  = .false. is now the default
>>
>> -Patrick
>>
>>
>>
>> On Apr 14, 2009, at 12:22 PM, Patrick Heimbach wrote:
>>
>>>
>>> Hong,
>>>
>>> Jean-Michel gave me a few hints on how to restore
>>> previous defaults to remain compatible with checkpoint61j
>>>
>>> As far as I can see most of them are mentioned in Martin's email.
>>> But I think one CPP option is missing:
>>> I now put in SEAICE_OPTIONS.h
>>> #define SEAICE_OLD_AND_BAD_DISCRETIZATION
>>> Not sure which of the changes is the relevant one.
>>> Currently have a job in queue on columbia to find out.
>>>
>>> In the meantime, if you only revert pkg/seaice/
>>> to checkpoint61j then you should be ok.
>>>
>>> The changes to mom_calc_visc.F should be independent and
>>> you can keep those (but also need consistent change to  
>>> the_main_loop.F)
>>>
>>> Good luck!
>>> -Patrick
>>>
>>>
>>>
>>> On Apr 14, 2009, at 12:04 PM, Hong Zhang wrote:
>>>
>>>> On Tue, 2009-04-14 at 03:49 -0700, Martin Losch wrote:
>>>>>> I do not know if Dimitris has gotten around to test this on CS- 
>>>>>> or curvilinear grids.
>>>> Hi
>>>> We also got the problem on CS:
>>>> got all seaice fields NaN both on levl 28 and level 50 config.
>>>> We updated the code on April 7
>>>> and want to fix the potential blowup (sensitivity) on CS-corner
>>>> with Patrick's check-in (see :
>>>>> Modified Files:
>>>>>    mom_calc_visc.F
>>>>> Log Message:
>>>>> Overlaps had been forgotten in calculating ijk keys
>>>>> (spotted by jmc using gfortran with check-bounds)
>>>> Have to revert?
>>>>
>>>> cheers,
>>>> hong
>>>> _______________________________________________
>>>> MITgcm-devel mailing list
>>>> MITgcm-devel at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>
>>> ---
>>> 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
>>
>> ---
>> 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
>
> ---
> 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