Problem with Renaming Geometry from STL File

[anandanandan86]

Hello, I am having trouble setting up a very simple OpenLB case that I am trying to adapt from the cylinder3d sample.

To start, the case simply models flow through a 15m (x-dir) x 15m (y-dir) x 5m (z-dir) prism with a 1m (y-dir) x 2m (z-dir) inlet/outlet pair on the walls normal to the x-direction.

As this is only the initial domain for test purposes and the final domain may be more complex, I want to be able to read in the domain shape from an STL file.

I try to do this based on the cylinder 3d sample, and my understanding of the required code is as follows:

Read in STL data (main function) and create initial domain from it, expanded by 1 cell:
STLreader<T> stlReader(“roomscale.stl”, converter.getConversionFactorLength(), 0.001, 0, true);
IndicatorLayer3D<T> extendedDomain(stlReader, converter.getConversionFactorLength());

Assign geometry IDs (prepareGeometry function):
superGeometry.rename(0, 2, indicator);
superGeometry.rename(2, 1, stlReader);
superGeometry.clean();

From just these commands I expect to receive a domain with all exterior cells set to 0, boundary cells set to 2, and interior cells set to 1 as shown in Figure 5.2 of the OpenLB manual.

However, when I check the geometry vtm files, I find that large parts of the expected boundary and interior remain set to 0–so the case is not set up correctly. The incorrect parts especially seem to appear along the diagonal seams of the 6 side-walls of the domain introduced by the triangulation in the STL file.

However, when I reduce the size of the domain in the STL file to 5m x 5m x 5m, even keeping the same grid resolution in the converter, the issue no longer appears and the geometry appears to be set up correctly.

I am curious as to why the same process should produce different outcomes merely depending on the domain size and would welcome any support to overcome this issue for the larger-sized (15x15x5m) domain.

P.S. I heard that changing the method of the STL Reader from 0 to 1 can help make it more robust, but in this case it did not resolve the issue for the larger domain.

• This topic was modified 2 years ago by anandanandan86. Reason: Additional information added

[jjessberger]

Hi,

this is not a general solution, but merely some ideas in order to eliminate the error source (probably you have tried some of these already):
– does the problem depend on the number of cuboids/ cores?
– plot and check the material numbers in paraview, before and after each rename
– increasing the extent of the CuboidGeometry can avoid round-off errors at that stage

Yours,
Julius

[anandanandan86]

Hello,

Thank you for your tips. I checked these points and can confirm as below:

– does the problem depend on the number of cuboids/ cores?
No, for the problematic case (15m x 15m x 5m), I tried running with both 1 cuboid/core as well as 4 cuboids/cores, but observe the same error

– plot and check the material numbers in paraview, before and after each rename
I did this and I can confirm that the issue arises at the very first rename:

superGeometry.rename(0, 2, indicator);

However, as the indicator layer is created from the grid generated by the STLReader, this indicates that the problem is occurring from the STLReader itself. I cannot diagnose this further as the STLReader is a black-box to me.

– increasing the extent of the CuboidGeometry can avoid round-off errors at that stage
I tried this by increasing the extension distance in the IndicatorLayer3D<T> extendedDomain declaration five-fold, but it does not fix the issue

If possible I would like to diagnose what is going on within the STLReader further, but I am not sure how to do this, so I would like to request any possible support on further resolving this issue.

[jjessberger]

Hi,

It sounds as if the geometry which comes out of the STLreader is not watertight. This can still be due to the super- or cuboid geometry.
How exactly did you define the variable “indicator” which is used for the first rename and how did you define the cuboidGeometry?

As I do not know the insides of the STLreader either, I can only suggest looking inside with a debugging tool and checking, whether/ why some points at the boundary are not recognized.

[Author]

Posts