ROMS + SWAN with nesting : error on the child grid

[Eugen]

Dear ROMS users,

I run ROMS + SWAN in coupling using MCT library on two grids, one inside of another, in two way nesting.

I'm sure about the wave results on the coarse grid. However, the fine resolution grid does not behave on the way I expect it.

Here is a picture of the significant wave height on the coarse grid with superimposed resuls from the fine grid. I clearly see:

1) There is a masked area on the right boundary of the fine grid.
2) Also, the upper boundary seems to not function at all, even it is open

Could you tell please, from where does this error probably come from? Does it come from the wrong scrip interpolation? Or I defined something wrong in the swan.in ?

I tried to play with time steps, as well as several times checked grid dimensions in swan input files, verifying them with the Sandy test case, and still did not spot an error.

[jcwarner]

how long into the model run is this? it may take some time for information to propagate into the child.
this depends on the initial conditions. Also, do you have the same winds on both swan grids? you can use copy the parent wind grid to put on the child.
-john

[Eugen]

Hi, John.

This is a snapshot after 11 hours.

But the model can go 30 days without explosion, just the results on the child grid have a little connection to the parent.

About winds: I use the same regular ECMWF grid with winds for both of my grids. I tried to run with having winds on both grids, and only on the parent - the results seem to be equally nonsense for the child grid.

If I have information "Map 1 weight < 0" while doing interpolation between grids with using the SCRIP library, does it mean, that something went wrong and weights don't have sense?

Could you have a look on my SCRIP log please?

[jcwarner]

the winds should be important for the child.
can you send to me both of your swan input files?
jcwarner@usgs.gov

[Eugen]

Thanks John,

Here they are:

[jcwarner]

some things to try:
- run it with just swan with 2 grids, not coupled.
- do the currents in both grids look continuous?
- try to run the swan files with
INIT
in both of them. this will help the child grid to have some init conditions. if you run the swan without any init commands, it can take a long time for the grid to develop waves because the wave growth term has a function like hnew=hinit+hold*exp(A)
but if no waves are there to start with, it takes a while to grow them.

-j

[Eugen]

Thanks, John !

I'll try your suggestions and tell the result

[Eugen]

Hi John,

1) I run SWAN grids without ROMS. No numerical errors and "zero" boundaries are found;

2) Currents are continuous, yes;

3) I've run the coupled system for one day and then have rerun with HOTFILEs. The error is still on both ROMS grids, while both SWAN grids look OK.

I suspect an interpolation error, when SWAN gives data to ROMS. But why? Sandy test-case, which I used as a reference, doesn't have it.

[jcwarner]

I am not really clear on these results, and perhaps i was not very clear either.
1) if you just run swan by itself, do you get results on both the parent and child that are consistent and look correct?
2) currents continuous = good, roms refinement works.
3) roms+swan coupled: you say that with it coupled the waves on both swan parent and child are ok ? is that from swan mat files?
but the waves on both the parent and child in roms (from roms his files) are not ok?


-j

[Eugen]

Dear John,

1) SWAN only (results after 5 days):


3) If I run the coupled system, after 4 days on the SWAN grids (.mat) the results look like this:


Probably due to ROMS results in netcdf look like this:


The blue straight line corresponds to the 'zero' area along the child grid boundary.
Colorbar = wave height in meters.

[jcwarner]

i cant see the images. can you upload png files?
-j

[Eugen]

Yes, sure

[Eugen]

I compared indexes of child grid edge points compared to the corresponding parent grid cells in the scrip interpolation weight logs.

For Sandy hurricane it is:

ROMS starting i & j index of parent w.r.t child grid
23 27
ending i & j index of parent w.r.t child grid--
60 54

And ncdump says, that the coordinates of the Sandy nested grid are:
22 26
60 54

So, we should except the same behavior for my case.

The scrip interpolation weight log says:

SWAN starting i & j index of parent w.r.t child grid--
7 33
ending i & j index of parent w.r.t child grid--
35 56

But ncdump gives:
7 32
34 56

That means, that along the i-dimension everything should be shifted ! But why?

[jcwarner]

swan with nesting by itself (no roms) does not need the scrip weights, so there is an issue with the swan child grid. Can you send to me the 2 *.bot and the 2 *.grd swan files (4 files)
jcwarner@usgs.gov
thanks
-j

[Eugen]

Thanks, John,

I've sent you a message.

Did I mention that my ROMS grids have an angle of 120 degrees?
Can it be a reason, why the configuration works such bad?

SWAN does not read the southern nested boundary at all, and the western boundary it reads with a numerical error...

[Eugen]

John,

I've decided to make an experiment.
I've turned both grids of the Sandy test-case on 180 degrees. Then, I've created .grd and .bot files and have run SWAN (without coupling with ROMS). And then I've compared it with the run on the normal (non-reversed) grid.

I've switched off the winds on the child grid to show clearer the information transfer between both grids.

Here are the results.

Neither Northern, neither Southern boundary seems to function properly in the "reversed run".

I do remember that SWAN does not like angles, but the parent grid runs normally, so I had decided to forget about this issue.

By far my grid is turned on 120 degrees, so I would expect the same kind of problem.

I'll turn my grid to something in between 0 and 90 degrees and tell you the results.

[jcwarner]

So i can get this to work.
The grid files seem to be ok (2xbathy.bot and 2x coord.grd). They are ok.
Here are some changes i did to the INPUT files:
1) I did not have your wind file, so i commented out the wind commands and added
WIND 10. 0.
this puts a 10 m/s wind from north on both grids.
2) You had a 3600s time step for both child and parent. That is too long. I set them to be 900s for parent, and 150 for child. This worked a lot better.
3) for child grid you do not need a BC files. so comment out this line in the child INPUT
&BOUND SHAPESPEC JONSWAP MEAN DSPR DEGREES
4) in both INPUT files i added
& Restart name **********************************
INIT
This INIT command computes an initial Hsig in each grid, for the first time step based on the wind field.
5) the Output time step was not consistent with the model time. So i changed the HSIG outputs to be
BLOCK 'COMPGRID' NOHEADER 'NS_hsig.mat' LAY 4 HSIGN 1. OUTPUT 20060101.000000 1 HR
and
BLOCK 'COMPGRID' NOHEADER 'NS_nest_hsig.mat' LAY 4 HSIGN 1. OUTPUT 20060101.000000 1 HR

Give those a try for SWAN by itself (2 grids). That should help. here is an image after 24 hours for my constant wind, parent and child swan.:

[Eugen]

Thanks a lot, John !

I'll try your suggestions and soon tell the results of the coupled run.

[Eugen]

John,

The SWAN itself works fine now. But, coupled with ROMS, the nested grid gives a weird numerical error along the upper boundary.

It is not deadly anymore, but it is definitely a patch to be eliminated.

Could you guess please, why does it appear?

[jcwarner]

if i had to guess, i would ask what the time steps are being used for roms.

[Eugen]

John,

Unfortunately, I didn't succeed to eliminate this error while playing with the ROMS time step, nor with the SWAN time step or with the coupling time step.

Could it be due to a mask mismatch? I made some significant changes in the mask inside of the domain (not in the contact point layer). But fields of any other variables, except of the wave ones, are perfectly fine and continuous.

[jcwarner]

can send to me the scrip file you used to create the scrip weights?
and are the grids the same size for the parent roms/swan and the child roms/swan?
you need to make sure you enter the swan grid sizes correctly.
-j