IV.4.1.2 “Post-processing” classes

All the post-processing classes derive from the generic “GenPost” class defined in file “PGR/post.rb”. A post-processing object performs the calculation of a one or several criteria on a specific structural part or interface. It then manages the following operations:

• Initialization and storage of the data defining the post-processing object.
• Method “calc_0” generally performs the extraction of Results from the active FEM database. This method is defined in base “GenPost” class, but will generally be re-defined in all the specialization classes. Extracted Results are stored in @step_0_results member data.
• Method “calc_1” performs linear operations on extracted Results, or operations that are not specific to the calculation of a failure criterion. Corresponding Results are stored in @step_1_results member data.
• Method “calc_2” performs the calculation of failure criteria, which generally involve non-linear calculations. Corresponding Results are stored in @step_1_results member data.
• Method “calculate” chains the three calculation steps. For static load cases, the chaining is done as follows:
      when "Static" then  
          calc_0()  
          calc_1()  
          srLcName=currentLcName  
          mosLcName=currentLcName  
          if self.respond_to?("calc_2") then  
              calc_2(srLcName,mosLcName)  
          end  
          @step_0_results = {}  
          @step_1_results = {}  
          @step_2_results = {}

  Remark that one tests that “calc_2” method is defined as this method is not defined in “GenPost” base class, and not necessarily defined in derived classes. For the dynamic load cases, that produce complex Results, the chaining is done as follows:

      calc_0()  
      calc_1()  
      # calc_2 not necessarily defined in sub-classes :  
      if self.respond_to?("calc_2") then  
          lcNameA=currentLcName  
          # One backups the complex results and uses them as argument in iterator :  
          bakResults=@step_1_results  
          DbAndLoadCases.iterateOnTheta(currentLcName,bakResults) do |srLcName,mosLcName,results|  
              # One performs the calculations with the Real results :  
              @step_1_results=results  
              calc_2(srLcName,mosLcName)  
          end  
      end  
      @step_0_results = {}  
      @step_1_results = {}  
      @step_2_results = {}

  Here again, the existence of “calc_2” method in the Post object is tested. One also remarks that the iteration on the different phases is done inside the “calculate” method by calling “DbAndLoadCases.iterateOnTheta”. This method produces real results from complex ones. Indeed, “calc_2” methods defined in derived classes can deal with real Results only.

• Method “getParam” is used in the post-processing specialization classes to obtain parameters. Parameters can be defined at different levels. Function “getParam” looks for the parameters in the following order:

  1.

  In the “@parameters” Hash member data of “GenPost” class.

  2.

  In the “critParams” Hash optional argument the “getParam” method.

  3.

  in the parameters associated to current laod cases, and that are retrieved with “DbAndLoadCases.getParam(paramName)” instruction.

  “getParam” method has two arguments:

  1.

  A String corresponding to the name of the parameter.

  2.

  An optional Hash argument corresponding to the list of parameters associated to a criterion.

• Different methods are related to the the management of @mosResults and @srResults member data. Among these methods, only the “updateSrResults” method present some complexity as one of its purposes is also to aggregate the strength ratios produced by different post-processing objects.

The different member data of “GenPost” class deserve some explanation as well:

• “@step_0_results” is a Hash that associates a String Result name, to a Result object. These Results by “calc_0” method.
• “@step_1_results” is a Hash that associates a String Result name, to a Result object. These Results by “calc_1” method.
• “@step_2_results” is a Hash that associates a String Result name, to a Result object. These Results by “calc_2” method, when applicable.
• “@mosResults” is used to store temporarily results to be saved in excel-like SQL Tables. This variable contains an Array of which each element is an Array of 4 elements:

  1.

  A String corresponding to the name of the SQL table in which results will be saved. This String is defined when post-processing object is initialized. It is not “hard-coded” in post-processing class code.

  2.

  A String containing the SQL statement for table creation.

  3.

  A String containing the SQL statement for insertion in table.

  4.

  An Array corresponding to the values to be inserted in the SQL table.

  In the end, each “@mosResults” element should correspond to a line saved in an SQL table.

• “@srResults” is used to store temporarily the Strength Ratios for later archiving in SQL database. Storage is done in a Hash object. Each key is an Array of 4 Strings corresponding to:

  1.

  A load case name,

  2.

  The name of a GMSH file,

  3.

  A GMSH result name,

  4.

  A location or FEM association (for example “ElemeCenters”, “ElemCorners”, “Nodes”...).

  The value associated to each key is a Result object (normally a real scalar one).

  The reader will have understood that the purpose of saving Results in a temporary variable is to prepare the production of GMSH files for the visualization of Strength Ratios. A Strength Ratio is a Result object corresponding to the inverse of RF, but mapped to part of the structure.

Note that the “Post” classes have been programmed in such a way that they remain, as much as possible “unaware” of the peculiar solver that has is used to produce the results that are post-processed. In particular:

• “calc_0” and “calc_1” steps should not care whether the Results that are post-processed are real or complex. Or when it matters, the format of Results should be tested to be managed by appropriate code.
• The example “Post” objects should work as well with as with Nastran Results. When post-processing Nastran Results, the reading of Results from OP2, HDF or XDB file is not supposed to produce different outputs. Practically, this behaviour is obtained by accessing FEM results via calls to “DbAndLoadCases.getResult” method.
• Note also that the Result names used to specify to “DbAndLoadCases.getResult” method which Results are requested are always real Result names. (There is no “ (MP)” or “ (RI)” involved.) “DbAndLoadCases.getResult” method manages a mapping that allows to access the relevant complex Results when needed.

The classes inheriting “GenPost” class are listed below.

IV.4.1.2.1 “PostCauchyStress” class

This class is devoted to the post-processing of “Stress Tensor” Results. It proposes several failure criteria corresponding to Von Mises or core justification. For a single “Stress Tensor” Result extraction, several failure criteria can be calculated, and parameters specific to each failure criterion are defined in the data for this failure criterion. (See the definition of data in section IV.4.2 for more details.)

IV.4.1.2.2 “PostLaminate” class

This class is devoted to the calculation of composite failure criteria via the classical laminate analysis. Here also, several criteria can be calculated by each “PostLaminate” object, but always for a single calculation of Stress or Strain Tensor Result.

IV.4.1.2.3 “postConnect.rb” class

This class is devoted to the justification of connections. It presents several failure criteria corresponding to sliding of interfaces, gapping,failure of inserts, failure of bolts (according to method proposed in [otNCE21]), failure by bearing.

Note that:

• Each criterion is associated to its own specific parameters.
• For the failure of bolts, the programming of failure criterion according to NASA-STD-5020 makes use of the predefined interaction criterion “Interaction_abg_N_SR” discussed in section X.D.1.6.

IV.4.1.2.4 “postExtract.rb” class

This method performs simple extractions of results, to be archived in excel-like SQL tables, but without actual calculation of failure criteria. This is an example of post-processing class in which no “calc_2” method is defined. Also, this class does not fill the “@srResults” member data.