Custom Query (964 matches)

• This update enhances the observation operator to allow the input NetCDF variable obs_depth to have the data vertical location specified as a negative value (depths in meters), a positive value (fractional vertical coordinate ranging from 1:N), or a combination of both conventions.

Recall that during initialization, the ROMS 4D-Var algorithm always processes obs_depth from the input observations NetCDF file. Then, it will update the obs_Zgrid variable with all depths in fractional vertical coordinates. The obs_Zgrid variable is used after initialization in the inner loops to facilitate the vertical interpolation of the TLM and ADM state at the observation locations.

Many thanks to Brian Powell for bringing this issue to my attention. Before, it only worked if the user selected a single convention for all the observations in the file (negative depths or positive vertical fractional coordinate).

• Updated extract_obs.F and ad_extract_obs.F to avoid rejecting observation depths above the center of the top vertical grid cell, k=N(g). Recall that ROMS vertical grid is staggered with 3D variables (u, v, T, S, ...) located at the center of the grid cell. Notice that W-type variable are located at the bottom and top of the grid cell.

Thus, now we have:

           ...
           Ztop=Adepth(i1,j1,N(ng))
           Zbot=Adepth(i1,j1,1    )
           IF (Zobs(iobs).ge.Ztop) THEN
             k1=N(ng)                         ! If shallower, assign to
             k2=N(ng)                         ! top grid cell. The
             r1=1.0_r8                        ! observation is located
             r2=0.0_r8                        ! on the upper cell half
             Zobs(iobs)=REAL(N(ng),r8)        ! above its middle depth.
           ELSE IF (Zbot.ge.Zobs(iobs)) THEN
             r1=0.0_r8                        ! If deeper, ignore.
             r2=0.0_r8
             ObsVetting(iobs)=0.0_r8
           ELSE
             ...

Many thanks to Brian Powell for bringing this issue to my attention. It is only relevant when processing vertical observations as negative depths in meters.

• Updated read_asspar.F and read_phypar.F to avoid a hanging-up in MPI application when find_file triggers an exit during ROMS configuration due to the wrong specification of input NetCDF files by the User.

• The obs_depth variable in the input observation NetCDF file can be specified as negative values in meters or nondimensional, positive, fractional vertical coordinates ranging from 1.0 to N, where N is the number of vertical levels. Recall that in ROMS level N is located next to sea-surface, as shown below:

• The observation operator was modified to allow both vertical location conventions (meters and fractional) in the variable obs_depth for specific data. Recall that in ROMS, the vertical grid locations are time-dependent due to the evolution of the free surface, which may include tidal forcing or not. Therefore, ROMS will interpolate from depths in meters to the fractional vertical coordinate when computing 4D-Var prior trajectory (background phase) at the observation locations in time and space. Then, the fractional vertical coordinates are written into the obs_Zgrid of the input observation NetCDF file. As a result, we always recommend making a copy of the input observation NetCDF before running a 4D-Var data assimilation cycle if you want to preserve the original file. However, notice that obs_Zgrid is only needed internally in ROMS by the tangent linear and adjoint kernels during the inner-loops minimization when processing the linearized observation operator, H(x).

• Surface observations are tricky. Therefore, we usually use the fractional vertical coordinate for SSH, SST, SSS, and HFR observations as obs_depth=N. However, notice that level N depth is located at the middle of the top grid cell, as shown above. All the ROMS state variables used in the data assimilation are vertically located at the grid cell center (finite volume sense), vertical RHO-point. Using zero as surface depth is problematic due to its floating-point bit representation. IEEE-754 allows positive and negative zero. The representation of zero using sign bit, biased exponent, and a fraction is subject to roundoff due to precision. There is not an absolute zero value in computers. Using negative depths for surface observations, say obs_depth=-0.005 m, it will be assigned a obs_Zgrid=N in the fractional coordinate because such depth is above the top grid cell middle depth.

