[MITgcm-devel] [MITgcm-cvs] MITgcm/pkg/seaice CVS Commit

Jean-Michel Campin jmc at ocean.mit.edu
Fri Nov 5 08:54:15 EDT 2010


Hi Dimitris,

Thanks for the answer. 
I now understand the motivations for this modification (it was not
clear to me before).
But right now, I don't have a good suggestion to try for this
problem. Might need to go deeper in the details of seaice
dynsolver (i.e., trying to make the ice-flow quasi non-divergent
near OB). Martin might have has some idea on that ?
Cheers,
Jean-Michel

PS: I am not yet ready to check-in my changes to prevent "links" of
tracers: right now, my version is breaking the restart !

On Thu, Nov 04, 2010 at 11:59:30PM -0700, Menemenlis, Dimitris (3248) wrote:
> Jean-Michel, Oliver has already contacted me about the exch2 issue.
> In addition, the mod that I checked in is not thread-safe.  So it definitely
> needs to be changed.
> 
> The issue I am trying to address is following.  Sea ice open boundary
> conditions are problematic because there can be a mismatch between
> the ice velocity that is imposed at the boundaries and that which is
> computed by the sea ice dynamic solver.  This can happen, for example, 
> when specifying monthly mean sea ice boundary conditions because of
> higher-frequency sea ice variability or when interpolating sea ice OBCS
> spatially from a lower-resoluton integration.
> 
> When there is convergence, ice piles up and cause model to crash.
> This is what flag OBCS_SEAICE_AVOID_CONVERGENCE
> takes care of by allowing ice to exit the domain of integration
> when there is convergence at the edges.
> 
> Divergence at the edges can also be problematic.  For example,
> Michael is integrating a hi-res Pine Island Glacier domain with OBCS
> from a CS510 integration.  Ice divergence at the edge causes
> ice formation -> salt rejection -> convection -> warmer water to rise to
> surface.  It looks ugly and eventually causes integration to blow up.
> 
> My attempted solution was to (i) put the open boundaries 4 grid point away
> from the edge as you suggested in your October 28 email and
> (ii) "not" to specify uice or vice at the edges but rather to
> use that which is computed by ice dynamic solver which extends a few
> point outside the OBCS.  This did not work as expected.  There are
> some sea ice artifacts in the region between the OBCS and the edge
> of the integration domain, which cause integration to crash.
> 
> So I am thinking that I should revert back to original OBCS mask in
> seaice_init_varia.F and to implement instead a relaxation region for
> sea ice tracer quantities similar to rbcs.
> 
> Suggestions?
> 
> Dimitris
> 
> On Nov 4, 2010, at 7:41 PM, Jean-Michel Campin wrote:
> 
> > Hi Dimitris,
> > 
> > I was going to make my changes to prevent "links" of
> > tracers (T, S, pTraver or seaice thermodynamics variables)
> > when using high order Adv.Scheme with OBCS (and when no
> > opposite land barrier prevents EXCH to transfert tracers
> > values). 
> > 
> > I started to look at seaice_init_varia.F (because it's related to exch)
> > but I don't undestand your latest changes (I know very little
> > about seaice dynsolver too, so may be it's the reason). In particular, 
> > 1) It does not seems compatible with Oliver's recent changes to make 
> > OBCS works with exch2; from tag-index, on Oct 13:
> >> o pkg/obcs: add support for exch2
> >>  - the position of the boundary and prescribed values are specified using
> >>    a global domain with exch2 facets stacked
> >>    - in x for N,S boundaries (like W2_mapIO=-1)
> >>    - in y for E,W boundaries (so E,W boundaries do not overlap)
> > 2) without exch2, I have some concern when the OB are further inside the 
> > domain (OB_Iw > 1, e.g., OB_Iw =4 ): what will be the effect of setting
> > those masks to zero just for i=1 ?
> > 
> > Thanks,
> > Jean-Michel
> > 
> > On Tue, Nov 02, 2010 at 05:23:50PM -0400, Dimitris Menemenlis wrote:
> >> Update of /u/gcmpack/MITgcm/pkg/seaice
> >> In directory forge:/tmp/cvs-serv22627/pkg/seaice
> >> 
> >> Modified Files:
> >> 	seaice_init_varia.F 
> >> Log Message:
> >> For OBCS, close southern and western boundaries for sea ice solver
> >> based on myYGlobalLo and myXGlobalLo instead of OB_Js and OB_Iw.
> >> 
> >> 
> >> _______________________________________________
> >> MITgcm-cvs mailing list
> >> MITgcm-cvs at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-cvs
> > 
> > _______________________________________________
> > 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



More information about the MITgcm-devel mailing list