Custom Query (986 matches)

The ROMS and WRF NUOPC cap modules were updated to exchange surface current (Usur, Vsur) between ocean and atmosphere couple components.

We are currently using the WRF code from ​https://github.com/myroms, which we applied a couple of corrections to the code submitted to its developers and will appear in future releases. As before, there will be no need to patch WRF for each release version.

Test Case

The Hurricane IRENE application has a new test case in the IRENE/Coupling/data_wrf_roms_wmc subdirectory. For more details, please check the link to the roms_test repository inGitHub for detailed information and instructions:

​https://github.com/myroms/roms_test/blob/main/IRENE/Coupling/data_wrf_roms_wmc/Readme.md

The ROMS and WRF grids are incongruent in this test case. Since ROMS doesn't cover all the ocean points in the WRF grid (red domain below), a DATA component is used to supply such values from the 3-hour HyCOM dataset. ROMS and DATA components export surface ocean current at the cell center (RHO-points). Then, the ocean currents from DATA and ROMS are melded smoothly using the appropriate weights.

Surface Ocean U-velocity	Surface Ocean V-velocity

The meldes surface currents are imported by WRF into variables grid%uoce and grid%voce. We will continue exploring WRF internal parameters to study the effects of the surface currents on the winds and wind stress. As shown by Renault et al. (2016), the feedback from surface ocean currents to the atmosphere is an eddy-killing effect stabilizing the Gulf Stream separation at Cape Hatteras in WRF-ROMS fully coupled applications. The result is around 0.3 N/m² weaker surface wind stress in the core of the Gulf Stream.

The rotated wind variables, eastward and northward, were defined in output History and Quicksave NetCDF files but were not written. The input wind variables are rotated and averaged at RHO points when appropriate and requested in roms.in:

Hout(idUair) == T       ! Uwind              surface U-wind
Hout(idVair) == T       ! Vwind              surface V-wind
Hout(idUaiE) == T       ! Uwind_eastward     surface Eastward  U-wind
Hout(idVaiN) == T       ! Vwind_northward    surface Northward V-wind

...

Qout(idUair) == T       ! Uair               surface U-wind
Qout(idVair) == T       ! Vair               surface V-wind
Qout(idUaiE) == T       ! Uwind_eastward     surface Eastward  U-wind
Qout(idVaiN) == T       ! Vwind_northward    surface Northward V-wind

Many thanks, John Wilkin, for bringing this issue to my attention.

I developed a grid extraction capability into ROMS that is independent of nesting, which can be activated with the GRID_EXTRACT option. This capability allows the creation of a new NetCDF file (XTRNAME) containing the extracted fields via decimation or horizontal interpolation, level-by-level, in 3D fields.

The ROMS standard input script roms.in includes new parameters:

! Input grid extraction flag and input extraction grid geometry
! NetCDF filename. They are used to extract a history solution at
! the desired geometry by decimation or horizontal interpolation:
!
!   ExtractFlag = 1                 horizontal interpolation
!   ExtractFlag > 1                 coarsening by decimation
!
! If decimation, ExtracTFlag is the sampling factor. For now, use
! ExtractFlag=2 so data is written at every other point. Notice
! that it is required to satisfy the following criteria:
!
!   MOD(Lm+1, ExtractFlag) = 0                                      
!   MOD(Mm+1, ExtractFlag) = 0

 ExtractFlag == 2
     GRXNAME == ../Data/lake_decimate_grd_2km.nc

...

     XTRNAME == lake_decimate_xtr.nc

The users must provide the extraction fields geometry grid NetCDF file GRXNAME at the input. This grid needs to be created with tools similar to the parent ROMS application grid and contained inside.

• If ExtractFlag = 1: Level-by-level horizontal interpolation. The development of extracted grids with land/sea masks is still under development, complicating the interpolation. We are developing a generic ESMF grid-to-grid remapping inside of ROMS.

• If ExtractFlag > 1: Decimation. It decimates the field solution at the prescribed integer factor, ExtractFlag . For example, if !Extract_Flag=2 (recommended), the output fields are written at every other point, resulting in coarser data resolution. This strategy is advantageous in mixed resolution, split 4D-Var applications where the outer loop background (prior) trajectory may be computed at a higher resolution than in the inner loop minimization to accelerate the calculations. For decimation to work, the number of parent grid RHO-points (0: Lm+1, 0:Mm+1) must be multiples of ExtractFlag. That is,

       MOD(Lm(ng)+1, ExtractFlag) = 0                                      
       MOD(Mm(ng)+1, ExtractFlag) = 0
  

For debugging and testing, a new idealized test case, LAKE_DECIMATE, at 1km resolution (360x300x20), is introduced.