• Minor changes are made to obs_depth.F and obs_write.F to allow both vertical location conventions in obs_depth NetCDF variable. Thanks to Brian Powell for bringing this issue to my attention and providing a test case to debug.

• The variables time and tdays are initialized to zero in mod_scalars.F to avoid segmentation faults in some computer during 4D-Var prior error phase. Such variables haven't been assigned yet in the prior error phase. We may get some unwanted Fortran error when calling time_string in get_state.F with an uninitialized time variable:

       CALL time_string (time(ng), time_code(ng))
  

  This issue was discovered in the ROMS-JEDI interface. The ctest command was failing when running the JEDI unit tests.

I implemented the astronomical Tide Generating Forces (TGF) in ROMS 2D and 3D pressure gradient routines. They are coded in terms of the equilibrium tide (ζeq), defined as the shape that the sea surface (m) would assume if it were motionless and in equilibrium with the TGF on a fluid plane (Arbic et al., 2018).

It is activated with the option TIDE_GENERATING_FORCES. It is restricted to spherical grids since we need (lon, lat) of every cell to compute the harmonic constituents parameters for the location of the Moon and Sun. We recommend activating this option in conjunction with boundary tidal forcing (SSH_TIDES and UV_TIDES).

Thanks to John Wilkin for writing the ​implementation documentation (including equations and harmonics) and the Matlab scripts to compute the equilibrium tide offline and examine the harmonic parameters. Basically, the pressure gradient terms are of the form:

-g (∂(ζ - ζeq))/∂x
-g (∂(ζ - ζeq))/∂y

where g is the acceleration due to gravity (m/s2), ζ is the surface elevation (m), and ζeq is the equilibrium tide (m).

During its implementation, I examined and tested the 3D and 2D pressure gradient algorithms in ROMS. I discovered a but in prsgrd32.h (activated with DJ_GRADPS). This issue is discussed in detail in ​following forum post.

Two new routines were added:

• ROMS/Utility/equilibrium_tide.F: module containing routines to compute the equilibrium tide (equilibrium_tide) at every timestep and the harmonic constituents parameters (harmonic_constituents) once during initialization. The equilibrium tide is save in state variable OCEAN(ng)%eq_tide.

• ROMS/Utility/tides_date.F: Routine to checkout the input time reference parameter TIDE_START, defined as the time of phase zero when preparing the input tidal boundary data NetCDF file specified in TIDENAME.

Currently, there are two ways to specify the tide_start ROMS variable in an application:

(1) Set the zero_phase_date variable in the input tidal forcing NetCDF file (recommended). It a floating-point variable of the form YYYYMMDD.dddd with the following NetCDF metadata:

variables:
        double zero_phase_date ;
                zero_phase_date:long_name = "tidal reference date for zero phase" ;
                zero_phase_date:units = "days as %Y%m%d.%f" ;
                zero_phase_date:C_format = "%13.4f" ;
                zero_phase_date:FORTRAN_format = "(f13.4)" ;

For example, if the tide reference date is 2005-01-01 12:00:00, the zero_phase_date = 20050101.5000:

data:

 zero_phase_date = 20060101.0000 ;

Again, it corresponds to the zero tidal phase when preparing the forcing NetCDF file from the tides dataset (say, OTPS).

Use script forcing/add_tide_date.m from the ROMS Matlab repository to add the zero_phase_date variable to your existing tidal forcing NetCDF file:

>> add_tide_date('my_frc_tides.nc', datenum(2006,1,1))

It is highly recommended to use this approach. If such a variable is found, the TIDE_START value will be overwritten.

Notice that it is possible to have different reference values for zero_phase_date and ROMS clock defined as seconds from reference date (standard input parameter TIME_REF). If ROMS variable time_ref is earlier than zero_phase_date, the frequencies (omega) to harmonic terms will be negative since they are computed as follows:

     tide_start = Rclock%tide_DateNumber(2) - Rclock%DateNumber(2))
     omega = 2 * pi * (time - tide_start) / Tperiod

