Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

CSI SAFE Exporting/Manipulating Slab Rebar Objects

Status
Not open for further replies.

bookowski

Structural
Aug 29, 2010
968
0
0
US
I know that there is a SAFE forum but it's a wasteland so asking here, maybe JoshPlum can chime in?

Has anyone had luck with exporting slab rebar objects from safe as a database file, a table, or even a dxf as a last resort? I've been battling it for quite a while and it seems extremely buggy to say the least. It often only recognizes the most recent rebar objects that you've created and ignores the balance. So if you create 100 instances of slab rebar, close the program, reopen and create 5 more and then export as a database file you only see the new 5 objects. I've tried every option and workaround I can think of. It's hard to believe that exporting rebar from a slab design program could be this buggy so I'm hoping someone can point out a fix or what I'm doing wrong.
 
Replies continue below

Recommended for you

I reached out to CSI recently regarding importing and exporting loads from SAFE.

Back in the day, it was pretty smooth and the button worked as intended. Now, the button does not work and after communication with CSI, they know that the button does not work.
I assume that your slab rebar stuff is similar related to the importing and exporting loads bug.

It is frustrating, I have reverted to manipulating all data through the interactive database editor.

Maybe you can copy and paste from one safe file to another with the interactive database editor?

S&T -
 
Thanks, S&T. It's the same issue with the interactive database editor. It seems like csi has been focused on making etabs take over slab design and ignored safe, it seems to be getting buggier. I am having trouble believing that you can't export rebar from one of the major slab design softwares but it appears so.
 
I played with this a bit and see some of the issues with getting slab rebar out of SAFE.

The database tables lack the geometry parameters to accurately define where rebar elements exist.
Capture_y1kafg.png


Seems like CSI should expand "slab rebar property assignments" tables to include all pertinent parameters for easier access and data manipulation.

Capture1_eyq2dw.png




S&T -
 
S&T - It's worse than just that. Try opening that same model another time and drawing in more rebar, various bits - top, bottom, based on spacing, based on qty, etc. When you try to export the database you'll find that often not all of it shows up. From what I can tell only the newer objects appear, the older ones still are in the model but you can't get to them. The more you play with it the more you see how crap it is. Try drawing rebar after your model is run. It will let you draw some, but you can't edit it or delete it, and at some point you can't even keep drawing it. I gave up my support subscription out of frustration with them. The most I could get was that it's ultimately meant as an analysis tool and design needs to be manually done via post processing. That alone is annoying but if you can't export rebar objects it seriously limits the ability to build post processing tools easily.
 
It seems like csi has been focused on making etabs take over slab design and ignored safe

Not exactly, but I can see the reason why folks would think that. You see, the two programs were "merged together" code wise. Meaning there was a lot of duplicate programming between the two programs that made it challenging to maintain in two separate projects. If you found a bug in one program, you likely had to correct it in two places. But, since the code wasn't the same (just similar) the bug fix might have worked only for one of them and not the other. Same thing with new features that applied to both programs. Double the programming, double the testing.....

Anyway, that why the two projects were merged together maybe a year ago. Though it was a fairly long/ involved process. I'm not even sure when it truly started. Regardless, the issues that you're noticing could certainly be a consequence of the recently merged code.

The benefit is that SAFE and ETABS both can benefit from some of the features that the other program had. And, development of new features for both programs should be quicker / easier moving forward..... fingers crossed!

Regarding the OP's question, first let me ask what version of the program you're using. I believe an updated version of the program was released just last week!

I can try to recreate these issues with the latest version. But, I'm not sure I can do this on my own. Maybe if one of you had a model I could start with then a simple instruction that will help me see / demonstrate the issue?
 
@JoshPlum - Thanks for taking a look. It's not tricky to reproduce, it's not something that only happens occasionally. I just made a generic model with the built in templates and have drawn in some rebar. This is in V16, I also tried it in V20 and it's the same. I have not tried V21 yet.

