@Wasabi I always do offsets. It gets the moments right and I like for the model to look like reality. It helps to visually see if everything is modeled correctly.

@Air That is a good sign that we will eventually graduate and not be caught in the new unending purgatory of "beta without a worry of being shut down".

@hazzey Yes, that was my takeaway as well. Growth is slow but steady; we may not get there as quickly as another site has or could but we'll get there.

@hazzey Do you therefore design your beams to flexo-tension and your slabs to flexo-compression?

@Wasabi - Interesting discussion. I've not modelled anything in anger for a couple of years (since I switched to writing the software rather than using it), but a) I always used pseudo-grillages rather than modelling the slab as plate elements; b) I hate offsets and avoid them if at all possible.

One of my major gripes with LUSAS is where supports and loads are applied if you have offset geometry. For example, if you have a simply supported beam, with vertically offset geometry, vertical applied load will result in an axial internal load.

Why? Because the neutral axis is at the offset level, whereas the support is applied at the nodal level; the supports therefore resist the expected tension at the nodal level, compressing the whole beam. It does make sense, but every time I use offset geometry I have to spend a lot of time working out whether I also need to offset my loads somehow or not.

@Wasabi - With respect to flexo-tension and flexo-compression: Assuming you've modelled it correctly (i.e. got the loads applied at the right height) the results you get out will be true to life. In a composite beam the slab is in compression (with slight bending) and the beam is in flexo-tension.

The problem I find is that most design codes are written assuming you have moments/shears etc. on a composite beam. So when you come to do code checks you have to take your beam stresses and your slab stresses and add them together and back calculate... It's much simpler just to have a beam element in you model, that represents your composite beam, so that you can then just take the results and plug them into your design code equations.

@AndyT That's precisely my point. Are offsets more true to reality? Yes, no discussion. Are offsets worth it given how we (and the codes) design? I personally don't think so.

@AndyT I've never used LUSAS or such programs that allow you to define the insertion point away from the centroid (unless ROBOT and STRAP allow one to do so and I just didn't know!). But shouldn't the support be offset as well, such that it rests at the foot of the beam (meaning the support's offset wouldn't be equal to the beam's)?

For something "simple", designed to a "normal" code, offsets are more of a hindrance than a help. For more complicated geometry, when you depart from basic beam theory, offsets are definitely worth it.

@Wasabi - Being able to offset the supports would be a good feature. Unfortunately LUSAS (which is the only program I've used offset geometry in) doesn't allow it. So you have to define your elements at the support level, and then offset your geometry from that.

Folks, would this be on-topic for Engineering.SE? Look like this question is more about optics than EE.