[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