Using this test model or your own check this out:

- If you manually draw rebar you are able to see the info via display > tables and also edit > interactive database editing (and of course graphically). Now save the model, close it and open a different model and then close that, re-open the test model. Now draw another piece of rebar and do display> tables or interactive database. You will see that only the new rebar shows up. Graphically all of the specified rebar is there, but you can't get to the data - which means that you can't post process and/or manipulate it.

- Another weird one: After the model is run and locked you can draw in rebar. However, you can't edit or delete it. You can draw to you heart's content but then it's stuck, frozen in time unless you unlock it which ruins a lot of efficiency. If the user has chosen to base cracking/deflections on specified rebar then I can see how you would not be allowed to draw rebar after running, or better yet it should simply invalidate the deflection results but keep the strength design. If the user has chosen deflection based on fea required steel then it shouldn't be an issue to draw rebar over a locked model. What this means is that after running and seeing demands you can't draw rebar in and see if it works. You need to screen shot or post process the data, input your choice of rebar, re-run, and then if you want to tweak it repeat that loop. This is very different from ramp concept which allows you to draw in rebar, and I don't see any technical limitation that would cause this. I know that some firms are writing in house tools to extract the demands and design the rebar in the tool but this is a lot of work when all of that info is in safe already, we just can't get to it and manipulate it.
 
- If you manually draw rebar you are able to see the info via display > tables and also edit > interactive database editing (and of course graphically). Now save the model, close it and open a different model and then close that, re-open the test model. Now draw another piece of rebar and do display> tables or interactive database. You will see that only the new rebar shows up. Graphically all of the specified rebar is there, but you can't get to the data - which means that you can't post process and/or manipulate it.

Okay, I definitely confirm this behavior in the 2016 version of SAFE. But, if I open that model in the version I'm using (v21) the issue in the file still remains. But, if I save it and re-open it, the issue goes away. Very strange.

If I start with a V21 model from scratch, and try to reproduce the behavior, then I cannot reproduce the behavior. However, I have gotten an odd error messages when saving it at this stage. No information about what the error is though. And, when the model opens up and is just fine.

If I had to guess, I'd assume that there was an issue in v2016 (maybe even v19 or v20) that was related to saving this rebar data (which was the cause for that error message I saw). And, that the newer version fixed the issue, but there is some residual "memory" error that hasn't quite gotten fixed and caused that error when I was saving my file. I have to test more. If this is consistently reproducible, I'll flag it to development... even if it's relatively minor. Sometimes little errors are hiding something more significant underneath.

- Another weird one: After the model is run and locked you can draw in rebar. However, you can't edit or delete it. You can draw to you heart's content but then it's stuck, frozen in time unless you unlock it which ruins a lot of efficiency.

That behavior is the same in v21. Honestly, the weirdest part to me is the fact that you can draw rebar without unlocking the model. We don't allow you to make any other significant changes to the model without clearing the results. But, we do have the two solution options (Run Analysis or Run Analysis and Design). So, if I just ran the analysis (with no design) then I probably SHOULD be able to draw (or edit) rebar. I'll ask one of my guys about why we allow the Draw Rebar action to be active when these other ones are not.
 
Why shouldn't you be able to draw rebar after the model is run/locked? How else could you efficiently design/draw rebar. Lets say that after running it shows that a strip needs 5.0 sq. in. of steel. I should be able to draw in (12)-#6 bars and then change my mind and draw in (16)-#5 etc etc. The specifying of rebar doesn't change the analysis results (since the design is linear elastic). Only allowing rebar to be drawn over an unlocked model is very limiting. Is the intent that the user screen shots the demands, unlocks, draws the rebar in, and then re-runs? What would be the reasoning? SAFE defaults to deflections being based on FEA, not user rebar, so the deflections are not affected. If the user switches to cracking based on user rebar then safe could simply not allow deflection plots after changing the rebar.

I'll have to get the trial of V21 and see if there's any improvement.
 
