I am trying to generate a hex mesh of a microstructure using Parallel Sculpt. This microstructure has annealing twin structures, which I am using thin lamellae to represent. I have attached an example of this microstructure below.
I am having trouble with generating the mesh for the thin lamellae. I am currently running the following input file (through Python). As you can see, I have attempted adaptive meshing, but have not been successful.
Does anyone have any recommendations on how to mesh such a volume (including the thin lamellae) without using too many hexahedrons (< 10 million)?
Also, a somewhat related question: Does anyone know why I would not be able to run the mesh using multiple processors? I am running mpiexec -n 2 ~/cubit/psculpt.exe -j 2 -i sculpt.i in the command line, but keep getting the error below. It works fine when I use 1 instead of 2 for the number of processors.
The sculpt developer was kind enough to respond to your query. Here is his edited reply.
A few suggestions.
Pillow = 2
Pillowing curves won’t be effective in this case because the geometry is too complex. The objective of pillow = 2 is to put a pillow adjacent every curve in the model so that the “real” geometry can be captured. Since RVEs are generally statistical models, you don’t generally need to exactly capture every curve. In my experience, using curve_op_threshold = 0.25 gives sculpt more freedom to move nodes off of curves to improve quality if it can’t achieve a minimum quality. The 0.25 in this case is the SJ (edit: Scaled Jacobian) threshold at which sculpt will allow nodes to float off of curves if an SJ of 0.25 can’t be achieved. It’s normally set to 0.1 as default.
Instead of pillow=2, use pillow=3 or pillow_boundaries=true. That puts a pillow at each of the six RVE faces and is necessary when you are doing any refinement near the boundaries.
Capture = 2
Don’t use capture for this problem. Capture is experimental and guarantee geometry is too complex to use for capture
Smooth = 8
I would use smooth = fixed_bbox for this case. The smooth=8 option should be deprecated. This will force the boundary nodes to lie exactly on the RVE faces
Adapt_levels = 2
Adapt_type = 6
Adapt_type = 6 will refine anywhere the material changes. This is good for capturing material interfaces. This is OK to use, however for this case, because so much going on, I suspect the majority of your volume will be refined, once you add in the transition elements. Won’t hurt to try, and you may save some DOF (edit: degrees of freedom). I would start with adapt_type turned off and instead split the cell_size in half or a quarter. Compare with what the result is with the original cell size and adapt_levels = 1 and 2.
Defeature = 1
I would experiment with adding defeaturing. This will attempt to remove small clusters of elements and protrusions that are difficult for Sculpt to manage. It takes some liberty with the geometry, so you will want to monitor how much it changes from the initial volume fractions. When using defeature, I recommend using the compare_volumes option which will dump a chart at the end of your log that compares the volume fraction on input with the final volume of the hex elements. If you know what the percent of each material should be, the element block volumes should be approximately the same.
He had some additional questions and comments.
Is the geometry periodic? If you have real geometry that extends beyond the RVE that repeats at a period equal to the RVE edge length, then you can use the periodic option. This treats the domain as if it was an infinite space so that nodes on the left exactly match those on the right. Those on the top match the bottom, etc. This allows the smoother to do continuous smoothing across the RVE boundaries without having an arbitrary plane that the nodes must stick to. It results in some jagged looking boundaries but can improve element quality overall.
I would suggest they review the sculpt pdf document on the Cubit site that describes various cases for RVEs and to get some ideas and examples:
Regarding the processor question, we did make some fixes in Coreform Cubit 2022.6 that fixed some licensing issues with trying to run Sculpt on a cluster. Are you running sculpt directly from inside Coreform Cubit or are you running from the command line? If you are using the command line, make sure you specify the processors correctly.
Thank you for your very comprehensive response as well as the link to the PDF. The suggestions were great, and successfully reduced the number of elements, as well as the mesh time. While the mesh looks really nice, the min SJ value seems to still hover around -0.98 though. Is this a big problem?
(example of mesh with smaller volume)
Regarding your first question, the geometry is not periodic, though it is incredible that Cubit has the capability to account for such a geometry.
Regarding your second question, I am running Cubit from the command line. Specifically, I am using the subprocess library in Python to run the command, mpiexec -n <N> ~/cubit/psculpt.exe -j <N> -i sculpt.i, where <N> is the number of processors. Could this be an issue with the license I am using?
The negative Scaled Jacobian is likely a problem. It depends on your solver, but element is likely inverted or has zero volume. Either of these cases will create an invalid matrix in most solvers. You may need to tweak sizes or some of the parameters for sculpt. This is a difficult case.
With the mpi issue, what happens if you run mpiexec from the command line instead of from the python call? Do you have the same results? What happens if you run sculpt from inside the GUI and specify multiple processors.
I don’t think it should be a license issue if you are running multiple processes on the same machine. What OS and what version Coreform Cubit are you running?
The negative Scaled Jacobian is likely a problem. It depends on your solver, but element is likely inverted or has zero volume. Either of these cases will create an invalid matrix in most solvers. You may need to tweak sizes or some of the parameters for sculpt. This is a difficult case.
I believe so as well. The internal grain boundaries are very abnormally shaped. Using thicker (less statistically accurate) twins does increase the mesh quality. Using no twins basically eliminates the min SJ issue. Do you think adaptive meshing was the correct choice?
With the mpi issue, what happens if you run mpiexec from the command line instead of from the python call? Do you have the same results?
The same thing happens. I am similarly unable to run the meshing with multiple processors.
What happens if you run sculpt from inside the GUI and specify multiple processors.
I am indeed able to run with multiple processors. I am thus confused as to why it wouldn’t work with mpiexec.
What OS and what version Coreform Cubit are you running?
Windows 10 and 2022.04.
Regards,
Janzen
Edit: I installed Coreform Cubit for Windows, created a symbolic link into the Network drive, and used WSL2 to run psculpt.exe (linking to psculpt through the symbolic link). I just tried this on another computer, and it seems like I am also only able to run psculpt using a single processor. I think this is where the issue lies.
The suggestion from the developer was to initially turn off the adapt_type and decrease the cell size by a half to a quarter of the size. This will drive up the number of elements, but more elements will likely capture the geometry better and give more freedom to the meshing algorithm to improve the quality.
I don’t understand the mpiexec issue. If I start up PowerShell and execute
