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

[Jean-Michel Campin]

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