Brought this issue up previously but wanted to see if anyone else is having the same issue. Figured it'd be worth posting on here just in case.
We’ve had a few cases in our office with folks who have upgraded to the most recent RAM Elements version trying to open past projects. It appears that the issue results when trying to run an “old” file that was created in a previous version. My understanding is that the analysis will sometimes return an error due to an instability at a node (as is common). The issue lies in the fact that the noted node/instability does not impact the error result. For example it’ll return an instability at Node 1 in UX. If you grab Node 1 and fully fix it, it will then return an error at Node 2 in UX (and then Node 3, Node 4, etc). In the past it was easier to “chase” these instabilities around, fixing the errors, rerunning, and then fixing new errors. These errors would correspond to the actual location of the instability, not just a sequential step through the node numbers.
I understand that best practice would be to NOT create a model in the first place that has instabilities. That said, when folks start creating models with hundreds and hundreds of members, they're bound to make some sort of mistake, especially if they're a little newer to the program. Best practices in modeling would obviously be the best starting point, but this issue just makes it a bit more of a scavenger hunt when trying to clean up a model. As noted, in the past (up until this last update), the errors that came up would point you to the actual location of the instability. With the new issue, the default error is simply the first node which makes it really hard to pinpoint the source of your instability.
Any chance we could revert back to how the previous updates handled things, where the error module helped us out a bit by pointing to the location of instability (versus simply using the first node in the stiffness matrix)? Not sure if there is a real downside of that unless I'm missing something.
I'll run some tests, but having one of your old models where the behavior changed would be useful. Did you notice the version going from version 16.05 to 16.06 or were you on something older before?
Seth - looks like I got the first question from a coworker on it around the beginning of October 2021, so I'm thinking it was maybe the 16.5 update that did it? Not 100% sure on that, though.
I ran a bunch of test using various models. Some have an instability, some only when performing P-Delta analysis, and some only when using the sparse solver. I also tested some where the model DOF are restricted (i.e a 2D frame, vs 3D frame). The results can all be accounted for and are expected. The only thing that stands out is the P-Delta analysis of a model with tension-only braces and using the Sparse solver, this always fails.
Seth, thanks for testing. In our tests over here we have tried with and without the P-Delta analysis (per your suggestion) with no change. I'll check and see if the sparse solver has any affect. In the past one workaround was restricting the DOF in the model and re-running. Without changing any releases/fixities, this sometimes changed the error output to reference a different node (other than Node 1) which sometimes helped the user locate the source of the model instability. None of the models that we were running had tension only braces that I know of.
It does look like changing from the default Direct Sparse solver to the standard Direct solver does make a difference. Although both return instabilities, the Direct Sparse solver always returns (Node 1 at DOF UX) while the Direct Solver returns the actual location of the instability.
Being unfamiliar with teh differences in solvers, is the Direct Sparse better/more accurate (besides allowing you to use all available CPU cores)?
The sparse solver uses some Intel technology to optimize the matrix and generally offers better performance for large models, but it's a little more sensitive to a 0 diagonal issues.
Gotcha - makes sense. For that reason I guess it would be nice to see if we can figure it out and still use the default (sparse solver). That said, we can play around with some of our models over here and see if changing that to just Direct fixes the issue in other situations or just for this particular one.