Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations pierreick on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Rigid elements using Bar/Beam elements 1

Status
Not open for further replies.

RAFIKUS003

Mechanical
Jul 17, 2010
4
Hello,

I am trying to run a model on Femap made of beam elements. One of the materials of these elements is with very high Young modulus (to simulate a rigid structure).
I could not succeed to make the model working because of this difference in elasticity modulus between two elements of different materials.
Beside using RBEs (Rigid body Element type 2 or 3) elements, what could be the best to simulate rigid beams? Could anyone help me with that please?
Thanks in advance!

Best regards,
 
Replies continue below

Recommended for you

Hello!,
Do not use finite elements with big differences in the stiffness, adjacent elements whose stiffness differ by several orders of magnitude or more can produce an ill-conditioned stiffness matrix, which leads to problems when solving the model. In such cases the use of RBE2 elements is correct because the RBE2 element uses constraint equations to couple the motion of the dependent degrees of freedom to the motion of the independent degrees of freedom. Consequently, RBE2 elements do not contribute directly to the stiffness matrix of the structure and ill-conditioning is avoided.

The RBE2 provides a very convenient tool for rigidly connecting the same components of several grid points together, then feel free to use it, OK?.

Regarding alternatives, an RBAR element is preferred over creating a ‘stiff beam’, as it has no relative stiffness side effects. MPC equations are created internally and the RBAR does not ground model.

Best regards,
Blas.

~~~~~~~~~~~~~~~~~~~~~~
Blas Molero Hidalgo
Ingeniero Industrial
Director

IBERISA
48004 BILBAO (SPAIN)
WEB: Blog de FEMAP & NX Nastran:
 
Hi Blas,

Thanks a lot for your explanations, I am always fun of your videos on youtube…

The use of RBE2 elements is convenient indeed, but for this particular case I have a model with a lot of rigid beams connected to “non-rigid” ones.
If I have to convert all the rigid beams to RBE2, I would have to pay attention to the connection of two RBE2 elements(independent and dependent nodes).
Could you please give an explanation of assembling different RBE2, what could be the easiest way to do it?

Thanks in advance.

Best regards,
Rafik
 
PS:
Also, if I want to keep the same beams (without using RBE2), will it be correct to do:
E/1000 and I*1000
E: Young modulus of the material.
I: moment of inertia.
This means, in order to use the finite elements with the same order of magnitude of stiffness:
- the modulus of elasticity has to be divided by the difference of order (to reach the same level of other stiffness’s).
- the moment of inertia of these elements has to be multiplied by the same number.
Is this approach correct?

Thanks in advance.

Best regards,
Rafik
 
Dear Rafik,
You can run the way you like using stiffer beams, of course, but you will have problems for sure!!. This is a Nastran forum, and with FEMAP + NX NASTRAN you have plenty of meshing resources to make things perfectly using RBE2 elements, not need to make strange things proper of FEA codes that do not have RBEx elements on its FE library.

With RBE2 you need to understand the following: the active degrees of freedom of the single core node (independent node, or master node) enforce the active degrees of freedom of the leg nodes (dependent nodes, or slave nodes). Therefore, the active degrees of freedom of all nodes included in an RBE2 element are considered rigidly connected. The rule of gold to avoid solver error is the following: NEVER apply any constraint to dependent nodes!!, only is possible to the INDEPENDENT node (the core node), OK?.

rbe2.png


Another typical issue that users runs with rigid elements (either RBE2 or RBE3) is the "double dependencies":
Double dependencies occur when two RBE2 elements share a dependent node. If your model contains double-dependencies, the solver may not be able to correctly resolve the degrees of freedom in your model. Then have clear that not any dependent node can be shared between two or more rigid elements.

In FEMAP you can run a macro under "CUSTOM TOOLS > ELEMENT UPDATE > MULTI-DEPENDENT RIGID CHECK"
This is a very handy API program to have. When setting up a complex model that contains many rigid links, it is important to ensure that a slave node is subject to only one master node. This API goes through all the rigid links in the model, and lists any nodes associated with more than one rigid link.

