[MITgcm-devel] (not so) funny things happen in seaice_lsr and pickups
Jinlun Zhang
zhang at apl.washington.edu
Mon Mar 9 12:54:01 EDT 2009
Hi Martin,
As you said, for B-grid, the value does not matter because of the
non-slip bc's. I am not sure about C-grid non-slip bc's. If you need
that value at the boundary for C-grid, it seems that your approach
probably makes better sense.
Jinlun
Martin Losch wrote:
> Hi again,
>
> I have another question for Jinlun. I am now quite confident, that I
> have found all (serious) problems in the metric terms. However, my
> code still blows up. Could the discretization of \eta be a problem? On
> Z-points ("bottom left" corner of C-grid cell, on a B-grid this is
> where the velocities are), I average eta like this:
> DO j=1,sNy+1
> DO i=1,sNx+1
> etaMeanZ (I,J,bi,bj) =
> & ( ETA (I,J ,bi,bj) + ETA (I-1,J ,bi,bj)
> & + ETA (I,J-1,bi,bj) + ETA (I-1,J-1,bi,bj) )
> & / MAX(1.D0,maskC(I,J, k,bi,bj)+maskC(I-1,J, k,bi,bj)
> & + maskC(I,J-1,k,bi,bj)+maskC(I-1,J-1,k,bi,bj) )
> ENDDO
> ENDDO
> In the B-grid code I find this:
> DO j=1-Oly+1,sNy+Oly
> DO i=1-Olx+1,sNx+Olx
> ETAMEAN(I,J,bi,bj) =QUART*(
> & ETA(I,J-1,bi,bj) + ETA(I-1,J-1,bi,bj)
> & +ETA(I,J ,bi,bj) + ETA(I-1,J ,bi,bj))
> ZETAMEAN(I,J,bi,bj)=QUART*(
> & ZETA(I,J-1,bi,bj) + ZETA(I-1,J-1,bi,bj)
> & +ZETA(I,J ,bi,bj) + ZETA(I-1,J ,bi,bj))
> ENDDO
> ENDDO
> This means that \eta/\zeta on the boundaries are only half as large as
> in my C-grid discretization (however, these values may actually never
> be used because of the no-slip BCs on the B-grid). So I am wondering,
> what the "correct" value of \eta on the boundary is. I observe, that
> code with
> DO j=1,sNy+1
> DO i=1,sNx+1
> etaMeanZ (I,J,bi,bj) = 0.25 _d 0 *
> & ( ETA (I,J ,bi,bj) + ETA (I-1,J ,bi,bj)
> & + ETA (I,J-1,bi,bj) + ETA (I-1,J-1,bi,bj) )
> ENDDO
> ENDDO
> tends to be stable (at least in the shorter test that I made). Jinlun,
> what's your opinion on this?
>
> Martin
>
> ----- Original Message -----
> From: Martin Losch <Martin.Losch at awi.de>
> Date: Friday, March 6, 2009 8:38
> Subject: Re: [MITgcm-devel] (not so) funny things happen in seaice_lsr
> and pickups
> To: MITgcm-devel at mitgcm.org
>
> > Hi Jean-Michel,
> >
> > I'll create a SEAICE_GRID.h, there are actually quite a few
> > fields in
> > SEAICE.h, that are really grid parameters (e.g., masks). These
> > are
> > then initialized in seaice_init_varia.F which is not quite
> > consistent
> > either. I'll do something about that once the C-LSR with metric
> > terms
> > proves to be stable (it's still running, but I need at least
> > the
> > weekend before I can say more)
> >
> > Martin
> >
> > On Mar 5, 2009, at 10:44 PM, Jean-Michel Campin wrote:
> >
> > > Hi Martin,
> > >
> > > I guess it depends if we want
> > > tanPhiAtZ and tanPhiAtC arrays to always be defined
> > > (in this case, they will sit in GRID.h) or if we want
> > > to define those 2 2-D arrays only with pkg/seaice,
> > > and in this case I will prefer to put them elsewhere,
> > > so that when GRID.h is included without PACKAGES_CONFIG.h
> > > we don't have an incomplete file. Why not keeping those
> > > 2 simple names tanPhiAtZ/C, but in a new header file
> > > SEAICE_GRID.h ? This way, if, in the future, they need
> > > to be move back to GRID.h, it will not be a big deal.
> > > And they could be set in ini_spherical_polar_grid.F
> > > before the grid-rotation.
> > >
> > > Just a comment: regarding the the grid-rotation calls, them
> > > could have been put in ini_grid.F (and then used also with
> > > curvilinear grids, when x & y are lon & lat), no ?
> > >
> > > Jean-Michel
> > >
> > > On Thu, Mar 05, 2009 at 12:16:31PM -0800, Dimitris Menemenlis wrote:
> > >> I will let JM answer this.
> > >>
> > >> On Mar 5, 2009, at 11:17 AM, Martin Losch wrote:
> > >>
> > >>> However, first I'd like to get a comment on how to add these new
> > >>> fields tanPhiAtZ and tanPhiAtC (see a previous email in
> > this
> > >>> thread).
> > >>> Currently I have implemented a version that is "private" to
> > >>> pkg/seaice, because these fields would not be used
> > elsewhere. Or
> > >>> is it
> > >>> better to define these fields in GRID.h where they would actually
> > >>> belong?
> > >>
> > >> _______________________________________________
> > >> 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
>
> Martin Losch
> Alfred Wegener Institute
> Postfach 120161, 27515 Bremerhaven, Germany;
> Tel./Fax: ++49(0471)4831-1872/1797
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>
--
Jinlun Zhang
Polar Science Center, Applied Physics Laboratory
University of Washington, 1013 NE 40th St, Seattle, WA 98105-6698
Phone: (206)-543-5569; Fax: (206)-616-3142
zhang at apl.washington.edu
http://psc.apl.washington.edu/pscweb2002/Staff/zhang/zhang.html
More information about the MITgcm-devel
mailing list