Version 4 (modified by vichi, 9 years ago) (diff)

Last edited Timestamp?

Author : Marcello Vichi

ticket : #846

Branch : dev_r2784_CMCC1_topbfm


Branch to develop a common interface for other biogeochemical models not included in the TOP directory. The idea is to provide an as much as possible seamless interface for more complex biogeochemical models that do not fit into the TOP MY_TRC framework. This will consider the development done by CMCC, Met Office? (Karen Edwards) and NCOF-PML (Momme Butenschoen) integrating with the existing TOP interface.

Current state

Currently, BGC models are resolved within the SMS part (trcsms.F0) and that the transport (trc_trp) and output (trc_wri, trc_dia and trc_rst) is done identically for each model , assuming that all the memory layout is provided by NEMO through the tra and trn arrays and the number of passive tracers jptra. This is a good solution for models that are developed within NEMO but does not fit well with more complex biogeochemical models that are also used with other OGCMs. This is the case for the BFM, which has a wide growing community of users and therefore has an independent development with a specific coding structure. For models like the BFM (CMCC and INGV) and ERSEM (Met Office? and NERC) the common solution (independently developed) was to add an alternative set of routines for stepping and output

This is an excerpt from a modified trcstp.F90 for the BFM case

#if defined key_bfm
   ! Check the main BFM flag

         CALL trc_bfm( kt )           ! main call to BFM

         CALL trc_trp_bfm( kt )       ! transport of BFM tracers

         CALL trc_dia_bfm( kt )       ! diagnostic output for BFM



         tra(:,:,:,:) = 0.e0
         IF( kt == nit000 .AND. lk_trdmld_trc  )  &
            &                      CALL trd_mld_trc_init        ! trends: Mixed-layer
                                   CALL trc_rst_opn( kt )       ! Open tracer restart file 
         IF( lk_iomput ) THEN  ;   CALL trc_wri( kt )           ! output of passive tracers
         ELSE                  ;   CALL trc_dia( kt )
                                   CALL trc_sms( kt )           ! tracers: sink and source
                                   CALL trc_trp( kt )           ! transport of passive tracers
         IF( kt == nit000 )     CALL iom_close( numrtr )     ! close input  passive tracers restart file
         IF( lrst_trc )            CALL trc_rst_wri( kt )       ! write tracer restart file
         IF( lk_trdmld_trc  )      CALL trd_mld_trc( kt )       ! trends: Mixed-layer

Actually Met Office? is currently using a hybrid approach mixing the standard SMS approach with a specific key.


To accommodate this kind of models it is required to add flexibility to the code, like allowing the possibility to not use the output/restart facilities of NEMO and to have different combinations of transport schemes. The major issue here is the loop over the number of tracers, which is not possible within the my_trc framework and therefore requires another tracer stepping scheme. It is indeed possible to use trn(tra) with more complex models (Karen is doing this with ERSEM, while NERC/PML is not). However, this is not likely with the BFM as it allows to define the number of variables dynamically and it builds its own structure separately with specific input/output routines. Another issue is that it is important to keep the sedimentation rates separated from vertical advection as MPDATA schemes are not mass conserving. I think we can work out a common solution within the framework of my_trc, although I would propose to have an extended my_trc that allows more flexibility. Whether to achieve this through additional logical flags or by means of macros is a matter of discussion. I guess we all agree that it makes no sense to have a different key for each new model, though we also need to realize that we'll have to accommodate two different coupling strategies, one for SMS models and one for "ecosystem" models (which may also incorporate benthic systems like the ones we use now).

One (very) simple solution is to have only an additional key to accommodate any BGC model that does not use at all the NEMO memory structure and facilities. This would only involve two changes in the NEMO code, during the initialization step and during the time stepping


The strategy is open for discussion because it is not urgent matter in the 2011 work plan, but it is important that we find a common way forward that will maximize all development efforts and the research carried on by the community of ecosystem modelling.


On the dev branch we have now committed the method we currently use and that has to be modified. It is just a placeholder for the status quo at CMCC and very similar to NERC and Met Office?.


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

NVTK Tested'''YES/NO'''
Other model configurations'''YES/NO'''
Processor configurations tested[ Enter processor configs tested here ]
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'

  • Processor configurations tested
  • etc——

Bit Comparability

Does this change preserve answers in your tested standard configurations (to the last bit) ?'''YES/NO '''
Does this change bit compare across various processor configurations. (1xM, Nx1 and MxN are recommended)'''YES/NO'''
Is this change expected to preserve answers in all possible model configurations?'''YES/NO'''
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/NO '''
Does your change require a change in compiler options?'''YES/NO '''

If any of these apply, please document the changes required here…….


''Please ''summarize'' any changes in runtime or memory use caused by this change……''

IPR issues

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

Attachments (1)

Download all attachments as: .zip