Custom Query (986 matches)

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.

​github.com/myroms/roms/pull/33

A few routines were updated to allow compiling and running split 4D-Var with mixed precision.

The split 4D-Var algorithms (like RBL4DVAR_SPLIT) recommend the mixed precision approach to accelerate computations. The executing script (see submit_split_rbl4dvar.sh) uses multiple ROMS executables, which runs the outer loop in double precision (nonlinear background trajectory, prior) and single precision in the inner loops (tangent linear and adjoint minimization, increment phase).

In this update, several of the variables needed by the RPCG solver are declared in double precision to reduce the impact of rounding error and the convergence of the minimization algorithm (rpcg_lanczos.F) when computing dot-products and Ritz eigenvalues and eigenvectors.

We use the real(dp) to declare specific internal variables in such cases. For example, in rpcg_lanczos.F, we have:

!
!  Local variable declarations.
!
      logical :: Ltrans, Laug
!
      integer :: i, ic, j, iobs, ivec, Lscale, info
!
      real(dp) :: zbet, eps, preducv, preducy
      real(dp) :: Jopt, Jf, Jmod, Jdata, Jb, Jobs, Jact, cff
!
      real(dp), dimension(NinnLoop) :: zu, zgam, zfact, ztemp3
      real(dp), dimension(NinnLoop) :: ztemp1, ztemp2, zu1, zu2
      real(dp), dimension(NinnLoop) :: ztemp4
      real(dp), dimension(Ndatum(ng)+1) :: px, pgrad, zw, zt
      real(dp), dimension(Ndatum(ng)+1) :: zhv, zht, zd
      real(dp), dimension(Ninner,3) :: zwork
      real(dp), dimension(2*(NinnLoop-1)) :: work
      real(dp), dimension(Ninner,Ninner) :: zgv

Many thanks to Pariza Heidary (NOAA) and Julia Levin for bringing this to my attention.