A simple question about default obc in old version roms

[leonjld]

hi,

This question is related to older versions of ROMS (e.g. v3.3) when OBC was implemented as preprocessing options: if no option is undefined, e.g. for baroclinic velocity OBC. What will the default M3 OBC be? It seems the ROMS can run without problem even if baroclinic velocity and tracer OBC are not defined.

For example, I have:
......
#undef EASTERN_WALL
#define EAST_FSRADIATION
#define EAST_M2RADIATION
#undef EAST_M3RADIATION
#undef EAST_TRADIATION
......

and in the output it shows:

......
ASSUMED_SHAPE Using assumed-shape arrays.
DJ_GRADPS Parabolic Splines density Jacobian (Shchepetkin, 2002).
DOUBLE_PRECISION Double precision arithmetic.
EAST_FSRADIATION Eastern edge, free-surface, radiation condition.
EAST_M2RADIATION Eastern edge, 2D momentum, radiation condition.
GLS_MIXING Generic Length-Scale turbulence closure.
MIX_S_UV Mixing of momentum along constant S-surfaces.
NONLINEAR Nonlinear Model.
......


Thanks in advance!

[arango]

In the past, some users ignored the fact the we need to specify the open boundary conditions for all state variables. This is extremely important in ROMS because we used the deprecated WESTERN_WALL, EASTERN_WALL, SOUTHERN_WALL, and NORTHERN_WALL in other places in the kernel other than lateral boundary conditions. If none is specified, the default is closed (a wall). This can be checked easily by looking the files Build/u3dbc_im.f90 or Build/v3dbc_im.f90 for your application. In the source code it is handled with the #else CPP directive.

[leonjld]

thanks for the reply, Arango. So what happens if I have radiation 2D velocity obc and a closed wall 3D velocity bc? I feel the ubar/vbar and u/v are not consistent then, since ubar should be depth-averaged u?

[arango]

I have never tried that combination. I will never use that combination either. It is very inconsistent. I am not a fan of 2D radiation boundary conditions. You get into a lot of trouble with volume conservation because you dealing with gravity wave phenomena and the open boundary quickly becomes unstable. This problem is so ill posed mathematically and physically. You will get much better solutions with the Flather boundary conditions with uses the free-surface gradient. It is like 1D reduced physics boundary conditions (barotropic pressure gradient). You need to get the free-surface at the open boundary from a large scale model or a tidal model. For 3D momentum you clamp data from a large scale model. Open boundary conditions are very tricky and are application dependent ...

[tony1230]

Hi prof. Arango
On mention the OBCs, i was always confused by their combination of so many state variables. On Wikipage, we can find 6 types of OBCs

Gradient,Clamped,Flather,Chapman,Radiation and Wall

.But in the ocean.in file,there also exists Nested,Nudging,periodic and Reduced Physicstypes of OBC.Further more,there could be combinations(eg. RadNud) to each variable at each of the 4 boundaries.In some situations,i dont konw how to specify a OBC and i must understand under which condition that a designated OBC should be used. Are there files or documentations that be prepared for comprehension?

Thank you in advanced.

shou

[kate]

Like everything, it depends. What fields do you have to provide for boundary values? Just tides? Just tidal elevation? Some coarse global model? A global climatology? For the 2-D flow, we use tides from Oregon State, both elevation and velocity and we apply them with a Chapman-Flather combination. Note that this only uses the normal component of velocity from the boundary conditions.

For the 3-D flow, we found a montly climatology to be unsatisfactory many, many years ago. We now use results from SODA on five-day intervals - what's available online is only monthly. When Hernan talks about clamping, he's running that larger domain and can therefore save as often as he wants using station files. Also, clamping is *all* that works for the adjoint. Those not using the adjoint have more options.

[tony1230]

Hi kate, thank you for yr reply.
I have been running a two-boundary domain nested in a bigger domain with only eastern OBC posed there. I configured them as follows.
To the big domain,i just have elevation(using 8 tidal constituents)imposed on OBC without any currents(say 2D or 3D). Note that when i run the big domain,i used the old version of roms cpp-definitions.I defined Wall for 3 fixed laterals and a combination of FSCHANPMAN and M2REDUCED for OBC,since i had UV_TIDES and ADD_M2OBC bound.Here i had a combination type of Cha and Red to one boundary,if this,i have a question:All the state variables share the same type of BOC? As Hernan exposed that we need to give all the variables a designated type of OBC just as new version ocean.in file looks like.

