[MITgcm-devel] seaice*_if

[Martin Losch]

Hi Ian,

On Jul 21, 2010, at 9:56 PM, Ian G. Fenty wrote:

> Hey Martin,
> 
>> 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?
> 
> They actually are up to date and to a very good approximation they are what I used for the thesis.  By the end of the week they will be completely up to date.  I'm making two verification experiments for it now.
Good to hear. I'll have to back and check why my adjoint runs did not work. I have to admit that I just gave it a quick shot and got problems similar to the ones that I got with the default thermodynamic code. Basically I got instabilities in the ocean far away from the region of interest (where the cost function was evaluated), that were much smaller when I turned off sea-ice altogether.
> 
>> 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.
> 
> I think it is good to be ensure mass and energy conservation.  They way I wrote seaice_growth_if, I consider the actual change of HEFF and actual loss of HSNOW (from melt) within the routine when computing EmPmR.  Obviously, when ice/snow mass tendencies are negative, one can't use a tendency * time_step * conversion_factor to calculate the contribution to EmPmR because more ice/snow mass loss may be implied than is actually present.  I calculate QNET using a similar logic.  Thus, zeroing out HEFF/AREA etc. before QNET and EmPmR are calculated does not lead to mass/energy imbalances.
> 
> Of course, I'm excluding the routine's initial sanity check for physical AREA and HEFF values after seaice_dynamics (e.g., dealing with a positive HEFF and zero or negative AREA).  Unless this issue has been fixed (or maxima-preserving advection schemes are being used) and I missed it, the ice dynamics routines regularly generate such conditions.  I think dealing with the imbalances associated with creation/destruction of ice/snow mass should be handled *before* seaice_growth.  I don't think seaice_growth is the place where we mop up problems in seiace_dynamics!
I agree. Sometimes I do encounter these things too, but choose to ignore them. They nearly go away with flux limited advection schemes (77, 33 are possible currently), but for the adjoint, only the 2nd-order scheme with extra diffusivity is possible.
> 
>> (I got an unstable adjoint, but that may be my fault).
> 
> I have a nice 1D setup where one can easily compare how the adjoints of the default branch and seaice_growth_if behave.  If you want, I'll add it to a contrib directory and you can verify a working (or broken!) adjoint.
That would be great! Please do so.
> 
> With respect to latent heat flux/sublimation questions, you are right that the models represent heat fluxes associated with sublimation/adsorption while not actually exchanging water between the ice/snow surface and the atmosphere.  In other words, we don't add frost to the ice/snow surface out of "thin air" during adsorption nor do we remove snow/ice during sublimation. Ergo, the water budget is closed.
> 
> However, with respect to distributing mass between the atmosphere and ice/snow surface, we're definitely missing a process.
> 
> Sublimation never causes melting of snow/ice while adsorption can in a narrow condition.  Consider the following.  When qhice_mm>  AQH, sublimating ice/snow removes heat from the ice/snow surface - so no melting.  When qhice_mm<  AQH, water vapor adsorption transfers heat to the ice/snow surface.  However, under freezing conditions (F_ia>  0, F_ia_net = 0, T_surf<  0 deg C) the energy convergence associated with adsorption only reduces the flux of heat from the ice/snow surface flux to the atmosphere.  So again, no melting.
> 
> Heat gained from adsorption can contribute to surface melt only when 1) AQH>  qhice_mm (water vapor condensing on the ice/snow surface) and 2) there is a net energy flux convergence at the surface (implying T_surf = 0 deg C).  Whether the new (imaginary) frost melts or the existing snow or snow seems unimportant.  It seems physical to me that water vapor can condense on an icy surface at its melting point and by doing so, cause the icy surface to warm a bit thereby triggering melting.
> 
> I think it makes sense to extract water vapor from the atmosphere and add it as frost (snow) to the ice/snow surface
> during adsorption and to remove snow or ice from the ice/snow surface and add it as water vapor to the atmosphere during sublimation.  But, unless I'm missing something, I don't see a problem with the way we are calculating the heat fluxes.  Please enlighten me if you see a problem with the above!
I had hoped to enlightened by you about this subject, as you have thought about this much more. I think I can agree with all of the above statements (except for the mass conservation). After thinking (and talking to some ice/snow observationalists) about this, I understand now that the latent heat form (re-)sublimation enters the general heat flux into the ice and can be used for melting and freezing (whether that may or may not occur does not matter to me). So everything OK with the heat flux. For a coupled atmosphere ice/ocean-model, I still need to convert the F_lh into a fresh water flux that is then added to the atmosphere and removed from the snow ice (or vice versa in the case of re-sublimation). For an ice/ocean-model without reactive atmosphere, not rermoving the sublimated snow/ice (as currently implemented) means mass conservation within the ice model, but it is actually wrong, because in this uncoupled system, I do not expect to conserve mass. In the ocean anology, we would neglect any evaporation from the ocean, even if we take into account the latent heat flux, and that would not be right either. So I believe, that the fresh-water flux associated with F_lh must be accounted for also in an uncoupled system.

Martin