[MITgcm-devel] upcoming changes in seaice_growth.F

Gael Forget gforget at MIT.EDU
Wed Jun 1 15:26:39 EDT 2011


Ian,

> Better would be to use two different variables,...

I would prefer we stick to one areamin parameter. I don't see 
the need to get too fency with those ad-hoc capping constants and I 
would rather not see them proliferate. (In fact it puzzles me that we
have spent so much time and energy discussing those already.)

Setting two different constants, with areaMin> area_reg, would 
imply that area_reg is in effect replaced with areaMin. But this would
not be the case if areaMin<area_reg. So now we would need more logic in 
readparams for this to become any clearer to the user. I don't advocate this.

Plus I do interpretet areamin the same way in both cases. It is just
that if ALLOW_PRECLUDE_INFINTESIMAL_AREA is defined, 
then areamin is actually enforced on the 'area' variable itself.
To make this logic more evident to the user, it would seem sufficient 
to replace the ALLOW_PRECLUDE_INFINTESIMAL_AREA 
name with SEAICE_ENFORCE_AREAMIN. Makes sense?

> I tested values between 0.05 and 1x10^-5 and everything was stable in the 1D_ocean_ice verification setup over 11,000 time steps.  
Good. Assuming you want to make areaMin=1x10^-5 the default for 
the EVOLUTION branch (leaving it at 0.15 by default in LEGACY case)
I would just ask you to check how it affects global_cs32x15 too (and
of course it should not affect the legacy results).

> Also, since we are now regularizing heffActual in seaice_growth, there is now no reason for the following lines in "evolution" branch of seaice_solve4temp.F:
> 
> C     Set a mininum sea ice thickness of 5 cm to bound
> C     the magnitude of conductive heat fluxes.
>         hice_tmp = max(HICE_ACTUAL(I,J),5.D-2)
> 
> Including the above probably breaks some sensitivity.
Good point. If I am not mistaken, this was never active, even in the 
legacy branch, since the hiceMin default was 0.05 too. Just double 
check that the lab_sea (and the other legacy exps) results don't 
change before you remove this.

Cheers,
Gael





More information about the MITgcm-devel mailing list