Version 7 (modified by jchanut, 17 months ago) (diff)


Last edition: 12/09/19 19:48:06 by smueller

The PI is responsible to closely follow the progress of the action, and especially to contact NEMO project manager if the delay on preview (or review) are longer than the 2 weeks expected.

  1. Summary
  2. Preview
    1. Current implementation of tidal forcing
    2. Proposed addition of an alternative set of tidal component parameters
    3. Proposed combination of tide-related functionality into one module in a new source-code subdirectory OCE/TDE
    4. Previewer's comments
  3. Tests
  4. Review


This action aims to enhance the implementation of tidal forcing with the addition of an optional, alternative parameter set for the harmonic expansion of the tide potential and by converting a currently fixed coefficient into a configurable namelist parameter; this work has previously been implemented and tested by Nicolas Bruneau in a pre-4.0beta version of NEMO.

Further, this action aims to reduce the total number of modules related to tides (the current implementation comprises the modules sbctide, tideini, tide_mod, updtide, and bdytide) and to thereby somewhat simplify the current implementation of tidal forcing.

See ticket #2194.


Current implementation of tidal forcing

The current implementation of tide-related functionality is distributed across a number of files and there are intertwined dependencies across the tide-related modules. The current implementation of tidal forcing (tidal potential and forcing at open boundaries) comprises five modules (in separate files):

In addition, the parameters for the current set of selectable tidal constituents are supplied via an include file (source:/NEMO/trunk/src/OCE/SBC/tide.h90). Further, the computation of the surface pressure gradient (source:/NEMO/trunk/src/OCE/DYN/dynspg.F90 and source:NEMO/trunk/src/OCE/DYN/dynspg_ts.F90) with activated tidal potential as well as the harmonic analysis (module diaharm, source:/NEMO/trunk/src/OCE/DIA/diaharm.F90) call subroutines and access variables of the modules listed above.

Proposed addition of an alternative set of tidal component parameters

