Hermitian beam elements - discretization and boundary conditions #332
Replies: 3 comments 2 replies
-
And one thing regarding input (@sebproell) Would it make sense to check if too much DOF's are given in a DBC? For example I have a node with three degrees of freedom - but I can define a random amount of DOF's for that node
This would also work for a node with 3 DOFs and the remainder is just ignored |
Beta Was this translation helpful? Give feedback.
-
The problem somehow originates form the fact, that we just specify a list of DBC values. Their assignment to a certain DOF is not part of the DBC input line, but has to be done by the physical field. Ultimately, the interpretation, which entry in the DBC input line acts on which DOF, is not given explicitly, but is only encoded implicitly in each physical field. For the example with beams described above, the first three entries in the list of DBC values is interpreted as "displacement" values for the end nodes of the element. However, the middle node interprets them as rotational DOFs. So far, this is just an observation. When thinking about it, it might be better to encode this directly in the DBC input line, however this is a major change and I cannot even "4C" 😉 its implications right now ... we might end up with having to implement physics-specific DBC input lines... not so sure, if this would be a bright idea. Nevertheless, these are my two cents for this discussion so far. |
Beta Was this translation helpful? Give feedback.
-
That is a very good question. With DBCs in 4C we define which discrete DOF(s) of a node are constrained. The physical meaning of those DOF are encoded in the elements and can not (at least with the standard DBC conditions) directly be constrained. Take your example of the A few comments on your example:
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Question / discussion for all beam experts of 4C (@isteinbrecher, …)
I currently do not know if the following behaviour is a feature or a bug - therefore, I am opening this discussion to summarize and discuss everything
Prerequisites
Based on the improved convergence rate (see https://www.sciencedirect.com/science/article/pii/S0020768317303372) it is preferred to use cubic Hermite polynomials for the centreline discretization and quadratic Lagrange polynomials for the triad interpolation (->
HERM2LINE3
elements in 4C) for some problem types. This type of beam discretization is also used in the following.The beam discretization looks like
with one element being defined with
Problem setup
In my setup I simply want to move a beam element as a rigid body through space. Therefore, I want to fix all DOF's of the beam element. Further, I want to record the resulting forces/moments of the boundary condition with the
TAG monitor_reaction
Due to the
TAG monitor_reaction
only working with--DESIGN POINT DIRICH CONDITIONS
and notDESIGN LINE DIRICH CONDITIONS
I only use DBCs on individual nodes/points.Not working / "broken" version
For a long time I am using the following setup which is reproduced in the following minimal working example.
Minimal working example "broken"
Just recently I found out that this now produces a not wanted / wrong force acting on the beam:
Force output "broken"
As you can see we now get a random force in the x-direction of the DBC.
Working version
Just recently I found out that this appearing force in x-direction can be attributed to the DBC. With the following version the random force vanishes
Minimal working example "working"
Force output "working"
This now produces a force response as expected - every force/moment vanishes.
Differences
The difference between both setup lies within the DBC
The broken version applies the DBC to all three nodes of the beam with:
The working version applies the DBC seperately to the outer and inner nodes like:
After some further tinkering I found out why the first version produces the seemingly wrong results. If you apply the function to the center node (i.e., rotational degree of freedom) the results are identical to the wrong/"broken" version:
Expected behaviour
I always thought that 4C is "smart enough" / that it is implemented so I can apply DBCs to all nodes of a
HERM2LINE3
element at once.I know that the outer nodes have 9 degrees of freedom (displacement, rotation, tangents) and the center nodes have 3 degrees of freedom (rotation).
As you can see above - if you apply the DBC to all nodes at once, 4C applies the DBC of the displacement onto the rotational degrees of freedom of the center node. Therefore, the results are wrong.
Question / Discussion
Is it wanted that one has to split up the DBC for the outer/center nodes of a
HERM2LINE3
beam element?In my opinion it should be possible to use one DBC and 4C correctly applies the boundary conditions to the correct DOFs
Beta Was this translation helpful? Give feedback.
All reactions