Fix BMI.update_until (InexactError: Int64)

[verseve]

Issue addressed

Fixes #386

Explanation

BMI.update_until could throw an InexactError: Int64 caused by a not whole number. This is fixed by using divrem for the computation of the number of steps in BMI.update_until, an error is thrown when the absolute remainder is larger than eps(). An error is also thrown when steps is a negative number.

Checklist

• Updated tests or added new tests
• Branch is up to date with master
• Tests & pre-commit hooks pass
• Updated documentation if needed
• Updated changelog.md if needed

[visr]

Choosing round here means that you can either undershoot or overshoot if the desired time does not fall on a model timestep. I feel like either an error or a cld, where there can never be undershoot, may be a better option, though I'm not sure what the BMI best practices are for this.

[verseve]

Thanks for your comment @visr, good point. I think an improved error message may indeed be a better option than rounding. Will convert this PR back to draft, as it is not yet clear where the deviation from a whole number for the time argument is coming from (wflow or openda).

[visr]

Perhaps it is almost exactly and integer, but not quite since it comes from floating point math.

julia> t = 10 * (0.1 + 0.2)
3.0000000000000004

julia> Int(t)
ERROR: InexactError: Int64(3.0000000000000004)

julia> round(t)
3.0

julia> isapprox(round(t), t)
true

That should probably be allowed at least, and a better error message for the not so close times would also be an improvement.

[verseve]

Perhaps it is almost exactly and integer, but not quite since it comes from floating point math.

Yes, if time is almost equal to an allowed model timestamp this probably happens for steps (almost exactly and integer). I think the issue is probably caused by the time input, because both current model time and model time step are always whole numbers. First a bit more testing with openda-wflow is required (timestamps are rounded in openda) to check where the problem occurs and to decide if we need to allow almost exactly and integer steps. Besides that, if the problem is the external time input, you could also argue that is the responsibility of the external software package to deal with this properly (based on the error message).

[CFBaptista]

I have a few suggestions regarding

1. How to compute steps
2. The exact conditional statements
3. Code style