Question Thread | Some (undocumented?) Questions

[niklassay]

Hey everyone,

I'm a regular user of fTetWild and I'm really happy about what the software can do! However, from time to time I experience some unexpected behaviour. Maybe someone can shed some light on it:

• Assuming one specifies a background mesh for mesh sizes and a global edge length goal: How are the background mesh and the --lr/ --la flag interacting? Is one overriding the other, or is there simply e.g. a minimum of the two values at some specific location taken?
• On the difference between TetWild and fTetWild: Is my understanding correct, that TetWild is faithful to the input surfaces and orientations while fTetWild is not? Does that imply that the surface mesh of the result is a 1:1 copy of the input surface mesh? Surely not, because in that case the whole envelope approach would not make any sense? So what exactly is meant by "faithful" in this context?
• About the energy stop value: On larger meshes I sometimes experience the postprocessing step to start before the cutoff is apparently reached. Below is an example of the output in such a case:

//////////////// pass 49 ////////////////
edge splitting...
fixed 0 tangled element
success = 10198531(10198531)
edge splitting done!
time = 106.05s
#v = 20154866
#t = 112266236
max_energy = 190.392
avg_energy = 3.78811
edge collapsing...
fixed 0 tangled element
success(env) = 40585
success = 6140513(89799942)
success(env) = 2331
success = 365742(19392973)
success(env) = 256
success = 39013(3459896)
success(env) = 57
success = 8492(453876)
success(env) = 15
success = 1869(101513)
success(env) = 2
success = 380(23066)
success(env) = 1
success = 116(5094)
success(env) = 0
success = 21(1439)
success(env) = 0
success = 6(258)
success(env) = 0
success = 0(68)
edge collapsing done!
time = 1041.97s
#v = 13598714
#t = 77940159
max_energy = 119.437
avg_energy = 3.59529
edge swapping...
fixed 0 tangled element
success3 = 68086
success4 = 1493992
success5 = 55305
success = 1617383(64243888)
edge swapping done!
time = 617.506s
#v = 13598714
#t = 77927378
max_energy = 81.8547
avg_energy = 3.56945
vertex smoothing...
success = 12263868(13478602)
vertex smoothing done!
time = 141.568s
#v = 13598714
#t = 77927378
max_energy = 67.2553
avg_energy = 3.4918
//////////////// postprocessing ////////////////

Why is this happening? I didnt set any other stop criterion explicitly.

Best,
Niklas

[DavidJourdan]

About the first question: from my experiments it seems like both background mesh and global edge lengths are necessary, and sizing values on the background mesh are taken into account only if they are smaller than the global edge length goal, i.e. fTetWild first meshes uniformly following the global length goal, and then refines according to the background mesh.

Then again, the bg-mesh feature as been apparently broken since commit dc552fb, I can submit a pull request if there is interest

[mjx888]

@DavidJourdan I also find the background mesh feature not working. It would be nice if you could fix it.

BTW, I did a quick test and confirmed that the broken bg-mesh feature is caused by commit dc552fb.

[niklassay]

Is it really broken? I have the feeling that there sometimes is confusion as to what a background mesh should do. My understanding is that, analogous to a background mesh in Gmsh, it simply defines a spatial field of mesh sizes - some people expect that it defines a mesh that appears in the final mesh as well. Stuff like that should be made more clear imo.
I’m probably going to run some tests when I find the time

[DavidJourdan]

@niklassay To clarify, I am not saying the bg-mesh function is not working as in "it doesn't behave the way I want to", I mean that if you try using the bg-mesh flag, the code will crash.

You can check this by compiling the project on the latest commit and by running the run.sh script provided in the README (link), the second command ./FloatTetwild_bin --input input.stl --bg-mesh bg_mesh.msh --stop-energy 20 --level 3 should return something like a std::bad_function_call exception, this is because the get_sizing_field_value function has been deleted so the code is calling an uninitialized std::function