[MITgcm-devel] Add sea ice surface forcing to pkg/seaice

[Gael Forget]

Hi Dimitris,

I think I caught up with your recent code changes and the associated devel thread.

> Fine with me to stay with the code as it is now, as long as:
It's NOT fine by me. In my opinion, the only sensible and time efficient way 
out of this spiraling mess is to revert back to r164 of seaice_growth.F. 

Jean Michel has pointed a number of issues, which I also believe are serious ones. Trying 
to argue your way around them (and not in a very convincing way I think) is not the same 
as addressing them. Here are my 2 cents, and what I think I understand and would suggest.

What's wrong with the present state of affairs?
seaice_growth.F  now has a bunch of freshly duplicated code blocs, which hardly seems 
justified and will make maintenance that much harder. For starters I would prefer it if we did not 
have to spend time double checking and possibly debugging r167. Secondly we have now hacked 
an array called snowPrecip as a way to specify ice bergs/glacier melt, which is very confiusing since 
ice bergs/glacier melt would seem to have nothing to do with local snow or precip in reality. Thirdly we have 
a freshly added conflict between pkg/seaice and pkg/thsice, namely their rather different implementations of 
snowPrecip/snowPrecipFile (see AREA factor you dont want for icebergs), for no good reason. This makes 
switching between pkgs that more tricky. Finally the added snowPrecip/snowPrecipFile code do not seem very 
practical or likely to produce useful results regarding snow precipitation (as opposed to some iceberg dump; may be).

What would be useful to do? 
- Strike this hack gone wrong altogether and revert to r164.
- Since you want to add an ice berg/melting glacier forcing, start by adding dedicated arrays and 
  I/O to this end (in exf or seaice?). We would thus save some confusion and reserve snowprecip/snowprecipFile 
  for a potential implementation of snow precipitation that ought to be in line with what is done in pkg/thsice (see next bullet). 
  In seaice_growth.F, you would add the berg/glacier forcing accordingly to ice/snow/salt stocks, separately 
  from snow & precip). Please keep that code self contained and identifiable (namely within CPPs; at least for a while).
  You will need to specify the AREA of the added snow/ice one way or another, especially in the case 
  of no pre-existing ice when using siEPS is quite silly as pointed out by Jean Michel.
- Then an implementation of snowprecip/snowprecipFile following that of pkg/thsice would be useful 
  in pkg/seaice, where it could help improve/tune the simulated snow layer. In this case I believe you want to 
  remove snowPrecip from precip, add snowPrecip*AREA to the ice/snow stock via d_HSNWbyRAIN (in 
  place of the precip version), pass all of the liquid precip plus (1-AREA)*snowPrecip turned liquid to 
  empmr, account for the different latent energies accordingly in qnet, and finally take care of 
  the diagnostics. Sounds about right Jean Michel?

Sorry if I sound confused -- I am.

Cheers,
Gael


> a) things are clear (clarification below).
> b) I can put the "snowprecipFile" business into the list of
>  "other reason to use pkg/thsice (instead of pkg/seaice thermo)"
> c) we don't turn on snowprecipFile in experiment global_ocean.cs32x15 
>  (input.seaice + ad tests).
> 
> clarification:
> 1) we know how to implement snowPrecip, whether it's specified
>  through snowprecipFile or inferred for precip & atemp/tsurf
>  (cf pkg/thsice).
> 2) however a different route has been taken in seaice_growth.F
>  in order to squeeze in ice from iceberg into snow precip.
> 
> Note regarding point (2): by thsice standard, it would be called a bug, 
> but in pkg/seaice, it's not so clear according to your list of 
> remarks from yesterday, (i) to (v), which left me confused.
> 
> Cheers,
> Jean-Michel
> 
> On Mon, Apr 23, 2012 at 11:25:44PM +0000, Menemenlis, Dimitris (3248) wrote:
>> Jean-Michel, to address your concerns below and in previous two messages,
>> (and make sure that novice telemarkers will not be overwhelmed by too much fresh powder)
>> 
>> I can set AREA=1 when and where following conditions are met:
>> snowPrecipFile .NE. ' '
>> snowPrecip(i,j,bi,bj) .GT. ZERO
>> HSNOW .GT. siEps
>> or some slightly more adjoint-friendly version of above.
>> 
>> The assumption is that snowPrecip spreads evenly in each model grid box where it is non-zero.
>> 
>> Will that be OK?
>> 
>> Dimitris Menemenlis
>> 
>> On Apr 23, 2012, at 3:50 PM, Jean-Michel Campin wrote:
>> 
>>> Dimitris,
>>> 
>>> I am confused about your comments (i) to (v) below.
>>> For me, the actual snow thickness is more natural that 
>>> the effective one. Can do in-situ measurements. 
>>> If it does not exist in some parts of seaice_growth but still exists
>>> in seaice_solve4temp, it's going to be quite chalenging to explain 
>>> to new users how seaice pkg works.
>>> Point (iii) to (v) are even more confusing to me.
>>> 
>>> But to come back to my example of a good snow fall (> 1.cm/h) over 
>>> small fraction of seaice, which could be as low as 10^-5 for default
>>> SEAICE_area_reg=siEPS, within the same grid cell, the SST can 
>>> still be warm enough to be cooled by the latent heat of the snow 
>>> and to remain above freezing (no new ice formed). But instead of 
>>> doing this, the falling snow will increase the actual snow thickness 
>>> over seaice at a rate ~10^5 larger than the real accumulation rate.
>>> Can easily get 1.km of fresh snow (ye, fresh powder !) in an hour or so.
>>> 
>>> Cheers,
>>> Jean-Michel
>> 
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel