[MITgcm-devel] seaice*_if

[Martin Losch]

Hi Ian (and others),

are the *_if routines, that are presently in pkg/seaice, up to date? I.e. is this the code that you used for you thesis work and afterwards? Since Patrick's initial check-in in Mar 2008 they have only been modified by infidels (like myself; I never even checked the results, because there are no verification tests for this code), so I am wondering if this is the code you refer to in your email. I was not able to use it successfully (I got an unstable adjoint, but that may be my fault).

I think the *_if code should become the default, once the differences 1-3 have been resolved in one way or other (I expect that multicategory sea-ice is no problem at all), so I think your option #2 is the best one.

I have two more things that need to be "tinkered with" in the context of coupling the ocean/ice-system to an atmosphere:
1. include sublimation of snow/ice in the mass balance. I have code for this and want to/will check that into seaice_growth.F soon (requires some additional fields to be passed between seaice_growth and seaice_budget_ice, also requires, or would be facilitated greatly by, the conversion of many things into units of mass rather than meters of ice/water/snow).
2. mass conservation in general: I found a few places in seaice_growth_if.F where HEFF/AREA/HSNOW/PRECIP are just reset, and rightly so, I would not expect negative precipitation, etc. either (this is also the case in seaice_growth), but this will have implications for the mass balance, that may be a problem in long coupled runs.

Martin

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