I was working on benchmark problems using SwiftComp, but I almost always got this message from SwiftComp:
determinant of Jacobian matrix less than 0 for element 27595. The first several nodes of distorted element are: 202508 9.0000999999999998E-002 -0.21920999999999999 3.0281270000000000 202507 9.0000999999999998E-002 -0.1549780000
Basically SwiftComp will not run if there is at least one element that has bad quality. For this reason I had to manually search for the element that SwiftComp complains about and manually edit the element, which is very time consuming. Some of my benchmark problems, like wing structures, it’s not easy to get a mesh where every element is high quality, so it is pretty much unavoidable to have a few bad quality elements. It is even more tricky for quadratic elements.
Because having a few bad elements out of thousands (in my case tens or even hundreds of thousands) do not actually invalidate the homogenization results, I would like to see if there is any way to temporarily disable quality (determinant of Jacobian matrix) check so I don’t have to spend hours or days trying to fix some bad elements. It would be nice if SwiftComp only gives you a warning but doesn’t stop SwiftComp from running, just like how it would tell you some nodes are not periodic when you don’t have a strictly periodic mesh but you are using periodic boundary condition.
@Yu_Group
That is not a good suggestion. When it complains about a distorted element, it implies that the jacobian is smaller than zero. This is physically impossible, thus conceptually wrong. We are not sure that a conceptually wrong mistake will not affect the results. It will definitely affect the dehomogenization results in/close to that area. Periodic condition is different. Because if it is not periodic, it is just an approximation, not a physical impossibility.
Negative Jacobian is indeed not conceptually right, but I think the point is not saying it is right but rather whether it is practical.
In case of complex geometries, especially ones with tens or hundreds of thousands of elements, it’s generally hard to avoid a few distorted elements. In Abaqus, those elements may be flagged as distorted (sometimes it may not even flag them as Abaqus seems to have different standards when it comes to mesh quality check) but at least not “unusable” so you can still run the analysis but with warnings.
It seems SwiftComp is not as forgiving as Abaqus as it completely stops when a bad element is found and it only reports one bad element at a time. For example, if there are 10 bad elements (which is optimistic) hidden inside the mesh, I have to rerun SwiftComp 10 times to find each element that does not pass SwiftComp’s quality check, so each time going back to Abaqus, writing or running a script just to highlight the element by ID, and then manually editing the coordinates of the nodes. In worst cases you may have hundreds of bad elements, and you wouldn’t know this until you redo it over and over again to pinpoint all the elements that don’t pass SwiftComp’s quality check. At least warning the user about how many elements have bad quality can be helpful.
Also when when you need to deal with a strict periodic mesh, and bad elements happen to be on the periodic boundaries, you have to edit elements on both sides to make their coordinates match. If the elements are buried deep inside the mesh, you can’t directly select them in GUI and may need to manually search for the mesh data and edit the coordinates and you also need to know how to adjust the coordinates to make elements less distorted.
For these reasons generating a quality mesh can be very time consuming, also because SwiftComp doesn’t help visualize or select the element directly and you can only edit those elements by writing scripts in Abaqus.
And yes, it can be argued that a few bad element might compromise the dehomogenization results, but whether the result is considered acceptable should be up to the person running the simulation, as it depends on the problem they are solving and the goal they’re trying to achieve. But whatever they do, people running simulations may not have the patience to edit the element one by one like what I did.
As for periodicity, if periodicity is broken due to meshing issues, and it is supposed to use periodic boundary condition, the results might be very different based on my studies. The difference in stiffness matrix can be as high as 50% for major stiffness terms with only a few aperiodic nodes, say 5-10% aperiodic nodes for the wing structure that I studied. The actual difference would depend on the geometry (structure gene) you are analyzing.
a good way to learn is to identify which types of elements that swiftcomp complains as distorted elements), then work out the math and propose a rigorous solution, not just simply ignore them. I believe Abaqus is not just ignore them but has some ways to amend them. If you identify what type of elements that SwiftComp will complain, I believe Dr. Mao @kmao24 might be able to help us to find some practical/yet theoretical sound solutions.
I’m not sure if this applies to your situation, but when I developed gmsh4sc, I encountered similar issues, particularly the same error message. However, these issues are not typically caused by bad elements. In most cases, they stem from the mesh algorithm in Gmsh. In SwiftComp, the element connectivity must follow a counterclockwise order, whereas Gmsh may create elements with a clockwise nodal index. In Abaqus, both counterclockwise and clockwise orientations are acceptable. Again, I’m not certain if this is relevant to your model, but I wanted to share this information for your reference. Good luck!
Thanks for all the insights. For my case I think it is an element quality issue, because all the elements SwiftComp is complaining are indeed not in ideal shape. It is indeed possible that the order of nodes can be an issue for SwiftComp, and I’ve also encountered this issue while running SwiftComp. Also if the elements are supposed to 3D but the nodal coordinates only contain two coordinates because you accidentally selected cross-sectional analysis, and SwiftComp will also complain about a negative Jacobian but its not because you have bad elements, but it is missing another coordinate. I believe Dr. Su has also seen this issue.
What these mean is that, when SwiftComp complains about a negative Jacobian its not necessarily “distorted elements.“ So you have to find out if its you accidentally used the wrong command, or because you used gmsh, or you just have bad elements somewhere. It would be better if SwiftComp could tell what the problem actually is.
Finally, the real challenge is Abaqus can never guarantee good quality mesh when it comes to somewhat complex geometry, like in my case, I have a wing with trailing edge and a very thin skin, and ribs with sharp edges. There is no existing tool to modify the mesh, and scripting isn’t very effective to target those bad elements. Adjusting node coordinates for the existing bad elements are tricky as you don’t want to create new bad elements. Dividing or collapsing multiple bad elements are also tricky as you often don’t know how to divide, and editing them one by one is often not practical for a fine mesh. That is why I had to modify elements one by one. I know we are not supposed to have negative Jacobian, but for now I don’t really have a good solution to make meshing more efficient.
Also note that many times SwiftComp is fine with 8 node solid elements (C3D8 element), but when we convert to quadratic (20 nodes), it complains about distorted elements, so it seems using quadratic elements is more difficult.
I’m not familar with SwiftComp. If the complaints of the bad elements are not easy to be located, maybe you can convert the mesh to an Abaqus format, and do a datacheck (or a very basic analysis) to see if Abaqus can help you identify the bad elements.
Generally trying mesh nicely is a good start for any analysis. Sometimes we have to try multiple times during meshing.
@kmao24 Thanks for the comment.
The general workflow for SwiftComp is like this:
Create or import geometry → Meshing (usually Abaqus or Gmsh) → Convert mesh data to SwiftComp input file → Run SwiftComp
Since I am not expert in Gmsh, I chose to use Abaqus, therefore my workflow is
Import geometry to Abaqus → Meshing using Abaqus → Check mesh quality using Mesh Verify → Write inp file in Job → Convert inp to SwiftComp input file → Run SwiftComp
Since the mesh data comes from Abaqus I don’t have to convert to Abaqus format.
My issue is, Abaqus may not complain about those elements, but SwiftComp may. In my case mesh check on Abaqus sees no unusable element, but SwiftComp thinks it’s unusable. I can perform analysis on Abaqus but not SwiftComp, so mesh check with Abaqus does not help in my case. It does seem that SwiftComp is more strict about mesh quality.
Indeed trying meshing several times with different setting (like different partitioning, edge sizing, element type etc) may help but sometimes with complex geometry it still produces low quality elements, like sharp edges, thin-walled structures. The difficulty with SwiftComp is I don’t know if the quality is okay until I run SwiftComp (the last step in my workflow) so I have to edit my mesh over and over again until SwiftComp detects no unusable element.
You might have heard the famous saying about modeling: garbage in garbage out. Having a quality/correct mesh is the least to ensure the quality of the results. Particularly, if you are still in the process of training yourself to be an advanced FEA analyst (not replaceable by AI), you should not seek this easy out. Instead, use those indicators to understand how elements behavior and improve your skills to generate a good mesh with less trial and error.
After the discussion here, I thought let the code run through with aperiodic nodes for periodic structure is not good idea either. It might deceive the user to think it is not important and looking for errors somewhere else. Actually, they are important and your own experiences taught yourself a lesson (indeed, initially you don’t believe the small number of aperiodic nodes will cause so much difference, and looking for many other different reasons but not necessarily focus on creating a correct mesh).
What I learned about meshing is that it highly depends on the geometry, which requires different methods to properly mesh the geometry to avoid bad elements. The most effective methods is to use partition with edge seeds to “guide“ Abaqus to mesh the way you desired. This will avoid “blind meshing“ which significantly decrease the chance that you have to do trial and error. The only downside is this requires lots of patience but may pay off if it avoids remeshing/mesh editing back and forth.
And yes I do believe that we should not let SwiftComp run and generate a result if the user specify its a periodic structure but nodes aren’t actually periodic. Especially when the user cannot get a result from full 3D model with DNS to verify the result, using the result from aperiodic nodes could be problematic.