Replace use of LoopVectorization in local inertial model stable_timestep function with Polyester (reduction)

[verseve]

Issue addressed

Fixes #360

Explanation

The internal time step of the local inertial model (stable_timestep function) can get zero when LoopVectorization is applied (@tturbo) to the for loop of these functions. This issue occurred on a virtual machine, Windows 10 Enterprise, with Intel(R) Xeon(R) Gold 6144 CPU (2 processors). This has been fixed by replacing @tturbo with reduction of the Polyester package.

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

Additional Notes (optional)

Add any additional notes or information that may be helpful.

[verseve]

@JoostBuitink: the Blue Nile model (1d-2d local inertial model) ran fine with these code changes on a WCF node. I think it would be good to also test this for one of your wflow model applications on a WCF node, as part of the review.

[verseve]

Marked this PR as draft, because I just thought of another solution without the need to replace tturbo from LoopVectorization. The wflow Blue Nile model is running again to test this.

[JoostBuitink]

I did a couple of checks with the model that produced errors, and this branch seems to indeed fix it! @shartgring will also do a check, since he just ran into the issue that should be solved by this PR

[shartgring]

I did not get the error myself anymore when redoing my runs so that looks good!

At the same time, the Wflow model I recieved from @TBuskop still shows the error. However, that one uses kinematic-wave instead of local-inertial. So, it might be the question whether this PR will solve the error mentioned in the issue. I will elaborate further in the issue itself

[verseve]

At the same time, the Wflow model I recieved from @TBuskop still shows the error. However, that one uses kinematic-wave instead of local-inertial. So, it might be the question whether this PR will solve the error mentioned in the issue. I will elaborate further in the issue itself

I did check the wflow model of Ted, and the forcing file is not valid. At 2015-11-02 infinite values occur for a couple of grid cells for variable pet. This is causing the wflow error.

[atsiokanos]

Just re-encountered this type of error, so I can also provide the model for further testing (loc iner. 1d floodplains for Rio). We need to merge this branch soon, this error really limits our setups as in most of them floodplains are included.

[verseve]

Just re-encountered this type of error, so I can also provide the model for further testing (loc iner. 1d floodplains for Rio). We need to merge this branch soon, this error really limits our setups as in most of them floodplains are included.

@JoostBuitink: could you please add your review?

[JoostBuitink]

Just re-encountered this type of error, so I can also provide the model for further testing (loc iner. 1d floodplains for Rio). We need to merge this branch soon, this error really limits our setups as in most of them floodplains are included.

@JoostBuitink: could you please add your review?

Oops, my apologies. I thought I already approved the PR, but it looks like I only left a comment. Should be approved now!