New URL for NEMO forge!

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
#2283 (Reproductibility issue in dynkeg.F90 if(ln_bdy)) – NEMO

Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#2283 closed Bug (fixed)

Reproductibility issue in dynkeg.F90 if(ln_bdy)

Reported by: girrmann Owned by: systeam
Priority: low Milestone:
Component: TOP Version:
Severity: minor Keywords:

Description (last modified by girrmann)


The result is dependant on the mpi domain decomposition when the rim is located along one of the edges of the local mpi domain.


2 issues have been found :

  • in some cases of MPI-domains decomposition, the model is not reproductible, see attached plot.
    For example in the flagu = -1 case, as the rim is defined only from 2 to jpi-1, the left MPI task will detect Urim located on jpi-1 and modify U_left(jpi) with U_left(jpi-1). However, the right MPI task will not detect Urim located in 1 and will not modify U_right(2).
    Note that a call to lbc_bdy_lnk won't solve the problem as it would in this case put U_right(2) back into in U_left(jpi) and erasing the modification we just done...
  • the modification of Un or Vn is done according to the value of flagu or flagv.
    With some geometry, see attached plots, knowing that un and vn are masked to 0, the value of zhke is not what I thing we are expecting (see yellow cells )...

We propose another computation of zhke using a mask weighted computation (see last image)...


Change zhke array after computation and not un and vn speeds beforehand

Commit History (2)


v4 : Report commit from bugfix #2283 fixed in the trunk


trunk : fixed reproductibility issue in dynkeg.F90 with bdy, see #2283

Attachments (3)

bdy_keg.001.png (34.4 KB) - added by smasson 5 years ago.
bdy_keg.002.png (77.9 KB) - added by smasson 5 years ago.
bdy_keg.003.png (78.9 KB) - added by smasson 5 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 5 years ago by jchanut

BTW, I have been thinking for a while now that what is done in dynkeg with ln_bdy=T is really dangerous. Is there enough evidence (by Maria or Fred) that we have to apply such a change (which breaks energy consistency between kinetic energy gradient and other terms in the domain interior) ?
I experienced issues with this trick, although I did not consider only changing zhke, which is far better.

comment:2 Changed 5 years ago by smasson

  • Description modified (diff)

Changed 5 years ago by smasson

Changed 5 years ago by smasson

Changed 5 years ago by smasson

comment:3 Changed 5 years ago by girrmann

In 10996:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:4 Changed 5 years ago by girrmann

  • Resolution set to fixed
  • Status changed from new to closed

fixed, see [10996]

comment:5 Changed 5 years ago by girrmann

  • Description modified (diff)

comment:6 Changed 5 years ago by girrmann

In 10997:

Error: Failed to load processor CommitTicketReference
No macro or processor named 'CommitTicketReference' found

comment:7 Changed 5 years ago by girrmann

done in v4 see [10997]

comment:8 Changed 5 years ago by dupontf

  • Version trunk deleted

Hi all,

I am seeing two problems in one here: 1) a MPI problem with the bdy implementation; 2) a kinetic energy formulation problem close to solid/open boundaries

I cannot comment on 1) but 2) worries me a bit for the same reasons that Jerome flagged above: Could you give some details on the rationale for the modification of the kinetic energy formulation along boundaries? Thanks,


comment:9 Changed 5 years ago by girrmann

The trick of (2) has been introduced in changeset [6807] without an option to switch it off. It has therefore been used for 3 years...
Our change in [10996] does not question the relevance (or irrelevance) of this feature but simply aim to correct the previous implementation that was faulty in some cases.
We are open to discussion to see if this modification of dynkeg is justified and should be kept with or without the possibility to deactivate it.

comment:10 Changed 4 years ago by smasson

Following dupontf and jchanut advises, we finally removed the patch related to ln_bdy in dynkeg. see [11258]

Note: See TracTickets for help on using tickets.