Lateral Boundary Zeta wall of water

[itswx]

Hello!

I am hitting an issue trying to implement boundary conditions with HYCOM data, where the zeta boundary condition reaches insane heights on the second time step, sending a wave across the domain, destroying lives and, worse, blowing up the model.
On the first time step, It seems to read the data in just fine. Zeta values along the boundary in question are ~-2 meters for most points, which is reflected in my boundary condition file:

1st timestep, looks nice

However at the second step, the Zeta values at the boundary jump to 50-60 meters:

2nd timestep, insane values

Which spikes the surface height across the domain:

NaN wave

Checking my boundary condition file for this time, there are no such values along the boundary. ROMS itself confirms this, as before the second time stamp it logs:

Code: Select all

GET_NGFLD_NF90   - free-surface eastern boundary condition,             2026-03-20 01:00:00.00
                      (Grid= 01, Rec=110, Index=2, File: bdry_Narragansett.nc)
                      (Tmin=      20527.5000 Tmax=      20535.5000)   t =      20532.0417
                      (Min = -2.56999999E-01 Max = -2.45000005E-01)

Reasonable and expected values. Does anyone have any idea what could be causing this issue?
Thanks!

[jcwarner]

did you check ubar, vbar, salt, temp?
is that your eastern boundary? looks like southern.

[itswx]

did you check ubar, vbar, salt, temp?
is that your eastern boundary? looks like southern.

Yeah, when I made the grid I accidentally made it rotated 90 degrees, so in ROMS coordinate terms south is east.

I am not providing boundary conditions for salt and temperature nor writing them out, this is primarily for current simulations so I'm not really concerned with them. For ubar/vbar, the model crashes whether I use clamped boundaries for these values or not, though the model limps along a little longer if I use a gradient condition because the huge wave does not propagate as readily.

[itswx]

Feel I should post a follow up for posterity. This issue was totally my fault, my tidal data was in cm instead of m. I did NOT see this issue on testing with tidal forcing without boundary conditions, unsure as to why. It could have been I changed build flags between tests and forgot, so my tidal data was not having the impact I believed in the first test. Regardless, if you, future user, face this issue, it may be worth looking into your tidal data even if it seemed to have worked fine on other tests.

[jcwarner]

thanks for posting that the issue has been resolved!
glad you got it to work.

[arango]

Yes, it is always a good idea to check ROMS logs carefully for the range of values processed when reading data. ROMS uses metric (MKS) units. Recall that NASA lost the 125 million dollar Mars Climate Orbiter because one of the engineers coded the algorithm with the wrong units instead of MKS.