Recomendations:
- Many users avoid reading the emails sent to everyone after the ROMS code and support repositories are updated. They contain helpful information and instructions. The ROMS system is now distributed exclusively via
GitHub. Everything is documented in the Pull Requests (PRs) and also in the Trac Wiki. It is recommended that users keep their code up to date to utilize new developments and fixed bugs. The system is now very stable, and updates are infrequent. - If the standard input files (*.in) for ROMS are modified, we will issue a warning that users may need to update their roms.in script.
- Similar warnings will be issued if the metadata configuration YAML file varinfo.yaml is updated to include new variables.
- There is no reason for users to modify the primary makefile or the distributed build scripts (GNU or CMake) in ROMS/Bin sub-directory that users may copy to their application directory as templates for their ROMS configuration.
- There is no reason for users to modify the CMake configuration and the CMakeList.txt files in every ROMS code subdirectory. The CMake configuration is more elaborate, requiring expertise to modify.
- Notice that the strategy is to provide build scripts in the ROMS Test Repository for every application that we distribute. You will find build_roms.csh, build_roms.sh, cbuild_roms.csh, and cbuild_roms.sh in every test sub-directory. We always set a few crucial CPP options in those build scripts to show the user how to modify the configuration of ROMS Unit Tests, as users may add comments to such build scripts. We do not recommend changing the application header files (*.h).
- In super computer centers, the users may have access to Spack-Stack modules that facilitate the loading of libraries needed to compile and link ROMS. The native ROMS and the ROMS-JEDI interface compile seamlessly with the latest Spak-Stack release 1.9.1, but they would also work with older versions for native ROMS.
- We can compile ROMS with ifx, since Intel doesn't support the ifort compiler, which means that they won't fix bugs in the ifort compiler.
- Notice that the ROMS build scripts include new options. Please check their documentation at the top of the script. For example, one could use the -g option to compile and link with Fortran debug flags, which renders slower code. We could use the -pio option to compile and link with the Parallel I/O (PIO) library, which accelerates the computations, or specify a particular branch from ROMS GitHub repository as a source code with the -b option:
Code: Select all
build_roms.csh -g -j 10 build_roms.sh -g -pio -j 10 build_roms.sh -pio -j 10 -b feature/kernel cbuild_roms.csh -g -j 10 -b develop cbuild_roms.sh -pio -j 10 -b feature/kernel - Warning, the PIO library only works in distributed-memory (MPI applications) since it is built on top of MPI-IO. For more information about the ROMS PIO implementation, please check the following ROMS GitHub PR.
- When configuring a ROMS application, ensure that the bottom bathymetry, h(lon, lat), for your grid is always positive and greater than zero. Recall that ROMS is a terrain-following coordinates discrete model. We need to have N vertically distributed levels with non-zero thicknesses (Hz>0). Thus, the bathymetry minimum (hmin>0) value at the coastlines must have a finite value to avoid segmentation or numerical vertical CFL violations. In most applications, the value of hmin ranges between 5 to 20 m, depending on the local topology, even if wetting and drying mask (WET_DRY) is activated.
- Users need to check ROMS input NetCDF files and ensure that the data doesn't contain NaN or Inf values. It is always advisable to plot the fields contained in such NetCDF files. The ncview tool is convenient for browsing input NetCDF fields and the value ranges.
- ROMS has a very verbose standard output that should be redirected to a log file. Users should not ignore that information and should check it carefully before posting panic messages in this Forum. It would save time for everybody. Failing is good when starting to use ROMS because learning comes after frustration.