Unknown/confusing error message - 2033

[larcix]

I am getting what seems to be a bug, but maybe there is something I'm just not thinking of, and you guys might have some ideas.

Firstly, all I'm doing between the 3 test runs is updating the ANALYSIS OFFSET for 1 member (C8x13.75), and I get the following results:
[ul]
[li]With +z-0.54, the analysis runs just fine, nothing odd.[/li]
[li]With +z-0.55, the analysis runs, but starts locking various node's translation and rotational symmetries, even tho it just ran fine without those locks.[/li]
[li]With +z-0.56, the analysis stops running at all, and errors out with the following:[/li]
[/ul]
ERROR
Member M91 [with 50 spaces afterwards] has the Top-Of-Member flag set, but it's depth cannot be determined. Solution terminated.
ErrorCode = 2033

I have no idea what this error means, and the help file and online searches yield nothing related to this error code or the error message. Yes, I know I AM adjusting the members position in the analysis, but not even in the "Top-Of-Member" direction, I'm moving sideways, and what does an ANALYSIS OFFSET have to do with "determining" the member's depth, anyways, it's literally just part of the database entries for the member.

One large hint is that AISC lists the C8x13.75 as having an X-bar (OOP centroid) of 0.554", which matches the point at which the model entirely breaks itself. If I change the member to C10x30 (X-bar = 0.649) then this passes at +z-0.63, locks a node at +z-0.64 and breaks at +z-0.65, which is consistent with the X-bar theory. I also then tried an L10x10x3/4, which runs at +z-2.74 but breaks at +z-2.75, which is similar to the x-bar=2.80 per AISC. It looks like RISA calc'd a slightly different Centroid for this shape, so it still seems to be consistent with the centroid theory.

Does anyone have any idea what is happening here? I see no reason why I couldn't make my analysis offset +z-1000, besides for likely failing miserably in flexure, I see no reason why this wouldn't be mathematically tenable.

 

[JoshPlumSE]

Member M91 [with 50 spaces afterwards] has the Top-Of-Member flag set, but it's depth cannot be determined. Solution terminated.
ErrorCode = 2033

So, it sounds like you know what the problem is. It's the top of member offset for member M91, right? You might want to check the properties of your C8x13.75 to make sure it's all good data. If there is garbage in this member's property (like the depth) then the offsets might get messed up.

 

[larcix]

Its a standard member definition, with typical values in agreement with the AISC manual. I also tried another channel and an angle, just to see if the centroid theory held, and it mostly did, see my original post. And while I do have a strong suspicion what is causing the problem (adjusting analysis offset past the centroid) the questions remain, what is happening here, why is there an error, what is the error trying to tell me, and how do I put the member where I want it without the error? The model runs just fine with z-0.54, so making it z-0.56 shouldn't be an issue, I wouldn't think.

For now, I just shifted it back enough to run smoothly. It's only off by a fraction of an inch now, and no one except an anal engineer (hi) will ever notice or care. Doesn't change the oddness of this, nor the fact that it keeps happening to me as I try and adjust my member offsets to be easy to work with.

EDIT: I have the latest (or one of the latest) version at 21.0.1, I'm not sure if you or anyone else might have an eelier version to try the same offsets. Maybe even a pre-2017 version, before they completely reworked everything.

 

[WinelandV]

Assuming that your channel is oriented with the web parallel to vertical, why don't you just adjust your node coordinates and not deal with the analysis offset?

Please note that is a "v" (as in Violin) not a "y".

 

[JoshPlumSE]

Is there anything else happening in proximity to that members' offset location. Is there a diaphragm at that same location. Are there other members with offsets at that same location.

What about anything that gets "automatically meshed" by the program. Like a diaphragm or a wall. I'm just trying to think of things that could cause the program to get confused.

Obviously, you can (and maybe should) send this into the RISA tech support. If you've already tried that, I wonder what response you were given.

 

[larcix]

Josh,

I have members coming into it, and it's supported on another member. Most of my members have analysis offsets and end offsets, including the supported and supporting members.

There are no diaphragms, walls, plates, or other meshing-type elements anywhere near this frame. I do some area loads coming in, which has to auto distribute the loads to each of the members that have this issue. I actually have this model open right now; so, I just removed every load, every extra element, every offset, everything except just a couple members to not have this be unstable, and it still gave me the error as soon as I input z-0.56.

I haven't submitted this to the RISA tech, I thought I might just not be thinking about something here. Might be a good idea, they should at least be able to tell me more about what's happening here.