wave in coupling code

[wulunyu]

Hi All,

I used the inlet test case to test the wave code in the coupling code.
I made two change of the inlet two-way couple case,
1)set tide amplitude at boundary equal to zero(0.0_r8).
2)undefine NEARSHORE_MELLOR and SED_MORPH
All other options are kept.It is supposed to get a result as if I ran with pure SWAN code.
with those two changes I got very small elevation and velocity value(1e-15~1e-17) but very different
wave height pattern with results from SWAN code.(It seems there is still wave current interaction )
1)My question is where the small values comes from? in my opinion without wave radiation stress and tide forcing at boundary, no current will be genrated.
2)Can that small current affect the wave ?
3) How is zo(exported from ocean to wave) used in wave model?
any comments? thanks!

Allen

[jacopo]

When you couple the two models (def SWAN_COUPLING) and in the coupling_inlet_test.in you specify to exchange UBAR and VBAR from the ROMS into SWAN, SWAN actually computes wave based on 'apparent wind', instead of the exact input wind. This is the way SWAN takes into account currents.

Zo is used as input roughness coefficient for MADSEN scheme in SWAN. This scheme is wave-only (in SWAN), but Zo provided by ROMS (estimated in SSW_BBL.h) is varying in time and space taking into account bed forms and (non linear) wave-current interactions in the BBL.
In other words, in the application you run, even if NEARSHORE_MELLOR and SED_MORPH are undefined, the bottom friction in SWAN is different as it was just setting
FRICTION MADSEN 0.05
In this case you have in fact a constant in time and space friction coefficient of 0.05. Of course, you can decide to provide a spatially and time varying coefficient, or you want to let ROMS estimate this within its BBL (as it is in the inlet test) .

Jacopo

[jacopo]

well, digging a little bit into the model (ROMS - ssw_bbl.h), I see:

Code: Select all

zoMAX=0.9_r8*Zr(i,j)
          zoMIN=MAX(absolute_zoMIN,2.5_r8*d50/30.0_r8)
!
!  Initialize arrays.
!
          zoN(i,j)=MIN(MAX(2.5_r8*d50/30.0_r8, zoMIN ),zoMAX)

[...]

Code: Select all

bottom(i,j,izNik)=zoN(i,j)

and, in mct_roms_swan.h

Code: Select all

          CASE ('ZO')                   ! bottom roughness

            DO j=JstrR,JendR
              DO i=IstrR,IendR
#ifdef BBL_MODEL
                Awrk(i,j)=MAX(0.0001_r8,                                &
     &                        OCEAN(ng)%bottom(i,j,izNik)*30.0_r8)
#else
                Awrk(i,j)=MAX(0.0001_r8,rdrg2(ng))
#endif

This looks to me as the coefficient exchanged is function of d50=bottom(i,j,isd50) only,
so my previous statement

but Zo provided by ROMS (estimated in SSW_BBL.h) is varying in time and space taking into account bed forms and (non linear) wave-current interactions in the BBL.

should be a little bit revisited

[wulunyu]

‘apparent wind’ means relative wind(Uwind-Ucurrent),am I right?actually current influences wave more than that way(like influence on wave propagation,doppler shift,etc) But in this case wave is forced by open boundary and no wind is input. Besides the Ucurrent is very small(~1e-15,probably numeric),so I think the current should not affect the wave. But the results with this coupling code is very different with that from SWAN(same INPUT).


Thanks for explaining zo. I have found that in the code,but I don't know whether the value is trnasferred to wave code or not, I found swan still uses PBOT(5) (0.05) in the coupling code.
I've been working on the coupling of FVCOM and the unstructured SWAN based on FVCOM. I just coupled them directly , so I am not famliar with MCT. Maybe the value is changed in other MCT related routines

Allen

When you couple the two models (def SWAN_COUPLING) and in the coupling_inlet_test.in you specify to exchange UBAR and VBAR from the ROMS into SWAN, SWAN actually computes wave based on 'apparent wind', instead of the exact input wind. This is the way SWAN takes into account currents.

Zo is used as input friction coefficient for MADSEN scheme in SWAN. This scheme is wave-only (in SWAN), but Zo provided by ROMS (estimated in SSW_BBL.h) is varying in time and space taking into account bed forms and (non linear) wave-current interactions in the BBL.
In other words, in the application you run, even if NEARSHORE_MELLOR and SED_MORPH are undefined, the bottom friction in SWAN is different as it was just setting
FRICTION MADSEN 0.05
In is case you have in fact a constant in time and space friction coefficient of 0.05. Of course, you can decide to provide a spatially and time varying coefficient, or you want to let ROMS estimate this within its BBL (as it is in the inlet test) .

Jacopo

[jcwarner]

If you #define SWAN_COUPLING, then the model is expecting that roms will send certain parameters to swan and that swan will send certain params back to roms.
I recommend that users set:
Nexport(ocean) = 5
Nexport(waves) = 6

Export(ocean) = bath \
SSH \
Ubar \
Vbar \
ZO

Export(waves) = Wdir \
Wamp \
Wlen \
Wptop \
Wpbot \
Wubot

! Import fields per model, [1:Nimport(...)] string values are expected per
! coupled model. If there is no field to import, set
!
! Nimport(...) = 0
! Import(...) = NONE

Nimport(ocean) = 6
Nimport(waves) = 5

Import(ocean) = Wdir \
Wamp \
Wlen \
Wptop \
Wpbot \
Wubot

