East-west tidal currents issue

[jcharris]

I've been working on a model of tides / winds / waves off the coast of New England. Going back to the purely tidally-forced case and comparing to either the original input files or experimental data, I see that the north-south velocity and tidal elevations agree in magnitude and phase (with an error around 15-20 degrees, but this includes the model spin-up time, so the actual agreement may be better), and the east-west velocities have reasonable magnitudes but are out of phase by about 160-170 degrees -- essentially opposite of what they should be. Note that these observations are near the southern boundary of the domain.

I get a similar problem when I use either the regional OTPS forcing, or the US East coast ADCIRC database, as described in WikiROMS.

I would think that if I had made a mistake along the way, the error would be present in the north-south velocity as well or the tidal elevation, but it only appears to be the east-west velocity. Is there an obvious reason why there would be such an error? Or, failing that, what would be the typical thing to check next?

[jcharris]

To be more specific, it seems clearly to be an error in the phase angle of the velocity tangential to the boundary. Interestingly, the problem goes away using FSOBC_REDUCED (see the very simplified options below) -- if I change the options below only by switching FSOBC_REDUCED for UV_TIDES, though, the problem returns.

I'm assuming this is an error in my understanding of the boundary condition options? Has anyone encountered an issue like this?

(Strangely, I can re-run the simulation with UV_TIDES, manually changing the phase of the east-west velocity in the input file by 180 degrees, and the results so far appear to not be effected substantially.)

#define UV_COR
#define UV_VIS2
#define UV_QDRAG
#define OUT_DOUBLE
#define CURVGRID
#define MASKING
#define STATIONS
#define WET_DRY
#define ANA_INITIAL
#define ANA_SMFLUX
#define ANA_FSOBC
#define ANA_M2OBC

#define RAMP_TIDES
#define SSH_TIDES
#define FSOBC_REDUCED

#define EAST_FSCHAPMAN
#define WEST_FSCHAPMAN
#define SOUTH_FSCHAPMAN
#define NORTH_FSCHAPMAN
#define EAST_M2FLATHER
#define WEST_M2FLATHER
#define SOUTH_M2FLATHER
#define NORTH_M2FLATHER

[BAN]

Hi
I use a quite similar setup, and also use OTPS forcing. I observed that including currents gave a clear deviation from the forcing already at the model boundary, whereas the reduced physics option gave better fit with the forcing. I tried out some alternatives to FSCHAPMAN/M2FLATHER but the results were much the same.

The first plot (run 20) shows the surface M2 amplitude/phase of forcing (black) vs. ROMS (red) when using FSOBC_REDUCED. The second plot (run 21) is from a equivalent model run using UV_TIDES.

Some questions:
How many constituents are you using?
Is there a phase lag in all of them or just in some?
How does this change when using reduced physics?
Do you have a plot which illustrates the problem?

[jcharris]

Thank you for the information. I don't have a plot illustrating the problem at the moment, but I can easily provide tabulated results for a station very close to the boundary which I will post in the next day or so. If it would be more helpful, I would also be interested in posting figures equivalent to yours -- how are you going about producing the amplitude/phase diagrams for the boundaries that you displayed?

Out of curiosity, did you then have any stability issues when using FSOBC_REDUCED? (e.g., would it be reasonable to use FSOBC_REDUCED, in order to get the currents correct, and then apply nudging in order to keep the currents on the boundary from diverging too much from the forcing?) For my final application, I need to make use of one of the BBL models (e.g., SSW_BBL) in order to include wave-coupling in a meaningful way, and I find that the model blows up at the boundary when I use FSOBC_REDUCED, but the model runs (longer, at least) with UV_TIDES.

[BAN]

The tabulated results will be fine, but a plot of the model domain and measurement locations would make the picture clearer.

What I did was to save current and surface every hour via his files, convert into time series, run t_tide on all model points i.e. I have tidal constituents in all model points, but only plot values along the boundaries.

If you surf this forum you will notice that it is a common problem with getting the reference/model time right for the tidal routine i.e. the resulting phases will be wrong. I don't know if you also have this problem. For a single tidal constituent this means that

Amp * sin( 2*pi/Period * Time - Phase )

becomes

Amp * sin( 2*pi/Period * (Time + RefTime) - Phase )

= Amp * sin( 2*pi/Period * Time - Phase + Phase_RefTime)

It is also a good idea to check forcing data directly against measurements. Do the nodal corrections of the forcing make it better or worse relative to the data? Make sure that the problem is not in pre- or post-processing.

So far I have not had stability issues caused by FSOBS_REDUCED (but several stability issues due to model grid), and I have no experience with nudging or wave coupling, so I can offer no advice on these issues.

[leonjld]

I believe it will be useful if you check your tidal forcing netcdf files to see how the M2 current phase changes over the domain (when doing this you need to consider the inclination of the M2 current ellipse). You can even compare the forcing with your response by extracting the M2 current from your model results using harmonic analysis (e.g. t_tide).

Also I somehow believe current forcing in OTPS is less reliable, since it gives patchy and discontinuous results when you visualize it. While the current in ADCIRC tidal database is better since it's the output of a model (forced by OTPS at boundaries), smooth and consistent. But since you tried both forcings, then it should not be due to the OTPS current forcing.

[jcharris]

Apologies for the lengthy pause between replies... have been very busy with other projects. To answer the earlier questions, the model is forced with the S2, M2, K1, and O1 terms. I plan on adding back in a few others once the problem is solved, but I'm trying to use about as simple a test case for debugging purposes as possible, which is why I'm only considering the 2D case here.

To illustrate the problem, I'm attaching two figures: one of the domain (black grid is the ROMS domain; red dashed area is the area of interest); the other is similar to yours, but for all three components (elevation, U-bar, V-bar) on the southern border of the domain. X-axis is grid point number, and the grid spacing is an constant 600m for the entire domain. The comparisons of the tides was done by simulating one week, and saving history files each hour. I'm not expecting an exact match because of the crude way I processed the data for the graph, but I would expect a better agreement with the phase of ubar when UV_TIDES is used. (The problem is that in the area of interest, around 300-450 on these graphs, the ubar phase is very different than the input.)

Perhaps it is a mismatch between the tidal database and what ROMS "expects" around the islands on the eastern side of the domain, so a larger domain is needed? Or is there a more fundamental issue with the setup?

[crowley]

You may want to try adding the N2 constituent. For the elevation it is at least as large as the S2 and larger than both the K1 and O1, within Long Island Sound anyway.

Is the East River resolved in your grid? The tidal forcing through the East River and the western end of LIS is an important component of the whole picture. What do your tides look like in the western portion of the Sound?