a potential bug: SWAN not receives or not processes the sea surface level from ROMS

[xwu]

Hello,

I am reporting a potential issue with SWAN model that is coupled with ROMS. In my case, ROMS has barotropic tides and the sea surface level varies with an amplitude of ~1.0m. Within each coupling interval (12 mins), the log file clearly shows that ROMS and SWAN exchange information (see an example below):

** ROMS grid 1 recv data from SWAN grid 1
SWANtoROMS Min/Max DISBOT (Wm-2): 0.000000E+00 1.124170E-05
== SWAN grid 1 sent wave data to ROMS grid 1
SWANtoROMS Min/Max DISSURF (Wm-2): 0.000000E+00 5.077437E-02
SWANtoROMS Min/Max DISWCAP (Wm-2): 0.000000E+00 1.111538E-06
SWANtoROMS Min/Max HSIGN (m): 0.000000E+00 1.034356E+00
SWANtoROMS Min/Max RTP (s): 0.000000E+00 1.682180E+01
SWANtoROMS Min/Max TMBOT (s): 0.000000E+00 2.313801E+01
SWANtoROMS Min/Max DIR (deg): 0.000000E+00 6.201885E+00
SWANtoROMS Min/Max WLEN (m): 1.000000E+00 1.319471E+02
** ROMS grid 1 sent data to SWAN grid 1
== SWAN grid 1 recv data from ROMS grid 1
ROMStoSWAN Min/Max DEPTH (m): -2.000000E+00 6.428143E+02
ROMStoSWAN Min/Max WLEV (m): -2.911821E-01 2.250000E+00
ROMStoSWAN Min/Max VELX (ms-1): -8.887212E-01 5.951608E-01
ROMStoSWAN Min/Max VELY (ms-1): -4.260612E-01 3.394907E-01
ROMStoSWAN Min/Max ZO (m): 5.000000E-02 5.000000E-02
+time 20150718.071600 , step 109; iteration 1; sweep 1 grid 1
25921 2015-07-18 07:12:01.00 5.193107E-03 1.852671E+03 1.852676E+03 7.146690E+10
(387,565,02) 6.405765E-02 1.551187E-05 5.812848E-01 8.961226E-01

However, the two values of the 'Min/Max WLEV' barely change during a full model day (the log file is attached). I also output the 'WATLEV' from SWAN (using the 'BLOCK' command) and compare it with the 'zeta' value from the ROMS history file (see attached figure 'p19_eta_roms_swan_output.pdf'). As shown in the plot, the sea surface level is all 'zero' from SWAN output, while the ROMS history file shows the correct 'zeta' value. To me, this indicates that, either SWAN receives all zero values of 'zeta' from ROMS, or SWAN has some issue in processing the 'zeta' provided by ROMS.

Thanks,
Xiaodong Wu

[jcwarner]

that looks strange.
What is the 2.25 from? do you have wet/dry on, so that 2.25 is on land and probably masked out in swan.
can you make a pcolor plot of swan water level and roms water level at 07/18/06?
you do not have define ZETA_CONST ?
-j

[xwu]

hi John,

yes, the coupled model has wet/dye on. I did not turn on the 'ZETA_CONST'. The pcolor plot at 07/18/06 is attached. So it is clear that the 2.25m is the 'zeta' on land.

Below are the lines from ./SWAN/Src/waves_coupler.F (L1250 - 1270). If I understand correctly, the calculation of the Min/MAX WLEV values did not apply the wet/dry mask. This explains the Max WLEV = 2.25m in the log file.

! Water surface elevation.
!
CALL AttrVect_exportRAttr (AttrVect_G(ng)%ocn2wav_AV, &
& "WLEV",avdata,gsmsize)
range(1)= Large
range(2)=-Large
IP=0
DO IY=Jstr,Jend
DO IX=Istr,Iend
IP=IP+1
INDXG=(IY-1)*MXC+IX
TEMPMCT(INDXG,idwlv)=avdata(IP)
range(1)=MIN(range(1),REAL(avdata(IP)))
range(2)=MAX(range(2),REAL(avdata(IP)))
END DO
END DO
CALL SWREDUCE(range(1),1,SWREAL,SWMIN)
CALL SWREDUCE(range(2),1,SWREAL,SWMAX)
IF (MyRank.eq.0) THEN
write(SCREEN,40) 'ROMStoSWAN Min/Max WLEV (m): ', &
& range(1),range(2)
END IF

