[MITgcm-devel] ridging of ice

[Torge Martin]

Hi Martin,

I support option (ii) as well. I think ridging has nothing to do with
thermodynamics and thus shouldn't be hidden in seaice_growth (nor in
thsice) -- and it also should be independent of the advection routine.

Along the same lines: when implementing the ITD code I saw all this
"pathological case" treatment at the beginning of seaice_growth, which
truly is kind of a "cleaning" of the variables before going into the flux
calculations. This maybe necessary but is not really ice thermodynamics.
Cleaning up this part would clearly get us closer to treating seaice_growth
as a 1-D function that could be called for each ITD category ...

Torge


On Tue, Apr 8, 2014 at 3:40 PM, gael forget <gforget at mit.edu> wrote:

> Hi Martin,
> option (ii) seems fine to me. I have given up myself on
> the notion of tidying up seance_growth.F since the last
> time the code was almost entirely duplicated (for ITDs)
> so it is good to see that you are picking up the slack.
> Cheers,
> Gael
>
> On Apr 8, 2014, at 8:31 AM, Martin Losch <Martin.Losch at awi.de> wrote:
>
> > Hi there,
> >
> > I have picked up Torge's ITD code and am implementing a ridging scheme
> following Lipscomb et al (2007), Bitz et al. (2001). For that it would be
> nice, if we could cleanly separate the "ridging code" in seaice_growth from
> the rest, and put it at the end of or after s/r seaice_advdiff.
> >
> > I see potential conflicts with these points (because they happen before
> the ridging code that currently starts a point 2.5 or line 664 in
> seaice_growth.F):
> > PART 1: treat pathological cases (post advdiff), especially
> > - when EXF_SEAICE_FRACTION is defined, because AREA is then updated;
> > - AREA/HEFF/HSNOW below zero
> >
> > But for some reason (luck?) moving the ridging code to the end of
> seaice_advdiff does not change the results of the forward verification
> experiments.
> > If nobody objects, I will remove the ridging code from seaice_growth and
> move it to (along with the SItracer and DIAGNOSTICS code)
> > (i) the end of seaice_advdiff (where it already is, when
> usePW79thermodynamics=.False.) OR
> > (ii) into a separate routine that is called after seaice_advdiff
> > (iii) leave seaice_growth as it is and only change code related to
> SEAICE_ITD.
> >
> > For the ITD ridging code there will be a new routine anyway that could
> include the non-ITD ridging code so option (ii) appeals little more to me.
> Option (iii) is also possible, but I think this will backfire in the future
> and make the code even more complicated and difficult to understand.
> >
> > The thsice code includes its own ridging line (line 211 in
> thsice_extend.F: iceFrac = MIN(icFrac(i,j)+newIce/hNewIce,iceMaskMax)), so
> that this new routine would be called only if useThsice=.FALSE.
> >
> > What do you think?
> >
> > Martin
> >
> >
> >
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-devel/attachments/20140408/6e95df94/attachment.htm>