[MITgcm-devel] Could we split again the merged shelfice+icefront pkg in 2 ?

[Jean-Michel Campin]

Hi,

Have not received much feedback on this message. Will post it as a git-issue
(referencing PR #368) unless someone prefers not too.

Cheers,
Jean-Michel

On Tue, Sep 22, 2020 at 12:09:51AM -0400, Jean-Michel Campin wrote:
> Hi,
> 
> Regarding PR #368 ("Combined package of shelfice and icefront"),
> I am not sure that merging pkg/icefront into pkg/shelfice is the right way to go.
> Instead of simplifying the code and instructions on how to use it, I am concerned it might 
> instead results in 2 versions of icefront (the pkg + the merged in version) and equally
> 2 versions of pkg/shelfice (with or without icefront), and a very confusing "documentation". 
> 
> But let's put on the side the code management problems (e.g., what to do with current
> pkg/icefront if an other version is merged in shelfice ? ) that could always be sorted out 
> in one way or an other and imagine that we have a single pkg that does both: ocean ice-shelf 
> interactions and melting at a glacier terminal edge (icefront): 
> I would seriously consider what would prevent us to split this pkg in 2 parts:
> 1) many users (and many scientific problems) only involve one of the two, with no need
>   to event consider the one other part.
>   a) high-res process studies (for which icefront was developed): in some cases, e.g., 
>     grounded glacier terminating in a fjord, there is not even an ice-shelf ! 
>   b) many set-up that do consider ice-shelf cavity interaction don't need to worry about 
>     melting at the terminal edge of the glacier:
>     - geometry of the ice-shelf: the lateral surface at terminal edge in contact with sea
>       water is so much smaller than the base of the ice-shelf surface.
>     - for an ice point of view the "icefront" melting is generally negligible compared to 
>       calving rate (if I am interested in coupling with ice-sheet/ glacier).
>   c) at high resolution (grid-cell aspect of order 1), in addition to "ice-shelf basal melting" 
>     processes, the icefront part might be considered too.
>     But the "icefront" aspect requires specific parameterizations, e.g., to account for 
>     the effect of surface waves erosion (like in iceberg modeling), that have not much to do 
>     with the ice-cavity.
> 2) This might become the most confusing package, because of the z-coordinate:
>   The base of ice-shelfs are sloping, but the basal surface is generally smooth and
>   except, may be, very close to grounding line, the slope is not that steep.
>   In a z-coordinate model, this slope will be represented with some steps; but these "lateral" 
>   area of contact between ice and sea-water are mostly an artifact of vertical coordinate, and 
>   has not much in common with the vertical wall of ice at the terminal edge of the ice-shelf.
>   Whether or not it is treated as the "icefront" will rise questions and misnderstanding,
>   especially when both processes are deal with in the same package.
>   May be a good place to start if we decide to go for a unique package that does both, 
>   would be to get the documentation sorted out and diagnostics list with description written out.
>   This might help to realize that, may be, splitted in two packages helps.
> 3) coding aspect:
>   Most if not all ocean interactions with the ice-shelf basal surface are 2-D, and can
>   be considered as "surface processes" (e.g., realFreshWaterFlux) whereas the icefront
>   interact with a significant portion of few water columns. So the implementation are
>   a bit different as well as limitations (config_check.F) and diagnostics.
>   The advantages of having two packages is that anywhere in the code, without adding other
>   included files, we are able to know if one or the other or both are used (useShelfIce,
>   useICEFRONT in PARAMS.h). It also save memory in case we only use one of the 2 and
>   help clarify the diagnostics. The pieces of code in each pkg is easier to manage and
>   understand than mixed up in a single pkg. So if we were starting from a single pkg
>   I would argue that a good way to move forward would be to split it in 2.
>  
> Two different processes interacting with the ocean at different locations and requiring
> different main-code interface: seems like a good reason to have two packages, specially
> since many applications will continue to rely on the use of one and only one of the two.
> 
> Here is what I would suggest:
> Could we make a list of issues/problems that are related to having 2 different
> packages (instead of a merged one). May be some set-up pieces (e.g., location 
> of ice-front and ice-shelf) we would like to share between the 2 ?
> And from there, we could see what is the best way to address these problems
> and decide what to do.
> 
> Cheers,
> Jean-Michel
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-devel