[MITgcm-devel] upcoming changes in seaice_growth.F
Ian Fenty
ifenty at gmail.com
Thu May 26 23:03:36 EDT 2011
Gael,
> thanks for confirming that hiceMin=0.05 is fine for the adjoint.
> I will wait until tomorrow to proceed because Jean Michel
> has other changes underway.
Yes, when implemented as:
heff_star = sqrt(HEFF * HEFF + hiceMin*hiceMin)
heffActual = heff_star / area_star
then the minimum possible value of the "actual ice thickness" for the
purposes of the effective conductivty calculation is then
hiceMin/area_star, i.e. hiceMin when AREA = 1.
I'm emphasizing that we should still use the construct:
d_AREAbyATM(i,J) = HALF*tmpscal1*AREApreTH(I,J) / heff_star(I,J)
and *not*
d_AREAbyATM(i,J) = HALF*tmpscal1*heffActual
because there is no reason to put a minimum bound on AREA in the above
calculation; AREA can be arbitrarily small. It's a small HEFF that we
need to avoid there.
>
> I will add a CPP option around the bloc of code that you dislike,
> and will use your advised sqrt(AREA * AREA + areaMin * areaMin)
> in computing actual thicknesses.
>
> I have one question though. I thought you wanted something like
> 10^-5 for the areaMin default because 0.15 was way too large.
> Do you now suggest 0.1 is best?
What I tried to convey was that for only the purpose of calculating
heffActual, limiting AREA (the denominator) to 0.1 is fine and that I
saw no reason to impose a minimum nonzero value on it otherwise.
I will just send you a copy of seaice_growth.F with the changes I
suggested in my last message so that you can see what I have in mind.
-Ian
Cheers,
> Gael
>
> On May 26, 2011, at 6:00 PM, Ian Fenty wrote:
>
>>
>> On May 25, 2011, at 12:40 PM, Gael Forget wrote:
>>
>>> Hi Ian and co.,
>>>
>>> below I report what Ian and I discussed at the ECCO2 meeting,
>>> which I just got started with seaice_growth.F rev.121 (see below).
>>>
>>> So, to complete the 'merging' process, we planned the following:
>>> 1) a few changes in the EVOLUTION branch
>>> 1.1) reduce the areaMin default
>>> 1.2) always include a_QSWbyATM_cover in QNET
>>> 1.3) use Ian's heff_star sqrt formula in heffActual
>>> 1.4) add the Winton (?) formula for flooding
>>> 1.5) add a check for the areaMax range
>>
>>> 2) remove code duplicates and restore the integrity of the two
>>> branches structure
>>> (EVOLUTION: with Ian's codes // LEGACY: for backward compatibilty)
>>
>> The default non-legacy behavior w.r.t. the thickening of existing ice
>> is now the same as what I put in with:
>> #define FENTY_DELTA_HEFF_OPEN_WATER_FLUXES
>>
>> and w.r.t. the behavior of open water air-sea flux
>> divergence/convergence, the following are now equivalent:
>> #SEAICE_DO_OPEN_WATER_GROWTH with #FENTY_DELTA_HEFF_OPEN_WATER_FLUXES
>> #SEAICE_DO_OPEN_WATER_MELT with #FENTY_OPEN_WATER_FLUXES_MELT ICE
>>
>> so it seems that the following can be safely removed:
>> #FENTY_DELTA_HEFF_OPEN_WATER_FLUXES
>> #FENTY_OPEN_WATER_FLUXES_MELT_ICE
>>
>> which you actually did it in 1.121.
>>
>>
>>> 3) add somewhere in the code (SEAICE_OPTIONS.h or seaice_check.F may be)
>>> the combination of CPP options that is advised for adjoint runs.
>>>
>>> With regard to 1.2) I felt it was best not to do it in the LEGACY
>>> branch,
>>> since it would affect backward reproductibility. Makes sense, right?
>>
>> That makes sense to me.
>>
>>> With regard to 1.4) I argued at the time that we may as well replace the
>>> flooding formula in the EVOLUTION branch (only). But may be we should
>>> keep both and add a CPP option. Opinions?
>>
>> I think that since the non-evolution branch is kept around so that
>> some old results can be reproduced it is best to leave what is there
>> alone.
>>
>>>
>>> With regard to 1.1) Ian argued at the time that we don't need
>>> areaMin (old A22) to be a run time parameter. Opinions?
>>
>>> In any case we would leave the 0.15 default for the LEGACY branch.
>>> For the EVOLUTION branch we talked about 10^-5 if I remember right.
>>
>> I still don't understand why we would ever use areaMin > 0 and not
>> areaMin = 0. Why do we need to prevent the model from generating
>> arbitrarily small amounts of AREA? Maybe I'm missing something
>> really obvious.
>>
>> The only place where a minimum non-zero value of AREA might be useful
>> is when we are calculating the "actual" ice thickness (heffActual =
>> HEFF/AREA) for the heat conduction calculation. I suggest that we
>> simply maintain a lower bound of AREA > 0 to keep things physical
>> when HEFF > 0 and for the calculation of heffActual (and hsnowActual)
>> to do something like:
>>
>> area_star = sqrt(AREA * AREA + 0.1 * 0.1)
>> heff_star = sqrt(HEFFpreTH * HEFFpreTH + 0.05 * 0.05)
>>
>> heffActual = heff_star / area_star
>> hsnowActual = HSNWpreTH / area_star
>>
>> The above caps the max value of heffActual (for the purposes of the
>> heat conduction only) to 10*HEFF and the minimum value of 0.05 m and
>> maintains smooth gradients with respect to AREA and HEFF as AREA,
>> HEFF --> 0. For actual ice thicknesses of >= 10 m, conductive fluxes
>> are effectively zero anyway so we don't need to use a number smaller
>> than 0.01 _d 0 in the area_star calculation.
>>
>> And in case it isn't obvious, a lower bound on heffActual is required
>> because it is used in a denominator in seaice_solve4temp:
>>
>> effConduct(I,J) = XKI * XKS /
>> & (XKS * HICE_ACTUAL(I,J) + XKI * HSNOW_ACTUAL(I,J))
>>
>> I experimented with the heff_star and area_star formulations written
>> above already in my local version and everything worked very well.
>> So I propose we do implement that.
>>
>>>
>>> With regard to 2) I left the FENTY_AREA_EXPANSION_CONTRACTION part
>>> for later,
>>> since 1.3) is a pre-requisite. Ian, you were going to check that
>>> using 0.05^2 rather
>>> than 0.1^2 in the heff_star sqrt formula is fine in adjoint mode. Is it?
>>
>> I checked that 0.05 m works just as well in the adjoint as 0.1 m in
>> the contraction bits. Because it is the denominator which we have to
>> prevent from getting arbitrarily small to keep gradients bounded, we
>> can keep the calculation in the following form:
>>
>> d_AREAbyATM(i,J) = HALF*tmpscal1*AREApreTH(I,J) / heff_star(I,J)
>>
>> Reactions?
>>
>> -Ian
>>
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20110526/23476cf5/attachment.htm>
More information about the MITgcm-devel
mailing list