In the 1D beam analysis application BeamFEA, I use hinge elements for rotary dof release (to insert a hinge in the beam). They connect coincident nodes of adjacent beam elements.

In the 1D case, the element matrix is just parametrized by the stiffness EI and the length l. The dofs are w1, phi1, w2, phi2. A hinge element is generated if l=0. Then the EI value is taken als spring stiffness between the w dofs of the nodes. This means that equal w for both nodes is not enforced by reduction of the system but by a penalty term.

I see that this penalty approach could be implemented also in the frame case. I've recently tested a purely hinged connection (at node 6 in my model) and it did not worked (non-invertible Kr matrix) until I had specified in the constraints matrix R, that rotation in that node is a constraint.

I understand that this as a workaround, since the reduced stiffness matrix is non-invertible (trying to get, via qr = invert(Kr)*Fr, a rotation value that doesn't introduce efforts in the adjacent members means a row of zeros in Kr)

Here I attach the correct matrix MF2. What I wrote is in magenta. When calling the displacements you should use the DOF vector of the element to index them.

Frames with FEM (internal releases) v2-Example.sm (207kb) downloaded 45 time(s). Frames with FEM (internal releases) v2-Example1.sm (116kb) downloaded 26 time(s).

Hi wb.c,

Attached the corrected worksheet. I modified three things:

1. Connectivity for the three rigid-hinged bars. They must be coherent with the elementary matrix: start node is rigid and the end node is hinged.
2. Rotation value must be assigned as a constraint, otherwise you will have a singular Kr matrix. (there is a previous comment that I did on this post)
3. Cosinus formula should be avoided for angle calculations, as cos(alpha)=cos(-alpha), I think that the best way is to use xy2pol. (For example, for the vertical bar, if you change the node order, you will obtain 90 deg as well (instead of the correct value of -90 deg with xy2pol)).

I attached a comparison with a model made in FTOOL to validate the results (different than yours, perhaps because the condition of bars 1, 2, 3 is hinged-hinged).

Regards!

Alvaro

New Frame FEM Example.sm (170kb) downloaded 20 time(s).

Does not open ... Incorrect format.

For the sake of simplicity, I eliminated some of the automated vector assemblies, as I didn't want to spend too much time trying to figure a good way to work with the DOFs as they are shown in LinPro.
Assembly Vector - Manual
Elimination Vector - Manual
Force Vector (global) - Manual

They start with 0, SMath with 1, so keep that in mind.

What they do is restrict the fixed DOFs to the end of the DOF numbering.

Now, my K (global) matches the result from LinPro exactly.
There was some interesting things that had to be done to make that happen:
As Jean has pointed out in the past, the order of matrix multiplication has varied results.
It seems that for this configuration:

I could not get the global k matrix to match the results in LinPro.
I ended up arranging it like this:

And it worked.

I also removed all units for now, because as it seems, the inverse operation of a matrix requires numeric evaluation, and with units, I get a "units don't match" error, and you can't evaluate the inverse symbolically for some reason (That's a whole different topic for another day...).

In any case, After getting the right complete stiffness matrix K, it seems that things go south. Solving for the reduced displacements vector is way off.
It seems that LinPro produces an updated forces vector after solving "the system of equations" that includes the reactions at the fixed DOFs along with the forces applied.
It makes me wonder if perhaps there is something off in the sequence we have in the SMath sheet.
After we assemble the complete stiffness matrix K, we obtain a reduced K, Kr that eliminates the fixed DOF (in this case, the last 6 DOF, 19-24).
Then we use that Kr along with a reduced F, Fr, to solve for reduced deflections, Qr.
Is all this right?

Maybe a set fresh of eyes can find the problem here:
New Frame FEM Example - Updated.sm (130kb) downloaded 13 time(s).

Hi wb.c,

There was an error in your connectivity table for the last bar. Also, k_prime = L'*k*L (and not L*k*L' ) must be used to retrieve q_prime =L*q. I corrected your transformation matrix L (I shared a good book on this topic, you can take a look at chapter 5 to see the L matrix). You described the correct procedure at the end of your comment.

New Frame FEM Example - v2 (LinPro validation).sm (130kb) downloaded 11 time(s).


And here the automated (FEM tasks) worksheet:

New Frame FEM Example - v2 (LinPro validation - automated).sm (85kb) downloaded 21 time(s).

Edited by user 09 March 2023 12:57:44(UTC)  | Reason: Not specified

Up until doctored wrt to my SS, only MP plots.
Above my head anyway !
Few more matrix utilities ... more than minimalist !
Cheers ... Jean

Page3 Utilities.sm (38kb) downloaded 5 time(s).

Alright, so the FEM sequence is working well. No issues with the values obtained thus far. Thanks Alvaro for that!

I have implemented a loop now to evaluate a specified force at 360-deg.
The issue now is that this loop takes some time. Currently about 22-sec.
I would like to speed things up as much as possible.

I already stripped down the the original sheet and eliminated any unnecessary calculations, but the real time consumer here is obviously the loop containing 360 steps.

Originally I thought that I could only evaluate 180 degrees and that the other 180 would just be opposite, but the results are not quite symmetrical, so 360 it is...
In the loop, I am only calculating member forces for the first 3 members, but before that, displacements must be calculated for the whole system.
The loop is not storing large vectors, in fact the vector being stored only contains 3 smaller vectors, each of length 3, for each of the struts in question.
The stiffness matrix is only assembled once, and the loop is really only for solving for Q as the applied force changes and then the solving for the member forces.
The loop then evaluates if the new value is the biggest so far and if it is, it will save it. if not, it keep the previous value.

Any ideas on how to speed up the loop?
Maybe there is a way to isolate the FEM method to only the three members of interest? So that Q is smaller?
Maybe there is a better way to get the worst case for each strut out of the loop?

Thanks!

FEM Concept v0.0.sm (89kb) downloaded 11 time(s).

Wow that is crazy fast now. Less than 1sec for me.
Thanks so much for the input.

Been watching some of your YouTube videos, and it is really great stuff.
Keep it up.