WikiROMS - User contributions [en]

https://www.myroms.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=Csherwood WikiROMS - User contributions [en] 2026-04-27T20:55:13Z User contributions MediaWiki 1.42.3 https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3682 CSTMS UNSW2008 2009-04-09T15:26:39Z

<p>Csherwood: /* Make an init file (Run03) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original ''.h'' and ''.in'' files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the ''.h'' file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the ''.in'' file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ''../out''.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[w:ChangeTcline|Changing netCDF variables]].<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <div class="box"><span class="red">#define TS_MPDATA</span></div>and<div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div>(or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations. First, the following declarations are needed. Some of these were already defined...the additional ones represent fluxes that are required but not provided by a sediment bed, and will be set to zero in their respective ana_xx.F files.<div class="box">#define ANA_BPFLUX /* needed when sediment and bulk fluxes are on */<br>#define ANA_SPFLUX /* needed when sediment and bulk fluxes are on */<br>#define ANA_BSFLUX /* bottom temp flux...defaults to zero */<br>#define ANA_BTFLUX /* bottom heat flux...defaults to zero */<br>#define ANA_SSFLUX /* analytical surface salt flux defaults to zero */</div>Now add the declarations for the wave-current bottom stress calculations, and for sediment. We have to turn off the quadratic drag specification, because we are replacing it with SSW_BBL.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div>Finally, to reduce the output, we can also:<div class="box">#undef AVERAGES /* reduce output */<br>#undef STATIONS /* reduce output */</div>You can download the resulting .h file from https://coast-enviro.er.usgs.gov/Latte/run03.<br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div>We will only have one bed layer; it should be thick enough so that it does not erode completely in most of the model domain but, if it is too thick, changes in composition during the model run will be less apparent. We are going to specify only one non-cohesive sediment class, so we need only one value for each parameter.<div class="box"> NEWLAYER_THICK == 0.01d0<br><br>...<br><br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...<br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * Add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<div class="box"> ININAME == ../in/lattec_sed1_ini_94.nc</div><br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br></div>* Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ==Needs waves!==<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3681 CSTMS UNSW2008 2009-04-09T13:30:46Z

<p>Csherwood: /* Make an init file (Run03) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original ''.h'' and ''.in'' files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the ''.h'' file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the ''.in'' file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ''../out''.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[w:ChangeTcline|Changing netCDF variables]].<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <div class="box"><span class="red">#define TS_MPDATA</span></div>and<div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div>(or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations. First, the following declarations are needed.<div class="box">#define ANA_BPFLUX /* needed when sediment and bulk fluxes are on */<br>#define ANA_SPFLUX /* needed when sediment and bulk fluxes are on */<br>#define ANA_BSFLUX /* bottom temp flux...defaults to zero */<br>#define ANA_BTFLUX /* bottom heat flux...defaults to zero */<br>#define ANA_SSFLUX /* analytical surface salt flux defaults to zero */</div>Now add the declarations for sediment.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div>We will only have one bed layer; it should be thick enough so that it does not erode completely in most of the model domain but, if it is too thick, changes in composition during the model run will be less apparent. We are going to specify only one non-cohesive sediment class, so we need only one value for each parameter.<div class="box"> NEWLAYER_THICK == 0.01d0<br><br>...<br><br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...<br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * Add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<div class="box"> ININAME == ../in/lattec_sed1_ini_94.nc</div><br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br></div>* Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ==Needs waves!==<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=ROMS_UNSW2008&diff=3680 ROMS UNSW2008 2009-04-09T02:23:49Z

