ROMS + SWAN with nesting : obvious error in the results

[fransUgent]

Good day!

We are busy producing a coupled + nested ROMS + SWAN model. To date we have successfully:
1: Coupled ROMS to SWAN without refinement
2: Run ROMS with refinement
3. Run SWAN without nesting in ROMS
4. Run native SWAN with nesting (NESTout, BOUNDNEST1, etc.)

All the runs above compare relatively well to measurements (wave, tide, etc.)

Currently we are testing a refined SWAN run in ROMS
#define SWAN_MODEL and #define NESTING

The model is forced with wind forcing only (across the whole domain of Large (coarse) and small (refinement) grids)
The model runs well in terms of calculations.
However, when the calculated HSIGN (and TP) is compared to the measured data, an #undef NESTING (large grid) run and a native SWAN run the results shows an extreme over estimation of the HSIGN. The attached plot shows the measurements, SWAN only, ROMS SWAN_MODEL unrefined (no nesting) and ROMS SWAN NESTING. This problem is also present when coupling SWAN to ROMS with refinement.

I am using the COAWST roms.

I have looked at:
1. A "similar" problem and implemented John's suggestions (viewtopic.php?f=24&t=5054&p=19604&hilit ... ing#p19604
2. The COAWST sandy and inlet_test (SWAN) only cases and I cannot see any significant difference between my SWAN input files and the previous mentioned examples.
3. Spinning up the wind over 12 hours (shown in this plot)

Has someone encountered the same problem ?

Thanks

Frans van Eeden

[jcwarner]

ok. i think i understand what the issue is.
If you just run SWAN by itself with NESTING (swan with 2 grids) you are getting an Hsig that is very large compared to SWAN by itself and other similar tests. Here are some suggestions:
- do a pcolor of Hsig from the parent, hold on, pcolor hsig from child. that can help see spatial differences.
- what is LIM 10 1 in parent INPUT file (some computational limiter). try without that.
- seems like you are making a new wind forc file for each grid. Suggest you just make a wind file large enough for the full domain, unrotated, and use that for both grids. You might need to make a copy for the child grid, as some systems cant open Ascii files twice at the same time.

if you want to send the pcolor to me at jcwarner@usgs.gov we can get this resolved then you can post here what the solution was.
thanks
john

[fransUgent]

Hi John,

Thanks for the quick reply. I had a look at your suggestions with the following results:
1. See attached results. The Nested large and smaller grid Hsig calculations are consistent with each other (no clear offset or weird spatial issues). I have included, for reference, Hsig plot of a non-nested run, which agrees with the measurements. AS can be seen from comparing the Nested results with the NON-nested HSIGN results, the wave heights differ significantly but the overall wave patterns are consistent with each other. It is as if the effect of the wind forcing on the energy transfer is amplified in some way. I have not checked if there is some kind of correlation between the HSIGN of the NEsted and the NON-Nested (I will do that tomorrow)

2. The LIMiter option has no effect on the results.

3. The grid is curve linear and as such the wind files must correspond to the CGRID CURV COORD (curvelinear cannot be interpolated like on a regular grid). My wind forcing files are interpolated from the same source (ECMWF) and as such are consistent with each other temporally and spatially. I do notice that the SANDY case is on a regular grid. Could the fact that the wind is on a CURVElinear grid be an issue ? I notice in the SWAN use manual that for INPgrid it is stated that "For a CURVILINEAR input (not fully tested for spherical coordinates)" However, I have run a nested native SWAN run and the results are consistent with the measurements, which at least shows that for this statement is not necessarily a factor in the native SWAN Nested case.

I will attempt tomorrow to run the nested grid with a regular grid (as opposed to CURV) and see if it makes a difference in addition to checking if there is some correlation between the ROMS nested and SWAN nested difference in HSIG results.

Thanks for your thoughts. It is much appreciated. I will post my findings if they are worthwhile.

Frans van Eeden

[jcwarner]

BLOCK 'COMPGRID' NOHEADER 'NorthSea_wind.mat' LAY 4 WIND 1. OUTPUT 20110101.000000 1 HR
BLOCK 'COMPGRID' NOHEADER 'NorthSea_nest_wind.mat' LAY 4 WIND 1. OUTPUT 20110101.000000 1 HR

how about pcolor or quiver of the winds?
-j

[fransUgent]

Hi John (and all other subsequent readers)

After quite a few tests I have figured it out. in the nested input file (nested file only), white capping is the culprit. Basically three options exist
a) WCAP: this produces an error in the run (screen dump attached compiled with debug on) and the programme does not run. I then moved to set WCAP to OFF in order to get the program to run (and, subsequently where the mistake in the HSIGN crept in ).
b) WCAP OFF: Obviously this will allow more energy into the system (or not damp the wave energy) leading to an increase in HSIGN; and
c) &WCAP (or $WCAP in SWAN native): commenting out the WCAP option (or leaving it out) activates WCAP in the background but does not produce the error in (a).

Obviously the solution is to leave WCAP out of the file unless you have a good reason to set it to OFF WCAP.

Thanks for the help.