[MITgcm-devel] conservation // sublimation
Jean-Michel Campin
jmc at ocean.mit.edu
Mon Dec 13 21:31:36 EST 2010
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
More information about the MITgcm-devel
mailing list