Coupled ROMS-SWAN experiment

[hyunmin.eom]

Dear all users

My cases is about roms-swan coupling
Experimental region is Northwest Pacific around Korean Peninsula.

ROMS model was setup with TPXO6, COADS and WOA dataset.
And then for coupling I edited files(cppdefs.h, ocean.in, wave.in, and coupling.in) like INLET_TEST case.

I added to cppdefs.h

#define SWAN_COUPLING
#ifdef SWAN_COUPLING
# define MCT_LIB
# define NEARSHORE_MELLOR
#endif

DT

ROMS : 240 sec
SWAN : 600 sec
Coupling : 1200 sec

Export and Import

ROMS : E - bath/SSH/Ubar/Vbar/ZO, I - Wdir/Wamp/Wlen/Wptop/Wpbot/Wubot
SWAN : E - Wdir/Wamp/Wlen/Wptop/Wpbot/Wubot, I - bath/SSH/Ubar/Vbar/ZO

But the result has some problem.
Current get along the boundary and wave height is over eastimated at some area and some point.

How can I solve the problem?

Thanks
Eom

[jacopo]

For the second problem, try using the solution with PWTAIL=5
viewtopic.php?f=20&t=1311

For the first problem (current along the boundary), I'm not sure I can help. Maybe there is an issue with the radiation stress over there? Try defining DIAGNOSTIC_UV and check if you see weird spikes in that area.

Jacopo

[hyunmin.eom]

Thank you for your reply, Jacopo
I will try with your comments and be back..

Thanks
Eom

[jcwarner]

For the first problem, i am working on that. There are issues with the boundary data from SWAN. I hope to have this issue resolved soon. In the mean time we have ways to run roms and swan on different grids. But i have not ported this technology to the Rutgers code. If you are interested in that method i can help set you up with a different version of the code.

-john

[drews]

I have seen spuriously large currents along a domain boundary when the Coriolis force pushes the current against the wall. My solution was to set the domain boundaries to no-slip:

GAMMA2 == -1.0d0


This change makes the walls less greasy.

I am modeling wave radiation stress with NEARSHORE_MELLOR as you are, but I use analytical wave height, length, and direction instead of SWAN. In a few grid cells the u-currents increased to 30 m/s (yee-hah!) right before a blowup error. Upon investigation, the problem grid cell had very shallow water. The water level was near my critical depth of 0.1 meters, while the wave heights were 0.2 meters.

I assume this is my own fault for allowing big waves in shallow water, but since it sounds like your topic here, it might be of interest. You might check the water depth and the wave height in those cells where the current is a problem.

Are you using WET_DRY? I noticed that if I make tiny waves (0.02 meters) in dry cells, the water level still drops (meaning that water still flows out of that cell). I get water level variation below the critical depth. This occurs at the shoreline, and again I get huge currents. John, I take it that I should set wave heights to 0.0 in all dry cells?

->Carl

[jcwarner]

it may be best to set wave heights to zero in dry cells. The swan model will give zero wave heights for cells that are dry in swan. So if you are using some analytical wave field, you should make it be realistic.

[hyunmin.eom]

Thanks, Jacopo, John and Carl for your interestings and comments.

I'm sorry, late reponse.
I'm still testing the problem with comments of Jacopo and Carl.
I will post as soon as possible.

To. John
Of course, I am interested in that method. Could you help me?

Thanks
Eom

[hyunmin.eom]

Dear all.

So far, the solutions are like these.
For first problem
I reduced the gradient of each results(height, period, etc.) around boundary by averaging.

For second problem
I can't solve with only 'PWTAIL=5'
So I used 'GEN3 JANSSEN', but this method takes more time for calculation.

And I have a question. ^^;
The receive time of ROMS has increased from 1.6 sec to 38.0 sec.
Why do increase the time?

WAV2OCN - (05) imported and (06) exported fields, t = 20041105.034000
- SWAN coupling exchanges wait clock (s):
(Recv= 1.87942028E-01 Send= 7.71284103E-04)
OCN2WAV - (06) imported and (05) exported fields, t = 1770 03:40:00
- ROMS coupling exchanges wait clock (s):
(Recv= 1.59428024E+00 Send= 6.40869141E-04)

.....

WAV2OCN - (05) imported and (06) exported fields, t = 20071228.084000
- SWAN coupling exchanges wait clock (s):
(Recv= 2.73242950E-01 Send= 8.53061676E-04)
OCN2WAV - (06) imported and (05) exported fields, t = 2918 08:40:00
- ROMS coupling exchanges wait clock (s):
(Recv= 3.80019579E+01 Send= 7.44819641E-04)

[hyunmin.eom]

Hi.

Does anybody tried to solve this problem?
If I use a lot of CPU, I could solve this problem?
I could be calculated long term by using the coupled model?

Thanks
Eom

[jcwarner]

I am not clear what the problem actually is here. Can you restate what the real problem is??

[hyunmin.eom]

I want to be described it better.

Problem is...
'Recv' time of roms-swan coupled model is increased.
Initially, 'Recv' time is almost 2 seconds,
but that is increased to 38 seconds after 3 years simulation

Each models don't have unknown value or over flow problem.
I have no idea why 'Recv' time is increased.

Thanks.
Eom