IMPORTANT: Updated Test Cases to ROMS 3.6

[arango]

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.