STL porous media loading

[araeli]

Hello everyone,

I am currently trying to get familiar with managing STL loading (porous media geometry). I’ve conducted a few tests, here attached a section 100x100x100 of a Ketton stone https://drive.google.com/file/d/1pMyj_PHon0Yiu1ErcoVoiFyHNHY_6-Cp/view?usp=drive_link

Concerning this specific file, I am uncertain whether the memory issue is due to the file being too large (overcoming 44GB ram in voxeling, also with a low refinement of 10) or mine poor usage of routines.
I used basically the tutorial guideline without any optimization:

STLreader<T> stlreader(filename,converter.getConversionFactorLength(),domainLength,1,true);

I tried with different physDx ConversionFactorLength() from 0.001 to 0.1, defined the domainLenght as 1e-06 (my resolution is in micrometer), and the method as 1.

Could anyone provide tested dimensions for complex geometries that I can refer to? Any guidance would be gratly appreciated,
Thank you!

Alice

[jan]

Dear araeli,

I believe the following examples may help you:
– examples/laminar/cylinder3d
– examples/particles/bifurcation3d
– examples/adsorption/microMixer3d
– examples/turbulence/aorta3d
– examples/porousMedia/city3d

In general, it is also helpful to check the documentation:
– User guide: https://www.openlb.net/wp-content/uploads/2024/06/olb_ug-1.7r0.pdf (3.4. Reading STL-files)
– Doxygen: https://www.openlb.net/DoxyGen/html/d2/d60/classolb_1_1STLreader.html#a0c802e7d7c251615de04b2610697d0d5

The voxelSize should usually be converter.getConversionFactorLength(). However, the stlSize (3. parameter) depends on your STL. If your STL is in meter, it should be 1. If your STL is in millimeter, it should be 1e-3, etc. Therefore, 1e-6 should be correct in your case.

What error do you get exactly and what are the dimensions of your geometry? Are you certain that each dimension is resolved sufficiently?

Best regards,
Jan

[araeli]

Dear Jan,
Dear all,

sorry for the late I tried several tests in these days. I noticed that even though the STL file is intended to be interpreted in micrometers, it is treated as dimensionless in my case. Initially, I requested a number of cells that was too high for my RAM, so I started to reduce the domain size, and eventually, I created a very basic example.
I created a 5x5x5 domain
https://drive.google.com/file/d/16ppn1-Q-qHcpqL5afSLJi74MXikbur2Q/view?usp=sharing
The domain is essentially made up of cubes, so I expected the lattice to conform to these dimensions as well. However, I noticed that the mesh tends to ‘contain’ the domain rather than adhere to the edge, with the border vertices being both internal and external in the surrounding cells. Therefore, I have a series of questions, as I am working with porous materials where every approximation is significant:

-Is this behavior normal, or is it due to my poor use of the library?
-Is the excess always just one cell?
-Depending on the refinement (one slice in the figure https://drive.google.com/file/d/17Y5hOm8kHF_wEGSXES7g5QgLBqNmnmKt/view?usp=sharing ), it is not symmetric. The test presented here is at a 1:1 scale, but the ‘shift’ of the vertices is 0.25. Is this also due to a mistake in the library, or is it justified?
-Is there a way to force the boundary mesh to adhere to the vertices of the porous medium once they are given as voxels, thus theoretically already cubic and easily adaptable in structure?

Thank you in advance,
Alice

[jan]

Dear araeli,

Do I understand that your question is about the layer of zeros around the actual geometry you imported?

– Is this behavior normal?
Yes, this is normal. Without periodic boundaries, OpenLB sets a layer of 0 on the outside. (Feel free to check some examples).

– Is the excess always just one cell?
Yes, in many examples an extra layer is added to the geometry using IndicatorLayer3D (e.g. cylinder3d, line 336 in cylinder3d.h).

– Shift:
I think this is caused by the discretization? In OpenLB you only have the information if a certain point is inside or outside, and this information seems to match your geometry, doesn’t it?

– Is there a way to force the boundary mesh to adhere to the vertices of the porous medium once they are given as voxels, thus theoretically already cubic and easily adaptable in structure?
Is this related to the shift above? As mentioned above, this seems to be caused by the discretization. Maybe you can make the simulation domain “better” match your geometry (does the STL start at the origin or is it shifted a bit?). However, this discretization error should get better with increasing resolution. If it is your intention to keep a structure made up of smaller cubes, you could also consider using many IndicatorCuboid3D to create in the OpenLB case, like this it might be easier to align them with the lattice.

Best regards,
Jan

[Author]

Posts