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 = {}
  

  Note that the existence of “calc_2” method is tested 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. Note also 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 with the current load cases, 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 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 are produced by the “calc_0” method.

• “@step_1_results” is a Hash that associates a String Result name, to a Result object. These Results are produced by the “calc_1” method.

• “@step_2_results” is a Hash that associates a String Result name, to a Result object. These Results are produced by the “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 particular solver that 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 Samcef 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. In practice, 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. A “PostCauchyStress” object is created as follows:

        p=PostCauchyStress.new()
        p.setData(partName,loc,grpName,layers,criteria,params)

The parameters of “setData” method are explained in Table IV.4.1. It is the user’s responsibility to write the code that builds the post-processing objects with appropriate parameters. (See examples of definitions 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.A “PostLaminate” object is created as follows:

        p=PostLaminate.new()
        p.setData(partName,loc,grpName,layers,criteria,params)

The parameters of “setData” method are explained in Table IV.4.2. It is the user’s responsibility to write the code that builds the post-processing objects with appropriate parameters. (See examples of definitions of data in section IV.4.2 for more details.)

IV.4.1.2.3 “PostConnect” 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... A “PostConnect” object is created as follows:

        p=PostConnect.new()
        p.setData(ifName,params)

The parameters of constructor method are explained in Table IV.4.3. It is the user’s responsibility to write the code that builds the post-processing objects with appropriate parameters. (See examples of definitions of data in section IV.4.2 for more details.)

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” 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.

IV.4.1.2.5 “PostBuckling” class

This class is used to post-process the buckling results. Post-processing of buckling results requires an additional preliminary step before launching the Static loop analysis. Method “identifyCriticalBucklingElemLoadCases” is used to build a separate SQLite database containing a summary of buckling load case results. File “DATA/postBucklingDatag.rb" in post-processing main directory illustrates the use of this method. For example:

    sqlDbName="buckling.db3"

    datFile="../../MODEL/EXEC_XDB/sol105_unit_xyz.bdf"
    resFile="../../MODEL/EXEC_XDB/sol105_unit_xyz.xdb"
    PostBuckling.identifyCriticalBucklingElemLoadCases(datFile,resFile,sqlDbName)

    datFile="../../MODEL/EXEC_XDB/sol105_temp_grad.bdf"
    resFile="../../MODEL/EXEC_XDB/sol105_temp_grad.xdb"
    PostBuckling.identifyCriticalBucklingElemLoadCases(datFile,resFile,sqlDbName)

    datFile="../../MODEL/EXEC_XDB/sol105_temp_disc.bdf"
    resFile="../../MODEL/EXEC_XDB/sol105_temp_disc.xdb"
    PostBuckling.identifyCriticalBucklingElemLoadCases(datFile,resFile,sqlDbName)

In this example, SQLite database containing the buckling results is stored in file “buckling.db3” in post-processing main directory.

The function builds for each load case in a Nastran SOL 105 analysis output file (HDF5 or XDB), a map of the critical load factors associated to the different parts of the structure. More precisely:

• One reviews all the buckling modes associated to the load case. For each mode, one identifies the nodes having a displacement at least 10% of the maximum displacement for this mode. These nodes define the buckling area. One associates the critial load factors to these nodes (scalar Result).

  The 10% threshold is a default value corresponding to parameter “magRatio” of “PostBuckling.identifyCriticalBucklingElemLoadCases” function.

• One then builds an envelope of the critical load factors. In this envelope, each node is associated to the smallest critical load factor of buckling mode to which the node “participates”.

• For this construction on distinguishes two “positive” and “negative” envelopes, depending on the signs of the critical load factors.

• The nodes that participate to no buckling mode are associated to the largest critical load factor, in absolute value:

  $$EN{V}_{\text{default}}=\pm \underset{i}{max<!--FUNCTION\; APPLICATION-->}\left|CL{F}_i\right|.$$

In the end, for each load case, one builds two scalar Results corresponding to the positive and negative envelopes respectively (Figure IV.4.1). The load case names to which envelope Results are associated are the Nastran static load case names. This means that the buckling load case names must be transformed into static ones. In our class, the default transformation is done in method “filterBucklingLcName” as follows:

    shortLcName=tmpName.strip.gsub("BUCK_","").gsub("BUCKLING_","")

This default transformation can be modified via a redefinition of method “filterBucklingLcName” in a class deriving from “PostBuckling”

Figure IV.4.1: Storage of buckling positive and negative critical load factor envelopes in SQLite database.

The rest of buckling post-processing is done as for the other criteria. The only difference is that the positive and negative envelopes of critical load fators are extracted from SQLite database "buckling.db3" and not from Nastran HDF5 or XDB files. One distinguishes the elementary and combined load cases:

• For elementary load cases one always considers the positive envelope of critical load factors.

• For combined load cases, one approximates the combined load case critical load factors by calculating linear combinations of positive and negative critical load factors:

  $$SR\left(CLC\right)=\sum _{i=1}^N\left|{\alpha }_i\cdot SR\left(EL{C}_i\right)\right|,$$

  in which $SR$s are Strength Ratios:

  $$SR=\frac{1}{RF}=\frac{1}{CLF}.$$

  In the linear combination above, the one uses postive elementary envelopes if ${\alpha }_i\ge 0$ and negative elementary envelopes if ${\alpha }_i<0$.

As for the other post-processing classes, “PostBuckling” outputs “xl_” outputs and SR mapping on the structure. The calculation of buckling can be done for separate parts. Parameters of the “PostBuckling” class are summarized in Table IV.4.5. An example of buckling distribution of strnegth ratios is shown in Figure IV.4.2.

Figure IV.4.2: Example of envelope of buckling strength ratios distribution.