Fix LBGPU velocity interpolation close to boundary

[RudolfWeeber]

Fixes #

Description of changes:
LB GPu velocity interpolation used incorrect velocities at boundary nodes. This lead to incorrect resutls for interpolations closer than one lattice constant to the boundary.
This adds a missing unit conversion 1/lattice_speed for boundary nodes, which fixes the issue.

Tests for interpolation at the boundary position and at the mid-point between the boundary and the next lattice site.

This should go into 4.1.3

[codecov]

Codecov Report

Merging #3593 into python will increase coverage by <1%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           python   #3593    +/-   ##
=======================================
+ Coverage      88%     88%   +<1%     
=======================================
  Files         527     527            
  Lines       23572   23572            
=======================================
+ Hits        20755   20761     +6     
+ Misses       2817    2811     -6

Impacted Files	Coverage Δ
src/core/electrostatics_magnetostatics/p3m.cpp	85% <0%> (ø)	⬆️
src/core/polymer.cpp	98% <0%> (+5%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bf30a6c...ecaedad. Read the comment docs.

[jngrad]

do we need to guard the result of get_interpolated_velocity with np.copy()?

[RudolfWeeber]

We let the CI decide.

[jngrad]

Did you figure out the source of the error Lattice velocity exceeds the Mach number limit in function void lb_boundary_mach_check() in failed CI jobs?

[RudolfWeeber]

I don't understand the larger error for the clang:6.0 and cuda 9 images. On my machine, (and apparently on the cuda 10 container), the accuracy is much better. Atol=1E-10 worked locally.

I'm increasing the tolerance for now, because the result is still much better than the one with the missing prefactor without this PR. But I don't understand why that should be needed.

[RudolfWeeber]

Accuracy reduction was caused by an unintended parameter change (TAU) which I reverted now. still don't understand the platform-dependence, now.

[jngrad]

Seems to be working now. Could you please revert the print/sys.stdout changes and squash the PR down to a single commit? This will make backporting go smoother.

[RudolfWeeber]

I added the print stuff on purpose, just like in the LB test. Since the error message output from the Mach limit test cannot be supressed, the output of the test is confusing without the new print. W.r. to squashing I already eliminated the merge commit. couldn’t you cherry-pick the commit range with a current git. The frequent context switches for revisiting PRs impedes my science work too much, currently.

[KaiSzuttor]

is the boundary velocity stored in MD units? The correct fix would be to store it in LB units and not adding this unit conversion in the LB code. This should be reverted.

[RudolfWeeber]

is the boundary velocity stored in MD units? The correct fix would be to store it in LB units and not adding this unit conversion in the LB code. This should be reverted.

Apparantly it is in LBGPU. I find the boundary code to be rather ‘write-only’ and the LBGPU is to be replaced anyway, so I did not make an attempt at cleaning things up. For Walberla, we use the same units everywhere, obviously.

[KaiSzuttor]

all right