Jason K. Moore

> What can I do about it? My previous version would have failed, too, I suppose? We can report the issue upstream on the scotch feedstock and we can add...

Closed/reopened to trigger the CI again. The upstream scotch issue may be fixed.

Beware, this just crashed my computer by using all its memory.

This is what the matrix looks like, for reference: ``` Matrix([ [ 0, 0, -1, 0], [ 0, 0, 0, -1], [(-d_L*g*m_L - d_T*g*m_T - g*l_L*m_T + k_00*s_00 - (-I_T...

This computes the result very fast: ```python In [1]: import sympy as sm In [2]: from sympy.physics.control import StateSpace In [3]: a, b, c, d, e, f, g, h =...

Note that this bug is seen here: https://github.com/openjournals/jose-reviews/issues/111#issuecomment-830785135 and that it seems to be a regression from SymPy 1.7 to 1.8.

I personally don't use `linsolve()` and don't really understand it. If `linsolve()` is used internally in the Beam module, I'd be infavor of replacing it with `solve()` or a matrix...

Also, it seems that we need some way to manage solving systems of equations from beam depending on if they are floating point coefficients or not.

> If it should be expected that users can pass floats and the beam code will just "do the right thing" then I don't really see how anything else would...

> Is there any appetite for merging #21377? Is this the correct solution? From a beam bending problem perspective, should we not allow placing too many constraints on the beam?...