Sloping BoxBeam CCX Solver Error

cwharpe

Looking at modeling a stair superstructure with CCX Rect. Tube cross-sections, with intent on running NL analysis. Just trying out Static3D with fixed-end constraints for simplicity.

I can get the solver to run for (Line3) beams in most positions EXCEPT for beam slopes between ~42 deg. and 90 deg., wherein I am met with the "ERROR in cascade:..." solver fail message. (I advanced the SlopeBox beam group by z-axis rotation about zero.)

Anyone see this before? ~Thanks.

disla

HI,

There seems to be some conflict with the application of shared BC for arbitrary beam orientations.
It could be solved adding a common orientation which is always recommended for beams.

cwharpe

@disla,
Still mis-behaves if the beams are separated apart. Also, each beams' V-axis seems correct in the orthogonal position to the beam axis? It is puzzling why some angles work, others don't.

disla

.

If "a" dimension is very close to "1.5b" it fails.
This doesn't happen if you switch a by b.


a=149mm
b=100mm works

a=150mm
b=100mm fails


a=298mm
b=200mm works

a=300mm
b=200mm fails

disla

I guess if with those dimensions some nodes end up with the same coordinates after expansion.

cwharpe

@disla: Well, you are on to something. Turns out CCX will pass solver for all principal angles in the plane up to the limit of arcsin(b/a). For b/a=100/150 yields my 42 degrees (41.81..). Just an eyelash past that angle CCX solver fails. That seems to describe the behavior, but I just don't know why.

@Victor: Any insight into this riddle with Rectangles? For squares, arcsin(b/a)=90 deg., so no problem with any beam slope.

Victor

That's a pretty huge bug. I've posted it as an issue on CCX's Github.

I did find a workaround is to *TRANSFORM the constrained node so the node's axes align with the beam's, then it seems to work OK.

@cwharpe, interesting observation about arcsin(b/a). No idea what it might imply though.

cwharpe

@Victor: I was able to get the *TRANSFORM card to work, so Thank You for that. No free lunch, however. I had to keep working the trig to load it properly, then to interpret the results from Beam coord. system back into World C.S. -- became a little twisted for me to compare apples to apples (CCX vs. Internal).

There is a "trick" that seems to work-out OK. When the beam slope is beyond the sweet spot of arcsin(b/a), I found that adding a micro "dog-leg" to each beam-end permitted the model to solve. That is, tiny beams are created by extruding the end-points horizontally (or vertically) by a fractional amount such that the new end-pt. constraints can align with World C.S. The small error this introduces to Solution is proportional to the length of the dog-leg offset. For my level of precision I was finding b/1000, maybe b/10000 to be acceptable. Naturally, a poison-pill to this setup is forgetfully Merging Nodes.

Thanks to all for the help.