Import(waves) = bath \
SSH \
Ubar \
Vbar \
ZO

This method of selecting the variables is not completely robust, so users should just activate these values for exchange.


" 1)My question is where the small values comes from? in my opinion without wave radiation stress and tide forcing at boundary, no current will be genrated."
Small values of what ?? currents? water level? waves?

"2)Can that small current affect the wave ?"
Yes, any current will affect the wave. But if current is small, then effect will be small.


"3) How is zo(exported from ocean to wave) used in wave model?"
This is a new feature that i am not very happy with. It needs revisiting. I think Jacopo found the relevant code, and I do not need to repeat it here.

[jacopo]

Thanks for explaining zo. I have found that in the code,but I don't know whether the value is trnasferred to wave code or not, I found swan still uses PBOT(5) (0.05) in the coupling code.

did you comment out

Code: Select all

&& KEYWORD TO CREATE BOTTOM FRICTION GRID &&
INPGRID FRIC CURVILINEAR 0 0 76 71 EXC 9.999000e+003                 &
        NONSTAT  20000101.000000 25 DAY 20000126.000000

in the swan input file? if so, SWAN does not use Zo input from ROMS.

Did you try plotting FRCOEF SWAN output for additional check?

[jcwarner]

at some point i did some checks.
There is potentially a problem if the user does not set all the Export/Import flags correctly. They are coded with "case" options, and there is no "no case" default option for some of these. I would prefer this all to be coded a different way, to make sure it traps all user choices.
The zo thing is a good example of this. I had to put in a cpp catch to make sure that some value is used if the user does not select to exchang Export Zo.
So I recommend for now that people just select to exchange all the params.

I am not sure what you mean about the PBOT(5) 0.05.
Is that in the version you and i are working on, or is that in the distributed rutgers version?

[wulunyu]

Hi warner,
For small values I mean velocity and water level(~1E-15) because I set tide amplitude at boundary to zero and undef MEARSHORE_MELLOR(no wave radiation stress forcing). weight height ranges from 0 to 1 but has very strong interaction at the mouth of the inlet. My question is, with this small current why we have so strong interaction? Or let me ask this way: How to use the two way coupling code to run a wave only case, actually I want to compare wave induced bed erosion(no deposition,no current advection) with wave model in roms and in fvcom.

I didn't change the coupling input file.There IS some problem when I am not chooing all of them: code stop at the data exchanging time.
PBOT(5) is friction coefficient in swancom2.F. I don't know how zo is import in that routine. I am using roms3.2 from the CVS. But the setup is download from the link you provided before.

[wulunyu]

Hi jacopo,

I didn't comment this

Code: Select all

&& KEYWORD TO CREATE BOTTOM FRICTION GRID &&
INPGRID FRIC CURVILINEAR 0 0 76 71 EXC 9.999000e+003                 &
        NONSTAT  20000101.000000 25 DAY 20000126.000000

from ocean_his.nc Zo varies spatially but time invariant. When I try to plot the fric.mat , matlab says the file is corrupt. I will check this.
,

Did you try plotting FRCOEF SWAN output for additional check?[/quote]

[jcwarner]

The code is not really set up to run swan as a wave only case. It can be done, but i dont want to explain that here. The ability to do that is work in progress, and requires a different design philosophy (ie developing a modeling system, rather than devloping an ocean model that has inputs).

[wulunyu]

By running the two way coupling code with 1)ubar,vbar,zeta set to zero 2)no morphology, is that the same as we run the SWAN code(except the computing efficency)?

[jcwarner]

i believe it would be so.

[wulunyu]

I think I find the problem.I plotted the wave height and it seems there is no friction to the wave. That's why the wave keep increase when shoaling.
So in this case with extremely small current(1e-15),the friction to wave is gone, this is not reasonable. Is that good to have z0 fed back to wave? From this case, NO!

Allen

[jcwarner]

well, the friction to SWAN is based on grain roughness, not on bottom stress.

#ifdef BBL_MODEL
Awrk(i,j)=MAX(0.0001_r8, &
& OCEAN(ng)%bottom(i,j,izNik)*30.0_r8)
#else

so I do not see how low velocities would result in low bottom stress to swan.

[wulunyu]

I commented below options in swan_inlet.in as suggested by jacopo and ROMS coupling code gave the same wave height pattern as SWAN.
&& KEYWORD TO CREATE BOTTOM FRICTION GRID &&
INPGRID FRIC CURVILINEAR 0 0 76 71 EXC 9.999000e+003 &
NONSTAT 20000101.000000 25 DAY 20000126.000000

But I am a little confused about how zo is taken from ROMS, Is AKN in swancom2.F the roughness we are talking about? When VARFR = .TRUE., AKN = FRCOEF(KCGRD(1)).
but when I searched the FRCOEF in the whole code I didn't find how it is related to zo in ROMS.
in the case I ran z0 =2.5*d50/30=8.333e-6 and it will take the minumum value 5e-5
so it's very small, that explained why there is not much dissipition when shoaling

Thanks Warner and Jacopo for help!!

[rcxy]

Hi, i have some question about the bottom roughness.
When the d50 is very small, such as 0.005mm,the zo is very small, and it will take the minumum value 5e-5 in ssw_bbl. It will result in a large zeta. how to do it? increase the absolute_zoMIN ?
The apparent bottom roughness have an impact on current? what it means? it's wave-induced turbulence?
Thank you very much!