Why shouldn't you be able to draw rebar after the model is run/locked?

Generally speaking, an FEM program does not allow you to change elements that were used in the analysis. Right? Now, programs like ETABS have a "Model Alive" feature which allow you to optimize members without invalidating the model results. Essentially, just upsizing or downsizing the members and checking the new ones with the assumption that the member forces will not have changed. We know the results are valid anymore (because member results will change slightly). But, we allow it.

Now, the rebar shouldn't generally have been used in the analysis, but would have been part of any design checks. So, any new reinforcement would invalidate the design checks. Unless there was a "model alive" type of feature. I've only been with CSI for a few years now and I've got a lot more experience with ETABS than SAFE. But, I don't believe "model alive" was ever a feature of SAFE. Am I incorrect and that's part of the 2016 or an earlier version of the program?

 
JoshPlumSE said:
Generally speaking, an FEM program does not allow you to change elements that were used in the analysis. Right?

JoshPlumSE said:
Now, the rebar shouldn't generally have been used in the analysis, but would have been part of any design checks.

You can't change anything that affects the analysis, but the design is a different story. As long as the design does not affect the analysis then there is no issue. By default SAFE does not use the user specified rebar in the analysis. There is an option to base the cracking on the user specified rebar. So by default there would be no issue. If the user chose the consider the rebar then only the deflection would be invalidated, not the strength design.

The best example to show that this is reasonable is that this is what ram concept allows, presumably the biggest competitor to safe.

Another example is to look at how Etabs does composite beam design. After running the model you can design the steel beams, changing the section, # of studs, spacing of studs, camber, etc etc. because in general the analysis (simply supported beams) are not affected for strength. In Etabs you will get a message on the next run that "design sections don't match analysis sections, do you want to update" which allows a final convergence of the design and analysis.

A bit different, but somewhat along the same logic, etabs allows you to define new load combos after a model is run. As long as they are linear there is no issue (risa does not allow this which is very annoying).

Model alive never existed in SAFE (I've been using safe since v8....), it would be too intense slow for a slab to be useful (it's not really that useful even in etabs).

To flip the question around, how does csi suggest that users design rebar if the user can't select/draw/specify rebar with a run model?
 
Another example is to look at how Etabs does composite beam design

Yes, that's exactly what I was thinking of. The model gets flagged if you make any changes to the member sizes. That the analysis and design results don't match. That's the "intermediate" stage that you can enter. Where, if you re-run the analysis, your member forces may change and your code checks can change.

Honestly, I'm more familiar with this ETABS behavior than I am with any SAP2000 or SAFE behavior.

To flip the question around, how does csi suggest that users design rebar if the user can't select/draw/specify rebar with a run model?

My impression is that the program is more geared towards the users defining support lines and design strips than it is for them to enter individual bars.

I can see how an individual bar or two would be useful if you specify a general bar size and spacing for the whole slab.... Then only add in a bar or two where there needs to be extra reinforcement. But, that's not generally how I've done it personally.
 
I do a lot of flat plate and it would be extremely useful to be able to draw and design the rebar in the program (similar to Concept). Most slabs do not have a typical size and then 1 or 2 add'l bars, the top bars are often detailed at a highly granular level. The large firm I worked at in the past had some fairly clunky tools for dumping the data and then designing in this xls/vba based tool, but it was very clunky. I've seen that other large firms have developed more sophisticated tools but I don't know the inner working. Since all of this data is already in safe it doesn't make sense that we have to dump data and build tools.

Regardless, it seems like these are bugs in the program - I don't see why someone would have intentionally programmed it to behave the way it does. If you're able to get any info on if this is a bug or intentional, or any workarounds that would be great.

(I know that one obvious solution here is to switch to ram concept - but we've got a lot of tools that interact with safe that we'd prefer to not abandon).
 
Well, I flagged this (the draw rebar bug / behavior) to the two developers that seem to work on SAFE the most. With an emphasis on how you would like it to behave and how your work process would use this feature.

