[MITgcm-support] Re: obcs
Martin Losch
mlosch at awi-bremerhaven.de
Fri Sep 16 03:57:26 EDT 2005
Hi Tom,
the short explanation in OBCS.h is misleading (if not wrong) and not
completely up to date. In general, the OBCS-pkg seems to be a bit of
everyone's step-child. I once volunteered to improve the documentation,
but have never gotten around to it, sorry. I will do this!
This is what is really happening:
for scalar tracers, everything is simple and the boundary values are at
OB_Jnorth (as in the example), but as soon as you use higher order
advection schemes, that's not enough anymore, so that now the boundary
value at T(I,OB_Jnorth(I)) is also assigned to as many points beyond
the boundary as the overlap (OLy). You can see that in obcs_apply_ts,
for example.
The boundary u point at the northern boundary is u(I,OB_Jnorth(I)), and
the meridional velocity gets the same boundary value south and north of
the tracer point, i.e. at v(I,OB_Jnorth(I)) and v(I,OB_Jnorth(I)+1).
The same is true for the southern boudnary. In both cases the applied
masks for meridional velocity are the masks on the *INSIDE* points of
the domain (that's OB_Jnorth in the north and OB_Jsouth + 1 in the
south). For eastern/western boundaries things are analogous (swap u and
v).
This way, when vertical velocities w ON the boundary are computed (from
integrating the continuity equation), only the derivatives of the
velocities parallel/tangent to the boundary are non-zeros (derivate of
normal velocities are zeros by definition). The other component of w is
a gradient of topography, so it is wise (and maybe even necessary under
certain circumstance, with the nonlinear free surface, for example, and
therefore also with r*-stuff), to have constant depth across a
boundary, so that the hfacs (for northern/southern boundaries) are the
same to the north and the south of the tracer point.
What's missing (and I am not sure whether this is necessary) is the
overlap business. We should probably include that for safety.
Martin
On Sep 15, 2005, at 6:28 PM, Thomas Haine wrote:
> I'm trying to understand how obcs are applied but I'm confused by
> OBCS.h
> and obcs_apply_uv.F
>
> OBCS.h says:
>
> These are input arrays (of integers) that contain the *absolute*
> C computational index of an open-boundary (OB) point.
> C A zero (0) element means there is no corresponding OB in that
> column/row.
> C The computational coordinate refers to "tracer" cells.
> C For a northern/southern OB, the OB V point is to the south/north.
> C For an eastern/western OB, the OB U point is to the west/east.
> C eg.
> C OB_Jnorth(3)=34 means that:
> C T( 3 ,34) is a an OB point
> C U(3:4,34) is a an OB point
> C V( 4 ,34) is a an OB point
> C while
> C OB_Jsouth(3)=1 means that:
> C T( 3 ,1) is a an OB point
> C U(3:4,1) is a an OB point
> C V( 4 ,2) is a an OB point
>
> and in obcs_apply_uv.F:
>
> DO I=1-Olx,sNx+Olx
> C Northern boundary
> IF (OB_Jn(I,bi,bj).NE.0) THEN
> vFld(I,OB_Jn(I,bi,bj),K,bi,bj)=OBNv(I,K,bi,bj)
> & *_maskS(I,OB_Jn(I,bi,bj),K,bi,bj)
> uFld(I,OB_Jn(I,bi,bj),K,bi,bj)=OBNu(I,K,bi,bj)
> & *_maskW(I,OB_Jn(I,bi,bj),K,bi,bj)
> vFld(I,OB_Jn(I,bi,bj)+1,K,bi,bj)=OBNv(I,K,bi,bj)
> & *_maskS(I,OB_Jn(I,bi,bj),K,bi,bj)
> ENDIF
> ENDDO
>
> There seem to be some inconsistencies here:
>
> i) Why are both U(3,34) and U(4,34) OB points in the first example?
> (similarly 2nd example)
>
> ii) Why is V(4,34) an OB point, not V(3,33) in the first example?
> (similarly 2nd example)
>
> iii) The code doesn't seem to implement either the rules illustrated in
> the examples, or the rule about a northern/southern OB having the OB V
> point to the south/north.
>
> I'm confused! Can anyone clarify please?
>
> Thanks, Tom.
> --
> --------------------------------------------
> Thomas W. N. Haine
>
> Associate Professor of Physical Oceanography,
> Department of Earth & Planetary Sciences,
> 329 Olin Hall, The Johns Hopkins University,
> Baltimore, MD 21218, USA.
> Tel : 410 516 7048, Fax : 410 516 7933
> Thomas.Haine at jhu.edu
> http://www.jhu.edu/~eps/faculty/haine
> --------------------------------------------
>
More information about the MITgcm-support
mailing list