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]
>From various posts, I believe we have stumbled onto the crux of the 
matter, i.e., a muddled definition of terms. Chen points this out.  I 
believe that we should continue with the terms originally stated by 
the developers of the concepts. Nevatia cites "Structural Analysis" by 
Ghali & Neville for definition of the master/slave relationship, which 
in turn cites work by Weaver and Nelson ("Three-Dimensional Analysis 
of Tier Buildings," Proc. ASCE, Vol 92, No. ST6 (1966),pp. 385-404). 
 Actually, Clough, King & Wilson "Structural Analysis of Multistory 
Buildings" (Journal of the Structural Division, ASCE, ST3, June 1964, 
pp 19-34) pre-date Weaver and Nelson by two years.  In this paper, the 
authors detail exactly how the diaphragm reduces the number of DOF's.

As for the master/slave definition supplied by Bates/STAAD (i.e., 
 slaves do not reflect the rigid body rotation of the master), I am at 
a loss to find a real-world structural example of where this may occur 
when there is a spatial separation between the master and the slave. 
 In the special case where the slave coincides with the master, i.e, 
pinned x-bracing, I can visualize Bate's/STAAD definition.  But 
realize that the Ghali and Neville formulation also works here.  If 
this is so, then the question arises as to why we need the Bates/STAAD 
definition at all.

With regards to Bruce Bates of 1/2/98:

>If we lock the table top nodes together for in-plane displacements 
>rotation only, they are not connected for out of plane rotations and 
>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 

Not true.  We'd get uplift on a leg if and only if a beam element 
connects the tops of two appropriate legs to together.  It is the 
relative displacement (local y) of the beam ends that produces the 
uplift forces/displacements in the table legs.  Even your "real" rigid 
link shouldn't provide uplift forces, unless it has assumed some sort 
of beam element built into it (bad idea!).

>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 
>will definitely impact our diaphragm, and the previously mentioned
>transposition isn't going to account for it.

The Ghali and Neville formulation will properly account for this.

>Another consideration: With this pseudo rigid link, how is the 
>rotation at the tops of the columns resisted? Real rigid links will 
>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.

The stiffness/DOF for rotation of the column tops should be left to 
the user of the program.  It is the user that must provide for the 
stability of the structure and to model the beams at the diaphragm 

>RISA-3D has an explicit "rigid diaphragm" option where *real* rigid 
links are
>automatically created at a diaphragm level, so master/slave 
>would never be used to model diaphragm behavior in RISA-3D.
>So, in summary, I agree that your definition of master/slave will 
>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 
>matrix terms (not described by Rudra)
>--You don't have any out of plane loads/effects applied to your 
>As for me, I'll stick with *real* rigid links.

I think we better define terms.  I recommend that we go back to the 
original definitions of the pioneers.  Anybody have an old SAP IV 
manual??  Or perhaps we should refer this whole conversation to Ed 

Warren Stewart, SE
Frederic R. Harris, Inc.
San Pedro, CA

Chang Chen  wrote:

>This subject was discussed extensively by Warren, Bates, Krishnan, 
>and Nevatia.  After reading all responses, I have to agree with 
>based on my past experience of writing my own program for dynamic
>analysis of multi-story buildings with rigid floor diaphragms.
>As pointed out by Bates, the crux of the matter is the definition of
>master/slave relationship.  We all have to make up our mind as to 
>is master/slave relationship.  The definition given by Ghali & 
>in "Structural Analysis" as shown below assures that the master and
>slave nodes have the same rotation but different displacements.  Are 
>satisfied with this definition?  Or do we want master and slave nodes 
>have same rotation as well as displacement?
>As a matter of fact, the definition given below by Ghali and Neville 
>the same equation I used to model a rigid diaphragm more than 25 
>ago.  Thus, to avoid future confusion, may I suggest that a true
>master/slave relationship be defined as the one which assures the 
>displacement and rotation for all assigned master/slave degrees of
>freedom.  The definition given below by Ghali and Neville should be
>reserved for relationship between nodes on a rigid diaphragm.
>IMHO, If one wants to model a rigid diaphragm, he or she should 
>use the equation below by Ghali and Neville in writing his or her 
>program, or use rigid links in general purpose programs, e.g., SAP,
>Chang Chen, Ph.D., P.E.
>Apollo Consulting, Inc.
>Rudra Nevatia wrote:
>> I agree with Warren's point that master/slave, diaphragm and
>> rigid link are all synonymous mathematically. The displacements,
>> actions and stiffness matrices corresponding to slave DOF's are
>> transferred to master DOF's by the following relations :
>> (See section 16-7 of "Structural Analysis" by Ghali & Neville)
>>                     {q} =  [C].{D}
>>                     {F} =  transpose [C] . {Q)
>>                     [Sm] = transpose [C] . [Ss] . [C]
>> where
>> {q}  = displacements at slave DOF's
>> {D}  = displacements at master DOF's
>> {Q}  = actions at slave DOF's
>> {F}  = equivalent actions at master DOF's
>> [Ss] = stiffness matrix at slave DOF's
>> [Sm] = stiffness matrix at master DOF's
>>           | 1  0 -y |
>> [C]  = | 0  1  x |
>>           | 0  0  1 |
>> x,y  =  co-ordinates of slave node with origin at master node
>> I have verified that the master/slave method when applied in
>> this fashion gives correct results for translations *and*
>> in-plane rotations.
>> Incidentally, static condensation is a process of folding
>> (usually) internal DOF's into external DOF's of an element. This
>> process is not applicable to master/slave DOF's.
>> Rudra Nevatia
>> Central Computing Facility