ROMS SWAN Coupling Possible Bug

[robjenkinsiii]

I'm running into something curious during an extended period runs of ROMS & SWAN.
If you have a moment can you please make a suggestion about the following?

Let me say first that I am trying to run a coupled ROMS/SWAN application over a 7 year period. To make SWAN output manageable, I've opted to run the simulation in one year increments which means I'm doing quite a lot of restarts to achieve this. For the first two years both models seem to run just fine, but I notice something very strange in the third year with regard to coupling time intervals, and SWAN output intervals which I'll describe in more detail below.

(Note: date formats are YYYYMMDD_hhmmss or YYYYMMDD.hhmmss)

In trying to process output from SWAN for the year 2008-2009 I got an error that it could not find the variable 'Hsig_20080216_190000.'
This is because the variable does not exist and in the swan record at this point, the record (which had been reporting each hour on the hour) goes like this.

'Hsig_20080216_170000'
'Hsig_20080216_180000'
'Hsig_20080216_191440'
'Hsig_20080216_202920'

And it continues reporting at intervals of 1hr, 14min, and 40 seconds for the remainder of the year & in the year 2009 as well.

Now, the problem of simply processing past this hour I can probably work around but I'm worried that it points to a bigger problem.

According the the ROMS printed log, coupling exchanges which had occurred at each 30 minute interval, begin occurring at a slightly odd interval (a shift of 8 seconds) beginning with....

20080216.173000
20080216.180000
20080216.182952
20080216.185944

With no other message associated with the change. This change in the coupling in ROMS seems related to the change in output time in SWAN in some way since they occur around the same hour.

One thing I've found is that, I calculated the number of time steps needed for each year using Matlab's datenum function. The value that I've calculated, and now rechecked /should/ lead ROMS to a final time step of:

20090101.000000

The ocean_rst.nc file reflects that the last time of the ROMS simulation was indeed 20090101.00000 AND YET the last time reported that the models exchange information is...

20081230.135648

This incorrect ending is also the last hour which SWAN outputs for that year.

My first thought was that it is somehow not handling the leap year correctly for this year, however, BOTH models show dates for Feb. 29th. so I don't believe this is the problem.

I'm working now to actually process the SWAN output to see if there are any instabilities or obvious issues. However do note that although The timing seems to shift in the coupling and in SWAN, there are no errors reported, and the simulations do seem to be finishing.

Thanks for your time.

-Rob

[jcwarner]

Rob-
there could be several issues. SWAN is only real*4, so if you add a small dt for many years, it can get to a point where the accuracy is longer able to keep track of small time increments. not sure if this is the case or not. Did you say that if you start the coupled app on jan 1 2008, does it go past that time ok?
All the coupling intervals are based on number of steps, not the actual times. It is very difficult to compare real numbers, so we convert everything to integers and just count how many steps should be taken between exchanges. If the swan dt got messed up somehow, then the coupling times will be off. can you check your COMPUTE command and the input file. IS this with coawst or rutgers code?
-john

[robjenkinsiii]

John-
Thank you for getting back to me.
To answer your questions and concerns: I'm using the Rutgers code, not COAWST.
The app is restarted at 20080101.00000 and produces bad results.
I have tested it again with everything the same except that I remove the HOTSTART command and let SWAN initialize analytically, but this did not change the bad output.

The compute command, I think is OK....

COMPUTE NONSTATIONARY 20080101.000000 900 SEC 20090101.000000

Thanks again,
Rob

[jcwarner]

Really suggest that you use COAWST for model coupling applications.
I am about to release a new version that has the latest version of roms, and newer swan, etc. If you want to use the newer system, send me an email to
jcwarner@usgs.gov

-john

[robjenkinsiii]

Just to follow up I think it was indeed a problem with SWAN's real*4 type interger.
The SWAN dt starts to shift by 4 seconds back and forth as the computation time in seconds reaches the limits of accuracy for the real*4 (7 sig. digits).

In my current set up, I solved this by treating the restart in the third year for the coupled application as a HOTSTART in SWAN and the beginning of "new solutions" in ROMS by setting NRREC==0 and creating an initial file from the most recent restart record.
That seems to have eliminated any weird shifts in the coupling time and SWAN model output.

However, I think, setting up COAWST for the rest of this research would be my best bet.

Thanks again for your input, John.

-Rob