[MITgcm-devel] conservation // sublimation

Mon Jun 27 09:22:07 EDT 2011

Ian,

since we agreed that, regardless of your upcoming apriori fix, we 
need to do something about the r_FWbySublim pathological case
aposteriori, I proceeded and included the fix I had proposed at 
the start of this thread.

In second thought, the type of approach Martin had taken (applying the 
residual fresh water flux as evap -- as an aposteiori fix) makes more sense
than an 'if r_FWbySublim > 0 then stop' for several reasons (e.g. why stop 
since we dont need to?). So I followed that road, and completed it properly.

With regard to your upcoming apriori fix via seaice_solve4temp, 
this does not change anything, except that you dont 
have to worry about adding an aposteriori test anymore.

Cheers,
Gael

On Jun 21, 2011, at 12:17 PM, Ian Fenty wrote:

> Gael,
> Our thinking on the subject is almost identical.  In fact, the trial version I gave Martin had multicategory support and an almost identical posteriori test.  I did overlook legacy solve4temp support, however.  I'll commit following JM's checkpoint.
> -Ian
> 
> On 6/21/2011 8:12 AM, Gael Forget wrote:
>> 
>> Hi Ian,
>> 
>> thanks for taking charge of this. Your approach sounds fine.
>> You probably thought it through already, but I would like
>> to raise two issues before you proceed with the check-in.
>> 
>> The a posteriori fixes (the one in line with Martin's code that
>> I had annotated, and the other one that I would have argued for) would have
>> been adequate with&without SEAICE_MULTICATEGORY, with&without
>> SEAICE_SOLVE4TEMP_LEGACY. Please make sure your fix does too.
>> 
>> Also, in the a priori fix approach (via solve4temp, as you implemented) I see how 
>> things could go wrong in the future. To remove the risk of the problem re-appearing
>> and going undetected again, we now need an a posteriori test in seaice_growth.F.
>> Something like "if r_FWbySublim<>0 then print_error and stop" right after the 
>> sublimation term has been applied. It is probably not great for vectorization,
>> but safety should be the highest priority. So please add one such test.
>> 
>> Cheers,
>> Gael
>> 
>> On Jun 20, 2011, at 7:40 PM, Ian Fenty wrote:
>> 
>>> 
>>> Martin,
>>> 
>>> On 6/17/2011 3:56 PM, Martin Losch wrote:
>>>> Hi there,
>>>> 
>>>> it looks like, Ian's "crack" is really fixing the heat conservation problem.
>>>> 
>>>> Further I like the conceptual idea: you cannot not sublimate more mass than there is.
>>>> 
>>>> I completely vote for this version.
>>>> 
>>>> Now, what does the adjoint think of this?
>>>> 
>>> 
>>> I tested today.  The adjoint is stable when sublimation is treated with my fix (it may have been stable with the other method but I didn't look).  Moreover, including sublimation in the adjoint modifies the dJ/dAQH in a perfectly interpretable way.  Basically, the greater the AQH, the lower the latent heat flux/sublimation/mass loss, the greater the ice concentrations at the end of the simulation.
>>> 
>>> So.  That's two votes yes and an unknown number of votes abstaining.  I put it my fix tomorrow unless there is objection.
>>> 
>>> -Ian
>>> 
>>>> Martin
>>>> 
>>>> On Jun 17, 2011, at 11:06 AM, Ian Fenty wrote:
>>>> 
>>>>> Ice-people,
>>>>> 
>>>>> After discussing with Martin, I took a crack at fixing the non-conservation bug that Gael found in the sublimation code.  The approach I took, which works and is physically sound, is to cap the latent heat flux over the ice in solve4temp so that sublimation cannot remove more than the total mass of snow and ice present over a time step.
>>>>> 
>>>>> A maximum latent heat flux (F_lh_max) is calculated in seaice_growth using the true (not regularized) ice and snow thickness and passed as an argument to solve4temp.  In the Newton-Rhapson loop, if F_lh is capped, the derivative of F_lh with respect to tsurfLoc is set to zero so that both numerical convergence and energy conservation are achieved.
>>>>> 
>>>>> #ifdef SEAICE_ADD_SUBLIMATION_TO_FWBUDGET
>>>>> c     if the latent heat flux implied by tsurfLoc exceeds
>>>>> c     F_lh_max, cap F_lh and decouple the flux magnitude from TICE
>>>>>          if (F_lh(I,J) .GT. F_lh_max(I,J)) THEN
>>>>>             F_lh(I,J)  = F_lh_max(I,J)
>>>>>             dqhice_dTice = ZERO
>>>>>          endif
>>>>> #endif
>>>>> 
>>>>> In addition, the order in which thickness tendency terms are applied in seaice_growth must be changed such that loss of ice and snow by sublimation occurs before ice-ocean melting (if ice and snow are removed by ice-ocean fluxes prior to sublimation we can end up with nonzero r_FWbySublim).
>>>>> 
>>>>> Unlike other ice fluxes, the latent heat flux does actually have an upper bound which we simply overlooked in the past (which was a good approximation being that actual latent heat fluxes<<  maximum latent heat fluxes).  By bounding F_lh and switching the order of the d_HEFF operations, we are ensured no latent heat flux residuals and therefore no need for complicated retroactive accounting of energy and freshwater fluxes in QNET and EmPmR.
>>>>> 
>>>>> Comments?
>>>>> 
>>>>> -Ian
>>>>> 
>>>>> 
>>>>> On Jun 7, 2011, at 9:29 PM, Gael Forget wrote:
>>>>> 
>>>>>> Hi Martin et al.,
>>>>>> 
>>>>>> as you may have notice, I did a slight re-organization of the
>>>>>> SEAICE_ADD_SUBLIMATION_TO_FWBUDGET code.
>>>>>> 
>>>>>> The reason why I did this now is that, once we double check it,
>>>>>> I think it should become the default for the EVOLUTION branch (i.e.
>>>>>> I would replace #ifdef SEAICE_ADD_SUBLIMATION_TO_FWBUDGET
>>>>>> with a simple #ifndef SEAICE_GROWTH_LEGACY) and then
>>>>>> include it in the seaice tracer stuff (seaice_tracer_phys.F).
>>>>>> 
>>>>>> I tested the changes with global_ocean.cs32x15, after adding
>>>>>> SEAICE_ADD_SUBLIMATION_TO_FWBUDGET, over one year.
>>>>>> I checked that the experiment thus tested all of the 'if ...' blocs, and it believe it
>>>>>> did. Then I checked that the results remained identical as I edited the code,
>>>>>> which they did. So I am pretty confident I did not change a thing. Am I mistaken?
>>>>>> 
>>>>>> However, one point got my attention, which I think is a bug that is likely to break
>>>>>> conservation. Indeed in the case when the pre-determined sublimation increment goes
>>>>>> beyond all of the ice/snow that is present, we take the rest of a_FWbySublim (now called
>>>>>> r_FWbySublim in analogy with the rest of the code) form the ocean, consistent with
>>>>>> evaporation not sublimation. So I think we need to do something about the different latent
>>>>>> heats. It took me a while, and I had to ask for Jean-Michel's help, but I think we figured
>>>>>> the correct bug fix.  I wrote it down as a comment (line 1499 to 1503).
>>>>>> 
>>>>>> What do you think?
>>>>>> 
>>>>>> Cheers,
>>>>>> Gael
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>> 
>> 
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20110627/cc9edbcc/attachment-0001.htm>