[MITgcm-devel] upcoming changes in seaice_growth.F

[Gael Forget]

Good. So I will expect to see the agreed upon check-in.

Regarding Martin's alternative suggestion. The situation we want 
to resolve is heff>0 (or hsnow>0) and area=0, implying h=inf, 
In this case, the instantaneous melting approach seems  less 
natural (setting h to 0 becauce it was inf ??) and more intrusive 
(there is no need to remove the ice) than the reshaping approach 
(setting area to area_floor). So after you check in the modification, 
I suggest and hope we simply close this thread. 

Cheers,
Gael




On Jun 17, 2011, at 2:48 PM, Ian Fenty wrote:

> Gael,
> 
> 
> On Jun 15, 2011, at 4:06 PM, Gael Forget wrote:
> 
>> 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
> 
> NP.
> 
>> 
>> 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 found your new variable SIeps, and 10^-5 does work fine so we'll use it.
> 
>> 
>> 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.
> 
> One day over beer I'll tell you why I really want area_floor = 0.  Although see Martin's email in which he suggests that we should simply kill HEFF in pathological cases where AREA comes back <= 0 from dynamics (like we do to AREA when HEFF comes back <= 0).  If we did that then there is no need to include the "FLOOR bloc" for sanity checking.
> 
> Until then, 10^-5 it is!
> 
> -Ian
> 
> 
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> 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