[MITgcm-devel] seaice dynamics questions

Fri Oct 7 16:29:33 EDT 2011

Hi Martin,

I will probably remove the 2 B-grid features I listed, 
and probably not move seaice+obcs into pkg/seaice.

And to clarify the mask issue: I would like to try to use seaice dynamics
in the atmosphere with slab ocean (or couple), and for this purpose,
I need to replace all maskC,maskW,maskS and later also uVel,vVel.
We already have a perfect candidate for maskC, i.e., HEFFM,
and would like to use seaiceMaskU & seaiceMaskV in place of
maskW,maskS (assuming I ignore OBCS for now). 
I am also guessing that if seaiceMaskU & seaiceMaskV
were set in seaice_init_fixed.F, and if the part of the code
you don't like: "IF SEAICE_maskRHS THEN" was put within 
#ifndef ALLOW_AUTODIFF_TAMC, those seaiceMaskU & seaiceMaskV
should not make too much trouble for the adjoint.
It's just a guess.

Cheers,
Jean-Michel

On Fri, Oct 07, 2011 at 06:35:03PM +0200, Martin Losch wrote:
> Hi Jean-Michel,
> just some comments below.
> M.
> On Oct 7, 2011, at 6:16 PM, Jean-Michel Campin wrote:
> 
> > 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).
> Good.
> > 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).
> I am no longer happy about seaiceMaskU/V, they are only there fore testing. In real runs, they should always be one. Currently all they do is make the adjoint more complicated. 
> > 
> > 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.
> I am not sure if this is really a priority. I do not see the advantage of moving the obcs-stuff into seaice, because then you have to deal with two packages when you want to include seaice ice (or change something in the obcs code. 
> 
> Martin
> 
> > 
> > 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
> > 
> > _______________________________________________
> > 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