<p>Csherwood: </p> <hr /> <div><div class="title">Installing and Running ROMS for First Time Users</div><br /> <br /> '''A tutorial for new ROMS users will be held at the UNSW Computer Labs on Monday 30 March 2009, immediately prior to the ROMS Sydney 2009 User Workshop at the Sydney Institute of Marine Sciences, 31 March to 2 April 2009.'''<br /> <br /> {{note}}''<span class="blue">This tutorial is intended for complete newcomers to ROMS. It assumes basic knowledge of working in a UNIX environment, and that the essential components required to compile and execute ROMS are already installed on the host computer network. This wiki page borrows heavily from David Robertson's excellent [[ROMS_Cygwin|Installing ROMS under Cygwin]] tutorial where you will find more information about setting up the required computing environment (compilers, libraries etc.) for ROMS.</span>''<br /> <br /> In this tutorial, we cover how to download the code, configure it for an application, and run the model. Error messages that arise during the configuration process will be explained so that these can better be debugged when users return to their home institutions and try to work through this process again.<br /> <br /> '''A follow-on [[CSTMS_UNSW2008|tutorial discussing sediment in ROMS]] will be presented on Friday 03 April.'''<br /> <br /> {{note}}An important resource you should use as you get started is the [[Frequently_Asked_Questions | Frequently Asked Questions]] entry in [https://www.myroms.org/wiki WikiROMS].<br /> <br /> <br /> __TOC__<br /> <br /> ==Download ROMS==<br /> <br /> The disk space available on the UNSW Computer Lab machines is quite limited, so for the purposes of this tutorial we have downloaded the ROMS source code to '''<span class="red">/srv/ckpt/roms/shared/src</span>''' on host '''<span class="blue">matht001</span>'''. Instructions below will explain how to point the '''<span class="red">build.bash</span>''' script that compiles ROMS to this directory.<br /> <br /> '''To download the code to your own machine, these are the steps you would follow:'''<br /> <br /> :*You must have already registered on the ROMS portal and obtained your ROMS username/password as indicated in the [[ROMS_Cygwin#Register|Register]]. If you are also interested in access to research branches of the sediment code, indicate an interest in the Community Sediment Transport Modeling System (CSTMS) while you are registering. Once your registration is accepted, or if you are already registered, ask Dave Robertson (<span class="twilightBlue">robertson at marine.rutgers.edu</span>) to add you as a CSTMS user.<br /> <br /> :*Create a <span class="red">src</span> folder where you will keep the ROMS source code. You can place this wherever you wish in your directory tree (here we assume under your home directory "<span class="forestGreen">~</span>") and name it whatever you like.<br /> ::<div class="box"><span class="forestGreen">cd ~<br />mkdir src</span></div><br /> <br /> :*Check out the ROMS source code replacing <span class="forestGreen">''bruce''</span> with the ROMS user name you registered with.<br /> ::<div class="box"><span class="forestGreen">svn checkout --username bruce <nowiki>https://www.myroms.org/svn/src/trunk src</nowiki></span></div> Note the target directory <span class="forestGreen">src</span> at the end of the command. If your code ends up in the wrong place, you may have omitted this. <br /> <br /> You will see many lines stream by indicating the files that are being added to your src directory. When it finishes, you can type <span class="forestGreen">ls src</span> to see the contents of the directory. <br /> <br /> To see the contents of the directory where the code is downloaded for this tutorial, type this:<br /> ::<div class="box"><span class="forestGreen">cd /srv/ckpt/roms/shared<br />ls src</span></div><br /> <br /> ==Customize the [[build Script|Build Script]]==<br /> The ROMS source code comes with a [[build Script|build script]] in the <span class="red">ROMS/Bin</span> directory. Examples written with <span class="forestGreen">bash</span> (<span class="red">build.bash</span>) and <span class="forestGreen">csh</span> (<span class="red">build.sh</span>) are provided. The UNSW Computer Lab machines are configured to use <span class="forestGreen">bash</span> as the default login shell, so we will work with <span class="red">build.bash</span>. A full description of the build script can be found [[build Script|here]].<br /> <br /> :*In your home directory (you can use some other directory to organize your ROMS projects if you wish) create a new folder named <span class="red">Projects</span> and change into it.<br /> ::<div class="box"><span class="forestGreen">cd ~<br />mkdir Projects<br />cd Projects</span></div><br /> :*Create a folder named <span class="red">upwelling</span> and change into it. ROMS is distributed with several [[Test Cases|Test Cases]] and the [[UPWELLING_CASE|Upwelling example]] is the default which we will compile and run here. <br /> ::<div class="box"><span class="forestGreen">mkdir upwelling<br />cd upwelling</span></div><br /> <br /> :*Copy the <span class="red">build.bash</span> file distributed with ROMS to your <span class="red">Projects/upwelling</span> directory.<br /> ::<div class="box"><span class="forestGreen">cp /srv/ckpt/roms/shared/src/ROMS/Bin/build.bash .</span></div><br /> <br /> Next we need to configure a few options inside <span class="red">build.bash</span> so that it finds the directories where the source code and your Project are located. <br /> <br /> :*Open the <span class="red">build.bash</span> script you just copied into your <span class="red">upwelling</span> directory using your preferred text editor, e.g. vi.<br /> ::<div class="box"><span class="forestGreen">vi build.bash</span></div><br /> <br /> :*Scroll down until you find <span class="orange">ROMS_APPLICATION</span>. You will notice it is set as follows:<br /> ::<div class="box"> <span class="blue">export</span> <span class="red">ROMS_APPLICATION</span>=UPWELLING</div> We do not need to change this. But this is the first thing you will alter when starting your own project. This tells ROMS the name of an include file that will contain all the directives to the C-PreProcessor to configure your application at compile time. ROMS' rule is change this string to lowercase and append a ".h", so this will search for a file called <span class="red">upwelling.h</span>. It must be in the directory specified by <span class="orange">MY_PROJECT_DIR</span>:<br /> <br /> :*Scroll down until you find <span class="orange">MY_PROJECT_DIR</span> and set it as follows:<br /> ::<div class="box"> <span class="blue">export</span> <span class="red">MY_PROJECT_DIR</span>=${<span class="red">HOME</span>}/Projects/upwelling</div> This obviously assumes you put <span class="red">Projects/upwelling</span> under your home directory.<br /> <br /> If you frequently move your ROMS project between hosts where you have a different directory structure, e.g. a temporary scratch space, you can use the <span class="orange">MY_ROOT_DIR</span> variable to minimize the changes you make to <span class="red">build.bash</span>.<br /> <br /> :*For example: <br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROOT_DIR</span>=/usr/scratch/bruce<br /><span class="blue">export</span> <span class="red">MY_PROJECT_DIR</span>=${<span class="red">MY_ROOT_DIR</span>}/Projects/upwelling</div><br /> <br /> Next we tell <span class="red">build.bash</span> where to find the ROMS source code downloaded from the svn repository (which you can keep up to date the <span class="forestGreen">svn update</span> command - see more on this at LINK ). Note that most of the source code changes you make to customize ROMS will be made in your Projects space, and need not be made to the downloaded code directly. We will discuss exceptions to this during the tutorial, and how source code modifications interact with svn.<br /> <br /> :*Set <span class="orange">MY_ROMS_SRC</span> to the location of the source code:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROMS_SRC</span>=/srv/ckpt/roms/shared/src</div> In practise, you will probably do something more like this:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROMS_SRC</span>=${<span class="red">MY_ROOT_DIR</span>}/src</div> assuming this is the relative path in which you keep your source code on the various machines you work on. <br /> <br /> Make sure that <span class="orange">MY_CPP_FLAGS</span> is '''not''' set. Sometimes this is set in the distributed build.bash exmaple. Comment out options with the # symbol like so:<br /> ::<div class="box"><span class="blue">#export MY_CPP_FLAGS="-DAVERAGES"</span> </div><br /> <br /> The UNSW Computer Lab machines are single core, so we need to tell <span class="red">build.bash</span> not to assume MPI parallel compilation. <br /> <br /> :*Comment out the options for <span class="orange">USE_MPI</span> and <span class="orange">USE_MPIF90</span><br /> ::<div class="box"><span class="blue">#export USE_MPI=on <br>#export USE_MPIF90=on</span> </div><br /> <br /> :*If you were compiling in parallel you would leave the default entries in <span class="red">build.bash</span>. <br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_MPI</span>=<br /><span class="blue">export</span> <span class="red">USE_MPIF90</span>=</div><br /> <br /> :*We leave the compiler option as the default because this says use the <span class="forestGreen">ifort</span> (Intel FORTRAN) compiler which is what we want on the UNSW machines. <br /> ::<div class="box"><span class="blue">export</span> <span class="red">FORT</span>=ifort</div><br /> <br /> :*In the interests of speed for this tutorial, we turn off compiler optimization by activating the debug option: <br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_DEBUG</span>=on</div>On the UNSW Lab machines compiling with optimization on will take over 15 minutes, but with optimization off (USE_DEBUG=on) it will be less than 60 seconds.<br /> <br /> Save and close the <span class="red">build.bash</span> file.<br /> <br /> <br /> ==Copy the input and CPPDEFS options files==<br /> <br /> We need three more files in <span class="red">Projects/upwelling</span> to configure and run ROMS. We copy the versions downloaded with svn because these are files you will work with locally when you experiment with changes to the test case example configuration. <br /> <br /> :*Copy files <span class="red">ocean_upwelling.in, varinfo.dat</span> and <span class="red">upwelling.h</span> into the <span class="red">Projects/upwelling</span> directory you just created.<br /> <br /> ::<div class="box"><span class="forestGreen">cd ~/Projects/upwelling<br />cp /srv/ckpt/roms/shared/src/ROMS/External/ocean_upwelling.in . <br>cp /srv/ckpt/roms/shared/src/ROMS/External/varinfo.dat . <br>cp /srv/ckpt/roms/shared/src/ROMS/Include/upwelling.h .</span></div><br /> <br /> View the file <span class="red">upwelling.h</span>. It contains all the [[C_Preprocessor|C-Pre-Processor (CPP)]] options that the compiler interprets to activate certain source code options within ROMS.<br /> <br /> View the file <span class="red">ocean_upwelling.in</span>. It contains the inputs options that ROMS [[ocean.in|reads from standard input]] at run time to set options that need not be fixed at compile time. <br /> <br /> View <span class="red">varinfo.dat</span>. The file [[varinfo.dat]] contains descriptions of the names and attributes of input and output variables that ROMS reads and writes from netcdf files. For most applications you will not need to change the entries in this file. If you need to know the default units assumed for different variables, those are noted in this file. (Before we run ROMS, we will need to tell it where to find this file). <br /> <br /> Now we are ready to compile ROMS by executing the <span class="red">build.bash</span> script.<br /> <br /> ==Compile ROMS==<br /> <br /> Before you run ROMS, you need to compile it to create an executable <span class="red">oceanS</span> file ('''S''' for serial or single processor computer), or <span class="red">oceanM</span> file (if using '''MPI''' on a parallel computer).<br /> <br /> :*Go to your upwelling project directory:<br /> ::<div class="box"><span class="forestGreen">cd ~/Projects/upwelling</span></div><br /> <br /> :*Then type:<br /> ::<div class="box"><span class="forestGreen">./build.bash</span></div><br /> <br /> :*If lots of stuff comes on the screen then compilation is proceeding, and make take some time. <br /> <br /> :*If the build process ends quickly with an error, then it is likely that <span class="red">build.bash</span> does not point to the correct location for the <span class="red">upwelling.h</span> file, the FORTRAN compiler, or some libraries. We describe common ''getting started'' errors and solutions in the next section. <br /> <br /> :*You may give the option <span class="forestGreen">-j</span> to the build command to distribute the compilation to multiple processors if your host supports this, e.g.:<br /> ::<div class="box"><span class="forestGreen">./build.bash -j 8</span></div> to compile on 8 processor at once. <br /> <br /> If your build was successful it will not have reported any errors, and there will be an executable file in your <span class="red">Projects/upwelling</span> directory called <span class="forestGreen">oceanG</span>. The <span class="forestGreen">"G"</span> in the file name indicates <span class="red">build.bash</span> activated the <span class="blue">USE_DEBUG</span> option. <br /> <br /> If <span class="blue">USE_DEBUG</span> were not selected, the executable would be <span class="forestGreen">oceanS</span>, where the <span class="forestGreen">"S"</span> indicates "serial" or "single-processor" because we deactivated MPI. <br /> <br /> If you had activated MPI with the <span class="blue">USE_MPI</span> option the executable would be named <span class="forestGreen">oceanM</span>.<br /> <br /> (See also [[Frequently_Asked_Questions#My_build_finished_with_no_errors._Where_is_the_ROMS_executable.3F|FAQ: My build finished with no errors, where is the ROMS executable?]]). <br /> <br /> <br /> ===Common ''getting started'' compile error messages===<br /> <br /> Getting past the first few errors with compilation is often tricky. Carefully read any error messages you get for clues on what might be wrong with your configuration. Here are some common difficulties new users encounter getting started when first executing the <span class="red">build.bash</span> command. <br /> <br /> :*<div class="box">Compilers/../ROMS/Include/cppdefs.h:709:22: <br>error: /student/0/a0000020/Projects/upwelling/upwelling.h: No such file or directory</div> This says the file <span class="red">upwelling.h</span> is not where Build expects it to be, which is in <span class="orange">MY_PROJECT_DIR</span>. You set this to <span class="red">~/Projects/upwelling</span>.<br /> <br /> :*<div class="box">cp: cannot stat `/opt/intelsoft/netcdf/include/netcdf.mod': No such file or directory</div> This says that netcdf is not where build.bash expects to find it. Locate where the netcdf include and lib directories with steps something like:<div class="box"><span class="forestGreen">cd /usr <br>find . -name netcdf.mod -print<br></span> ./local/netcdf-3.6.2/include/netcdf.mod <br> ./local/netcdf/intel/3.6.3/include/netcdf.mod</div>This tells us the most recent (3.6.3) netcdf is in <span class="red">/usr/local/netcdf/intel/3.6.3</span>. Direct ROMS to this location by making two changes to <span class="red">build.bash</span>. First, advise ROMS to read your changes to the default library path by uncommenting the option for <span class="orange">USE_MY_LIBS</span>.<br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_MY_LIBS</span>=on</div> Then specifiy the correct location for netcdf:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">NETCDF_INCDIR</span>=/usr/local/netcdf/intel/3.6.3/include<br /><span class="blue">export</span> <span class="red">NETCDF_LIBDIR</span>=/usr/local/netcdf/intel/3.6.3/lib</div> {{warning}} Be careful where you make this change. You need to make it for the <span class="forestGreen">ifort</span> compiler option, and NOT for the <span class="orange">USE_NETCDF4</span> option (we are using netcdf-3). If you've done this correctly, your compilation with <span class="red">build.bash</span> should now succeed.<br /> <br /> :*<div class="box">error <br>error: </div> Note here further errors we encounter during the tutorial.<br /> <br /> <br /> ==Run ROMS==<br /> <br /> You run ROMS by executing the <span class="forestGreen">oceanG</span> (or <span class="forestGreen">oceanS</span>) binary, giving it the <span class="red">ocean_upwelling.in</span> file as UNIX standard input. <br /> ::<div class="box"><span class="forestGreen">./oceanS < ocean_upwelling.in</span></div> ROMS standard output will be typed to the screen. To save it a file instead, enter, e.g.:<br /> ::<div class="box"><span class="forestGreen">./oceanS < ocean_upwelling.in > my_upwelling.log </span></div><br /> <br /> If you have compiled a parallel (MPI) executable, the syntax for running the mode is slightly '''but critically''' different. The <span class="red">ocean_upwelling.in</span> file is no longer read from UNIX standard input (it has handled by all the MPI threads) so the <span class="forestGreen">"<"</span> disappears from the command, and you need the correct syntax on your UNIX host for running an MPI process. It is probably something like: <br /> ::<div class="box"><span class="forestGreen">mpirun -np 8 ./oceanM ocean_upwelling.in > my_upwelling.log</span></div> where the <span class="forestGreen">"-np 8"</span> indicates use 8 processors and this number of tiles must have been set by <br /> <br /> (See also [[Frequently_Asked_Questions#What_do_I_have_to_do_to_run_an_application.3F | FAQ: What do I have to do to runs ROMS?]]).<br /> <br /> <br /> ===Common ''getting started'' run error messages===<br /> <br /> ::<div class="box">bash: oceanG: command not found</div>The working directory is not in your UNIX path. That's why we type "dot-slash" in front of the commands above.<br /> <br /> <br /> ==Successful execution==<br /> <br /> ===Standard Output===<br /> <br /> When ROMS runs it will type a lot of information to UNIX standard output. This is the "logfile" you named following the ">", or your terminal if you did not redirect stdout. <br /> <br /> STDOUT shows the following:<br /> <br /> :*UNIX process info, run time, run TITLE <br /> ::<div class="box"> Process Information: <br> Thread # 0 (pid= 4449) is active. <br> Model Input Parameters: ROMS/TOMS version 3.2 <br> Monday - March 23, 2009 - 10:02:39 AM <br>----------------------------------------------------------- <br> Wind-Driven Upwelling/Downwelling over a Periodic Channel</div><br /> <br /> :*OS, compiler information, SVN version, and your MY_ROMS_SRC, MY_HEADER_DIR and ROMS_APPLICATION settings<br /> ::<div class="box">Operating system : Linux<br>CPU/hardware : i686<br>Compiler system : ifort <br>Compiler command : /usr/local/intel/fc/10.1.021/bin/ifort <br>Compiler flags : -heap-arrays -ip -O3 -pc80 -xW -free<br><br>SVN Root URL : <nowiki>https://www.myroms.org/svn/src/trunk</nowiki><br>SVN Revision : 333<br>Local Root : /srv/ckpt/roms/shared/src<br>Header Dir : /student/0/a0000020/srv/Projects/upwelling<br>Header file : upwelling.h<br>Analytical Dir: /student/0/a0000020/srv/Projects/upwelling<br><br>Resolution, Grid 01: 0041x0080x016, Parallel Threads: 1, Tiling: 001x001</div>Check that these are what you intended. In last line above<br /> ::*"Grid 01" pertains to future ROMS developments with multiple nested/connected grids, <br /> ::* 0041x0080x016 shows the grid size is 41 x 80 x 16 grid points in the K,J,I directions<br /> ::* The Parallel/Tiling message shows you are using a single process and a single domain tile. When using MPI, this message will describe how many tiles you are using and the MPI processes assigned. <br /> <br /> :*Input parameters set in <span class="red">ocean_upwelling.in</span><br /> ::<div class="box">Physical Parameters, Grid: 01<br>=============================<br><br> 288 ntimes Number of timesteps for 3-D equations.<br> 300.000 dt Timestep size (s) for 3-D equations.<br> 30 ndtfast Number of timesteps for 2-D equations between<br> each 3D timestep.<br> ...<br> Output Averages File: ocean_avg.nc<br> Output Diagnostics File: ocean_dia.nc</div><br /> <br /> :*Then some more about the tiling when running in parallel<br /> <br /> :*The C-PreProcessor (CPP) flags set in <span class="red">upwelling.h</span> but '''AS MODIFIED''' by ROMS when interpreting and checking the selected CPP options. <br /> ::<div class="box"> Activated C-preprocessing Options:<br><br> UPWELLING Wind-Driven Upwelling/Downwelling over a Periodic Channel<br> ANA_BSFLUX Analytical kinematic bottom salinity flux.<br> ANA_BTFLUX Analytical kinematic bottom temperature flux.<br> ANA_GRID Analytical grid set-up.<br> ANA_INITIAL Analytical initial conditions.<br> ...</div>You should check that the CPP options displayed here agree with what you intended. For example, if you inadvertently specify more than one horizontal advection scheme option, ROMS will have chosen only one and reported that option here.<br /> <br /> :*The preamble in STDOUT continues with information about the space and time discretization: grid spacing, grid volume, Courant number (time step stability) and stiffness (related to s-coordinate accuracy).<br /> <br /> :*Then the model starts time stepping:<br /> ::<div class="box">NL ROMS/TOMS: started time-stepping: (Grid: 01 TimeSteps: 00000001 - 00000288)<br><br> STEP Day HH:MM:SS KINETIC_ENRG POTEN_ENRG TOTAL_ENRG NET_VOLUME<br><br> 0 0 00:00:00 0.000000E+00 6.579497E+02 6.579497E+02 3.884376E+11<br> DEF_HIS - creating history file: ocean_his.nc<br> WRT_HIS - wrote history fields (Index=1,1) into time record = 000000<br> DEF_AVG - creating average file: ocean_avg.nc<br> DEF_DIAGS - creating diagnostics file: ocean_dia.nc<br> 1 0 00:05:00 3.268255E-13 6.579497E+02 6.579497E+02 3.884376E+11<br> 2 0 00:10:00 6.503587E-12 6.579497E+02 6.579497E+02 3.884376E+11<br> 3 0 00:15:00 4.592307E-11 6.579497E+02 6.579497E+02 3.884376E+11<br><br> ...</div>This output indicates several things:<br /> ::*the run is programmed to run from time step 1 to 288<br /> ::*the run starts at time 00:00:0<br /> ::*netcdf output HISTORY, AVERAGES and DIAGNOSTICS files are created. Every time ROMS creates a new netcdf file, and writes to an existing file, it reports this to STDOUT<br /> ::*output is written to the HISTORY file<br /> ::*then global quantities related to the model KE, PE and domain volume are reported on each time step<br /> <br /> {{note}} In 99% of situations, ''getting started'' problems with model set-up and configuration can be diagnosed by carefully reading the STDOUT above. Things to look for are:<br /> :*misconfigured CPP options (what you got is not what you thought you asked for)<br /> :*parameter errors (e.g. you activated horizontal mixing but left the coefficient as zero)<br /> :*misnamed output files (that's why the files from your last run got overwritten)<br /> :*irrational choices of grid spacing or time step <br /> :*initial/boundary/forcing data being read from the wrong file, or not read at all (because you selected analytical conditions)<br /> <br /> At the conclusion of the run, ROMS reports information about run time:<br /> ::<div class="box"> Elapsed CPU time (seconds):<br><br> Thread # 0 CPU: 108.079<br> Total: 108.079<br><br>Nonlinear model elapsed time profile:<br><br> Initialization ................................... 0.016 ( 0.0148 %)<br> Processing of input data ......................... 0.028 ( 0.0259 %)<br> Processing of output time averaged data .......... 4.312 ( 3.9899 %)<br> ... </div><br /> :*about the number of output records written to each file<br /> ::<div class="box"> ROMS/TOMS - Output NetCDF summary for Grid 01: <br> number of time records written in HISTORY file = 00000005 <br> ...</div><br /> :*and the analytical files included <br /> ::<div class="box"> Analytical header files used:<br><br> ROMS/Functionals/ana_btflux.h<br> ROMS/Functionals/ana_grid.h<br> ...</div>If you used a modified analytical file in your <span class="orange">MY_HEADER_DIR</span> it will be reported here and is another thing you should check for consistency with your intentions.<br /> <br /> <br /> ===Netcdf file output===<br /> <br /> As reported above, ROMS created 4 output netcdf files when it ran. There are ocean_his.nc, ocean_avg.nc, ocean_dia.nc, and coean_rst.nc. These are, respectively:<br /> :*history records or 'snapshots' of the model state a selected time intervals<br /> :*averages of the model state over selected intervals (not necessarily the same intervals as the history)<br /> :*diagnostics of the model state, the precise contents of which are controlled by CPP options<br /> :*a restart file with everything ROMS needs to restart a application. This is useful if your job crashes at some point and you want to recommence from a previous state without starting over. Typically the restart file is set to keep just 2 time records by continually over-writing the oldest as the run proceeds. This behaviour is controlled in ocean_upwelling.in. Also, when ROMS "blows up" it dumps the ocean state to a 3rd record in the restart file. <br /> <br /> You can browse the contents of netcdf files at the UNIX command line with the command ncdump, e.g. <br /> ::<div class="box"><span class="forestGreen">ncdump -h ocean_his.nc | more</span> </div><br /> Note the use of the <span class="forestGreen">"-h"</span> option. This restricts the output from ncdump to be just the header information, or metadata, in the netcdf file. Without the "-h" option you will get the entire contents of the file converted to ascii. <br /> <br /> Things to notice when you ncdump the ocean_his.nc file are that it contains all the input parameters (time step, mixing coefficients, s-coordinate parameters, etc.) from ocean.in, the model grid coordinates (x, y, lon, lat, depth, Coriolis parameter, etc.) which may have been computed by the ANA_GRID option or read from an input grid netcdf file, in addition to the actual model output (ocean_time, zeta, u, v, temp, salt). <br /> <br /> There are netcdf '''global attributes''' that echo much of the information typed to STDOUT. This includes compiler, svn version, and project directory information, and all the CPP options. This is a valuable source of information when returning to a project and trying to figure out what you did! The global attributes metadata show precisely which options were activated when creating the output in this netcdf file. <br /> <br /> <br /> ==Changing the UPWELLING test case configuration==<br /> <br /> <br /> ===Compile time changes: <span class="red">upwelling.h</span>===<br /> <br /> Changes to options that must be set at compilation time are made to the upwelling.h file. These settings are interpreted during the C-PreProcessing step. <br /> <br /> To see what the present options are, edit the upwelling.h file:<br /> ::<div class="box"><span class="forestGreen">vi upwelling.h</span></div><br /> <br /> Recall that the actual options active after this file in interpreted will be typed to STDOUT (the "logfile") and also written to the output netcdf file in the global attributes.<br /> <br /> To see the all the options that might be set using C-PreProcessor directives, you can browse the <span class="forestGreen">cppdefs.h</span> file in the <span class="red">ROMS/Include</span> directory underneath the <span class="orange">MY_ROMS_SRC</span> location set in your build.bash. In this case:<br /> ::<div class="box"><span class="forestGreen">cd /srv/ckpt/roms/shared/src<br>more ROMS/Include/cppdefs.h</span></div><br /> <br /> The contents of this file are almost entirely comments and are provided to document the options available. For more information consult WikiROMS or the User Forum.<br /> <br /> At the very bottom of <span class="red">cppdefs.h</span> you will see a short code segment that loads the actual application options from ROMS_HEADER. This variable is set by the <span class="orange">ROMS_APPLICATION</span> value in build.bash.<br /> <br /> <br /> ===Run time changes: <span class="red">ocean_upwelling.in</span>===<br /> <br /> Changes to options that are set at run time are made to the ocean_upwelling.in file. <br /> <br /> To see what the present options are, edit the ocean_upwelling.in file:<br /> ::<div class="box"><span class="forestGreen">vi ocean_upwelling.in</span></div><br /> <br /> Comments at the beginning of this file document the <span class="blue">KEYWORD <nowiki>==</nowiki> value</span> syntax.<br /> <br /> Comments at the end of file provide brief summaries of what each parameter does. <br /> <br /> For more information consult WikiROMS or the Use Forum. <br /> <br /> Recall that the actual parameter values ROMS uses after reading this file will be typed to STDOUT (the "logfile") and also written to the output netcdf files.<br /> <br /> ==A ''Realistic'' model example: LaTTE==<br /> <br /> This section of the tutorial assumes you have successfully compiled and run the UPWELLING example above. Key concepts you should be comfortable with before you proceed are:<br /> :*you need a new directory where you will keep the files specific to the new application<br /> :*customize <span class="red">build.bash</span> for the new application (copy the build.bash from <span class="red">upwelling</span> because it has all the correct compiler and library settings)<br /> :*set <span class="blue">MY_PROJECT_DIR</span> in <span class="red">build.bash</span> to point to the directory for the new application<br /> :*set <span class="blue">ROMS_APPLICATION</span> in <span class="red">build.bash</span> to the correct name for the new application<br /> :*if you wish to customize any of the <span class="forestGreen">ana_*.h</span> files, copy just the ones you need into the new project directory <br /> :*you '''don't''' need to make a copy the source code a new application<br /> <br /> With these concepts in mind, we proceed by configuring ROMS to run a realistic coastal ocean application that includes open boundaries on 3 sides, open boundary tides and climatological open boundary velocity and tracer (temperature and salinity) conditions, surface meteorological forcing, and initial conditions, all provided by input netcdf files. <br /> <br /> The example is called LaTTE_C because it simulates ocean conditions during the '''Lagrangian Transport and Transformation Experiment''' conducted on the New Jersey inner shelf in the Spring of 2006. The '_C' denotes a coarse resolution configuration suitable for this training exercise. <br /> <br /> <br /> ===Create a latte_c project directory===<br /> <br /> We have placed the CPP options file <span class="red">latte_c.h</span>, standand input <span class="red">ocean_lattec.in</span>, and a modified <span class="red">varinfo.dat</span> in <span class="red">/srv/ckpt/roms/shared/latte_c/Forward</span>. Make a new Project directory for this new application and copy these 3 files. '''DO NOT''' copy all the netcdf files from <span class="red">/srv/ckpt/roms/shared/latte_c/in<br /> </span>.<br /> <br /> ===Edit build.bash===<br /> <br /> Set the correct entries for environment variables that define the user application.<br /> <br /> <span class="blue">ROMS_APPLICATION=LATTE_C</span> causes <span class="red">build.bash</span> to look for the file <span class="red">latte_c.h</span> in order to set the CPP options<br /> <br /> <span class="blue">MY_PROJECT_DIR=${HOME}/Projects/latte_c</span> will instruct build.bash where to look for the latte_c.h file. <br /> <br /> Setting <span class="blue">MY_HEADER_DIR</span> would instruct ROMS where to look for the user functional files <span class="red">ana_*.h</span> that over-ride default options. In this example, however, we don’t actually need to modify any of those functionals. This is typical of “realistic” applications where input grid, initial and boundary conditions are provided from data in input netcdf files. <br /> <br /> {{note}}The format of ROMS output files (history, averages and restart) is the same as ROMS input initial conditions and climatology. This means the output of previous runs can become the initial conditions, or 3-D climatology (for nudging) for new runs. <br /> <br /> ===Edit ocean_lattec.in===<br /> <br /> Open the ocean_lattec.in file in an editor. There are KEYWORDS that define the names of the input netcdf files for applications of this type:<br /> :*GRDNAME is the grid file with coordinates, grid metrics (spacing), bathymetry, land/sea mask and Coriolis<br /> :*ININAME is the initial conditions<br /> :*BRYNAME are the open boundary sea leve, velocity and tracer conditions<br /> :*FRCNAME are the tides, river source, and surface meteorological forcing files. Notice there are multiple files and the number of files ROMS is to read is set by the NFFILES parameter. On initialization, ROMS scans this list for each forcing variable it needs, using the first file to contain the necessary and ''shadowing'' any entry in subsequent files. Therefore if you want to re-run your model with a new set of wind data but happen to have other wind data in a files with all your other meteorology inputs, just put the new file at the beginning of the list.<br /> <br /> There are KEYWORDS that determine the output file names. These are:<br /> :*RSTNAME, HISNAME, AVGNAME, DIANAME, STANAME, FLTNAME .... etc<br /> <br /> There are keywords that set how many time steps ROMS takes between writing output. These are:<br /> :*NRST,NHIS,NAVG,NDIA,NSTA ...etc<br /> <br /> You can have ROMS write multiple records to each output file at these intervals, but periodically create a new file (to keep file sizes manageable) by setting the keywords:<br /> :*NDEFHIS,NDEFAVG,NDEFDIA <br /> <br /> <br /> <br /> ===Compile with build.bash===<br /> <br /> If you have set the entries in build.bash correctly, you compile exactly as before by executing the script. <br /> <br /> Watch the output of the build process. You should see that instead of "Project/upwelling/Build" the compilation is now writing temporary files to "Project/latte_c/Build". This Build subdirectory is kept separate so you can be working on two projects at once and not confuse things.<br /> <br /> cd to the Build subdirectory and look at some of the files there, e.g.<br /> ::<div class="box"><span class="forestGreen">cd ~/Projects/latte_c/Build<br>more u3dbc_im.f90</span></div><br /> This is the file that sets open boundary conditions on 3-d velocity. This is the Fortran90 file that is generated after the C-PreProcessor has done its job. If you find your model is doing things you don't expect, it can be instructive to view the <span class="forestGreen">".f90"</span> file and corresponding <span class="forestGreen">".F"</span> (in MY_ROMS_SRC) to see whether the CPP options being processed are what you intended. If not, review your header file (in this case latte_c.h), and the list of CPP options typed to STDOUT. Don't edit the "f90" file directly because it gets over-written when you recompile.<br /> <br /> ==Before we run latte_c==<br /> <br /> ===Browse the latte_c.h options===<br /> <br /> Use <span class="forestGreen">vi</span> or <span class="forestGreen">more</span> to browse the CPP options used in this "realistic" application. Things to notice that are different from <span class="red">upwelling.h</span> are:<br /> <br /> :*There are no <span class="blue">ANA_INITIAL</span> or <span class="blue">ANA_WINDS</span> options. If analytical initial and forcing options are not set with a <span class="blue">#define</span> then ROMS defaults to reading this information from input netcdf files.<br /> <br /> :*<span class="blue">WEST_, EAST_, SOUTH_</span> and <span class="blue">NORTHERN_WALL</span>. These options define the open boundary schemes. (The nomenclature of the compass points assume a grid oriented with west along ''i=1'' and south along ''j=1''). The upwelling case had closed boundaries to the north and south, and periodic conditions east-west. The open boundary conditions here are set with the following options:<br /> <br /> :*<span class="blue">WEST_FSCHAPMAN,WEST_M2FLATHER</span> etc. indicate “west” side free surface (FS) and depth-averaged velocity/momentum (M2)<br /> <br /> :*<span class="blue">WEST_M3GRADIENT,WEST_TGRADIENT</span> “west side” 3-d velocity/momentum (M3) and all tracers. <br /> <br /> :*<span class="blue">SSH_TIDES, UV_TIDES</span> cause ROMS to add tidal variability in sea level and depth-average velocity using the harmonics read from the tides forcing file. See the wikiROMS entry on tides for more information. <br /> <br /> :*<span class="blue"><nowiki>#</nowiki>ifdef SSH_TIDES<br> #define ADD_FSOBC</span><br>This construct is a conditional test that causes prescribed mean or slowly varying sea surface height to be added to the tidal variability. <br> The further option <span class="blue">ANA_FSOBC</span> means the prescribed value is set by one of the analytical functional include files. If <span class="blue">ANA_FSOBC</span> is not defined, ROMS will look for the boundary sea level in a boundary conditions file. <br /> <br /> :*<span class="blue">BULK_FLUXES</span> In this application the surface meteorology forcing files give net shortwave and longwave radiation and the temperature, pressure and humidity conditions in the marine atmospheric boundary layer. These values are converted to air-sea fluxes of heat and momentum according to the Fairall et al. bulk formulae. <br /> <br /> :*<span class="blue">GLS_MIXING</span> This activates the Generalized Length Scale vertical turbulence closure parameterization of Umlauf and Buchard. Parameters in ocean_lattec.in determine details such as whether the closure method is actually k-epsilon, k-kl, etc. <br /> <br /> :*<span class="blue">UV_PSOURCE, TS_PSOURCE</span> These options activate point sources; in this case the inflow of the Hudson River.<br /> <br /> ===The input netcdf files===<br /> <br /> Use ncdump to browse the contents of some of the input files, e.g.:<br /> ::<div class="box"><span class="forestGreen">ncdump -h frc_lattec_wrf_Pair.nc | more</span></div><br /> <br /> We see that in this case the dimensions of the data match the dimensions of the ROMS grid:<br /> ::<div class="box">dimensions:<br> time = UNLIMITED ; // (1560 currently)<br> eta_rho = 82 ;<br> xi_rho = 146 ;</div>For '''time varying 2D surface forcing data only''' (e.g. meteorological data) ROMS will regrid during execution 2D data defined on simple 1D coordinates (vectors of lon and lat). In all other cases, the forcing data must have already been interpolated to the ROMS grid. <br /> <br /> ROMS associates the variable name of the forcing data with the appropriate internal variable by consulting the entries in varinfo.dat. Edit varinfo.dat and search for the string "Pair" <br /> ::<div class="box"><span class="forestGreen">vi varinfo.dat</span></div><br /> ::<div class="box">'Pair' ! Input<br> 'surface air pressure'<br> 'millibar' ! [millibar]<br> 'Pair, scalar, series'<br> 'pair_time'<br> 'idPair'<br> 'r2dvar'<br> 1.0d0</div>This tells us 3 important things:<br /> ::*The name of the surface air pressure variable in the forcing netcdf is "Pair". If your netcdf file was made with some other name you can change it here, e.g. "press_sfc" and you DO NOT need to change the netcdf file. This is acceptable because the variable is strictly an ''Input'' variable as noted by the comment <nowiki>(! Input)</nowiki> at the end of the first line.<br /> ::*The units are assumed to be millibars. If your data are not in millibars you must either modify the data in the forcing netcdf file, or you may apply a scalar factor by editing the last line in the block above (presently set to 1.0d0).<br /> ::*The Pair data are defined at the times recorded by the variable named "pair_time" in the same forcing netcdf file. '''However''', in the netcdf file itself this default can be reset by adding a "time" attribute to Pair. Return to viewing the netcdf file with ncdump to see this: <br /> <br /> ::<div class="box">variables:<br> double Pair(time, eta_rho, xi_rho) ;<br> Pair:long_name = "Surface air pressure" ;<br>...<br> Pair:time = "ncep_time" ;<br> double ncep_time(time) ;<br> ncep_time:long_name = "forcing observations time" ;<br> ncep_time:units = "days since 01-Jan-2006" ;</div>The "time" attribute "Pair:time" indicates that variable "ncep_time" in this file contains the times at which the air pressure is reported. This overrides the value in varinfo.dat. The units attribute to ncep_time shows the CF convention of "days since 2006-01-01 00:00:0". This time base must match in ALL your forcing netcdf files AND the initial conditions file. ROMS '''will not enforce consistency between different time conventions''' - that would be nice but for now it's on you. (Nor will the ''TIME_REF'' keyword in ocean.in adjust this time - it only sets the units attribute string for ''ocean_time'' in output netcdf files so you need to take care to set all these times be be consistent.) Nor will ROMS convert data units if they do not match what is assumed in varinfo.dat. The units attributes in this file are therefore purely metadata that document the file contents. <br /> <br /> <br /> Let's also examine the format of the open boundary conditions file:<br /> ::<div class="box"><span class="forestGreen">ncdump -h lattec_bndy_uv2d_half.nc | more</span></div><br /> <br /> The file has the same dimensions as the forcing files and output netcdf files. It contains parameters and variables that define the vertical s-coordinate and then the actual open boundary data such as:<br /> ::<div class="box"> float temp_east(time, s_rho, eta_rho) ;<br> temp_east:long_name = "potential temperature east boundary condition" ;<br> temp_east:units = "Celcius" ;<br> temp_east:field = "temp_east, scalar, series" ;<br> temp_east:time = "ocean_time" ;</div>Notice that this variable has dimensions "''(time, s_rho, eta_rho)''" which describe a time varying 2D spatial structure in depth (s_rho) and horizontal coordinate (eta_rho). This "east" boundary is at constant "i" index (i=L) and therefore has no "xi" coordinate dimension. The data along the southern boundary on the other hand,'' temp_south'', has dimensions "''(time, s_rho, xi_rho)''".<br /> <br /> ==Run the latte_c example==<br /> <br /> Run the model exactly as you did in the UPWELLING example, but giving the new ocean_lattec.in as the input file.<br /> <br /> :*UNIX process info, run time, run TITLE <br /> ::<div class="box"><span class="forestGreen">./oceanG < ocean_lattec.in</span> </div><br /> <br /> === Stdout for Latte_C===<br /> <br /> The preamble to STDOUT (which you might redirect to a logfile with ">") will resemble what you saw for UPWELLING. UNIX process information, compiler and svn version information, model input parameters read from the ocean.in file, and the list of active CPP options. <br /> <br /> The differences from UPWELLING come shortly before the model begins time stepping. ROMS reports the following information to help you check that you have configured the model correctly.<br /> <br /> :*Initial conditions<br /> ::<div class="box">NLM: GET_STATE - Read state initial conditions, t = 94 00:00:00<br> (File: lattec_ini_94.nc, Rec=0001, Index=1)<br> - free-surface<br> (Min = -7.02081803E-01 Max = 0.00000000E+00)</div>This shows initial time is 94 days, that initial conditions were read from record 1 of file lattec_ini_94.nc, and that the free surface data read ranged from -0.702 meters to 0 meters. Check: are data being read from the correct file for the correct record/time? If you see unrealistic values in the Min/Max range you may have special values (999?) in your input netcdf file, or a units error.<br /> <br /> :*Forcing data - static non time varying<br /> ::<div class="box"> GET_NGFLD - tidal period<br> (Min = 4.30820452E+04 Max = 9.67260840E+04)<br> GET_2DFLD - tidal elevation amplitude<br> (Min = 0.00000000E+00 Max = 1.13473975E+00) </div>The vector of tidal priods (in hours) are read and then 2D fields of tidal elevation and velocity. Again: check the file source and Min/Max range. <br /> <br /> :*Forcing data - time varying <br /> ::<div class="box"> GET_NGFLD - river runoff mass transport, t = 94 00:00:00<br> (Rec=0465, Index=2, File: roms_lattec_river.nc)<br> (Tmin= -370.0000 Tmax= 267.0000)<br> (Min = -9.25473328E+02 Max = -1.69902756E+02)<br>...<br> GET_2DFLD - surface u-wind component, t = 94 00:00:00<br> (Rec=0001, Index=1, File: frc_latte_wrf_Uwind.nc)<br> (Tmin= 94.0000 Tmax= 158.9583)<br> (Min = -8.73357999E-02 Max = 4.12751995E+00)<br>...<br> GET_NGFLD - river runoff mass transport, t = 95 00:00:00<br> (Rec=0466, Index=1, File: roms_lattec_river.nc)<br> (Tmin= -370.0000 Tmax= 267.0000)<br> (Min = -9.88811890E+02 Max = -1.86609863E+02)<br>...<br> GET_2DFLD - surface u-wind component, t = 94 00:59:59<br> (Rec=0002, Index=2, File: frc_latte_wrf_Uwind.nc)<br> (Tmin= 94.0000 Tmax= 158.9583)<br> (Min = -1.26112560E-01 Max = 2.46840043E+00)<br></div>Time varying forcing data will be read for times that bracket the current ROMS time. ROMS finds the correct times from the time variable in the files (which can be different for each variable - see the "time" attribute of the data). ROMS linearly interpolates the forcing data for these two records to the ROMS ocean_time on every model time step. The forcing data do not need to be regularly spaced in time, but the data do need to bracket ROMS initial time for the model to start. Again: check file names, data ranges and the times. Recall that if forcing data of the same name occurs in two forcing files in the list set by FRCNAME in ocean.in then ROMS takes the first data it finds. This will be the filename in the message above. <br /> <br /> :*The model then begins execution, reporting global energy diagnostics and any netcdf files it creates and writes to.<br /> ::<div class="box"> STEP Day HH:MM:SS KINETIC_ENRG POTEN_ENRG TOTAL_ENRG NET_VOLUME<br><br> 0 94 00:00:00 9.698352E-03 2.011729E+02 2.011826E+02 1.421876E+12<br> DEF_HIS - creating history file: ./out/his_lattec.nc<br> WRT_HIS - wrote history fields (Index=1,1) into time record = 0000001<br> DEF_STATION - creating stations file: ./out/sta_ocean.nc<br> 1 94 00:06:00 8.873902E-03 2.011284E+02 2.011372E+02 1.422005E+12<br> 2 94 00:12:00 8.377911E-03 2.011090E+02 ...</div><br /> <br /> If in this initialization phase you do not see a report of values you expected ROMS to read, then ROMS '''did not''' read those data. This could be because you have an ANA option set that causes ROMS to get the information internally, or you may have set other CPP options such that there is no need to read the data. '''ROMS does not read data from netcdf files that it does not need to run.''' This information will help you diagnose misconfiguration or misunderstanding of the interaction of various CPP options.<br /> <br /> :*New forcing data when required<br /> ::<div class="box"> 9 94 00:54:00 6.518542E-03 2.012623E+02 2.012688E+02 1.424463E+12<br> GET_2DFLD - surface u-wind component, t = 94 02:00:00<br> (Rec=0003, Index=1, File: frc_latte_wrf_Uwind.nc)<br> (Tmin= 94.0000 Tmax= 158.9583)<br> (Min = -4.55454426E-01 Max = 4.03826709E+00)</div>When ROMS ocean_time reaches the end of the interval bracketed by any forcing data it holds in memory it will read the next set of values from the netcdf file and report this to STDOUT. If ROMS runs for a while and crashes shortly after reading some new forcing data check that you don't have corrupt data (from the Min/Max range). <br /> <br /> Eventually ROMS concludes and provides the same report it did in the UPWELLING example: elapsed time profile, the number of output records written, and the analytical functional used at compilation.<br /> <br /> ==Plotting netcdf output with Matlab==<br /> <br /> ===Basics of Matlab-Netcdf===<br /> <br /> Matlab version 2008b, which is installed on the UNSW Computer Lab machines, has support for reading netcdf files. It uses the built-in java tools to do this and the necessity to install a machine-dependent set of mexnc routines that was required in earlier versions of Matlab is no longer necessary.<br /> <br /> To ease the process of reading netcdf files into the Matlab workspace we have however installed a set of Matlab m-files called SNCTOOLS, written by John Evans at Mathworks. These tools should be in your Matlab path. You can verify this in Matlab by entering the command <span class="forestGreen">which nc_varget</span>. <br /> <br /> nc_varget is the workhorse utility that reads subsets of data from a netcdf file. Many of the Matlab tools that people distribute for working with ROMS output use SNCTOOLS functions, like nc_varget, to provide the interface to reading netcd files. You won't get much further in this part of the tutorial if you can't work nc_varget.<br /> <br /> Enter <span class="forestGreen">help nc_varget</span> to see the syntax. <br /> <br /> Note that nc_varget also supports reading from OPeNDAP/THREDDS data servers in addition to reading from local netcdf files. <br /> <br /> ===Using the roms_wilkin Matlab routines===<br /> <br /> ROMS output files are CF-Compliant netcdf files and therefore there are many software tools that allow you to browse, extract and plot output easily. There are also a number of collections of code written for Matlab that offer tools for plotting ROMS output. What you choose to use is a matter of personal preference and the functionality offered. <br /> <br /> For this tutorial I show just a few tools out of the set of <span class="purple">roms_wilkin</span> Matlab tools described in more detail at the tiddlywiki http://romsmatlab.tiddlyspot.com and also at [https://www.myroms.org/forum/viewtopic.php?f=23&t=916&start=0&hilit=roms_wilkin this thread] on the ROMS forum.<br /> <br /> On the UNSW Computer Lab machines you can add the directory of roms_wilkin Matlab routines to your Matlab path using the command: <br /> ::<div class="box"> <span class="purple">>> addpath('/student/0/a0000020/matlab/roms_wilkin','-end')</span></div><br /> <br /> The <span class="purple">{z,s,i,j}view</span> routines in roms_wilkin make simple plots directly from a ROMS file or OPeNDAP URL by slicing along coordinate directions. Enter <span class="purple">help roms_zview</span> to see the syntax. The functions all make use of the model coordinates loaded into a structure by function <span class="purple">roms_get_grid</span>. <br /> <br /> In matlab, load this grid structure from any file containing the grid coordinates, such as an output file:<br /> ::<div class="box"><span class="purple"> >> file = 'his_lattec.h';<br> >> g = roms_get_grid(file,file); </span></div><br /> <br /> Then to make a plot at constant z = -3 metres of salinity from time record 2 of the file, overlaying green coloured velocity vectors at every 2nd grid point (scaled by a factor of 0.2 deg lon/at per m/s), enter:<br /> ::<div class="box"><span class="purple"> >> roms_zview(file,'salt',2,-3,g,3,0.2,'g');</span></div> Not much has happened because we are only a few hours into the simulation so make it easier to the extent of the low salinity Hudson River water by changing the colorbar range and zooming in:<br /> ::<div class="box"><span class="purple"> >> caxis([20 34]); colorbar <br> >> axis([-74.4 -73.2 39.9 41]) </span></div><br /> <br /> If you specify time as a string instead of an index, <span class="purple">roms_zview</span> will endeavour to parse the time/date information in the file and select the record nearest in time to plot. You can also give an optional output argument to roms_zview in which case it returns a structure with the data that went in to the plot. <br /> ::<div class="box"><span class="purple"> >> thedata = roms_zview(file,'salt','2006-04-05 02:00',-3,g,3,0.2,'g');</span></div><br /> <br /> The output structure <span class="purple">thedata</span> contains: <br /> ::<div class="box"><span class="purple">thedata = <br><br> x: [82x146 double]<br> y: [82x146 double]<br> data: [82x146 double]<br> t: 7.3277e+05<br> tstr: '05-Apr-2006 03:00:00'<br> u: [82x145 double]<br> v: [81x146 double]<br> ue: [726x1 double]<br> vn: [726x1 double]<br> xq: [726x1 double]<br> yq: [726x1 double]</span></div><br /> <br /> "File" could equally well have been an OPeNDAP URL to ROMS output such as the example in the [https://www.myroms.org/forum/viewtopic.php?f=23&t=916&start=0&hilit=roms_wilkin ROMS Forum].<br /> ::<div class="box"><span class="purple"> >> file = <nowiki>'http://tashtego.marine.rutgers.edu:8080/thredds/dodsC/roms/cblast/2002-050/averages'</nowiki><br> >> g = roms_get_grid(file,file); % the grid structure<br> >> % temperature slice for time step nearest to 20JUN2002, at 2-m <br> >> % depth, with every 3rd velocity vector over-plotted<br> >> roms_zview(file,'temp','20-Jun-2002',-2,g,3,.1,'k')</span></div></div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3679 CSTMS UNSW2008 2009-04-09T02:21:39Z

