ROMS blew up with OOST defined

[CeeCee.X]

Dear all,

I tried to use ROMS coupled with SWAN to simulate a real hurricane. My problem is by using Taylor and Yelland option to calculate the sea surface roughness, my simulation went all well. However, by using the OOST option, the simulation quickly blew up after running about 1 day. My time step is only 30 sec. The only thing I changed by shifting from Taylor and Yelland to Oost is define COARE_OOST instead of COARE_TAYLOR_YELLAND in my header file. Can anyone help me to fix this blew-up problem? Here I attached my header file and input file for ROMS.

Thanks in advance.

[jcwarner]

one choice is to define COARE_OOST, build it, and save that Build/bulk_flux.f90.
Then define COARE_TAYLOR_YELLAND and save that Build/bulk_flux.f90.
Then compare those 2 bulk_flux.f90's and see what is different.
You will see things like this

in bulk flux there is:

DO Iter=1,IterMax
DO i=Istr-1,IendR
# ifdef COARE_OOST
ZoW(i)=(25.0_r8/pi)*WaveLength(i)* &
& (Wstar(i)/Cwave(i))**4.5_r8+ &
& 0.11_r8*VisAir(i)/(Wstar(i)+eps)
# elif defined COARE_TAYLOR_YELLAND
ZoW(i)=1200.0_r8*Hwave(i,j)* &
& (Hwave(i,j)/WaveLength(i))**4.5_r8+ &
& 0.11_r8*VisAir(i)/(Wstar(i)+eps)
# elif defined DRENNAN
ZoW(i)=(3.35_r8)*Hwave(i,j)* &
& MIN((Wstar(i)/Cwave(i)),0.1_r8)**3.4_r8+ &
& 0.11_r8*VisAir(i)/(Wstar(i)+eps)
# else
ZoW(i)=charn(i)*Wstar(i)*Wstar(i)/g+ &
& 0.11_r8*VisAir(i)/(Wstar(i)+eps)
# endif

OOst needs the wave celerity but TY does not. might have something to do with the Pwave_top.

-j

[CeeCee.X]

Thanks, John.

I looked into the code, and found the basic differences did exist in whether Pwave_top are needed or not. However, the Pwave_top is provided by the SWAN. In the ROMS code, there are two places when Pwave shows up besides the Bulk_flux.f90 and they are either import the value from SWAN or assign the initial value. Therefore, if it is the Pwave_top gets problem. How do I output and recognize it? Here I attached my SWAN input file.

CALL AttrVect_exportRAttr(AttrVect_G(ng)%wav2ocn_AV, "RTP", &
& A, Asize)
ij=0
DO j=JstrT,JendT
DO i=IstrT,IendT
ij=ij+1
FORCES(ng)%Pwave_top(i,j)=MAX(0.0_r8,A(ij))
END DO
END DO

[jcwarner]

there are ways to save the different swan vars. can you access the swan manual?
http://swanmodel.sourceforge.net/online ... anuse.html
something like
BLOCK 'COMPGRID' NOHEADER 'rtp.mat' LAY 4 RTP 1. OUTPUT 20000101.000000 1 HR

also, some vars come thru roms and can be written out to the roms netcdf file.
Hout(idWlep) == T ! Lwavep wave length, peak


-john

[CeeCee.X]

Thank you. Let me check the wave length and wave peak from ROMS first.

[CeeCee.X]

Hi,

did anyone encounter issue with opening the .mat files generated by SWAN during the ROMS-SWAN coupling process?

I used the following script in swan.in
BLOCK 'COMPGRID' NOHEADER 'rtp.mat' LAY 4 RTP 1. OUTPUT 20110822.000000 30 SEC
BLOCK 'COMPGRID' NOHEADER 'depth.mat' LAY 4 DEPTH 1. OUTPUT 20110822.000000 30 SEC
BLOCK 'COMPGRID' NOHEADER 'vel.mat' LAY 4 VEL 1. OUTPUT 20110822.000000 30 SEC
BLOCK 'COMPGRID' NOHEADER 'watlev.mat' LAY 4 WATLEV 1. OUTPUT 20110822.000000 30 SEC

and I obtained bounch of mat files. However, I couldn't open them in MATLAB, even if I have renamed it (i.e. from depth.mat-001 to depth-001.mat). The MATLAB shows that the file corrupt. Is there any special decoding process?

[jcwarner]

if it has -001 -002 etc at the end of hte file names, then swan most likely did not finish correctly. Wehn swan finishes it puts all the files into one file. for example, the hsig.mat-001 and hsig.mat-002 all go away and you just get hsig.mat.

[CeeCee.X]

I see. I actually have another simulation with ROMS and SWAN coupled. I used the following sentence, but nothing been generated from SWAN.
BLOCK 'COMPGRID' NOHEADER 'rtp.mat' LAY 4 RTP 1.
BLOCK 'COMPGRID' NOHEADER 'depth.mat' LAY 4 DEPTH 1.
BLOCK 'COMPGRID' NOHEADER 'vel.mat' LAY 4 VEL 1.
BLOCK 'COMPGRID' NOHEADER 'watlev.mat' LAY 4 WATLEV 1.

However, ROMS finished without blow up and I obtained complete his.nc. Judging from what you said, is that possible that SWAN blows up but the coupled simulation can still carry on? In that case, the results I obtained is basically from ROMS with little influence from SWAN, right?

[jcwarner]

probably not. IF one of the models dies, then at the next coupling interval there would be an mpi_waitall that is never fulfilled.

[CeeCee.X]

Thanks, John. Since I am not specifying OUTPUT in swan.in, only results from last time step is expected. If SWAN blows up in the middle, unlike in ROMS where the last time step can be saved in rst.nc, nothing can be printed out ?