wrong coastal boundary condition in dyn_ldf_blp

[smasson]

Context

Same as #2448 but for the 4.0-HEAD

This bug affects the coastal boundary conditions of dyn_ldf_blp...

Note that if the southern/western boundary is closed, the bug does not affect the points located just along the southern/western edge of the global domain.

It could explain a part of the problem that occurred at the southern boundary of ORCA grids along the southern boundary of the Weddell sea?

Analysis

After several discussions with Gurvan... I hope I get it right...

For example, consider the laplacian for a 1 V-point located along a southern coastline

           |              |
ocen side  |      D1      |
           |              |
coast: === C1 == Vlap == C2
           |              |
land side  |      D2      |
           |              |

C1 and C2 are the curl at F-points. They are multiplied by fmask because of ahmf. In free slip, they are equal to 0.
D1 and D2 are the divergence at T-points. D2 = 0 but not D1.
So in any case, Vlap won't be equal to 0 if we don't multiply it by vmask.

If Vlap were not equal to 0, this would be a source term in the laplacian diffusion trend, which is incompatible with the fact that V must always remain equal to 0 at the coast.
So V always equals to 0 at the coast imposes that its laplacian cannot be different from 0.

• in the dyn_ldf_lap case, this is not a problem as the trend will later be multipled by vmask.
• in dyn_ldf_blp, the output of the first call of dyn_ldf_lap (zulap, zvlap) won't be correctly masked when used as input arguments in the second call of dyn_ldf_lap. This is the source of the bug!

Same story, all along the coast, on each directions...

Note that, in case of closed boundaries conditions, the call to lbc_lnk between the 2 calls of dyn_ldf_lap in dyn_ldf_blp will put 0 on the first row/column that will correct the bug for ocean coastal plots located on the second line/row.

Fix

easy: in dyn_ldf_lap, multiply pu_rhs by umask and pv_rhs by vmask.

[smasson]

In 12791:

Error: Failed to load processor CommitTicketReference

No macro or processor named 'CommitTicketReference' found

[smasson]

fixed in [12791]
[12791] changes the results of configuration using dyn_ldf_blp