What I am concerned is, whether SWAN does read in and process the 'zeta' provided by ROMS. The output 'WATLEV' from SWAN clearly shows all zero values over the domain, which is scary. In the calculation of the maximum wave height 'HM', there is a variable 'DEP2(KCGRD(1))': (from ./SWAN/Src/swancom1.F, L5679 - 5692):

!
! --- compute actual maximum wave height based on breaking model
! include wave directionality, if appropriate 41.47
!
IF ( ISURF.GT.0 ) THEN
! compute some parameters for breaker models
CALL BRKPAR (BRCOEF, SPCDIR(1,2), SPCDIR(1,3), AC2,
& SIGPOW(:,1), DEP2, BOTLV, GAMBR, RESPL, 41.38
& RDX, RDY, KWAVE, IDDLOW, IDDTOP, SPCDIR(1,1), 41.38 41.03 40.22
& KTETA ) 41.47
HM = BRCOEF * DEP2(KCGRD(1)) 40.22
ELSE
! breaking disabled, assign very high value to HM
HM = 100. 40.22
ENDIF

I am not sure whether the variable 'DEP2(KCGRD(1))' already accounts for the 'zeta' provided by ROMS, or the 'DEP2(KCGRD(1))' is just the grid still water depth.

Thanks,
Xiaodong

[jcwarner]

so i just ran the inlet test again and it is fine. so there is something wrong in your setup.
can we look at the PRINT* files? how did you set the swan depths?
what does your INPUT file have?
-j

[xwu]

Here are the files:

(1) two PRINT* files (SWAN uses 30 processors so there are 30 copies);

(2) SWAN INPUT file (swan_LPL.in);

(3) ROMS INPUT file (ocean_LPL.in);

(4) header file (lpl_couple.h).

[jcwarner]

i am not seeing much wrong here. need to keep looking.
i went back to the original log file and searched for WLEV

42480 2015-07-18 11:48:00.00 6.631682E-03 1.852537E+03 1.852543E+03 7.089705E+10
(374,563,15) 1.241157E-02 2.806246E-04 3.950358E+00 9.911014E-01
.....
** ROMS grid 1 sent data to SWAN grid 1
== SWAN grid 1 recv data from ROMS grid 1
ROMStoSWAN Min/Max DEPTH (m): -2.000000E+00 6.428143E+02
ROMStoSWAN Min/Max WLEV (m): -1.068757E+00 2.250000E+00

here the WLEV is -1.0 so SWAN is seeing the tide decrease. maybe there is a ramp? but i cant find it.
can you do a pcolor of swan wlev near this time? what is your coupling interval?

[xwu]

The issue is now resolved after adding these lines in the SWAN INPUT files:

INPGRID CURRENT CURVILINEAR 0 0 481 908 EXC 9.999000e+003 &
NONSTATIONARY 20150718.000000 24 HR 20150719.000000

INPGRID WLEVEL CURVILINEAR 0 0 481 908 EXC 9.999000e+003 &
NONSTATIONARY 20150718.000000 24 HR 20150719.000000

INPGRID FRIC CURVILINEAR 0 0 481 908 EXC 9.999000e+003 &
NONSTATIONARY 20150718.000000 24 HR 20150719.000000

So, my understanding is, SWAN will process the WLEV (maybe also U/V) data from ROMS if this 'INPGRID' command is used to define the grid for WLEV (and CURRENT). Without doing this, SWAN only receives (as seen from the log file) but NOT processes the WLEV data. I am not sure whether the COAWST user manual has already mentioned this or not.

thanks a lot for the help!

[jcwarner]

glad you figured it out!
SWAN needs those flags in the input file so that internally it create the input grids, etc. they are the same effect as roms cppdefs, but swan uses keywords not cpp options.
I will make this more clear in the documentation.
-j