General Mechanical

General Mechanical

Postprocessing Response Spectrum. A Tech. Support Engineer point of view.

    • Dave Looman
      Ansys Employee

      The nuclear industry and the NRC have made response spectrum their preferred method for analyzing earthquake loading for over 40 years. They provide very clear guidelines for its input and how to combine the modal results, but the intricacies of how to use the combined results in a particular finite element program is by necessity the responsibility of the analyst.

      That’s one reason why response spectrum is so loved by the tech. support engineer. It is so tricky it is almost impossible for users to avoid some type of mistake without tech. support assistance. For example, infrequent users can confuse it with random vibration or a harmonic sweep (sometimes called a harmonic response spectrum.) It's easy to do because the response spectrum curve looks very similar to the psd input curve and a harmonic specification of acceleration vs frequency. These users have called tech. support over the years when they noticed damping doesn't reduce the magnitude of the results as it does with other mode-sup methods. It doesn't though because a response spectrum is the solution to a load, not the load itself. The tech. support engineer who has studied response spectrum can be of invaluable assistance in making sure the user avoids any such common mistakes and look like a hero in the eyes of the customer. That's what us tech. support engineers live for!

       A major shortcoming of response spectrum in my mind is that the SRSS type mode combination produces results without sign. That makes most of the usual linear postprocessing operations invalid. Even knowing that, the implication isn't clear unless you know what results are actually on the results file and which are computed "on the fly" at the time they are requested. 

      The basic quantities on the results file are the nodal displacements and reaction forces in the nodal coordinate system and the unaveraged element component stresses in the element coordinate system. A user has no easy way of knowing that, however. What is there is based in part on the need to keep the results file as small as possible and is somewhat arbitrary.  So any operation that attempts to transform results into another coordinate system, sum forces, average stresses or compute derived quantities like SEQV from the component values on the results file can be a source of error. 

      Having said that, there is a special case where a force summation is correct. Starting at 13.0 an enhancement was made to sum response spectrum nodal forces accurately with FSUM accounting for the sign of the forces in the modal results. Also there is a way for a user to obtain a reliable derived stresses like SEQV. The idea is to request that the derived stresses be computed before the SRSS combination. This is done with the command SUMTYPE,PRIN. When this command is issued before the combination, the derived stresses are computed first and then operated on directly. This is slightly conservative, but importantly is an upper bound. With this option the component stresses are zeroed out and will not be available after the combination. It's a simple matter to do the combination twice though with and without SUMTYPE,PRIN. Note that SUMTYPE,PRIN is not available in the WB Mechanical Response Spectrum.

      Some General recommendations for postprocessing response spectrum results are:

      ·        Use the solution coordinate system (RSYS,SOLU)

      ·        Only use FSUM to sum nodal values, not the total provided by PRRSOL

      ·        Use unaveraged element results

      ·        Only use derived quantities like S1, S2, S3, SINT, and SEQV after issuing SUMTYPE,PRIN before the combination.

    • Aniket
      Ansys Employee
Viewing 1 reply thread
  • You must be logged in to reply to this topic.