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 have read the discussion about "slave / master" and related options with
great interest. First, I have to point out that all contributing persons
have deep knowledge and understanding of mechanics, and in particular of
the "slave/master" problem. 
My impression is that the main reason of difficulties which different
software user had encountered is lack of commonly accepted nomenclature of
different modeling options and lack of proper attention put by software
vendors to document properly what are they in fact doing in the code. 

Let me explain how we dealt with these problems while developing in early
90' our general purpose (but civil engineering oriented) structural
analysis software (i.e. ROBOT v.6 under DOS or ROBOT '97 for Windows'95 &
NT) and how we call them in our English language version. NB, the system
concerns static & dynamic analysis of any 2/3D beam/surface element system;
for details contact www.robobat.com. 

The related options are: RIGID LINKS, OFFSETS AND COMPATIBLE NODES
----------------------------------------------------------------
"RIGID LINKS" 
Designed to model rigid body inclusion within the deformable system. The
syntax of the option in the ROBOT structure description language (and
corresponding dialog box while interactive mode is used) is as follows: 

RIGid
           <list_of_nodes> LINK <master_node> ([relaxed_DOF_code_list])

what means that nodes from <list_of_nodes> are rigidly linked with
<master_node> by all DOFs, despite these, which are specified on the
([relaxed_DOF_code_list]). Translations of a node at rigidly linked
directions from <list_of_nodes>are such as result from the translation and
the rotation of the <master_node>, and their rotations are identical. We
perform forces and stiffness matrix offset transformations for all elements
connected to nodes from <list_of_nodes>. In turn displacements of the nodes
from <list_of_nodes> are evaluated from the translation and the rotation of
<master_node>.

This enables us to model diaphragms (floors in building skeletons) in a
following simple way (assuming Z as vertical direction, consider that nodes
1,2,3,4 are the nodes by which 4 columns are hinged to the in-plane
perfectly stiff floor) it is enough to put:

RIGID
2 3 4  LINK  1 UZ  RX RY

In that way nodes 1,2,3,4, of the floor will have rigidly tied X, Y
translation displacements and Z - rotation in global coordinates, but Z
(vertical) displacements, and X, Y rotations will be independent for each
column at the connection with the floor. This corresponds to the diaphragm
perfectly rigid in its plane but perfectly deformable out of its plane. 

NB. I have to admit that programming this selective DOF rigid link option
was one of the most complicated parts of the whole development. 

Some limitations are however important while using the option "RIGID
LINKS":
rigid support can not be set at nodes from list ( only elastic are
acceptable) 
different groups of  "RIGID LINK" must be separated  by some deformable
elements
in dynamics the presence of "rigid link " options inevitably spoils the
diagonal structure of the mass matrix when lumped masses are used. In such
case consistent mass matrix should be used
one must be careful while using "rigid link" in the geometrically
non-linear  analysis. Particularly when large rotation are taken into
account "rigid link" as described for linear static are only very rough
simplification (NB, does anyone know the software dealing with "rigid link"
in the context of large rotations?)

----------------------------------------------------------------------------
---
"OFFSET" to handle (element-wise) the situation when beam element ends
centroid positions are shifted from the points (nodes) by which they beam
is connected with the rest of the structure 
Syntax: 
EXCentricity
  <List_of_elements> (ORI < X1,Y1,(Z1)>)( END< X2,Y2,(Z2))(LOCAL|GLOBAL)

which are in fact RIGID LINKS with no relaxed DOFs, built-up without the
necessity to define the new, offset pair of nodes.

----------------------------------------------------------------------------
-----
"COMPATIBLE NODES" to handle very common situation when different nodes
share user-specified DOFs. Example - pinned connection of crossing X -bars.
The corresponding nodes should however occupy the same position in the
space. 

Syntax: 
COMPatible
 <Node_1>  <List_of_common_D.O.Fs>  <Node_2>

----------------------------------------------------------------------------
-----

Attachment of the same DoFs to the group of nodes occupying DIFFERENT
positions in the space, but without "rigid link" type transformation is not
physically based, and as such, would never lead to correct results. Note -
this option describes a sort of a constraint - but what physical action can
assure that kind of a constraint? I think that this option has been built
in to many codes only because its programming realization is almost trivial
(attachments of the same equation number to the different nodes according
to given list).
The only known physically based and sensible application of such an option
is imposition of periodic boundary condition in the case of FEM analysis of
the representative cell of the periodic composite, but I do not think that
this was the reason of the appearance of this option in early FE codes.

Aleksander Urbanski, PhD,

Consultant & software developer, author of the computational module of
ROBOT structural analysis package.