The rebar table display issue, as I mentioned early, is fixed in the current version. So, I haven't mentioned that to them yet. Though I have some more testing of it on my to do list.
 
Thanks for looking into it. I'm surprised it hasn't been flagged by users before. It seems like safe users have developed a different workflow from ram concept users, with safe users relying on building their own post-processing tools so maybe no one noticed that the rebar is quite wonky to put it nicely.
 
bookowski -

My SAFE experts now tell me that they had a number of requests like your where people wanted to edit the reinforcement without "unlocking" the model (and clearing the results). They had a good amount of internal communication about it. They decided against it because it would open a can of worms.

It actually DOES affect the analysis (which I didn't realize) before. We talked about the stiffness used for cracking. Though, there are settings you can use where this doesn't depend on your reinforcement.

What I didn't realize earlier is that it also affects the MESHING algorithm.

Since it has the potential to change multiple things, they thought it would be safest (pun intended!) for the program to not allow this. The current "work around" suggestion is to take screen shots of the analysis results that will help determine where to add your extra bars and then use those after the solution has been unlocked / cleared. Bummer.

The behavior you describe has been requested by at least a few users. I'm not sure how many, but when I started quizzing him more specifically about what you are trying to do, he cited multiple users that had requested this. It might be one company, or it might be a lot, I just don't know.

When I was at RISA, the quickest way to "elevate" a request like this would be get it to the sales engineers (because the Sales department runs RISA). So, whenever you download a trial version, and are asked for feedback on the program you could respond about the one feature that you'd like to see before buying. I'm not as confident that this would work as well at CSI where there seems to be a lot of overlap / cross training between tech support, sales, and development. But, I'm am confident that the request would be processed. And, if enough people really needed that feature, then they'd find some way to do it.
 
That's great news. I'm curious what he means by there are ways that it can work, if there is a particular trick or workaround it would be good to know. I will gladly upgrade to the new version if this works.

While you're trying to get it to work try exporting the drawn rebar to dxf. This was in my same bug bucket list that I forgot to mention the first time around. Similar to the tabular data I find that exporting to dxf is often missing some or most of the rebar.

The goal would be to be able to draw in and design your rebar in safe and then export directly to a drawing.

We were recently overloaded and I had subbed out some flat plate work to a guy that uses Ram. He sent me over a dxf of the rebar straight out of concept. This is how I got started down the path of trying to make safe do this. I've been using safe for a long time but like everyone else I was using it as an fe analysis tool only, with all design being post processed and then drawn manually. The realization that concept can do design and straight to a drawing was like seeing the light. If SAFE could get there this would be a huge leap.
 
@JoshPlum - Circling back on this. Do you have any experience with ram concept? They are making this work so I would think that csi could look to their method to see how it could work. Taking screenshots seems like a pretty big ask as a workaround, and not very robust in terms of qa/qc. I've been looking at dumping all the data externally and developing an external tool for design but this is almost building a 2nd program. I'm also looking at switching to concept, but i've been a safe user for so long intertia is holding me back.

I understand that the rebar affects the meshing but this does not appear to be a fatal issue. The meshing and design stations would be what they are. Currently all demands are linearly interpolated between stations. As a first design it could leave meshing and stations as is and check the d/c at each station as it exists in the model. Similar to how etabs will flag "not all design sections match analysis properties" for steel auto design, SAFE could flag "final design may be affected by updated meshing, do you want to run analysis and design again". I probably need to reinstate my tech support contract to pepper them with this request. I had this conversation with them before and eventually gave up my support out of frustration. It seems bizarre that a major slab design software does not allow you to do rebar design and would suggest that you take screen shots.

I've still not gotten the exporting of user rebar to consistently work either, it's hit or miss with no apparent reason. I'll do a trial of the latest version and see if this has improved.
 
Status
Not open for further replies.
Back
Top