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 applying round().

Checklist

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

[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).