[MITgcm-devel] question about pkg/shelfice

Fri Sep 13 09:58:43 EDT 2019

Hi Martin and J-M:

>
> I don’t understand, why this is necessary. The temperature/salinity
> forcing is computed based on t/sLoc, why does that violate salt
> conservation?
>

I may have made a mistake but I am fairly confident that t/sLoc should not
be used to evaluate T/S fluxes.

My assumption is that with no other boundary sources than the ice-ocean
interface, if volume change due to melt is accounted for, and ice contains
no salt, the volume-weighted integral of salt should be constant. I
considered a 1-D column model with ice-ocean interface at zi and bathymetry
z_b. In this case,

d/dt [ \int_{z_b}^zi S dz ] = 0.

At the same time, zi is changing in time:

d/dt (zi) = -q/rho0

where q is fw flux due to melt and rho0 is rho_const. Thus by the leibniz
rule:

q S(zi) / rho0 =  \int_{z_b}^zi (dS/dt) dz.

Where S(zi) is the salinity at the top of the column (but not the molecular
value at the ice-ocean interface). The right hand side of this equation is
implemented by updating the tendency in the top cell (kSurfC), if
shelficeBoundaryLayer=.false. If  shelficeBoundaryLayer=.true., then i
think it is still implemented accurately by updating tendencies in the top
two cells -- I will assume this.

With shelficeConserve=.true. and ISOMIP_TD not allowed, shelficeForcingS
(as of now) is equivalent to

 q sLoc / rho0

and, if you believe everything to this point, this is correct in terms of
salt conservation, as long as sLoc = S(kSurfC). BUT with
shelficeBoundaryLayer=.true. this is not the case -- and sLoc must be
replaced by S(zi), regardless of the form used to actually derive q. This
is the change made in my pull request, as long as an additional boolean
parameter is set.

This is what was meant in my previous email: if the shelfice boundary layer
is used, but also the melt rate drives actual volume change through PmE,
then sLoc must be (partially) replaced in the shelficeForcingS. Im sorry if
I was not clear before and I hope you agree.

Of course, one canNOT currently implement volume change as well as
shelficeBoundaryLayer, but this is just because of the placement of an if
clause in shelfice_forcing_surf.F. I have done a column experiment, in
which i modified the IF block so this is possible. I looked at 3 cases:

1)  shelficeBoundaryLayer=.false., code unchanged aside from the IF block
in shelfice_forcing_surf.F
2)  shelficeBoundaryLayer=.true., code unchanged aside from the IF block in
shelfice_forcing_surf.F
3)  shelficeBoundaryLayer=.true., definition of shelficeForcingS modified
as described above

The code and input are here:
https://www.geos.ed.ac.uk/~dgoldber/shelficeBLrealFWflux/input_code.tgz
note the modified shelfice_thermodynamics.F has a "_mod" extension.

The results for integrated salt can be seen here:
https://www.geos.ed.ac.uk/~dgoldber/shelficeBLrealFWflux/saltplot.png
For cases (1) and (3) there is a very small change in salt initially but i
believe this decreases with time step; and it is nowhere near the error in
case (2).  I think a similar argument applies to theta, but the heat budget
is more difficult to check.

I hope this is more clear, and somewhat convincing. The change I made, even
if correct, might be very specific to the set of parameters being used, in
which case, as you mentioned, some validation of the input parameters might
be in order.

Thanks for reading. If i am incorrect here please let me know!

Dan

