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.
#2449 (wrong coastal boundary condition in dyn_ldf_blp) – NEMO

Opened 4 years ago

Closed 4 years ago

#2449 closed Bug (fixed)

wrong coastal boundary condition in dyn_ldf_blp

Reported by: smasson Owned by: systeam
Priority: high Milestone:
Component: LDF Version: v4.0.*
Severity: major Keywords:



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?


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.


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

Commit History (1)


r4.0-HEAD: fix coastal boundary conditions in dyn_ldf_blp, see #2449

Change History (2)

comment:1 Changed 4 years ago by smasson

In 12791:

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

comment:2 Changed 4 years ago by smasson

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

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

Note: See TracTickets for help on using tickets.