warning if dt is modified during kernel returning SUCCESS

[delandmeterp]

This PR captures if a kernel has modified particle.dt.
This leads to problems in many situations:

• In our code, particle.time will be updated using the dt before the kernel call, ignoring the dt, which will be used at next kernel call (so one time step later)
• everything called after the particle.dt will then be executed with the wrong dt

-> There is no problem if after modifying dt, the kernel returns REPEAT, in which case, all variables are reset to their value before the kernel call (except dt) and the kernel is rerun

Problems:

• In current version of the PR, JIT particles call a warning for each occurence of p.dt modification. This can lead to a lot of prints
• the test does not capture the scipy particle warning. Nothing is really tested there
• Should JIT particle return a different error code in case of p.dt modifications, and a true warning_once be printed? There will be only one print, but the C loop will be broken all the time...

Solution? Why do we want to raise a warning? Why don't deleting the particle (or even killing the run?). Modifying dt during kernel execution is dangerous. Some users could use such operation correctly. But they could also do the same job without modifying the dt like this. It's better to completely disable such operation

[delandmeterp]

So we decided that the code should crash if dt is modified without REPEAT error.
This makes sense.

Now, we have a problem with RK45. RK45 does either divide dt by 2 if accuracy is bad, or multiply it by 2 if accuracy really good. We were not repeating the kernel in the last case (which was wrong).

But if RK45 requests to multiply dt by 2, but dt can't be increased since t+dt > tend, them we are stuck in an infinite loop.

[delandmeterp]

Solution might be the following:

We wanted to do "if dt is modified, code crashes"
Why not: "if dt is modified*, then kernel.repeat"

by modified*, I mean modified between "before kernel call" and "after kernel call + adjustment due to tend"

I think this would make sense

[erikvansebille]

I think this would make sense

Yes, I agree.

[delandmeterp]

Limitation is that if kernel does particle.dt *=2 then it loops forever, but
(1) it would have crashed anyway with first suggestion
(2) we already have possible infinite loops in current code. So it's a different weakness

I'll implement this then.

[erikvansebille]

These two lines are somewhat unclear. Would it help to rename pdt to something clearer, e.g.

p.dt =  sign_dt * dt_pos
pdt_prekernels = p.dt

and then check ... not np.isclose(p.dt, pdt_prekernels) below?