You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Strange behaviour of release - Forces all elements at node to be released #464
Release (spring) command for one element seems to force all elements at that node to behave as if they are released. This was not present in v1.6.1 version.
Attention @Ayberkrk :
First of all, thanks a lot to all maintainers and other contributors of this package. Highly appreciate this.
The Issue I flagged above continues to exist in the new release v1.7.1
Giving a bit more context to help you identify the issue.
Attaching the original .py file used to check. Grid_3_rev_3.py
Geometry
Load Applied
Result with Version 1.6.1
This behaviour is reasonable. Only the internal span beam is having end release and remaining members would attract moments at joints.
Results with Version 1.7.1
In the new version, all elements meeting at node 3 seem to have been treated to have moment release.
@harikri1988 thanks for raising had a look at this.
It looks like since 1.7.0, internal hinges are identified every time an element is added (so they can be plotted before solve()). When element 3 (released at node 3) is added, node 3 only has elements 2 and 3, so it's treated as a hinge and element 2 is released. Column 7 is added later and gets released as well. The result therefore depends on the order in which the elements are added.
It would be possible to work around the issue by adding the elements that have releases after the other elements connected to the same nodes. For your script, that's elements 3 and 4 last. Note that the element ids would then change, when applying loads.
Thanks a lot @mitchell-tesch
That explains the strange behaviour. I think it will be helpful to have the circle marking hinge to be shown slightly offset into the member with release so that it is clear.
Could you also suggest what should be the order if there are 2 members meeting at a node and each has a different release? Would the first release override (get overridden by) the second one?
Technically neither overrides the other, releases are stored per element end. The exception is when only one member at a node is left rigidly connected: the node is then treated as a hinge and that member is released too. With two members, that means if one is released (0), both are, which gives the same moments anyway. Two non-zero springs are each kept.
So the order only matters with three or more members at a node, as in your node 3, and #492 removes that. Until then, adding the released elements last avoids it.
Like the plotting good idea. At the moment the circle is only drawn when the whole node is a hinge, so a release on a single member isn't shown. I am thinking this could be raised separate to #492 as an enhancement?
Activity
harikri1988 commentedon Oct 31, 2026
Attention @Ayberkrk :
First of all, thanks a lot to all maintainers and other contributors of this package. Highly appreciate this.
The Issue I flagged above continues to exist in the new release v1.7.1
Giving a bit more context to help you identify the issue.
Attaching the original .py file used to check.
Grid_3_rev_3.py
Geometry
Load Applied
Result with Version 1.6.1
This behaviour is reasonable. Only the internal span beam is having end release and remaining members would attract moments at joints.
Results with Version 1.7.1
In the new version, all elements meeting at node 3 seem to have been treated to have moment release.
mitchell-tesch commentedon Nov 4, 2026
@harikri1988 thanks for raising had a look at this.
It looks like since 1.7.0, internal hinges are identified every time an element is added (so they can be plotted before
solve()). When element 3 (released at node 3) is added, node 3 only has elements 2 and 3, so it's treated as a hinge and element 2 is released. Column 7 is added later and gets released as well. The result therefore depends on the order in which the elements are added.I have put put together a fix in #492
It would be possible to work around the issue by adding the elements that have releases after the other elements connected to the same nodes. For your script, that's elements 3 and 4 last. Note that the element ids would then change, when applying loads.
harikri1988 commentedon Nov 4, 2026
Thanks a lot @mitchell-tesch
That explains the strange behaviour. I think it will be helpful to have the circle marking hinge to be shown slightly offset into the member with release so that it is clear.
Could you also suggest what should be the order if there are 2 members meeting at a node and each has a different release? Would the first release override (get overridden by) the second one?
mitchell-tesch commentedon Nov 4, 2026
No problem @harikri1988
Technically neither overrides the other, releases are stored per element end. The exception is when only one member at a node is left rigidly connected: the node is then treated as a hinge and that member is released too. With two members, that means if one is released (0), both are, which gives the same moments anyway. Two non-zero springs are each kept.
So the order only matters with three or more members at a node, as in your node 3, and #492 removes that. Until then, adding the released elements last avoids it.
Like the plotting good idea. At the moment the circle is only drawn when the whole node is a hinge, so a release on a single member isn't shown. I am thinking this could be raised separate to #492 as an enhancement?