Custom Query (964 matches)

Added the capability to output of 2D/3D momentum components in the geographical eastward (TRUE East, positive) and northward (TRUE North, positive) directions at the center of the grid cell (RHO-points).

The vector components are averaged to RHO-points and then rotated from (XI,ETA) coordinates to true (East,North) directions, if applicable:

    Urho = 0.5_r8 * (Uinp(i,j,:) + Uinp(i+1,j,:))
    Vrho = 0.5_r8 * (Vinp(i,j,:) + Vinp(i,j+1,:))
    
    Uout = Urho * COS(angler(:,:)) - Vrho * SIN(angler(:,:))
    Vout = Vrho * COS(angler(:,:)) + Urho * SIN(angler(:,:))

Notice that if angler=0, no rotation is carried since COS(0)=1 and SIN(0)=0. Here, angler is the grid rotation angle with respect to the XI-axis.

A new parallel routine, ROMS/Nonlinear/uv_rotate.F, is introduced to process (Eastward,Northward) vector components. At the present, only the 2D momentum components (ubar,vbar) and 3D momentum components (u,v) are processed for history, time-averaged, and stations NetCDF files. The resulting vector components are averaged at RHO-points (grid cell center). The values are only viable at the interior RHO-points. However, the output data has the same dimensions as any output RHO-field (h, zeta, tracers). The values in the one-point halo region are set to zero. This is convenient for ROMS operational products and data on OpenDAP servers.

Recall that ROMS uses an Arakawa's staggered C-grid:

         psi --- v --- psi
          |             |
          u     rho     u
          |             |
         psi --- v --- psi

This is a numerical scheme to facilitate the natural discretization of the governing equations (momentum, tracers, continuity). It has nice numerical and physical properties. Notice that in the real world, velocity components are measured directly at the same point. Here, we make the assumption that this point is at the center of a particular grid cell in numerical discretizations. This is convenient when processing data assimilation observations and model-data comparisons.

The metadata for the new variables are:

        double ubar_eastward(ocean_time, eta_rho, xi_rho) ;
                ubar_eastward:long_name = "eastward vertically integrated momentum component at RHO-points" ;
                ubar_eastward:units = "meter second-1" ;
                ubar_eastward:time = "ocean_time" ;
                ubar_eastward:coordinates = "x_rho y_rho ocean_time" ;

        double vbar_northward(ocean_time, eta_rho, xi_rho) ;
                vbar_northward:long_name = "northward vertically integrated momentum component at RHO-points" ;
                vbar_northward:units = "meter second-1" ;
                vbar_northward:time = "ocean_time" ;
                vbar_northward:coordinates = "x_rho y_rho ocean_time" ;


        double u_eastward(ocean_time, s_rho, eta_rho, xi_rho) ;
                u_eastward:long_name = "eastward momentum component at RHO-points" ;
                u_eastward:units = "meter second-1" ;
                u_eastward:time = "ocean_time" ;
                u_eastward:coordinates = "x_rho y_rho s_rho ocean_time" ;

        double v_northward(ocean_time, s_rho, eta_rho, xi_rho) ;
                v_northward:long_name = "northward momentum component at RHO-points" ;
                v_northward:units = "meter second-1" ;
                v_northward:time = "ocean_time" ;
                v_northward:coordinates = "x_rho y_rho s_rho ocean_time" ; 

Several new switches were added to input script ocean.in to specify the output of such history and time-averaged variables:

Hout(idu3dE) == T       ! u_eastward         3D U-eastward  at RHO-points
Hout(idv3dN) == T       ! v_northward        3D V-northward at RHO-points

Hout(idu2dE) == T       ! ubar_eastward      2D U-eastward  at RHO-points
Hout(idv2dN) == T       ! vbar_northward     2D V-northward at RHO-points

...

Aout(idu3dE) == T       ! u_eastward         3D U-eastward  at RHO-points
Aout(idv3dN) == T       ! v_northward        3D V-northward at RHO-points

Aout(idu2dE) == F       ! ubar_eastward      2D U-eastward  at RHO-points
Aout(idv2dN) == F       ! vbar_northward     2D V-northward at RHO-points

Similar switches are available in the input station script, stations.in:

Sout(idu3dE) == T       ! u_eastward         3D U-eastward at RHO-points
Sout(idv3dN) == T       ! v_northward        3D V-nortward at RHO-points

Sout(idu2dE) == T       ! ubar_eastward      2D U-eastward  at RHO-points
Sout(idv2dN) == T       ! vbar_northward     2D V-northward at RHO-points

WARNINGS:

• All standard input scripts ROMS/External/ocean*.in and User/External/ocean*.in were modified. Similarly, also all the stations*.in scripts were modified in the same directories.

• The metadata file ROMS/Exteran/varinfo.dat was modified to include the information about the new variables.

• All the input scripts in the test cases repository were also updated.

• In order for this to work, Users need to update the above files.

• This can be used only for output purposes. However, this kind of output data can be used when interpolating data to a down-scaling ROMS application.

Mark Hadfield ​reported a problem in the forum about a round-off problem in the time-stepping loop in main2d and main3d. As suggested, this loop is changed so the equality test is more robust:

      my_StepTime=0.0_r8
      MaxDT=MAXVAL(dt)

      STEP_LOOP : DO WHILE (my_StepTime.le.(RunInterval+0.5_r8*MaxDT))

        my_StepTime=my_StepTime+MaxDT

        ...

      END DO STEP_LOOP

Similar change is made to the TLM, RPM, and ADM versions of these routines. Many thanks to Mark for bringing this to my attention.

The ROMS makefile is very powerful and complex. All the ROMS algorithms are distributed in several sub-directories. Each sub-directory has it own library, which is used during the linking stage. We need to account for the circularity of these objects in the libraries. For instance, the ROMS/Utility codes (libUTIL.a) uses modules located in other sub-directories. Therefore, in the makefile we have the libUTIL.a at the beginning and near the end of the libraries list token. For example, in nonlinear model algorithms we have:

  libraries  := $(SCRATCH_DIR)/libUTIL.a
                $(SCRATCH_DIR)/libNLM.a
                $(SCRATCH_DIR)/libNLM_bio.a
                $(SCRATCH_DIR)/libNLM_sed.a
                $(SCRATCH_DIR)/libANA.a
                $(SCRATCH_DIR)/libUTIL.a
                $(SCRATCH_DIR)/libMODS.a

It turns out that with some compiler versions and computers operating systems we also need circularity in the modules token for the ROMS/Nonlinear directory modules:

 modules  +=    ROMS/Nonlinear \
                ROMS/Nonlinear/Biology \
                ROMS/Nonlinear/Sediment \
                ROMS/Functionals \
                ROMS/Utility \
                ROMS/Nonlinear \
                ROMS/Modules

Many thanks to Özgür Gürses for ​reporting this problem and to Kate for providing a family.