To the nested domain,since i have elevation and currents calculated from the previous run,i imposed both of them on the open boundaries.This time i used the new version of roms and so got a bit of confused,especially by the combination type.West and South are closed type with no argue and East and North are open ones.For zeta,ubar and vbar,i gave them the Flather type of condition and gave the Chapman type to the rest.Though have all the variables specified,i also have doubts on whether the right definition they should or must require.Because i did not gave the 3D velocity to the open boundary,so i was wondering that i ought to impose a closed type to u and v even on open boundaries,am i right? And to temp,salt and tke the same.On this point,i really have a bit of trouble and expecting your suggestion for help.

Any suggestion or tip was appreciated.Thanks in advance.

shou

[wilkin]

Since you are using the new code for your inner domain, and using the logical flags LBC to set the boundary condition options, it's clear that all variables do NOT share the same boundary condition scheme because you have to set LBC for every state variable on every boundary in ocean.in.

What's not clear from the documentation in ocean.in is that certain options are available only to certain state variables.

Cha is only for zeta
Fla, Red are only for ubar and vbar

whereas
Per, Rad, Gra, Cla, Clo are for all

Other traps:
Nud can only used in conjunction with Rad, not on its own.
Nud cannot be added to other options, i.e. there is no ClaNud or RedNud etc.

The new code has the flexibility to add these combinations - to the extent that they would be rational - but as it stands we implemented only the options previously available by CPP directives and supported backward compatibility.

As suggested in posts to this thread, look at the t3dbc_im.f90 file in the Build directory to see what options you actually got. This would reveal, for example, that the ClaNud option had not worked.

For your application, your choices depend heavily on how often you saved output from the outer domain to provide information to the inner nest domain. If it was frequent enough to resolve the tidal frequencies well (no more than an hour interval?) you can give the zeta, ubar, vbar as the boundary data through ADD_??OBC and use Cha for zeta and Fla for ubar/vbar. I think this is what you are doing.

You do NOT want Clo for u,v, because you would have completely inconsistent depth integrated velocity. If you have high frequency interval u,v you could try Cla. If not, try Rad, (or even Gra), and hope the dynamics adjust. My preference would be RadNud since you have the u,v from the outer nest, but be aware that the Nud will be a filter that damps the flow somewhat so you have to make a sensible choice for the nudging time scale. Only you can determine the best choice from your own experience and analysis of the results you obtain.

[tony1230]

Thank you so much John

That is exactly what i want and extremely useful to me(and others).In my previous post,i really confused by these so much kind of OBCs and even their awesome combinations.I am sure we have to specify all the state variables a designated type of condition at each of the boundaries and that would and should be much more reasonable.And now i think there would be no question about OBCs that can baffle me with your exhaustive interpretation.

For your application, your choices depend heavily on how often you saved output from the outer domain to provide information to the inner nest domain.

Yes,i saved Zeta(also Ubar,Vbar,U,V) from the outer domain with a frequency of 3 mins and i deemed its enouth for providing the inner domain the state variables at open boundaries.

You do NOT want Clo for u,v, because you would have completely inconsistent depth integrated velocity. If you have high frequency interval u,v you could try Cla.

Indeed,i dont want WALLs for 3D u and v.But as mentioned above,i didnt konw how to define them as i haven't supplied the OB the u and v.Do you mean that if i provide u and v to OB,i could give them the Cla and if not i can try Rad or Gra and even RadNud?

Last point,how to define the OBCs for temperature and salinity, and for mixing turbulence kinetic energy(TKE)?

Thank you for all of your advices.
Best regards.

shou

[patrickm]

I think that this discussion demonstrates the fact that users should not have to choose their combination of OBCs (unless they really want to). in the ROMS_AGRIF version, there is a default set of choices which avoids a lot of trouble for users and a much faster start up.

concerning 2D radiative conditions, I tend to disagree with Hernan that radiative conditions are a bad choice. All these OBCs are ill-posed anyway in PE models. I always had smoother and better results (for non-tidal forcing cases) using 2D radiative conditions with a volume conservation constraint than with Flather conditions (as illustrated in our 2001 paper). However, the enforcement of volume constraint is tricky in a parallel code and when tides are involved, Flather-type conditions are much more appropriate. We therefore also use a Flather type (characteristic method) condition as a default, although that can easily be changed when tides are not considered.