Best regards,
Blas.

~~~~~~~~~~~~~~~~~~~~~~
Blas Molero Hidalgo
Ingeniero Industrial
Director

IBERISA
48004 BILBAO (SPAIN)
WEB: Blog de FEMAP & NX Nastran:
 
Hello Blas,

Thanks a lot for your explanations.
It was very helpful.

Kind regards,
Rafik
 
Hi Rafik,

Moreover, you can easily invert the master / slave nodes of a selection of RBE2 elements using the API I posted in the following thread:
In addition of the API Blas suggested to you this one will help you to properly work with RBE2 elements.

Regards,
SN

Seif Eddine Naffoussi, Stress Engineer
33650 Martillac – France
 
Another option of doing this is using param,automset,yes for solving double-dependency conflicts within NASTRAN.
 
Hello,
In fact, PARAM,AUTOMPC,YES can solve the problem, but is not a good rule (in sort, is a bad practice!), is better to understand the meshing problem and solve it correctly at the first time, if not you can have complications later (Murphy´s law!!). For instance, NX NASTRAN Advanced Nonlinear Solver (SOL601) (ie, ADINA solver) do not understand the PARAM,AUTOMPC,YES command and then you will receive solver error for sure, OK?.

double-dependency-rbe2-rbe3.png


Best regards,
Blas.

~~~~~~~~~~~~~~~~~~~~~~
Blas Molero Hidalgo
Ingeniero Industrial
Director

IBERISA
48004 BILBAO (SPAIN)
WEB: Blog de FEMAP & NX Nastran:
 
You could output your model as a .bdf file, then use excel to convert all of your bars to MPC's, then read them back into your model. It would ease the process if you renumbered your nodes prior to export to make the nodes you want as the dependent nodes to be lower or higher than the independent nodes. For example, renumber all the nodes on one side of your interface to 100000 and up and all the ones on the other side to 200000 and up. Then you could use the sorting and the copy and paste functions in excel to rewrite the bars as MPC's very quickly. Sometimes it pays to work outside the pre/post processor.

"On the human scale, the laws of Newtonian Physics are non-negotiable"
 
Quoting:

> In fact, PARAM,AUTOMPC,YES can solve the problem, but is not a good rule (in sort, is a bad practice!),

I don't think so. I routinely use automset feature, and I find it an invaluable tool to the modeler. The AUTOMSET feature removes much of the difficulty of assigning m-set variables by repairing errors in the global m-set. This means that the modeler can concentrate on correctly specifying each constraint element by itself, with less concern about its interaction with other constraint elements or with sets exclusive from the m-set.

Using a feature that is not supported in other down-stream solution sequences doesn't necessary qualify it to be a bad-practice! In the aero-world a whole bulk of fe-models that are run are linear.

 
Dear nlgyro,
PARAM,AUTOMPC,YES is not available in some circumstances and will be automatically set to NO for:
A p-element analysis with local coordinate systems or RSSCON elements.
A design optimization solution (SOL=200) with DVGRID data.
The AUTOMPC option is not recommended for use in models with RSSCON elements connected to CPENTA elements.

Also I can add the following:
PARAM,AUTOMPC,YES does not change equations. It simply reorders terms between dependent (M-set) and independent (N-Set).
AUTOMPC does not know about DOF in the S-set and A-set so it can decide to place these in M-set (results in FATAL error).
User loses control over which DOF are dependent.
Does not get rid of issues associated with circular dependencies.
Default behavior is “NO” (original behavior).

In summary, you can run the way you like, but for me is clear: I try to avoid its use at all.
Best regards,
Blas.

~~~~~~~~~~~~~~~~~~~~~~
Blas Molero Hidalgo
Ingeniero Industrial
Director

IBERISA
48004 BILBAO (SPAIN)
WEB: Blog de FEMAP & NX Nastran:
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor