[MITgcm-devel] seaice*_if

[Ian G. Fenty]

>  From: "Menemenlis, Dimitris (3248)"<Dimitris.Menemenlis at jpl.nasa.gov>
>  Re: [MITgcm-devel] [MITgcm-support] maintaining sea	ice
	coverage	over multi-year run on cs32

>On a related note, are there any plans to eventually merge back
>the *_if routines with original growth and budget routines?

>Dimitris


Hey Dimitris,
It is not immediately clear what is meant by "merging back" the *_if routines with the original growth and budget routines.  After years of accumulated changes, the "original" routines are long gone.  At present, we have a "default" branch and several alternatives.

The thermodynamic assumptions between the default and the *_if branches are nearly identical.

The practical differences between the default and *_if branches are:
  1. An interface with the salt plume package.  Actually, I interfaced seaice_growth_if and the plume package last week and will check in the changes after more testing.
  2. Variable sea ice salinity and the advection of a spatially-varying ice salinity field.  I used a globally constant value because I knew of no justifiable alternative.
  3. Multiple thickness categories.  I think this is easily implemented but it is not something that I found necessary for realistic simulations.  Prescribed atmospheric forcing fields (e.g., reanalyses) drive errors in sea ice-atmosphere heat fluxes that are probably much larger than those caused by the assumption of single-category ice.

The significant differences remain with their adjoints.  The default thermo codes gave NaNs (at worst) or unphysical sensitivities (at best) in several simple tests I made in the past two weeks.  Whereas the *_if codes behave in a way which is consistent with my expectations.

As long as default thermo ice code is being continually tinkered with, one should expect its adjoint will behave oddly.  Like it or not, the utility of the adjoint of the thermodynamic ice model is sensitive to the details of how its physical assumptions are numerically implemented.

To anyone who has a stake in the future of these codes, I can see two alternatives:
  1. Keep the "default" line for tinkering and maintain realistic expectations about its adjoint.  Leave the *_if codes relatively untouched except to maintain continuity with other developments (e.g., how one treats time levels in AREA and HEFF).

  2. Freeze development on the "default" line and put it aside.  Implement the important updates to the *_if line, making sure its adjoint remains intact.  Freeze that version (calling it _if or _adjoint) for those efforts benefiting from an ice adjoint.  Use a copy of that version for use in a 'developmental' or 'experimental' branch.  Maintain realistic expectation about the utility of its adjoint.

If the consensus is #2, I volunteer to bring the *_if codes up to date before doing the version freeze.

My 2c.
- Ian



-- 
Dr. Ian G. Fenty
Postdoctoral Associate
Department of Earth, Atmospheric and Planetary Sciences
Massachusetts Institute of Technology | 54-1511A
Cambridge, MA  02139-4307
508-498-4879