[MITgcm-devel] question about pkg/shelfice

[Martin Losch]

Hi Jean-Michel and Dan,

sorry for the silence.
A lot of this is not very clear to me either.

I think:

1) the stop in SHELFICEconserve with useISOMIPTD is not necessary, cannot remember, why it is there. From the history (the check was there before the cFac code with ISOMIPTD) I guess I forgot to remove the check. What should we do now? I think we can keep it as it is and remove the check (preferred option), but we can also remove the cFac-code from the ISOMIPTD code.
rFac can be 0 or 1 when cFac = 1, as far as I can see, e.g. SHEFLICEconserv = T => cFac = 1, but useRealFreshWaterFlux = F => rFac = 1, so I don’t think that rFac no longer needed. Am I missing something?

2) I am afraid that if SHELFICEBoundaryLayer=T, there’s something wrong, isn’t it? The freshwater contribution shelfIceFreshWaterFlux is not added to EmPmR. Still, the results with or without boundary layer nearly the same in terms of mean sea level (inside and outside the cavity, I am using the diags_stats in isomip.obcs), probably because the thermodynamic freshwater flux is 3 orders of magnitude smaller than the massflux of the ice into the domain, so not a good test. I assume that the corresponding block in shelfice_forcing_surf should be moved outside of the if SHELFICEBoundaryLayer=True block. Or a check in shelfice_check that prevents this combination of flags?

side remark: the "IF ( .NOT.SHELFICEDynMassOnly ) THEN” statement in S/R shelfice_netmassflux_surf could be moved outside the i,j-loops …

3) I am fine with that.

4) The SHELFICEBoundaryLayer was a hack. We can decide not to keep it. If we decide to keep it though, the averaging of velocities should probably be done in a different way: first vertically (as Dan suggests), then square it, then average horizontally.

For the “realFWflux”, you want to have saltFreeze-salt instead of saltFreeze-sloc, right? I think the code in the PR does not do that correctly: it cancels/corrects sloc/tloc multiplied by shelfIceFreshWaterFlux(I,J,bi,bj)*mass2rUnit, but not the part multiplied with shiTransCoeffS/T
I don’t understand, why this is necessary. The temperature/salinity forcing is computed based on t/sLoc, why does that violate salt conservation?

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