[MITgcm-devel] conservation // sublimation

Ian Fenty ifenty at gmail.com
Mon Jun 27 12:53:18 EDT 2011 

Gael,

I don't know about the fix you put in but I think that you should check 
with Martin to see if his conservation tests pass with it alone.  
Conservation was broken with the hack/fix that was in before which was 
what motivated me to rewrite the flux treatment in the first place.

Anyway, I'm all for keeping an a posterior treatment (even though it 
won't do anything) because after spending too much time with the LEGACY 
solve4temp I decided that it was too much of a pain to try to cap the 
latent heat flux from within all of those A1, A2, and A3 intermediate 
variables.   So, I'm applying my fix to the EVOLUTION seaice_solve4temp 
where I cleanly treat F_lh.

A cap on the latent heat flux wasn't a part of the LEGACY experience 
anyhow so no one's results will change.

-Ian


On 6/27/2011 6:22 AM, Gael Forget wrote:
> 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 <mailto:MITgcm-devel at mitgcm.org>
>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>>>>>
>>>>> _______________________________________________
>>>>> 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 <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
>>
>> _______________________________________________
>> 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/20110627/d1a02754/attachment-0001.htm>

More information about the MITgcm-devel mailing list