Check that particles remain within grid domain about parcels HOT 6 CLOSED

I had another think about this, after discussions with @Jacketless, and it is easy to create a function check_withinbounds, as I did in the commit above. However, this simple function now stops execution of the entire set as soon as at least one particle is out of bounds.

Better would be to have a set of optional behaviour if a particle gets out of bounds, and then let users choose. These option can be

1. Stop execution altogether
2. Stop execution only for particles that are out of bound (this would be expected behaviour for physical oceanographers); requires the particles to be able to be 'popped', as in #14.
3. Do not execute a particle if it means getting out-of-bound. This requires the old position to be saved, so we can revert back to it if a particle get out-of-bound
4. More sophisticated behaviour like 'bouncing back from a wall'. This can be implemented at later stages

from parcels.

Since the new spatial interpolation routines implemented in PR #81, boundary conditions have become more apparent as PARCELS currently grinds to a halt if attempts at sampling field values outside the boundary are made.

The animal behavioural work requires diffusion/random jumps/walks etc. This often results in particles ending up past boundaries or at least much closer to them than would occur for passive particles.
At present, PARCELS fails whenever sampled fields are out of bounds. This occurs not just when a particle ends up on land during the previous time-step, when we might wish the particle to "die", but also when the RK4 algorithm samples points as fractions of dt (e.g. calculating u1, u2, u3 & u4).

I suggest to keep things simple, we allow an option for particles to "die" if any sampling takes place outside a field boundary (even if it's just part of the RK4). I think we also need to allow an option for some kind of error or other object to be returned in place of the interpolated value from interpolator1d() in field.py. If this error object can propagate back to a user-defined kernel, the user can then choose some alternative action himself/herself (re-drawing a random jump, for example).

At the moment, putting a try-except statement within my user-kernels does not catch the error: they occur in the interpolation functions of field.py.

What does the team think about how we might best handle this?

from parcels.

I agree with your analysis @Jacketless, and that we need to make sure there is some way to catch out-of-bounds errors in the interpolation functions.

Note that this also relates to issue #76, on periodic boundary conditions. Expected behaviour there is that if an out-of-bound interpolation is returned (say because the particle is west of the western boundary), the location is changed and re-evaluated such that the particle is just west of the eastern boundary (and therefore inside the domain again)

Not sure what the most 'pythonic' way is to implement this error propagating. @mlange05 any ideas?

from parcels.

This was temporarily fixed in PR #85. However, a more graceful solution is needed, also to accomodate PR #86 by @nathanieltarshish

from parcels.

In the hopes of a more graceful solution that is amenable to parallelization, I thought more about the problem and am interested in hearing your thoughts on the approach shown in the attached file (which is a .py file I renamed as .txt to comply with Github's attachment restrictions). The basic idea is that we check to see if each new latitude and longitude generated during the Runge-Kutta integration are within the domain before the velocity interpolation step. This obviates the need to propagate the interpolation error from the field method to the Runge-Kutta integration. If the particle is out of the domain, we call a separate boundary recovery method that notifies the user. A flag set by the user controls the subsequent boundary behavior: mask, remove, or circumpolar. The recovery method is hopefully written in a way that is compatible with the parallelization plan and allows the user to easily add custom boundary behavior. I am interested to hear if you folks think this approach moves us in the right direction (or, more likely, is just wrong-headed).
AdvectionRK4_outline.txt

from parcels.

This has been fixed with PR #122

from parcels.