[MITgcm-devel] seaice*_if

[Menemenlis, Dimitris (3248)]

Ian, sorry for delay in getting back.

It'd be great if you were willing to take on the merging of seaice*_if and seaice* routines, as you describe below.  
Maintaining two separate branches, one adjoint-friendly and one for forward code development, did not prove very productive in the past, for example, the short-lived ecco-branch.

Also, I am glad that you are working toward a verification experiment for the seaice*_if routines.
That (along with checkpoint tags) is the preferred way to "freeze" code, i.e., to make sure that future modifications do not break it.

Regarding variable sea ice salinity, what is eventually needed is an aging function, where the ice rejects progressively more salt as it ages.
The merged code has to provide CPP and/or runtime options to switch between the constant salinity of seaice*_if and the variable salinity of seaice*.

Regarding thickness categories, again what is eventually needed is to combine this capability with ice age and/or dynamics as is done in more modern sea ice codes.

Regarding adjointability, I am surprised that the default thermo code gives NaNs.
Patrick used this code for several adjoint sensitivity experiments and there are sea_ice adjoint verification experiments in lab_sea.
Did you run your adjoint test experiments with same settings as the lab_sea/*ad* experiments?

Cheers, Dimitris

> On Jul 18, 2010, at 12:49 AM, Ian G. Fenty wrote:
> 
>>> 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