<p>Csherwood: /* Make an init file (Run03) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original ''.h'' and ''.in'' files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the ''.h'' file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the ''.in'' file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ''../out''.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[w:ChangeTcline|Changing netCDF variables]].<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <div class="box"><span class="red">#define TS_MPDATA</span></div>and<div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div>(or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div>We will only have one bed layer; it should be thick enough so that it does not erode completely in most of the model domain but, if it is too thick, changes in composition during the model run will be less apparent. We are going to specify only one non-cohesive sediment class, so we need only one value for each parameter.<div class="box"> NEWLAYER_THICK == 0.01d0<br><br>...<br><br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...<br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * Add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<div class="box"> ININAME == ../in/lattec_sed1_ini_94.nc</div><br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br></div>* Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ==Needs waves!==<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3678 CSTMS UNSW2008 2009-04-09T02:17:28Z

<p>Csherwood: /* Make an init file (Run03) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original ''.h'' and ''.in'' files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the ''.h'' file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the ''.in'' file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ''../out''.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[w:ChangeTcline|Changing netCDF variables]].<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <div class="box"><span class="red">#define TS_MPDATA</span></div>and<div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div>(or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div>We will only have one bed layer; it should be thick enough so that it does not erode completely in most of the model domain but, if it is too thick, changes in composition during the model run will be less apparent. We are going to specify only one non-cohesive sediment class, so we need only one value for each parameter.<div class="box"> NEWLAYER_THICK == 0.01d0<br><br>...<br><br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...<br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * Add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<div class="box"> ININAME == ../in/lattec_sed1_ini_94.nc</div><br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br><\div>* Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3677 CSTMS UNSW2008 2009-04-09T02:07:59Z

<p>Csherwood: /* Change the advection scheme (Run01) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original ''.h'' and ''.in'' files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the ''.h'' file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the ''.in'' file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ''../out''.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[w:ChangeTcline|Changing netCDF variables]].<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <div class="box"><span class="red">#define TS_MPDATA</span></div>and<div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div>(or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div><br /> We are going to specify only one non-cohesive sediment class.<div class="box"> NEWLAYER_THICK == 0.01d0<br>...<br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...<br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * We will need to add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<div class="box"> ININAME == ../in/lattec_sed1_ini_94.nc</div><br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<br /> <div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br><\div><br /> * Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3676 CSTMS UNSW2008 2009-04-09T02:07:34Z

<p>Csherwood: /* Change the advection scheme (Run01) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original ''.h'' and ''.in'' files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the ''.h'' file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the ''.in'' file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ''../out''.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[w:ChangeTcline|Changing netCDF variables]].<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <div class="box"><span class="red">#define TS_MPDATA</span></div>and<div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div><br /> We are going to specify only one non-cohesive sediment class.<div class="box"> NEWLAYER_THICK == 0.01d0<br>...<br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...<br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * We will need to add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<div class="box"> ININAME == ../in/lattec_sed1_ini_94.nc</div><br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<br /> <div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br><\div><br /> * Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3675 CSTMS UNSW2008 2009-04-09T02:06:48Z

<p>Csherwood: /* Build and run the Latte example */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original ''.h'' and ''.in'' files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the ''.h'' file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the ''.in'' file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ''../out''.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[w:ChangeTcline|Changing netCDF variables]].<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div><br /> We are going to specify only one non-cohesive sediment class.<div class="box"> NEWLAYER_THICK == 0.01d0<br>...<br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...<br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * We will need to add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<div class="box"> ININAME == ../in/lattec_sed1_ini_94.nc</div><br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<br /> <div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br><\div><br /> * Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3674 CSTMS UNSW2008 2009-04-08T18:27:40Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the .h file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the .in file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ../out.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[ChangeTcline]Changing netCDF variables]<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div><br /> We are going to specify only one non-cohesive sediment class.<div class="box"> NEWLAYER_THICK == 0.01d0<br>...<br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...<br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * We will need to add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<div class="box"> ININAME == ../in/lattec_sed1_ini_94.nc</div><br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<br /> <div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br><\div><br /> * Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3673 CSTMS UNSW2008 2009-04-08T18:22:27Z

