​
Vocabulary Notes

  • Node: A location of a support, hinge, concentrated load, beginning or end of a distributed load, or beginning or end of the member as a whole.
    • Also, for variable distributed loads or variable sections (which can only come from a continuous reaction load link) - every point at which the distributed load changes. There are usually 25 of these along a variable distributed load.
  • Element: The member connecting between nodes.

​
Merging of Nearby Nodes

​
What Happens

If any nodes are within a very small distance of each other - currently a distance of L/800 - then they will be merged into a single node.
Nodes are created in the order outlined in the vocabulary notes above. For example, if a support and a concentrated load are a few millimeters from each other, then the support will be created at exactly its location, but the concentrated load will be moved to the location of the support.

​
When It Can Be Bad

The most likely scenario is a user trying to apply a “pure” shear force at a support by putting the load extremely close to the support. However, when the nodes merge, there will end up being zero shear because the load got placed at the support instead.
There’s a good engineering argument here that a load that’s physically very near to a support is not actually going to be pure shear - it will mostly get resisted in bearing, and bearing loads will still be picked up in the solve.

​
Why We Do It

There’s an inherent limitation in FEA mathematics where if two connected elements are of very different lengths, then in the stiffness matrix, you end up adding a very small number to a very large number. When the stiffness matrix includes terms that vary dramatically in magnitude, then the “condition number” of the matrix rises rapidly, indicating that matrix calculations such as multiplication or eigenvalue determination become mathematically less stable. If you’re doing those matrix calculations using a tool with a fixed maximum precision (i.e., all computers), then the numerical stability can be poor (i.e., the actual results can incorrectly become zero or infinity, or become mathematically impossible to calculate).
Typical users aren’t going to understand this limitation, and tools like CalcsCad imports also aren’t going to understand it. So rather than give incomprehensible errors to users, we deal with this limitation automatically by merging together nodes that are very close to each other. There’s a slight accuracy cost to that, but it’s usually negligible.

​
Workarounds

  • Short-Term: You can’t work around this - keep your nodes farther apart. Note that there is now a solver warning message that will be issued if we merge nodes, but users normally can and should ignore it.
  • Long-Term: Not mathematically possible without higher-precision computers!

​
Axial Distributed Loads

​
What Happens

Axial distributed loads are currently applied as two axial point loads, each equal to 1/2 of the total magnitude, applied at either end of the load.

​
When It Can Be Bad

This means that the axial demand outputs (e.g., remote.gov.P) can end up being equal to only 1/2 of the total axial distributed load if one of those point loads is at a support.

​
Why We Do It

Previously, there was an inherent restriction in anaStruct (our upstream FEA package) in that it wasn’t capable of applying distributed loads in multiple directions at once (i.e., lateral + axial). If you tried to apply an axial distributed load, anaStruct actually internally converted it into two point loads like this. So we just moved that behavior to the code on our side, so that we could apply axial and lateral distributed loads simultaneously.
A couple of months ago, Brooks updated the upstream anaStruct package to allow real axial distributed loads and to allow distributed loads in both axes simultaneously. So the upstream restriction is now gone. But we need to update our code to make use of the anaStruct updates.

​
Workarounds

  • Short-Term: This does NOT affect reactions - so if you want to be sure that you’re getting the maximum axial demand in a column, it may be best to use the axial reaction instead, or to use a max(remote.gov.P, remote.gov.Ry), for example.
  • Long-Term: Our upstream anaStruct code HAS already been updated to allow for proper axial distributed loads now. However, we’ve not implemented the update on our side yet. We need to get on that!

​
Non-Concurrent Loads - FIXED

As of Jan 2024, fixed as long as you’ve set includeZeroNonConc: false in the parameters of your remote widget - which we’ve done on most existing templates.

​
Previous Issue (Now Fixed)

All non-concurrent loads, and load combinations associated with them, were previously considered always. For example, in US ASD load combinations, there is the combination D + L, but there are three non-concurrent live load types L, L2, and L3. The solver would ALWAYS consider the three load combinations D + L, D + L2, and D + L3, and would combine the results of the three of them together in its final outputs.

​
When It Was Bad (Now Fixed)

Probably most confusing with wind uplift, because that load is usually acting in the opposite direction of gravity. While governing demands would still be correctly calculated, outputs based on the signed absolute maxima would be potentially confusing.

​
Why We Did It (Historical Context)

Up until mid-2021, due to dev-side restrictions in identifying blank inputs, there was no way for the solver to know whether or not the user intended to enter a load type. So we had to consider every load type no matter what.

​
Current Status

This issue has been resolved by implementing the includeZeroNonConc: false parameter in remote widgets, which prevents the solver from considering unused non-concurrent load types in calculations.