[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