Custom Query (964 matches)

The current trunk revision (-r 568) is quite stable so we are tagging this as ROMS/TOMS Version 3.5. Please check the following forum ​message for information about this release.

This is a major update of ROMS nonlinear (NLM), tangent linear (TLM), representer (RPM), and adjoint (ADM) models to include the multiple grid nesting (refinement, composed, and mosaics) Phase II development. The main goal in Phase II is to remove all the lateral boundary conditions C-preprocessing options and replace them with logical switches. The changes are extensive because there were periodic boundary conditions (EW_PERIODIC and NS_PERIODIC) everywhere in the code. This required extensive testing of the NLM, TLM, RPM, and ADM kernels and provided idealized and realistic test cases.

The actual nesting capabilities are not available yet. This will be released in Phase III in the near future. There is is still some work ahead. The changes that will be required for full nesting capabilities are very minimal but tricky and will involve changes to main2d/main3d and adding new files for the actual nesting.

However, the current update is very important since it includes changes to the ROMS kernel. At the beginning, I thought that Phase II was really easy but tedious. Well, I greatly underestimated the amount of work and time in the debugger during testing. It was as tricky as Phase I but it only took me five months to finish it.

We are releasing this update at this time to allow the Users time to assimilate, test, and play with the new lateral boundary conditions structure. One of the advantages of the new design is the we can have different lateral boundary conditions for each active (temperature and salinity) and passive (inert, biology, sediment, etc) tracers. I highly recommend that you use the same lateral boundary conditions for temperature and salinity because they uniquely determine the density of the fluid via the equation of state for seawater.

This version is named ROMS 3.6. Once we have the full nesting in place and finish other important developments it will become ROMS 4.0. The current plan is to release ROMS 4.0 sometime this year.

The technical description of the changes is elaborated and will be reported in the ROMS ​forum.

Good look updating to ROMS Version 3.6 ...

Updated the ROMS Test Cases input scripts (ocean_*.in, biology.in, sediment.in) and build (build.bash and build.sh) scripts to ROMS 3.6.

The technical description of the changes are elaborated and are reported in the ROMS ​forum.

The lateral boundary conditions are now set-up in input script. For example, User/External/ocean.cblast.in has:

! Set lateral boundary conditions keyword. Notice that a value is expected
! for each boundary segment per nested grid for each state variable.
!
! Each tracer variable requieres [1:4,1:NAT+NPT,Ngrids] values. Otherwise,
! [1:4,1:Ngrids] values are expected for other variables. The boundary
! order is: 1=west, 2=south, 3=east, and 4=north. That is, anticlockwise
! starting at the western boundary.
!
! The keyword is case insensitive and usually has three characters. However,
! it is possible to have compound keywords, if applicable. For example, the
! keyword "RadNug" implies radiation boundary condition with nudging. This
! combinatiion is usually used in active/passive radiation conditions.
! 
!   Keyword    Lateral Boundary Condition Type
!
!   Cha        Chapman
!   Cla        Clamped
!   Clo        Closed
!   Fla        Flather                                _____N_____     j=Mm
!   Gra        Gradient                              |     4     |
!   Nes        Nested                                |           |
!   Nud        Nudging                             1 W           E 3
!   Per        Periodic                              |           |
!   Rad        Radiation                             |_____S_____|
!   Red        Reduced Physics                             2          j=1
!                                                   i=1         i=Lm
!                   W       S       E       N     
!                   e       o       a       o     
!                   s       u       s       r     
!                   t       t       t       t     
!                           h               h     
!                                                 
!                   1       2       3       4     

   LBC(isFsur) ==   Cha     Cha     Cha     Cha         ! free-surface
   LBC(isUbar) ==   Fla     Fla     Fla     Fla         ! 2D U-momentum
   LBC(isVbar) ==   Fla     Fla     Fla     Fla         ! 2D V-momentum
   LBC(isUvel) ==   RadNud  RadNud  RadNud  RadNud      ! 3D U-momentum
   LBC(isVvel) ==   RadNud  RadNud  RadNud  RadNud      ! 3D V-momentum
   LBC(isMtke) ==   Gra     Gra     Gra     Gra         ! mixing TKE

   LBC(isTvar) ==   RadNud  RadNud  RadNud  RadNud \    ! temperature
                    RadNud  RadNud  RadNud  RadNud      ! salinity

! Adjoint-based algorithms, can have different lateral boundary
! conditions keywords.

ad_LBC(isFsur) ==   Cha     Cha     Cha     Cha         ! free-surface
ad_LBC(isUbar) ==   Fla     Fla     Fla     Fla         ! 2D U-momentum
ad_LBC(isVbar) ==   Fla     Fla     Fla     Fla         ! 2D U-momentum
ad_LBC(isUvel) ==   RadNud  RadNud  RadNud  RadNud      ! 3D U-momentum
ad_LBC(isVvel) ==   RadNud  RadNud  RadNud  RadNud      ! 3D V-momentum
ad_LBC(isMtke) ==   Gra     Gra     Gra     Gra         ! mixing TKE

ad_LBC(isTvar) ==   RadNud  RadNud  RadNud  RadNud \    ! temperature
                    RadNud  RadNud  RadNud  RadNud      ! salinity

