ROMS 3.1 Released

ROMS Code Release Announcements

Moderators: arango, robertson

Post Reply
Message
Author
User avatar
arango
Site Admin
Posts: 1367
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:
Contact arango

ROMS 3.1 Released

#1 Unread post by arango »

ROMS/TOMS 3.1 Tagged, 3.2 Released

The latest version of the :arrow: ROMS/TOMS svn repository, revision 166, was frozen and tagged as ROMS 3.1. This version is quite stable. Then, the trunk was updated with the newest version of the code that includes the nesting and ESMF infrastructure. This version will be referred as ROMS/TOMS 3.2 in the future. The update is incremental due to the complexity of multi-grid nesting. However, a lot of files were modified as explained below.

We already have a nesting prototype working but it still needs work. However, nesting is not available yet. We will let know when you can use nesting. There are still more changes to come. Many thanks to John Warner for his help in developing and testing this capability. This version also includes the ESMF drivers for ROMS. Many thanks to the ESMF group (Cecelia Deluca, Gerhard Theurich, and collaborators) for their help. This version works with any ESMF library, version 3.x or higher. More changes are planned for the multi-model coupling. We are now working on the interpolation routines and waiting for ESMF to allow curvilinear grids remaping.

As shown below, three types of multiple grid nesting are possible in ROMS: refined (top diagram), mosaic (lower left diagram), and composite (lower right diagram) grids.

Image

The details of the connectivity between grids are shown and discussed in :arrow: WikiROMS. The contact area strategy is similar to that used in periodic boundary conditions. The computational stencil is expanded to evaluate the horizontal fluxes at the contact boundary points which are needed to evaluate the state variables at the boundary correctly. Only the state variables are interpolated at the contact areas. The secondary variables are computed using the new IstrT, IendT, JstrT, and JendT indices. For example, the potential temperature and sality is interpolated between grids in the contact areas but not the density. The density is computed from the interpolants in rho_eos.F over the extended horizontal ranges.

What is New:

(*) The lower and upper bound indices per domain partitions for all nested grids are stored in the array structure BOUNDS declared in mod_param.F. These values are now are accessed from the include file set_bounds.h, as follow:

Code: Select all

      Istr =BOUNDS(ng)%Istr (tile)
      IstrR=BOUNDS(ng)%IstrR(tile)
      IstrT=BOUNDS(ng)%IstrT(tile)
      IstrU=BOUNDS(ng)%IstrU(tile)
      Iend =BOUNDS(ng)%Iend (tile)
      IendR=BOUNDS(ng)%IendR(tile)
      IendT=BOUNDS(ng)%IendT(tile)

      Jstr =BOUNDS(ng)%Jstr (tile)
      JstrR=BOUNDS(ng)%JstrR(tile)
      JstrT=BOUNDS(ng)%JstrT(tile)
      JstrV=BOUNDS(ng)%JstrV(tile)
      Jend =BOUNDS(ng)%Jend (tile)
      JendR=BOUNDS(ng)%JendR(tile)
      JendT=BOUNDS(ng)%JendT(tile)
This array structure is allocated in inp_par.F after reading ROMS input script ocean.in. For example,

Code: Select all

     DO ng=1,Ngrids
        Ntiles=NtileI(ng)*NtileJ(ng)-1
        allocate ( BOUNDS(ng) % IstrR(-1:Ntiles) )
        ...
     END DO
The -1 array element is the value for the global grid and the rest are the values for each tile (0:Ntiles). These values are assigned in routines get_bounds, get_tile, and var_bounds. All these routines can be found in file get_bounds.F.

The indices IstrT, IendT, JstrT, JendT are used during nesting applications and include the overlap contact points between refined, mosaic, or composite grids. If not nesting, they are set to the same values as IstrR, IendR, JstrR, JendR, respectively.

(*) In the same fashion, the state array lower and upper bounds are available from the BOUNDS structure by including tile.h:

Code: Select all

      LBi=BOUNDS(ng)%LBi(tile)
      UBi=BOUNDS(ng)%UBi(tile)
      LBj=BOUNDS(ng)%LBj(tile)
      UBj=BOUNDS(ng)%UBj(tile)
(*) Consequently, the Istr, Iend, Jstr, Jend arguments for each tiled subroutine are replaced by the tile argument. For Example,

Code: Select all

  Old arguments:

      CALL omega_tile (ng, Istr, Iend, Jstr, Jend,                      &
     &                 LBi, UBi, LBj, UBj,                              &
     &                 ...)

  New arguments:

      CALL omega_tile (ng, tile,                                        &
     &                 LBi, UBi, LBj, UBj,                              &
     &                 ...)
If you are curious about this change, check the :arrow: difference in trac between old and new version of omega.F. As mentioned above, such values are now available the BOUNDS structure by including:

Code: Select all

# include "set_bounds.h"
This is an easy but a tedious change since involves mostly all the internal ROMS subroutines. This change will become more obvious in nested applications. Notice that this change also affects internal calls to boundary conditions, parallel exchanges, etc. For Example:

