Custom Query (986 matches)

WARNING:

The standard input script ocean.in was modified and include new configuration parameters.

This ticket includes two critical updates to ROMS: tidal processing and upper limiter in vertical diffusion and viscosity computed from mixing parameterizations.

• The tidal forcing file was removed from the FRCNAME filenames list in ocean.in. It is now is entered separately in a new TIDENAME keyword:

  ! Input tidal forcing file name
  
    TIDENAME == ../om/doppio_tide_7km.nc
  

  If all the forcing files are the same for all nested grids and the data is in its native resolution, we could only specify one set of filenames instead of Ngrids copies. ROMS will replicate those files internally to the remaining grids using the plural keyword protocol. Including the tidal forcing filename in the list does not allow a single set because, in nested applications, the tidal forcing is needed only by the main coarser grid (RefineScale(ng)=0). The replication of tidal forcing file gives errors due to the different nested grid dimensions.

For example, in a three-grid nesting application we just need:

 NFFILES == 8 ! number of unique forcing files

 FRCNAME == ../om/lwrad_down_nam_3hourly_MAB_and_GoM_2014.nc |
            ../om/lwrad_down_nam_3hourly_MAB_and_GoM_2015.nc \

            ../om/Pair_nam_3hourly_MAB_and_GoM_2014.nc |
            ../om/Pair_nam_3hourly_MAB_and_GoM_2015.nc \

            ../om/Qair_nam_3hourly_MAB_and_GoM_2014.nc |
            ../om/Qair_nam_3hourly_MAB_and_GoM_2015.nc \

            ../om/rain_nam_3hourly_MAB_and_GoM_2014.nc |
            ../om/rain_nam_3hourly_MAB_and_GoM_2015.nc \

            ../om/swrad_daily_nam_3hourly_MAB_and_GoM_2014.nc |
            ../om/swrad_daily_nam_3hourly_MAB_and_GoM_2015.nc \

            ../om/Tair_nam_3hourly_MAB_and_GoM_2014.nc |
            ../om/Tair_nam_3hourly_MAB_and_GoM_2015.nc \

            ../om/Uwind_nam_3hourly_MAB_and_GoM_2014.nc |
            ../om/Uwind_nam_3hourly_MAB_and_GoM_2015.nc \

            ../om/Vwind_nam_3hourly_MAB_and_GoM_2014.nc |
            ../om/Vwind_nam_3hourly_MAB_and_GoM_2015.nc

instead of three copies of these set of atmospheric forcing files.

Notice that some idealized applications may have a single file for all the forcing fields (say, atmospheric and tidal data). In such case, we just need to specify the same filename in both the TIDENAME and FRCNAME keywords. ROMS will read the fields that it needs in both cases.

• A new output NetCDF file (HARNAME keyword) is added to store the least-squared detiding harmonic coefficients when the AVERAGES_DETIDE option is activated:

   HARNAME == doppio_har.nc  \
              pioneer_har.nc \
              array_har.nc
  

  for a three-grid nested application. The time-accumulated harmonic coefficients no longer are written in the input tidal forcing NetCDF file because of nesting. We need a harmonics NetCDF for each nested grid. Even if the tidal forcing is applied to just the coarser file, the detiding is operated in all nested grids.

• Introduced switches LprocessTides and LprocessOBS to determine which nested grids need input tidal data and open boundary condition data. These switches are set in inp_par.F:

  !
  ! Determine the switch to process input open boundary conditions data.
  !
  ! In nesting applications, the lateral boundary conditions data is
  ! is needed only by the main coarser grid (RefineScale(ng)=0).
  !
        DO ng=1,Ngrids
          IF (.not.(RefinedGrid(ng).and.RefineScale(ng).gt.0)) THEN
            LprocessOBC(ng)=.TRUE.
          END IF
        END DO
  
  #if defined SSH_TIDES || defined UV_TIDES
  !
  ! Determine the switch to process input tidal forcing data.
  !
  ! In nesting applications, the tides are processed only by the main
  ! coarser grid (RefineScale(ng)=0) and the other grids get tidal
  ! forcing from the contact areas.
  !
        DO ng=1,Ngrids
          IF (.not.(RefinedGrid(ng).and.RefineScale(ng).gt.0)) THEN
            LprocessTides(ng)=.TRUE.
          END IF
        END DO
  #endif 
  

