STL voxelization
OpenLB – Open Source Lattice Boltzmann Code › Forums › on OpenLB › Bug Reports › STL voxelization
- This topic has 4 replies, 2 voices, and was last updated 4 years, 11 months ago by spider.
-
AuthorPosts
-
October 7, 2019 at 4:55 pm #4578spiderParticipant
Greetings!
For own debugging purposes, I created my own version of laminar flow in a pipe and took mainly the aorta3d example as a reference.
However, instead of using an IndicatorCylinder3D, I created a STL mesh with the exact same size and alignment as it’s done in the poiseuille3d example.
I didn’t want to use the CylinderIndicator here because I want to use an arbitrary meshes later on.
Running the program, I noticed a cross-shaped artifacts at the inlet and outlet.
To investigate further, I used the poisseuille example and did nothing but replace the IndicatorCylinder3D by a STLreader reading my cylindrical STL mesh (using the slow but more accurate indication method).The result can be seen in the following two material images (looking at the material ids after renaming as it’s done in the example).
Legend:
left=IndicatorCylinder, right=STLreader
black=empty, red=fluid, blue=wall<br />upload images<br />
<br />upload images<br />
<br />upload images<br />
Is this a known phenomenon of the octree-inside-outside test and (how) can it be avoided?
Thanks in advance!
SimonOctober 7, 2019 at 5:00 pm #4580mathiasKeymasterSorry, I cant see any images! You can email them to me, info(at)openlb(dot)net . Best Mathias
October 7, 2019 at 5:02 pm #4582spiderParticipantSorry I just wanted to fix that, but now I’m unable to edit the post :-/
I’ll send them via mail!
October 7, 2019 at 5:09 pm #4583mathiasKeymasterHi, was it a water-tight stl-file? Inlet and outlet should be closed. You also need to take care about the periodic set-up which we realised our example with. With a bit careful hand-work it should be possible, I dont see here a bug. Best Mathias
October 8, 2019 at 4:41 pm #4586spiderParticipantHi!
Actually the stl-file was not water-tight. Closing the holes removes the artifacts as expected.
However, I had assumed that it also works for untight STL files which is indicated by the constructor’s documentation of the STLreader, since it defines a ray for each of the major directions x, y and z and performs a majority vote on the three test results.
So if a node is exactly at the inlet or outlet, it should indicate correctly.But according to this, the reason for the cross-shaped artefact could be the following.
If a node of the octree is slightly off the inlet or outlet location, due to the floating point precision for example, the full node would be indicated as inside or outside according to the node’s position. Now the node could, of course, span a larger volume eventually reaching inside the geometry, since there is no face that would lead to another split into child nodes.
Same is true for adjacent nodes, but not for diagonally adjacent ones, leading to a different indication and therefore can be seen as a cross.So now I wouldn’t consider this a bug as well – thanks for investigating with me!
Best
Simon -
AuthorPosts
- You must be logged in to reply to this topic.