Alright, so this has turned into me VS. condensation. But I'm not one to back away. I don't think nonlinearities are supported (or can be supported). I tested it out and it immediately diverged (works with slave nodes).
I attached a zip. I'm not surprised it doesn't work at all, as I will detail below.
The problems in the zip reflects the problem illustrated here:
http://www.oofem.org/resources/doc/oofe … ode49.html
BP:
I've never seen static condensation done on anything but linear systems, since, well, it's based around substructuring a linear system of equations (?).
Either way, this, for example, can't support nonlinear problems;
FloatMatrix stiff;
// The un-condensed value is computed for the "normal" solution vector, which doesn't post-process the un-condensed dofs.
// This proves that the material with nonlinearities (layered c.s. with some plasticity maybe?) will be completely wrong.
StructuralElement :: computeLocalForceLoadVector(answer, tStep, mode); // in global c.s
if ( answer.giveSize() && dofsToCondense ) {
// condense requested dofs
if ( answer.giveSize() != 0 ) {
this->computeClampedStiffnessMatrix(stiff, TangentStiffness, tStep);
this->condense(& stiff, NULL, & answer, dofsToCondense);
}
}
So, I still don't think it will handle nonlinearities correctly, as it doesn't matter how the condensation is done, if the un-condensed answer is wrong (moment computed for the incorrect curvature).
Perhaps these problems can be fixed, but I'd need to see an example file before I'm convinced that it actaully support nonlinearities. Back when the condensation code was written, only linear problems for beam2d and beam3d was supported.
-------------------------------------------------------------------------------------------------
Giovanni;
I'm all for a good provocation!
I agree with you. I think the beam standard output should print the GP values of the material response and nothing else.
I think the condensation code should be removed since it has such a huge list of disadvantages.
If that was done, there would always be correct output.
( I'm not just now making this up, I talked to Borek about the condensation over a year ago: http://www.oofem.org/forum/viewtopic.php?id=1431 )
Condensing dofs is a very invasive operation. Beams now need to know of any external load in order to compute it's stiffness matrix, which isn't the case for any other element.
Using sets for loads is more than just an alternative syntax for the input files. Part of the reason (long term plans) I pushed for this is because this will enable me to do easier adaptivity for all types of analysis. It will enable me to implement a much simpler to use indirect load control while keeping the possibility of adaptivity/remeshing/change dirichlet b.c. at the same time (currently not possible).
These are major features planned, and the fact of removing the element loads from the elements directly is a central part of this.
Personally, I really can't understand why static condensation could ever be considered simpler than using a bearing-type node (or some other type of support) when explaining to a beginner. "Here is a bearing/hinge, you can connect beams/whatever to either side of it" is all there is to it. It clearly reflects real life components.
And most trusses you find in real life are, in fact, frames. So the need to have any extra rotations or the likes (with or without condensation) is nearly meaningless outside a few school book examples in mechanics.
Lets also take a look at the file (OneEndRels-Qk1.out)
...
beam element 1 :
local displacements 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000 0.0000e+000
...
That's wrong. The beam is free to deflect in dof 2 and 3, and will certainly do so on dof 3 with the load applied.
So my conclusion is that using condensation is just too risky for a beginner (and anyone else)!
It has so many many major disadvantages. You can't export the condensed dofs to VTK (or anywhere else]. You can't use in arc-length methods/indirect load control. You can't apply nodal loads to the condensed dof. You can't have 2 beams connected to the same condensed dof (it's *very* limited in terms of types of trusses and frames).
If it wasn't possible to do this type of analysis without condensation, then there would be a different discussion. But now we have a more general, works-in-all-cases, bulletproof, consistent, super flexible, proper, easy-to-explain, way of doing it with slave nodes.
Your counter to the slave nodes was basically that it was to inconvenient when you have a truss, so you have to do this for every beam. In that case, you have completely disconnected the beam equation from the bar equation in your element, and you are basically only solving the FE-problem with bar stiffness only, and computing the bending moment inside each element induvidually due to loads.
This moment will be completely seperate from the solution, and you can solve for it analytically without FEM. The only reason to ever use beams is when you have a frame, and in those cases you don't have any momentless joints.
One can always dream up a scenario where in the syntax of the input file is more cumbersome, but for some pratical examples, like
http://www.oofem.org/resources/doc/oofe … ode49.html
there is absolutely no problem in having slave nodes.
I'm unconvinced that there is any benefits of the condensation code.
Post's attachmentsnonlinear.zip 1.66 kb, 3 downloads since 2015-10-14
You don't have the permssions to download the attachments of this post.