Reproductibility issue in dynkeg.F90 if(ln_bdy)

[girrmann]

Context

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

Analysis

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)...

Fix

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

[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.

[girrmann]

In 10996:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[girrmann]

fixed, see [10996]

[girrmann]

In 10997:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[girrmann]

done in v4 see [10997]

[dupontf]

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,

Fred.

[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.

[smasson]

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