• Introduced C-preprocessing options LIMIT_VDIFF and LIMIT_VVISC to limit the upper values of vertical diffusion and vertical viscosity, respectively, computed from vertical mixing parameterizations (GLS_MIXING, LMD_MIXING, and MY25_MIXING). Sometimes, these parameterizations yield high mixing values under stable water column conditions, and the threshold variables Akt_limit and Akv_limit are used as an upper limiter. However, if the water column is unstable, high values of vertical mixing are needed to eliminate vertical static instability numerically. So, please use these limiters with caution. The standard input script ocean.in was modified to include these upper limiting values:

  ! Upper threshold values to limit vertical mixing coefficients computed
  ! from vertical mixing parameterizations. Although this is an engineering
  ! fix, the vertical mixing values inferred from ocean observations are
  ! rarely higher than this upper limit value.
  
    AKT_LIMIT == 1.0d-3 1.0d-3 ! m2/s
  
    AKV_LIMIT == 1.0d-3 ! m2/s
  

  For example, in gls_corstep.F we have:

  # if defined LIMIT_VDIFF || defined LIMIT_VVISC
  !
  ! Limit vertical mixing coefficients with the upper threshold value.
  ! This is an engineering fix, but it can be based on the fact that
  ! vertical mixing in the ocean from indirect observations are not
  ! higher than the threshold value.
  !
        DO k=0,N(ng)
  # ifdef LIMIT_VDIFF
          DO itrc=1,NAT
            Akt(i,j,k,itrc)=MIN(Akt_limit(itrc,ng), Akt(i,j,k,itrc))
          END DO
  # endif
  # ifdef LIMIT_VVISC
          Akv(i,j,k)=MIN(Akv_limit(ng), Akv(i,j,k))
  # endif
        END DO
  # endif
  

  My experience with the vertical mixing parameterizations is that often they yield high vertical diffusion/viscosity values in trouble spots. Usually, their values are from 3 to 4 orders of magnitude greater than those inferred from ocean observations. I have talked with various observationalists in meetings, and the consensus is that vertical diffusion/viscosity in the ocean rarely exceeds a nominal value of 0.001. I have been worry about this for years, and I mentioned it to Hans Burchard when he visited us several years ago. Apparently, the turbulence algorithm goes unstable. I suspected that this was due to the nonlinear 3D advection of turbulent state variables. Hans mentioned that they rarely activate 3D advection in GOTM (General Ocean Turbulence Model). I tried to turn off the 3D advection in the GLS with CPP options, but the model blow-up. I didn't spend much time debugging. It is still an item in my extensive priority list.

This update changed several files to improve the error handling in ROMS.

• The check error statements:

       IF (exit_flag.ne.NoError) RETURN 
  
       IF (status.ne.nf90_noerr) THEN
         ...
       END IF
  

  were changed to:

       IF (FoundError(exit_flag, NoError, __LINE__,                &
      &               __FILE__)) RETURN
  
       IF (FoundError(status, nf90_noerr, __LINE__,                &
      &               __FILE__)) THEN
         ...
       END IF
  

  The logical function FoundError was added to the string_mod module (ROMS/Utility/string.F):

       USE strings_mod, ONLY : FoundError
  
  

• The function FindError prints the line and source code where the error occurred, if any:

        FUNCTION FoundError (flag, NoErr, line, routine) RESULT (foundit)
  !
  !=======================================================================
  !                                                                      !
  !  This logical function checks ROMS execution flag against no-error   !
  !  code and issue a message if they are not equal.                     !
  !                                                                      !
  !  On Input:                                                           !
  !                                                                      !
  !     flag         ROMS execution flag (integer)                       !
  !     NoErr        No Error code (integer)                             !
  !     line         Calling model routine line (integer)                !
  !     routine      Calling model routine (string)                      !
  !                                                                      !
  !  On Output:                                                          !
  !                                                                      !
  !     foundit      The value of the result is TRUE/FALSE if the        !
  !                    execution flag is in error.                       !
  !                                                                      !
  !=======================================================================
  !
        USE mod_iounits,  ONLY : stdout
        USE mod_parallel, ONLY : Master
  
  !  Imported variable declarations.
  !
        integer, intent(in) :: flag, NoErr, line
  
        character (len=*), intent(in) :: routine
  !
  !  Local variable declarations.
  !
        logical :: foundit
        character (len=5) :: lstr
  !
  !-----------------------------------------------------------------------
  !  Scan array for requested string.
  !-----------------------------------------------------------------------
  !
        foundit=.FALSE.
        IF (flag.ne.NoErr) THEN
          foundit=.TRUE.
          IF (Master) THEN
            WRITE (lstr,'(i5)') line
            WRITE (stdout,10) flag, ADJUSTL(TRIM(lstr)), TRIM(routine)
    10      FORMAT (' Found Error: ', i2.2, t20, 'Line: ', a,             &
       &            t35, 'Source: ', a)
          END IF
        END IF
  
        RETURN
        END FUNCTION FoundError
  

