Eigenvalue analysis

The efficient Lanczos algorithm [Hughes, 1987] is used by default for the evaluation of the structural natural frequencies and mode shapes. However, the Jacobi algorithm with Ritz transformation may also be chosen by the user in the project settings menu. Evidently, no loads are to be specified.

Eigenvalue analysis is a purely elastic type of structural analysis, since material properties are taken as constant throughout the entire computation procedure and hence it is natural for elastic frame elements (elfrm) to be employed in the creation of the structural model. As described in here, this type of elements do not call for the definition of material or section types, as their inelastic counterparts, being instead fully described by the values of the following sectional mechanical properties: cross-section, moment of inertia, torsional constant, modulus of elasticity and modulus of rigidity [e.g. Pilkey, 1994]. Therefore, an estimate of the vibration period corresponding to the cracked, as opposed to uncracked, state of the structure, can be readily obtained by applying reduction factors to the moment of inertia of beam and column cross-sections, as recommended by Paulay and Priestley [1992], amongst others. These factors may vary from values of 0.3 up to 0.8, depending on the type of member being considered (beam or column), loading characteristics, and structural configuration. Users are advised to refer to the work of Priestley [2003] for a thorough discussion on this matter.

If the user, however, wishes to carry out not only eigenvalue but also other types of analysis, possibly within the inelastic material response range, then he/she might prefer to build only one structural model, employing inelastic rather than elastic frame elements, that will be employed on all analyses, including the eigenvalue one. In this case, different material and section types are employed in the characterisation of the elements' sectional mechanical properties, which are no longer explicitly defined by the user, but internally determined by the program instead, using classic formulae that can be found on any book or publication on basics of structural mechanics [e.g. Gere and Timoshenko, 1997; Pilkey, 1994]. As a consequence, it results impossible for users to directly modify the second moment of area (or moment of inertia) of cross-sections to account for the effects of cracking, for which reason the stiffness reduction of members due to cracking should be instead simulated by changes applied to the modulus of elasticity of the concrete material (e.g. by reducing it by the same factor that one would apply to the moment of inertia of a cross-section).

Notes

  1. The use of inelastic elements in eigenvalue analysis features also the advantage of exempting the user from the onus of (manually) calculating the section mechanical properties of each element type, taking full account of the presence of longitudinal reinforcement bars within the section.
  2. Concrete confinement will increase the compressive strength of the material, and hence the stiffness of the member, leading thus to shorter periods of vibration.
  3. When running an eigenvalue analysis using Lanczos algorithm, user may be presented with a message stating: "could not re-orthogonalise all Lanczos vectors", meaning that the Lanczos algorithm could not calculate all or some of the vibration modes of the structure. This behaviour may be observed in either (i) models with assemblage errors (e.g. unconnected nodes/elements) or (ii) complex structural models that feature links/hinges etc. If users have checked carefully their model and found no modelling errors, then they may perhaps try to "simplify" it, by removing its more complex features until the attainment of the eigenvalue solutions. This will enable a better understanding of what might be causing the analysis problems, and thus assist users in deciding on how to proceed. This message typically appears when too many modes are sought, e.g. when 30 modes are asked in a 24 DOF model, or when the eigensolver cannot simply find so many modes (even if DOFs > modes).