I’m encountering an unexpected behavior in Karamba3D when analyzing a structure with sequentially activated members. Would appreciate any insights or solutions.
Problem Setup:
Structure: Multiple members (e.g., a tree-like frame).
Loading:
Self-weight applied to all members (activated or not).
Nodal load (e.g., vertical/horizontal force) applied at the topmost nodes.
Analysis Method: Members are activated step-by-step from bottom to top (using is_active in Python environment).
Observed Issue:
Even when upper members are inactive, their presence (and their self-weight) still significantly impacts the deformation of already activated lower members.
Example: If only the bottom 3 out of 10 members are activated, the displacement of these 3 members still changes noticeably when the top 7 members (inactive) are included in the model.
Request for Expertise:
I know that in Karamba3D, the unactivated elements are using the soft kill method. How can I eliminate as much as possible the effect of soft-killed elements and their loads on the deformation of activated elements? sequence.gh (120.3 KB)
Hi @Derui_Zhao,
the activation and deactivation of elements works in Grasshopper scripts (I tested it here: Beam_Cantilever_Activation_Test_cp.gh (30.0 KB)).
One possible issue might be that you’re not invalidating the FEB model after modifying it. Make sure to call model.febmodel.touch() after making changes (see for example this reference).
– Clemens
I’m not so sure there’s still a problem. I modified your grasshopper script. Changed the cantilever beams to vertical columns. And applied a horizontal load at the very top. When only the first segment is activated, it should not have a very large horizontal displacement. But the current calculation shows such a displacement anyway. I am still attaching the modified script for reference. Beam_Cantilever_Activation_Test_cp.gh (43.7 KB)
The code model.febmodel.touch() I also added to my script, but it doesn’t seem to work.
Hi @Derui_Zhao,
thanks for the clarification! The issue in Karamba3D 3.1.50414 stems from nodal loads not being deactivated when the associated node is only connected to deactivated elements. I’ll fix this in the next service release.
As a workaround, you can define the concentrated load as a beam load—in that case, it will be properly deactivated along with the element.