Nodes sharing the same pinned support BC.

disla

Hello,

When two nodes share the same "pinned support" BC, the BC is not applied individually to each node . A new ghost "node" appears in between , and the BC is applied there inducing a strange behaviour. See attached file.
This doesn't happen with fixed support BC where BC is applied individually to each node.

Regards

Victor

That's intentional. Pinned support is at a higher level of abstraction and it makes a single pinned support for the entire selection by coupling all the nodes with constraint equations. It's suitable for putting a pinned support on the end of a beam made from solid elements where a single node won't support it correctly.

In the special case of a single node, it behaves the same as 3 separate X, Y, and Z displacement constraints.

It's consistent with fixed support in that both are applied to the whole selection. This is why fixed support isn't allowed on solid element nodes - because it can't constrain their rotation to fully fix them.

disla

Good morning Victor,

I thought the word "Support" was reserved to define the behavior of the model with respect the outside. From my point of view, you are imposing additional constrains not requested between the elements of the model.

Beams: When a set of nodes is selected, I think the BC should be applied to the set of nodes as you say but one by one as you do with fixed support.

Surface or Solid : In case the nodes belong to a surface or a solid , I agree they should be applied at an upper level , some kind of middle node to avoid fully fix, but still one “middle point” per element.

If not, you are constraining elements between them, as in my previous example.

I have built an example to show why I think the actual procedure of imposing “pinned support” is not right.

A slab with a pinned support on its base should not be allowed to deform as it is doing. Part of the slab finish under the supporting base. This would be solved if the support is applied element by element and letting the stiffness matrix of the model be the one to solve the interrelationships between nodes.

Regards

Victor

You have some good points there and this is a behavior that several people have questioned.

Some general principles I'm trying to adhere to:

1. Support means a connection to ground or constraint of rigid body motion, not necessarily without imposing any relationship between nodes.
   
2. The physical meaning should be independent of the mesh refinement or element type.
   
3. One item in the outline tree should represent one conceptual or real "thing", whatever that means.
   

I think your definition of support is too strict because even fixed support imposes a relationship between the displacements of each node in that they must all be equal (and equal to 0).

For beams, I realize that the behavior it has is surprising and probably not very useful. I agree it would be more convenient if it pinned each beam separately. However, that would violate principle 3 and also break the consistency with other element and load/constraint types (principle 2). For example, if you converted your beam example to solids, the two separate supports would become a single one.

For solids, if it made a separate pinned support on each face, the physical meaning would be dependent on the mesh (principle 2). A course mesh would allow rigid body rotation but any refinement would suddenly turn it into multiple pinned supports (principle 3) which would be the same as fixed support but with soft edges whose width depends on mesh refinement.

There can be cases where the surface displaces through the point of the support but it's meant for situations where you're not very concerned about the local details and just want a distributed support without the stress concentration and excess displacement that would come from putting it at a single node or element face. The same cases where you would use Nastran's RBE3 with constraints on the single node.

disla

Thanks Victor,

I understand the need to keep consistency in the criteria.