[MITgcm-devel] another stop in seaice_check: mcPheePiston

Gael Forget gforget at MIT.EDU
Fri Mar 9 12:02:11 EST 2012


Reset rather than stop is fine by me, as long as the model cant start with unsafe values (i.e. reset to 
0. <=  <= 1. for both params  is ALWAYS active) and the reason for the reset is documented enough.

Unlike argued by Dimitris I vote for at least a warning. My reasons : (1) I like to be made aware of it
when I am doing something silly (2) I like to know when the model messes with what I specify in namelists 
(3) it documents/explains the reset (state why it is needed). I wont cry if you remove the warning though.

While you are at it, would you consider preventing SEAICE_mcPheePiston=0.
because this case will let the ocean warm up as much as it wants under ice?

Cheers,
Gael

On Mar 9, 2012, at 10:11 AM, Martin Losch wrote:

> OK, this corresponds to the case of gamma_t < deltaT, which doesn't make much sense, I agree. Couldn't we just have the code reset SEAICE_mcPheePiston to dz/dt (with a warning) rather than stop. I can see myself explaining these new parameters to at least 3 people after I have carelessly advised them to update their code (again), and resetting might be useful in the end.
> 
> Martin
> 
> 
> On Mar 9, 2012, at 3:44 PM, Gael Forget wrote:
> 
>> Hi Martin,
>> unless I am mistaken this a useful stability and sanity requirement. It may be 
>> easiest to see with the corresponding check for SEAICE_frazilFrac (adimensional).
>> Beyond 1. seaice_growth would overshoot the freezing point (go below it in the McPhee case).
>> I suppose < 2. (rather than <=1.) would be enough for strict stability, but I dont see why we would 
>> want to overshoot / bounce around the freezing point (as would happen for 1.< frac < 2. I think). 
>> Cheers,
>> there ;)
>> 
>> 
>> On Mar 9, 2012, at 9:27 AM, Martin Losch wrote:
>> 
>>> Hi there,
>>> 
>>> I just ran across another check that made the model stop in seaice_check:
>>> when the default
>>>    SEAICE_mcPheePiston  =
>>>   &      MCPHEE_TAPER_FAC * STANTON_NUMBER * USTAR_BASE
>>> = 8.4000e-04 m/s
>>> is larger than SEAICE_mcphee_max=dRf(kSurface)/SEAICE_deltaTtherm
>>> the model stops. This happens to me for my very coarse cs32 experiment (basically global_ocean.cs32 with seaice), when I use the default parameters, because in this configuration dz/dt =  50m/86400s = 5.7870e-04 m/s.
>>> 
>>> Is this a useful stop? Why shouldn't mcPheePiston be larger than dz/dt? Please advise and possibly correct seaice_check.F
>>> 
>>> Martin
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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




More information about the MITgcm-devel mailing list