Custom Query (964 matches)
Results (895 - 897 of 964)
Ticket | Owner | Reporter | Resolution | Summary |
---|---|---|---|---|
#888 | Done | VERY IMPORTANT: Model Coupling with the ESMF/NUOPC Library | ||
Description |
I have been developing the coupling with the Earth System Modeling Framework (ESMF) library with the National Unified Operational Prediction Capability (NUOPC) layer for a while. It was challenging to code the coupling infrastructure from scratch. It took lots of debugging. For more information about this development, check WikiROMS. We will continue expanding the online documentation. Currently, the ROMS coupling ESMF/NUOPC interface can be illustrated with the following diagram. It includes four distinct compartments: Driver, Model Components, Coupler, and Connectors. Righ now, we are considering five classes of coupled Earth System Model (ESM) components: ROMS, ATM, DATA, SEA-ICE, and WAVE models. There is a Fortran module that sits on of each ESM component and referred as the NUOPC cap file. It is a Fortran code layer making calls to the ESM numerical kernel via the initialize, run, and finalize phases
There is a separate cap file for each coupled ESM component, which, from the ROMS perspective, corresponds to the atmosphere, sea-ice, wave, data models. Therefore, it is an abstract block that allows ROMS to communicate and exchange data seamlessly within the ESMF/NUOPC framework. The ROMS and other ESM components grids may (and usually do) have a different geographical extent and horizontal resolution. So if, for example, the atmosphere component domain is larger than the ROMS domain, it is necessary to provide data from another source to the atmosphere model at all surface grid points outside the ROMS domain. Therefore, a DATA component and its cap file are also required for most applications. In this case, SST is exported from ROMS and DATA to the atmosphere component, which imports the regridded values and then melds both SST fields. The melding is computed as:
These weights are computed with the script coupling/wrf_weights.m of the ROMS Matlab repository. The design of the ROMS coupling interface with the ESMF/NUOPC library allows both driver and component modes of operation:
All the ESMF/NUOCP source codes are located in the Master sub-directory:
The ROMS cap file has the following routines: MODULE esmf_roms_mod ROMS_SetServices Sets entry points using NUPOC generic methods for initialize, run, and finalize kernel routines. ROMS_SetInitializeP1 Phase 1 initialization: advertise import and export fields long- and short names. ROMS_SetInitializeP2 Phase 2 initialization: Initializes solution, sets application grid arrays, and registers fields into import state and export state. ROMS_DataInit Exports fields during initialization or restart. ROMS_SetClock Sets calendar, start and stop times, and coupling interval. ROMS_SetRunClock Sets ROMS run clock manually. ROMS_CheckImport Checks if the import field is at the correct time. ROMS_SetGridArrays Sets staggered, horizontal grid arrays, grid area, and land/sea masks. ROMS_SetStates Realize fields into import and export states by allocating and initializing pointers. ROMS_ModelAdvance Advances kernel for a coupling interval and calls import and export routines. ROMS_SetFinalize Finalizes execution. ROMS_Import Imports fields from other connected components. ROMS_Export Exports fields to other connected components MODULE esmf_roms_mod The ESMF RunSequence configuration file sets how the ESM components are connected and coupled. All the components interact with the same or different coupling time step. Usually, the connector from ROMS to ATM is explicit, whereas the connector from ATM to ROMS is semi-implicit. Often, the timestep of the atmosphere kernel is smaller than that for the ocean. Therefore, it is advantageous for the ATM model to export time-averaged fields over the coupling interval, which is the same as the ROMS timestep. It is semi-implicit because ROMS right-hand-side terms are forced with n+1/2 ATM fields because of the time-averaging. The following diagram shows the explicit and semi-implicit coupling for a DATA-ATM-ROMS system: For example, in the Hurricane Irene application, we have: runSeq:: @* # timeStep = wildcard (*), single time loop DATA -> WRF # DATA to WRF connector, step (1) DATA ROMS -> WRF # ROMS to WRF connector, step (2) WRF # step (3) WRF -> ROMS # WRF to ROMS connector, step (4) ROMS # step (5) @ :: The test repository is updated to include the Hurricane Irene Test Case. We have the following directory structure for this test: test/IRENE /Data /FRC /HyCOM /NRM /OBS /ROMS /STD /WPS /WRF /Coupling /Coupled_RBL4DVAR /Forward
Check WikiROMS for detailed information about Hurricane Irene Test Case configurations and different execution flavors in the Forward, Coupling, and Coupled_RBL4DVAR sub-directories. Many thanks to my collaborators John Wilkin, Julia Levin, Travis Miles, David Robertson, and Joseph Brodie at Rutgers for helping me with several aspects of the configuration and testing of this complex test case. Special thanks to David Robertson for his herculean task of fixing and modernizing COAMPS to compile with aggressive compiler flags for debugging. Also, for his software management skills to compile, link and maintain all these libraries. It requires patience, expertise, and experience! Many thanks to our colleagues at NRL-Monterrey for their help with COAMPS. Finally, many thanks to my colleague Ufuk Turuncoglu for his help with the ESMF/NUOPC coding strategies. This system is inspired by his RegESM system. This work was funded by the Office of Naval Research (ONR) and the National Oceanic and Atmospheric Administration (NOAA). |
|||
#889 | Fixed | Added missing subroutine arguments for def_tides.F and wrt_tides.F | ||
Description |
|
|||
#890 | Done | Important: Updated ROMS interpolation Object | ||
Description |
The interpolation module inside interpolate.F is renamed to roms_interpolate_mod to differentiate with other interpolation objects inside JEDI. It now includes the following overloading routines: INTERFACE roms_datum_interp MODULE PROCEDURE roms_datum_interp_2d MODULE PROCEDURE roms_datum_interp_3d MODULE PROCEDURE roms_datum_column_interp END INTERFACE roms_datum_interp ! INTERFACE roms_horiz_interp MODULE PROCEDURE roms_horiz_interp_2d MODULE PROCEDURE roms_horiz_interp_3d END INTERFACE roms_horiz_interp All these overloading routines use the roms_interp_type object structure, say S, for the ROMS-JEDI interface. In the future, it can be used for regridding inside ROMS. They can be used in different ways:
It also includes managing routines for the "roms_interp_type" object.
The adjoint of the interpolation object still needs to be coded when the design of the interpolation object is final. Currently, the interpolation object has the following declarations: TYPE :: roms_interp_type logical :: rectangular = .FALSE. ! plaid grid switch ! integer :: ng ! nested grid number integer :: model ! model identifier ! real(r8):: spval ! unbounded value ! ! Source grid array declaration bounds, tile partition range, ! longitude/latitude, curvilinear angle, and land/sea mask ! integer :: LBi_src, UBi_src, LBj_src, UBj_src integer :: Istr_src, Iend_src, Jstr_src, Jend_src ! real(r8) :: min_src, max_src ! real(r8), allocatable :: lon_src(:,:) real(r8), allocatable :: lat_src(:,:) real(r8), allocatable :: angle_src(:,:) real(r8), allocatable :: mask_src(:,:) ! ! Destination grid array declaration bounds, tile partition range, ! longitude/latitude, fractional coordinates, and land/sea mask. ! integer :: LBi_dst, UBi_dst, LBj_dst, UBj_dst integer :: Istr_dst, Iend_dst, Jstr_dst, Jend_dst ! real(r8) :: min_dst, max_dst ! real(r8), allocatable :: lon_dst(:,:) real(r8), allocatable :: lat_dst(:,:) real(r8), allocatable :: mask_dst(:,:) real(r8), allocatable :: x_dst(:,:) real(r8), allocatable :: y_dst(:,:) END TYPE roms_interp_type It can be easily converted to a Fortran 2003 CLASS object by incorporating the interpolation and managing routines. |