Default Boundary Conditons?

General scientific issues regarding ROMS

Moderators: arango, robertson

Post Reply
Message
Author
black

Default Boundary Conditons?

#1 Post by black » Fri Mar 17, 2006 7:12 pm

What are the default boundary conditions for ROMS? I wouldn't think ROMS would have default BC's but when looking at several of the example configurations I noticed that some (Seamount in particular) do not specify BCs. Why? And what is ROMS doing when no boundary condtions are assgined?

User avatar
shchepet
Posts: 185
Joined: Fri Nov 14, 2003 4:57 pm

RE: default boundary conditions...

#2 Post by shchepet » Mon Mar 20, 2006 7:40 pm

This reply is not a to be understood as statement of policy, but rather explanation of de-facto settled practices.

If no boundary conditions are specified, then it means that they are CLOSED everywhere. It means: (1) no normal flow; (2) Neumann (zero-gradient extrapolation rule) for T,S; and (3) either free-slip, or no-slip for tangential velocity, depending on input parameter gamma2.

Starting with this default, the boundary conditions may be SELECTIVELY changed to either

OPEN [by setting OBC_WEST ...EAST ....SOUTH ...NORTH] on each side independently;

or

PERIODIC [EW_... or NS_PERIODIC] obviously pairwise, i.e., EW_PERIODIC affects both east and west sides.

Within the OPEN class there is a rich choice of sub-classes (Orlanski, Flather, clamped, reduced physics etc... --- some of them experimental, and some even ill-posed).

In principle, THERE MUST BE NO DEFAULT within the OPEN class, i.e., if you say OPEN you must also specify WHAT KIND OF open boundary you want.

...But, for a very long time, and as a manner of bad policy, we made GRADIENT boundary conditions to play the role of default open boundary. Then we were receiving e-mails saying "I defined open boundary [and nothing else] and model blows up!" Of course it blows up, because it should blow up --- otherwise there is something wrong with the code.

...I checked the most recent official Rutgers code and found that it is still possible to specify SOUTH_M2GRADIENT which would result in code like

Code: Select all

        DO i=Istr,Iend
          vbar(i,Jstr,kout)=vbar(i,Jstr+1,kout)
#  ifdef MASKING
          vbar(i,Jstr,kout)=vbar(i,Jstr,kout)*GRID(ng)%vmask(i,Jstr)
#  endif
        ENDDO
and subsequent blow up because of fundamental ill-posedness.

black

#3 Post by black » Mon Mar 20, 2006 8:34 pm

Thank you for the explanation. That was exactly the information I was looking for.
Now is there a central reference that explains the options for open boundary conditions and when each one is appropriate. I figure I will just start trying them and see which one gives me good results (unfortunately the understanding of which will probably come much later).

User avatar
kate
Posts: 3780
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

#4 Post by kate » Wed Mar 22, 2006 8:52 pm

Maybe you should tell us what problem you are trying to solve and then we can suggest things to try. Walls work, the periodic boundaries work, open boundaries are a big mess of trial and error. If you can define your problem in terms of a closed domain, go for it.

For open boundaries, do you need tides? Do you have boundary information to provide the model? We've had far better luck with daily info from a larger domain than with monthly climatologies.

goutam

Re: RE: default boundary conditions...

#5 Post by goutam » Fri Mar 24, 2006 6:48 pm

shchepet wrote: If no boundary conditions are specified, then it means that they are CLOSED everywhere. It means: (1) no normal flow; (2) Neumann (zero-gradient extrapolation rule) for T,S; and (3) either free-slip, or no-slip for tangential velocity, depending on input parameter gamma2.

Starting with this default, the boundary conditions may be SELECTIVELY changed to either

OPEN [by setting OBC_WEST ...EAST ....SOUTH ...NORTH] on each side independently;

or

PERIODIC [EW_... or NS_PERIODIC] obviously pairwise, i.e., EW_PERIODIC affects both east and west sides.
I am using ROMS 2.2. In cppdefs.h, I don't find
OBC_WEST
OBC_EAST
OBC_SOUTH
OBC_NORTH

what I find is
EASTERN_WALL
WESTERN_WALL
NORTHERN_WALL
SOUTHERN_WALL

So does this mean that in ROMS 2.2, if no boundary conditions are specified, then it is open everywhere, unlike as stated above?

Thanks
Goutam

User avatar
kate
Posts: 3780
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

#6 Post by kate » Fri Mar 24, 2006 11:59 pm

In Include/globaldefs.h:

#if (defined NORTH_M3RADIATION && defined NORTH_M3NUDGING) || \
defined NORTH_M3CLAMPED
# define NORTH_M3OBC
#endif

# if defined WEST_FSOBC || defined EAST_FSOBC || \
defined SOUTH_FSOBC || defined NORTH_FSOBC || \
defined WEST_M2OBC || defined EAST_M2OBC || \
defined SOUTH_M2OBC || defined NORTH_M2OBC || \
defined WEST_M3OBC || defined EAST_M3OBC || \
defined SOUTH_M3OBC || defined NORTH_M3OBC || \
defined WEST_TOBC || defined EAST_TOBC || \
defined SOUTH_TOBC || defined NORTH_TOBC
# define OBC
# endif

If OBC is #defined, it will look for an open boundary condition file.

In Nonlinear/t3dbc_im.F:

# if defined WEST_TRADIATION
# elif defined WEST_TCLAMPED
# elif defined WEST_TGRADIENT
# else
!
! Western edge, closed boundary condition.
!
!# endif

The default is closed. You can always check the t3dbc_im.f90 file to see what's left after the C preprocessor has been through.

goutam

#7 Post by goutam » Mon Mar 27, 2006 10:34 am

So if the default is closed then what is the use of these options in cppdefs.h :-
EASTERN_WALL
WESTERN_WALL
NORTHERN_WALL
SOUTHERN_WALL

Can you please explain?
Thanks
Goutam

User avatar
kate
Posts: 3780
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

#8 Post by kate » Mon Mar 27, 2006 5:52 pm

grep is your friend in these situations. Doing a grep for EASTERN_WALL on all the files will show you where it is used. It is used in the biharmonic operators when setting the boundary contition on the Laplacian intermediate result.

Post Reply