Version 1 (modified by lovato, 5 years ago) (diff)

Last edited Timestamp?


ticket : #1441

Branch : dev_r5144_CMCC5_BDY_for_TOP


This development deals with the implementation of BDY for biogeochemical models by following the TOP interface structures developed in 2014 activities to build a general coupling framework for NEMO.

The BDY for the passive tracers chiefly rely to the main BDY information computed within the OPA component (e.g., bdy coordinates, damping time scales, which is relevant for offline coupling!!) and it requires the specification of the following values in namtrc_bdy (contained in namelist_top_ref): cn_trc_dflt, it is the default boundary conditions used for all those tracers which are not driven by external data and automatically initialised from initial conditions; cn_trc it is the boundary condition to be applied when external data are provided for a specific tracer by setting llobc value to true in trcnam (see above example); nn_trcdmp_bdy, this integer flag control the use of damping for tracers at the open boundary, the following option are available:

0 = NO damping of tracers at open boundaries; 1 = Only for tracers forced with external data; 2 = Damping applied to all tracers

In addition to the BDY development, it was necessary to revise the structure of the generalised Boundary Conditions subroutines (trcbc.F90), and related namelists, for TOP component to become a comprehensive function for handling the different types of BCs (namely, SBC, CBC and OBC). This activity complements the one of Ticket #1143 and once that it is finalised both tickets has to be closed.

In the MY_TRC configuration, the NEMO/TOP_SRC/trc.F90 subroutine was modified such that the general PTRACERS data structure now contains also the logical fields to setup the reading of external data for surface (SBC), coastal (CBC), and open (OBC) boundary conditions (see details on trc.F90 changes). This also enables for a complete linkage of the BCs subroutines within my_trc configuration (see details in #1441). At the moment these fields are defined using the macro "key_my_trc", but I think they could become a static part of the code.


Testing could consider (where appropriate) other configurations in addition to SETTE].

SETTE Tested'''NO'''
Other model configurations'''YES'''
Processor configurations tested[ MFS: 23x16 ]
If adding new functionality please confirm that the
New code doesn't change results when it is switched off
and ''works'' when switched on

(Answering UNSURE is likely to generate further questions from reviewers.)

'Please add further summary details here'

  • The development was done with the Mediterranean Sea configuration (MFS)
  • As this add a new element to the dynamics of passive tracers obviously the results changes with respect to before. Switching off the BDY for TOP give the same results as before.

Bit Comparability

Does this change preserve answers in your tested standard configurations (to the last bit) ?'''YES '''
Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended)'''YES'''
Is this change expected to preserve answers in all possible model configurations?'''YES'''
Is this change expected to preserve all diagnostics?
,,''Preserving answers in model runs does not necessarily imply preserved diagnostics. ''

If you answered '''NO''' to any of the above, please provide further details:

  • Which routine(s) are causing the difference?
  • Why the changes are not protected by a logical switch or new section-version
  • What is needed to achieve regression with the previous model release (e.g. a regression branch, hand-edits etc). If this is not possible, explain why not.
  • What do you expect to see occur in the test harness jobs?
  • Which diagnostics have you altered and why have they changed?Please add details here……..

System Changes

Does your change alter namelists?'''YES '''
Does your change require a change in compiler options?''NO '''
  • namelist_top it is necessary to include the control for BDY and it was proposed a modification to generalise the application of boundary conditions (coastal, open, surface)


I haven't noticed any appreciable change in resources usage while testing, but certainly it will require some computational time.

IPR issues

Has the code been wholly (100%) produced by NEMO developers staff working exclusively on NEMO?'''YES'''