I'm modeling a thin-walled tube space frame imported as STEP. Actually 1/12th of it, because I'm hoping to use cyclic symmetry to fill out the rest. Much pain getting it to mesh. Finally I turned off the fit midsides to geometry and got a mesh of about 2.5M nodes, but the material configuration was asking for a thickness even though it is a solid. That simulation failed with many non-jacobian errors (presumably the thin wall was not adequately represented). So I re-meshed with smaller elements, and found another solution at 8.5M nodes. Set up a quick test, and CCX is grinding away on that now, so it seems to be a good mesh. Running about 92% of 32GB, and 25-60% of 12 cores, and this is not even the real (larger) simulation. Is there an economical way to mesh thin walled tubing? Eventually the analysis will be non-linear with all possible stresses.
I assume the 1 million node spec for Mecway just refers to the internal solver....or will I be running into some other limit when going over that size?
Comments
It sounds like you should be using shell or beam elements, perhaps with solids just for a few places like joints where you're concerned about the stress. That will have a much smaller mesh. The automesher's tets are very inefficient for thin-walled parts.
You can make a shell mesh by first making a surface mesh, then deleting the surfaces you don't want to use (ie, ends, inside surfaces). But perhaps you can export the members it as .dxf lines from CAD to make a beam mesh?
> "but the material configuration was asking for a thickness even though it is a solid"
That means at least one element is a shell not a solid. If there was an error message popup after meshing, it may have left just the surface mesh. I do need to clarify this error message because it's pretty confusing. You can identify the shells using Edit -> Select elements by... and select the 4 shell shapes (tri3/6, quad4/8).
Many analysts* successfully use RBE2/RBE3 (Kinematic/Distributed Couplings), i.e. "Spiders", to transition between beam elements and shells. Just transition far enough back from your joints (St.-Venant) and you'll be good. Beam elements also useful to inform the loadings of stand-alone submodels of design.
* This guy, for one:
Reference: Youtube NAFEMS channel.
Because of the goal of the analysis, it seems to me that I can't use increasing density or using different element transitions at areas of special interest. The frame is all non-linear curves, and essentially 'everywhere' is of special interest. I'm trying to optimize the tubing dimensions to prevent local and global buckling. Is there one 'most efficient' element type to accomplish this?
If you do use solids, you'd get a lower node count with hex20 or possibly hex8 (with reduced integration?). You could form the mesh with Mesh tools -> Sweep starting from the section shape and line3 elements defining the curve of the tube and bonded contact at the connections. It could be a lot of manual work though.
Victor, that model exited the solver.....good?? CCX seemed happy, but I'm not getting any results displayed as far as von Mises stress, or displacement or I'm guessing anything else. The distorted view shows no change. The test I ran is meaningless, as I simply applied a constraint and load in order to see if the mesh was really any good. However, I think that it was valid enough to produce some output.
The input file has lots of numbers in it (technically speaking). The file size was about 840MB. Just meaning that the solver did have something to work on.
Is there a way to determine where it when bad? I only see my models getting larger. 1TB RAM PC is on the way. I hear you saying that this stuff is too big....I'm just not a good listener...until something actually breaks. I don't think that a lot of manual work is going to be a solution. Both because it would take a ton of time every iteration, and because I don't venture beyond algebra and trig unless there's an Excel function that covers it.
************************************************************
CalculiX Version 2.19, Copyright(C) 1998-2021 Guido Dhondt
CalculiX comes with ABSOLUTELY NO WARRANTY. This is free
software, and you are welcome to redistribute it under
certain conditions, see gpl.htm
************************************************************
You are using an executable made on Mon Aug 14 18:47:44 PDT 2023
The numbers below are estimated upper bounds
number of:
nodes: 8504238
elements: 4078756
one-dimensional elements: 0
two-dimensional elements: 0
integration points per element: 4
degrees of freedom per node: 3
layers per element: 1
distributed facial loads: 195820
distributed volumetric loads: 0
concentrated loads: 0
single point constraints: 3492
multiple point constraints: 1
terms in all multiple point constraints: 1
tie constraints: 0
dependent nodes tied by cyclic constraints: 0
dependent nodes in pre-tension constraints: 0
sets: 3
terms in all sets: 8353720
materials: 1
constants per material and temperature: 2
temperature points per material: 1
plastic data points per material: 0
orientations: 0
amplitudes: 2
data points in all amplitudes: 2
print requests: 0
transformations: 0
property cards: 0
STEP 1
Static analysis was selected
Decascading the MPC's
Determining the structure of the matrix:
number of equations
25509222
number of nonzero lower triangular matrix elements
845410095
Using up to 1 cpu(s) for the stress calculation.
Using up to 1 cpu(s) for the symmetric stiffness/mass contributions.
Factoring the system of equations using the symmetric pardiso solver
number of threads = 1
Solving the system of equations using the symmetric pardiso solver
number of threads = 1
Using up to 1 cpu(s) for the stress calculation.
Job finished
________________________________________
Total CalculiX Time: 7851.028883
________________________________________
I think I've seen all zero results before with either too big a mesh for the memory or too big for Pardiso/CCX, hard to tell which.
You might need a version of CCX compiled with ILP-64 aka i8 (8-bit integers). Your problem has 8e8 nonzeros which is getting close to the 2e9 limit of signed 4-byte integer array indexing. After fill-in, it would surely exceed it.
The next version of Mecway (23) will be able to correct badly shaped elements by straightening the midside nodes of the bad elements only. This also solves the random spike problems if they're the midside nodes. I can give you an early version in a few days if interested.
Yes, I would like to try out the early version!
Ok, so unless I get the mesh size down, I'm headed for adventures in compiling. For some reason it sounds entertaining...must be the coffee and cake high I'm on right now.
I'll see what the forum file limitations are, and post something. Nothing is very small.
Thank you
I attempted to preoptimize the diameter and wall thickness dimensions by modeling some straight sections. The bracing and loading will not be the same for the curved model, but it was a start. The small octagonal bosses are for mating to another part via bonded contacts (yes, there are even more elements to the model). These may be the main perturbation in the meshing flow. The boss geometry was mainly dictated by the limitations of the CAD's lofting ability, and the ease in which the load could be assigned to all of the many faces. There have been a lot of tradeoffs while attempting to generate a valid model that doesn't require thousands of manual operations...for every iteration.
Specs for this little piece:
Longest axis ~41 in
Surface area = 828.2859 in2
Volume = 3.9192 in3
So now it should sound like even more elements than before.
For some reason the exported step files have some weird surfaces, so I clean it in Salome to have only one surface for each tube. Then can be easil meshed in Mecway using shell elements. Be aware that in case of using simmetry boundary conditions and CCX solver could lead to bad results, I personally would use a solid mesh extruding the basic shell elements.
When I started this FEA adventure, I didn't know that meshing would present so many challenges. Perhaps the recent acceleration of AI will prompt someone to build an intelligent mesher.
https://mecway.com/download/mecway230_Beta1.msi
The relevant new feature is an option in Meshing parameters called Straighten bad elements which is on by default.
To begin with I want to acknowledge that the program claims to be good for "up to 1 million nodes". And that it does great for that and even more.
But.... I keep running into geometry that requires a lot of elements to mesh directly from CAD, even after simplifying it for modeling. The tubing issue above is reasonable to generate as suggested by Sergio, and that was a big help. However, other parts are going to be too time consuming to build directly from elements. So, I'm hoping that there is a path forward for working with larger meshes.
I have upgraded my RAM to 1TB, and it seems that I will have to compile Calculix for 8-byte integers somehow. I'm trying to move forward one step at a time, which brings me to here....
I meshed a portion of my CAD geometry, and extrapolated the likely quantity of nodes required to do the entire model, and it is several M nodes (I'm kind of embarrassed to say the actual number, but it is way over spec). So I run the entire mesh, and it completes in maybe 30 minutes, and gmsh writes the file and exits. Then I get the Windows swirl for 2 days (so far), with no clue as to whether it will complete whatever it is doing in my lifetime, or not. I haven't asked it to solve, so it's just working on the mesh render? Is there any way to know how far along it is? The RAM and CPU are both running around 2 or 3%.
Also, the ability to display the geometry preview quits working at some model size.
Is it just a fool's errand to try and work with meshes this large?
Paul
The geometry preview is set to give up after 2 minutes in case the triangle mesher gets stuck. But I notice on your 1 and 2 half tube model, it fails before it reaches the timeout, so there's something wrong there I don't understand.
There's certainly software that can handle 10's of millions of nodes when you have that much RAM but I'm not sure Mecway will be able to. Maybe you should use Gmsh and CCX directly. I think CGX can convert the mesh format. Apparently Gmsh can export .inp format too. The graphics in Mecway are going to be hopelessly slow even if you can get it to open anything.
I do admire your persistence to brute force it! Sometimes old-fashioned techniques like optimizing element types linger on beyond their usefulness.
You need a model that can be solved in a reduced time, because as you have to many parts that need to be joined by TIE or other means, if you have to wait hours or days to solve, and find out that some parts fly over due to lack or bad boundary condition, you will have to adjust and run again, several times... that will make you lost a lot of valuable time.
Yes, your time to mesh surely is more expensive than the CPU time, but trying to solve by brute force will lead to a no result situation, that is your worst (and actual) scenary.
If is needed more accuracy in some areas, then they could be refined in further analysis, once the basic model is running well.
It sounds like it's not unreasonable to do this, but the path isn't going to be as quick and easy as I would like.
The application seems locked up (the PC still responds otherwise), but previously I've had smaller (still large) models get stuck at this point for hours. Then the mesh would render, and I could move forward. If it was grinding away with resources, things would seem normal. However, the performance tab in task manager indicates that everything is mostly dozing off, relative to the available resources.
It appears that the easy analyses are behind me, and it's a matter of choosing my poison now....which task I want to spend significant time on.