The proposed revision of the tidal-forcing functionality of NEMO allows for the possibility to apply tidal boundary conditions that are derived from the FES2014 version of the Global Tide FES data product, which provides tide elevations, currents and loadings for 34 tidal components ( It includes the addition of an alternative tidal-component parameter set that extends the currently available set of tidal components (19 components; source:/NEMO/trunk/src/OCE/SBC/tide.h90) to correspond to the full range of components available in the FES2014 data product.

The coefficients for the proposed new parameter set have already been compiled, and the coefficients relating to the equilibrium tide amplitudes of all components (including those of the 19 components available in the current model version) have newly been recomputed in a form that is compatible with the conventions used for the existing tidal forcing implementation.

Further, the proposed revision adds long-periodic components (if selected) to the tide potential that currently only comprises the selected diurnal and semidiurnal components.

For reproducibility of the current tidal forcing, a new namelist parameter, ln_tide_var, is proposed to permit the combined selection of tidal parameter set and variant of tide-potential computation; the proposed default is the revised parameter set and the inclusion of long-periodic tides in the tide-potential computation.

Proposed combination of tide-related functionality into one module in a new source-code subdirectory OCE/TDE

The basis of the proposed simplified and clarified tidal-forcing implementation is:

  • the merging of most of the current tide-related functionality from modules sbctide, tideini, and updtide into module tide_mod; and
  • the provision of an appropriate public interface in module tide_mod for access to module subroutines and data as required by other modules (sbctide, dynspg, dynspg_ts, bdytides, diaharm).

Further, specific proposed modifications of the tide-related code include:

  1. the addition of a new namelist parameter rn_love_number with a default value of 0.7 that replaces the hard-coded Love-number coefficient in subroutine tide_init_potential (currently in module sbctide);
  1. the renaming of the current namelist parameters that violate the namelist parameter naming convention (renaming of parameters rndttideramp and clname to rn_tide_ramp_dt and sn_tide_cnames, respectively);
  1. the replacement of the array Wave that contains parameters for all available tidal components by an array (tide_components) that is returned by a new reentrant initialisation subroutine (tide_init_components) and only contains the parameters for the selected components, thereby enabling the reading in of alternative tidal parameter databases with differing numbers of components, simplifying the implementation (the subsetting of the database using an array of selected indices, ntide, would no longer be required), and making it possible to reuse the initialisation subroutine (e.g., it can be used when a subroutine of module diaharm requests a list of harmonics parameters for a specific subset of tidal components, see item e below);
  1. the simplification of the internal representation of amplitudes, frequencies, and phases of the selected tidal components in the new public array tide_harmonics (for internal use as well as for external access of tidal harmonics information by module bdytides) that contains variables of a new type tide_harmonic,
   TYPE, PUBLIC :: tide_harmonic
      CHARACTER(LEN=4) :: name
      REAL(wp) :: f
      REAL(wp) :: omega
      REAL(wp) :: u
      REAL(wp) :: v
   END TYPE tide_harmonic,

and which replaces the arrays omega_tide, v0tide, utide, ftide (and additionally stores the names of the components; this feature would be used by subroutine tide_harmo, see item e, and module bdytides, see item i);

  1. the extension of subroutine tide_harmo of module tide_mod so that it optionally accepts an array of tidal-component names and, if called with such a list of names, returns a pointer to an array of elements of type tide_harmonic that have been filled with the tidal harmonic parameters for the respective components (this proposed development would make use of developments described in items c and d, and take into account the modification described in item g);
  1. the simplified daily synchronisation of the temporal tidal-forcing update in subroutine sbc_tide (module sbctide) using a single call to a new subroutine tide_update of module tide_mod (this proposed subroutine would include calls to subroutines tide_harmo and tide_init_potential and the output of tide-related information);
  1. the replacement of the use of variable nset_day by the value of an argument (passed via subroutine tide_harmo) in subroutine astronomic_angle (module tide_mod), in order to remove the dangerous temporary modification of nday_sec in module sbcmod;
  1. the modification of subroutine upd_tide, called in the computation of the surface pressure gradient, so that instead of kt and kt_tide only the time between midnight and the current (sub)timestep is required as argument (this makes the setting of kt_tide in module sbctide unnecessary); and
  1. in module bdytide, the replacement of references to variables Wave, ftide, omega, utide, and v0tide by references to components of variable tide_harmonics.

Previewer's comments

Looks good to me. Maybe an example of the new input format for tidal components would be welcome.


  • Clarify the use of complex conjugate in some places of the code. At least this option should be suppressed for boundary data files as it is a recurrent source of error.
  • Clean the bdytide module. There are useless routines. I think that one used to set tidal open boundary data at each barotropic time step, which made things more complex.


Once the development is done, the PI should complete the tests section below and after ask the reviewers to start their review.

This part should contain the detailed results of SETTE tests (restartability and reproducibility for each of the reference configuration) and detailed results of restartability and reproducibility when the option is activated on specified configurations used for this test

Regular checks:

  • Can this change be shown to produce expected impact (option activated)?
  • Can this change be shown to have a null impact (option not activated)?
  • Results of the required bit comparability tests been run: are there no differences when activating the development?
  • If some differences appear, is reason for the change valid/understood?
  • If some differences appear, is the impact as expected on model configurations?
  • Is this change expected to preserve all diagnostics?
  • If no, is reason for the change valid/understood?
  • Are there significant changes in run time/memory?


A successful review is needed to schedule the merge of this development into the future NEMO release during next Merge Party (usually in November).


  • Is the proposed methodology now implemented?
  • Are the code changes in agreement with the flowchart defined at preview step?
  • Are the code changes in agreement with list of routines and variables as proposed at preview step?
    If, not, are the discrepancies acceptable?
  • Is the in-line documentation accurate and sufficient?
  • Do the code changes comply with NEMO coding standards?
  • Is the development documented with sufficient details for others to understand the impact of the change?
  • Is the project literature (manual, guide, web, …) now updated or completed following the proposed summary in preview section?


Is the review fully successful? If not, please indicate what is still missing

Once review is successful, the development must be scheduled for merge during next Merge Party Meeting.