Open Boudary Conditions: Inflow

[koesters]

Dear ROMS users,

I am trying to prescribe an inflow at one of my (open) boundaries. As far as I understand this can be done with the NORTH_M3NUDGING switch in cppdefs.h and setting the nudging coefficients. This doesn't seem to work as I would have expected.

Has anyone experience setting this up ?

Furthermore, the GENT McWilliams is set up to work with epineutral (iso_mix_ts) mixing only, is there a special reason for that ?

Regards,

Frank.

[dupontf]

Has anyone tried a testcase similar to the Chapman paper (JPO, 1985) in a 2D/3D setup?

(A wind blowing along a shelf break with radiative BCs on both inflow/outflow; north and south bdy closed)

From our experience, for the 2D case, the available BCs don't seem to reproduce the desired result. In the end I decided to move the computation of the radiated variables one point inside the domain plus gradient condition right at the boundaryy and then ROMS would converge to the desired solution.

The same approach unfortunately failed in the 3D case for reasons still unclear to me. I have the feeling that I don't understand how ROMS treats the last (or two) rows of points before the boundary. For instance, if the channel is oriented west-east, there should not be any need for u (eastward velocity) BCs, since there are already one for zeta and v.

Any help welcome!

Fred.

[m.hadfield]

has anyone tried a testcase similar to the Chapman paper (JPO, 1985) in a 2d/3d setup? (A wind blowing along a shelf break with radiative BCs on both inflow/outflow; north and south bdy closed)

From our experience,for the 2d case, the available BCs don't seem to reproduce the desired result. In the end i decided to move the computation of the radiated variables one point inside the domain plus gradient condition right at the bdy and then ROMS would converge to the desired solution.

Sorry for not replying sooner. I only just discovered the forums. I observed this some time ago and wrote it up in a page that I occasionally put on the WWW:

ftp://ftp.niwa.co.nz/incoming/m.hadfiel ... index.html

It's a bit embarassing to read some of this stuff now--can't believe how thick I was. But it might be worth your while to have a look at it.

I never did work out why ROMS boundary conditions are sticky. I suspected, and you have confirmed, that it has something to do with staggering of variables near the boundary.

The same approach unfortunately failed in the 3d case for reasons still unclear to me. I have the feeling that i don't understand how ROMS treats the last (or two) rows of points before the bdy. For instance, if the channel is oriented west-east, there should not be any need for u (eastward velocity) BCs, since there are already one for zeta and v.

Don't get too hung up on this issue. Some of the ROMS variables in the rows near the boundary do not get used for anything much. they're just along for the ride. This means that some of the ROMS boundary options have very little effect.

Mark Hadfield
NIWA

[m.hadfield]

