[MITgcm-devel] conservation // sublimation
Martin Losch
Martin.Losch at awi.de
Tue Feb 1 11:01:27 EST 2011
Hi Gael,
I cannot remember exactly how far I got, but it looks like everything was strickly conserving for both "legacy" and new code
as long as the new flag
#undef SEAICE_ADD_SUBLIMATION_TO_FWBUDGET
is undefined. When SEAICE_ADD_SUBLIMATION_TO_FWBUDGET is defined, only the legacy code conserved heat and fresh water, but in the new code heat is not conserved by a big deal.
I have put my configuration (code and input with an updated check_conserve.m) as here: faulks.csail.mit.edu:~mlosch/cs32conserve_20110201.tgz
I believe it's not very different from the previous version (cs32conserve_20101213.tgz). Maybe you can reproduce my findings.
I am still struggling to close the heat budget within the ice and Jean-Michel has sent me (and the list) a long explanation how do things, but I still need to understand, how to realize, what I think I now understand, in FORTRAN code. Maybe you are faster.
Martin
On Feb 1, 2011, at 2:22 PM, Gael Forget wrote:
> Hi Martin,
>
> cool. I am looking forward to your update.
>
> Jean-Michel helped me locate the cs32conserve_20101213.tgz you had
> last referred him to. I started playing with the check_conserve.m script and
> setup that are inside, which seemed to work. I have not tried global_ocea.cs32x15 though.
>
> Cheers,
> Gael
>
>
> On Feb 1, 2011, at 4:29 AM, Martin Losch wrote:
>
>> Hi Gael,
>>
>> so far I have only put my code/input directories including a matlab script somewhere on faulks for Jean-Michel to check, but since I got it back from him (corrected) I have not yet made available a new version. I was distracted from this issue for quite a while now. Will go back and give make the configuration available, but maybe not check it in. As far as I remember, the status was that I could no make everything conserve simulatenously, and that I probably misunderstood some of the latent heat flux issues. I'll have another look into this today and will send you the files as soon as I remember the exact problems I had.
>>
>> Martin
>>
>> On Jan 31, 2011, at 4:57 PM, Gael Forget wrote:
>>
>>> Hello Martin,
>>>
>>> have you posted material (e.g. matlab code and data.diagnostics)
>>> regarding conservation somewhere? Could we consolidate
>>> e.g. verification/global_ocea.cs32x15/input.seaice
>>> with a list of diagnostics that give a close budget?
>>>
>>> Ultimately I would like to check my own set-up in this respect.
>>> Could you provide guidelines (e.g. how to get started; is it easier
>>> to omit some pkgs or options? ...) and/or matlab routines that
>>> you may have written to do do conservation checks.
>>>
>>> May be it is already in contrib and I missed it. If this is the
>>> case can you remind me where it would be.
>>>
>>> Cheers,
>>> Gael
>>>
>>> On Dec 14, 2010, at 6:14 AM, Martin Losch wrote:
>>>
>>>> Hi Jean-Michel, Gael,
>>>>
>>>> excuse me for being such a brainless brick. I know think that I understand how things work (and that's more inline with what you have been trying to tell me):
>>>> 1. The net atmospheric heat flux (positive downward), including the latent heat of sublimation, is used to melt ice (if > 0).
>>>> 2. In addition, the latent heat flux of sublimation/resublimation removes/adds mass to the surface. It is this latter part that is missing in the current budget (as Jean-Michel keeps trying to tell me).
>>>>
>>>> I have now managed to implement this fresh water flux (in solve4temp, passed to seaice_growth, where it is converted, added, diagnosed, whatever). The volume budget is closed to 1e-16, unfortunately the heat bugdet isn't, still looking.
>>>>
>>>> Martin
>>>>
>>>> On Dec 14, 2010, at 3:31 AM, Jean-Michel Campin wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> I am still confused.
>>>>>
>>>>> Is it a question related to the latent heat of sublimation (Lsub)
>>>>> versus the latent heat of vaporisation (Lvap) ?
>>>>> Lsub = Lvap + Lf (with Lf = latent heat of fusion)
>>>>>
>>>>> And yes indeed, it should be more consistent to have,
>>>>> in the diagnostics SIatmQnt, the latent heat flux computed
>>>>> with Lvap rather than with Lsub (it's an issue of the reference
>>>>> level of energy for water, and the most convenient convention
>>>>> is to take liquid water at 0^oC).
>>>>>
>>>>> I think it is what we have in thsice_solve4temp.F:
>>>>> 82 C flxAtm :: net flux of energy from the atmosphere [W/m2] (+=down)
>>>>> 83 C without snow precip. (energy=0 for liquid water at 0.oC)
>>>>> ...
>>>>> 548 C- Update energy flux to Atmos with other than SW contributions;
>>>>> 549 C use latent heat = Lvap (energy=0 for liq. water at 0.oC)
>>>>> 550 flxAtm(i,j) = flxAtm(i,j) + flxTexSW(i,j)
>>>>> 551 & + dFlxdT(i,j)*dTsrf(i,j) + evpAtm(i,j)*Lfresh
>>>>>
>>>>> Is it what you are refering to ?
>>>>> In what you wrote, you did not make the distinction, so I interpreted
>>>>> it as the full latent heat flux of sublimation (= dM/dt * Lsub)
>>>>>
>>>>> Cheers,
>>>>> Jean-Michel
>>>>>
>>>>> On Mon, Dec 13, 2010 at 09:26:35PM +0100, Martin Losch wrote:
>>>>>> Hi Jean-Michel
>>>>>> On Dec 13, 2010, at 8:50 PM, Jean-Michel Campin wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> Not yet 100% clear to me. But what I would propose (following
>>>>>>> your way) would be:
>>>>>>> 1) to fix the inconsistency (and would prefer to add a
>>>>>>> freshwater flux to the argument list of seaice_solve4temp,
>>>>>>> since this is what is missing and what also need to be
>>>>>>> accounted for in seaice_growth + diagnostics SIatmFW).
>>>>>> Here I disagree. You are normally right about these things, but I do not see how we can get it right if we use the latent heat twice, once as a fresh water flux (passed from solve4temp) and once as part of the net heat flux a_QbyATM_cover (formerly QNETI). I think that the latent heat needs to be used exclusively for sublimation. So either compute freshwater flux from latent heat within solve4temp and pass as an argument, but then the latent heat needs to be removed from the net heat flux, or pass latent heat as an argument, and then we do these things (subtracting latent heat from net heat, convert latent heat to fresh water flux) within growth. Or am I totally wrong? (Gael seems to think so)
>>>>>>> 2) Once this is done, could check where we are in term of heat
>>>>>>> flux (but my impression was that it's OK as it is now).
>>>>>>>
>>>>>>> A side question:
>>>>>>> Do we prefer to fix this inconsistency now (before Matt and
>>>>>>> others have a chance to check that the "evolution" version is
>>>>>>> producing similar results as the pkg/seaice _if version),
>>>>>>> or should we allow a way (run time parameter at least) to keep
>>>>>>> the inconsistent option for a while ?
>>>>>> Not sure how quickly we can do that. Fixing this issue is less important for "uncoupled" simulations. Only with a coupled atmosphere this becomes important, right?
>>>>>>
>>>>>> M.
>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jean-Michel
>>>>>>>
>>>>>>> On Mon, Dec 13, 2010 at 03:46:58PM +0100, Martin Losch wrote:
>>>>>>>> Hi Jean-Michel, and Gael,
>>>>>>>> On Dec 10, 2010, at 6:53 PM, Jean-Michel Campin wrote:
>>>>>>>>
>>>>>>>>> Hi Martin and Gael,
>>>>>>>>>
>>>>>>>>> I am not sure I am understanding every thing,
>>>>>>>>> But I will still make few comments.
>>>>>>>>>
>>>>>>>>> 1) Martin: if would be usefull to know which CPP flags you turn on/off
>>>>>>>>> in this legacy/evolution comparison on conservation.
>>>>>>>> These are the differences between the two SEAICE_OPTIONS.h files:
>>>>>>>>> csysm15::run_new> diff ../build/SEAICE_OPTIONS.h ../build_new/SEAICE_OPTIONS.h
>>>>>>>>> 46c46
>>>>>>>>> < #define SEAICE_GROWTH_LEGACY
>>>>>>>>> ---
>>>>>>>>>> #undef SEAICE_GROWTH_LEGACY
>>>>>>>>> 58c59
>>>>>>>>> < #define SEAICE_SOLVE4TEMP_LEGACY
>>>>>>>>> ---
>>>>>>>>>> #undef SEAICE_SOLVE4TEMP_LEGACY
>>>>>>>>
>>>>>>>>> 2) I think it has been discussed previously (I don't remember when)
>>>>>>>>> that sublimation is taken into account when computing (seace_solve4temp)
>>>>>>>>> tsurf and atmos-fluxes, but there is no snow/ice removal due to sublimation.
>>>>>>>>> The diagnostic SIatmFW is consistent with this inconsistency
>>>>>>>>> of seaice_growth (i.e, no eval over sea-ice covered region).
>>>>>>>>> The diagnostic SIatmQnt seems right to me (easier to follow in the
>>>>>>>>> evolution branch).
>>>>>>>>> Is it right or has something changed in one of the branch (evolution/legacy)?
>>>>>>>> Some of this confusion can be attributed to my not quite understanding the issues and blurting out unreflected statements. As I see it now, the latent heat of sublimation is added to the net heat flux in seaice_solve4temp. This net heat (a_QbyATM_cover) is then used to melt the ice in seaice_growth, this includes the contribution of the latent heat. If you think of sublimation as melting that followed immediately by evaporation, then we are basically not taking into account the evaporation part but use all heat to just melt. But this is done consistently within the model, so there is conservation of FW and heat.
>>>>>>>>>
>>>>>>>>> 3) if point 2 is still valid, then the question remain: how to get
>>>>>>>>> a meaningfull heat budget with a sublimation term which is present
>>>>>>>>> (for tsurf and heat fluxes) and missing (in FW) ?
>>>>>>>> I think, and that's what I am currently implementing, that we need to pass the latent heat from solve4temp to growth, remove it from the net heat and account for it separately. In thsice, it's done this way (as far as I can see, but I do not see very far in the thsice-package). Currently I am getting a conservation of about 1e-7 relative to the signal (e.g., change of ice volume), I am aiming for 1e-14. Bear with me.
>>>>>>>>>
>>>>>>>>> 4) I have the impression (when I read carefully the previous emails),
>>>>>>>>> that the fact that there is no heat capacity in seaice, thus
>>>>>>>>> with surface atmos flux = conductive flux at seaice base (if tsurf < 0)
>>>>>>>>> or = excess of energy to melt (if tsurf = 0)
>>>>>>>>> is the reason of some confusion.
>>>>>>>>> In fact, what is used, from seaice_solve4temp, in seaice_growth to
>>>>>>>>> grow or melt ice is the conductive-flux / excess of heat.
>>>>>>>>> It just happens that it corresponds also to atmos surf flux, but it's
>>>>>>>>> just because we have a simple seaice model.
>>>>>>>>> Does this make sense ?
>>>>>>>> Yes, that's part of the problem (when trying to understand what's going on in the model).
>>>>>>>>>
>>>>>>>>> Hope I am not increasing the confusion.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Jean-Michel
>>>>>>>>>
>>>>>>>>> On Fri, Dec 10, 2010 at 10:43:51AM -0500, Gael Forget wrote:
>>>>>>>>>>
>>>>>>>>>>> You can use the heat to either melt OR sublimate (melt+evaporate), but not for both. Either process can be done consistently. If you think that sublimation/(melting+evaporation) is faster than meltling+runoff into the ocean then you should use all hl=coeff*(qice-qsat) to sublimate (and saturate the atmosphere). If you melt and put the water into the ocean, you implicitly assume that there is no evaporation (maybe because the atmosphere is already saturated, or the water runs off more quickly). Both is possible, I am not sure what's more realistic, personally I feel it's the sublimation first, then melting.
>>>>>>>>>>
>>>>>>>>>> Jean-Michel will know the correct answer...
>>>>>>>>>>
>>>>>>>>>> I still would think that the missing part is a fresh-water flux (ice -> water vapor)
>>>>>>>>>> that would imply a <0 latent heat storage on the atmosphere side (until it rains),
>>>>>>>>>> to compensate the >0 latent heat storage on the ocn/ice side. In analogy with evap.
>>>>>>>>>> (I am not completely sure I got those signs correctly).
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>
>>>>>> Martin Losch
>>>>>> Martin.Losch at awi.de
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
More information about the MITgcm-devel
mailing list