Possible bug in LRSplineVolume::insert_line ?

[TheBB]

Context: I have 50 solutions, each with 204 patches, linear and quadratic. Of all these combinations, this bug reproduces only twice. I've attached the smallest of those two reproducing examples. For what it's worth, it does not repro on any of the quadratic cases I have, but it could be that they are just not fine enough.

The problem boils down to the following: create two patches (A and B) with the same order and parameter space, but potentially different topology and control points, or even physical dimension. Copy all mesh rectangles from A over to B, and then back again. The resulting two patches should be topologically identical. In particular they should have the same number of basis functions.

In each reproducing case, one of the patches (A) I picked had to be from a specific solution (out of the 50), but the bug reproed with any other solution playing the role of B. Whether you copy from A to B first or vice-versa does not seem to matter.

Two patch files and a small program that demonstrates the mismatching lengths can be found here:
https://gist.github.com/TheBB/a9c22ee1acc96caed2b7bff7884cd822

Output:

A: 1433 B: 208
A: 1433 B: 1425
A: 1433 B: 1425

[VikingScientist]

This is for sure a bug. Good catch.

My initial thoughts is that this is related to floating point precision. The LRSpline library is sadly not terrible robust when it comes to near-hit meshlines (when looking if the meshline exist or note), and I'm pretty sure it also commits the cardinal sin of comparing floating-point numbers using == at some points. The problem is apparent when reading from file, which has limited precision, but can even exist when using 1/3 as knot vectors.

The short-term fix is to only consider knot vectors in multiples of 2^-n (which can be done by rescaling the original knot vector to contain integer numbers and by refining through only halving element sizes.

The long-term fix is to insert custom tolerance into the library, but the biggest roadblock here is to find a good hashing function for the Basisfunction object; see https://github.com/VikingScientist/LRsplines/blob/master/src/Basisfunction.cpp#L588. The hashing function is used to find if functions exist in the solution space or not and I don't know how to do this lookup with a tolerance-dependent knot vector.

[VikingScientist]

This bug should be closed once #48 is merged to trunk.

In short, the file provided: a.lr is already corrupted. This can be seen by checking i.e. the following basis function:

1372: [0.36 0.37 0.38 ] x [0.416667 0.5 0.583333 ] x [0.5 0.75 1 ]

This should not contain the w-knot 0.75 as all MeshRectangle objects at the w=0.75-plane are the following:

  [0.46, 0.5600000000000001] x [0.3333333333333333, 0.6666666666666666] x [0.75, 0.75] (1)
  [0.46, 0.54] x [0.1666666666666667, 0.6666666666666666] x [0.75, 0.75] (1)   
  [0.28, 0.38] x [0.3333333333333333, 0.5] x [0.75, 0.75] (1)                      
  [0.46, 0.54] x [0.1666666666666667, 0.5] x [0.75, 0.75] (1)                      
  [0.28, 0.36] x [0.1666666666666667, 0.5] x [0.75, 0.75] (1)                      
  [0.28, 0.36] x [0.1666666666666667, 0.6666666666666666] x [0.75, 0.75] (1)   
  [0.28, 0.36] x [0.1666666666666667, 0.8333333333333333] x [0.75, 0.75] (1)   
  [0.46, 0.54] x [0.1666666666666667, 0.8333333333333333] x [0.75, 0.75] (1)

and none of these span the entire support of basis function 1372.