STL file not read

Hi everybody,

I hope this email finds you well.

I seek help for understanding why no facets are detected in an STL file I have generated with a python code. This STL file is in ASCII. The bug report is attached. I have MFiX 25.3 on Ubuntu 22.04.

Basically, I would like to have a simple DEM simulation. In a domain box ranging between (0,0,0) and (0.1, 0.3, 0.1), I put a closed rectangular box (my STL file) ranging between (0.01, 0.01, 0.01) and (0.09, 0.29, 0.09) so that the physical box walls are strictly inside the domain box. Then, inside the physical box, I create a small region containing particles. When simulation starts, the particles should just fall on the floor of the box. No fluid.

Is there something wrong in the content of my STL file ?

Thanks in advance for your help (I already read a lot of topics on the forum, without success. Same with User Guide)

four_2025-12-15T213642.087560.zip (75.9 KB)

bonnefoy speaking, again :wink:

to say that, after converting the ascii STL file into a binary STL file (with a Python code), all facets could be read in displayed correctly in the Model View but that, on running my case, all facets are tagged “IGNORED”. When looking at “get_stl_data.f” file, it seems that the error comes from the fact that the angle is smaller than tolerance. After a slight modification of the ‘get_stl_data.f” file for debugging, it appears that the vertex coordinates (values V1x,V1y,V1z,V2x,V2y,V2z, V3x,V3y,V3z) are here all wrong, whereas they have bee correctly captured from the STL file to produce a nice 3D view in the Model. Are there two places in the code, where STL files are read ? How is it that one is succeeding (for 3D graphics) and the other one (for tagging the facets valid/invalid) not ?

and again bonnefoy (myself):

both ascii and binary STL files are correctly read and displayed in Paraview.

Hi @bonnefoy Welcome to the MFiX forum.

As you have guessed, there are different STL readers involved. In the GUI front-end, which is written in Python, we use the VTK library. Paraview also uses this library, but possibly a different version.

In the backend (solver) which is written in Fortran, we use our own home-grown STL reader which can be found in model/cartesian_grid/get_stl_data.f

I’m not too surprised that the different readers have their own quirks. I’ll look into this and get back to you when I have a better idea what’s going on.

– Charles

When I run the setup you attached, the error message says you did not associate the stl file with any BC. If your wall geometry is rectangular, you should no use an STL file, just use the regular BCs. You can even check the box “Define default walls at domain boundaries” in the Boundary Condition pane to define walls all around the box.

Now if you use an stl file that is basically a rectangle and you align it with the grid lines, this will not create cut cells and the meshing will fails. Another reason why you should not use an stl file for this application.

Thanks both of you, Charles and Jeff, for your first replies !!

What I understand is that there must be at least one cut cell when using an STL file.

So, I tried with another STL file, a little bit more complex than a rectangular box: a quasi 2D sandhour, which will force the creation of cut cells.

The same symptoms persist when using an ASCII STL file:

  • I read “Number of selected facets = 0” in the “Regions” pane
  • no visual rendering in the GUI front end.
  • at runtime: I receive “There are no facets selected with region silo_walls. Please make sure this is a valid region on the region pane.” even if I have set a NSW BC at the STL walls

Attached is the bug report for the sandhour ascii STL file.

Any idea about the constraint that I should respect and forgot to ?

Olivier

five_2025-12-17T153500.128384.zip (301.1 KB)

I can see the STL in the GUI model viewport. Maybe make sure the geometry and regions views are toggled:

I am not sure why the facets are not selected by default, but I went to the selection shape, and re-selected “all” and now I can see 264 facets are selected.

A couple more things:

  1. You defined a Reservoir region but you are not using it. Particles are initialized in the Background region. If you want to use the Reservoir region, keep the background region (it is used for vtk output) but set a zero solids fraction. Then add the Reservoir region as an IC region and set the solids fraction.

  2. There is a known bug with default BC, so go to the BC pane and check the box “Define default walls at domain boundaries”

Hi Jeff,

thanks for your help.

As shown below on the screenshot, the two “Geometry” and “Regions” are toggled ON … but this does not help rendering the STL file on my MFiX installation.

I tried the “All” select/deselect/select trick, but without more success. To be noted: “Full” is grayed when “All” is selected".

Understood for the Reservoir. I did it in previous attempts.

OK for selecting “Define default walls at domain boundaries”. This does not help further in the STL file rendering.

five_2025-12-18T110819.560271.zip (214.6 KB)

I am not sure, I cannot reproduce, your latest file works fine for me. Maybe try to delete the region and add it again.

Hi Jeff,
I re-installed Ubuntu and MFiX 25.3 and did the whole process again from scratch. Still, there is no facet selected, so I cannot visualize the geometry in the GUI. It happens also with the “screwfeeder.stl” file that I found in a tutorial provide along with the mfix code.
Any idea what I do wrong ?
Olivier

one_2025-12-22T140249.028912.zip (2.1 MB)

I am not sure, I cannot reproduce. Can you please try with another MFiX version, say 25.2 or 25.1?

I tried with 25.1.2 and got the same result, i.e. no facets selected and no visual rendering in the GUI.
Could that be because my conda installation through Miniforge3 is conflicting with Anaconda ?
Also, my STL uses point as decimal separator when I open with a text editor but, in the mfix environment, when I type:
locale -k LC_NUMERIC
I get:
decimal_point=”,”
thousands_sep=“ “
grouping=3
numeric-decimal-point-wc=44
numeric-thousands-sep-wc=8239
numeric-codeset=”UTF-8”

Yipee !!

Last intuition was correct. After changing locale to en_US.UTF-8 the STL could be read and properly rendered.

Wish you a nice Christmas time !

Kind regards, Olivier

Excellent, this is great findings! This is good to know. No wonder I could not reproduce!

Merry Christmas!

We can force locale to en_US.UTF8 in the STL reading code. I’ll add this for 26.1

1 Like