[MITgcm-support] hFac's and obcs

Martin Losch mlosch at awi-bremerhaven.de
Mon Sep 12 04:45:55 EDT 2005


Hi Tom,

I tried to find places in the OBCS-related code, where hFacS (or maskS) 
could be a problem. Having had only a quick look I couldn't find 
anything. In fact, the open southern boundary values for v-velocity are 
prescribed at OB_Js+1, that is at J=2 in your case, so that the value 
of hFacS/maskS at J=1 shouldn't matter:
In obcs_apply_uv.F, the velocities fields are set:
>        IF (OB_Js(I,bi,bj).NE.0) THEN
>         vFld(I,OB_Js(I,bi,bj)+1,K,bi,bj)=OBSv(I,K,bi,bj)
>      &                              *_maskS(I,OB_Js(I,bi,bj)+1,K,bi,bj)
>         uFld(I,OB_Js(I,bi,bj),K,bi,bj)=OBSu(I,K,bi,bj)
>      &                              *_maskW(I,OB_Js(I,bi,bj),K,bi,bj)
>         vFld(I,OB_Js(I,bi,bj),K,bi,bj)=OBSv(I,K,bi,bj)
>      &                              *_maskS(I,OB_Js(I,bi,bj)+1,K,bi,bj)
>        ENDIF
In your case, OB_Js = 1 for all i, correct? That means, that 
vFld(:,1,:)=vFld(:,2,:)=OBSv(:,:).*maskS(:,2,:), so that maskS(:,1,:), 
which should really be 0 for most i, is never used.]
In solve_for_pressure.F, cg2d_b and cg2d_x are set to zero on the 
boundaries and hFacS/W are not used.

However, both in mom_fluxform and mom_vecinv, hfacs/hfacw are 
excessively used, so that I would agree, there is a problem with using 
OBCS. Have you tried to modify the hFac's in ini_masks_etc? After the 
line
CALL EXCH_UV_XYZ_RS(hFacC,hFacS,.FALSE.,myThid)
you could hack your hfacs according to your domain. Something like:
>       DO bj=myByLo(myThid), myByHi(myThid)
>        DO bi=myBxLo(myThid), myBxHi(myThid)
>         DO K=1, Nr
>          DO J=1-Oly,1
>           DO I=1-Olx,sNx+Olx
>            hFacS(I,J,K,bi,bj)=hFacS(I,2,K,bi,bj)
>           ENDDO
>          ENDDO
>          DO J=1-Oly,sNy+Oly
>           DO I=1-Olx,1
>            hFacW(I,J,K,bi,bj)=hFacW(2,J,K,bi,bj)
>           ENDDO
>          ENDDO
>         ENDDO
>        ENDDO
>       ENDDO
If the code survives such a such a fundamental modification, that is, 
if this fixes the problem, we should consider including it in the 
OBCS-package.

Martin

On Sep 9, 2005, at 11:53 PM, Thomas Haine wrote:

> Dear MITgcm Support,
>
> I'm confused by the following issue and suspect a bug, or at least the
> potential for unwary users to be seriously mislead:
>
> I'm running checkpoint57p_post with pkg/obcs and realistic bathymetry
> (Denmark Strait/Irminger Sea). My bathy looks roughly like:
>
>                     N
>    _______________________________________
>   |                  _______________/     |
>   |  LAND       ____/                     |
>   |        ____/                          |
>   |       /                              /|
>   |      /                              /l|
> W |    _/                               |a| E
>   |   /               OCEAN             |n|
>   |  /                                  |d|
>   | /                                    \|
>   |/                                      |
>   |                                       |
>   |_______________________________________|
>
>                       S
>
> There are open bcs on all four walls, but notice that they're all
> different. The problem is that hFacS(:,j=1,:) is set wrong (i.e. the
> southernmost wall should be entirely open). It's set to the hFacS of 
> the
> *northern* wall, which is almost closed. The other bounding hFacS/hFacW
> fields are OK (but presumably the problem would occur in different
> places with different bathy).
>
> The symptom, in my case, is that SSH rises by about 1m/day until the r*
> code crashes after a few days. This makes sense because the western
> Irminger Sea is draining the domain, but with the wrong hFacS only a
> small part of my obc is being applied here (at the eastern end). My
> calculations of the volume convergence with the wrong hFac's gives a 
> few
> Sv, which gives O(1)m/day increase in SSH, as I see. The obcs I'm
> applying with the correct boundaries have very small convergence,
> however, as I expect.
>
> The problem seems to be ini_masks_etc.F where the hFac's are set.
> There's no logic to deal with the case of obcs in a complex bathy such
> as mine. With obcs off wrapping the hFac's is correct (periodic bcs).
> With obcs on and simple bathy (same at opposite boundaries) it also
> works correctly. But wrapping for cases like mine looks either wrong or
> very misleading.
>
> Can I fiddle with the bathy and obc definitions (data.obcs) to fool the
> current code?  Or maybe ini_masks_etc.F needs to be more sophisticated?
> Other users should beware in any case. Previous versions of this 
> config.
> included a hack that relaxed mean ssh to zero to deal with drifting 
> ssh.
> Clearly, we should have worked harder to understand the cause of this
> problem, however.
>
> Cheers, Tom.
> P.S. Incidentally, with Leith, r*, and vec inv. mom eqns, my solutions,
> as far as they go, look exquisite!
> -- 
> --------------------------------------------
>  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
> --------------------------------------------
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support




More information about the MITgcm-support mailing list