[MITgcm-devel] question about pkg/shelfice

[Daniel Goldberg]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-devel/attachments/20190831/73602adf/attachment.html>