I ran the SMS meshing tutorial successfully (#3.8) and I was mostly having success with this workflow for my own .mfx input files, but the mesher seems to have suddenly stopped working. It now blocks all cells and produces no fluid cells, despite seeming to run the other checks correctly. The only difference I’m seeing between the tutorial case output and my case output is this error message:
WARNING: UNABLE TO PROPAGATE F_AT ARRAY FROM myPE=. 0
THIS USUALLY INDICATE A RANK WITH NO ACTIVE CELL
YOU MAY NEED TO ADJUST THE GRID PARTITIONNING
TO GET BETTER LOAD_BALANCE.
I ran both cases on my PC in the same general directory (subfolder to my user folder in the C:\ drive), so I don’t see why there would suddenly be a processor communication issue…
If anyone has any ideas, please let me know!
3dpseudo_mixingslice_flucAll_kSIM2hSIM_triTest2.zip (12.3 KB)
You are in a case where all intersection points between the STL file and the background mesh occur at a cell corner, and there is no information to propagate. Increase the number of cells in the z-direction from 5 to 6 and you will start seeing the mesh. This is too coarse though, you may need to get to at least 48x24x8 to get decent resolution.Don’t use multiples of 64x32x10 or else you will get into the same issue.
You also need to define boundary conditions along the left, right, front and back walls.
Jeff,
I see, in that case I think I have some fundamental misunderstandings about how to use the cut cell meshing method.
I thought STL facets intersecting the boundary mesh was desirable, because when they don’t, the boundary mesh generated only approximately represents the boundary (like in the screenshot below). A triangular prism seems like a very simple shape, why does the cut cell method require several mesh cells deep to resolve it when a triangular prism can be represented using just one mesh cell in depth, as mostly regular hex cells with cut cells only on the hypotenuse?
My “regular” input files have periodic boundaries in the X and Z directions, which is why I left those regions undefined.
There is a limitation with the stl file preprocessing where we propagate values at the cell corners (positive means outside the fluid domain, negative means inside). In your case all values are initially exactly zero (every stl intersection between the stl file and the background mesh occurs at a cell corner). This could be remedied by adding a seed point (not implemented yet). The second issue is the boundary conditions are applied using a ghost cell on the other side of the wall. If you have only one cell between two walls, then the same ghost cell will be used and that will break the application of the BC.
Ahh okay, that makes sense. I definitely need to spend some more time studying the cut cell method. In that case, I think what I want to do would be more feasible with a series of UDF-controlled “wall particles” that simulate my sawtooth geometry. I will try both approaches and see which works best, thanks a lot for your help!
