[Ayberkrk]

anastruct/fem/elements.py, constitutive_matrix(). The function's own comment states the correct flexibility matrix with springs on both sides:

[[ c11 + 1/k1, c12       ]
 [  c21      , c21 + 1/k2 ]]

only the diagonal terms change, off-diagonal stays put. The code matches that for node 1 (matrix[1][1]) but for node 2 it modifies matrix[2][1] and matrix[1][2] instead of matrix[2][2]:

if 2 in spring and spring[2] != 0:
    matrix[2][1] = 1 / (1 / matrix[2][1] + 1 / spring[2])
    matrix[1][2] = 1 / (1 / matrix[1][2] + 1 / spring[2])

So a node 2 spring never softens matrix[2][2] at all, and instead corrupts the moment/rotation coupling terms, leaving the matrix asymmetric, which is not physically possible for a linear-elastic element.

Reproduced directly against a hand-derived matrix (EI=15000, l=4, spring={1:1000, 2:2000}): expected [[937.5, -7500], [-7500, 1764.7]] for the [1:2, 1:2] block, old code returns [[937.5, 2727.27], [731.71, 15000]], asymmetric and node 2's spring stiffness never shows up on the diagonal at all.

Also reproduced the practical effect: a cantilever fixed at node 1 with only a rotational spring at node 2 under a moment load gets flagged as an unstable structure (StabilityError), a false positive caused by the corrupted, singular constitutive matrix.

Fix is switching matrix[2][1]/matrix[1][2] to matrix[2][2] for the node 2 case, matching the node 1 case and the function's own comment.

Added tests/test_constitutive_matrix.py: a symmetry check, a check that each node's spring only touches its own diagonal term against the exact hand-derived values, and a case with only a node 2 spring. Verified all three fail on the old code with the precise wrong values shown above, and pass with the fix.

This is very likely the root cause behind #144 (element rotation wrong with springs at element ends), that report used spring={1: k1, 2: k2} and saw wrong rotation, then suspected geometric nonlinearity, but the linear constitutive matrix itself was already wrong before any nonlinear iteration starts. Left that issue alone since it's not the same fix and didn't want to conflate the two.

Full test suite passes, 214 tests (installed matplotlib in the test venv so the plotter tests actually run instead of silently falling back to a null plotter, this is unrelated to the fix itself).

[Ayberkrk]

Gentle ping on this one. With a rotational spring on node 2, constitutive_matrix() currently modifies the off-diagonal terms instead of the node 2 diagonal term, which breaks the symmetry of the matrix and disagrees with the flexibility matrix described in the comment above the code. The fix updates only the diagonal term, and the new test checks that the matrix stays symmetric with springs on either or both nodes. The CI runs expired while waiting for approval, so they would need a fresh approval to run. Happy to rebase or adjust anything if that helps.

[brookshsmith]

Thank you so much, @Ayberkrk ! This is a great catch, and apparently a 9-year-old bug that meant that rotational springs haven't worked correctly since very early versions of anaStruct... Thank you too for adding the tests alongside. I'll get out a release this weekend with the fix.

[Ayberkrk]

Thanks a lot for merging this, and for the kind words! It was fun to dig into, and I had no idea the bug went back that far. I went through the history out of curiosity: it looks like it came in with the "Changed rotational spring order. Needs some checking" commit in August 2017, so I guess the checking finally happened :)

While double-checking my fix against closed-form results, I found that this PR only fixed half of the problem, sorry about that. The springs were still being added term by term instead of in series with the element's flexibility. With a soft spring, solve() now raises a stability error, and stiffer springs still give noticeably wrong deflections. I've opened #487 to fix that properly: it inverts the rotational flexibility matrix, and the results now match the closed-form cantilever cases and example 7 exactly.

If you're planning the release this weekend, it might be worth including #487 too, so the stability error from this PR doesn't reach users. Happy to adjust anything you'd like there. Thanks again for maintaining anaStruct!