Converting hex27 to hex8 fails

[gtheler]

Reported by Franz Maximilian Trompetter

$ feenox second2first.fee 
gsl: lu.c:324: ERROR: matrix is singular
Default GSL error handler invoked.
[tom:433808] *** Process received signal ***
[tom:433808] Signal: Aborted (6)
[tom:433808] Signal code:  (-6)
[tom:433808] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x3fdf0) [0x7fe812049df0]
[tom:433808] [ 1] /lib/x86_64-linux-gnu/libc.so.6(+0x9495c) [0x7fe81209e95c]
[tom:433808] [ 2] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x12) [0x7fe812049cc2]
[tom:433808] [ 3] /lib/x86_64-linux-gnu/libc.so.6(abort+0x22) [0x7fe8120324ac]
[tom:433808] [ 4] /lib/x86_64-linux-gnu/libgsl.so.28(+0x96098) [0x7fe812296098]
[tom:433808] [ 5] /lib/x86_64-linux-gnu/libgsl.so.28(gsl_linalg_LU_solve+0xa5) [0x7fe8122e7af5]
[tom:433808] [ 6] /lib/x86_64-linux-gnu/libgsl.so.28(+0x15802a) [0x7fe81235802a]
[tom:433808] [ 7] feenox() [0x43bda7]
[tom:433808] [ 8] feenox() [0x42787b]
[tom:433808] [ 9] feenox() [0x43dd97]
[tom:433808] [10] feenox() [0x438081]
[tom:433808] [11] feenox() [0x40f6e9]
[tom:433808] [12] feenox() [0x40edcf]
[tom:433808] [13] /lib/x86_64-linux-gnu/libc.so.6(+0x29ca8) [0x7fe812033ca8]
[tom:433808] [14] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7fe812033d65]
[tom:433808] [15] feenox() [0x40f2a1]
[tom:433808] *** End of error message ***
Aborted (core dumped)

[gtheler]

Here's what's going on.
SunCAE's converter from 2nd order to 1st order is here: https://github.com/seamplex/suncae/blob/main/solvers/feenox/second2first.fee

READ_MESH ${1}.vtk DIMENSIONS 3 {
  READ_FIELD displacements1 AS u
  READ_FIELD displacements2 AS v
  READ_FIELD displacements3 AS w
  READ_FUNCTION sigma
}

READ_MESH meshes/${2}.msh
WRITE_MESH ${1}-1.vtk MESH meshes/${2}.msh VECTOR NAME displacements u v w  sigma

The idea is that the nodes in ${1}-1.vtk are exactly the corner nodes of ${1}.vtk so the WRITE_MESH instruction does not need to interpolate but just evaluate the displacements at the definition point.

However, the precision of the floating-point values in ${1}.vtk is different from ${1}-1.vtk so the coordinates of some nodes might differ and FeenoX will interpolate. For tet10 it seems that the interpolation is no problematic but for hex27 it is.

The solution would be to increase the threshold for avoiding interpolation, which for regular functions is given by the keyword INTERPOLATION_THRESHOLD of the FUNCTION definition. But here the functions u, v and w are implicitly defined by READ_MESH so there is no way to do it right now.

This commit adds a special variable nearest_node_threshold which controls the threshold for the implicitly-defined functions: f044993
Hence, the file now should be

nearest_node_threshold = 0.1
READ_MESH 2.vtk DIMENSIONS 3 {
  READ_FIELD displacements1 AS u
  READ_FIELD displacements2 AS v
  READ_FIELD displacements3 AS w
  READ_FUNCTION sigma
}

READ_MESH 1.msh
WRITE_MESH 1.vtk MESH 1.msh VECTOR NAME displacements u v w  sigma

Using the latest FeenoX version, this now works.