>
> Martin
>
> > On 31. Aug 2019, at 20:21, Daniel Goldberg <dngoldberg at gmail.com> wrote:
> >
> > Hi J-M and Martin
> >
> > I should probably say something about (2) and (4) (which are somewhat
> overlapping, from what i understand).
> >
> > SHI_USTAR_TOPDR was something that Iwe wrote to address the "stripes" in
> melt rate that appeared when SHELFICEuseGammaFrict=.TRUE. At the time, the
> behaviour seemed to worsen when hFacC(ktop) > 1. We reasoned it might be
> good to first vertically integrate at U,V-points and then horizontally
> average, rather than the other way around, and it seemed to work for the
> cases we tested. I do realise that J-M was working on a more elegant
> solution at the same time, and this might be implemented in the main branch
> now (J-M, i apologise for not keeping up with you on this) -- but we had
> gone too far down the road with Jim's experiments. If the more elegant
> solution also addresses the "stripes" issue with hFacC(ktop) > 1 (it should
> be clear from the verification experiment) then i don't think
> SHI_USTAR_TOPDR is vital, but at the same time it could be included as an
> option? I decided to include it in the pull request just in case.
> >
> > The other change to which I think J-M is referring to in (4) is at line
> 641 of shelfice_thermodynamics
> >
> https://github.com/dngoldberg/MITgcm/blob/branch_remeshing/pkg/shelfice/shelfice_thermodynamics.F
> > To implement synchronous coupling, we need to add fluid through PmE (i
> don't see a better way), but in the main branch this precludes
> shelficeBoundaryLayer, which we definitely wanted to keep to prevent
> overcooling and overfreshening!!! The only adjustment needed is that "X" in
> https://mitgcm.readthedocs.io/en/latest/phys_pkgs/shelfice.html#equation-jenkinsbc
> needs to be theta(ktopc), salt(ktopc), not tLoc and sLoc (they are
> equivalent when shelficeBoundaryLayer=.false.). Using a column model i
> tested that salt is conserved to machine precision with
> >
> > shelficeBoundaryLayer=.true.,
> > useRealFreshWaterFlux=.true.,
> > SHELFICErealFWflux=.true., (new parameter in P/R)
> >
> > Dan
> >
> > On Fri, Aug 30, 2019 at 12:57 AM Jean-Michel Campin <jmc at mit.edu> wrote:
> > Hi Martin,
> >
> > I was looking at pkg/shelfice code, and have few questions that came up:
> >
> > 1) From shelfice_check.F, seems that I cannot use SHELFICEconserve with
> useISOMIPTD
> >  but in shelfice_thermodynamics.F, in the "useISOMIPTD" block, I see
> some cFac there
> >  (lines 421 & 425) that could safely be removed (cFac is always = 0 if
> useISOMIPTD=T),
> >  which means "rFac" is no longer needed neither. Is it right ?
> >
> > 2) The melting from ice-shelf contributes to sea-level variations only
> >   if useRealFreshWaterFlux=T,  (logical and expected) AND if
> SHELFICEBoundaryLayer=F
> >   (see shelfice_forcing_surf.F).
> >   Now regarding the recently merged PR #251 (obcs_balance_surface), it's
> not very clear
> >   to me what is done regarding pkg/shelfice contribution:
> >    a) with SHELFICEBoundaryLayer=F
> >     The comments within S/R SHELFICE_NETMASSFLUX_SURF, in file:
> >     in file: shelfice_step_icemass.F, lines 185-189, describe accurately
> the balancing
> >     correction.
> >    b) with SHELFICEBoundaryLayer=T
> >     Things are less clear here, but I don't have the impression that
> it's not right,
> >     just not clear. May be we should add some documentation/comments fro
> this case ?
> >
> > 3) Could we try to change all the secondary isomip test to use
> SHELFICEBoundaryLayer=F
> >   (I am fine with keeping SHELFICEBoundaryLayer in the primary one and,
> for now,
> >    the adjoint tests) ? I changed isomip.htd a while ago but no other
> have been switched
> >   since and the new ones (isomip.obcs and Dan's shelfice_remeshing) are
> still using
> >   SHELFICEBoundaryLayer.
> >
> > 4) This bring me to Dan's modifs (within PR #124, "branch_remeshing"):
> >  Did you look at the 2 modifications/additions to pkg/shelfice that are
> not part of the
> >  remeshing, i.e., under #ifdef SHI_USTAR_TOPDR and when new param
> SHELFICErealFWflux=T ?
> >  Both are addressing issue within SHELFICEBoundaryLayer code (a bit of a
> hack to start
> >  with) but the SHELFICEBoundaryLayer looks even more like a hack on a
> hack.
> >
> > Let us now what your thought are.
> > Cheers,
> > Jean-Michel
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-devel/attachments/20190913/c41f8747/attachment.html>