Can I do better than an 8.5M node mesh?

pberry

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?

Victor

I wouldn't have much hope for 8 million nodes on 32 GB of RAM, or even with any amount. I'm not sure what the limits really are but it depends on the matrix solver (Pardiso/Pastix/Spooles) and amount of RAM.

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).

cwharpe

Big vote for the beam elements into shells at areas of interest, for reasons of node economy, improved solve times, and easier model inspection.

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.

pberry

Thank you for the responses!

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?

Victor

Beam elements can capture global buckling and perhaps you can use the internal forces and bending moments from the solution to find local buckling using hand calculations in a spreadsheet or the formula feature in the solution?

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.

JohnM

The 'needs a thickness" likely means the mesher only got through the surface meshing. I would try and identify where the mesh is struggling and see if you can improve the CAD Sometimes it is one little blend that makes it choke. You would not want to expand and 8M elements into 12 sectors

pberry

John, It seemed to be struggling in a lot of places....too many to deal with manually. Even after meshing left only 1 red X, I could see a lot of severely distorted elements. I'm not sure that I can de-feature it further to reduce transitions, but will think on it some more. I had to set the 'min size' close to the 'max size' in order to keep it from making long spike elements. Maybe it's the nature of meshing a thin solid? Anyway, I'm discovering that as the element size approaches molecule dimensions, the mesh becomes perfect and convergence studies are no longer necessary. Just have to wait for the pocket super computers to be released for this holiday season.

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
________________________________________

Victor

Good on you for refusing to accept the old fashioned ways of scrimping on computing power

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.

Sebastianmaklary

Ooooh, that teaser for Mecway 23 is very interesting! Looking forward to it!

Sergio

Can you show or share the geometry? It's a lot of elements!

pberry

Sometimes a bigger hammer is the most appropriate solution. Other times it's just fun to own a giant hammer. Not sure which applies here. BTW, used/good hardware on ebay can be surprisingly inexpensive.
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

pberry

The STEP should be attached for your meshing enjoyment. This is from a significantly scaled down version of the part, and then is only 12th of that. I guess the thin wall is what's killing me. However, buckle resistance with maximum specific strength is the goal, and I think tubing is the only practical way to get there.

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.

Sergio

I just recreate the basic tubes as surfaces in Solidedge (I would not consider the small hexa features, too small compared against the tube, at least for an initial analysis), using a simple sweep with parametric sketchs (circle and elipse for the path), then export as surfaces to Mecway to mesh.

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.

Sergio

I just note that you need the hexagonal nuts. I would model separately as solids and join with TIE boundary conditions to the tube. For more accuracy, in the CAD the surface around the nuts could be splitted in order to be selectable in Mecway for doing a mesh refinement. Even the lower surfaces of the nuts could be modeled including the curvature of the tube to ensure that the TIE works better.

pberry

Hi Sergio, thanks for working on this for me! It seems that I painted myself into a corner early on, with certain choices that I made while adapting the geometry for modeling. At this point, it's a bit of a duck-billed platypus. I'll start over from scratch, utilizing your suggestions. I normally depend on the CAD functions to build a solid, but in this case it looks like extruding from a surface mesh in Mecway is a much more economical approach.

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.

Victor

@pberry any anyone else, here's v23 beta 1

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.

Sergio

It works very well, have tested with a simple aluminium rim. Thanks for this update

pberry

Thanks for the beta. Looks like it will salvage some of those "almost good" meshes.

pberry

I think this is still an appropriate thread for this, so...

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

MikeMcMullen

I routinely work with meshs of about 2M nodes (using quite a bit of page fileing). They take a couple of hours on my 64 GB machine, though I usually run non-linear which is much much slower than purely linear problems. At this size viewing mesh or results can get bogged down depending the video card. Note time to process may have a component that is proportional to the cube of nodes, and memory is probably a function of the square of node counts. I did once run an out of core version of 4M nodes that took about 24 hours. You may have barely enough memory for an 8M mesh run, running partially out of core, but be prepared for it to run for several days. Note output files are huge, and graphically viewing them requires a lot of GPU ram. The project that developed Pastix for Calculix had 1 test problem that had 4.83 M nodes that ran on an 8 core Zeon in about 5 minutes. The report did not mention the Memory in the machine.

Victor

@pberry it sounds like it's locked up. Loading the mesh should take time proportional to the number of nodes or elements and this sounds way longer than that. For comparison, I just made a 2.3 M node mesh that took 2.5 minutes from the end of meshing until it was displayed in Mecway.

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.

Sergio

I would mesh carefully every element separately, maybe using Salome to get more control on mesh creation and node/element count, trying to use hexa elements where is easy to set up. Could take one, two, three days, but will finish with a model that can be solved, in a razonable time, at least for global displacements and to get a feeling were the more stressed components are located.

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.

pberry

Thank you for all the feedback. It is much appreciated.

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.