P-9 Not enough memory for matrix solver

Victor

I don't have any other ideas for improving the solver, sorry.

100 MB of STEP file sounds like a lot more opportunities to defeature it. Usually, there will be a lot of details like fillets or small holes that hog elements but don't affect the results.

Do you have an aggressive size gradient setting in Meshing parameters? Interior elements can usually be much bigger than at the surface details.

When counting nodes, beware that CCX expands shells to solids so there will be more nodes than reported by Mecway - about 2x as many. But the counts reported by CCX are usually higher than what's really there.

disla

HI, pberry

“I tried changing the analysis type from Nonlinear Static 3D to Static 3D”

You are still in nonlinear analysis. Static GUI but NLGEOM=ON triggered by contact or some material nonlinearity.
Check all contacts are bonded Elastic or better Tied to perform a frequency analysis requesting only 6 modes to not overload the memory.

Remove the requested PEEQ-output until you solve the linear static problem.
You can keep second order but use reduced integration temporarily in case you aren't to speed the process.

There are other things to do but I would do this one’s first to discard other issues.

Ideally you could share your inp file to see if I have the same issue.

pberry

Thank you for the replies.

Victor, yes it is feature-rich, but I'm not sure how that I would significantly defeature it without altering its' fundamental behavior. It is a lattice of cables which both transfers load from a covering membrane to the underlying frame, as well as buckling support for the frame. The connectors are already simplified as octagons, which is where the bonded contacts are applied between the frame. I attached a couple of screen shots.

The only way I could figure to model tension-only cables for nonlinear analysis, is as very thin flat ribbons, so I had a reasonable surface to apply the load (for modeling, the overlying membrane is excluded), and they should just buckle out of the way should compression occur.

I have already run partial models to reveal local bucking issues. Now it's time to look for global buckling, which I can already see three failure modes, but want to quantify them to see where to best apply additional reinforcement. Loading the entire model for this resulted in the RAM issue.

Initially I meshed this as a surface, but CCX failed with hundreds or thousands of "inverted normal" errors. Meshing as solid resolved the CCX errors, but I had to give it a finer grain to eliminate meshing errors.

disla, I did not activate PEEQ, that was done by....?. May be some way to override it off. Will have to investigate. For the last solve, I removed contacts with the frame just to see if it would solve, but still no. Thanks for the offer to test it on your system. However, after reading this and trying a few more adjustments, I think maybe I should really be asking how I could model this better, rather than how I can solve this one.

Suggestions for better modeling of a cable lattice?

Victor

Wow, that's definitely a challenge.

I'd be skeptical of any solution from that mesh with the high aspect ratios of the elements.

If these are shells, make a quad-dominant mesh instead to reduce the node count. They'll likely perform better with the high aspect ratios too. If they're solids, mesh it as a surface mesh and extrude to hex20 solids.

I guess you can't use beam elements? That would save a lot of nodes and should should be able to use tension-only with custom CCX cards. Or spring elements if you don't need rigid connections or any bending stiffness - spring elements in CCX are very efficient since they don't get expanded to solids and don't suffer from the bugs that sometimes affect beams and shells. If you can do it with springs, you can also use the internal solver (possibly as truss elements instead) for linear buckling.

Another thought, could you treat the whole grid as a homogenous material with special anisotropic properties? Perhaps by loading a small (flattened?) patch in all directions and characterizing the equivalent material's elastic properties from that?

If your global buckling modes have any symmetry, you could delete the redundant half/quadrant/etc.

pberry

Those elements no good? I was just happy to finish meshing without a screen full of red Xs. The cross section of that piece isn't all that different from the parts which meshed 'normally'. It seems that gmsh can be orientation sensitive in how it meshes, or slight geometry differences can make it decide to do something way different.

I'll explore those other element options. They do sound better. It's been a balance between what I think will represent the structure accurately, and avoidance of performing manual operations thousands of times.

Apply special anisotropic properties and characterize the material? I'm almost guaranteed to screw that one up, but I'll keep the option in mind.

There is symmetry in the buckling behavior, but if I just model a quadrant, I'm not at all certain that I can give it valid boundary conditions without just loading the entire model to provide them. I wouldn't want to inadvertently eliminate that 4th buckling mode that I haven't anticipated.

Thank you for your help and suggestions,
Paul