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 understand that RISA3D and STAAD  have "slave/master" problem. Recently,
year ago, I bought the programm called "STRAP". In this program
"slave/master" is the most easily created. See 
Leonid Shectman P.E.----------
> From: JACEKLK <JACEKLK(--nospam--at)>
> To: seaoc(--nospam--at)
> Subject: Re: SAP, RISA3D, STAAD - Master/Slave Relationships
> Date: Wednesday, April 01, 1998 2:34 PM
> I have read the discussion about "slave / master" and related options
> 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
> 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
> for details contact 
> ----------------------------------------------------------------
> 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
> the rotation of the <master_node>, and their rotations are identical. We
> perform forces and stiffness matrix offset transformations for all
> connected to nodes from <list_of_nodes>. In turn displacements of the
> from <list_of_nodes> are evaluated from the translation and the rotation
> <master_node>.
> This enables us to model diaphragms (floors in building skeletons) in a
> following simple way (assuming Z as vertical direction, consider that
> 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:
> 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
> 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
> 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
> 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
> 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
> 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
> physically based, and as such, would never lead to correct results. Note
> this option describes a sort of a constraint - but what physical action
> 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
> (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
> is imposition of periodic boundary condition in the case of FEM analysis
> the representative cell of the periodic composite, but I do not think
> 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.