Particles get permanently stuck near seafloor topography (A-grid, silent zero velocity): is deletion the only option, or is there a vertical equivalent to XFreeslip/XPartialslip?

[imariaguiar]

Question

Question

Hi,

I'm running Lagrangian simulations with Parcels (v3.1.4) to study Antarctic Bottom Water (AABW) pathways in the Vema Channel region, using OFES model output. I release particles at every valid grid point along a vertical section (from ~3800 m down to the local seafloor) and track them for up to 50 years (using time_periodic to loop over the ~28 yr of available velocity data).
The problem: a significant fraction of particles get permanently stuck, their position never changes again, for the remainder of the simulation (sometimes 40+ years), while neighboring particles continue moving normally.

This looked at first like a bug in my error-handling kernels, but after diagnosing it directly, I found:
Querying fieldset.U/fieldset.V directly (via .eval()) at the stuck particle's position raises FieldOutOfBoundError, confirming the particle is at a depth below the local seafloor (I verified this by comparing the particle's depth to the deepest valid level in that same water column: margins as small as 0 m, since my release grid intentionally includes the deepest available level in each column).

However, during the actual pset.execute() run with AdvectionRK4_3D, no error is ever raised, particle.state stays Success the whole time. Instead, U and V silently return 0.0 at that exact position. This means neither in-list check-kernels nor postIterationCallbacks (checking particle.state) ever catch it, since there's simply no error state to catch.

I found your "Preventing stuck particles" tutorial afterward, and the DeleteOnLand example ((u==0)&(v==0) → delete) confirms this is the known A-grid behavior, just for a horizontal coastline case rather than a vertical seafloor case. My current workaround is a custom kernel that checks particle depth against a locally-computed bathymetry field (deepest valid U level per lon/lat column) and deletes the particle if it exceeds that, which works correctly.

My question: is deletion really my only reasonable option here, or is there a vertical equivalent to XFreeslip/XPartialslip (which, as far as I understand, only correct interpolation in the horizontal ξ/η directions)? I'd like to know if there's a recommended way to instead "rescue" these particles with a corrected vertical interpolation near the seafloor, rather than just deleting them, since a fairly large fraction of my release points (~35% in one test batch) have near-zero margin to the local seafloor by construction (since I want to sample water immediately above the bottom).

Here's the core of my diagnostic:
traj 6: LAST position = lon=320.69, lat=-29.00, depth=4126.3m
traj 15: LAST position = lon=321.23, lat=-29.12, depth=4388.6m
traj 16: LAST position = lon=321.00, lat=-29.32, depth=4675.3m

local seafloor depth at these same (lon, lat) columns, from the

deepest finite U level:

traj 6: seafloor = 4113.4 m -> particle is ~13 m BELOW seafloor

traj 15: seafloor = 4388.6 m -> margin = 0.0 m (exact bottom cell)

traj 16: seafloor = 4388.6 m -> margin ~ -287 m

Any guidance on best practice here would be much appreciated, happy to share more of my code/data if useful.
Thanks!

[erikvansebille]

Thank you for reaching out, @imariaguiar. Indeed, stuck particles near complex/deep topography is a known issue in Parcels.

Coincidentally, MSc student Paolo started a project today to explore best interpolation practises near seafloor topography. Note that he will do this in the new Parcels v4.

So I'm afraid I don't have a quick solution, but keep an eye on the tracker here fr updates!

[imariaguiar]

Hi @erikvansebille, thanks for confirming there's no built-in solution yet, that matches what I found.

I ended up writing a custom kernel that checks particle depth against a static bathymetry field (built as the deepest valid U-level per lon/lat column), deleting the particle when it exceeds that. I validated it against the documented (u==0)&(v==0) criterion from the "Preventing stuck particles" tutorial, and found something worth sharing: on my OFES data, the exact u==0 check catches essentially none of the stuck particles (0% in one test batch), because near invalid cells the interpolated velocity is often a tiny non-zero floating-point value (~1e-6 to 1e-8 m/s) rather than exact zero.

My bathymetry-based check catches ~65-95% of the same particles (depending on dt), which a manual position check confirms is correct, those particles genuinely end up below the local seafloor and keep sinking indefinitely if not caught.

I also found the mortality rate is strongly dt-dependent (65% at dt=12h, up to 94% at dt=3h in my tests), consistent with a CFL argument (Δx≈10km, u_max≈0.3 m/s → CFL limit ≈9h).

Given this, would you recommend the bathymetry-depth-check approach as reasonable practice, or is there a better-established pattern for this specific abyssal/bottom case (as opposed to the horizontal coastline case)?

Specifically: (1) is comparing particle depth against a precomputed local-seafloor field a sound method, or is there a pitfall I'm missing? (2) would you suggest combining it with a velocity-near-zero check (with a tolerance threshold, not exact zero) as a safety net, or is that redundant?

Thanks again for the guidance!

[erikvansebille]

Thanks for this detailed write-up, @imariaguiar. Yes, I fully agree with your approach to check particles based on a depth-dependent check. Whether you then remove these particles or move them a bit upward in the water column is up to you (and may depend on the research question you have). But I think your on the right track