[MITgcm-devel] upcoming changes in seaice_growth.F

[Martin Losch]

Hi there,

I agree that areaMin (my creation if I remember right) is not a good name for what it was supposed to do (replace A22). I thinkt that areaMin should be retired and replaced by two variables as Ian suggests, the names that Ian suggests are fine with me.

Martin

On Jun 15, 2011, at 11:09 AM, Ian Fenty wrote:

> Gael,
> 
> Sorry for the lag, but this topic still needs resolution.
> 
>>> (In fact it puzzles me that we have spent so much time and energy discussing those already.)
> 
> I think it's because the old seaice_growth became so convoluted and impossible to understand that we all desperately want to ensure that the new one is as clear and comprehensible as humanly possible.
> 
>>> 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.
> 
> 
> Well, there is nothing fancy about A22.  Whoever gave that poor variable such a bland name was suffering from total imagination failure.  Anyway, you're right that its original value was ad-hoc (0.15). However, it did have one fantastic thing going for it: a simple and unambiguous job of regularization.
> 
> Now, I don't know who is proliferated the fancy ad-hoc capping constant "areaMin" for the new role of putting a floor on allowable AREA.  But A22 and the new "areaMin" are distinct in their purpose and meaning.  We aren't making the code any cleaner or comprehensible by using areaMin to mean two different things.  Obviously we can probably get away with it numerically - both constants being between 0 and 1 and all - but that doesn't make it good coding practice.   
> 
> Consider a variation of what I proposed a few emails ago combined with your last suggestion: 
> 
> C ==================================================
> 
> c  area_floor :: a constant which bounds the minimum allowable AREA when HEFF > 0 when
>                   SEAICE_ENFORCE_FLOOR_ON_AREA is defined
> c  area_reg  :: a constant which regularizes AREA in a smooth way for seaice_solve4temp 
>                   (similar to A22 and areaMin for old-timers)
> c  hice_reg :: a constant which regularizes heffActual in a smooth way for seaice_solve4temp
> 
> 
> #ifdef SEAICE_ENFORCE_FLOOR_ON_AREA
> 
> C set a minimum value for AREA when HEFF > 0  
> C ==================================================
> 
> if (HEFFpreTH .GT. ZERO) then
> AREA = max(area_floor, AREA)
> endif
> 
> #endif /* SEAICE_ENFORCE_FLOOR_ON_AREA */
> 
> 
> C  calculate the actual ice and snow thickness for seaice_solve4temp.F 
> C ==================================================
> 
> if (HEFFpreTH .GT. ZERO) then
>     area_star = sqrt(AREA^2 + area_reg^2)
>     heffActual = sqrt( (HEFF/area_star) ^2 + hice_reg^2)   
>     hsnowActual = hsnow / area_star
> else
>     heffActual = 0. _d 0
>     hsnowActual = 0. _d 0
> endif
> 
> 
> In the above, you can see that we are ensured of a good safe regularization independent of whether #SEAICE_ENFORCE_FLOOR_ON_AREA is defined and the user-specified value of area_floor (area_star will always be >= area_reg).  Indeed, I there is no need for additional logical checks in seaice_readparms for it to work.  
> 
> We can then make area_floor, area_reg, and hice_reg run-time parameters with default values of 0.0, 0.15 (or 1e-5), and 0.05, respectively.  
> 
> Comments?  If there is agreement, I will take care of checking in above changes.
> 
> Cheers,
> Ian
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel