adventures with OFFLINE, BDY and MY_TRC

[rblod]

Context

Oddly, I happened to try the combination of TOP OFFLINE with open boundaries (ln_bdy and frs or orlanski but certainly true for other choices of conditions), using MY_TRC in my case, just needing to radiate out my domain some kind of dye. I wanted to set the boundaries to the initial state. (I think) I found light inconsistencies in term of coding of the different combinations of flags (some are generic and not only related to MY_TRC). I'm using NEMO 4.01
.

Analysis

1- there is no call to bdy_ini and bdy alloc in nemogcm (the one from OFFLINE). With 2 consequences :

• OFFLINE with bdy activated crash obviously

• a bit more disturbing, whatever the use of OFFLINE, ln_bdy is never initialised. Luckily gfortran and ifort with standard options often initialise logical to .false. but there is no warranty, and we may end up with an OFFLINE code always trying to use bdy (even with global configurations...)

2- in trcbc.F90 (routine trc_bc_ini called when using my_trc) I'm not convinced by the last test (this may be a problem with BDY-TOP too, not tested)

                IF(  .NOT.( 0 < nn_trcdmp_bdy(ib)  .AND.  nn_trcdmp_bdy(ib) <= 2 )  )   &
                   & CALL ctl_stop( 'trc_bc_ini: Not a valid option for nn_trcdmp_bdy. Allowed: 0,1,2.' )

If we're not using damping (so nn_trcdmp_bdy=0) but another condition at the boundary, this test is always wrong and the model stops. A simple fix could be

            IF(  .NOT.( 0 <= nn_trcdmp_bdy(ib)  .AND.  nn_trcdmp_bdy(ib) <= 2 )  )   &

or changes in trcini

3- in trcini.F90 (trc_ini_istate), this call

      IF( ln_my_trc )   CALL trc_bc_ini ( jptra )      ! set tracers Boundary Conditions

is done before the call to trc_dta so setting boundaries to initial conditions for MY_TRC fails. There is a related comment from Gurvan, and Gurvan is often right (in term of coding)

4- In addition, since It may have been a combination too simple, I was also running with jpk =2 . In this case the time stepping in trc_zdf_imp crashes . I remember I made the test with dynamics only some time ago with the same issue in tra_zdf. Minor, but I think it's nice to have a dynamical core able to run in 2D (even with useless computation) for development and academic studies, and eventually operational purposes (storm surges). I didn't investigate why in this case the matrix inversion doesn't just end up with something like 1=1, but a simple time stepping could be done in this in trczdf/trazdf in this case

Not very familiar with OFFLINE nor TOP and I did this quickly so I may have misunderstood the logic of the whole thing. It may also have been an unfortunate/stupid combination to test.

Recommendation

See above.

[cetlod]

In 12841:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[cetlod]

In 12842:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[cetlod]

In 12843:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[cetlod]

Fixes done in r4.0-HEAD & trunk