<p>Csherwood: /* Make an init file (Run03) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the .h file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the .in file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ../out.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[ChangeTcline]Changing netCDF variables]<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application and make some changes.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div><br /> We are going to specify only one non-cohesive sediment class.<div class="box"> NEWLAYER_THICK == 0.01d0<br>...<br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div>If we had several sediment classes, we would need more (NNS) numbers arrayed across after each variable.<br /> * Make several changes to the .in file, starting with the title.<div class="box"> TITLE = Latte Tutorial, Run03</div>Specify the number of sediment tracers...in this case, one non-cohesive size.<div class="box"> NCS = 0 ! Number of cohesive (mud) sediment tracers<br><br /> NNS = 1 ! Number of non-cohesive (sand) sediment tracers</div>Turn on additional output to appear in the .his output file.<div class="box">...br>Hout(idUbrs) == T ! bottom U-current stress<br>Hout(idVbrs) == T ! bottom V-current stress<br>Hout(idUbws) == T ! bottom U-wave stress<br>Hout(idVbws) == T ! bottom V-wave stress<br>Hout(idUbcs) == T ! bottom max wave-current U-stress<br>Hout(idVbcs) == T ! bottom max wave-current V-stress<br><br>Hout(idUbot) == T ! bed wave orbital U-velocity<br>Hout(idVbot) == T ! bed wave orbital V-velocity<br>Hout(idUbur) == T ! bottom U-velocity above bed<br>Hout(idVbvr) == T ! bottom V-velocity above bed<br>...<br>Hout(idBott) == T T T T T T T T T F F F F F F F<br>...</div><br /> * We will need to add more information to the initialization file (discussed in the next section), so we will point to that in the .in file<br /> ININAME == ../in/lattec_sed1_ini_94.nc<br /> * We want to add some waves, so a wave forcing file (see below) is added to the list and NFFILES is increased.<br /> <div class="box"> NFFILES == 10 ! number of forcing files<br><br> FRCNAME == ../in/frc_latte_wrf_Lwrf.nc \<br> ../in/frc_latte_wrf_Pair.nc \<br><br /> ../in/frc_latte_wrf_Qair.nc \<br> ../in/frc_latte_wrf_Swrf.nc \<br> ../in/frc_latte_wrf_Tair.nc \<br> ../in/frc_latte_wrf_Uwind.nc \<br> ../in/frc_latte_wrf_Vwind.nc \<br> ../in/roms_lattec_river.nc \<br> ../in/frc_tides_lattec.nc \<br> ../in/frc_lattec_small_waves.nc<br><\div><br /> * Also, rename the output files<div class="box"> ! Output NetCDF file names, [1:Ngrids].<br><br> GSTNAME == ocean_gst.nc<br> RSTNAME == ../out/lattec_rst_run03.nc<br> HISNAME == ../out/lattec_his_run03.nc<br></div><br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3672 CSTMS UNSW2008 2009-04-08T17:57:49Z

<p>Csherwood: /* Make an init file (Run03) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the .h file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the .in file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ../out.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[ChangeTcline]Changing netCDF variables]<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div><br /> * Change some of the parameters in sediment_lattec.in. We are going to specify only one non-cohesive sediment class.<div class="box"> NEWLAYER_THICK == 0.01d0<br>...<br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br>! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br>! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br>SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div><br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3671 CSTMS UNSW2008 2009-04-08T17:56:46Z

<p>Csherwood: /* Make an init file (Run03) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the .h file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the .in file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ../out.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[ChangeTcline]Changing netCDF variables]<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application.<div class="box">cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in</div><br /> * Change some of the parameters in sediment_lattec.in. We are going to specify only one non-cohesive sediment class.<div class="box"> NEWLAYER_THICK == 0.01d0<br>...<br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br><br /> ! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br><br /> ! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br> SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div><br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3670 CSTMS UNSW2008 2009-04-08T17:56:04Z

<p>Csherwood: /* Make an init file (Run03) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the .h file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the .in file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ../out.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[ChangeTcline]Changing netCDF variables]<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> * Copy the .h and .in files from Run01 to a directory called ../Latte/Run03<br /> * Edit the .h file to activate sediment and the SSW version of the bottom boundary layer calculations.<div class="box">/* stuff needed for sediment */<br>#define SSW_BBL /* Sherwood et al. BBL closure */<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Computing bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div><br /> * Copy a sediment.in file from an example application.<br /> cp ~/src/ROMS/External/sediment_sed_test1.in ./Run03/sediment_lattec.in<br /> * Change some of the parameters in sediment_lattec.in. We are going to specify only one non-cohesive sediment class.<div class="box"> NEWLAYER_THICK == 0.01d0<br>...<br>!------------------------------------------------------------------------------<br>! Non-cohesive Sediment Parameters, [1:NNS,1:Ngrids] values expected.<br>!------------------------------------------------------------------------------<br><br>! Median sediment grain diameter (mm).<br><br> SAND_SD50 == .150d0<br><br>!Sediment concentration (kg/m3).<br><br> SAND_CSED == 0.0d0<br><br>! Sediment grain density (kg/m3).<br><br> SAND_SRHO == 2650.0d0<br><br><br /> ! Particle settling velocity (mm/s).<br><br> SAND_WSED == .20d0<br><br>! Surface erosion rate (kg/m2/s).<br><br> SAND_ERATE == 5.0d-4<br><br><br /> ! Critical shear for erosion and deposition (N/m2).<br><br> SAND_TAU_CE == 0.1d0<br> SAND_TAU_CD == 0.1d0<br><br>! Porosity (nondimensional: 0.0-1.0): Vwater/(Vwater+Vsed).<br><br> SAND_POROS == 0.5d0<br></div><br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3669 CSTMS UNSW2008 2009-04-08T17:00:47Z

<p>Csherwood: /* Simplest possible case (Run 02) */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the .h file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the .in file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ../out.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[ChangeTcline]Changing netCDF variables]<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps. For now, skip to Run 03 and when this is working correctly, we'll describe it here.<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3668 CSTMS UNSW2008 2009-04-08T16:14:34Z

<p>Csherwood: /* Build and run the Latte example */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you can either #UNDEF STATIONS in the .h file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the .in file to point to a valid stations file. Unless you change the path of the output file, it will be end up in stations.nc in the run directory, while other output goes to ../out.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[ChangeTcline]Changing netCDF variables]<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3667 CSTMS UNSW2008 2009-04-07T19:27:54Z

<p>Csherwood: /* Build and run the Latte example */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> ** If you get a complaint about a missing ''stations'' file, you ca either #UNDEF STATIONS in the .h file (and rebuild), or copy a valid stations file to the local (Run01) directory, or change the filename mentioned in the .in file to point to a valid stations file.<br /> ** If you get an error that T_cline or S_cline don't match the input file, follow the instructions here [[ChangeTcline]Changing netCDF variables]<br /> <br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3666 CSTMS UNSW2008 2009-04-07T18:20:29Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Build and run the Latte example==<br /> * Copy of the original .h and .in files into the ../Latte/Run01 directory.<br /> * Try to build and run the Latte case.<br /> ** If you can use the '''build.bash''' script, set the correct entries for environment variables:<div class="box">ROMS_APPLICATION=LATTE_C causes build.bash to look for the file latte_c.h in order to set the CPP options<br>MY_PROJECT_DIR=${HOME}/Projects/latte_c will instruct build.bash where to look for the latte_c.h file.</div><br /> ** No one has figured out how to use build.bash with the Intel (ifort) compiler under Cygwin on a Windows machine. If this is your set up, then edit the makefile in the src directory so that it finds and builds the application.<div class="box">ROMS_APPLICATION ?= LATTE_C<br>MY_HEADER_DIR ?= /cygdrive/d/crs/proj/CSTMS_Tutorial/Latte/run01</div><br /> **<br /> ==Change the advection scheme (Run01)==<br /> * You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> * Modify the .h file <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3665 CSTMS UNSW2008 2009-04-07T17:40:42Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Set up and test the LATTE case==<br /> These instructions differ a little from the Monday tutorial because we assume you are working on your own computer.<br /> * If you have not already done so, check out a version of the code. We'll assume you keep it in a directory called ~/src. If you want to get the ''exact'' version used in this tutorial, then cd to the parent directory for your source code and then:<br /> <div class="box">mkdir src<br>svn checkout -r 342 --username bruce https://www.myroms.org/svn/src/trunk src</div><br /> replacing '''bruce''' with your ROMS user name. Omitting the '''-r 342''' will get you the most current (HEAD) version of the code.<br /> <br /> * Make sure you can compile and run UPWELLING.<br /> <br /> * Make a directory structure that looks like this:<br /> <div class="box">../Latte<br>../Latte/original<br>../Latte/in<br>../Latte/out<br>../Latte/run01<br></div><br /> We will add a few more directories later. Files for this case are at http://coast-enviro.er.usgs.gov/models/Latte/. Use your browser to copy the contents of '''original''' and '''in'''.<br /> <br /> ==Copy the Latte case to your local directory==<br /> For this tutorial, we will work with a directory structure that looks like:<br /> <br /> ./Lattec<br>./Latte/in<br>./Latte/out<br>./Latte/run01<br /> etc for additional cases.<br /> <br /> ==Change the advection scheme (Run01)==<br /> Start with a copy of the .h and .in files.<br /> <div class="box">Latte/run01/latte_c.h run02<br>Latte/run01/ocean_lattec.in</div><br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3664 CSTMS UNSW2008 2009-04-06T18:10:40Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April 2009, Chris Sherwood presented a tutorial for new ROMS users interested in sediments. The tutorial was held at the Sydney Institute of Marine Sciences as part of the ROMS/TOMS Asia-Pacific Workshop. This tutorial continues using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> ''UNDER CONSTRUCTION'' - I'll post a note on the forum when this provides a consistent, step-by-step approach. Until then, user beware.<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Copy the Latte case to your local directory==<br /> For this tutorial, we will work with a directory structure that looks like:<br /> <br /> <div class="box">./Lattec<br>./Latte/in<br>./Latte/out<br>./Latte/run01<br>./Latte/run02</div><br /> etc for additional cases.<br /> <br /> ==Change the advection scheme (Run01)==<br /> Start with a copy of the .h and .in files.<br /> <div class="box">Latte/run01/latte_c.h run02<br>Latte/run01/ocean_lattec.in</div><br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=sediment_cppdefs.h&diff=3663 sediment cppdefs.h 2009-04-06T18:04:49Z

<p>Csherwood: </p> <hr /> <div><div class="box">/* sediment CPPDEFS */<br>#define SEDIMENT<br>#ifdef SEDIMENT /* Chose one or all of these processes: */<br># define SUSPLOAD<br># undef BEDLOAD_SOULSBY /* or BEDLOAD_MPM */<br># undef SED_MORPH<br>#endif<br>#if defined SEDIMENT || defined SG_BBL || defined MB_BBL || defined SSW_BBL<br># define ANA_SEDIMENT /* sediment initialization from Fortran routine */<br># undef ANA_SEDIMENT /* will require initialziation file */<br>#endif<br>#if defined MB_BBL || defined SG_BBL || defined SSW_BBL /* will need wave input */<br># define ANA_WWAVE /* or provide SWAN input */<br>#endif<br>#define SSW_BBL /* or SG_BBL or MB_BBL */<br>#ifdef SG_BBL<br># define SG_CALC_ZNOT<br># undef SG_LOGINT<br>#endif<br>#ifdef MB_BBL<br># define MB_CALC_ZNOT<br># undef MB_Z0BIO<br># undef MB_Z0BL<br># undef MB_Z0RIP<br>#endif<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Compute bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br>#endif</div></div>

Csherwood https://www.myroms.org/wiki/index.php?title=sediment_cppdefs.h&diff=3662 sediment cppdefs.h 2009-04-06T18:04:09Z

<p>Csherwood: </p> <hr /> <div><div class="box">/* sediment CPPDEFS */<br>#define SEDIMENT<br>#ifdef SEDIMENT /* Chose one or all of these processes: */<br># define SUSPLOAD<br># undef BEDLOAD_SOULSBY /* or BEDLOAD_MPM */<br># undef SED_MORPH<br>#endif<br>#if defined SEDIMENT || defined SG_BBL || defined MB_BBL || defined SSW_BBL<br># define ANA_SEDIMENT /* sediment initialization from Fortran routine */<br># undef ANA_SEDIMENT /* will require initialziation file */<br>#endif<br>#if defined MB_BBL || defined SG_BBL || defined SSW_BBL /* will need wave input */<br># define ANA_WWAVE /* or provide SWAN input */<br>#endif<br>#define SSW_BBL /* or SG_BBL or MB_BBL */<br>#ifdef SG_BBL<br># define SG_CALC_ZNOT<br># undef SG_LOGINT<br>#endif<br>#ifdef MB_BBL<br># define MB_CALC_ZNOT<br># undef MB_Z0BIO<br># undef MB_Z0BL<br># undef MB_Z0RIP<br>#endif<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Compute bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br># endif</div></div>

Csherwood https://www.myroms.org/wiki/index.php?title=sediment_cppdefs.h&diff=3661 sediment cppdefs.h 2009-04-06T18:03:06Z

<p>Csherwood: New page: <div class="box">/* sediment CPPDEFS */<br>#define SEDIMENT<br>#ifdef SEDIMENT /* Chose one or all of these processes: */<br># define SUSPLOAD<br># undef BEDLOAD_SOULSBY /* or BEDLOAD_MPM...</p> <hr /> <div><div class="box">/* sediment CPPDEFS */<br>#define SEDIMENT<br>#ifdef SEDIMENT /* Chose one or all of these processes: */<br># define SUSPLOAD<br># undef BEDLOAD_SOULSBY /* or BEDLOAD_MPM */<br># undef SED_MORPH<br>#endif<br>#if defined SEDIMENT || defined SG_BBL || defined MB_BBL || defined SSW_BBL<br># define ANA_SEDIMENT /* sediment initialization from Fortran routine */<br># undef ANA_SEDIMENT /* will require initialziation file */<br>#endif<br>#if defined MB_BBL || defined SG_BBL || defined SSW_BBL /* will need wave input */<br># define ANA_WWAVE /* or provide SWAN input */<br>#endif<br>#define SSW_BBL /* or SG_BBL or MB_BBL */<br>#ifdef SG_BBL<br># define SG_CALC_ZNOT<br># undef SG_LOGINT<br>#endif<br>#ifdef MB_BBL<br># define MB_CALC_ZNOT<br># undef MB_Z0BIO<br># undef MB_Z0BL<br># undef MB_Z0RIP<br>#endif<br>#ifdef SSW_BBL<br># define SSW_CALC_ZNOT /* Compute bottom roughness internally */<br># undef SSW_LOGINT /* Logarithmic interpolation of (Ur,Vr) */<br># define SSW_CALC_UB /* Computing bottom orbital velocity internally */<br># undef SSW_FORM_DRAG_COR /* Activate form drag coefficient */<br># undef SSW_ZOBIO /* Biogenic bedform roughness from ripples */<br># undef SSW_ZOBL /* Bedload roughness for ripples */<br># undef SSW_ZORIP /* Bedform roughness from ripples */<br><br /> # endif</div></div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3660 CSTMS UNSW2008 2009-04-06T17:54:56Z

<p>Csherwood: /* External differences */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Copy the Latte case to your local directory==<br /> For this tutorial, we will work with a directory structure that looks like:<br /> <br /> <div class="box">./Lattec<br>./Latte/in<br>./Latte/out<br>./Latte/run01<br>./Latte/run02</div><br /> etc for additional cases.<br /> <br /> ==Change the advection scheme (Run01)==<br /> Start with a copy of the .h and .in files.<br /> <div class="box">Latte/run01/latte_c.h run02<br>Latte/run01/ocean_lattec.in</div><br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file. A summary of sediment-related cppdefs is listed in [[sediment_cppdefs.h]]<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> <br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3659 CSTMS UNSW2008 2009-04-06T17:51:39Z

