The GIT repository was modified to include the correct information about SVN properties (URL, revision, and modification date) along with with the GIT properties for URL and commit hash.

Both the SVN and GIT trunks are identical except for the makefile and ROMS/Version which have a couple of extra commands.

For example, the ROMS standard output will include repository and revision information:

 GIT Root URL     : https://www.myroms.org/git/src
 GIT Revision     : 2f07d7f23c47cb2a2364ff8b653addd1ebd0c699
 SVN Root URL     : https://www.myroms.org/svn/src/trunk
 SVN Revision     : 967

And the output NetCDF files global attributes will include:

                :git_url = "https://www.myroms.org/git/src" ;
                :git_rev = "2f07d7f23c47cb2a2364ff8b653addd1ebd0c699" ;
                :svn_url = "https://www.myroms.org/svn/src/trunk" ;
                :svn_rev = "967" ;

Warning:

• If you are downloading the source code from the GIT repository for the first time, you need to execute the following command after cloning (git clone https://joe_roms@www.myroms.org/git/src MyDir) from inside your chosen MyDir for ROMS code to activate the updating of the git hash properties in each file:

  git config filter.id.smudge ".git_filters/id.smudge %f"
  

• If you already downloaded the code from the GIT repository, you need to execute a git pull to update your repository, and then issue:

  git config filter.id.smudge ".git_filters/id.smudge %f"
  

The activation of the above instructions for the hash property needs to be done only once.

For more information, check ​WikiROMS.

Added a new driver obs_sen_w4dpsas_forecast.h for computing observation impacts for the analysis-forecast cycle. It is activated with C-preprocessing option W4DPSAS_FCT_SENSITIVITY. It basically computes the impacts of each observation on the forecast error.

Added the tangent linear (tl_rpcg_lanczos.F) and adjoint (ad_rpcg_lanczos.F) versions of the Restricted B-preconditioned Conjugate Gradient Lanczos algorithm (known as RBLanczos or RPCG) used the 4D-Var dual formulation.

The following diagram is used to explain the forecast cycle observations impacts: For more information, check the following WikiROMS ​page. The red and blue curves show the typical configuration for the algorithm computing the analysis-forecast cycle observation impacts.

The observation impacts can be forced at the model grid points, defining the desired metrics or at the observation locations when OBS_SPACE is activated additionally.

WARNINGS:

Both the roms.in and s4dvar.in scripts were modified to add new parameters needed in them analysis-forecast cycle observation impacts configuration:

• In ocean.in, we have:

  ! Number of timesteps for computing observation impacts during the
  ! analysis-forecast cycle.
  
    NTIMES_ANA == 1440                               ! analysis interval
    NTIMES_FCT == 1440                               ! forecast interval
  
  ...
  
  ! Input adjoint forcing NetCDF filenames for computing observations
  ! impacts during the analysis-forecast cycle. If the forecast error
  ! metric is defined in state-space, then FOInameA and FOInameB should
  ! be regular adjoint forcing files just like ADSname. If the forecast
  ! error metric is defined in observation space (OBS_SPACE is activated)
  ! then the forecast is initialized OIFnameA and OIFnameB (specified in
  ! s4dva4.in input script) will have the structure of a 4D-Var observation
  ! file.
  
      FOInameA == roms_foi_a.nc
      FOInameB == roms_foi_b.nc
  
  ! Input NetCDF filenames for the forecasts initialized from the analysis
  ! of the current 4D-Var cycle (FCTnameA) and initialized from the analysis
  ! of the previous 4D-Var cycle (FCTnameB).
  
      FCTnameA == roms_fct_a.nc
      FCTnameB == roms_fct_b.nc
  

  Where NTIMES_ANA and NTIMES_FCT are the total number of timesteps to compute the observations-impacts interval during the analysis and forecast cycle, respectively, when W4DPSAS_FCT_SENSITIVITY is activated.

FOInameA and FOInameB are the input forcing NetCDF files at model grid points for computing the observation impact when the forecast is initialized with the 4D-Var analysis (red curve) or the 4D-Var background (blue curves), respectively. FCTnameA is the current 4D-Var analysis cycle (red curve) and FCTnameB is the previous 4D-Var analysis cycle (blue curve).

• In s4dvar.in, we have:

  ! Input forcing filenames at observation locations for computing observations
  ! impacts during the analysis-forecast cycle when the forecast is initialized
  ! with the 4D-Var analysis (OIFnameA) or the 4D-Var background (OIFnameB).
  
        OIFnameA == roms_oif_a.nc
        OIFnameB == roms_oif_b.nc
  

  were OIFnameA and OIFnameB are the input forcing NetCDF files at observation location for computing the observation impact when the forecast is initialized with the 4D-Var analysis (red curve) or the 4D-Var background (blue curves), respectively, when both W4DPSAS_FCT_SENSITIVITY and OBS_SPACE options are activates.

References:

Errico, R.M., 2007: Interpretations of an adjoint-derived observational impact measure, Tellus, 59A, 273-276.

Gelaro, R., Y. Zhu, R.M. Errico, 2007: Examination of various-order adjoint-based approximations of observation impact, Meteorologische Zeitschrift, 16, 685-692.

Langland, R.H. and N.Baker, 2004: Estimation of observation impact using the NRL atmospheric variational data assimilation adjoint system, Tellus, 56, 189-201.

Many thanks to Andy Moore for his help coding and testing this complex algorithm. There are involved technical description that will be published in the near feature with realistic applications.

• The pressure gradient routines prsgrd42.h and prsgrd44.h use the local variable dP, which is a conflict with the mod_kinds real_kind parameter dp used for double-precision for some selected variables when the solution is mostly in single precision.

Many thanks to Catherine Drinkorn for ​bringing this issue to my attention.

• Adjuted the initialization of the makefile macro libraries to take care of cyclic dependency. It fails in some computer operating system. Now, we have:

    libraries := $(SCRATCH_DIR)/libNLM.a $(SCRATCH_DIR)/libUTIL.a
  

Notice that we add first the dependency for libNLM.a. Many thanks to Bronwyn Cahill for reporting this problem and David Robertson for fixing it.