Ocean Modeling Discussion

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 ...

I've run ROMS on a Mac Pro with no problems. There were some issues initially, but nothing that I imagine would be different from getting started with ROMS on any other system. If you have any more specific questions I'd be glad to try to answer them.

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 ...

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 ...

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 ...

Alternatively, is there an easy way to use a simple bottom stress model, but modify the code to determine sediment suspension with the local wave parameters via wave-current interaction (i.e., use UV_QDRAG as a momentum boundary condition, but SSW_BBL as a suspended sediment boundary condition)?

I am attempting to model suspended sediment in a coastal area. When forcing a coupled ROMS/SWAN run with tides, winds, and waves, I have found that using UV_QDRAG has worked successfully in many model grids. Since I expect that the waves have a significant effect on the BBL in the area, I expect ...

Doesn't the section copied below from Utility/get_grid.F indicate that if EASYGRID is modified to store the rotation angle, it should be saved in radians, not degrees? ! ! Read in angle (radians) between XI-axis and EAST at RHO-points. ! CASE ('angle') gtype=r2dvar status=nf_fread2d(ng, model ...

If I understand the situation, I have experienced this as well with gfortran 4.5.0 (20090604; experimental; trunk rev. 148180). Commenting the statement in Master/mct_roms_swan.h does fix the problem, and does not cause any problems during the simulation. However, post-processing may have an issue ...

It is not how the others failed. The others failed with e.g., a segmentation fault. I have tried recompiling with gfortran, and that fixes my original problems. I may return to try using Absoft in the future and figuring out what the problem is, and so I would be curious if there were standard ...

Thanks. If it is of interest to anyone, I have learned that there is an obscure Absoft compiler bug ("with a variable length character return for a used module procedure when the size is determined by nested structures") which is the issue in this case.

I don't believe it is a (system) memory limitation, but I will check on this, and if I can't solve it soon may try a different compiler. I am able to run the BENCHMARK test with the small grid, but it does not work with the medium or large grids (failing at successively earlier points). If I run ...

I've encountered two errors that I can't seem to explain, both of which appear when I move from a small grid (240x160x10) to something larger for a real application. Gridding issue: --- With a 240x160 grid and a purely tidally forced domain (i.e., no input files which depend on the number of levels ...

When ROMS was still using MCT version 2.2, I was able to use it without issue. When / if I update my distribution to the new version using MCT 2.6, the same commands (on a 2 x 2.93 GHz Quad-Core Intel Xeon system with OS X 10.5.8 using Absoft Pro Fortran 10.2.1), though, I get an error. [I sent a ...

Defining WET_DRY appears to have done the trick, or at least allows the model to keep running; I will double-check that no other problems have formed. It did not occur to me that the tides might be large enough to cause negative values of depth, especially since I thought I had seen warnings about ...

I have been running some simulations of a moderate (~1 km) resolution of a coastal area (southern New England), at the moment strictly with a tidal forcing. While I have been able to get reasonable initial results, I seem to have a problem with model blow-up that I haven't solved, and am hoping ...

It seems worth mentioning that line 50 of the standard build script is not compatible with OS X, which does not support 'grep -P'. Perhaps this change would be useful: # test=`echo $1 | grep -P '^\d+$'` test=`echo $1 | egrep '^[[:digit:]]+$'` Although I have not finished getting ROMS working with ...