<p>Csherwood: /* Why so boring? Its the waves! */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Copy the Latte case to your local directory==<br /> For this tutorial, we will work with a directory structure that looks like:<br /> <br /> <div class="box">./Lattec<br>./Latte/in<br>./Latte/out<br>./Latte/run01<br>./Latte/run02</div><br /> etc for additional cases.<br /> <br /> ==Change the advection scheme (Run01)==<br /> Start with a copy of the .h and .in files.<br /> <div class="box">Latte/run01/latte_c.h run02<br>Latte/run01/ocean_lattec.in</div><br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> In most coastal sediment-transport applications, waves are critical. Waves are often responsible for mobilizing sediment when tidal or wind-generated currents are too weak...but currents are needed to mix sediment out of the wave boundary layer and transport it. Sometimes a time series of wave input is available, and can be passed to ROMS directly as a forcing file. To make use of the wave input, one of the three available wave-current bottom boundary layer routines must be enabled. These are [[SSW_BBL]], [[MB_BBL]], and [[SG_BBL]] (see https://www.myroms.org/wiki/index.php/Sediment_Model#Bottom_Stress).<br /> <br /> Wave input can be as simple as a single time series of wave height, period, and direction that applies to the whole model domain (handy for test cases and simplified models), or as complicated as calculated near-bottom orbital velocities and associated periods and directions that vary with time and space.<br /> In the first instance, the near bottom wave-orbital velocities are calculated from ''H_s'' and ''T'' using linear wave theory, using #define SSW_CALC_UB<br /> <br /> Note that the linear wave calculations made using #define SSW_CALC_UB are seldom exactly correct (see, for example, Soulsby, 1997). A better representation of near-bottom wave-orbital velocities can be made from measured wave spectra, or from Hs and T with a parameterized spectra. Both methods are discussed, and Matlab procedure are provided by Wiberg and Sherwood (2008). These orbital velocities are e<br /> <br /> ==Make and use a simple wave forcing file (Run04)==<br /> In this section, we will use buoy data to make a simple wave forcing file.<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3658 CSTMS UNSW2008 2009-04-06T17:23:43Z

<p>Csherwood: /* Why so boring? */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Copy the Latte case to your local directory==<br /> For this tutorial, we will work with a directory structure that looks like:<br /> <br /> <div class="box">./Lattec<br>./Latte/in<br>./Latte/out<br>./Latte/run01<br>./Latte/run02</div><br /> etc for additional cases.<br /> <br /> ==Change the advection scheme (Run01)==<br /> Start with a copy of the .h and .in files.<br /> <div class="box">Latte/run01/latte_c.h run02<br>Latte/run01/ocean_lattec.in</div><br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Make an init file (Run03)==<br /> <br /> ===Why so boring? Its the waves!===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3657 CSTMS UNSW2008 2009-04-06T17:21:45Z

<p>Csherwood: /* Change the advection scheme */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Copy the Latte case to your local directory==<br /> For this tutorial, we will work with a directory structure that looks like:<br /> <br /> <div class="box">./Lattec<br>./Latte/in<br>./Latte/out<br>./Latte/run01<br>./Latte/run02</div><br /> etc for additional cases.<br /> <br /> ==Change the advection scheme (Run01)==<br /> Start with a copy of the .h and .in files.<br /> <div class="box">Latte/run01/latte_c.h run02<br>Latte/run01/ocean_lattec.in</div><br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. This will be the only change, so recompile and make sure it works again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3656 CSTMS UNSW2008 2009-04-06T16:48:01Z

<p>Csherwood: /* A case study in troubleshooting */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Change the advection scheme==<br /> <br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. It is a good idea to recompile and test again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==Simplest possible case (Run 02)==<br /> It should be possible to turn sediment on by making the following simple changes. However, this did not work for the Latte case, and you will have take the additional steps (see Run 03).<br /> <br /> In the latte_c.h file:<br /> <div class="box">#define TS_MPDATA<br>#define sediment<br>#define ana_sediment</div><br /> <br /> In the ocean_lattec.in file:<br /> <div class="box"> NNS = 1 ! Number of non-cohesive (sand) sediment tracers<br>...<br> SPARNAM = ./sediment_lattec.in</div><br /> <br /> The best way to get a template for the sediment input file is to copy one from the source code to your local directory.<br /> <div class="box">cp ~/yoursourcedir/ROMS/External/sediment_sed_test1.in ./run02/sediment_lattec.in</div><br /> then edit to suit.<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3655 CSTMS UNSW2008 2009-04-06T15:50:36Z

<p>Csherwood: /* Turn on sediment */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Change the advection scheme==<br /> <br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. It is a good idea to recompile and test again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> == Turn on sediment ==<br /> What is different about sediment?<br /> === External differences ===<br /> The external differences are required changes in user input and output. They include:<br /> * Switches in .h file<br /> * Changes in .in file<br /> * Need sediment.in file<br /> * Need to modify (a copy of) ana_sediment.F<br /> * New output in his.nc file<br /> <br /> Many applications also need<br /> * More info in init.nc file (initial bed)<br /> * Wave input<br /> * River sediment input<br /> * Boundary conditions<br /> === Internal differences ===<br /> Components of the sediment model include:<br /> * TS_MPDATA – Positive-definite advection scheme<br /> * Wave model (as input via a forcing file, or directly coupled)<br /> * Wave-current combined bottom stresses<br /> * Erosion / deposition / bed model (sand)<br /> * Settling<br /> * Bedload transport and flux divergence<br /> * Morphological evolution<br /> * Wetting and drying<br /> * Cohesive and mixed sediments<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3654 CSTMS UNSW2008 2009-04-06T15:39:00Z

<p>Csherwood: /* Change the advection scheme */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Change the advection scheme==<br /> <br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?). [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection switches. It is a good idea to recompile and test again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3653 CSTMS UNSW2008 2009-04-06T15:36:54Z

<p>Csherwood: /* Change the advection scheme */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Change the advection scheme==<br /> <br /> You need to use a "positive-definite" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?. [[TS_MPDATA]] is a Multidimensional Positive Definite Advection Transport Algorithm method based on the work of[[Bibliography#Smolark | Piotr Smolarkiewicz]]. See the [[https://www.myroms.org/wiki/index.php/cppdefs.h#Options_associated_with_momentum_equations]wiki discussion.] <br /> <br /> Anyway, make sure you <br /> <div class="box"><span class="red">#define TS_MPDATA</span></div><br /> and<br /> <div class="box"><span class="red">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</span></div><br /> (or remove) any other horizontal advection swithches.<br /> <br /> It is a good idea to recompile and test again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3652 CSTMS UNSW2008 2009-04-06T14:51:19Z

<p>Csherwood: /* Change the advection scheme */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Change the advection scheme==<br /> <br /> You need to use a "positive-definate" advection scheme with sediment. The small over- and undershoots that occur with many advection algorithms will cause mass-conservation problems with sediment. (What, for example, is deposition of negative sediment concentrations? Erosion?)<br /> <br /> Anyway, make sure you <br /> <div class="box">#define MP_DATA</div><br /> and<br /> <div class="box">#undef TS_U3HADVECTION<br>#undef TS_SVADVECTION</div><br /> (or remove) any other horizontal advection swithches.<br /> <br /> It is a good idea to recompile and test again after this small change...if something goes awry, it is good not to have accumulated lots of changes.<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=Tutorials&diff=3649 Tutorials 2009-04-01T00:21:28Z

<p>Csherwood: /* Sediment Tutorials */</p> <hr /> <div><div class="title">ROMS Tutorials</div><br /> <br /> This page is for tutorials on using ROMS and other related software. If you create a tutorial please create a link to that tutorial in the list below.<br /> <br /> ==Installing ROMS==<br /> :*[[ROMS_Cygwin|Installing ROMS in Windows XP/Vista (via Cygwin)]]<br /> :*[[ROMS_UNSW2008|Installing and Running ROMS for First Time Users. Tutorial at UNSW Computer Labs, 30 March 2009]]<br /> <br /> ==Sediment Tutorials==<br /> :*[[CSTMS_UNSW2008|Adding sediment to the Latte example. Tutorial at Sydney Institute of Marine Sciences, 3 April 2009]]<br /> <br /> ==Utilities and Tools==<br /> :*[[MEXNC|For Matlab users: Installing MEXNC, SNCTOOLS and ROMS-Matlab-toolkit]]<br /> :*[[Plotting_Package_Installation|Installing and Using the ROMS/TOMS Plotting Package]]<br /> <br /> ==Grid Generation Tutorials==</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3648 CSTMS UNSW2008 2009-03-26T14:22:39Z

<p>Csherwood: /* Test the LATTE case */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> Make sure you can run the examples discussed in the Monday tutorial.<br /> <br /> Input files are at http://coast-enviro.er.usgs.gov/models/Latte/in<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3636 CSTMS UNSW2008 2009-03-25T02:10:09Z

<p>Csherwood: /* SWAN - A Digression */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> Getting SWAN set up correctly is easier if you do it separately. For many applications, one-way coupling (SWAN influences ROMS, but ROMS does not feed back to SWAN) captures the essential physics. So, before we couple ROMS and SWAN, we'll run SWAN indepedently. This effort won't be wasted because 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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>We can translate the frc_latte_wrf_Uwind.nc and frc_latte_wrf_Vwind.nc files to SWAN input using create_swan_wind.m. The resulting 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3635 CSTMS UNSW2008 2009-03-25T01:29:28Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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><br /> 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 <br /> file looks like this.<br /> <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>where the first indice is time step (1...nt), the second is x-direction (1...ni) and the third is y-direction (1...nj).<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3634 CSTMS UNSW2008 2009-03-25T01:24:22Z

<p>Csherwood: /* SWAN - A Digression */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> 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<br /> <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><br /> 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 <br /> file looks like this.<br /> <div class="box"><br /> u(1,1,1) u(1,1,2) ... u(1,1,nj)<br><br /> u(1,2,1) u(1,2,2) ... u(1,2,nj)<br><br /> ...<br><br /> u(1,ni,1) u(1,ni,2)... u(1,ni,nj)<br><br /> v(1,1,1) v(1,1,2) ... v(1,1,nj)<br><br /> v(1,2,1) v(1,2,2) ... v(1,2,nj)<br><br /> ...<br><br /> v(1,ni,1) v(1,ni,2)... v(1,ni,nj)<br><br /> u(1,1,1) u(1,1,2) ... u(1,1,nj)<br><br /> u(1,2,1) u(1,2,2) ... u(1,2,nj)<br><br /> ...<br><br /> u(1,ni,1) u(1,ni,2)... u(1,ni,nj)<br><br /> v(2,1,1) v(2,1,2) ... v(2,1,nj)<br><br /> v(2,2,1) v(2,2,2) ... v(2,2,nj)<br><br /> ...<br><br /> v(2,ni,1) v(2,ni,2)... v(2,ni,nj)<br><br /> ...etc<br /> </div><br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3621 CSTMS UNSW2008 2009-03-24T11:04:53Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> ''However'', when COORDINATES SPHERICAL is specified and winds are supplied in files using commands like<br /> <div class="box">INPGRID WIND CURVILINEAR 0 0 145 81 EXC 9.999000e+003<br>READINP WIND 1 SERIES './lattec_swan_wind_fnames.txt' 4 0 FREE</div><br /> the ''u-'' and ''v-'' components are aligned with the ''x-'' and ''y-''axes of the SWAN grid. ''But the angles are in math convention, CCW from the SWAN x-direction.''<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3618 CSTMS UNSW2008 2009-03-24T02:51:41Z

<p>Csherwood: /* SWAN - A Digression */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> ''However'', when COORDINATES SPHERICAL is specified and winds are supplied in files using commands like<br /> <div class="box">INPGRID WIND CURVILINEAR 0 0 145 81 EXC 9.999000e+003<br>READINP WIND 1 SERIES './lattec_swan_wind_fnames.txt' 4 0 FREE</div><br /> the ''u-'' and ''v-'' components are aligned with the ''x-'' and ''y-''axes of the SWAN grid.<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3617 CSTMS UNSW2008 2009-03-24T02:48:16Z

<p>Csherwood: /* SWAN - A Digression */</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> 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.<br /> <br /> Directions in SWAN can be tricky. For our purposes, we will use these commands in the INPUT file:<br /> <div class="box">SET NAUTICAL<br>COORDINATES SPHERICAL<br>CGRID CURVILINEAR 145 81 EXC 9.999000e+003 &<br>CIRCLE 36 0.0418 1.0 24<br>READGRID COORDINATES 1 './lattec_swan.grd' 4 0 0 FREE </div><br /> 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<br /> <div class="box">WIND 5 225</div>SWAN output in .mat files should be interpreted this way as well.<br /> ''However'', when COORDINATES SPHERICAL is specified and winds are supplied in files using commands like<br /> <div class="box">INPGRID WIND CURVILINEAR 0 0 145 81 EXC 9.999000e+003<br>READINP WIND 1 SERIES './lattec_swan_wind_fnames.txt' 4 0 FREE <br /> </div><br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3616 CSTMS UNSW2008 2009-03-23T18:12:11Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101: Its the waves!===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3615 CSTMS UNSW2008 2009-03-23T18:05:18Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''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 [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101 Its the waves===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=ROMS_UNSW2008&diff=3614 ROMS UNSW2008 2009-03-23T18:03:43Z

<p>Csherwood: </p> <hr /> <div><div class="title">Installing and Running ROMS for First Time Users</div><br /> <br /> '''A tutorial for new ROMS users will be held at the UNSW Computer Labs on Monday 30 March 2009, immediately prior to the ROMS Sydney 2009 User Workshop at the Sydney Institute of Marine Sciences, 31 March to 2 April 2009.'''<br /> <br /> {{note}}''<span class="blue">This tutorial is intended for complete newcomers to ROMS. It assumes basic knowledge of working in a UNIX environment, and that the essential components required to compile and execute ROMS are already installed on the host computer network. This wiki page borrows heavily from David's Robertson's excellent [[ROMS_Cygwin|Installing ROMS under Cygwin]] tutorial where you will find more information about setting up the required computing environment (compilers, libraries etc.) for ROMS.</span>''<br /> <br /> In this tutorial, we cover how to download the code, configure it for an application, and run the model. Error messages that arise during the configuration process will be explained so that these can better be debugged when users return to their home institutions and try to work through this process again.<br /> <br /> '''A follow-on [[CSTMS_UNSW2008|tutorial discussing sediment in ROMS]] will be presented on Friday 03 April.'''<br /> <br /> {{note}}An important resource you should use as you get started is the [[Frequently_Asked_Questions | Frequently Asked Questions]] entry in [https://www.myroms.org/wiki WikiROMS].<br /> <br /> <br /> __TOC__<br /> <br /> ==Download ROMS==<br /> <br /> The disk space available on the UNSW Computer Lab machines is quite limited, so for the purposes of this tutorial we have downloaded the ROMS source code to '''<span class="red">/srv/ckpt/roms/shared/src</span>''' on host '''<span class="blue">matht001</span>'''. Instructions below will explain how to point the '''<span class="red">build.bash</span>''' script that compiles ROMS to this directory.<br /> <br /> '''To download the code to your own machine, these are the steps you would follow:'''<br /> <br /> :*You must have already registered on the ROMS portal and obtained your ROMS username/password as indicated in the [[ROMS_Cygwin#Register|Register]]. If you are also interested in access to research branches of the sediment code, indicate an interest in the Community Sediment Transport Modeling System (CSTMS) while you are registering. Once your registration is accepted, or if you are already registered, ask Dave Robertson (<span class="twilightBlue">robertson at marine.rutgers.edu</span>) to add you as a CSTMS user.<br /> <br /> :*Create a <span class="red">src</span> folder where you will keep the ROMS source code. You can place this wherever you wish in your directory tree (here we assume under your home directory "<span class="forestGreen">~</span>") and name it whatever you like.<br /> ::<div class="box"><span class="forestGreen">cd ~<br />mkdir src</span></div><br /> <br /> :*Check out the ROMS source code replacing <span class="forestGreen">''bruce''</span> with the ROMS user name you registered with.<br /> ::<div class="box"><span class="forestGreen">svn checkout --username bruce <nowiki>https://www.myroms.org/svn/src/trunk src</nowiki></span></div> Note the target directory <span class="forestGreen">src</span> at the end of the command. If your code ends up in the wrong place, you may have omitted this. <br /> <br /> You will see many lines stream by indicating the files that are being added to your src directory. When it finishes, you can type <span class="forestGreen">ls src</span> to see the contents of the directory. <br /> <br /> To see the contents of the directory where the code is downloaded for this tutorial, type this:<br /> ::<div class="box"><span class="forestGreen">cd /srv/ckpt/roms/shared<br />ls src</span></div><br /> <br /> ==Customize the [[build Script|Build Script]]==<br /> The ROMS source code comes with a [[build Script|build script]] in the <span class="red">ROMS/Bin</span> directory. Examples written with <span class="forestGreen">bash</span> (<span class="red">build.bash</span>) and <span class="forestGreen">csh</span> (<span class="red">build.sh</span>) are provided. The UNSW Computer Lab machines are configured to use <span class="forestGreen">bash</span> as the default login shell, so we will work with <span class="red">build.bash</span>. A full description of the build script can be found [[build Script|here]].<br /> <br /> :*In your home directory (you can use some other directory to organize your ROMS projects if you wish) create a new folder named <span class="red">Projects</span> and change into it.<br /> ::<div class="box"><span class="forestGreen">cd ~<br />mkdir Projects<br />cd Projects</span></div><br /> :*Create a folder named <span class="red">upwelling</span> and change into it. ROMS is distributed with several [[Test Cases|Test Cases]] and the [[UPWELLING_CASE|Upwelling example]] is the default which we will compile and run here. <br /> ::<div class="box"><span class="forestGreen">mkdir upwelling<br />cd upwelling</span></div><br /> <br /> :*Copy the <span class="red">build.bash</span> file distributed with ROMS to your <span class="red">Projects/upwelling</span> directory.<br /> ::<div class="box"><span class="forestGreen">cp /srv/ckpt/roms/shared/src/ROMS/Bin/build.bash .</span></div><br /> <br /> Next we need to configure a few options inside <span class="red">build.bash</span> so that it finds the directories where the source code and your Project are located. <br /> <br /> :*Open the <span class="red">build.bash</span> script you just copied into your <span class="red">upwelling</span> directory using your preferred text editor, e.g. vi.<br /> ::<div class="box"><span class="forestGreen">vi build.bash</span></div><br /> <br /> :*Scroll down until you find <span class="orange">ROMS_APPLICATION</span>. You will notice it is set as follows:<br /> ::<div class="box"> <span class="blue">export</span> <span class="red">ROMS_APPLICATION</span>=UPWELLING</div> We do not need to change this. But this is the first thing you will alter when starting your own project. This tells ROMS the name of an include file that will contain all the directives to the C-PreProcessor to configure your application at compile time. ROMS' rule is change this string to lowercase and append a ".h", so this will search for a file called <span class="red">upwelling.h</span>. It must be in the directory specified by <span class="orange">MY_PROJECT_DIR</span>:<br /> <br /> :*Scroll down until you find <span class="orange">MY_PROJECT_DIR</span> and set it as follows:<br /> ::<div class="box"> <span class="blue">export</span> <span class="red">MY_PROJECT_DIR</span>=${<span class="red">HOME</span>}/Projects/upwelling</div> This obviously assumes you put <span class="red">Projects/upwelling</span> under your home directory.<br /> <br /> If you frequently move your ROMS project between hosts where you have a different directory structure, e.g. a temporary scratch space, you can use the <span class="orange">MY_ROOT_DIR</span> variable to minimize the changes you make to <span class="red">build.bash</span>.<br /> <br /> :*For example: <br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROOT_DIR</span>=/usr/scratch/bruce<br /><span class="blue">export</span> <span class="red">MY_PROJECT_DIR</span>=${<span class="red">MY_ROOT_DIR</span>}/Projects/upwelling</div><br /> <br /> Next we tell <span class="red">build.bash</span> where to find the ROMS source code downloaded from the svn repository (which you can keep up to date the <span class="forestGreen">svn update</span> command - see more on this at LINK ). Note that most of the source code changes you make to customize ROMS will be made in your Projects space, and need not be made to the downloaded code directly. We will discuss exceptions to this during the tutorial, and how source code modifications interact with svn.<br /> <br /> :*Set <span class="orange">MY_ROMS_SRC</span> to the location of the source code:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROMS_SRC</span>=/srv/ckpt/roms/shared/src</div> In practise, you will probably do something more like this:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROMS_SRC</span>=${<span class="red">MY_ROOT_DIR</span>}/src</div> assuming this is the relative path in which you keep your source code on the various machines you work on. <br /> <br /> Make sure that <span class="orange">MY_CPP_FLAGS</span> is '''not''' set. Sometimes this is set in the distributed build.bash exmaple. Comment out options with the # symbol like so:<br /> ::<div class="box"><span class="blue">#export MY_CPP_FLAGS="-DAVERAGES"</span> </div><br /> <br /> The UNSW Computer Lab machines are single core, so we need to tell <span class="red">build.bash</span> not to assume MPI parallel compilation. <br /> <br /> :*Comment out the options for <span class="orange">USE_MPI</span> and <span class="orange">USE_MPIF90</span><br /> ::<div class="box"><span class="blue">#export USE_MPI=on <br>#export USE_MPIF90=on</span> </div><br /> <br /> :*If you were compiling in parallel you would leave the default entries in <span class="red">build.bash</span>. <br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_MPI</span>=<br /><span class="blue">export</span> <span class="red">USE_MPIF90</span>=</div><br /> <br /> :*We leave the compiler option as the default because this says use the <span class="forestGreen">ifort</span> (Intel FORTRAN) compiler which is what we want on the UNSW machines. <br /> ::<div class="box"><span class="blue">export</span> <span class="red">FORT</span>=ifort</div><br /> <br /> :*In the interests of speed for this tutorial, we turn off compiler optimization by activating the debug option: <br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_DEBUG</span>=on</div>On the UNSW Lab machines compiling with optimization on will take over 15 minutes, but with optimization off (USE_DEBUG=on) it will be less than 60 seconds.<br /> <br /> Save and close the <span class="red">build.bash</span> file.<br /> <br /> <br /> ==Copy the input and CPPDEFS options files==<br /> <br /> We need three more files in <span class="red">Projects/upwelling</span> to configure and run ROMS. We copy the versions downloaded with svn because these are files you will work with locally when you experiment with changes to the test case example configuration. <br /> <br /> :*Copy files <span class="red">ocean_upwelling.in, varinfo.dat</span> and <span class="red">upwelling.h</span> into the <span class="red">Projects/upwelling</span> directory you just created.<br /> <br /> ::<div class="box"><span class="forestGreen">cd ~/Projects/upwelling<br />cp /srv/ckpt/roms/shared/src/ROMS/External/ocean_upwelling.in . <br>cp /srv/ckpt/roms/shared/src/ROMS/External/varinfo.dat . <br>cp /srv/ckpt/roms/shared/src/ROMS/Include/upwelling.h .</span></div><br /> <br /> View the file <span class="red">upwelling.h</span>. It contains all the [[C_Preprocessor|C-Pre-Processor (CPP)]] options that the compiler interprets to activate certain source code options within ROMS.<br /> <br /> View the file <span class="red">ocean_upwelling.in</span>. It contains the inputs options that ROMS [[ocean.in|reads from standard input]] at run time to set options that need not be fixed at compile time. <br /> <br /> View <span class="red">varinfo.dat</span>. The file [[varinfo.dat]] contains descriptions of the names and attributes of input and output variables that ROMS reads and writes from netcdf files. For most applications you will not need to change the entries in this file. If you need to know the default units assumed for different variables, those are noted in this file. (Before we run ROMS, we will need to tell it where to find this file). <br /> <br /> Now we are ready to compile ROMS by executing the <span class="red">build.bash</span> script.<br /> <br /> ==Compile ROMS==<br /> <br /> Before you run ROMS, you need to compile it to create an executable <span class="red">oceanS</span> file ('''S''' for serial or single processor computer), or <span class="red">oceanM</span> file (if using '''MPI''' on a parallel computer).<br /> <br /> :*Go to your upwelling project directory:<br /> ::<div class="box"><span class="forestGreen">cd ~/Projects/upwelling</span></div><br /> <br /> :*Then type:<br /> ::<div class="box"><span class="forestGreen">./build.bash</span></div><br /> <br /> :*If lots of stuff comes on the screen then compilation is proceeding, and make take some time. <br /> <br /> :*If the build process ends quickly with an error, then it is likely that <span class="red">build.bash</span> does not point to the correct location for the <span class="red">upwelling.h</span> file, the FORTRAN compiler, or some libraries. We describe common ''getting started'' errors and solutions in the next section. <br /> <br /> :*You may give the option <span class="forestGreen">-j</span> to the build command to distribute the compilation to multiple processors if your host supports this, e.g.:<br /> ::<div class="box"><span class="forestGreen">./build.bash -j 8</span></div> to compile on 8 processor at once. <br /> <br /> If your build was successful it will not have reported any errors, and there will be an executable file in your <span class="red">Projects/upwelling</span> directory called <span class="forestGreen">oceanG</span>. The <span class="forestGreen">"G"</span> in the file name indicates <span class="red">build.bash</span> activated the <span class="blue">USE_DEBUG</span> option. <br /> <br /> If <span class="blue">USE_DEBUG</span> were not selected, the executable would be <span class="forestGreen">oceanS</span>, where the <span class="forestGreen">"S"</span> indicates "serial" or "single-processor" because we deactivated MPI. <br /> <br /> If you had activated MPI with the <span class="blue">USE_MPI</span> option the executable would be named <span class="forestGreen">oceanM</span>.<br /> <br /> (See also [[Frequently_Asked_Questions#My_build_finished_with_no_errors._Where_is_the_ROMS_executable.3F|FAQ: My build finished with no errors, where is the ROMS executable?]]). <br /> <br /> <br /> ===Common ''getting started'' compile error messages===<br /> <br /> Getting past the first few errors with compilation is often tricky. Carefully read any error messages you get for clues on what might be wrong with your configuration. Here are some common difficulties new users encounter getting started when first executing the <span class="red">build.bash</span> command. <br /> <br /> :*<div class="box">Compilers/../ROMS/Include/cppdefs.h:709:22: <br>error: /student/0/a0000020/Projects/upwelling/upwelling.h: No such file or directory</div> This says the file <span class="red">upwelling.h</span> is not where Build expects it to be, which is in <span class="orange">MY_PROJECT_DIR</span>. You set this to <span class="red">~/Projects/upwelling</span>.<br /> <br /> :*<div class="box">cp: cannot stat `/opt/intelsoft/netcdf/include/netcdf.mod': No such file or directory</div> This says that netcdf is not where build.bash expects to find it. Locate where the netcdf include and lib directories with steps something like:<div class="box"><span class="forestGreen">cd /usr <br>find . -name netcdf.mod -print<br></span> ./local/netcdf-3.6.2/include/netcdf.mod <br> ./local/netcdf/intel/3.6.3/include/netcdf.mod</div>This tells us the most recent (3.6.3) netcdf is in <span class="red">/usr/local/netcdf/intel/3.6.3</span>. Direct ROMS to this location by making two changes to <span class="red">build.bash</span>. First, advise ROMS to read your changes to the default library path by uncommenting the option for <span class="orange">USE_MY_LIBS</span>.<br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_MY_LIBS</span>=on</div> Then specifiy the correct location for netcdf:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">NETCDF_INCDIR</span>=/usr/local/netcdf/intel/3.6.3/include<br /><span class="blue">export</span> <span class="red">NETCDF_LIBDIR</span>=/usr/local/netcdf/intel/3.6.3/lib</div> {{warning}} Be careful where you make this change. You need to make it for the <span class="forestGreen">ifort</span> compiler option, and NOT for the <span class="orange">USE_NETCDF4</span> option (we are using netcdf-3). If you've done this correctly, your compilation with <span class="red">build.bash</span> should now succeed.<br /> <br /> :*<div class="box">error <br>error: </div> Note here further errors we encounter during the tutorial.<br /> <br /> <br /> ==Run ROMS==<br /> <br /> You run ROMS by executing the <span class="forestGreen">oceanG</span> (or <span class="forestGreen">oceanS</span>) binary, giving it the <span class="red">ocean_upwelling.in</span> file as UNIX standard input. <br /> ::<div class="box"><span class="forestGreen">./oceanS < ocean_upwelling.in</span></div> ROMS standard output will be typed to the screen. To save it a file instead, enter, e.g.:<br /> ::<div class="box"><span class="forestGreen">./oceanS < ocean_upwelling.in > my_upwelling.log </span></div><br /> <br /> If you have compiled a parallel (MPI) executable, the syntax for running the mode is slightly '''but critically''' different. The <span class="red">ocean_upwelling.in</span> file is no longer read from UNIX standard input (it has handled by all the MPI threads) so the <span class="forestGreen">"<"</span> disappears from the command, and you need the correct syntax on your UNIX host for running an MPI process. It is probably something like: <br /> ::<div class="box"><span class="forestGreen">mpirun -np 8 ./oceanM ocean_upwelling.in > my_upwelling.log</span></div> where the <span class="forestGreen">"-np 8"</span> indicates use 8 processors and this number of tiles must have been set by <br /> <br /> (See also [[Frequently_Asked_Questions#What_do_I_have_to_do_to_run_an_application.3F | FAQ: What do I have to do to runs ROMS?]]).<br /> <br /> <br /> ===Common ''getting started'' run error messages===<br /> <br /> ::<div class="box">bash: oceanG: command not found</div>The working directory is not in your UNIX path. That's why we type "dot-slash" in front of the commands above.<br /> <br /> <br /> ==Successful execution==<br /> <br /> ===Standard Output===<br /> <br /> When ROMS runs it will type a lot of information to UNIX standard output. This is the "logfile" you named following the ">", or your terminal if you did not redirect stdout. <br /> <br /> STDOUT shows the following:<br /> <br /> :*UNIX process info, run time, run TITLE <br /> ::<div class="box"> Process Information: <br> Thread # 0 (pid= 4449) is active. <br> Model Input Parameters: ROMS/TOMS version 3.2 <br> Monday - March 23, 2009 - 10:02:39 AM <br>----------------------------------------------------------- <br> Wind-Driven Upwelling/Downwelling over a Periodic Channel</div><br /> <br /> :*OS, compiler information, SVN version, and your MY_ROMS_SRC, MY_HEADER_DIR and ROMS_APPLICATION settings<br /> ::<div class="box">Operating system : Linux<br>CPU/hardware : i686<br>Compiler system : ifort <br>Compiler command : /usr/local/intel/fc/10.1.021/bin/ifort <br>Compiler flags : -heap-arrays -ip -O3 -pc80 -xW -free<br><br>SVN Root URL : <nowiki>https://www.myroms.org/svn/src/trunk</nowiki><br>SVN Revision : 333<br>Local Root : /srv/ckpt/roms/shared/src<br>Header Dir : /student/0/a0000020/srv/Projects/upwelling<br>Header file : upwelling.h<br>Analytical Dir: /student/0/a0000020/srv/Projects/upwelling<br><br>Resolution, Grid 01: 0041x0080x016, Parallel Threads: 1, Tiling: 001x001</div>Check that these are what you intended. In last line above<br /> ::*"Grid 01" pertains to future ROMS developments with multiple nested/connected grids, <br /> ::* 0041x0080x016 shows the grid size is 41 x 80 x 16 grid points in the K,J,I directions<br /> ::* The Parallel/Tiling message shows you are using a single process and a single domain tile. When using MPI, this message will describe how many tiles you are using and the MPI processes assigned. <br /> <br /> :*Input parameters set in <span class="red">ocean_upwelling.in</span><br /> ::<div class="box">Physical Parameters, Grid: 01<br>=============================<br><br> 288 ntimes Number of timesteps for 3-D equations.<br> 300.000 dt Timestep size (s) for 3-D equations.<br> 30 ndtfast Number of timesteps for 2-D equations between<br> each 3D timestep.<br> ...<br> Output Averages File: ocean_avg.nc<br> Output Diagnostics File: ocean_dia.nc</div><br /> <br /> :*Then some more about the tiling when running in parallel<br /> <br /> :*The C-PreProcessor (CPP) flags set in <span class="red">upwelling.h</span> but '''AS MODIFIED''' by ROMS when interpreting and checking the selected CPP options. <br /> ::<div class="box"> Activated C-preprocessing Options:<br><br> UPWELLING Wind-Driven Upwelling/Downwelling over a Periodic Channel<br> ANA_BSFLUX Analytical kinematic bottom salinity flux.<br> ANA_BTFLUX Analytical kinematic bottom temperature flux.<br> ANA_GRID Analytical grid set-up.<br> ANA_INITIAL Analytical initial conditions.<br> ...</div>You should check that the CPP options displayed here agree with what you intended. For example, if you inadvertently specify more than one horizontal advection scheme option, ROMS will have chosen only one and reported that option here.<br /> <br /> :*The preamble in STDOUT continues with information about the space and time discretization: grid spacing, grid volume, Courant number (time step stability) and stiffness (related to s-coordinate accuracy).<br /> <br /> :*Then the model starts time stepping:<br /> ::<div class="box">NL ROMS/TOMS: started time-stepping: (Grid: 01 TimeSteps: 00000001 - 00000288)<br><br> STEP Day HH:MM:SS KINETIC_ENRG POTEN_ENRG TOTAL_ENRG NET_VOLUME<br><br> 0 0 00:00:00 0.000000E+00 6.579497E+02 6.579497E+02 3.884376E+11<br> DEF_HIS - creating history file: ocean_his.nc<br> WRT_HIS - wrote history fields (Index=1,1) into time record = 000000<br> DEF_AVG - creating average file: ocean_avg.nc<br> DEF_DIAGS - creating diagnostics file: ocean_dia.nc<br> 1 0 00:05:00 3.268255E-13 6.579497E+02 6.579497E+02 3.884376E+11<br> 2 0 00:10:00 6.503587E-12 6.579497E+02 6.579497E+02 3.884376E+11<br> 3 0 00:15:00 4.592307E-11 6.579497E+02 6.579497E+02 3.884376E+11<br><br> ...</div>This output indicates several things:<br /> ::*the run is programmed to run from time step 1 to 288<br /> ::*the run starts at time 00:00:0<br /> ::*netcdf output HISTORY, AVERAGES and DIAGNOSTICS files are created. Every time ROMS creates a new netcdf file, and writes to an existing file, it reports this to STDOUT<br /> ::*output is written to the HISTORY file<br /> ::*then global quantities related to the model KE, PE and domain volume are reported on each time step<br /> <br /> {{note}} In 99% of situations, ''getting started'' problems with model set-up and configuration can be diagnosed by carefully reading the STDOUT above. Things to look for are:<br /> :*misconfigured CPP options (what you got is not what you thought you asked for)<br /> :*parameter errors (e.g. you activated horizontal mixing but left the coefficient as zero)<br /> :*misnamed output files (that's why the files from your last run got overwritten)<br /> :*irrational choices of grid spacing or time step <br /> :*initial/boundary/forcing data being read from the wrong file, or not read at all (because you selected analytical conditions)<br /> <br /> At the conclusion of the run, ROMS reports information about run time:<br /> ::<div class="box"> Elapsed CPU time (seconds):<br><br> Thread # 0 CPU: 108.079<br> Total: 108.079<br><br>Nonlinear model elapsed time profile:<br><br> Initialization ................................... 0.016 ( 0.0148 %)<br> Processing of input data ......................... 0.028 ( 0.0259 %)<br> Processing of output time averaged data .......... 4.312 ( 3.9899 %)<br> ... </div><br /> :*about the number of output records written to each file<br /> ::<div class="box"> ROMS/TOMS - Output NetCDF summary for Grid 01: <br> number of time records written in HISTORY file = 00000005 <br> ...</div><br /> :*and the analytical files included <br /> ::<div class="box"> Analytical header files used:<br><br> ROMS/Functionals/ana_btflux.h<br> ROMS/Functionals/ana_grid.h<br> ...</div>If you used a modified analytical file in your <span class="orange">MY_HEADER_DIR</span> it will be reported here and is another thing you should check for consistency with your intentions.<br /> <br /> <br /> ===Netcdf file output===<br /> <br /> As reported above, ROMS created 4 output netcdf files when it ran. There are ocean_his.nc, ocean_avg.nc, ocean_dia.nc, and coean_rst.nc. These are, respectively:<br /> :*history records or 'snapshots' of the model state a selected time intervals<br /> :*averages of the model state over selected intervals (not necessarily the same intervals as the history)<br /> :*diagnostics of the model state, the precise contents of which are controlled by CPP options<br /> :*a restart file with everything ROMS needs to restart a application. This is useful if your job crashes at some point and you want to recommence from a previous state without starting over. Typically the restart file is set to keep just 2 time records by continually over-writing the oldest as the run proceeds. This behaviour is controlled in ocean_upwelling.in. Also, when ROMS "blows up" it dumps the ocean state to a 3rd record in the restart file. <br /> <br /> You can browse the contents of netcdf files at the UNIX command line with the command ncdump, e.g. <br /> ::<div class="box"><span class="forestGreen">ncdump -h ocean_his.nc | more</span> </div><br /> Note the use of the <span class="forestGreen">"-h"</span> option. This restricts the output from ncdump to be just the header information, or metadata, in the netcdf file. Without the "-h" option you will get the entire contents of the file converted to ascii. <br /> <br /> Things to notice when you ncdump the ocean_his.nc file are that it contains all the input parameters (time step, mixing coefficients, s-coordinate parameters, etc.) from ocean.in, the model grid coordinates (x, y, lon, lat, depth, Coriolis parameter, etc.) which may have been computed by the ANA_GRID option or read from an input grid netcdf file, in addition to the actual model output (ocean_time, zeta, u, v, temp, salt). <br /> <br /> There are netcdf '''global attributes''' that echo much of the information typed to STDOUT. This includes compiler, svn version, and project directory information, and all the CPP options. This is a valuable source of information when returning to a project and trying to figure out what you did! The global attributes metadata show precisely which options were activated when creating the output in this netcdf file. <br /> <br /> <br /> ==Changing the UPWELLING test case configuration==<br /> <br /> <br /> ===Compile time changes: <span class="red">upwelling.h</span>===<br /> <br /> <br /> <br /> <br /> <br /> <br /> ===Run time changes: <span class="red">ocean_upwelling.in</span>===<br /> <br /> <br /> <br /> <br /> <br /> ==A ''Realistic'' model example: LaTTE==<br /> <br /> This section of the tutorial assumes you have successfully compiled and run the UPWELLING example above. Key concepts you should be comfortable with to proceed are:<br /> :*you need a new directory where you will keep the files specific to the new application<br /> :*customize <span class="red">build.bash</span> for the new application (copy the build.bash from <span class="red">upwelling</span> because it has all the correct compiler and library settings)<br /> :*set <span class="blue">MY_PROJECT_DIR</span> in <span class="red">build.bash</span> to point to the directory for the new application<br /> :*set <span class="blue">ROMS_APPLICATION</span> in <span class="red">build.bash</span> to the correct name for the new application<br /> :*if you wish to customize any of the <span class="forestGreen">ana_*.h</span> files, copy just the ones you need into the new project directory <br /> :*you '''don't''' need to make a copy the source code a new application<br /> <br /> With these concepts in mind, we proceed by configuring ROMS to run a realistic coastal ocean application that includes open boundaries on 3 sides, open boundary tides and climatology velocity and tracer (temperature and salinity) conditions, surface meteorological forcing, and initial conditions, all provided by input netcdf files. The example is called LaTTE_C because it simulates ocean conditions during the '''Lagrangian Transport and Transformation Experiment''' conducted on the New Jersey inner shelf in the Spring of 2006. The '_C' denotes a coarse resolution configuration suitable for this training exercise. <br /> <br /> <br /> ===Create a latte_c project directory===<br /> <br /> We have placed the CPP options file <span class="red">latte_c.h</span>, standand input <span class="red">ocean_lattec.in</span>, and a modified <span class="red">varinfo.dat</span> in <span class="red">/srv/ckpt/roms/shared/latte_c/Forward</span>. Make a new Project directory for this new application and copy these 3 files. '''DO NOT''' copy all the netcdf files from <span class="red">/srv/ckpt/roms/shared/latte_c/in<br /> </span>.<br /> <br /> ===Edit build.bash===<br /> <br /> Set the correct entries for ROMS_APPLICATION and MY_PROJECT_DIR<br /> <br /> ===Edit ocean_lattec.in===<br /> <br /> Change the entries for GRDNAME etc so that ROMS finds the shared input files.<br /> <br /> Change the path for HISNAME and other outputs so that your output is written to your own work space.<br /> <br /> ===Compile with build.bash===<br /> <br /> ==Before we run latte_c==<br /> <br /> ===Browse the latt_c.h options===<br /> <br /> ===Browse input netcdf files===<br /> <br /> Use ncdump -h<br /> <br /> ==Run the latte_c example==<br /> <br /> <br /> <br /> ==Plotting netcdf outout with Matlab==<br /> <br /> ===Basics of Matlab-Netcdf===<br /> <br /> ===Using roms_wilkin routines===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=ROMS_UNSW2008&diff=3613 ROMS UNSW2008 2009-03-23T18:02:45Z

<p>Csherwood: </p> <hr /> <div><div class="title">Installing and Running ROMS for First Time Users</div><br /> <br /> '''A tutorial for new ROMS users will be held at the UNSW Computer Labs on Monday 30 March 2009, immediately prior to the ROMS Sydney 2009 User Workshop at the Sydney Institute of Marine Sciences, 31 March to 2 April 2009.'''<br /> <br /> {{note}}''<span class="blue">This tutorial is intended for complete newcomers to ROMS. It assumes basic knowledge of working in a UNIX environment, and that the essential components required to compile and execute ROMS are already installed on the host computer network. This wiki page borrows heavily from David's Robertson's excellent [[ROMS_Cygwin|Installing ROMS under Cygwin]] tutorial where you will find more information about setting up the required computing environment (compilers, libraries etc.) for ROMS.</span>''<br /> <br /> In this tutorial, we cover how to download the code, configure it for an application, and run the model. Error messages that arise during the configuration process will be explained so that these can better be debugged when users return to their home institutions and try to work through this process again.<br /> <br /> '''A follow-in tutorial covering sediment will be presented on [[CSTMS_UNSW2008| Friday 03 April]].'''<br /> <br /> {{note}}An important resource you should use as you get started is the [[Frequently_Asked_Questions | Frequently Asked Questions]] entry in [https://www.myroms.org/wiki WikiROMS].<br /> <br /> <br /> __TOC__<br /> <br /> ==Download ROMS==<br /> <br /> The disk space available on the UNSW Computer Lab machines is quite limited, so for the purposes of this tutorial we have downloaded the ROMS source code to '''<span class="red">/srv/ckpt/roms/shared/src</span>''' on host '''<span class="blue">matht001</span>'''. Instructions below will explain how to point the '''<span class="red">build.bash</span>''' script that compiles ROMS to this directory.<br /> <br /> '''To download the code to your own machine, these are the steps you would follow:'''<br /> <br /> :*You must have already registered on the ROMS portal and obtained your ROMS username/password as indicated in the [[ROMS_Cygwin#Register|Register]]. If you are also interested in access to research branches of the sediment code, indicate an interest in the Community Sediment Transport Modeling System (CSTMS) while you are registering. Once your registration is accepted, or if you are already registered, ask Dave Robertson (<span class="twilightBlue">robertson at marine.rutgers.edu</span>) to add you as a CSTMS user.<br /> <br /> :*Create a <span class="red">src</span> folder where you will keep the ROMS source code. You can place this wherever you wish in your directory tree (here we assume under your home directory "<span class="forestGreen">~</span>") and name it whatever you like.<br /> ::<div class="box"><span class="forestGreen">cd ~<br />mkdir src</span></div><br /> <br /> :*Check out the ROMS source code replacing <span class="forestGreen">''bruce''</span> with the ROMS user name you registered with.<br /> ::<div class="box"><span class="forestGreen">svn checkout --username bruce <nowiki>https://www.myroms.org/svn/src/trunk src</nowiki></span></div> Note the target directory <span class="forestGreen">src</span> at the end of the command. If your code ends up in the wrong place, you may have omitted this. <br /> <br /> You will see many lines stream by indicating the files that are being added to your src directory. When it finishes, you can type <span class="forestGreen">ls src</span> to see the contents of the directory. <br /> <br /> To see the contents of the directory where the code is downloaded for this tutorial, type this:<br /> ::<div class="box"><span class="forestGreen">cd /srv/ckpt/roms/shared<br />ls src</span></div><br /> <br /> ==Customize the [[build Script|Build Script]]==<br /> The ROMS source code comes with a [[build Script|build script]] in the <span class="red">ROMS/Bin</span> directory. Examples written with <span class="forestGreen">bash</span> (<span class="red">build.bash</span>) and <span class="forestGreen">csh</span> (<span class="red">build.sh</span>) are provided. The UNSW Computer Lab machines are configured to use <span class="forestGreen">bash</span> as the default login shell, so we will work with <span class="red">build.bash</span>. A full description of the build script can be found [[build Script|here]].<br /> <br /> :*In your home directory (you can use some other directory to organize your ROMS projects if you wish) create a new folder named <span class="red">Projects</span> and change into it.<br /> ::<div class="box"><span class="forestGreen">cd ~<br />mkdir Projects<br />cd Projects</span></div><br /> :*Create a folder named <span class="red">upwelling</span> and change into it. ROMS is distributed with several [[Test Cases|Test Cases]] and the [[UPWELLING_CASE|Upwelling example]] is the default which we will compile and run here. <br /> ::<div class="box"><span class="forestGreen">mkdir upwelling<br />cd upwelling</span></div><br /> <br /> :*Copy the <span class="red">build.bash</span> file distributed with ROMS to your <span class="red">Projects/upwelling</span> directory.<br /> ::<div class="box"><span class="forestGreen">cp /srv/ckpt/roms/shared/src/ROMS/Bin/build.bash .</span></div><br /> <br /> Next we need to configure a few options inside <span class="red">build.bash</span> so that it finds the directories where the source code and your Project are located. <br /> <br /> :*Open the <span class="red">build.bash</span> script you just copied into your <span class="red">upwelling</span> directory using your preferred text editor, e.g. vi.<br /> ::<div class="box"><span class="forestGreen">vi build.bash</span></div><br /> <br /> :*Scroll down until you find <span class="orange">ROMS_APPLICATION</span>. You will notice it is set as follows:<br /> ::<div class="box"> <span class="blue">export</span> <span class="red">ROMS_APPLICATION</span>=UPWELLING</div> We do not need to change this. But this is the first thing you will alter when starting your own project. This tells ROMS the name of an include file that will contain all the directives to the C-PreProcessor to configure your application at compile time. ROMS' rule is change this string to lowercase and append a ".h", so this will search for a file called <span class="red">upwelling.h</span>. It must be in the directory specified by <span class="orange">MY_PROJECT_DIR</span>:<br /> <br /> :*Scroll down until you find <span class="orange">MY_PROJECT_DIR</span> and set it as follows:<br /> ::<div class="box"> <span class="blue">export</span> <span class="red">MY_PROJECT_DIR</span>=${<span class="red">HOME</span>}/Projects/upwelling</div> This obviously assumes you put <span class="red">Projects/upwelling</span> under your home directory.<br /> <br /> If you frequently move your ROMS project between hosts where you have a different directory structure, e.g. a temporary scratch space, you can use the <span class="orange">MY_ROOT_DIR</span> variable to minimize the changes you make to <span class="red">build.bash</span>.<br /> <br /> :*For example: <br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROOT_DIR</span>=/usr/scratch/bruce<br /><span class="blue">export</span> <span class="red">MY_PROJECT_DIR</span>=${<span class="red">MY_ROOT_DIR</span>}/Projects/upwelling</div><br /> <br /> Next we tell <span class="red">build.bash</span> where to find the ROMS source code downloaded from the svn repository (which you can keep up to date the <span class="forestGreen">svn update</span> command - see more on this at LINK ). Note that most of the source code changes you make to customize ROMS will be made in your Projects space, and need not be made to the downloaded code directly. We will discuss exceptions to this during the tutorial, and how source code modifications interact with svn.<br /> <br /> :*Set <span class="orange">MY_ROMS_SRC</span> to the location of the source code:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROMS_SRC</span>=/srv/ckpt/roms/shared/src</div> In practise, you will probably do something more like this:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">MY_ROMS_SRC</span>=${<span class="red">MY_ROOT_DIR</span>}/src</div> assuming this is the relative path in which you keep your source code on the various machines you work on. <br /> <br /> Make sure that <span class="orange">MY_CPP_FLAGS</span> is '''not''' set. Sometimes this is set in the distributed build.bash exmaple. Comment out options with the # symbol like so:<br /> ::<div class="box"><span class="blue">#export MY_CPP_FLAGS="-DAVERAGES"</span> </div><br /> <br /> The UNSW Computer Lab machines are single core, so we need to tell <span class="red">build.bash</span> not to assume MPI parallel compilation. <br /> <br /> :*Comment out the options for <span class="orange">USE_MPI</span> and <span class="orange">USE_MPIF90</span><br /> ::<div class="box"><span class="blue">#export USE_MPI=on <br>#export USE_MPIF90=on</span> </div><br /> <br /> :*If you were compiling in parallel you would leave the default entries in <span class="red">build.bash</span>. <br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_MPI</span>=<br /><span class="blue">export</span> <span class="red">USE_MPIF90</span>=</div><br /> <br /> :*We leave the compiler option as the default because this says use the <span class="forestGreen">ifort</span> (Intel FORTRAN) compiler which is what we want on the UNSW machines. <br /> ::<div class="box"><span class="blue">export</span> <span class="red">FORT</span>=ifort</div><br /> <br /> :*In the interests of speed for this tutorial, we turn off compiler optimization by activating the debug option: <br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_DEBUG</span>=on</div>On the UNSW Lab machines compiling with optimization on will take over 15 minutes, but with optimization off (USE_DEBUG=on) it will be less than 60 seconds.<br /> <br /> Save and close the <span class="red">build.bash</span> file.<br /> <br /> <br /> ==Copy the input and CPPDEFS options files==<br /> <br /> We need three more files in <span class="red">Projects/upwelling</span> to configure and run ROMS. We copy the versions downloaded with svn because these are files you will work with locally when you experiment with changes to the test case example configuration. <br /> <br /> :*Copy files <span class="red">ocean_upwelling.in, varinfo.dat</span> and <span class="red">upwelling.h</span> into the <span class="red">Projects/upwelling</span> directory you just created.<br /> <br /> ::<div class="box"><span class="forestGreen">cd ~/Projects/upwelling<br />cp /srv/ckpt/roms/shared/src/ROMS/External/ocean_upwelling.in . <br>cp /srv/ckpt/roms/shared/src/ROMS/External/varinfo.dat . <br>cp /srv/ckpt/roms/shared/src/ROMS/Include/upwelling.h .</span></div><br /> <br /> View the file <span class="red">upwelling.h</span>. It contains all the [[C_Preprocessor|C-Pre-Processor (CPP)]] options that the compiler interprets to activate certain source code options within ROMS.<br /> <br /> View the file <span class="red">ocean_upwelling.in</span>. It contains the inputs options that ROMS [[ocean.in|reads from standard input]] at run time to set options that need not be fixed at compile time. <br /> <br /> View <span class="red">varinfo.dat</span>. The file [[varinfo.dat]] contains descriptions of the names and attributes of input and output variables that ROMS reads and writes from netcdf files. For most applications you will not need to change the entries in this file. If you need to know the default units assumed for different variables, those are noted in this file. (Before we run ROMS, we will need to tell it where to find this file). <br /> <br /> Now we are ready to compile ROMS by executing the <span class="red">build.bash</span> script.<br /> <br /> ==Compile ROMS==<br /> <br /> Before you run ROMS, you need to compile it to create an executable <span class="red">oceanS</span> file ('''S''' for serial or single processor computer), or <span class="red">oceanM</span> file (if using '''MPI''' on a parallel computer).<br /> <br /> :*Go to your upwelling project directory:<br /> ::<div class="box"><span class="forestGreen">cd ~/Projects/upwelling</span></div><br /> <br /> :*Then type:<br /> ::<div class="box"><span class="forestGreen">./build.bash</span></div><br /> <br /> :*If lots of stuff comes on the screen then compilation is proceeding, and make take some time. <br /> <br /> :*If the build process ends quickly with an error, then it is likely that <span class="red">build.bash</span> does not point to the correct location for the <span class="red">upwelling.h</span> file, the FORTRAN compiler, or some libraries. We describe common ''getting started'' errors and solutions in the next section. <br /> <br /> :*You may give the option <span class="forestGreen">-j</span> to the build command to distribute the compilation to multiple processors if your host supports this, e.g.:<br /> ::<div class="box"><span class="forestGreen">./build.bash -j 8</span></div> to compile on 8 processor at once. <br /> <br /> If your build was successful it will not have reported any errors, and there will be an executable file in your <span class="red">Projects/upwelling</span> directory called <span class="forestGreen">oceanG</span>. The <span class="forestGreen">"G"</span> in the file name indicates <span class="red">build.bash</span> activated the <span class="blue">USE_DEBUG</span> option. <br /> <br /> If <span class="blue">USE_DEBUG</span> were not selected, the executable would be <span class="forestGreen">oceanS</span>, where the <span class="forestGreen">"S"</span> indicates "serial" or "single-processor" because we deactivated MPI. <br /> <br /> If you had activated MPI with the <span class="blue">USE_MPI</span> option the executable would be named <span class="forestGreen">oceanM</span>.<br /> <br /> (See also [[Frequently_Asked_Questions#My_build_finished_with_no_errors._Where_is_the_ROMS_executable.3F|FAQ: My build finished with no errors, where is the ROMS executable?]]). <br /> <br /> <br /> ===Common ''getting started'' compile error messages===<br /> <br /> Getting past the first few errors with compilation is often tricky. Carefully read any error messages you get for clues on what might be wrong with your configuration. Here are some common difficulties new users encounter getting started when first executing the <span class="red">build.bash</span> command. <br /> <br /> :*<div class="box">Compilers/../ROMS/Include/cppdefs.h:709:22: <br>error: /student/0/a0000020/Projects/upwelling/upwelling.h: No such file or directory</div> This says the file <span class="red">upwelling.h</span> is not where Build expects it to be, which is in <span class="orange">MY_PROJECT_DIR</span>. You set this to <span class="red">~/Projects/upwelling</span>.<br /> <br /> :*<div class="box">cp: cannot stat `/opt/intelsoft/netcdf/include/netcdf.mod': No such file or directory</div> This says that netcdf is not where build.bash expects to find it. Locate where the netcdf include and lib directories with steps something like:<div class="box"><span class="forestGreen">cd /usr <br>find . -name netcdf.mod -print<br></span> ./local/netcdf-3.6.2/include/netcdf.mod <br> ./local/netcdf/intel/3.6.3/include/netcdf.mod</div>This tells us the most recent (3.6.3) netcdf is in <span class="red">/usr/local/netcdf/intel/3.6.3</span>. Direct ROMS to this location by making two changes to <span class="red">build.bash</span>. First, advise ROMS to read your changes to the default library path by uncommenting the option for <span class="orange">USE_MY_LIBS</span>.<br /> ::<div class="box"><span class="blue">export</span> <span class="red">USE_MY_LIBS</span>=on</div> Then specifiy the correct location for netcdf:<br /> ::<div class="box"><span class="blue">export</span> <span class="red">NETCDF_INCDIR</span>=/usr/local/netcdf/intel/3.6.3/include<br /><span class="blue">export</span> <span class="red">NETCDF_LIBDIR</span>=/usr/local/netcdf/intel/3.6.3/lib</div> {{warning}} Be careful where you make this change. You need to make it for the <span class="forestGreen">ifort</span> compiler option, and NOT for the <span class="orange">USE_NETCDF4</span> option (we are using netcdf-3). If you've done this correctly, your compilation with <span class="red">build.bash</span> should now succeed.<br /> <br /> :*<div class="box">error <br>error: </div> Note here further errors we encounter during the tutorial.<br /> <br /> <br /> ==Run ROMS==<br /> <br /> You run ROMS by executing the <span class="forestGreen">oceanG</span> (or <span class="forestGreen">oceanS</span>) binary, giving it the <span class="red">ocean_upwelling.in</span> file as UNIX standard input. <br /> ::<div class="box"><span class="forestGreen">./oceanS < ocean_upwelling.in</span></div> ROMS standard output will be typed to the screen. To save it a file instead, enter, e.g.:<br /> ::<div class="box"><span class="forestGreen">./oceanS < ocean_upwelling.in > my_upwelling.log </span></div><br /> <br /> If you have compiled a parallel (MPI) executable, the syntax for running the mode is slightly '''but critically''' different. The <span class="red">ocean_upwelling.in</span> file is no longer read from UNIX standard input (it has handled by all the MPI threads) so the <span class="forestGreen">"<"</span> disappears from the command, and you need the correct syntax on your UNIX host for running an MPI process. It is probably something like: <br /> ::<div class="box"><span class="forestGreen">mpirun -np 8 ./oceanM ocean_upwelling.in > my_upwelling.log</span></div> where the <span class="forestGreen">"-np 8"</span> indicates use 8 processors and this number of tiles must have been set by <br /> <br /> (See also [[Frequently_Asked_Questions#What_do_I_have_to_do_to_run_an_application.3F | FAQ: What do I have to do to runs ROMS?]]).<br /> <br /> <br /> ===Common ''getting started'' run error messages===<br /> <br /> ::<div class="box">bash: oceanG: command not found</div>The working directory is not in your UNIX path. That's why we type "dot-slash" in front of the commands above.<br /> <br /> <br /> ==Successful execution==<br /> <br /> ===Standard Output===<br /> <br /> When ROMS runs it will type a lot of information to UNIX standard output. This is the "logfile" you named following the ">", or your terminal if you did not redirect stdout. <br /> <br /> STDOUT shows the following:<br /> <br /> :*UNIX process info, run time, run TITLE <br /> ::<div class="box"> Process Information: <br> Thread # 0 (pid= 4449) is active. <br> Model Input Parameters: ROMS/TOMS version 3.2 <br> Monday - March 23, 2009 - 10:02:39 AM <br>----------------------------------------------------------- <br> Wind-Driven Upwelling/Downwelling over a Periodic Channel</div><br /> <br /> :*OS, compiler information, SVN version, and your MY_ROMS_SRC, MY_HEADER_DIR and ROMS_APPLICATION settings<br /> ::<div class="box">Operating system : Linux<br>CPU/hardware : i686<br>Compiler system : ifort <br>Compiler command : /usr/local/intel/fc/10.1.021/bin/ifort <br>Compiler flags : -heap-arrays -ip -O3 -pc80 -xW -free<br><br>SVN Root URL : <nowiki>https://www.myroms.org/svn/src/trunk</nowiki><br>SVN Revision : 333<br>Local Root : /srv/ckpt/roms/shared/src<br>Header Dir : /student/0/a0000020/srv/Projects/upwelling<br>Header file : upwelling.h<br>Analytical Dir: /student/0/a0000020/srv/Projects/upwelling<br><br>Resolution, Grid 01: 0041x0080x016, Parallel Threads: 1, Tiling: 001x001</div>Check that these are what you intended. In last line above<br /> ::*"Grid 01" pertains to future ROMS developments with multiple nested/connected grids, <br /> ::* 0041x0080x016 shows the grid size is 41 x 80 x 16 grid points in the K,J,I directions<br /> ::* The Parallel/Tiling message shows you are using a single process and a single domain tile. When using MPI, this message will describe how many tiles you are using and the MPI processes assigned. <br /> <br /> :*Input parameters set in <span class="red">ocean_upwelling.in</span><br /> ::<div class="box">Physical Parameters, Grid: 01<br>=============================<br><br> 288 ntimes Number of timesteps for 3-D equations.<br> 300.000 dt Timestep size (s) for 3-D equations.<br> 30 ndtfast Number of timesteps for 2-D equations between<br> each 3D timestep.<br> ...<br> Output Averages File: ocean_avg.nc<br> Output Diagnostics File: ocean_dia.nc</div><br /> <br /> :*Then some more about the tiling when running in parallel<br /> <br /> :*The C-PreProcessor (CPP) flags set in <span class="red">upwelling.h</span> but '''AS MODIFIED''' by ROMS when interpreting and checking the selected CPP options. <br /> ::<div class="box"> Activated C-preprocessing Options:<br><br> UPWELLING Wind-Driven Upwelling/Downwelling over a Periodic Channel<br> ANA_BSFLUX Analytical kinematic bottom salinity flux.<br> ANA_BTFLUX Analytical kinematic bottom temperature flux.<br> ANA_GRID Analytical grid set-up.<br> ANA_INITIAL Analytical initial conditions.<br> ...</div>You should check that the CPP options displayed here agree with what you intended. For example, if you inadvertently specify more than one horizontal advection scheme option, ROMS will have chosen only one and reported that option here.<br /> <br /> :*The preamble in STDOUT continues with information about the space and time discretization: grid spacing, grid volume, Courant number (time step stability) and stiffness (related to s-coordinate accuracy).<br /> <br /> :*Then the model starts time stepping:<br /> ::<div class="box">NL ROMS/TOMS: started time-stepping: (Grid: 01 TimeSteps: 00000001 - 00000288)<br><br> STEP Day HH:MM:SS KINETIC_ENRG POTEN_ENRG TOTAL_ENRG NET_VOLUME<br><br> 0 0 00:00:00 0.000000E+00 6.579497E+02 6.579497E+02 3.884376E+11<br> DEF_HIS - creating history file: ocean_his.nc<br> WRT_HIS - wrote history fields (Index=1,1) into time record = 000000<br> DEF_AVG - creating average file: ocean_avg.nc<br> DEF_DIAGS - creating diagnostics file: ocean_dia.nc<br> 1 0 00:05:00 3.268255E-13 6.579497E+02 6.579497E+02 3.884376E+11<br> 2 0 00:10:00 6.503587E-12 6.579497E+02 6.579497E+02 3.884376E+11<br> 3 0 00:15:00 4.592307E-11 6.579497E+02 6.579497E+02 3.884376E+11<br><br> ...</div>This output indicates several things:<br /> ::*the run is programmed to run from time step 1 to 288<br /> ::*the run starts at time 00:00:0<br /> ::*netcdf output HISTORY, AVERAGES and DIAGNOSTICS files are created. Every time ROMS creates a new netcdf file, and writes to an existing file, it reports this to STDOUT<br /> ::*output is written to the HISTORY file<br /> ::*then global quantities related to the model KE, PE and domain volume are reported on each time step<br /> <br /> {{note}} In 99% of situations, ''getting started'' problems with model set-up and configuration can be diagnosed by carefully reading the STDOUT above. Things to look for are:<br /> :*misconfigured CPP options (what you got is not what you thought you asked for)<br /> :*parameter errors (e.g. you activated horizontal mixing but left the coefficient as zero)<br /> :*misnamed output files (that's why the files from your last run got overwritten)<br /> :*irrational choices of grid spacing or time step <br /> :*initial/boundary/forcing data being read from the wrong file, or not read at all (because you selected analytical conditions)<br /> <br /> At the conclusion of the run, ROMS reports information about run time:<br /> ::<div class="box"> Elapsed CPU time (seconds):<br><br> Thread # 0 CPU: 108.079<br> Total: 108.079<br><br>Nonlinear model elapsed time profile:<br><br> Initialization ................................... 0.016 ( 0.0148 %)<br> Processing of input data ......................... 0.028 ( 0.0259 %)<br> Processing of output time averaged data .......... 4.312 ( 3.9899 %)<br> ... </div><br /> :*about the number of output records written to each file<br /> ::<div class="box"> ROMS/TOMS - Output NetCDF summary for Grid 01: <br> number of time records written in HISTORY file = 00000005 <br> ...</div><br /> :*and the analytical files included <br /> ::<div class="box"> Analytical header files used:<br><br> ROMS/Functionals/ana_btflux.h<br> ROMS/Functionals/ana_grid.h<br> ...</div>If you used a modified analytical file in your <span class="orange">MY_HEADER_DIR</span> it will be reported here and is another thing you should check for consistency with your intentions.<br /> <br /> <br /> ===Netcdf file output===<br /> <br /> As reported above, ROMS created 4 output netcdf files when it ran. There are ocean_his.nc, ocean_avg.nc, ocean_dia.nc, and coean_rst.nc. These are, respectively:<br /> :*history records or 'snapshots' of the model state a selected time intervals<br /> :*averages of the model state over selected intervals (not necessarily the same intervals as the history)<br /> :*diagnostics of the model state, the precise contents of which are controlled by CPP options<br /> :*a restart file with everything ROMS needs to restart a application. This is useful if your job crashes at some point and you want to recommence from a previous state without starting over. Typically the restart file is set to keep just 2 time records by continually over-writing the oldest as the run proceeds. This behaviour is controlled in ocean_upwelling.in. Also, when ROMS "blows up" it dumps the ocean state to a 3rd record in the restart file. <br /> <br /> You can browse the contents of netcdf files at the UNIX command line with the command ncdump, e.g. <br /> ::<div class="box"><span class="forestGreen">ncdump -h ocean_his.nc | more</span> </div><br /> Note the use of the <span class="forestGreen">"-h"</span> option. This restricts the output from ncdump to be just the header information, or metadata, in the netcdf file. Without the "-h" option you will get the entire contents of the file converted to ascii. <br /> <br /> Things to notice when you ncdump the ocean_his.nc file are that it contains all the input parameters (time step, mixing coefficients, s-coordinate parameters, etc.) from ocean.in, the model grid coordinates (x, y, lon, lat, depth, Coriolis parameter, etc.) which may have been computed by the ANA_GRID option or read from an input grid netcdf file, in addition to the actual model output (ocean_time, zeta, u, v, temp, salt). <br /> <br /> There are netcdf '''global attributes''' that echo much of the information typed to STDOUT. This includes compiler, svn version, and project directory information, and all the CPP options. This is a valuable source of information when returning to a project and trying to figure out what you did! The global attributes metadata show precisely which options were activated when creating the output in this netcdf file. <br /> <br /> <br /> ==Changing the UPWELLING test case configuration==<br /> <br /> <br /> ===Compile time changes: <span class="red">upwelling.h</span>===<br /> <br /> <br /> <br /> <br /> <br /> <br /> ===Run time changes: <span class="red">ocean_upwelling.in</span>===<br /> <br /> <br /> <br /> <br /> <br /> ==A ''Realistic'' model example: LaTTE==<br /> <br /> This section of the tutorial assumes you have successfully compiled and run the UPWELLING example above. Key concepts you should be comfortable with to proceed are:<br /> :*you need a new directory where you will keep the files specific to the new application<br /> :*customize <span class="red">build.bash</span> for the new application (copy the build.bash from <span class="red">upwelling</span> because it has all the correct compiler and library settings)<br /> :*set <span class="blue">MY_PROJECT_DIR</span> in <span class="red">build.bash</span> to point to the directory for the new application<br /> :*set <span class="blue">ROMS_APPLICATION</span> in <span class="red">build.bash</span> to the correct name for the new application<br /> :*if you wish to customize any of the <span class="forestGreen">ana_*.h</span> files, copy just the ones you need into the new project directory <br /> :*you '''don't''' need to make a copy the source code a new application<br /> <br /> With these concepts in mind, we proceed by configuring ROMS to run a realistic coastal ocean application that includes open boundaries on 3 sides, open boundary tides and climatology velocity and tracer (temperature and salinity) conditions, surface meteorological forcing, and initial conditions, all provided by input netcdf files. The example is called LaTTE_C because it simulates ocean conditions during the '''Lagrangian Transport and Transformation Experiment''' conducted on the New Jersey inner shelf in the Spring of 2006. The '_C' denotes a coarse resolution configuration suitable for this training exercise. <br /> <br /> <br /> ===Create a latte_c project directory===<br /> <br /> We have placed the CPP options file <span class="red">latte_c.h</span>, standand input <span class="red">ocean_lattec.in</span>, and a modified <span class="red">varinfo.dat</span> in <span class="red">/srv/ckpt/roms/shared/latte_c/Forward</span>. Make a new Project directory for this new application and copy these 3 files. '''DO NOT''' copy all the netcdf files from <span class="red">/srv/ckpt/roms/shared/latte_c/in<br /> </span>.<br /> <br /> ===Edit build.bash===<br /> <br /> Set the correct entries for ROMS_APPLICATION and MY_PROJECT_DIR<br /> <br /> ===Edit ocean_lattec.in===<br /> <br /> Change the entries for GRDNAME etc so that ROMS finds the shared input files.<br /> <br /> Change the path for HISNAME and other outputs so that your output is written to your own work space.<br /> <br /> ===Compile with build.bash===<br /> <br /> ==Before we run latte_c==<br /> <br /> ===Browse the latt_c.h options===<br /> <br /> ===Browse input netcdf files===<br /> <br /> Use ncdump -h<br /> <br /> ==Run the latte_c example==<br /> <br /> <br /> <br /> ==Plotting netcdf outout with Matlab==<br /> <br /> ===Basics of Matlab-Netcdf===<br /> <br /> ===Using roms_wilkin routines===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3612 CSTMS UNSW2008 2009-03-23T17:38:57Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April, there will be a tutorial for new ROMS users interested in sediments. This will continue using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A case study in troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101 Its the waves===<br /> ===Analytical waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3611 CSTMS UNSW2008 2009-03-23T17:20:31Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April, there will be a tutorial for new ROMS users interested in sediments. This will continue using the LATTE example presented during the [[ROMS_UNSW2008|Monday tutorial]].'''<br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A Case Study in Troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101 Its the waves===<br /> ===Analytical Waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3610 CSTMS UNSW2008 2009-03-23T17:01:29Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April, there will be a tutorial for new ROMS users interested in sediments. This will which will continue using the LATTE example started on [[ROMS_UNSW2008|Monday]].'''<br /> <br /> In this tutorial, we do. <br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A Case Study in Troubleshooting==<br /> <br /> ==Why so boring?==<br /> <br /> ===Sediment 101 Its the waves===<br /> ===Analytical Waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3609 CSTMS UNSW2008 2009-03-23T16:57:52Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April, there will be a tutorial for new ROMS users interested in sediments. This will which will continue using the LATTE example started on Monday.'''<br /> <br /> In this tutorial, we do. <br /> <br /> __TOC__<br /> <br /> ==Test the LATTE case==<br /> <br /> ==Change the advection scheme==<br /> <br /> ==Turn on sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A Case Study in Troubleshooting==<br /> <br /> ==Why so boring?==<br /> ===Sediment 101: Its the waves, s...===<br /> ===Analytical Waves===<br /> <br /> ==SWAN - A Digression==<br /> <br /> ==Wave-current coupling==<br /> <br /> ==Realistic sediment==<br /> <br /> ==Stuff not covered in the LATTE example==<br /> <br /> ===Bedload===<br /> <br /> ===Morphodynamics===<br /> <br /> ===Wetting and drying===<br /> <br /> ===Cohesive and Mixed Sediment===<br /> <br /> ===</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3608 CSTMS UNSW2008 2009-03-23T16:51:14Z

<p>Csherwood: </p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''On Friday, 3 April, there will be a tutorial for new ROMS users interested in sediments. This will which will continue using the Latte example.'''<br /> <br /> <br /> In this tutorial, . <br /> <br /> <br /> <br /> __TOC__<br /> <br /> ==Test the Latte Case==<br /> <br /> ==Change the Advection Scheme==<br /> <br /> ==Turn on Sediment==<br /> <br /> ===Changes to the .h file===<br /> ===Additions to the init file===<br /> <br /> ==A Case Study in Troubleshooting==<br /> <br /> ==Why so boring?==<br /> ===Sediment 101: Its the waves, s...===<br /> ===Analytical Waves===<br /> <br /> ==SWAN - A Digression==</div>

Csherwood https://www.myroms.org/wiki/index.php?title=CSTMS_UNSW2008&diff=3607 CSTMS UNSW2008 2009-03-23T16:33:27Z

<p>Csherwood: New page: <div class="title">Adding Sediment to the Latte Example</div> '''A tutorial for new ROMS users will be held at the UNSW Computer Labs on Monday 30 March 2009, immediately prior to the ROM...</p> <hr /> <div><div class="title">Adding Sediment to the Latte Example</div><br /> <br /> '''A tutorial for new ROMS users will be held at the UNSW Computer Labs on Monday 30 March 2009, immediately prior to the ROMS Sydney 2009 User Workshop at the Sydney Institute of Marine Sciences, 31 March to 2 April 2009. On Friday, 3 April, there will be a tutorial for new ROMS users interested in sediments which will continue using the Latte example.'''<br /> <br /> <br /> In this tutorial, . <br /> <br /> <br /> <br /> __TOC__<br /> <br /> ==Download ROMS==<br /> <br /> The disk space available on the UNSW Computer Lab machines is quite limited, so for the purposes of this tutorial we have downloaded the ROMS so</div>

Csherwood https://www.myroms.org/wiki/index.php?title=Tutorials&diff=3606 Tutorials 2009-03-23T16:03:41Z

<p>Csherwood: </p> <hr /> <div><div class="title">ROMS Tutorials</div><br /> <br /> This page is for tutorials on using ROMS and other related software. If you create a tutorial please create a link to that tutorial in the list below.<br /> <br /> ==Installing ROMS==<br /> :*[[ROMS_Cygwin|Installing ROMS in Windows XP/Vista (via Cygwin)]]<br /> :*[[ROMS_UNSW2008|Installing and Running ROMS for First Time Users. Tutorial at UNSW Computer Labs, 30 March 2009]]<br /> <br /> ==Sediment Tutorials==<br /> :*[[CSTMS_UNSW2008|Adding sediment to the Latte example. Tutorial at UNSW Computer Labs, 3 April 2009]]<br /> <br /> ==Utilities and Tools==<br /> :*[[MEXNC|For Matlab users: Installing MEXNC, SNCTOOLS and ROMS-Matlab-toolkit]]<br /> :*[[Plotting_Package_Installation|Installing and Using the ROMS/TOMS Plotting Package]]<br /> <br /> ==Grid Generation Tutorials==</div>

Csherwood