#1441 closed Task (fixed)
BDY open boundaries for biogeochemistry (CMCC-5)
Reported by: | lovato | Owned by: | nemo |
---|---|---|---|
Priority: | low | Milestone: | 2014 WP postponed |
Component: | TOP | Version: | v3.6 |
Severity: | Keywords: | BDY | |
Cc: |
Description
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.
This development will be restarted from the current revision of the trunk for nemo 3.6 alpha.
More details in the CMCC work plan Actions for 2015 at CMCC 2015WP
The development branch is dev_r5037_CMCC5_BDY_for_TOP
Commit History (3)
Changeset | Author | Time | ChangeLog |
---|---|---|---|
6053 | lovato | 2015-12-15T15:50:11+01:00 | Merge branches/2015/dev_r5144_CMCC5_BDY_for_TOP (see ticket #1441) |
5160 | lovato | 2015-03-23T15:30:55+01:00 | First implementation of BDY for TOP component, see #1441 (dev_r5144_CMCC5_BDY_for_TOP). |
5041 | lovato | 2015-01-22T17:25:16+01:00 | Development branch CMCC5_BDY_for_TOP ticket #1441. |
Change History (10)
comment:1 Changed 10 years ago by lovato
comment:2 Changed 10 years ago by lovato
To test of new bdy for the TOP component using the regional configuration for the Mediterranean Sea,
we had to change the reference revision of this development in order to include recent updates
of the DOM subroutines to be able to compute the correct grid metrics and masks.
The new path for this development is dev_r5144_CMCC5_BDY_for_TOP
comment:3 Changed 10 years ago by lovato
A first implementation of BDY structure for the tracers of TOP component is made available
in branch dev_r5144_CMCC5_BDY_for_TOP at r5160 (with a revert of an erroneous change at r5161).
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 below).
In MY_TRC case, the namtrc will have the following structure:
!----------------------------------------------------------------------- &namtrc ! tracers definition !----------------------------------------------------------------------- ! ! name ! title of the field ! data ! initial data ! sbc ! cbc ! obc ! save ! ! ! ! ! units ! from file ! ! ! ! or not ! ! ! ! ! ! or not ! ! ! ! ! sn_tracer(1) = 'TRACER1 ' , 'Tracer1 for key_my_trc ', 'unitless' , .true. , .true. , .true. , .true. , .true. sn_tracer(2) = 'TRACER2 ' , 'Tracer2 for key_my_trc ', 'unitless' , .true. , .false. , .false. , .false. , .true. ln_trcdta = .true. ! Initialisation from data input file (T) or not (F) ln_trcdmp = .false. ! add a damping term (T) or not (F) /
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.
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.
!! GENERAL NOTE ON TOP !! a revision of the TOP component is likely needed as tracers general settings (number of tracers, diagnostics etc) are still defined in the fortran files and they should be moved into the top namelists, as done in other parts of NEMO.
An explanation of the changes and developments performed up to r5161 is given below:
CONFIG/SHARED/namelist_top_ref (1 diff)
Addition of the namtrc_bdy namelist to control tracers parameterization at OBC
As 3 different Boundary dataset are handled in namtrc_bc, it appeared useful to specifically declare the root directories for each one of them.
NEMO/OPA_SRC/BDY/bdy_oce.F90 (1 diff)
In the general data structure OBC_DATA, 4 specific fields for the TOP component were added to keep trace of the type of boundary condition (cn_obc), now field value of the tracer (trc), multiplicative scaling factor of external data (rn_fac), and the use of a damping term at obc (dmp).
NEMO/TOP_SRC/MY_TRC/trcsms_my_trc.F90 (2 diffs)
A call to the update subroutine of boundary conditions values was included (trc_bc_read) to partly complete the information flow in the my_trc configuration.
A WHERE statement filling values in the tracer array was removed as it seems to be a left over of previous coding.
NEMO/TOP_SRC/MY_TRC/trcwri_my_trc.F90 (1 diff)
The control on the output of the variables was added using the logical array ln_trc_wri that is defined in namtrc.
NEMO/TOP_SRC/TRP/trcdmp.F90 (1 diff)
The logical l_tradmp was erroneously modified and this change was corrected in r5161, by restoring the original variable.
NEMO/TOP_SRC/TRP/trcnxt.F90 (2 diffs)
Added the call to apply open boundary conditions to tracers (trc_bdy)
NEMO/TOP_SRC/TRP/trctrp.F90 (2 diffs)
Added the call for tracers damping at open boundaries (trc_bdy_dmp)
NEMO/TOP_SRC/trc.F90 (4 diffs)
The values form the namelist namtrc_bdy are declared and allocated.
In addition, the logical fields to control the use of the different boundary conditions are included in the structure of PTRACER, namely to control the use of external data for surface (llsbc), coastal (llcbc) and open (llobc) boundary data using the macro key_my_trc.
These logical are then used in trc_bc subroutine to initialize the external data reading and BDY conditions.
NEMO/TOP_SRC/trcbc.F90 (12 diffs)
A general rearrangement of the routine was performed to include also the initialisation and reading of Open Boundary Data.
Here tracers at bdy segments are initialised using initial conditions (IC) if no external data are provided, or linked as a pointer to the data structure of that tracer at the boundary (like in original bdy).
It was revised and updated also the log informations written in ocean.output
NEMO/TOP_SRC/trcbdy.F90
This module was derived from the one for active tracers (trabdy), with the exclusion of the runoff case. Note that the user defined scaling factor for external bdy data is performed in trc_bdy subroutine.
NEMO/TOP_SRC/trcdta.F90 (8 diffs)
A revision of the log information was done, since many control output were addressing to the module name instead of the subroutine.
NEMO/TOP_SRC/trcini.F90 (2 diffs)
A call to the initialisation of boundary conditions values was included (trc_bc_init) to partly complete
the information flow in the case of my_trc configuration.
NEMO/TOP_SRC/trcnam.F90 (5 diffs)
It was removed a duplicate log info written in ocean.output.
comment:4 Changed 9 years ago by cetlod
1 major comment :
1 - the idea was to avoid duplicates routines for BDY purpose. This implies the use of what have done for active tracers (trabdy) i.e slight modifications of bdytra module : put the number of tracers as an argument in the bdy routines ( jpts for T/S and jptra for passive tracers ) exactly in the same way than the advection/diffusion routines.
Typically, the trcbdy routine should look like :
SUBROUTINE trc_bdy( kt ) !!---------------------------------------------------------------------- !! *** SUBROUTINE trc_bdy *** !! !! ** Purpose : - Apply open boundary conditions for tracers in TOP component !! and scale the tracer data !! !!---------------------------------------------------------------------- INTEGER, INTENT( in ) :: kt ! Main time step counter !! INTEGER :: ib_bdy, jn ! Loop indeces !!---------------------------------------------------------------------- ! IF( nn_timing == 1 ) CALL timing_start('trc_bdy') ! DO ib_bdy=1, nb_bdy SELECT CASE( trcdta_bdy(jn,ib_bdy)%cn_obc ) CASE('none') CYCLE CASE('frs') CALL bdy_trc_frs( jn, idx_bdy(ib_bdy), trcdta_bdy(jn,ib_bdy), kt , jptra ) CASE('specified') CALL bdy_trc_spe( jn, idx_bdy(ib_bdy), trcdta_bdy(jn,ib_bdy), kt , jptra ) CASE('neumann') CALL bdy_trc_nmn( jn, idx_bdy(ib_bdy), trcdta_bdy(jn,ib_bdy), kt, jptra ) CASE('orlanski') CALL bdy_trc_orlanski( jn, idx_bdy(ib_bdy), trcdta_bdy(jn,ib_bdy), jptra, ll_npo=.false. ) CASE('orlanski_npo') CALL bdy_trc_orlanski( jn, idx_bdy(ib_bdy), trcdta_bdy(jn,ib_bdy), jptra, ll_npo=.true. ) CASE DEFAULT CALL ctl_stop( 'bdy_trc : unrecognised option for open boundaries for passive tracers ) END SELECT ! Boundary points should be updated CALL lbc_bdy_lnk( tra(:,:,:,jn), 'T', 1., ib_bdy ) ENDDO IF( nn_timing == 1 ) CALL timing_stop('trc_bdy') END SUBROUTINE trc_bdy
comment:5 Changed 9 years ago by gm
A remark on Christian's (cetlod) comment:
In terms of MPP efficiency, it should be great to modify lbc_bdy_lnk so that its call can be put outside the loop on the number of tracers:
END DO ! end of tracer loop CALL lbc_bdy_lnk( tra, 'T', 1., ib_bdy ) ! Boundary condition
and in lbc_bdy_lnk , only one phase of communication on all tracers.
This can be postpone to next year, but it should appear in the 2016 HPC shared actions
comment:6 Changed 9 years ago by timgraham
Reply to Gurvan's comment:
Assuming this is postponed to next year it probably fits into my task on "removing unnecessary communications (HPC-3). I'll include it in the description to remind me.
comment:7 Changed 8 years ago by lambertn
I had to change some littles things in the code (trunk) to be able to compile the bdy option in the TOP component.
First, in the file trc.F90 the variables cn_trc_dflt, cn_trc and nn_trcdmp_bdy can't be allocatable because they are part of a namelist structure (namtrc_bdy). So as it is done with the physicals varialbes of bdy, I declare those three variables with the dimmension = jp_bdy.
- CHARACTER(len=20), PUBLIC, SAVE, DIMENSION(jp_bdy) cn_trc_dflt
- CHARACTER(len=20), PUBLIC, SAVE, DIMENSION(jp_bdy) cn_trc
- INTEGER, PUBLIC, SAVE, DIMENSION(jp_bdy) nn_trcdmp_bdy
But to do that, the line "USE bdy_par, only: jp_bdy ! NL" must be add at the beginning of the file (inside the key_bdy). And of course, the allocation must be removed (line ~228).
Second, in trcdta.F90 the variable fsdept_n does’nt exists anymore, I assume that the variable gdept_n must be used instead.
comment:8 Changed 8 years ago by lovato
Reply to lambert comment:
The bdy namelist of passive tracers is read after the one for active tracers, thus their value is set to allocatable and then allocated using nb_bdy that is previously set in the memory of the code
instead of using the maximum value of bdy segments.
This will allow to save some memory and force the number of bdy segments used for passive tracers to be consistent with that of active ones.
For the second point, the use of fsdept_n was in the development branch of bdy for passive tracers that it is coherent with the NEMO code structure of last year,
while trcdta.F90 was uptdated after last NEMO merge party and the trunk code is correctly using the gdept_n.
I might guess you were mixing the code of the trunk and the development branch of bdy for passive tracers
and I would suggest you to refer to the trunk.
comment:9 Changed 8 years ago by lovato
- Resolution set to fixed
- Status changed from new to closed
comment:10 Changed 7 years ago by nemo
- Type changed from Development to Task
Remove 'Development' type
During the creation of this ticket the trunk was updated
so the correct path to the development branch is dev_r5040_CMCC5_BDY_for_TOP