• I used a Perl script to make this substitution in the entire code. We get more information for error, for example:

  NETCDF_PUT_FVAR_1D - error while writing variable:  tide_period
                       in input file:  r10/doppio_har.nc
                       call from:  ROMS/Utility/wrt_tides.F
  
   Found Error: 03   Line: 93       Source: ROMS/Utility/wrt_tides.F
  
   ERROR: Abnormal termination: NetCDF OUTPUT.
   REASON: NetCDF: Variable not found
  

  Notice that the line number is in the original *.F code instead of the compiled file *.f90 because we are using the __LINE__ and __FILE__ C-preprocessing macros that operate in the original source code.

Introduction

I have been working for few month on completely rewriting the multi-model coupling using the ESMF (Earth System Modeling Framework) library with the NUOPC (National Unified Operational Prediction Capability) layer. The NUOPC Layer is a simplified infrastructure on top of the ESMF library (version 7 or higher) that provides conventions and templates to facilitate the smooth coupling between Earth System Models (ESMs).

The ESMF/NUOPC coupling algorithms in ROMS allow both driver and component modes of operation. In the driver mode, ROMS provides all the interfaces needed to couple to other ESM components including the main driver, NUOPC-based generic ESM component services, model gridded components or NUOPC Model cap files, connectors between components for re-gridding source and destination fields, and input scripts and coupling metadata management. The NUOPC Model cap is a Fortran module layer that sits on top of the ESM component, making calls into it (initialize, run, and finalize phases). Alternatively, in the component mode, the NUOPC ROMS cap module is provided which can be adapted and incorporated into other NUOPC-based coupling systems.

The current design of the ROMS native driver mode includes seven ESM components: (i) Ocean Model, (ii) Atmosphere Model, (iii) Sea Ice model, (iv) Wave Model, (v) Ocean Boundary Model (vi) Estuary Model, and (vii) Data Model. Currently, the following cap files are in various staged of development:

• Ocean Model: ROMS
• Atmosphere Models: COAMPS, RegCM, WRF
• Sea Ice Model: CICE
• Waves Models: SWAN, WAM, WaveWatch III
• Ocean Boundary Model: To be determined
• Estuary Model: ADCIRC, or other storn surge models

The Data Model is used to provide coupling data to the atmospheric model at locations not covered by the other ESM components because of smaller grid coverage. For example, if the atmosphere and ocean model grids do not have the same area coverage, the atmosphere model still needs to import sea surface temperature (SST) on those grid points not covered by the ocean model. In the future, CICE will need a data connection for when just coupled to ROMS.

Phase I

In Phase I, several minor changes are done to ROMS to facilitate synchronization between all the svn branches:

• The C-preprocessing options AIR_OCEAN and WAVES_OCEAN are renamed to ATM_COUPLING and WAV_COUPLING, respectively.

• Several new C-preprocessing options are introduced for coupling to various ESM components: CICE_COUPLING, COAMPS_COUPLING, REGCM_COUPLING, SWAN_COUPLING, WAM_COUPLING, and more to come.

• The following files are renamed:

  svn mv Master/mct_coupler.h Master/mct_driver.h
  svn mv Master/ocean_coupler.F Master/mct_coupler.h
  svn mv Master/esmf_coupler.h Master/esmf_coupler.h
  svn mv ROMS/External/coupling.dat ROMS/External/coupling_mct.dat
  svn mv ROMS/Utility/inquire.F ROMS/Utility/inquiry.F
  

  The first two needs to be done in that particular order. We cannot use the inquire subroutine name because it is an intrinsic Fortran function. I missed that one.

• The COUPLING_INTERP option is added to allow time interpolation between coupling fields to the case that the time exchange window is long. The two-snapshots arrays are used to store the imported data. As consequence, very tricky CPP logic in needed in set_data.F. Please do not change that logic. It 's hard to figure it out.

• All the compilation configuration files (Compilers/*.mk) were updated to include the newer ESMF compiling logic.

• Warning: the globaldefs.h was modified to include new CPP options for coupling.

I am not ready to release the full coupling algorithms. There are still developments ahead and testing.