Need a book? Engineering books recommendations...

Return to index: [Subject] [Thread] [Date] [Author]

Re: SAP, RISA3D, STAAD - Master/Slave Relationships

[Subject Prev][Subject Next][Thread Prev][Thread Next]
I'm starting to feel ganged up on, but I shall persevere!

As pointed out by Swaminathan, the crux of all this is that we are working
with different definitions of master/slave. I define a master/slave
relationship as a shared DOF, and that's it. This is, of course, documented in
RISA-3D and RISA-2D, and this is how it's always been in those programs.

As an aside, Stewart had mentioned an older STAAD master/slave model that gave
him equal x, y and rotation displacements for his diaphragm, obviously not a
correct modeling of diaphragm behavior, but, in fact, exactly what I would
expect a master/slave model to do. As I stated in a previous post, I believe
STAAD used to interpret master/slave the same way (as me) and Stewart's
comment reinforces that, though I understand STAAD's interpretation of
master/slave may be different now.

As a further aside, in an earlier post I had said Greg Luth's modeling of a
diaphragm using master/slave was *wrong*. This was because Greg and I were
working under different assumptions as to what "master/slave" meant and so I
was *wrong* to say that. My apologies to Greg.

Ok, that said, let's discuss diaphragm modeling with your (Luth, Steward,
Nevatia, Krishnan) definition of a master/slave relationship.

While the simple transpositions presented by Rudra will correctly adjust the
load vector on the front end and the displacements on the back end of the
solution (sort of, read on) I am of the opinion that you are creating a
"pseudo" rigid link as opposed to a *real* rigid link, and that there is, in
fact, a difference. Here's why:

If we lock the table top nodes together for in-plane displacements and
rotation only, they are not connected for out of plane rotations and vertical
displacements. If we push on one corner of the table top, we not only get in-
plane translations and rotation, we should also see uplift on the corner being
pushed on, with resulting effects on the other corners. This isn't addressed
with the pseudo rigid link, but is handled correctly with a *real* rigid link
because the real rigid link retains independent DOF for the corner nodes.
Another example: What if we introduce a support settlement at the base of one
of the columns? This node is out of plane and is not slaved, but this load
will definitely impact our diaphragm, and the previously mentioned
transposition isn't going to account for it. 

Another consideration: With this pseudo rigid link, how is the bending
rotation at the tops of the columns resisted? Real rigid links will provide
bending restraint to the columns (or not, if that's what you want). With the
pseudo rigid link and our table top model, we have no choice but to assume our
columns are pinned (for bending) to the diaphragm.

RISA-3D has an explicit "rigid diaphragm" option where *real* rigid links are
automatically created at a diaphragm level, so master/slave relationships
would never be used to model diaphragm behavior in RISA-3D.

So, in summary, I agree that your definition of master/slave will model
diaphragm behavior (sort of), with these caveats:

--You don't care about out of plane displacements and rotations
--You don't consider the diaphragm to provide bending restraint to the columns
--You do the front and back end transpositions (described by Rudra)
--You account for the master/slave and non-slave/slave COUPLED stiffness
matrix terms (not described by Rudra)
--You don't have any out of plane loads/effects applied to your diaphragm

As for me, I'll stick with *real* rigid links.

As pointed out in a previous post, anyone using master/slave should review
their program's documentation to understand what exactly is being formulated.

Bruce Bates
RISA Technologies