[[PageOutline]] Last edited [[Timestamp]] '''Author''' : Marcello Vichi '''[http://forge.ipsl.jussieu.fr/nemo/wiki/ticket ticket]''' : [http://forge.ipsl.jussieu.fr/nemo/ticket/665 #846] '''Branch''' : [https://forge.ipsl.jussieu.fr/nemo/browser/branches/2011/dev_r2784_CMCC1_topbfm dev_r2784_CMCC1_topbfm] ---- === Description === 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, MetOffice (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 (MetOffice 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 #else ... 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 ) ENDIF 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 MetOffice is currently using a hybrid approach mixing the standard SMS approach with a specific key. === Strategy === 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 (like key_obgcm, other biogeochemical model) 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 {{{ nemogcm.F90: ------------- #if defined key_top #if defined key_obgcm ! ! Other external biogeochemical model CALL trc_init_obgc #else ! ! Passive tracers CALL trc_init #endif #endif step.F90: --------- #if defined key_top #if defined key_obgcm !>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ! Passive Tracer Model !<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< CALL trc_stp_obgc( kstp ) ! time-stepping #else !>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ! Other Biogeochemical Model !<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< CALL trc_stp( kstp ) ! time-stepping #endif #endif }}} The routines trc_init_obgc and trc_stp_obgc are wrappers that have to be provided by the external model in its own directory structure and linked during compilation. We can also put an EXTERNAL statement in the code to clarify this. 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. === Status === 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 MetOffice. ---- === Testing === 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 [[BR]]New code doesn't change results when it is switched off [[BR]]and !''works!'' when switched on||!'''YES/NO/NA!'''|| (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? [[BR]]!,,!''Preserving answers in model runs does not necessarily imply preserved diagnostics. !''||!'''YES/NO!'''|| 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....... ---- === Resources === !''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 !'''||