! Set lateral open boundary edge volume conservation switch for
! nonlinear model and adjoint-based algorithms. Usually activated
! with radiation boundary conditions to enforce global mass
! conservation, except if tidal forcing. [1:Ngrids].

   VolCons(west)  ==  F                            ! western  boundary
   VolCons(east)  ==  F                            ! eastern  boundary
   VolCons(south) ==  F                            ! southern boundary
   VolCons(north) ==  F                            ! northern boundary

ad_VolCons(west)  ==  F                            ! western  boundary
ad_VolCons(east)  ==  F                            ! eastern  boundary
ad_VolCons(south) ==  F                            ! southern boundary
ad_VolCons(north) ==  F                            ! northern boundary

If your lateral boundary conditions are periodic, all the variables in such periodic direction must be set to periodic (Per keyword). I highly recommend to set the same type of lateral boundary condition for 2D momentum components (ubar, vbar). Similarly, use the same lateral boundary condition to 3D momentum components (u, v).

Notice all that the volume conservation option used in radiation conditions (VolCons) are also set-up in ocean.in.

Similarly, the boundary conditions for sediment and biological tracers are set-up in its respective input parameter script.

Backward compatibility with previous versions of ROMS is a little tricky bit but possible. After all, we are just changing C-preprocessing directives with Fortran logical switches. There are no changes to the computational kernels but changes in the flow of the computations. All the lateral boundary conditions are available after compiling (for instance, see Build/zetabc_im.f90). This can be both an advantage or a disadvantage. It is advantageous because we do not need to recompile the entire code when the lateral boundary conditions are changed. It also greatly facilitates nesting with simple logic instead of cumbersome and additional C-preprocessing options. It facilitates different lateral boundary conditions for some or all tracer fields. However, it is disadvantageous in the sense that we can no longer easily see which lateral boundary conditions were activated. We need to inspect carefully the standard output and NetCDF file global attributes.

All the C-preprocessing lateral boundary conditions options are removed from the svn distributed code. As such, any CPP option that you may have in your application header file will be ignored. However, it is very dangerous to have them if you have customized the code or use any customized analytical routines from ROMS/Functionals or User/Functionals. Therefore, I highly recommend that you remove them from your application header file and use the build script instead. I am providing examples of how this is done in the ​test repository. For example, in the INLET_TEST case (test/inlet_test/build.sh) we have:

# Set tunable CPP options.
#
# Sometimes it is desirable to activate one or more CPP options to run
# different variants of the same application without modifying its header
# file. If this is the case, specify each options here using the -D syntax.
# Notice also that you need to use shell's quoting syntax to enclose the
# definition.  Both single or double quotes work. For example,
#
#    setenv MY_CPP_FLAGS "-DAVERAGES"
#    setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DDEBUGGING"
#
# can be use to write time-averaged fields. Notice that you can have as
# many definitions as you want by appending values.

 setenv MY_CPP_FLAGS "-DSWAN_COUPLING"
 setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DMCT_LIB"

#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DDEBUGGING"
#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DOUT_DOUBLE"
#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DPOSITIVE_ZERO"

#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DUV_LOGDRAG"
#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DUV_QDRAG"

#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DMB_BBL"
#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DSG_BBL"
 setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DSSW_BBL"

 setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DNEARSHORE_MELLOR05"

#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DBEDLOAD_SOULSBY"
#setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DBEDLOAD_MPM"

# Set deprecated lateral boundary conditions CPP flags for backward
# compatibility with older versions of the code.

  setenv BACK_COMPATIBILITY  on         # needed for ROMS 3.4 or older

if ($?BACK_COMPATIBILITY) then
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DSOUTHERN_WALL"

  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DNORTH_FSGRADIENT"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DNORTH_M2REDUCED"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DFSOBC_REDUCED"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DNORTH_M3GRADIENT"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DNORTH_TGRADIENT"

  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DWEST_FSGRADIENT"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DWEST_M2GRADIENT"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DWEST_M3GRADIENT"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DWEST_TGRADIENT"

  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DEAST_FSGRADIENT"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DEAST_M2GRADIENT"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DEAST_M3GRADIENT"
  setenv MY_CPP_FLAGS "${MY_CPP_FLAGS} -DEAST_TGRADIENT"
endif

Notice the local environmental variable BACK_COMPATIBILITY which allows you to set the lateral boundary conditions C-preprocessing options for backward compatibility with older versions of the code. You can also modify the build script to use the old/new header files. For example, you may have:

# If applicable, use the MY_ANALYTICAL_DIR directory to place your
# customized biology model header file (like fennel.h, nemuro.h, ecosim.h,
# etc).

 setenv MY_HEADER_DIR       ${MY_PROJECT_DIR}

if (! $?BACK_COMPATIBILITY) then
  setenv MY_ANALYTICAL_DIR   ${MY_PROJECT_DIR}/Functionals_new
else
  setenv MY_ANALYTICAL_DIR   ${MY_PROJECT_DIR}/Functionals_old
endif

I also update some of the NetCDF files for BIO_TOY to insure that the solution is horizontally homogeneous.