Atom topic feed | site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban
You are not logged in.
Hello,
In my current study I was testing (bi-)quadratic elements and I used LIAISON_RBE3 for the first time.
In this analysis I was testing a rack, to lift a shaft. This shaft is supposed to be carried by the hull on the lower end of the construction (see attached picture).
In order to not add artificial rigidity to the model, I wanted to use LIAISON_RBE3. 1 master-node and around 80 000 slave nodes for the three translational DOFs.
This LIAISON_RBE3 wanted a whopping 425Gb of RAM! I did the analysis using a commercial solver on my workstation at home (32Gb of RAM) without a problem. Of course the Code_Aster implementation will be different (code-wise) than in NASTRAN-based solvers, but this huge difference in resource-consumption gave me pause and I think I made a mistake somewhere in the application of LIAISON_RBE3.
Attached is the .comm and .mess file, as well as a screenshot, that gives an idea of the nature of the problem.
Thanks in advance,
Jonas
Last edited by jonas loenartz (2021-12-10 12:48:48)
Offline
My bad, the .comm file I attached is an earlier state.
Here are the recent files:
Offline
Hello Jonas,
I have had similar problem in MSC Nastran - the calculation didn't run. The solution was that I had to decrease the spider (independent or slave nodes). Maybe the formulation of LIAISON_RBE3 is similar to RBE3 from MSC NASTRAN. I didn't investigate the differences among other software but at least it seems that in Ansys the deformable MPC are more effective than RBE3 elements in MSC Nastran.
Have a nice weekend,
Jan
Offline
Thank you very much for your reply. I think you are right. I substituted LIAISON_RBE3 for LIAISON_SOLIDE (thus adding the unwanted rigidity) and the study ran to completion, but it took over 10 hours for a run, that should have been 10 minutes at most. The results were physically plausible. I think the sheer number of nodes (around 80 000) is the problem here (for *SOLIDE as well as for *RBE3). I haven't had any issues, when the number of nodes was considerably lower.
I will run some more tests, but preliminaryly what I draw from this is, that LIAISON_RBE3 as well as LIAISON_SOLIDE are meant to be used on a small number of nodes. Otherwise the calculatioin time or the ressource-consumption gets out of hand. I will have to overthink the way I build my models and especially the way to transfer loads.
Can anybody recommend an 'asterian' way, to do this? My next step, would be to test discrete elements of stiffness to connect point-masses to the mesh for example.
Offline