<div dir="ltr">Hi J-M and Martin<br><div><br></div><div>I should probably say something about (2) and (4) (which are somewhat overlapping, from what i understand).</div><div><br></div><div>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. </div><div><br></div><div>The other change to which I think J-M is referring to in (4) is at line 641 of shelfice_thermodynamics</div><div><a href="https://github.com/dngoldberg/MITgcm/blob/branch_remeshing/pkg/shelfice/shelfice_thermodynamics.F" target="_blank">https://github.com/dngoldberg/MITgcm/blob/branch_remeshing/pkg/shelfice/shelfice_thermodynamics.F</a><br></div><div>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 <a href="https://mitgcm.readthedocs.io/en/latest/phys_pkgs/shelfice.html#equation-jenkinsbc" target="_blank">https://mitgcm.readthedocs.io/en/latest/phys_pkgs/shelfice.html#equation-jenkinsbc</a> 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 </div><div><br></div><div>shelficeBoundaryLayer=.true., </div><div>useRealFreshWaterFlux=.true.,<br>SHELFICErealFWflux=.true., (new parameter in P/R)</div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 30, 2019 at 12:57 AM Jean-Michel Campin <<a href="mailto:jmc@mit.edu">jmc@mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Martin,<br>
<br>
I was looking at pkg/shelfice code, and have few questions that came up:<br>
<br>
1) From shelfice_check.F, seems that I cannot use SHELFICEconserve with useISOMIPTD<br>
but in shelfice_thermodynamics.F, in the "useISOMIPTD" block, I see some cFac there<br>
(lines 421 & 425) that could safely be removed (cFac is always = 0 if useISOMIPTD=T), <br>
which means "rFac" is no longer needed neither. Is it right ?<br>
<br>
2) The melting from ice-shelf contributes to sea-level variations only<br>
if useRealFreshWaterFlux=T, (logical and expected) AND if SHELFICEBoundaryLayer=F<br>
(see shelfice_forcing_surf.F).<br>
Now regarding the recently merged PR #251 (obcs_balance_surface), it's not very clear<br>
to me what is done regarding pkg/shelfice contribution:<br>
a) with SHELFICEBoundaryLayer=F<br>
The comments within S/R SHELFICE_NETMASSFLUX_SURF, in file: <br>
in file: shelfice_step_icemass.F, lines 185-189, describe accurately the balancing<br>
correction.<br>
b) with SHELFICEBoundaryLayer=T<br>
Things are less clear here, but I don't have the impression that it's not right,<br>
just not clear. May be we should add some documentation/comments fro this case ?<br>
<br>
3) Could we try to change all the secondary isomip test to use SHELFICEBoundaryLayer=F<br>
(I am fine with keeping SHELFICEBoundaryLayer in the primary one and, for now, <br>
the adjoint tests) ? I changed isomip.htd a while ago but no other have been switched <br>
since and the new ones (isomip.obcs and Dan's shelfice_remeshing) are still using<br>
SHELFICEBoundaryLayer.<br>
<br>
4) This bring me to Dan's modifs (within PR #124, "branch_remeshing"):<br>
Did you look at the 2 modifications/additions to pkg/shelfice that are not part of the<br>
remeshing, i.e., under #ifdef SHI_USTAR_TOPDR and when new param SHELFICErealFWflux=T ?<br>
Both are addressing issue within SHELFICEBoundaryLayer code (a bit of a hack to start <br>
with) but the SHELFICEBoundaryLayer looks even more like a hack on a hack.<br>
<br>
Let us now what your thought are.<br>
Cheers,<br>
Jean-Michel<br>
_______________________________________________<br>
MITgcm-devel mailing list<br>
<a href="mailto:MITgcm-devel@mitgcm.org" target="_blank">MITgcm-devel@mitgcm.org</a><br>
<a href="http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel" rel="noreferrer" target="_blank">http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel</a><br>
</blockquote></div>