Currently the boundary in ROMS goes through normal-velocity points (by which I mean that velocity normal to the boundary is supplied by the boundary condition--wall, clamped, radiative or whatever--and the zeta and transverse-velocity points immediately inside thsi are calcualted via dynamic equations

I believe there are some situations (mainly coastal) in which it would be desirable to have the ROMS boundary go through the row of zeta and transverse-velocity points. This would allow

• Clamped-zeta boundary conditions. (With the current layout one could clamp zeta on the outer row of zeta-points, but it will have negligible effect on the flow.)

• Radiative BCs will not be as resistive to normal flow as they are now, eg in the Chapman test case.

It's not clear to me how hard it is to do this. Fred Dupont apears to have done it already. Fred, do you think it would be feasible to merge your changes back into the ROMS code as an option?

[dupontf]

Yes, it would be desirable and somewhat more intiutive to be able to use Dirichlet boundary condition for elevation. Tidal applications are one reason. (I think someone mentioned this problem already in this forum).

Roms has been written with the idea of using spunge layers to enforce the BCs instead of Dirichlet OBCs, probably with the goal-end of nesting grids. The side effect is that locating what is the last row of points dynamically active is not trivial. I played around last year with ROMS 1.7.3 and guessed that some discrepancy exists in the way the 2d and 3d modes are treated in that respect (just a wild guess).

I would suggest a careful check of the dynamic equations 2d-3d to ensure that they are applied to the last row of points (it is not always possible for all the terms) at least for the pressure gradient, wind forcing and bottom drag, so that users can implement their own OBCs. I would not suggest to use my modifications to ROMS since they only partially worked (and they are very crude!) and i don't know how they would apply anyway to the latest version.

What Arango would think of that?

Fred.

[kate]

There is a grad student here asking me how to apply a long-shore sea-surface tilt. He wants to specify the zeta boundary condition, which is exactly this problem, right? Is he out of luck?

Kate (and Jeremy Kaspar)

[arango]

This issue has come up several times. In ROMS, because of the C-grid stencil, the actual domain boundaries occurs at i=1 and i=Mm (southern and northern edges) and j=1 and j=Lm (western and eastern edges). This is where you find the normal (perpendicular) boundaries for v- and u-momentum, respectively. The other non-physical points are defined outside these edges to evaluate correctly the fluxes at the physical boundaries.

The free surface in models like ROMS, is computed from the barotropic continuity equation. It is an expression for the time-rate-of-change of the barotropic momentum divergence. If you follow the free-surface in ROMS, you will notice that its values at the non-physical points are only used to compute total depth and associated variables. The non-physical points of these variables are only relevant in the computation of horizontal viscosity and diffusion. Its values do not enter in the computation of the barotropic velocity divergence. Therefore, it is not a good idea to prescribe any barotropic inflow condition in terms of free-surface. In tidal forcing, we need to specify both tidal elevation and currents.

Now, I am very aware that we do not always have tidal elevation and currents. Also is easier to specify elevation than currents at the boundary. We (John Warner, Mark Hadfield and I) have been looking at this problem and trying to find solutions to all these issues. We have incorporate new options to the code to allow such forcing from free-surface at the open boundary.

In tidal forcing, we added a new option UV_REDUCED in which the tidal currents are computed from tidal elevation at the boundary using reduced physics where the important terms are pressure gradient, Coriolis, and surface and bottom stresses. We also added the reduced-physics barotropic boundary conditions: EAST_M2REDUCED, WEST_M2REDUCED, SOUTH_M2REDUCED, and NORTH_M2REDUCED. These options can be combined with at prescribed (clamped) free-surface at the open boundary to obtain the desired behavior mentioned in the above postings.

We are currently testing these options and they will be available in the next release of ROMS (version 2.2). I still don't know when this version will be released. I hope in a couple of months. There is a lot of new stuff coming. If you are interested on some of the above updates and cannot wait for the next release, please send me an e-mail and I will send you the relevant codes.

[m.hadfield]

Just a minor follow-up to Hernan's post. I have tested the prototype xxxx_M2REDUCED options in a number of situations (all 2D-only) and can confirm that they work as expected. They combine well with the xxxx_FSCLAMPED option (when you want to prescribe zeta) and with xxxx_FSCHAPMAN (when you want a passive boundary that allows normal flow--eq the Chapman wind-forced test).

[wmartin]

I have a question along these lines. Basically, What is the relationship/ interdependence between tidal forcing and the climatology codes. I have been doing a bunch of simple runs in a non-rotating, unstratified, rectagular channel just to understand how the tidal forcing and OBC's work. I am using Flather and Chapman, but at first I just used Analytic.F to set ubar and zeta OBC's. In one case I defined condtions for a standing wave with ubar > 0 and zeta = 0 at the ends of a channel that was one wave-length long. Instead the system "chose" a mode where there was both ubar and zeta at the ends and the nodes were at the .25 and .75 wavelenght points. Even when I clamped zeta at the ends, the interior points went right back to the same motions as before. However, when I put the same forcing into a forcing file and used it with the full tide system, clm_tides, climatology etc. I got the wave I expected. I've looked at those codes but I don't really get it. Is it actually nudging that pushes the sytem into a particular solution and holds it there? If so, how much is enough? Why does it prefer one mode over another so strongly when I used just analytic.F. I'd like to better understand what is causing the system to respond this way so I can evaluate how well my tidal forcing is working.
Thanks for your thoughts.
Wayne

[jivica]

Well I just wonder
what to #def and #undef for specifying only TIDE_SSH
and not TIDE_UV?? but to be able to use FLATER OBC?
Thnks!
ivica

[rsignell]

Ivica's question got me wondering:

It looks like the XXXX_M2REDUCED option will allow you to specify elevation at the open boundary and have the depth-averaged velocity at the open boundary determined by the reduced physics approximation.

It should also be possible to specify depth-averaged velocity at the boundary and have the elevation at the open boundary determined by reduced physics, but it doesn't look like this is an option in ROMS2.2.

Is this correct?

Thanks,
Rich

[m.hadfield]

A belated reply to Rich's post of 1 Dec 2006...

You can specify velocity at the boundary with xxx_M2CLAMPED and xxx_M3CLAMPED. The (normal) velocity values will then be used in the calculations for zeta at the rho points immediately inside the boundary, with almost-full physics, by which I mean the pressure-gradient terms are not simplified, but the model does have to invent zeta values at the rho points immediately outside the boundary for advection and diffusion. For this purpose xxx_FSCHAPMAN seems to do the trick.

In other words, what I am saying is that ROMS is already set up nicely for applying boundary conditions on velocity, less so on zeta.

Does this make sense?