CSTMS UNSW2008: Difference between revisions
No edit summary (change visibility) |
|||
| Line 29: | Line 29: | ||
NAUTICAL implies that directions are specified in degrees and (for wind and waves) indicate the direction ''from which'' the wind/waves are approaching, For example, a uniform southwesterly wind (blowing toward the northeast) at 5 m/s for a stationary run would be specified as | NAUTICAL implies that directions are specified in degrees and (for wind and waves) indicate the direction ''from which'' the wind/waves are approaching, For example, a uniform southwesterly wind (blowing toward the northeast) at 5 m/s for a stationary run would be specified as | ||
<div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well. | <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well. | ||
In the Latte example, we have good wind forcing files that work with ROMS, and we want to use the same files to force waves in SWAN. We will use the SWAN commands | |||
<div class="box">INPGRID WIND CURVILINEAR 0 0 145 81 EXC 9.999000e+003<br>READINP WIND 1 | <div class="box">INPGRID WIND CURVILINEAR 0 0 145 81 EXC 9.999000e+003 &<br>NONSTATIONARY 20060405.000000 1 HR 20060608.230000<br>READINP WIND 1 'swan_lattec_wind.dat' 4 0 FREE </div> | ||
The file swan_lattec_wind.dat has sequences of u and v velocities written for each time step. The ''u-'' and ''v-'' components are aligned with the ''x-'' and ''y-''axes of the SWAN grid. The order in which they are written is determined by the 'layout' parameter (in this case, 4), which means the | |||
file looks like this. | |||
<div class="box"> | |||
u(1,1,1) u(1,1,2) ... u(1,1,nj)<br> | |||
u(1,2,1) u(1,2,2) ... u(1,2,nj)<br> | |||
...<br> | |||
u(1,ni,1) u(1,ni,2)... u(1,ni,nj)<br> | |||
v(1,1,1) v(1,1,2) ... v(1,1,nj)<br> | |||
v(1,2,1) v(1,2,2) ... v(1,2,nj)<br> | |||
...<br> | |||
v(1,ni,1) v(1,ni,2)... v(1,ni,nj)<br> | |||
u(1,1,1) u(1,1,2) ... u(1,1,nj)<br> | |||
u(1,2,1) u(1,2,2) ... u(1,2,nj)<br> | |||
...<br> | |||
u(1,ni,1) u(1,ni,2)... u(1,ni,nj)<br> | |||
v(2,1,1) v(2,1,2) ... v(2,1,nj)<br> | |||
v(2,2,1) v(2,2,2) ... v(2,2,nj)<br> | |||
...<br> | |||
v(2,ni,1) v(2,ni,2)... v(2,ni,nj)<br> | |||
...etc | |||
</div> | |||
==Wave-current coupling== | ==Wave-current coupling== | ||
Revision as of 01:24, 25 March 2009
On Friday, 3 April, there will be a tutorial for new ROMS users interested in sediments. This tutorial continues using the LATTE example presented during the Monday tutorial.
Test the LATTE case
Change the advection scheme
Turn on sediment
Changes to the .h file
Additions to the init file
A case study in troubleshooting
Why so boring?
Sediment 101: Its the waves!
Analytical waves
SWAN - A Digression
Getting SWAN set up correctly is easier if you do it separately. The coupling to ROMS is not seamless...you still have to specify the SWAN INPUT file, bathymetry, and some of the forcing for SWAN as separate files.
Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:
COORDINATES SPHERICAL
CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &
CIRCLE 36 0.0418 1.0 24
READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE
NAUTICAL implies that directions are specified in degrees and (for wind and waves) indicate the direction from which the wind/waves are approaching, For example, a uniform southwesterly wind (blowing toward the northeast) at 5 m/s for a stationary run would be specified as
SWAN output in .mat files should be interpreted this way as well.
In the Latte example, we have good wind forcing files that work with ROMS, and we want to use the same files to force waves in SWAN. We will use the SWAN commands
NONSTATIONARY 20060405.000000 1 HR 20060608.230000
READINP WIND 1 'swan_lattec_wind.dat' 4 0 FREE
The file swan_lattec_wind.dat has sequences of u and v velocities written for each time step. The u- and v- components are aligned with the x- and y-axes of the SWAN grid. The order in which they are written is determined by the 'layout' parameter (in this case, 4), which means the file looks like this.
u(1,1,1) u(1,1,2) ... u(1,1,nj)
u(1,2,1) u(1,2,2) ... u(1,2,nj)
...
u(1,ni,1) u(1,ni,2)... u(1,ni,nj)
v(1,1,1) v(1,1,2) ... v(1,1,nj)
v(1,2,1) v(1,2,2) ... v(1,2,nj)
...
v(1,ni,1) v(1,ni,2)... v(1,ni,nj)
u(1,1,1) u(1,1,2) ... u(1,1,nj)
u(1,2,1) u(1,2,2) ... u(1,2,nj)
...
u(1,ni,1) u(1,ni,2)... u(1,ni,nj)
v(2,1,1) v(2,1,2) ... v(2,1,nj)
v(2,2,1) v(2,2,2) ... v(2,2,nj)
...
v(2,ni,1) v(2,ni,2)... v(2,ni,nj)
...etc