Notice that tide_start (in seconds) is recomputed, and the value specified in the input standard file is ignored.

If the variable zero_phase_date is found, ROMS will report to standard output:

 TIDES_DATE - Checking tidal reference date for zero phase:
                zero_phase_date = 20060101.0000 (read from ../../../om/doppio_tide_7km.nc)
                tide_DateNumber =   732678.0000 (2006-01-01 00:00:00)
                old tide_start  =        0.0000 (days)
                new tide_start  =        0.0000 (days)

(2) The specify TIDE_START in the ROMS standard input file as days from the application reference time (TIME_REF) is used it the variable zero_phase_date is not found in the NetCDF file. In the input standard input file we have:

  TIDE_START =  0.0d0                      ! days
  TIME_REF   =  20060101.0d0               ! yyyymmdd.dd

Usually, tide_start = 0 implies that the zero-phase tidal forcing date is the same as the application reference date time_ref. ROMS does not know how to check if it is the case. Thus, it is assumed that the user was careful when configuring their application.

In this case, ROMS will report to standard output:

  TIDES_DATE - Checking tidal reference date for zero phase:
                 'zero_phase_date' variable not found in ../../../om/doppio_tide_7km.nc)
                 given tide_start  =        0.0000 (days)
                 tide_DateNumber   =   732678.0000 (2006-01-01 00:00:00)

This capability was also added to the ADM, TLM, and RPM pressure gradient routines. However, I noticed that it slows the 4D-Var algorithm convergence. I need to test in other applications.

I look forward to advanced users helping us test the TGF implementation in their tide forced applications.

Below are two figures that show the sea surface elevation in the center of the Gulf of Maine (top) and at the entrance of the Bay of Fundi (bottom). ROMS is configured with boundary tidal forcing, tide generating force, and inverted barometer effect in the pressure gradient.

As expected, the TGF makes very small corrections to the boundary tidal forcing. It implies that the tide boundary forcing is well calibrated for this application. Users will need to activate both tidal forcings (SSH_TIDES, UV_TIDES, TIDE_GENERATING_FORCES). The ATM_PRESS is activated for all solutions.

WARNINGS:

• All the standard input files (roms_*.in) in the repositories were modified to add the Lnodal input switch for the TGF harmonics:

  ! If tide generating forces, set switch (T/F) to apply an 18.6-year lunar
  ! nodal correction to equilibrium tide constituents.
  
        Lnodal =  T
  

• The file varinfo.dat was updated to include the zero_phase_date metadata:

  'zero_phase_date'                                  ! Input
    'tidal reference date for zero phase'
    'days as %Y%m%d.%f'                              ! YYYYMMDD.dddd
    'nulvar'
    'nulvar'
    'idTref'
    'nulvar'
    1.0d0
  

References:

Arbic, B.K., Garner, S.T., Hallberg, R.W. and Simmons, H.L., 2004: The accuracy of surface elevations in forward global barotropic and baroclinic tide models, Deep Sea Research Part II: Topical Studies in Oceanography, 51(25-26), pp. 3069-3101.

Arbic, B.K., Alford, M.H., Ansong, J.K., Buijsman, M.C., Ciotti, R.B., Farrar, J.T., Hallberg, R.W., Henze, C.E., Hill, C.N., Luecke, C.A. and Menemenlis, D., 2018: Primer on Global Internal Tide and Internal Gravity Wave Continuum Modeling in HYCOM and MITgcm. In: New Frontiers in Operational Oceanography, E. Chassignet, A. Pascual, J. Tintoré and J. Verron (Eds.), GODAE OceanView, 307-392, doi: 10.17125/gov2018.ch13

Doodson, A.T. and Warburg, H.D., 1941: Admiralty Manual of Tides. His Majesty’s Stationery Office, London, UK, 270 pp.

Egbert, G.D. and Ray, R.D., 2017: Tidal prediction, Journal of Marine Research, 75(3), pp.189-237.