[MITgcm-devel] seaice dynamics questions

Fri Oct 7 12:16:34 EDT 2011

Hi,

two things:

The first thing was to start to remove some B-grid pieces of code,
in 2 cases: a) B-grid with useCubedSphereExchange ;
        and b) B-grid with OBCS ;
(I would add a stop if falling into these cases).
and may be to move those 2 masks (seaiceMaskU & seaiceMaskV)
out of the #ifdef SEAICE_CGRID (so that they are always available,
even if not used).

The other thing is as I was looking at this seaice+obcs code, I had the
impression that it would make things easier if it was in pkg/seaice
rather than in pkg/obcs, with a couple of changes:
a) seaice+obcs options in SEAICE_OPTIONS.h ;
b) move & rename pkg/obcs/OBCS_SEAICE.h to pkg/seaice/SEAICE_OBCS.h ;
c) move & rename the 2 seaice S/R in pkg/obcs to pkg/seaice ;
d) could also think of moving OB?[ice-var]File spec from OBCS_PARM01
 in data.obcs to a new namelist in data.seaice, but could also
 wait until obcs_exf_load.F is splitted (which I would not do right now).
My main concern is that if for some reasons (sequence of calls/
algorithm/time-stepping, or the need to make pkg/seaice more flexible, 
e.g., to be used in atmospheric + slab-ocean set-up) we need to have a
specific seaice_obcs_calc.F, it would be nicer to get this done
within seaice pkg.
I am not sure that every one want to go for this move,
it's why I am asking.

Cheers,
Jean-Michel

On Mon, Sep 26, 2011 at 10:39:30AM +0200, Martin Losch wrote:
> Hi Jean-Michel,
> 
> currently I use this
> #define OBCS_SEAICE_COMPUTE_UVICE
> and hack the corresponging code, so any change is "welcome" (I'll brace for it).
> 
> M.
> 
> 
> On Sep 23, 2011, at 1:17 AM, Jean-Michel Campin wrote:
> 
> > Hi Michael & Dimitris,
> > 
> > Thanks for the information. This helps.
> > Don't know yet how/when I will try something,
> > but I will keep these options unchanged.
> > 
> > Cheers,
> > Jean-Michel
> > 
> > On Thu, Sep 22, 2011 at 03:48:03PM -0700, Michael Schodlok wrote:
> >> 
> >> those are my OBCS seaice options
> >> 
> >> I apparently did not turn the avoid convergence on for the 1 km grid
> >> but it still works and I did not have any issues with it.
> >> As discussed a while ago for this resolution something like
> >> avoid_divergence,
> >> or rbcs would be good.
> >> 
> >> #undef OBCS_SEAICE_AVOID_CONVERGENCE
> >> #undef OBCS_SEAICE_SMOOTH_UVICE_PERP
> >> #undef OBCS_SEAICE_SMOOTH_UVICE_PAR
> >> #undef OBCS_SEAICE_SMOOTH_EDGE
> >> #define OBCS_SEAICE_COMPUTE_UVICE
> >> 
> >> Michael
> >> 
> >> 
> >>> Michael, what SEAICE_OBCS options
> >>> do you use for your 1-km integrations?
> >>> 
> >>> Jean-Michel, at a minimum I think that
> >>> OBCS_SEAICE_AVOID_CONVERGENCE
> >>> needs to be supported.
> >>> 
> >>> Thanks
> >>> 
> >>> Dimitris Menemenlis
> >>> 
> >>> On Sep 22, 2011, at 4:07 PM, Jean-Michel Campin wrote:
> >>> 
> >>>> Hi,
> >>>> 
> >>>> I made some changes in seaice_lsr.F that should fix the point 2
> >>>> below. I've checked that it does not break completly the adjoint
> >>>> (I got roughtly the same number of recomputation warnings, and
> >>>> it's not slower to run) but it might be worth to check.
> >>>> 
> >>>> Regrding point 3 (obcs + seaice velocity): I would like to know
> >>>> which CPP options in obcs_apply_uvice.F are currently used
> >>>> (in order to know which one to keep unchanged if I made some
> >>>> modifications):
> >>>> OBCS_SEAICE_COMPUTE_UVICE
> >>>> OBCS_SEAICE_SMOOTH_UVICE_PAR
> >>>> OBCS_SEAICE_SMOOTH_UVICE_PERP
> >>>> OBCS_SEAICE_AVOID_CONVERGENCE
> >>>> The idea is that I could try to implement some masking in
> >>>> seaice_lsr.F, and calling obcs_apply_uvice before seaice_lsr
> >>>> (or at the top of it); but I need to know what to do with what is
> >>>> currently in obcs_apply_uvice.F
> >>>> 
> >>>> Cheers,
> >>>> Jean-Michel
> >>>> 
> >>>> On Thu, Sep 01, 2011 at 02:18:59PM -0400, Jean-Michel Campin wrote:
> >>>>> Hi,
> >>>>> 
> >>>>> I have a couple of questions and remarks regarding pkg/seaice:
> >>>>> 
> >>>>> 1) I found annoying not to be able to know where some CPP options
> >>>>> should be defined/undef, since they don't appears in any
> >>>>> *OPTIONS.h files, neither set at the top of the *.F file
> >>>>> in which they are used (might want to use this to keep some
> >>>>> inactive pieces of code):
> >>>>> DISABLE_SEAICE_OBCS <- I guess in SEAICE_OPTIONS.h ?
> >>>>> and many more in other seaice S/R.
> >>>>> 
> >>>>> 2) LSR solver: we always do uIce first and then vIce, right ?
> >>>>> and I guess the vIce solution depend on the new uIce.
> >>>>> Now when the seaice extends over 2 faces of the CS-grid,
> >>>>> might have an issue with U/V not being continuous at the
> >>>>> face boundary. As I understand, it's not so much an issue on
> >>>>> regular CS grid (e.g., CS-510) for present day conditions but
> >>>>> this is likely to happen on lat-lon cap grid. I guess the
> >>>>> solution would be to have a 3 pass algorithm, like in
> >>>>> multi-dim advection with CS topology.
> >>>>> 
> >>>>> 3) I did not find many OBCS specific code in seaice_lsr.F
> >>>>> Would it make sense to prevent the LSR solver from updating
> >>>>> the ice velocity at the OB (like we do in CG2D) ?
> >>>>> Would it be useful ? Might not be too difficult with some masking.
> >>>>> 
> >>>>> 4) I am going to add an EXCH call at the end of obcs_apply_uvice.F,
> >>>>> since it seems we need one. I am also tempted to remove
> >>>>> all the "if ( OB?u/vicefile .NE. ' ' ) then" : I think it's
> >>>>> not right and not safe to by-pass the setting of ice-velocity at
> >>>>> an open-boundary, and it's better to apply a default zero velocity
> >>>>> when no file is provided.
> >>>>> 
> >>>>> Cheers,
> >>>>> Jean-Michel
> >>> 
> >>> 
> >> 
> >> 
> >> -- 
> >> --
> >> --
> >> 
> >> *************************************************
> >> 
> >> Michael Schodlok <schodlok at jpl.nasa.gov>
> >> Jet Propulsion Lab/
> >> California Institute of Technology
> >> MS 300-323
> >> 4800 Oak Grove Dr
> >> Pasadena CA 91109-8099 USA
> >> Tel: +1-818-354-4015  Fax: +1-818-393-6720
> >> 
> >> *************************************************
> >> 
> >> 
> >> 
> > 
> > _______________________________________________
> > 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