Under the SMS mode, once I set the cell number in each direction large, the following error will pop up. Could you please tell me the meaning of that, what incurs that and how to fix it? Thank you.
The file FACETS_READ.stl was successfully written.
and is provided for convenience (it is not used).
MFIX WITH CARTESIAN GRID IMPLEMENTATION.
RE-INDEXING IS TURNED OFF.
INITIALIZING VELOCITY NODES...
ESTIMATING POTENTIAL SCALAR CUT CELLS...
INTERSECTING GEOMETRY WITH SCALAR CELLS...
At line 735 of file C:\Users\Admin\miniconda3\conda-bld\mfix-solver_1627537308023\work\model\cartesian_grid\get_cut_cell_volume_area.f
Fortran runtime error: Index '1047033408' of dimension 1 of array 'list_facet_at' above upper bound of 820328
Thank you Jeff, yes this question is related to the other post about meshing to which you have provided a correct example and attached the file. But I want to know the underlying reasons incur this question, thank you.
I am using the latest version of MFiX, when I try to generate the mesh under SMS mode, the error appeared up persistently. Could you please give me some hints to explain that? I hereby attach the .stl file and .mfx files. Thank you.
Ju - these sort of âout of rangeâ errors often occur when a particle accidentally leaves the domain. Sometimes this happens when the particle velocity is too high, wall collisions can be missed. Also meshing failures can cause behavior like this.
The MFiX solver does not do bounds-checking on all array accesses, as doing so would slow down the simulation. However for debugging you can try building a solver with the -fcheck=all compiler option as shown below
(note,this option should probably get enabled with the Debug build type but the build script does not currently do that, Iâll change that for the next release).
Building with this solver option may give more information about your failure. Let me know if this helps.
Thank you Charles, I hereby attach the snapshot for the error as well. I am using control point method in the following snapshot, sometimes, both uniform mesh and control point meshing will have the indicated errors. And I want to know how and where to set the compiler options to enter the debug mode? Thank you.
Please see the screenshot I posted. In the build popup, set âBuild typeâ to âCustomâ, then you can enter -fcheck=all on the Compiler flags line.
Thank you Charles, maybe my GUI is a little bit different from yours. You can see my screenshot. I want to know whether I can directly type in flags in the âbuild commandâ line.
Is that 21.3? You should have the âBuild typeâ control, Iâm not sure why itâs not showing up. Can you please go to the main MFiX menu, click on âAbout MFiXâ, and paste the results?
You can try building a debug-enabled solver from the command line. Go to the project directory and run:
I cannot reproduce the error on Linux. However, some geometric details are smaller than the grid spacing and this is probably the cause of the error you see.
The first step in meshing complex geometries is to inspect the stl file: make sure it is clean (water tight, no collapsed triangles, normals are consistent and pointing in the correct direction), and be aware of the smallest geometrical detail. The background mesh need to be smaller that the smallest geometrical detail. This means you need to refine the mesh, either locally of globally. Based on this, you can see if the number of cells will be affordable. If it isnât then you will need to simplify the geometry. My guess is you wonât be able to run this on a Windows PC.
Iâm sorry, I should have remembered that the âBuild typeâ control is not present in the Windows version of MFiX. I will address this in the next release. In the meanwhile you can try to build a debug-enabled mfixsolver using the build_mfixsolver.py command as described above (and in the user manual)
Thank you Jeff. I want to know whether the size of each cell everywhere should be smaller than the smallest geometries, that means apart from the uniform meshing, even if I use control points, the size of largest cell should be smaller than the smallest geometries. Otherwise, can I only control the largest cell size of background mesh around the geometries with the smallest scale smaller than the smallest geometries? Thank you.
I use control point method this time, and this type is error is persistent. I hereby attach the .mfx file. Could you please help me have a look at it (the .stl does not change)? I am not sure whether I have missed anything related to the method. Thank you.
The mesh needs to be smaller than the geometric detail near that detail. It can be larger elsewhere.
You missed the following steps:
Inspecting the stl file. Is there any collapsed triangle, duplicate edge/vertex, missing triangles? Are all the normals pointing in the correct direction?
Be aware of smallest geometry. I still see some areas where the mesh is larger or about the same size of the internal tubes.
You will not be able to proceed until to spend some time on the above.
Hey Jeff, Thank you for your reply and reminder. I have checked the above two steps as you said. And they are both fine. But the âindex dimension1, above upper boundsâ error persistent, so then I adjusted slightly the paras such as increasing dot product tol, etc, and obtained the following result, which gives better meshing quality for the small geometries than previous attempts. So I want to know whether there exists a systematic tutotial instead of trial&error to let us know how to coordinate the paras of cut cell method and cell numbers/control point positions. Thank you.
Hi Jeff, could you please help me figure out how to fix the tiny defects that can not be detected without zooming. I have tried different set of paras for cut-cell method but not obtain a perfect mesh. And @cgw also has helped to fix a bug with bug report I uploaded. Thank you.
And when I slightly adjust the sets of related parameters of cut cell method, I found out some of them are self-contradict, that means one specific param is suitable for one part of geometry while incurred defects in the other parts of the geometry.
So I want to know 1. whether there exists a standard procedure to generate acceptable and convergent mesh when the .stl model has already satisfied the two key points you mentioned above. 2. whether there exists meshing methods available for the MFIX apart from cut-cell method. 3. how can I thoroughly inspect the stl file. to find out the existence of any collapsed triangle, duplicate edge/vertex, missing triangles? Thank you.
It turns out your STL file is not clean. There are many duplicate vertices/triangles. Please see attached. My recommendation is you start with much simpler models to get familiar with the procedure. See 3. Tutorials â MFiX 21.3 documentation for some examples. For non-rectangular geometries, the cut-cell method is the only option. To clean your STL file, use the CAD sofware you used to generate the file, it should have options to remove duplicates and recompute normals.
What worries me in your simulation is that the inlet velocity is quite high (around 9 m/s) for the size of the inlet tube (around 2.5 mm), and you have many other tubes smaller than 1 mm, so you will end up with very large velocities that require tiny time steps (see picture below). In the attached, I used a grid spacing that will get you the bare minimum to resolve the internal tubes, and I had to use fairly large values of the snap and small cell tolerances to get it to run (you may be able to find a better combination that work too). I also removed duplicates in the stl file, which went from 2894 triangles to 1298. It still has many stretched triangles, and you need to set a facet angle tolerance to zero or close to zero so no facet is excluded. You want to see this
Total number of facets read = 1298
Number of valid facets = 1298
Number of ignored facets = 0
If you have ignored facets, this will create holes in the stl and the meshing will likely fail.
Thank you Jeff, but when I load your updated .mfx and .stl, the âindex, dimension 1, above upper boundsâ type error happened again, and I did not change your settings and the .stl file. So I wonder whether there exists some stochastic effects to incur error in one computer while run meshing normally in another computer? Thank you.
And when I just copied and pasted your clean .mfx and .stl files into a new project and open the project by clicking its .mfx file, the error reported in the following link happened. I remembered this kind of problem happened just after I deleted the mfix21.2 and installed 21.3 version. And there is no bug report generated currently. Thank you.
