[MITgcm-devel] question about pkg/shelfice

Fri Sep 20 11:08:18 EDT 2019

Hi Dan and Martin,

I got distracted with other things but will get back to this soon.
I the mean time, I am also looking at "improving" the testing part
of remeshing feature within the shelfice_remeshing (new) experiment,
to make sure that we indeed "test" the new pieces of code.
More to come.

Cheers,
Jean-Michel

On Fri, Sep 13, 2019 at 02:58:43PM +0100, Daniel Goldberg wrote:
> 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
> >

> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel