<div dir="ltr"><div dir="ltr">Hi Martin and J-M:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I don’t understand, why this is necessary. The temperature/salinity forcing is computed based on t/sLoc, why does that violate salt conservation?<br></blockquote><div><br></div><div>I may have made a mistake but I am fairly confident that t/sLoc should not be used to evaluate T/S fluxes.</div><div><br></div><div>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,</div><div><br></div><div>d/dt [ \int_{z_b}^zi S dz ] = 0.</div><div><br></div><div>At the same time, zi is changing in time:</div><div><br></div><div>d/dt (zi) = -q/rho0</div><div><br></div><div>where q is fw flux due to melt and rho0 is rho_const. Thus by the leibniz rule:</div><div><br></div><div>q S(zi) / rho0 =
\int_{z_b}^zi (dS/dt) dz.</div><div><br></div><div>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.</div><div><br></div><div>With shelficeConserve=.true. and ISOMIP_TD not allowed, shelficeForcingS (as of now) is equivalent to</div><div><br></div><div> q sLoc / rho0 <br></div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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:</div><div><br></div><div>1)
shelficeBoundaryLayer=.false., code unchanged aside from the IF block in shelfice_forcing_surf.F</div><div>2)
shelficeBoundaryLayer=.true., code unchanged aside from the IF block in shelfice_forcing_surf.F
</div><div>3)
shelficeBoundaryLayer=.true., definition of shelficeForcingS modified as described above</div><div><br></div><div>The code and input are here: <a href="https://www.geos.ed.ac.uk/~dgoldber/shelficeBLrealFWflux/input_code.tgz">https://www.geos.ed.ac.uk/~dgoldber/shelficeBLrealFWflux/input_code.tgz</a></div><div>note the modified shelfice_thermodynamics.F has a "_mod" extension. </div><div><br></div><div>The results for integrated salt can be seen here: <a href="https://www.geos.ed.ac.uk/~dgoldber/shelficeBLrealFWflux/saltplot.png">https://www.geos.ed.ac.uk/~dgoldber/shelficeBLrealFWflux/saltplot.png</a><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>Thanks for reading. If i am incorrect here please let me know!</div><div><br></div><div>Dan</div><div><br></div><div><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Martin<br>
<br>
> On 31. Aug 2019, at 20:21, Daniel Goldberg <<a href="mailto:dngoldberg@gmail.com" target="_blank">dngoldberg@gmail.com</a>> wrote:<br>
> <br>
> Hi J-M and Martin<br>
> <br>
> I should probably say something about (2) and (4) (which are somewhat overlapping, from what i understand).<br>
> <br>
> 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. <br>
> <br>
> The other change to which I think J-M is referring to in (4) is at line 641 of shelfice_thermodynamics<br>
> <a href="https://github.com/dngoldberg/MITgcm/blob/branch_remeshing/pkg/shelfice/shelfice_thermodynamics.F" rel="noreferrer" target="_blank">https://github.com/dngoldberg/MITgcm/blob/branch_remeshing/pkg/shelfice/shelfice_thermodynamics.F</a><br>
> 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" rel="noreferrer" 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 <br>
> <br>
> shelficeBoundaryLayer=.true., <br>
> useRealFreshWaterFlux=.true.,<br>
> SHELFICErealFWflux=.true., (new parameter in P/R)<br>
> <br>
> Dan<br>
> <br>
> On Fri, Aug 30, 2019 at 12:57 AM Jean-Michel Campin <<a href="mailto:jmc@mit.edu" target="_blank">jmc@mit.edu</a>> wrote:<br>
> 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>
> _______________________________________________<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>
<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></div>