Custom Query (964 matches)

We are modernizing the compiling of ROMS with gmake. The strategy has been since the beginning to create a static library for each sub-directory of ROMS source code. However, it is inconvenient nowadays because the compiling needs to be done in a specific order. Also, it is less efficient.

Therefore, the makefile, build scripts, Module.mk, and compiling and computer-specific configuration files (Compilers/*.mk) are modified to create a single STATIC and or SHARED library:

 libROMS.a            (static library)
 libROMS.so           (shared library)
 libROMS.dylib        (macOS shared/dynamic library)

It is similar to the strategy of compiling ROMS with CMake. It facilitates ROMS coupling with third-party systems like CMEPS/CDEPS and the integration to modern data assimilation systems like JEDI. A single ROMS library (libROMS) is passed to such systems.

Building a ROMS shared library is recommended for advanced users and specific applications that require it:

• Notice that you cannot delete or rename the standard Build_roms or Build_romsG directory containing the C-preprocessed, objects, modules, and library files because they are required to keep track of the objects in the shared libROMS.{so|dylib}. Those object will be lost and replaced with a new build.
• Static linking generates larger executables than shared/dynamic linking because it must compile all the code directly into the ROMS executable.
• Shared/dynamic libraries are smaller and place the calls at runtime to shared code objects. As a result, it has faster load times. In addition, it reduces disk space, memory, and improves multitasking.

Therefore, there is a tradeoff between static and shared libraries that require expertise. By default, we recommend using static libraries.

The build_roms.csh and build_roms.sh are modified to include options to create static and or shared ROMS library(ies). For example, in build_roms.sh, we have:

#export            SHARED=on            # build libROMS.{so|dylib}
 export            STATIC=on            # build libROMS.a

WARNING: If both SHARED and STATIC are turned on, in most computer operating systems (except CYGWIN), the shared library will be used to generate the ROMS executable.

Also, there is an option to create a specific ROMS executable:

export              EXEC=on            # build roms{G|M|O|S} executable

One could only run the build script to produce the library and not the executable (romsG, romsM, romsO, or romsS).

Still, ROMS can be compiled with the old build scripts. In such a case, ROMS will generate and be compiled with the static library (libROMS.a).

WARNING: Unfortunately, for the new static and shared libraries to work correctly few changes are required to the compiling configuration (*.mk) files in the Compilers sub-directory. They are usually user-customizable, so you need to update your compiling configuration. Alternatively, you could use the CMake build scripts (cbuild_roms.csh or cbuild_roms.sh) which do not require those tedius operating system dependent compilation files (See ​src:ticket:875 and ​src:ticket:876).

Many thanks to David Robertson for implementing and testing this update.

Corrected bug to define time-independent depth arrays in the output history, quicksave, and DA initialization NetCDF files. We get the following error during execution:

output statement overflows record, unit -5

The issue is fixed by changing the depth variable long_name attribute statement from:

        WRITE (Vinfo( 2),40) Vname(2,idpthR)

to

        WRITE (Vinfo( 2),40) TRIM(Vname(2,idpthR))
        ...

 40  FORMAT ('time independent',1x,a)

We need to use the intrinsic TRIM() function to remove the padding blanks and avoid overflow.

I am appalled about this one; no idea what the previous version of the compilers was doing here. Although the value in Vname for this case is "depth of RHO-points" the standard says that compilers should pad with blank spaces to the declared length of the character string (120). So, the first statement above prepended "time independent" to the resulting string, rendering the Vinfo(2) length larger than the declared 120 characters.

To avoid related issues in the future, the management of Vname and Vinfo is updated in several routines with a character length parameter, MaxLen in the delaration:

     integer, parameter :: MaxLen = 160    ! information string length
     ...
     character (len=MaxLen) :: Vname(6,0:NV)
     ...
     character (len=MaxLen), dimension(8) :: Vinfo

Notice its character length is incremented from 120 to 160.

Many thanks to Jiangtao Xu (NOAA) for reporting and tracking this bug.

We have carefully examined the DATA-WRF-ROMS coupling system with the ESMF/NUOPC library. We fixed esmf_atm_wrf.h NUOPC cap module after a detailed analysis of the heat flux balance equation. The documentation of WRF fluxes in the code is confusing about the direction (downward/upward) and the sign (positive/negative) of the latent and sensible heat fluxes. The net heat flux previously exported from WRF to ROMS was incorrect due to the confusing information.

• There are several variables in WRF for the heat component fluxes:

-- There is downwelling shortwave flux (swdnb, downward) and upwelling shortwave flux (swupb, upward) at the atmosphere bottom. Both are positive and with W/m² units. Therefore, the net shortwave radiation flux is swdnb minus swupb, stored in variable gsw, is positive and downward since swupb is around 8 percent of the magnitude of swdnb. Notice that the variable swdown is equivalent to swdnb. Both are positive and with W/m² units.

-- Since the ocean needs net shortwave radiation flux, we decided to use the downward (swdnb) and upward (swupb) fluxes for clarity. Also, the time-averaged values swdnb_mean and swupb_mean are available when the RAMS diagnostics are activated for semi-implicit coupling.

-- Similarly, there is downwelling longwave flux (lwdnb, downward) and upwelling longwave flux (lwupb, upward) at the atmosphere bottom. The variable lwupb is basically StefBo * emiss * Tsur⁴. Tsur is the land and ocean temperature at the atmosphere bottom (Kelvin). Likewise, notice that the variable glw is equivalent to lwdnb. We will use glw because its equivalent time-averaged variable is glw_mean when the RAMS diagnostics are activated for semi-implicit coupling. The net longwave radiation flux, glw minus lwupb, can be positive or negative.

-- The variable hfx is the sensible heat flux (W/m²), and lh is the latent heat flux (W/m²). Both fluxes are positive and upward from the bottom of the atmosphere. Please ignore the conflicting documentation in the WRF source code for these fluxes. The time-averaged values are hfx_mean and lh_mean, respectively. Therefore, we need to flip the sign and use minus when computing the ocean surface net heat flux.

-- Therefore, if BULK_FLUXES is off, the surface net heat flux (W/m²) exported to the ocean in subroutine WRF_Export of cap module esmf_atm_wrf.h needs to be:

            CASE ('nflx', 'shflux')
              MyFmin(1)= MISSING_dp
              MyFmax(1)=-MISSING_dp
              DO j=Jstr,Jend
                DO i=Istr,Iend
# ifdef WRF_TIMEAVG
                  Fval=(grid%swdnb_mean(i,j)-grid%swupb_mean(i,j))+     &
     &                 (grid%glw_mean(i,j)-grid%lwupb_mean(i,j))-       &
     &                 grid%lh_mean (i,j)-                              &
     &                 grid%hfx_mean(i,j)
# else
                  Fval=(grid%swdnb(i,j)-grid%swupb(i,j))+               &
     &                 (grid%glw(i,j)-grid%lwupb(i,j))-                 &
     &                 grid%lh (i,j)-                                   &
     &                 grid%hfx(i,j)
# endif
                  MyFmin(1)=MIN(MyFmin(1),Fval)
                  MyFmax(1)=MAX(MyFmax(1),Fval)
                  ptr2d(i,j)=Fval
                END DO
              END DO

Here, the CPP option WRF_TIMEAVG is used to compute the flux with the RAMS time-averaged diagnostics for semi-implicit coupling (see ​RunSequence in wikiROMS).

• Several routines in ROMS were updated to allow importing the components of the heat flux balance for debugging and output purposes when BULK_FLUXES is off.

• The test case for Hurricane Irene has been revised accordingly in the test repository. Please check this application when configuring your coupling system.

Snapshots of WRF land and ocean surface temperature and heat flux components are shown below for the hurricane Irene application:

Then, the atmospheric field imported by ROMS are:

Many thanks to my colleagues at Rutgers, John Wilkin, Julia Levin, and Travis Miles, for the discussions about WRF-ROMS coupling.

The zero values in the latent heat flux in the Mid-Atlantic Bight (MAB) were corrected by commenting a limiter kluge in WRF modules module_sf_sfclay.F and module_sf_sfclayrev.F. But unfortunately, it has been there for years, and the WRF developers refuse to correct it. Specifically, we need to comment on these two lines:

!   line 898

    QFX(I)=AMAX1(QFX(I),0.)    
 
!   And line 916

    HFX(I)=AMAX1(HFX(I),-250.)

Furthermore, unlimited and limited latent heat flux and its difference (unlimited minus limited) values are shown below. Notice the effects of the removing the limiters along the US East Coast, MAB, and the Gulf of Maine.

The resulting net heat flux difference between using unlimited and limited latent heat fluxes yields:

Therefore, users need to be aware of the latent heat flux limiters in the WRF modules mentioned above and experiment in their particular applications.