Question about the tidal forcing

[susonic]

Hi all,
While I was trying to add tidal forcing, I came to see that the ROMS is using both surface hieght and depth-averaged velocity boundary conditions in tidal forcing. I think that using both the height and velocity boundary conditions might lead into trouble due to the inconsistence between the surface height and velocity because the surface height and velocity are linked by the momentum equation. Is tidal forcing generally applied as only surface height at open boudaries?

Any comments would be appreciated.
Thanks in advance.

-Peter

[kate]

I generally apply the tidal boundary conditions as both elevation and velocity. Both fields come from a global tidal simulation, so ought to be dynamically consistent.

[arango]

Actually, in ROMS you need both tidal elevation (m) and tidal currents (m/s) This has been discussed before in this forum. The actual governing equation in ROMS are the vertical-integrated momentum equations. The free-surface equation is computed from the divergence of (ubar, vbar), that is, the vertically integrated continuity equation. The tidal forcing is applied using a combination of the Flather and Chapman conditions. If the currents are not available you can use the FSOBC_REDUCED. See set_tides.F, u2dbc_im.F, v2dbc_im.F, and zetabc.F.

Applying tidal forcing at the free-surface boundaries does not do much. These points are only used in larger stencils like viscosity and diffusion. Recal that ROMS is discritized on a C-grid. If you really need tidal forcing you need to specify such forcing in both 2D momentum and free-surface. This kind of forcing is optimal for data from tidal models.

[m.hadfield]

To amplify on Hernan's reply, the following graph shows the ROMS horizontal grid structure. The solid circles are the "rho" points where SSH is evaluated, the open circles are the points where the velocities are evaluated (blue for U, green for V).

Schematic diagram of ROMS horizontal grid layout.

ROMS_horizontal_grid.png (8.07 KiB) Viewed 3520 times

The red line marks the model's normal-velocity boundary. When a wall boundary condition is in effect, it is applied by setting normal velocity to zero on the red line. When one of the various open boundary conditions is in effect, points on and outside the red line are calculated by the boundary condition code. You can see that setting the SSH at the outer edge of the model is not going to affect flow in the interior significantly unless the code that calculates the boundary normal velocity (on the red line) responds to this SSH somehow.

The normal way of specifying tides in ROMS is to supply data for both depth-averaged tidal velocity and tidal SSH at the boundary, and activate the M2FLATHER and FSCHAPMAN options. The M2FLATHER boundary condition feeds the tidal velocity & SSH into the momentum at the boundary using a simple relationship based on the external wave equation. You can think of a Flather boundary as having an impedance to normal flow of h/sqrt(g h).

As Hernan says, the FSOBC_REDUCED option is intended to cope with the case where tidal velocity is not available. I confess that I've never been able to understand how it's supposed to work. There's an example of its use in the INLET_TEST case.

The M2REDUCED boundary condition is also intended to cope with the case where tidal velocity is not available. It calculates the normal velocity on the boundary with a simplified (reduced-physics) momentum equation.

M2REDUCED works only when SOLVE3D is undefined, as it does not include a contribution for depth-integrated pressure gradients due to density differences. In principle, these effects could be added and a corresponding M3REDUCED boundary condition could also be written.