[MITgcm-devel] upcoming changes in seaice_growth.F

[Gael Forget]

Ian,

since you really want to have two different run time parameters, 
let's go for it. Also the sqrt formula makes sense for the adjoint.

Before you check the code in cvs, accomodate me, and change two things though:
(1) make the default for area_floor and area_reg be the same and equal to SIeps (10^-5).
(2) make the 'FLOOR bloc' active by default. More explicitely, bracket it with 
#ifndef DISABLE_AREA_FLOOR instead of #ifdef SEAICE_ENFORCE_FLOOR_ON_AREA

Your concern originally was to reduce the threshold to a small number. You convinced me from 
the start that 0.15 was a priori way too large, which was likely affecting the solutions beyond 
pathological cases. You then told me that you have tested 10^-5 and it turned out fine for 
the adjoint, so I assume you will use 10^-5. No need to hard-code it again btw (SIeps=10^-5).

I want to have the 'FLOOR bloc' active by default (defined and with a 10^-5 threshold)
because I think it makes no physical sense to allow HEFF>0 and AREA=0
which is bound to happen occasionally with certain advection schemes. I think
that the model should take care of such pathological cases by default. The average 
user should not have to edit both SEAICE_OPTIONS.h and data.seaice to do this.
You are a very advanced user obviously; you know those epsilons exist for a start.
You will have to tell me one day why you really want area_floor=0 in your runs, but 
I hope you will at least agree that area_floor=10^-5 is basically harmless.

Thanks in advance for checking this in cvs.

Cheers,
Gael


On Jun 15, 2011, at 2:09 PM, 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