Code: Select all

  Old calls:

      CALL bc_**d_tile (ng, Istr, Iend, Jstr, Jend,                     &
     &                  LBi, UBi, LBj, UBj, ...)

      CALL exchange_**d_tile (ng, Istr, Iend, Jstr, Jend,               &
     &                        LBi, UBi, LBj, UBj, ...)

      CALL mp_exchange*d (ng, iNLM, *, Istr, Iend, Jstr, Jend,          &
     &                    LBi, UBi, LBj, UBj, ...)

  New calls:

      CALL bc_**d_tile (ng, tile,                                       &
     &                  LBi, UBi, LBj, UBj, ...)

      CALL exchange_**d_tile (ng, tile,                                 &
     &                        LBi, UBi, LBj, UBj, ...)

      CALL mp_exchange*d (ng, tile, iNLM, *,                            &
     &                    LBi, UBi, LBj, UBj, ...)

  In general,

      SUBROUTINE my_routine (ng, model, Istr, Iend, Jstr, Jend, ...)

  was changed to

      SUBROUTINE my_routine (ng, tile, model, ...)
This includes all the analytical routines in the Functionals directory. You need to modify your customized routines in your applications to follow the new arguments. If you are not sure what to do, please check the changes to that routine in the :arrow: changset list in trac and chick the (view diffs) link. The old code is in the left panel and the new code is the right panel.

(*) The initialize, run, and finalize routines are renamed in all drivers to ROMS_initialize, ROMS_run, and ROMS_finalize, respectively. This allows a differentiation between models when using the ESMF library. The routine ROMS_run has now two arguments Tstr and Tend indicating the number of time-steps to perform. This will be used for squential or concurrent coupling.

(*) An ESMF driver (Master/esmf_coupler.F) was added to couple ROMS to other models. This driver uses the ESMF super-structure to control the flow of information between all models. However, volumetric coupling between ROMS and other models is very hard, if impossible, within the super-structure. We interacted with the ESMF developers group about this weakness in the ESMF library. Although, we understand why the super-structure was designed to allow old legacy codes, time clocks, and parallel synchronization points. Then, Gerhard Theurich developed the direct coupling capabilities within the ESMF library. This is available in ESMF library version 3.1.0p or higher. This implies that is possible to call the ESMF library inside ROMS (say, main3d.F) to allow volumetric coupling and avoid splitting ROMS into different phases because of the super-structure. This also facilitates ESMF usage in the adjoint-based algorithms in the future. This is only possible because the coarse-grained parallelization of ROMS. All the parallel synchronization points are located in main2d/main3d.

(*) The generic ESMF framework registration of the ROMS grided component can be found in Master/esmf_roms.F. This is a quite complex algorithm that took me several weeks to mature and test. It contains the entire ESMF set-up for ROMS with several public and private routines:

Code: Select all

      PUBLIC  :: ROMS_SetServices
      PUBLIC  :: ROMS_SetGridArrays
      PUBLIC  :: ROMS_SetStates
      PUBLIC  :: ROMS_SetClock

      PUBLIC  :: ROMS_GetImportData
      PUBLIC  :: ROMS_PutExportData
      PUBLIC  :: ROMS_PutGridData

      PRIVATE :: ROMS_SetInitialize
      PRIVATE :: ROMS_SetRun
      PRIVATE :: ROMS_SetFinalize
The structure of this algorithm is generic and very minimal, if none, changes are needed to import and export fields within ROMS. There is an additional module which declares all the new variables and structures needed for coupling. See file Modules/mod_coupler.F.

(*) The coupling.in script was changed substantially to allow generic coupling. The idea here is generalize the coupling from few input parameters instead of changing the complex coupling subroutines. Currently, the fields to export and import are:

Code: Select all

    Field   Export    Import

    NONE    -         -                 No field to import or export
    Pair    atmos     ocean             surface air pressure
    Tair    atmos     ocean             surface air temperature
    Hair    atmos     ocean             surface air relative humidity
    cloud   atmos     ocean             cloud fraction
    SWrad   atmos     ocean             shortwave radiation flux
    LWrad   atmos     ocean             longwave radiation flux
    rain    atmos     ocean             rain fall rate
    Uwind   atmos     ocean, waves      surface U-wind component
    Vwind   atmos     ocean, waves      surface V-wind component
    heat    atmos     ocean             surface net heat flux
    Ustr    atmos     ocean             surface U-momentum stress
    Vstr    atmos     ocean             surface V-momentum stress
    SST     ocean     atmos             sea surface temperature
    bath    ocean     waves             bathymetry
    SSH     ocean     waves             free-surface
    Ubar    ocean     waves             vertically integrated U-momentum
    Vbar    ocean     waves             vertically integrated V-momentum
    Wdir    waves     ocean             wind-induced wave direction
    Wamp    waves     ocean             wind-induced significat wave height
    Wlen    waves     ocean             wind-induced mean wavelength
    Wptop   waves     ocean             wind-induced surface wave period
    Wpbot   waves     ocean             wind-induced bottom wave period
    Wdiss   waves     ocean             wave dissipation
    Wbrk    waves     ocean             percent wave breaking
The metadata for the export and import fields is specified in file External/coupling.dat.

My next task is to unify the coupling between ESMF and MCT libraries. We plan to support both. Therefore, more changes are coming in your way.

Good luck with this new version... :)
Top
Post Reply

Return to “ROMS Releases”