FeResPost

A Library distributed under LGPL license that allows you
to automate the post-processing of Nastran and Samcef  finite element results or FE model manipulations
with the programming language of your choice (Python, Ruby, C++, C, C#, VBA in excel...)




FeResPost library System requirements Documentation Downloads Install Mailing list Examples Videos License



FeResPost library description

FeResPost library

FeResPost is a  library that allows you to read Nastran and Samcef finite element models and results, and to automate post-processing operations.
 
Depending on the programming language being used (Ruby, Python, VBA, C#, C++...), FeResPost allows to program a wide variety of programs ranging from small scripts to large programs containing user-defined Classes and Modules, and allow to perform complex operations.
 
(The scripting capability of FeResPost can be very useful to automate simple tasks as automating the creation of connections, modifying element properties, creating temperature or force fields...)

Structural analysis

The structure analysis of complex structures often leads to repetitive tasks. This is related to :
This explains why engineers involved in structural analysis are often also programmers. The need for automation leads them to use spreadsheets, use third party programs to accelerate the justification, or write its own post-processing programs. FeResPost can help in the development of these small programs!

How can FeResPost help?

The main purpose of the program is to download and manipulate Result entities in order to calculate margins of safety. Possible operations that can be performed on ``Result'' objects are, for example :
So far, these results can be read from Nastran HDF5, XDB or OP2 files, or from Samcef DES/FAC files. The corresponding finite element models can also be important from Nastran Bulk BDF files, or Samcef Bacon DAT files.
 
The groups of elements and nodes can be read from Samcef DAT or Patran session files. Manipulation of these Groups, by addition, substraction, intersection, associations are possible.
 
FeResPost allows the simultaneous manipulation of several models by defining several NastranDb  and SamcefDb objects, and different Nastran and Samcef models can be manipulated simultaneously.
 
FeResPost also allows the calculation of composite structure by providing severeal classes for the Classical Laminate Analysis (CLA). Among other things, the CLA classes of FeResPost allow to :
The CLA classes can be used separately from the finite element results, but also used together with  finite element results. This allows for example to:

Who should use FeResPost?

The purpose of FeResPost is to automate post-processing operations by programming scripts. This means that FeResPost users must be ready to program his (or her) scripts. Fortunately, several programming languages and environments allow to use FeResPost (Ruby, Python, VBA, C#, C++...).

Some of the examples may give users the feeling that FeResPost provide tools that allow to perform complex operations without programming. It is sometimes true (excel examples). However, the user should keep in mind that those are just examples, and that there is a benefit in understanding how they work. In the case of excel examples, this means that the reading of documentation, the analysis of VBA code, and the testing of code and worksheet modifications will allow significant improved of what is provided.

Those who are not interested or alergic to programming should either "sub-contract" the programming work to their methodology service, or choose Nastran interactive pre- and post-processor (Patran, Femap, Hyperworks, NX...)

FeResPost library Classes and Modules

The library provides an access to 7 classes and 2 module allowing the manipulation of FE entities and results. The 7 classes are :
The ``Post'' module gives access to several additional functions.
 
Four classes used to perform Classical Laminate Analysis calculations are also provided:
The CLA classes are interfaced with the rest of FeResPost and allow to post-process very efficiently composite finite element Results.
 
The program is mainly written in C++, and different wrappings are proposed around the C++ code (Ruby, Python, COM and .NET). This solution ensures that the program is easy to manage and that the program remains efficient because costly operations are done at C++ level (compiled language efficiency).
FeResPost requirements and other programs

System requirements and other programs

Solvers

    So far, Results of Nastran and Samcef solvers can be post-processed:

Nastran

Samcef

Operating systems and programming languages

The library is distributed as a ruby extension (LINUX and Windows), as a COM component (Windows only) and as a .NET assembly (Windows only).  In order to use FeResPost you need to install first one of the corresponding programming languages :
The programming language in which all those operations are programmed is object oriented and allows the development of very sophisticated and large post-processing programs, or very small tools, according to the wishes of the programmer.

Other resources

Besides the installation of the programming language you wish to use, a few other programs may help you to develop scripts using FeResPost. The examples distributed on this web site and discussed in the User Manual sometimes assume that thos programs have been installed on your computer. For example:
FeResPost library description

FeResPost Documentation

The manual presents the different classes defined in FeResPost library, with the associated properties and methods. It also illustrates the use of different FeResPost objects with examples.

An online version of the manual is available here.

FeResPost User Manual is also available in PDF format. An older version version of the PDF manual is downloadable here (version 4.3.0 April 2015). The latest versions of PDF manual can then be downloaded via the Downloads section.

FeResPost downloads

FeResPost Downloads

Latest version is version 5.0.9 !

This page allows you to select the files that you want to download:


FeResPost downloads

Installation of FeResPost

We explain here how FeResPost binaries must be configured to be used on Windows or Linux OS. It is also possible to compile FeResPost from the source. (See FeResPost User Manual.)

Binaries download

Binaries (sources compiled into shared libraries) can be downloaded from FeResPost Downloads page. Just be careful to download the archive that suits your purpose:
  • Choose the version you are interested in (or "thid party contributions", "latest developments"...).
  • Select a "linux" archive if you work on Linux OS, and a "win32" or "win64" archive if you work on Windows OS. If you are using another type of OS, you will have to recompile FeResPost from sources. (See Appendix X.A of FeResPost User Manual for more information.)
  • Select also the right version amount the 32 bits or 64 bits archives. Note that your OS is probably 64 bits. Then, the choice between 32 bits or 64 bits binaries will depend on your installation of ruby, python or of the program with which you use the COM component. For example, many Microsoft Office distributions are still 32 bits, and the 32 bits COM component should then be used.
Because the submission of a new official issue of FeResPost is time consuming, one often publishes "un-official" distributions of the current version including small bug-fixes. Therefore, we suggest FeResPost users to regularly check the Latest Developments for latest sources or binaries on the Downloads page.

More information on FeResPost download is given in the Downloads page and in Appendix X.A of
FeResPost User Manual.

Extraction and configuration

The content of the archive(s) you have downloaded must be extracted in a suitable location. (You choose this location.) Then, the configuration depends on the kind of extension, component or assembly you are using.

We give below a few examples on how you can make it work, but we do not pretend to be exhaustive. The reader is referred to the documentation of the various languages to find an installation procedure that best suits your needs.

Python and Ruby extensions

There is not much to do to access FeResPost extensions from Ruby or Python. You just have to specify the path to the directory that contains the extension you are using:
  • With Ruby it can be done by specifying the path with "-I" command line. For example:
ruby -I../../../SRC/OUTPUTS/RUBY/RUBY_18 printGroups.rb


The path to directory can also be defined by setting or modifying RUBYLIB environment variable. Then, the "-I" option must no longer be used:
set RUBYLIB=D:/SHARED/FERESPOST/SRC/OUTPUTS/RUBY/RUBY_18
ruby printGroups.rb
      1. With Python by copying the "FeResPost.pyd" file in your site-packages directory. (You can also copy the library in your python script directory.) 
copy D:/SHARED/FERESPOST/SRC/OUTPUTS/PYTHON/PYTHON_27/FeResPost.pyd \
             D:/USERS/ferespost/AppData/Roaming/Python/Python27/site-packages

You can obtain the user-site packages directory by typing the command:

    python -m --user-site
  1. The path to directory can also be defined by setting or modifying PYTHONPATH environment variable:
set PYTHONPATH=D:/SHARED/FERESPOST/SRC/OUTPUTS/PYTHON/PYTHON_27
After this you simply run a python script as follows:
python printGroups.py
   
For Ruby and FeResPost extensions, you must also be careful and use the directory that contains binaries that match the version of the Ruby or Python executable you are using:
  • For Ruby,  RUBY_18 directory corresponds to versions 1.8.* of Ruby, RUBY_19 to versions 1.9.* or Ruby, etc.
  • For Python,  PYTHON_26 directory corresponds to versions 2.6.* of Python, PYTHON_27 to versions 2.7.* or Python, etc.

COM component

The servers must be registered before use. For that purpose, a program called “modifyRegistry.exe” is distributed with FeResPost library.This program is to be found in "OUTPUTS/VOM/bin" directory. It is used to add keys to the Windows register:
  • The component can be registered for the current user only, or for all the users. In the second case, the registration program should be used on an account that has administrator privileges.
  • The registration program allows to register the component as well as to unregister it. If you decide to uninstall FeResPost COM component, you should unregister it before removing FeResPost files.
  • You need to register only the "FeResPost.dll" library and the "FeResPost.tlb" type library file so that the selection of files to register should look as follows:
COM registration program and selected files to register
  • When you are ready, you simply click on "Start Registering COM Component" button.
To unregister the component, you do exactly the same ecept that you click on "Start Unregistering COM Component" button at the end.

Note that to use the COM component, you still need to access it from the aprticular environment from which you are using FeResPost COM component. For example, in excel, you use the COM component in VBA language, and you must refer to the COM component via VBA editor. More information on the different ways to do this is provided in the COM examples of FeResPost User Manual, and in a few COM examples provided in this web site.

.NET assembly

The .NET assembly can be registered by copying the corresponding FeResPost.dll library in the Global Assembly Cache (GAC). On my computer it is simply done by dropping of “FeResPost.dll” into “C:/Windows/assembly” directory. Note however that you need Administrators' privilige to perform this operation.

You can also use an assembly without registration. Then, the assembly must be located in the same directory as the one containing the executable. (That is generally what I do when I test a new version of FeResPost.)


FeResPost downloads

FeResPost mailing list

You can visit or subscribe to FeResPost Google group :

Subscribe to FeResPost Group

E-mail :

Visit this group

If you have a question to ask, a bug to report, we would appreciate that you do it via FeResPost google group, so that others can benefit of your remarks as well.
FeResPost library description

Examples

We propose below a few small scripts illustrating the use of FeResPost to automate operations on finite element models, groups, results...

The examples listed below are only a small subset of the examples distributed with FeResPost. FeResPost examples .
These examples are described and commented in FeResPost Reference Manual that gives more more technical information than what we provide in the linked pages below. As the examples are presented in a sequence that increases the complexity of post-processing operations, the manual that described them should be considered as a tutorial, and we strongly advise new users to spend some time reviewing, testing and modifying these example to familiarize with FeResPost.

Examples with Ruby

Ruby script for reading Nastran BDF file 

Ruby script for access to Nastran Results read from HDF5 file. 

Examples with Python

Python script for reading Nastran BDF file
 
Python script for the manipulation of Groups

Python script for the extraction of results from Nastran XDB file

Python script for the extraction of information from Nastran XDB file

Python scripts showing how Results can be extracted from OP2, XDB or HDF5 files

Examples with COM component

The examples presented here are using FeResPost COM component:
  • This limits the applicability of the examples to Windows platforms. As far as we know, the COM component cannot be used on UNIX/LINUX platforms.
  • On the other hand, the COM component can be used with various languages that support COM. For example: Ruby, Python, Perl, VBA, C++, C,...
FeRespost is distributed with examples of scripts using COM component and written in different languages (Ruby, Pyhton, C++, VBA). We think however, that VBA is particularly interesting for it allows you to access FeResPost from excel. We present below examples of FeResPost being used from excel:

Classical Laminate Analysis in excel using FeResPost COM component

Extraction of Nastran XDB file results into axcel using FeResPost COM component

Post-processing a large selection of load cases on an entire structure with excel using FeResPost COM component.

Examples with C#

A C# program using FeResPost .NET assembly and that reads stresses from Nastran OP2 file

Other Examples



FeResPost license

FeResPost Videos

FeResPost installation


FeResPost COM component registration :

 


FeResPost with excel


Reading dynamic results and displaying curves as a function of frequency :

 


FeResPost license

FeResPost license

FeResPost is distributed as a LGPL resource. This means that it is free, and that you can modify and re-distribute it gratis as long as you comply with ther therms of the LGPL license. (These are given in an Appendix of the User Manual.)

The LGPL license (Lesser General Public License) is similar to GPL license (General Public License) but is less restrictive and more adapated to software distributed as libraries and allows proprietary software to link their code to a library distributed under LGPL. The "L" of LGPL is sometimes considered to correspond to "Library".

We give below a few examples of what you may do or may not do with FeResPost:
The information given above correspond to my understanding of the LGPL license. As I am no lawyer, I can only recommend users to refer to the text of the LGPL license, and find more information from a lawyer competent in this area.

The text of LGPL license is given in an appendix of FeResPost Reference Manual.


File:LGPLv3 Logo.svg



FeResPost allows to automate the following operations :



Read Nastran results with Python Read Nastran XDB results with Python Read Nastran OP2 results with Python Read Nastran HDF5 results with Python Read Nastran H5 results with Python Read Samcef results with Python Read DES/FAC results with Python

Read Nastran results with C++ Read Nastran XDB results with C++ Read Nastran OP2 results with C++ Read Nastran HDF5 results with C++ Read Nastran H5 results with C++ Read Samcef results with C++ Read DES/FAC results with C++

Read Nastran results with C# Read Nastran XDB results with C# Read Nastran OP2 results with C# Read Nastran HDF5 results with C# Read Nastran H5 results with C# Read Samcef results with C# Read DES/FAC results with C#

Read Nastran results with C Read Nastran XDB results with C Read Nastran OP2 results with C Read Nastran HDF5 results with C Read Nastran H5 results with C Read Samcef results with C Read DES/FAC results with C

Read Nastran results extraction with Python Read Nastran XDB results extraction with Python Read Nastran OP2 results extraction with Python Read Nastran HDF5 results extraction with Python Read Nastran H5 results extraction with Python Read Samcef results extraction with Python Read DES/FAC results extraction with Python

Read Nastran results extraction with C++ Read Nastran XDB results extraction with C++ Read Nastran OP2 results extraction with C++ Read Nastran HDF5 results extraction with C++ Read Nastran H5 results extraction with C++ Read Samcef results extraction with C++ Read DES/FAC results extraction with C++

Read Nastran results extraction with C# Read Nastran XDB results extraction with C# Read Nastran OP2 results extraction with C# Read Nastran HDF5 results extraction with C# Read Nastran H5 results extraction with C# Read Samcef results extraction with C# Read DES/FAC results extraction with C#

Nastran results random access (XDB file), Nastran results import into DataBase, Nastran results read, Nastran XDB results, Nastran XDB attachment, Nastran OP2 results, Nastran HDF result, Nastran HDF5 results, Nastran h5 file extension, NX Nastran, MSC Nastran, Nastran BDF reader Nastran Bulk Data File reader Nastran Card Reader Nastran BDF writer Nastran Bulk Data File writer Nastran Card writer Nastran BDF card formatter

Patran results random access (XDB file), Patran results import into DataBase, Patran results read, Patran XDB results, Patran XDB attachment, Patran OP2 results, Patran HDF result, Patran HDF5 results, Patran h5 file extension,

Samcef results random access (DES/FAC files), Samcef results import, Samcef results read, Samcef DES/FAC results, Samcef DES/FAC attachment, Samcef U18,

a C++ Parser for NASTRAN BDF cards Nastran XDB reader Nastran OP2 reader Nastran HDF5 reader Samcef des/fac reader Batch post-processing of Nastran results Batch post-processing of Samcef results Export Nastran results to excel Export Nastran results to CSV file Export Nastran results to text file Export Nastran results to ascii file

Description of Nastran XDB binary file format Description of Nastran OP2 binary file format Description of Nastran Punch file format Description of Nastran HDF5 binary file format Description of Nastran H5 binary file format Description of Samcef Des and Fac binary file formats

Idaero Nas2cell nas2cell Mscsoftware Samtech Altair Hyperworks NX Nastran Siemens Hdfview Autodesk inventor Nastran Pynastran Pypi Steven doyle Nastran in-cad IDEAS, Hypermesh, FEMAP, Hyperworks, ESAComp, Digimat, CleanSky, Wings, PIT, Elon Musk, GSTP, FLTP, Ariane, launcher, Space X, Orion, MPCV, Saturn, Lockheed Martin, Vega, Soyuz, Soyouz, ISS, land rover, Altair, Siemens, NX, Ansys, Abaqus, FEMAP, Dassault, Mitsubishi, Bombardier, F35, Boeing, Embraer, NASA, ESA, Actran, Random, Acoustic, SINE, Modal analysis, Optimization, Static, ADS, Airbus Defense and Space, TAS-I, TAS-B, TAS-F, SOL 101, SOL 103, SOL 105, SOL 106, SOL 108, SOL 111, SOL 111, SOL 200, automated post-processing, excel, VBA, Ruby, Python, .NET, Visual C++, VB.NET, C#, GMSH, satellite, airplane, car, boat, structure, train, stability,

Satellite, Structure, Structural Analysis, Finite Elements, Aircraft, Airplane, Loads, Load case, SOL101, SOL103, SOL106, SOL600, SOL108, SOL111, Optimization, Stability, Strength, Stress, Strain, Beam, Shell, Composite, Laminate, Sandwich, Honeycomb, CFRP, GFRP, Astrium, Thales, Alcatel, Boeing, Alenia, Embraer, Dassault, Bombardier, Sonaca, Sabca, Samtech, MSC, Siemens, EADS, Spirit, Lockheed, Grumman, Martin, Latécoère, Rocket, Tsai-Hill, Tsai-Wu, Yamada-Sun, Von Mises, CATIA, Pro-Engineer, Sonia, Image, Isami, Python, Ruby, Java, Perl, VBA, C++, C#, ELFINI, mesh, properties, coordinate system, node, GRID, Bird impact, fatigue, dynamic response, shock, sinus, shaker, Marc, Abaqus, ansys, NX Nastran, MSC Nastran, Ariane, ISS, Hypermesh, hyperview, Ansys, Femap, Siemens PLM Software, NX Nastran, Nei Nastran, Algor, Von Mises, Cauchy, Tensor, Vector, real, complex, magnitude, phase, cylindrical, spherical, Cartesian, eigen-vector, principal values, eigen-value, frequency, virtual, simulation, McNeal Schwendler, Software, PLM, virtual, computation, simulation, calculation Lockeed, Martin, Pilatus, 310, 320, 330, 340, 350, 380, F7X, Falcon, Bruhn, Roark, 737, 747, 787 Learjet, knownledge based engineering, KBE, kbo, excel, spreadsheet, workbook, Microsoft word, Soyuz, corrosion, ETS, automatic, crash, pilot, test, AIT, quasi-static, gravity, thermo-elastic, thermal, temperature, failure, ply, Young modulus, shear modulus, Poisson ratio, 135, 145, 170, 190, electro-magnetic, power, engine, fuel, kerozen, battery, windgust, return flight loads, open office, calc, Latecoere, mig, yak, proton, jettison, separation, burst, landgear, flap, slat, wing, fuselage, module, service, support, cockpit, tail, tailplane, door, window, stringer, doubler, skin, core, rivet, bolt, fastener, washer, bearing, allowable, kbekbo, solidworks, fempad, dynamic load response, noise, acoustic, thermel, thermo-elastic, Hashin, Puck, hoffman, ILSS, maximum strain, maximum stress, inter-laminar shear stress, delamination, Software, program, solver, implicit, explicit, transient, result, results tresca principal stress, Puck, Hashin Yamada-Sun, Hoffman, ILSS,Tsai-Hill

FeResPost allows to export/import results and groups into/from BLOB objects (Binary Large OBjects) for insertion in in an SQL database. Several of the examples presented use the SQLite database, but the capability should also work with other SQL database systems as MySQL, PostgresSQL,...

BDF reader/editor/writer OP2 reader OP4 reader Windows, Linux, and Mac frequency response imaginary real magnitude phase complex F06 reader PUNCH reader Results include: displacement, velocity, acceleration, temperature, eigenvectors, eigenvalues, SPC forces, MPC forces, grid point forces, load vectors, applied loads, strain energy, as well as stress and strain. Printing nodes using built-in methods class-based methods function-based methods GUI Graphical User Interface mass matrix stiffness matrix demo programs and scripts get element properties isotropic orthotropic bilinear corner centroid import packages numpy dataframe Nastran Specific Features Setup Additional Formats Analysis setup deflection wing bending matlab comparison with PyNastran Optimization Results connectivity galerkin minimization shell solid damper damping amplification factor sine response shaker loads thermal CTE attributes free edge pressure distribution split spring CELAS plates beams sandwich gradient flux extract results from nastran xdb file with c# extract results from nastran xdb file with c++ extract results from nastran xdb file with c extract results from nastran xdb file with python extract results from nastran xdb file with vba extract results from nastran xdb file with excel extract results from nastran xdb file with ruby extract results from nastran hdf file with c# extract results from nastran hdf file with c++ extract results from nastran hdf file with c extract results from nastran hdf file with python extract results from nastran hdf file with vba extract results from nastran hdf file with excel extract results from nastran hdf file with ruby extract results from nastran op2 file with c# extract results from nastran op2 file with c++ extract results from nastran op2 file with c extract results from nastran op2 file with python extract results from nastran op2 file with vba extract results from nastran op2 file with excel extract results from nastran op2 file with ruby

FeResPost Web Site                     FeResPost Online User Manual

FeResPost User Manual

Version 5.0.9

2024/08/24

Renaud Sizaire



THIS PAGE IS INTENTIONALLY LEFT BLANK

Introduction

In this document, one presents the manual of FeResPost.

FeResPost

When sizing a structure with FE software, the engineer is often lead to use or develop tools that automate the computation of margins of safety, reserve factors or other results from outputs obtained with a FE solver. Then the engineer is facing several problems:

All these problems induce difficulties in the management of the automated post-processing. These must be as simple and cleanly written as possible to allow an easy understanding by everyone. Also their architecture must be flexible to make the modifications easy to implement and reduce the risk of errors.

The problems mentioned above are very similar to the kind of problems a programmer is facing when writing a large program. To help the programmer in this task, the object-orientation has emerged as a new programming language concept. Object-oriented languages allow the development of more flexible programs with a better architecture and allow the re-usability of code. Many object-oriented languages are now available. They can be compiled languages (C++, Fortran 90,...) or interpreted ones (Ruby, Python, Visual Basic,...).

FeResPost is a compiled library devoted to the programming of automated post-processing of finite element results. It provides the definition of several classes and one module. It uses object orientation at two levels:

1.

With object-oriented languages, it allows to write interpreted and object-oriented automated post-processing. An example of such an object-oriented post-processing program is given in Chapter IV.4.

2.

The FeResPost library is mainly written in C++, which is also an object-oriented language. Then a Ruby wrapping is provided around the C++ code.

During the development of FeResPost, the developer has been trying to maintain as much as possible the simplicity and clarity of the language in which post-processing programs are written.

FeResPost can be accessed from different languages and on different platforms:

How to learn FeResPost?

One gives here some advice to people starting to use FeResPost. The order in which the knowledge is acquired matters. One of the worst way to try to learn FeResPost is to read the manual while writing bits of code meant to solve the particular problem the user has in mind. Instead, one suggests the following sequence of knowledge acquisition:

1.

FeResPost is an extension of ruby programming language. This means that the examples provided in the document are small ruby programs. Therefore a basic knowledge of ruby is necessary. People trying to learn ruby and FeResPost at the same time will probably fail in both tasks.

Very good books on ruby language are available in libraries. Internet resources are also a source of information (newsgroups, tutorials with examples...).

Note that people already familiar with one or several object-oriented programming languages will have no difficulty to acquire a basic knowledge of ruby.

2.

Then, the user may test FeResPost by running the small examples. These are provided in the sub-directories in “RUBY” directory. Note that the Nastran bdf files should first be run in order to have the op2 result files available. It may be a good idea to try first to understand the structure of the bdf files and of the organization of the finite element model.

The small examples are meant to be increasingly difficult. So, the user should first run the examples in “EX01” directory, then in “EX02”... For each example, every statement should be understood, and the corresponding pages of the user manual should be carefully read.

3.

When all the small examples have been run and understood, the user will probably have acquired a reasonable understanding of the various capabilities of FeResPost. Then it may be a good idea to start to read the user manual. For example, to read a few pages each day in such a way that the information can be digested efficiently.

4.

The two examples “PROJECTa” and “PROJECTb” illustrate the programming of more complex post-processing of Results involving loops on load-cases, on several types of post-processing calculations... These two projects should be studied at the very end.

“PROJECTa” is meant to be studied before “PROJECTb”. Indeed, “PROJECTa” is easier to understand than “PROJECTb”, because it is less object-oriented. but it is also less complete and less nice from a programming point of view.

The reason why the advices above is given is that many users send mails of questions or complaints because they fail to understand something about FeResPost which is clearly illustrated in the examples. Sometimes, the problems faced by the users are simply related to a lack of understanding of the ruby programming language.

Structure of the document

This document is organized as follows:

A list of the different classes defined in FeResPost with pointers to Tables listing the methods defined by these classes is given in Table 1.


Table 1: Classes defined by FeResPost, and links to the corresponding lists of methods.

Future developments

FeResPost is still at the very beginning of its development and much work is still necessary to cover a wider range of applications. One gives below a few examples of possible improvements, more or less sorted by order of emergency or facility:

1.

Correction of bugs...

2.

Addition of specialized post-processing modules programmed at C++ level to provide efficiency. For examples:

  • A module devoted to fatigue and damage tolerance analysis.

  • A module devoted to the calculation of stresses in bar cross-sections from the bar forces and moments.

  • ...

3.

Extension of FeResPost by providing interfaces towards other FE software like Abaqus,...

4.

...

Of course, we are open to constructive remarks and comments about the ruby library in order to improve it.

Contents

I  FeResPost Reference Manual
I.0 Introduction
I.1 Generic “DataBase” class
I.1.1 Methods for FEM definition
I.1.2 “Group” methods
I.1.2.1 Simple manipulation of Groups
I.1.2.2 Construction of Groups by association operations
I.1.3 “Result” methods
I.1.3.1 Manipulation of Results
I.1.3.2 Enabling composite Results reading operations
I.1.4 Manipulation of abbreviations
I.1.5 Composite methods
I.1.6 Iterators
I.1.7 General purpose methods
I.1.8 “Gmsh” methods
I.2 The “CoordSys” class
I.2.1 The CoordSys object
I.2.2 Construction or manipulation functions
I.2.2.1 “initWith3Points” method
I.2.2.2 Three “initWithOViVj” methods
I.2.2.3 “updateDefWrt0” method
I.2.3 Transformation of point coordinates
I.2.3.1 “changeCoordsA20” method
I.2.3.2 “changeCoords02B” method
I.2.3.3 “changeCoordsA2B” method
I.2.4 Transformation of vector and tensor components
I.2.4.1 “changeCompsA20” method
I.2.4.2 “changeComps02B” method
I.2.4.3 “changeCompsA2B” method
I.2.5 Other methods
I.2.5.1 “initialize” method
I.2.5.2 “clone” method
I.2.5.3 “to_s” method
I.2.5.4 “Id” attribute
I.3 The “Group” class
I.3.1 The concept of “Group”
I.3.2 Creation of a Group object
I.3.3 Manipulation of entities stored in a Group
I.3.4 Group operators
I.3.5 “BLOBs”
I.3.6 Iterators of Group class
I.3.7 Other methods
I.4 The “Result” class
I.4.1 The concept of “Result”
I.4.1.1 “Keys”
I.4.1.2 “Values”
I.4.1.3 Identification of Result objects
I.4.1.4 Other characteristics
I.4.1.5 “FieldCS” Result
I.4.2 FeResPost Results’ characteristics
I.4.3 Extraction methods
I.4.3.1 “extractResultOnEntities” method
I.4.3.2 “extractResultOnLayers” method
I.4.3.3 “extractResultOnSubLayers” method
I.4.3.4 “extractResultOnRkl” method
I.4.3.5 “extractResultOnResultKeys” method
I.4.3.6 “extractResultOnRange” method
I.4.3.7 “extractResultForNbrVals” method
I.4.3.8 “extractResultMin” method
I.4.3.9 “extractResultMax” method
I.4.3.10 “extractRklOnRange” method
I.4.3.11 “extractRklForNbrVals” method
I.4.3.12 “extractRklMin” method
I.4.3.13 “extractRklMax” method
I.4.3.14 “extractRkl” method
I.4.3.15 “extractGroupOnRange” method
I.4.3.16 “extractGroupForNbrVals” method
I.4.3.17 “extractGroup” method
I.4.3.18 “extractLayers” method
I.4.3.19 “extractSubLayers” method
I.4.4 Derivation monadic methods
I.4.4.1 “deriveScalToScal” method
I.4.4.2 “deriveScalPerComponent” method
I.4.4.3 “deriveVectorToOneScal” method
I.4.4.4 “deriveVectorToVector” method
I.4.4.5 “deriveVectorToTensor” method
I.4.4.6 “deriveTensorToOneScal” method
I.4.4.7 “deriveTensorToTwoScals” method
I.4.4.8 “deriveTensorToThreeScals” method
I.4.4.9 “eigenQR” method
I.4.4.10 “deriveByRemapping” method
I.4.5 Dyadic derivation method
I.4.6 Methods modifying the object
I.4.6.1 Access to and modification of Result data
I.4.6.2 “setRefCoordSys”
I.4.6.3 “renumberLayers”
I.4.6.4 “renumberSubLayers”
I.4.6.5 “removeLayers”
I.4.6.6 “removeSubLayers”
I.4.6.7 “modifyRefCoordSys”
I.4.6.8 “modifyPositionRefCoordSys” method
I.4.6.9 Linear combination of Results
I.4.7 Operators
I.4.7.1 Addition operator
I.4.7.2 Substraction operator
I.4.7.3 Multiplication operator
I.4.7.4 Division operator
I.4.7.5 Exponent operator
I.4.8 “calcResultingFM” method
I.4.9 Complex Results
I.4.9.1 Rectangular-Polar conversions
I.4.9.2 Conjugate Complex Result
I.4.9.3 Rotation of Complex Result
I.4.9.4 Extractions from Complex Results
I.4.9.5 Assembling Complex from Real Results
I.4.10 “getData”
I.4.11 “BLOBs”
I.4.12 Iterators
I.4.13 A few singleton (static) methods
I.4.14 Other methods
I.4.14.1 “new”
I.4.14.2 “initialize”
I.4.14.3 “clone”
I.4.14.4 “cloneNoValues”
I.4.14.5 “initZeroResult”
I.4.14.6 “Size” attribute
I.4.14.7 “to_s”
I.5 The “ResKeyList” class
I.5.1 Creating and filling ResKeyList object
I.5.2 Extraction functions
I.5.3 Methods modifying the object
I.5.3.1 “renumberLayers” method
I.5.3.2 “renumberSubLayers”
I.5.3.3 “removeLayers”
I.5.3.4 “removeSubLayers”
I.5.4 Dyadic operators
I.5.5 Iterators
I.5.6 “getData” method
I.5.7 Other methods
I.6 The “Post” module, and other topics...
I.6.1 Manipulation of FeResPost standard output
I.6.2 Monadic functions for new Result creation
I.6.3 Dyadic functions for new Result creation
I.6.4 “Operator” methods
I.6.5 Reading and writing of Groups
I.6.6 Setting verbosity for debugging purposes
I.6.7 Conversion of CLA idfiers
I.6.8 SQL“BLOB” methods
I.6.9 Random or PSD integration methods
I.6.10 Predefined criteria
I.6.11 Loading HDF5 library
I.6.12 Exceptions
I.7 Arguments coercion for “Result” class operators
II  Composite Reference Manual
II.0 Introduction
II.0.1 Remarks and limitations
II.1 Theoretical background
II.1.1 Conventions
II.1.2 Rotation in XY plane and algebraic notations
II.1.2.0.1 Rotation of base vectors
II.1.2.0.2 Transformation of vector and tensor components
II.1.2.0.3 Matricial notations
II.1.2.0.4 Introduction of a short notation
II.1.3 Materials and plies
II.1.3.1 Plies
II.1.3.2 Materials and constitutive equations
II.1.3.3 In-plane properties
II.1.3.4 Out-of-plane shear properties
II.1.4 Thickness and mass of laminate
II.1.5 In-plane and flexural laminate behavior
II.1.6 Out-of-plane shear of laminate
II.1.6.1 Out-of-plane shear equilibrium equations
II.1.6.2 Triangular distribution of in-plane stresses
II.1.6.3 Out-of-plane shear stress partial derivative equations
II.1.6.4 Integration of out-of-plane shear stress equation
II.1.6.5 Approximations with out-of-plane shear forces
II.1.6.5.1 The “(μx,μy)” approach
II.1.6.5.2 “Uncoupled X-Y” approach
II.1.6.5.3 “Resolution in shear force axes” approach
II.1.6.5.4 Comparison of the three approaches
II.1.6.6 Out-of-plane laminate shear stiffness
II.1.6.6.1 Limitations of shear stiffness calculation
II.1.6.6.2 Introduction of new notations
II.1.6.6.3 Energetic approach
II.1.6.7 Calculation algorithm for shear stiffness
II.1.6.8 Ply out-of-plane shear stresses
II.1.6.8.1 With (μx,μy) approach
II.1.6.8.2 With “resolution in shear force axes” approach
II.1.7 CTE and CME calculations
II.1.7.1 In-plane and flexural thermo-elastic behavior
II.1.7.2 Out-of-plane shear thermo-elastic behavior
II.1.7.3 Hygrometric behavior of laminates
II.1.7.4 Full sets of equations
II.1.8 Calculation of load response
II.1.8.1 In-plane and flexural response
II.1.8.2 Out-of-plane shear response
II.1.8.3 Out-of-plane T/C deformation
II.1.9 Accelerating the calculation of load response
II.1.9.1 Calculation of laminate loads and strains
II.1.9.2 Calculation of plies stresses and strains
II.1.9.2.1 Loading in ply axes
II.1.10 Failure theories
II.1.10.1 Tresca criterion (2D)
II.1.10.2 Von Mises criterion (2D)
II.1.10.3 Von Mises criterion (3D)
II.1.10.4 Maximum stress criterion
II.1.10.5 Maximum stress criterion (3D)
II.1.10.6 Maximum strain criteria (2D)
II.1.10.7 Maximum strain criterion (3D)
II.1.10.8 Combined strain criterion (2D)
II.1.10.9 Tsai-Hill criterion
II.1.10.10 Tsai-Hill criterion (version b)
II.1.10.11 Tsai-Hill criterion (version c)
II.1.10.12 Tsai-Hill criterion (3D)
II.1.10.13 Tsai-Hill criterion (3D version b)
II.1.10.14 Tsai-Wu criterion
II.1.10.15 Tsai-Wu criterion (3D)
II.1.10.16 Hoffman criterion
II.1.10.17 Puck criterion
II.1.10.18 Puck “b” criterion
II.1.10.19 Puck “c” criterion
II.1.10.20 Hashin criteria
II.1.10.21 Hashin criteria (3D)
II.1.10.22 Yamada-Sun criterion
II.1.10.23 Yamada-Sun criterion (version b)
II.1.10.24 3D honeycomb criterion
II.1.10.25 Honeycomb shear criterion
II.1.10.26 Honeycomb simplified shear criterion
II.1.10.27 Inter-laminar shear criterion
II.1.11 Temperature diffusion in laminates
II.1.11.1 Material thermal parameters
II.1.11.2 In-plane and out-of-plane components
II.1.11.3 In-plane rotations of vectorial and tensorial properties
II.1.11.4 Integration along the laminate thickness
II.1.11.4.1 In-plane conductivity
II.1.11.4.2 Out-of-plane conductivity
II.1.11.4.3 Thermal capacity
II.1.12 Moisture diffusion in laminates
II.1.13 Units
II.2 The “ClaDb” class
II.2.1 Creation of an object
II.2.2 Identifying a ClaDb
II.2.3 Manipulating entities stored in a ClaDb
II.2.4 Management of Units
II.2.5 Saving to or retrieving from a disk file
II.2.6 Saving or initializing with NDF lines
II.2.7 Iterators
II.2.8 Other methods
II.3 The “ClaMat” class
II.3.1 Creation of an object
II.3.2 Identifier and type
II.3.3 Manipulating Data
II.3.4 Calculated results
II.3.5 Management of Units
II.3.6 Saving or initializing with NDF lines
II.3.7 Other methods
II.4 The “ClaLam” class
II.4.1 Class Methods
II.4.2 Creation of an object
II.4.3 Identifying a laminate
II.4.4 Manipulation of plies
II.4.5 Other data
II.4.6 Laminate properties
II.4.7 Laminate load response for a simple loading
II.4.7.1 Calculation of the load response
II.4.7.2 Laminate internal loads and strains
II.4.7.3 Ply stresses and strains
II.4.7.4 Temperatures and moistures at ply level
II.4.7.5 Other ply results
II.4.8 Laminate finite element load response
II.4.8.1 Calculation of laminate loads, stresses and strains
II.4.8.1.1 Units
II.4.8.2 Acceleration
II.4.9 Calculation of criteria from FE stresses or strains
II.4.10 Management of Units
II.4.11 Saving or initializing with NDF lines
II.4.12 One iterator
II.4.13 Other methods
II.5 The “ClaLoad” class
II.5.1 Creation of an object
II.5.2 Identifying a ClaLoad
II.5.3 Thermo-elastic and hygro-elastic contributions
II.5.4 Setting and getting mechanical parts
II.5.5 Linear combinations of loads
II.5.6 Finite element Results
II.5.7 Management of Units
II.5.8 Saving or initializing with NDF lines
II.5.9 Other methods
III  Solver Preferences
III.0 Introduction
III.1 Nastran Preferences
III.1.1 “NastranDb” class
III.1.1.1 Reading a BDF
III.1.1.2 “OP2” methods for reading a FEM
III.1.1.3 Superelements
III.1.1.4 Writing Bulk lines
III.1.1.5 Accessing FEM information or modifying the FEM
III.1.1.6 “CoordSys” methods
III.1.1.6.1 “getCoordSysCopy”
III.1.1.6.2 “addCoordSys”
III.1.1.6.3 “makeAllCoordSysWrt0”
III.1.1.7 Construction of Groups by associations
III.1.1.8 “OP2” methods for reading Results
III.1.1.9 “XDB” methods for extracting XDB information
III.1.1.9.1 “getXdbLcNames” method
III.1.1.9.2 “getXdbScNames” method
III.1.1.9.3 “getXdbResNames” method
III.1.1.9.4 “getXdbLcScNames” method
III.1.1.9.5 “getXdbLcScResNames” method
III.1.1.9.6 “getXdbLcInfos” method
III.1.1.9.7 “printXdbDictionnary” method
III.1.1.9.8 “readXdb” method
III.1.1.9.9 “readXdb2H” method
III.1.1.9.10 A note on “endianness”
III.1.1.9.11 XDB tables activation
III.1.1.10 Attaching “XDB” files to a Nastran DataBase
III.1.1.10.1 Managing XDB file attachments
III.1.1.10.2 Extracting information of XDB file attachments
III.1.1.10.3 Extracting Results From XDB file attachments
III.1.1.10.4 Importing Results From XDB file attachments
III.1.1.10.5 Getting optimization data from XDB
III.1.1.10.6 Storage buffers for XDB result files random access
III.1.1.10.7 “Raw” access to XDB file content
III.1.1.11 Attaching “HDF” files to a Nastran DataBase
III.1.1.11.1 Reading Results fron an HDF file
III.1.1.11.2 Managing HDF file attachments
III.1.1.11.3 Extracting information from HDF file attachments
III.1.1.11.4 Extracting Results From HDF file attachments
III.1.1.11.5 Raw access to HDF Datasets
III.1.1.12 GMSH outputs
III.1.1.13 Iterators
III.1.1.14 Other methods
III.1.1.15 Attributes
III.1.2 Nastran Result characteristics
III.1.2.1 General Results
III.1.2.2 Composite Results
III.1.3 Interaction with CLA classes
III.2 Samcef Preferences
III.2.1 “SamcefDb” class
III.2.1.1 Reading Samcef models
III.2.1.2 “CoordSys” methods
III.2.1.2.1 “getCoordSysCopy”
III.2.1.2.2 “addCoordSys”
III.2.1.2.3 “makeAllCoordSysWrt0”
III.2.1.3 Construction of Groups by association operations
III.2.1.4 Methods related to Results importation
III.2.1.4.1 “readDesFac” method
III.2.1.4.2 “readDesFac2H” method
III.2.1.4.3 Flags for reading of Results
III.2.1.5 Attaching “DES/FAC” files to a Samcef DataBase
III.2.1.5.1 Managing DES/FAC file attachments
III.2.1.5.2 Extracting information from DES/FAC attachments
III.2.1.5.3 Extracting Results from attachments
III.2.1.5.4 Storage buffers for result files random access
III.2.1.6 GMSH outputs
III.2.1.7 Production of additional Results
III.2.1.8 Iterators
III.2.1.9 Other methods
III.2.1.10 Attributes
III.2.2 Samcef Results characteristics
III.2.2.1 General Results
III.2.2.2 Composite Results
III.2.3 Methods defined in “Post” module
IV  FeResPost Examples with RUBY Extension
IV.0 Introduction
IV.0.1 Accessing the ruby extension
IV.1 A small satellite
IV.1.1 Presentation of the structure and its modeling
IV.1.2 Satellite FEM materials and properties
IV.1.3 Conventions for numbering and groups
IV.1.4 Loads and Boundary conditions
IV.1.4.1 Loads
IV.1.4.2 Boundary conditions
IV.1.5 Main data files
IV.1.5.1 Acceleration unit loads on entire structure
IV.1.5.2 Acceleration unit loads on parts of the structure
IV.1.5.3 Thermo-elastic load cases
IV.1.5.4 Other solution sequences
IV.1.6 Organization of FEM in files and directories
IV.2 A few small examples
IV.2.1 Utilities Module
IV.2.2 Examples without Results
IV.2.2.1 Reading Bulk Data
IV.2.2.2 Group examples
IV.2.2.2.1 Printing the list of a DataBase’s Groups
IV.2.2.2.2 Content of DataBase’s Groups
IV.2.2.2.3 Printing a Patran session file
IV.2.2.3 Manipulating Group entities
IV.2.2.4 Adding Groups to a DataBase
IV.2.3 Examples with iterators
IV.2.4 Examples with Results
IV.2.4.1 Inspecting Results contained in a DataBase
IV.2.4.2 Calculations with Results
IV.2.4.3 Using predefined criteria
IV.2.4.4 Printing Results’ content
IV.2.4.5 Coordinate system transformations
IV.2.4.6 Manipulation of Complex Results
IV.2.4.6.1 Extracting xdb lists of load cases and Results
IV.2.4.6.2 Extracting xdb Results information
IV.2.4.6.3 Manipulation of Complex Results
IV.2.4.6.4 Working with XDB attachments
IV.2.4.7 Manipulation of XDB attachments
IV.2.4.7.1 Extracting information from XDB attached file
IV.2.4.7.2 Extracting Results from XDB attached file
IV.2.4.7.3 Extracting linear combination of Results from XDB
IV.2.4.7.4 Random analysis or integration of PSD functions
IV.2.5 A few useful tools
IV.2.5.1 Definition of acceleration fields
IV.2.5.2 Definition of temperature fields
IV.2.5.3 Calculation of a total force and moment
IV.2.5.4 Outputting a Gmsh file
IV.2.6 Saving and retrieving Results from an SQL database
IV.2.6.1 Saving objects in an SQLite database
IV.2.6.2 Retrieving objects from an SQLite database
IV.2.7 Reading optimization results
IV.2.8 “Raw” access to XDB file content
IV.2.8.1 Utilities
IV.2.8.2 Printing Coordinate System Table Matrix
IV.2.8.3 Accessing results
IV.2.8.4 Producing a “clean” model from topometric optimization
IV.2.8.5 Reading and saving the temperature distributions
IV.2.9 Reading Results From Nastran HDF file
IV.2.10 Raw reading of Nastran HDF file’s content
IV.2.11 Superelements
IV.2.11.1 Reading BDF file and accessing superelements
IV.2.11.2 Superelements and OP2 files
IV.2.11.3 Getting superelement Results from XDB files
IV.2.11.4 Getting superelement Results from HDF files
IV.2.12 Other tests
IV.2.12.1 Reading RBE Results with Lagrange option
IV.2.12.2 Reading nonlinear analysis Results from HDF5 files
IV.2.12.3 Testing MPC Results
IV.2.13 CBEAM and CBAR intermediate stations
IV.3 Using the composite classes
IV.3.1 Importing and exporting data
IV.3.2 Manipulating composite entities
IV.3.3 Composite thermal properties
IV.3.4 Extending composite classes
IV.3.4.1 Extension “extendedCLA.rb”
IV.3.4.1.1 Modification of “ClaLam” class
IV.3.4.1.2 Modification of “ClaMat” class
IV.3.4.2 A very simple example of use
IV.3.4.3 Properties of the laminates defined in an ESAComp file
IV.3.4.4 Properties of the laminates defined in an ESAComp file
IV.3.4.5 Properties of the materials defined in an ESAComp file
IV.3.5 Out-of-plane laminate shear response
IV.3.6 Producing composite finite element Results
IV.3.7 Modifying units
IV.4 Object-oriented post-processing
IV.4.1 Post-processing classes and modules
IV.4.1.1 Management of databases and load cases
IV.4.1.2 “Post-processing” classes
IV.4.1.2.1 “PostCauchyStress” class
IV.4.1.2.2 “PostLaminate” class
IV.4.1.2.3 “PostConnect” class
IV.4.1.2.4 “postExtract.rb” class
IV.4.1.3 Other modules and classes
IV.4.1.3.1 “Util” module
IV.4.1.3.2 “SqlWrap” class
IV.4.2 Definition of data
IV.4.3 Sorting tools
IV.4.4 Recovery of results in excel and reporting word
IV.4.5 A few tricks...
IV.4.5.1 Exceptions
IV.4.5.2 Filtering the reading of Results
IV.4.6 Conclusions
V  FeResPost Python bindings
V.0 Introduction
V.0.1 Accessing the Python extension
V.0.2 Python versus ruby
V.0.2.1 Creating class instances
V.0.2.2 Associative containers and Arrays
V.0.2.3 Iterators
V.0.2.4 “nil” arguments
V.0.2.5 Exceptions
V.1 Python examples
V.1.1 Iterators
V.1.2 Accessing HDF and XDB results
V.1.3 SQLite examples
V.1.4 Object-oriented post-processing
V.1.5 Superelements
VI  FeResPost as COM component
VI.0 Introduction
VI.0.1 Accessing the COM component
VI.0.1.1 Accessing the COM component in ruby
VI.0.1.2 Accessing the COM component in python
VI.0.1.3 Accessing the COM component in VBscript
VI.0.1.4 Accessing the COM component in VBA
VI.0.1.5 Accessing the COM component in compiled languages
VI.0.2 COM component versus ruby extension
VI.0.2.1 Creating class instances
VI.0.2.2 Associative containers and Arrays
VI.0.2.3 Iterators
VI.0.2.4 Operators
VI.0.2.5 Singleton methods
VI.0.2.6 “Clone” methods
VI.0.2.7 “Post” Module
VI.0.2.8 Complex arguments
VI.0.2.9 “nil” arguments
VI.0.2.10 Exceptions
VI.0.2.11 Selection of standard output for information messages
VI.1 CLA classes
VI.1.1 “ClaDb” class
VI.1.2 “ClaMat” class
VI.1.3 “ClaLam” class
VI.1.4 “ClaLoad” class
VI.2 Generic FeResPost classes
VI.2.1 FeResPost Application class
VI.2.1.1 Management of the Application
VI.2.1.2 Creation of other objects
VI.2.1.3 Methods corresponding to “Post” module in ruby extension
VI.2.1.4 Changing working directory
VI.2.2 Generic DataBase class
VI.2.3 Group class
VI.2.4 CoordSys class
VI.2.5 Result class
VI.2.6 ResKeyList class
VI.3 Supported Solvers
VI.3.1 The “NastranDb” class
VI.3.2 The “SamcefDb” class
VII  FeResPost Examples with COM Component
VII.0 Introduction
VII.1 COM examples with various languages
VII.1.1 Using COM component with several languages
VII.1.1.1 Using component with python
VII.1.1.2 Using component with ruby
VII.1.1.3 Using component with VBscript
VII.1.1.4 Using component with C++
VII.1.1.5 Using component with C
VII.1.2 Testing the “NastranDb” and “Group” classes
VII.1.2.1 Using iterators and “NastranDb” class
VII.1.2.2 Writing elements connectivity
VII.1.2.3 Manipulation of Groups
VII.1.3 Translating a few small “RUBY” Result examples
VII.1.3.1 Printing DataBase lists of Results
VII.1.3.2 Printing maximum stress
VII.1.3.3 Generating Nastran GRAV cards
VII.1.3.4 Printing beam forces
VII.1.3.5 Printing strain tensor
VII.1.3.6 Modification of reference coordinate systems
VII.1.3.7 Calculation of global force and moment
VII.1.3.8 Writing GMSH mesh and Results
VII.1.3.9 Manipulation of XDB Result files
VII.1.3.9.1 Extraction of information from XDB Result file
VII.1.3.9.2 Manipulation of complex Results
VII.1.4 Using component for CLA analyses
VII.1.4.1 Laminate shear properties and load response
VII.1.4.2 Laminate load response with FE Results
VII.1.4.3 Laminate failure criteria with FE stresses and strains
VII.1.5 Superelements
VII.1.6 Object-oriented post-processing
VII.1.7 XDB attachment Results access with RUBY and COM
VII.1.8 Using COM component with excel
VII.1.9 An Excel workbook illustrating the use of SQL databases
VII.2 CLA analyses in excel
VII.2.1 Preparing the application
VII.2.2 Workbook events
VII.2.3 Spreadsheets
VII.2.3.1 Spreadsheet “HiddenData”
VII.2.3.2 Spreadsheet “NeutralLines”
VII.2.3.3 Spreadsheet “ClaDbIds”
VII.2.3.4 Spreadsheet “DbUnitsEdit”
VII.2.3.5 Spreadsheet “MatEdit”
VII.2.3.6 Spreadsheet “LamEdit”
VII.2.3.7 Spreadsheet “LoadEdit”
VII.2.3.8 Spreadsheet “MatProperties”
VII.2.3.9 Spreadsheet “LamProperties”
VII.2.3.10 Spreadsheet “LamText”
VII.2.3.11 Spreadsheet “LamLoadResponse_A”
VII.2.3.12 Spreadsheet “LamLoadResponse_B”
VII.2.3.13 Spreadsheet “LamMinMaxCalcArray”
VII.2.3.14 Spreadsheet “LamMinRfCalcScal”
VII.2.4 VBA modules
VII.2.4.1 “calcMatProperties” module
VII.2.4.2 “calcLamProperties” module
VII.2.4.3 “calcLamLoadResponse” module
VII.3 Extraction and manipulation of Results with excel
VII.3.1 Preparing the application
VII.3.2 Accessing the FEM and Results
VII.3.3 Accessing the FEM and Results
VII.3.4 Simple extraction of Results
VII.3.5 Extraction of linear combinations Results
VII.3.6 Calculation of criteria
VII.3.7 Extraction of dynamic response Results
VII.3.8 Current limitations
VII.4 An Excel workbook devoted to post-processing
VII.4.1 Preparing the application
VII.4.1.1 “Optimizing” excel
VII.4.1.2 Referencing FeResPost in VBA
VII.4.1.3 Installing “SQLite for Excel”
VII.4.2 Worksheets
VII.4.2.1 “LcSelector” worksheet
VII.4.2.2 Worksheet for Definition of databases and load cases
VII.4.2.3 Worksheet for Selection of load cases and associated parameters
VII.4.2.4 Post-processing worksheets
VII.4.2.5 “envelopeGMSH” worksheet
VII.4.3 VBA modules
VII.4.3.1 “DbAndLoadCases” VBA module
VII.4.3.2 “ExtractionCriteria” VBA module
VII.4.3.3 “ResultsExtraction” VBA module
VII.4.3.4 “ResultsArchiver” VBA module
VII.4.3.5 “ResultsGmsh” VBA module
VII.4.3.6 “Sqlite3” VBA module
VII.4.3.7 “UTIL” VBA module
VII.4.4 “ExtractionCriteria” VBA module
VII.4.4.1 Post-processing of stress Results
VII.4.4.1.1 “getVonMisesMax” function
VII.4.4.1.2 “getShellVonMisesMax” function
VII.4.4.1.3 “getHoneycombCoreAirbusRF” function
VII.4.4.1.4 “getHoneycombCoreMaxShearRF” function
VII.4.4.2 Post-processing of connection loads
VII.4.4.2.1 Calculation of the different components of connection loads
VII.4.4.2.2 “getSlidingRF” function
VII.4.4.2.3 “getGappingRF” function
VII.4.4.2.4 “getInsertRF” function
VII.4.4.2.5 “getShearBearingRF” function
VII.4.4.2.6 “getPullThroughRF” function
VII.4.4.3 composite post-processing
VIII  FeResPost as .NET assembly
VIII.0 Introduction
VIII.0.1 Accessing the .NET assembly
VIII.0.2 Accessing FeResPost namespace
VIII.0.3 Creating class instances
VIII.0.4 Basic types as arguments and returned values
VIII.0.5 Associative containers and Arrays
VIII.0.6 Iterators
VIII.0.7 Operators
VIII.0.8 Singleton methods
VIII.0.9 “Clone” and “ToString” methods
VIII.0.10 “Post” static class
VIII.0.11 Complex arguments
VIII.0.12 FeResPost exceptions
VIII.0.13 Output for information messages
VIII.1 CLA classes
VIII.1.1 “ClaDb” class
VIII.1.2 “ClaMat” class
VIII.1.3 “ClaLam” class
VIII.1.4 “ClaLoad” class
VIII.2 Generic FeResPost classes
VIII.2.1 “Post” static class
VIII.2.2 Generic DataBase class
VIII.2.3 Group class
VIII.2.4 CoordSys class
VIII.2.5 Result class
VIII.2.6 ResKeyList class
VIII.3 Supported Solvers
VIII.3.1 The “NastranDb” class
VIII.3.2 The “SamcefDb” class
IX  FeResPost Examples with .NET Assembly
IX.1 Examples of use for .NET assembly
IX.1.1 Reading a Nastran model
IX.1.1.1 Reading a Nastran model with C-sharp
IX.1.1.2 Reading a Nastran model with IronRuby
IX.1.2 “printStressMax” example
IX.1.3 Accessing FEM data
IX.1.4 Extending CLA classes
IX.1.5 Saving and retrieving Results from an SQL database
IX.1.6 Superelements
X  Appendices
X.A Installing FeResPost library
X.A.1 Binaries
X.A.1.1 Linux binaries (32 bits)
X.A.1.2 Linux binaries (64 bits)
X.A.1.3 Windows binaries (32 bits)
X.A.1.4 Windows binaries (64 bits)
X.A.1.5 Windows .NET assemblies
X.A.1.6 HDF shared libraries
X.A.2 Building from sources
X.A.3 Compilation options
X.A.4 Installation and configuration of binaries
X.A.4.1 Redistributable libraries
X.A.4.2 FeResPost C++ developer’s library and headers
X.A.4.3 Ruby extensions
X.A.4.4 Python extensions
X.A.4.5 COM component
X.A.4.5.1 Registration of COM component with “modifyRegistry.exe” program
X.A.4.5.2 Registration with “reg” files
X.A.4.6 .NET assembly
X.B Coordinate system transformations
X.B.1 Components of vectors and tensors
X.B.1.1 Vectors in a Cartesian coordinate system
X.B.1.2 Order 2 tensor in a Cartesian coordinate system
X.B.1.3 Cylindrical and spherical coordinate systems
X.B.2 Transformation of components
X.B.2.1 Transformation of vector components
X.B.2.2 Transformation of tensor components
X.B.3 Rotation of a coordinate system
X.B.4 Modification of coordinate systems
X.B.4.1 Local coordinate systems
X.B.4.2 Global coordinate systems
X.B.4.3 Projected coordinate systems
X.B.4.4 Local coordinate systems of CQUAD4 elements
X.B.4.5 Local coordinate systems of 3D elements
X.B.5 Coordinate systems and laminate properties
X.C Results characteristics
X.C.1 Real Results
X.C.2 Complex Results
X.D Predefined criteria
X.D.1 List of the predefined criteria
X.D.1.1 “HoneycombAirbusMoS” criterion
X.D.1.2 “HoneycombAirbusSR” criterion
X.D.1.3 “VonMisesMoS” criterion
X.D.1.4 “VonMisesSR” criterion
X.D.1.5 “SGI_SR” criterion
X.D.1.6 Interaction criteria
X.D.2 User predefined criteria
X.E A modular post-processing
X.E.1 Global structure of the program
X.E.1.1 The “LoadCases” module
X.E.2 Two post-processing modules
X.E.2.1 One using the connection loads
X.E.2.1.1 Member data
X.E.2.1.2 “calcOneInterface” method
X.E.2.1.3 Sliding criterion
X.E.2.1.4 Gapping criterion
X.E.2.1.5 Insert criterion
X.E.2.1.6 Definition of the list of interfaces
X.E.2.1.7 Definition of parameters
X.E.2.2 Critics on the previous post-processor
X.E.2.3 One using the Cauchy stress tensor
X.E.2.3.1 Member data
X.E.2.3.2 “calcOneGroup” method
X.E.2.3.3 Airbus criterion
X.E.2.3.4 MaxShear criterion
X.E.2.3.5 Von Mises criterion
X.E.2.3.6 “Post_honeycomb” specialization module
X.E.2.3.7 “Post_skins” specialization module
X.E.3 Main function
X.E.4 Conclusions
X.F An object-oriented post-processing
X.F.1 Difference in file organization
X.F.2 Transformation of modules into classes
X.F.2.1 Post-processing of Cauchy stress tensor
X.F.2.2 A composite post-processing
X.F.3 A new post-processing for dynamic Results
X.F.3.1 Simple extraction of components
X.F.3.2 Post-processing of composite dynamic Results
X.F.4 Main function
X.F.5 Definition of data
X.F.5.1 Data for load cases
X.F.5.2 Data of post-processing
X.F.5.2.1 Static post-processing
X.F.5.2.2 Dynamic post-processing
X.F.6 Acceleration with predefined criterion
X.F.7 Conclusions
X.G FeResPost ruby extension in excel
X.G.1 A VBA-ruby bridge
X.G.1.1 Programming the VBA-ruby bridge
X.G.1.2 Requirements
X.G.2 An example
X.G.2.1 Ruby programming
X.G.2.2 “RubyMarshal” VBA module
X.G.2.3 “RubyFunctions” VBA module
X.G.2.4 Other tips
X.G.2.5 Things to do to match a particular configuration
X.H Bolt group redistribution of connection loads
X.H.1 Assumptions
X.H.2 Group global stiffness
X.H.3 Distribution on a group of connections
X.H.4 Final remarks
X.I Copying FeResPost
X.I.1 Copyright
X.I.2 GNU GENERAL PUBLIC LICENSE
X.I.3 GNU LESSER GENERAL PUBLIC LICENSE
X.J Summary of changes
XI  References

Index

.NET515–527, 531–535

Abaqus6
abbreviations47–48, 314
Acceleration of computation118–119, 361–362, 575–585, 608
asef317
Autodesk266, 697

Bacon313, 314, 495
bacon314
banque313–314
BBBTsee Binary Blocked Balanced Tree, see Binary Blocked Balanced Tree
big endian275–277
Binary Blocked Balanced Tree270
BLOB65, 101, 115, 381–383, 436, 473, 492, 497–498, 500–501, 535
bolt group621
bolt group(617
bridge609–615

C467
C++62, 67, 70, 465–466
CLA449–450, 521–522
ClaDb125, 203–208, 449, 521
ClaLam125, 217–235, 450, 522
ClaLoad125, 237–243, 450, 522
ClaMat125, 209–215, 449–450, 521
Classical Laminate Analysis449–450, 521–522
code327–330
COM441–455, 459–512, 609
Combined strain criterion182
Complex, Complex98–100
Component Object Model441–455, 459–512
Composite48–49, 125–243
CoordSys35, 53–59, 263–264, 314–315, 366
COPYING623–637
CRMS296

DataBase35, 37–52, 92–94
DataBase, flags, readDesFac318
DataBase, flags, readDesFac318
DataBase, key43–44
des316–324
disable269, 276, 318
dynam317

ECMAScript268
EDS266, 268
enable269, 276, 318
endiannes275–277
EQEXINE286
EQEXING286
Equivalent Strain134, 166, 181, 182
ESAComp125, 207
excel413–415, 423, 425–426, 443, 472–473, 475–489, 491–512, 609–615
exception119, 433, 447

fac316–324
FEM265
FeResPost35
Fick199
FieldCS73, 75, 93, 366
finite elements35
Fourrier195

General Public License623–637
Gmsh50–52, 381, 492–495, 497–498, 500–501, 577
GNU543
GPL623–637
Group35, 37, 41–43, 61–66, 80, 109, 264–265, 315–316, 354–357

Hash Key271
Hashin criteria189–191
HD5119, 389–390, 395–396, 435–436
HDF119, 257–259, 288–293, 389–390, 395–396, 435–436, 542
HKsee Hash Key, see Hash Key
Hoffman criterion186
Honeycomb criterion193–194

I-DEAS266, 268
identifier125
IDispatch444, 466
Ilss criterion194–195
Ilss_b criterion194–195
include256
instance method436, 605
Inventor Nastran266, 697
iterator49–50, 65, 101–102, 107–108, 293–294, 325
iterators357–358

keysee DataBase, key, see Result, key

lambda436
layersee Result, layer
Lesser General Public License623–637
LGPL623–637
little endian275–277

Makefile542
Maximum strain criterion181–182
Maximum stress criterion180
mecano317
Mechanical Strain134, 166, 181, 182
Microsoft444, 466
Microsoft Office414, 425–426
MINGW543
Mohr83, 84
MSYS543

Nastran64, 198, 249–309, 335
NET515–527, 531–535
NX314

op2257–259, 265–269, 295–309, 392–393

Patran35, 41, 42, 61, 63, 97, 307, 344
Post35, 81, 89, 109–119
post-processing35
Predefined criterion118–119, 361–362, 575–585, 608
proc436, 604
PSD115–118, 296, 371–372
Puck criterion187
Puck_b criterion187–188
Puck_c criterion188
Python431–437
python461–463

random115–118, 270
random access277–288, 319–324
Regular expression267–269
Reserve Factor176
ResKeyList35, 71, 76, 78, 79, 105–108
Result35, 37, 38, 43–47, 67–103, 105, 109, 112, 119, 270–293, 295–309, 319–324, 358–372
Result, Complex98–100
Result, key70–71, 76, 79, 94, 100–102, 105, 108, 360
Result, layer70–71
Result, value44, 70, 73–74, 79, 100–102
Results563–571
results35
rfalter256
rfinclude256
RMSINT117
ruby35, 67, 464

Samcef47, 311–331, 483, 489, 492, 494–496
scalar73, 78, 79, 81–84, 87, 92, 94, 96, 97, 100
Siemens314
SQL65, 101, 115, 381–383, 436, 473, 492, 497–498, 500–501, 535
SQLite381–383, 436, 473, 492, 497–498, 500–501, 535
stabi317
Strength Ratio176
superelement257–259, 390–396

tensorial73, 83–85, 87, 92, 94, 100
Tresca criterion178–179
Tsai-Hill criterion183–184
Tsai-Wu criterion184–186
tuple432, 436

Unigraphics266, 268

valuesee Result, value
VBA413, 443, 472–473, 475–489, 491–512, 609–615
VBA-Ruby bridge609–615
VBscript464
vectorial73, 82, 83, 87, 92, 94, 100
Von Mises83, 84
Von Mises criterion179

word414, 425–426

xdb257–259, 270–288, 295–309, 393–395, 435–436

Yamada-Sun criterion192

Part I
FeResPost Reference Manual

Chapter I.0
Introduction

FeResPost is a library that allows the manipulation of finite element entities and results. Its purpose is to ease the development of post-processing programs. The supported solvers and corresponding program preferences are discussed in Part III of the document.

The various capabilities implemented in the ruby extension are mainly inspired by Patran capabilities. Several types of objects can be manipulated:

Finally, additional functions, not member of any class are defined in a module called “Post”. “Post” module is discussed in chapter I.6. In the same chapter one also discusses other topics, as exceptions.

Chapter I.1
Generic “DataBase” class

Basically, a “DataBase” class is a container used to store a finite element model, Groups, Results, and other less important entities. The DataBase class also allow to retrieve, manipulate or modify these objects. The DataBase class is a generic class that cannot be instantiated. The specialized classes that inherit the generic DataBase class are described in Part III. Other solvers might be supported in the future. The class hierarchy is schematically represented in Figure I.1.1.


PICT

Figure I.1.1: Finite element DataBase classes hierarchy.

As three classes are represented in Figure I.1.1, the methods described in this Chapter may belong to the generic DataBase class or to the derived classes. A few basic principles should help the user to “guess” in which class some of the methods are defined:

Throughout the Chapter one specifies for the different methods, in which class they are defined. This Chapter is divided in several sections:

A list of the methods defined in “DataBase” class is given in Table I.1.1.

Table I.1.1: The different methods that have been defined in “DataBase” class. Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
Method Name DescriptionExample
Creation and initialization methods
(new) I.1.1
(initialize) I.1.1
(clone) I.1.1
checkCoordSysExists I.1.1
checkElementExists I.1.1
checkNodeExists I.1.1
checkRbeExists I.1.1
getElementType I.1.1
getElementTypeName I.1.1
getElementDim I.1.1
getElementNbrNodes I.1.1
getElementNbrCornerNodes I.1.1
getElementNodes I.1.1
getElementCornerNodes I.1.1
Attributes
Name I.1.7 IV.2.2.1
NbrCoordSys I.1.1
NbrElements I.1.1
NbrNodes I.1.1
NbrAbbreviations I.1.4
NbrGroups I.1.2.1
Manipulation of Results
getResultLoadCaseNames I.1.3.1 “EX09/modifCS3D.rb”
getResultSubCaseNames I.1.3.1 “EX09/modifCS3D.rb”
getResultTypeNames I.1.3.1 “EX09/modifCS3D.rb”
checkResultExists I.1.3.1
getResultSize I.1.3.1
getResultLcInfos I.1.3.1
addResult I.1.3.1
generateCoordResults I.1.3.1 IV.2.4
generateElemAxesResults I.1.3.1
buildLoadCasesCombili I.1.3.1“PROJECTb/DATA/loadCases.rb”
renameResults I.1.3.1
copyResults I.1.3.1
removeResults I.1.3.1“PROJECTb/DATA/loadCases.rb”
removeAllResults I.1.3.1
getResultCopy I.1.3.1 IV.2.4.2
enableLayeredResultsReading (s)I.1.3.2
disableLayeredResultsReading (s)I.1.3.2 IV.2.4
enableSubLayersReading (s) I.1.3.2
disableSubLayersReading (s) I.1.3.2 IV.2.4
Manipulation of Groups
readGroupsFromPatranSession I.1.2.1 IV.2.2.2
writeGroupsToPatranSession I.1.2.1 IV.2.2.2
addGroupCopy I.1.2.1 IV.2.2.4
getAllGroupNames I.1.2.1 IV.2.2.2
checkGroupExists I.1.2.1
getGroupCopy I.1.2.1 IV.2.2.2
eraseGroup I.1.2.1
eraseAllGroups I.1.2.1
getGroupAllElements I.1.2.1
getGroupAllNodes I.1.2.1
getGroupAllRbes I.1.2.1
getGroupAllCoordSys I.1.2.1
getGroupAllFEM I.1.2.1 IV.2.4.4
Manipulation of abbreviations
clearAbbreviations I.1.4
addAbbreviation I.1.4
addAbbreviations I.1.4
Abbreviations I.1.4
getAbbreviation I.1.4
checkAbbreviationExists I.1.4
getAbbreviations I.1.4
CLA methods
getClaDb I.1.5 IV.3.1
calcFiniteElementResponse I.1.5 IV.3.6
calcFiniteElementCriteria I.1.5 IV.3.6
calcFemLamProperties I.1.5
Iterators
each_abbreviation I.1.6
each_groupName I.1.6 IV.2.2.2
each_resultKey I.1.6 IV.2.4
each_resultKeyCaseId I.1.6 IV.2.4
each_resultKeySubCaseId I.1.6 IV.2.4
each_resultKeyLcScId I.1.6 IV.2.4
each_resultKeyResId I.1.6 IV.2.4
Write methods
to_s I.1.7
writeGmsh I.1.8 IV.2.5.4
writeGmshMesh I.1.8 IV.2.5.4

I.1.1 Methods for FEM definition

No generic “DataBase” object can be created because “DataBase” class cannot be instantiated. This means that a statement like:

    db=DataBase.new()

leads to an error message. All the methods described in this section are defined in the specialized versions of the DataBase class. So no “new”, “initialize” or “clone” method is defined in DataBase class.

One defines three methods that allow to retrieve the number of entities of certain types stored in DataBase FE model:

Each of these methods has no argument and returns an integer. Other methods allow to check the existence of finite element entities:

Each of these four methods has one integer argument corresponding to the entity the existence of which is checked.

Several methods allow to retrieve elements information. Each of the following methods has one integer argument corresponding to the element ID:

Normally one class corresponds to each solver supported by FeResPost. The preferences for the different supported solvers are described in Part III.

I.1.2 “Group” methods

Groups can be stored in, and retrieved from a DataBase object. One presents here the methods defined in generic class DataBase, or in its derived classes, and that are devoted to the manipulation of Group objects. In the DataBase, the Group objects are stored in a mapping associating their names to the Group. This association allows to retrieve the Group when needed.

One makes the distinction between the simple manipulation of Groups described in section I.1.2.1 and the more complicated operation where new Groups are created by association operations (section I.1.2.2). The methods related to these associative operations are often defined in the specialized versions of the Database class.

I.1.2.1 Simple manipulation of Groups

One describes here methods that allow the manipulation of Groups stored in a generic DataBase object. All the methods described in this section are defined in generic DataBase class. These methods are described below:

I.1.2.2 Construction of Groups by association operations

This section is devoted to methods that allow the construction of a new Group by selecting entities associated to other entities of the finite element model. For all these methods, the association is checked by inspection of the finite element model stored in the DataBase. Therefore, these methods are defined in the specialized version of the “DataBase” class. Therefore, these methods are systematically defined in specialized versions of the “DataBase” class. For each supported solver, a description of these methods is given. (See Part III.)

I.1.3 “Result” methods

As explained in the introduction of this Chapter, the DataBase can be used to store Results. Internally, a mapping between keys and Results allows to associate Result objects to an identifier. Each key1 is characterized by three String objects corresponding respectively to the load case name, to the subcase name and to the Result type name.

I.1.3.1 Manipulation of Results

The class “Result” is described in Chapter I.4. In this section, one describes the methods of the generic “DataBase” class that deal with “Result” objects. The “Result” methods are:

Methods devoted to the importation of Results from binary Results files are specific to the peculiar solver that produced the Results. These methods are described in Part III.

I.1.3.2 Enabling composite Results reading operations

Four singleton methods allow to enable or disable partially or totally the reading of composite layered Results from finite element result files. These methods influence the behavior of methods defined in the “specialized” versions of the “DataBase” class. (See Part III.) The four methods are:

By default the reading of layered composite Results is enabled for all sub-layers. The disabling may help to reduce the size of Results stored in specialized DataBases. Actually, the reading of composite results is no longer mandatory as most composite results can be produced with the appropriate methods of the “CLA” classes (Part II).

I.1.4 Manipulation of abbreviations

When a Samcef banque is read into a DataBase, the abbreviations defined in the Samcef model are read as well and stored into the Samcef DataBase in a mapping of string objects. Five methods allow the manipulation of abbreviations stored in the DataBase:

1.

clearAbbreviations” has no argument and clears all the abbreviations stored into the DataBase.

2.

addAbbreviation” adds one abbreviation to the DataBase. The method has two String arguments: the key and the value.

3.

addAbbreviations” adds a list of abbreviations to the DataBase. The method has one argument: A Hash object containing the correspondence between keys and values. Each pair is of course a pair of String objects.

4.

NbrAbbreviations” attribute has no argument and returns the number of abbreviations stored in the DataBase.

5.

getAbbreviation” returns the String value of one abbreviation. The method has one String argument: the key of the abbreviation.

6.

checkAbbreviationExists” returns “true” if the abbreviation exists. The method has one String argument: the key of the abbreviation.

7.

getAbbreviations” returns a Hash object containing all the abbreviations stored in the DataBase. This method has no argument.

Note that, even though no abbreviation is defined in other solver models, the abbreviation methods defined in DataBase class can also be used when one works with all models. This is why the methods listed above are defined in generic “DataBase” class and not in “SamcefDb” class described in Chapter III.2.

I.1.5 Composite methods

The DataBase Class provides one method that returns a ClaDb object corresponding to the materials, plies and Laminates stored in the DataBase. This method is called “getClaDb” and has no argument. The units associated to this ClaDb object are the default units as defined in Table II.1.4. If the finite element model is defined in another unit system, it is the responsibility of the user to define correctly the units of the ClaDb database and of all its entities using the method “setUnitsAllEntities” of ClaDb class. (See section II.2.4.)

Another method corresponding to the calculation of Results related to laminate load response has been added. This method called “calcFiniteElementResponse” has the same arguments as the corresponding method defined in the “ClaLam” class. The method and the meaning of its arguments are described in section II.4.8. The method defined in “DataBase” class differs from the one defined in “ClaLam” class by the fact that the algorithm tries to retrieve the Laminate corresponding to the element to which Result values are attached. The information is found in the DataBase object. More precisely, The algorithm performs as follows:

Similarly, one defined the method “calcFiniteElementCriteria” which has exactly the same arguments and outputs as the corresponding method of “ClaLam” class described in section II.4.8. The difference between the two methods resides in the fact that the method in DataBase class retrieves the ClaLam object corresponding to the element to which the tensorial values are attached.

Finally, a third method allows to retrieve laminate engineering properties in the format of Result objects. The method “calcFemLamProperties” has three arguments:

1.

A ClaDb object which is used for the calculations of the different laminate properties.

2.

A ResKeyList object that corresponds to the finite element entities for which values shall be inserted in Result object. Note that the produced Result object are non layered. (Only the ElemId and NodeId of the ResKeyList keys matter.)

3.

A Hash with String keys and values corresponding to the requests. The key corresponds to the name by which the returned Result shall be referred. The value corresponds to the laminate engineering property that is requested. Presently, possible values of this parameter are: “E_f_xx”, “E_f_yy”, “E_k0_xx”, “E_k0_yy”, “E_xx”, “E_yy”, “G_f_xy”, “G_k0_xy”, “G_xy”, “nu_f_xy”, “nu_f_yx”, “nu_k0_xy”, “nu_k0_yx”, “nu_xy”, “nu_yx”, “thickness”, “surfacicMass”, “averageDensity”.

The method returns a Hash with String keys and Result values.

An example of use of this method follows:

    ...
    compDb=db.getClaDb

    res=db.getResultCopy("COORD","coord","coordinates")
    rkl=res.extractRkl

    requests={}
    requests["res1"]="thickness"
    requests["res2"]="E_xx"
    requests["res3"]="E_yy"

    resList=db.calcFemLamProperties(compDb,rkl,requests)

    resList.each do |id,res|
        Util.printRes(STDOUT,id,res)
    end
    ...

For the different “finite element” methods listed above, the units considered for the returned “Result” objects are the units of the “ClaDb” object argument. This characteristic differs from the behavior of the corresponding methods in “ClaLam” class.

I.1.6 Iterators

One describes here the iterators of the generic DataBase class only. The iterators of the specialized versions of the class are described in Part III.

I.1.7 General purpose methods

A few more methods with general purpose are defined:

These methods are defined in the generic “DataBase” class.

I.1.8 “Gmsh” methods

The “writeGmsh” method defined in generic “DataBase” class is used to create a Gmsh result file in which parts of the model and of the Results are saved for later visualization. The purpose of the method is to allow the user to visualize parts of the model and Results. An example of use of the method is as follows:

    db.writeGmsh("brol.gmsh",0,[[res,"stress","ElemCenters"],\
                                         [displ,"displ","Nodes"]],\
                                        [[skelGrp,"mesh slat"]],\
                                        [[skelGrp,"skel slat"]])

The method has six parameters:

1.

A string containing the name of the file in which the model and Results will be output.

2.

An integer corresponding to the id of a coordinate system in which the positions are located and in which the components of Result values are expressed. The coordinate system must be defined in the dataBase db and must be a rectangular one.

3.

An Array containing the Results to be stored in Gmsh file. Each element of the Array is An Array of three elements:

  • A Result object.

  • A String corresponding to the name with which the Result shall be referenced in Gmsh.

  • A String that can have five values: “ElemCenters”, “ElemCorners”, “Elements”, “Nodes”, “ElemCenterPoints” and “ElemNodePoints”. It corresponds to the location of values that are extracted from the Result object to be printed in the Gmsh file. Note:

    • “ElemCenterPoints” prints the values at center of elements but on a point, no matter the topology of the element. This may be handy for the visualization of Results on zero length elements.

    • “ElemNodePoints” prints the values at nodes of elements elements on points, no matter the topology of the element.

    • “Elements” output location combines the outputs at “ElemCorners” and “ElemCenters”. If no value is found at a corner, the algorithm checks whether an output is found at center of element, and uses that value if it is found.

4.

An Array containing the Meshes to be stored in Gmsh file. Each element of the Array is An Array of two elements:

  • A Group object. The elements contained in the Group will be output in the Gmsh file.

  • A String corresponding to the name with which the mesh shall be referenced in Gmsh.

5.

An Array containing the parts of the model for which a “skeleton” shall be saved in the Gmsh file. (A skeleton is a representation of the mesh with only a few edges.)

  • A Group object. The elements contained in the Group will be output in the Gmsh file.

  • A String corresponding to the name with which the skeleton shall be referenced in Gmsh.

6.

A logical parameter specifying whether a binary output is requested. If the parameter is “true” a binary output is done, otherwise, the output is an ASCII one. The parameter is optional and binary output is the default. A binary output is significantly faster than an ASCII one.

Parameters 3, 4 and 5 are optional. They can be a void Array or replaced by nil argument. All the last nil parameters may be omitted. Parameter 6 is optional too. If no pair of key-values is found for a Result to be printed. Nothing is output in the gmsh file.

It is the responsibility of the user to provide Results that associate values to a single valid key. Otherwise, an error message is issued and exception is thrown. In particular, as Results written in GMSH files are not layered, the user should be careful not to output multi-layered Results. The details in error message output are controlled by the debugging verbosity level. (See I.6.6.)

Note also that if the values that the user try to output are not correct, a substitution is done: Inifinite float values are replaced by MAXFLOAT value, NaN values are replaced by MINFLOAT value. (Of course it is advised to output Result objects with valid values.)

The “writeGmshMesh” method defined in generic “DataBase” class saves a Gmsh mesh file. The method has up to four arguments (last argument is optional):

1.

A String containing the name of the file in which the mesh is output.

2.

An integer argument corresponding to the coordinate system in which the nodes are expressed.

3.

A Group corresponding to the entities to be saved in the mesh file.

4.

An optional Boolean argument specifying whether the mesh is output in binary format. The default value of the argument is “true” and corresponds to a binary output.

An example of use follows:

        db.writeGmshMesh("brol.msh",0,skelGrp,false)

Chapter I.2
The “CoordSys” class

It may be practical to manipulate coordinate systems at post-processing level. Therefore, a “CoordSys” class devoted to the manipulation of coordinate systems is proposed. The methods defined in that class are described in sections I.2.2 and I.2.5. A list of the methods defined in “CoordSys” class is given in Table I.2.1.

Table I.2.1: The different methods that have been defined in “CoordSys” class. Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
Method Name DescriptionExample
Creation and initialization methods
new (s) I.2.2 IV.2.4.5
initialize I.2.5
clone I.2.5
Definition
initWith3Points I.2.2.1IV.2.4.5
initWithOV1V2 I.2.2.2
initWithOV2V3 I.2.2.2
initWithOV3V1 I.2.2.2
initWithOV2V1 I.2.2.2
initWithOV3V2 I.2.2.2
initWithOV1V3 I.2.2.2
updateDefWrt0 I.2.2.2
Modifying point coordinates
changeCoordsA20I.2.3.1IV.2.4.5
changeCoords02BI.2.3.2IV.2.4.5
changeCoordsA2BI.2.3.3IV.2.4.5
Modifying vector or tensor components
changeCompsA20I.2.4.1IV.2.4.5
changeComps02B I.2.4.2IV.2.4.5
changeCompsA2BI.2.4.3IV.2.4.5
Printing
to_s I.2.5
Attributes
Id I.2.5

I.2.1 The CoordSys object

A CoordSys object corresponds to a coordinate system. CoordSys objects are generally created in a DataBase when a model is imported.

Besides the data corresponding to the definition of the coordinate system, the CoordSys object also contains a definition of the coordinate system wrt the most basic coordinate system “0”. The corresponding member data are used by functions like the Result methods of modification of reference coordinate systems to perform the transformations of components (sections I.4.6.7 and I.4.6.8). Practically those functions work in two steps:

1.

The components of the Result object are expressed wrt the basic coordinate system “0”.

2.

Then, the components are expressed wrt the new coordinate system.

The definition of the corresponding member data is done by calling the method “updateDefWrt0” (section I.2.2.3).

I.2.2 Construction or manipulation functions

Besides the “new” class method that returns a new coordinate system initialized to the “0” structural coordinate system, several functions can be used to modify the CoordSys objects.

I.2.2.1 “initWith3Points” method

initWith3Points” method is used to define a coordinate system with the coordinates of three points A, B and C. (See the definition of “CORD2C”, “CORD2R” and “CORD2S” in [Sof04b].) This function has 5 arguments:

The three vectors mentioned above are actually Arrays of three real values corresponding to the coordinates of points given in coordinate system identified by the integer argument.

Note that no check is made in a DataBase to ensure that the data are consistent. (For example, checking that the reference coordinate system exists.)

I.2.2.2 Three “initWithOViVj” methods

The three methods are “initWithOV1V2”, “initWithOV2V3”, “initWithOV3V1”, “initWithOV2V1”, “initWithOV3V2” and “initWithOV1V3”. They produce CoordSys objects defined by their origin and two direction vectors corresponding to vector ei and to the orientation of vector ej respectively.

The six arguments of these methods are:

Note that the orientation vector ej is not necessarily orthogonal to ei. If the vectors are not orthogonal, then i is a unit vector parallel to ei, and vector j is the unit vector perpendicular to i closest to ej. The last vector k of the coordinate system is a unit vector perpendicular to both i and j.

Here again, no check is made in a DataBase to ensure that the data are consistent. (For example, checking that the reference coordinate system exists.)

I.2.2.3 “updateDefWrt0” method

updateDefWrt0” method updates the definition of a CoordSys object wrt to “0” (most basic coordinate system). This function has one argument: the DataBase in which the information needed to build the definition wrt 0 is found.

Note that if one works with several DataBases, the responsibility of managing the correspondence of coordinate systems and DataBases lies on the user.

I.2.3 Transformation of point coordinates

The “CoordSys” class defines three methods devoted to the transformation of a point coordinates from one coordinate system to another.

I.2.3.1 “changeCoordsA20” method

Method “changeCoordsA20” is used to calculate the coordinates of a point wrt basic or “0” coordinate system:

The method is called as follows:

   coords0=csA.changeCoordsA20(coordsA)

I.2.3.2 “changeCoords02B” method

Method “changeCoords02B” is used to calculate the coordinates of a point wrt a given coordinate system “B”:

The method is called as follows:

   coordsB=csB.changeCoords02B(coords0)

I.2.3.3 “changeCoordsA2B” method

Method “changeCoordsA2B” is used to calculate the coordinates of a point wrt a given coordinate system “B”. The initial coordinate system is a given “A” coordinate system:

The method is called as follows:

   coordsB=csA.changeCoordsA2B(coordsA,csB)

I.2.4 Transformation of vector and tensor components

The “CoordSys” class defines three methods devoted to the transformation of a vector or tensor components from one coordinate system to another. These methods are similar to the methods used to transform point coordinates in section I.2.3 but with the following differences:

I.2.4.1 “changeCompsA20” method

Method “changeCompsA20” is used to calculate the components of a vector or tensor wrt basic or “0” coordinate system:

The method is called as follows:

   vm0=csA.changeCompsA20(coordsA,vmA)

I.2.4.2 “changeComps02B” method

Method “changeComps02B” is used to calculate the components of a vector or tensor wrt basic or “B” coordinate system:

The method is called as follows:

   vmB=csB.changeCoords02B(coords0,vm0)

I.2.4.3 “changeCompsA2B” method

Method “changeCompsA2B” is used to calculate the components of a vector or tensor wrt basic or “B” coordinate system:

The method is called as follows:

   vmB=csA.changeCoordsA2B(coordsA,vmA,csB)

I.2.5 Other methods

One gives here a list of functions that do not fit in any category listed above.

I.2.5.1 “initialize” method

Method “initialize” initializes or clears a CoordSys object. After initializing, the definition corresponds to the “0” structural coordinate system.

I.2.5.2 “clone” method

clone” method returns a Copy of the CoordSys object to which it is applied.

I.2.5.3 “to_s” method

to_s” method is used for printing the Result object.

I.2.5.4 “Id” attribute

Id” integer attribute corresponds to the integer identifier of the CoordSys object. One defines a “setter” and “getter” attribute (“Id=” and “Id” methods respectively).

Chapter I.3
The “Group” class

The “Group” corresponds to the Patran notion of group. Group objects can be stored in a DataBase object, retrieved from it and manipulated outside the DataBase. One describes here the manipulation methods outside the DataBase class.

A list of the methods defined in “Group” class is given in Table I.3.1.

Table I.3.1: The different methods that have been defined in “Group” class. Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
Method Name DescriptionExample
Creation and initialization methods
new (s) I.3.2IV.2.5.1
initialize I.3.7
clone I.3.7
Identification (attributes)
Name= I.3.7IV.2.2.3
Name I.3.7
Manipulation of entities
getEntitiesByType I.3.3IV.2.2.2
getNbrEntities I.3.3
getNbrEntitiesByType I.3.3IV.2.2.2
setEntities I.3.3IV.2.5.1
setEntitiesByType I.3.3
addEntities I.3.3
addEntitiesByType I.3.3
removeEntities I.3.3
removeEntitiesByType I.3.3
clearAllEntitiesByTypeI.3.3
matchWithDbEntities I.3.3IV.2.5.1
importEntitiesByType I.3.3
containsEntity I.3.3
Operators
+ I.3.4IV.2.5.1
- I.3.4
* I.3.4IV.2.2.4
/ I.3.4
BLOBs for SQL
toBlob I.3.5
fromBlob I.3.5
Iterators
each_element I.3.6
each_rbe I.3.6
each_node I.3.6IV.2.2.2
each_coordsys I.3.6
Other methods
to_s I.3.7
Attribute readers
NbrElements I.3.7
NbrNodes I.3.7
NbrRbes I.3.7
NbrCoordsys I.3.7

I.3.1 The concept of “Group”

A Group is characterized by its name (a String object) and the entities it contains. Four type of entities can be contained in a FeResPost Group: coordinate systems, nodes, elements and rigid body elements (RBEs). At C++ level, for each type of entity, the class group manages a set of integers corresponding to the identifiers of the entities.

Part of the operations dealing with Groups are done by methods defined in DataBase class. The methods of DataBase specially devoted to operations mainly related to Groups are described in section I.1.2.

I.3.2 Creation of a Group object

The singleton method “new” is used to create Group objects.

I.3.3 Manipulation of entities stored in a Group

The class “Group” provides a large choice of methods devoted to the manipulation of the list of entities in its storage. One makes the distinction between operations that modify the content of a Group, and the operations that allow the inspection of this content.

The modification of the Group’s content can be done by calls to the following methods:

Presently, four methods devoted to the manipulation of entities and not modifying the Group have been defined:

A FeResPost Group cannot contain Nastran MPCs.

I.3.4 Group operators

Eight such operators have been defined. One first explains the meaning and behavior of the four elementary dyadic operations.

I.3.5 “BLOBs”

Group objects can be saved in SQL database as “BLOB” objects.

Two methods are defined in Group class to convert object to and from Blobs:

I.3.6 Iterators of Group class

The class “Group” provides four iterators:

These iterators iterate on the corresponding entities stored in the Group object. They produce Integer values that are passed to the block.

I.3.7 Other methods

One gives here a list of methods that do not fit in any category listed above:

The “Name” and “Name=” methods correspond to the “Name” attribute.

Chapter I.4
The “Result” class

The “Result” class is devoted to the manipulation of finite element Results. Examples of Results are stress tensor on volumic or surfacic elements, displacements, grid point forces,... The ruby class “Result” is a wrapping around the C++ class “Result”.

Results can be read from various solver binary files. See Part III for more information.

The “Result” class allows the storage and manipulation of Real as well as Complex values. Note however that several of the methods of Result class do not allow the manipulation of Complex Results. Therefore, indications are inserted here and there in this Chapter to provide information about the “Complex capabilities” of the different methods.

An important comment must be done: Even though the results can be imported into a DataBase, this does not mean that the manipulation of the results is correct. Indeed, all manipulation that involve transformation of coordinate systems can be incorrect because geometric non-linearities are not taken into account. Methods that can be affected by this limitation are for example: “modifyRefCoordSys”, “modifyPositionRefCoordSys” and “calcResultingFM”.

A list of the methods defined in “Result” class is given in Table I.4.1.

Table I.4.1: The different methods that have been defined in “Result” class. Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
Method Name DescriptionExample
Creation and initialization methods
new (s) I.4.14 IV.2.4.6
initialize I.4.14
clone I.4.14 IV.2.4.6
cloneNoValues I.4.14
Manipulation of data
Name= I.4.6.1
Name I.4.6.1
clearData I.4.6.1
getData I.4.10 IV.2.4.2
Size I.4.14 IV.2.4.1
Format= I.4.6.1
Format I.4.6.1
TensorOrder= I.4.6.1
TensorOrder I.4.6.1
setIntId I.4.6.1
getIntId I.4.6.1
setRealId I.4.6.1
getRealId I.4.6.1
insert I.4.6.1
assembleFieldCSFrom3VectorsI.4.1.5
insertRklVals I.4.6.1
insertResultValues I.4.6.1
removeKeysAndValues I.4.6.1
setComponent I.4.6.1
setRefCoordSys I.4.6.2
renumberLayers I.4.6.3
renumberSubLayers I.4.6.4
removeLayers I.4.6.5
removeSubLayers I.4.6.6
modifyRefCoordSys I.4.6.7 IV.2.4.5
modifyPositionRefCoordSys I.4.6.8 IV.2.5.2
setToCombili I.4.6.9
setToCombiliPerComponent I.4.6.9
Extraction methods
extractResultOnEntities I.4.3.1
extractResultOnLayers I.4.3.2
extractResultOnSubLayers I.4.3.3
extractResultOnRkl I.4.3.4 IV.2.4.2
extractResultOnResultKeys I.4.3.5
extractResultOnRange I.4.3.6
extractResultForNbrVals I.4.3.7
extractResultMin I.4.3.8
extractResultMax I.4.3.9 IV.2.4.2
extractRklOnRange I.4.3.10
extractRklForNbrVals I.4.3.11
extractRklMin I.4.3.12
extractRklMax I.4.3.13
extractRkl I.4.3.14 IV.2.4.2
extractLayers I.4.3.18
extractSubLayers I.4.3.19
extractGroup I.4.3.17
extractGroupOnRange I.4.3.15
extractGroupForNbrVals I.4.3.16
Derivation methods
deriveScalToScal I.4.4.1 IV.2.4.2
deriveScalPerComponent I.4.4.2 IV.2.4.2
deriveVectorToOneScal I.4.4.3 IV.2.5.4
deriveVectorToVector I.4.4.4
deriveVectorToTensor I.4.4.5
deriveTensorToOneScal I.4.4.6
deriveTensorToTwoScals I.4.4.7
deriveTensorToThreeScals I.4.4.8 IV.2.4.2
eigenQR I.4.4.9 IV.2.4.2
deriveDyadic I.4.5
deriveByRemapping I.4.4.10
Global Force and Moment
calcResultingFM (s) I.4.8 IV.2.5.3
Operators
+ I.4.7.1
- I.4.7.2
* I.4.7.3 IV.2.5.2
/ I.4.7.4
** I.4.7.5
BLOBs for SQL
toBlob I.4.11 IV.2.6, IX.1.5, VII.1.9
fromBlob I.4.11
Iterators
each I.4.12 IV.2.4.4
each_key I.4.12 IV.2.4.5
each_values I.4.12 IV.2.4.5
Complex Results manipulation
set2RI I.4.9.1 IV.2.4.6
set2MP I.4.9.1 IV.2.4.6
conjugate I.4.9.2
getR I.4.9.4 IV.2.4.6
getM I.4.9.4 IV.2.4.6
getI I.4.9.4 IV.2.4.6
getP I.4.9.4 IV.2.4.6
rotateBy I.4.9.3
assembleComplex I.4.9.5 IV.2.4.6
A few singleton methods
layerStr2Int (s) I.4.13
layerInt2Str (s) I.4.13
subLayerStr2Int (s) I.4.13
subLayerInt2Str (s) I.4.13
Attributes
Name I.4.6.1
Other methods
to_s I.4.14
Attributes
Name I.4.6.1
Size I.4.14 (read only)
Format I.4.6.1
TensorOrder I.4.6.1

I.4.1 The concept of “Result”

Basically, a Result may be considered as a mapping between “keys” and “values”. These two concepts are discussed in sections I.4.1.1 and I.4.1.2 respectively.

Otherwise several member data of Result objects can be accessed at ruby level. This is the case for Result name, integer and real identifiers. Those are discussed in section I.4.1.3.

I.4.1.1 “Keys”

The “keys” of Results correspond to the entities to which “values” are associated. For example, a key may be:

So, at C++ level, each key is characterized by four integers:

At ruby level, one can work with either the C++ integer ids, or their string correspondent. The correspondence between string and integers are given in Tables I.4.2, I.4.3, I.4.4 and I.4.5. The data given in these Tables can be completed by additional data peculiar to the different supported solvers. (See Part III for more information.)

In Table I.4.4, the last layers IDs cannot be attributed to Result keys. The elements corresponds to groups of layers and are used to perform extraction operations:


Table I.4.2: Correspondence between element strings and their integer ids.
No element association
"NONE" -1
For Results associated to elements
"elem 1" 1
"elem 2" 2
"elem 3" 3
"elem ..." ...


Table I.4.3: Correspondence between special nodes for element Results and their integer ids.
No node association
"NONE" -999
For Results associated to nodes
"node 1" 1
"node 2" 2
"node 3" 3
"node ..." ...


Table I.4.4: Correspondence between Result layer names and their integer ids.
For unlayered Results
NONE
-999
Undefined layer
UNDEF
-300
For stress recovery in bars and beams
"Point A" -201
"Point B" -202
"Point C" -203
"Point D" -204
"Point E" -205
"Point F" -206
For 2D elements
"Z0"1 -100
"Z1" -101
"Z2" -102
For Results in laminates (positive layers)
"layer 1" 1
"layer 2" 2
"layer 3" 3
"layer ..." ...
Group of layers for extraction operations
"Beam Points" -2001
"Shell Layers" -2002
"All Plies" -2003
"All Layers" -2004


Table I.4.5: Correspondence between Result sub-layer names and their integer ids. ("All Sub-Layers" is used for extractions only.)
"NONE" 0
"All Sub-Layers" 50
"Bottom" 101
"Mid" 102
"Top" 103

Note that the notion of “key” is also closely related to the “ResKeyList” ruby class which is simply a list of key objects (see Chapter I.5).

I.4.1.2 “Values”

The values of Result are characterized by an integer value (32 bits integer) and one or several real values. The integer value corresponds to the coordinate system into which the components are expressed:

Obviously, for several types of coordinate system, the values must be attached to an element to make sense. This is the case for “elemIJK”, “plyCS”, “matCS”, “elemCS”,...

The real values correspond to the components:

Note that the name of the components given above matter, as they may be used to extract a single component out of a vectorial or tensorial Result. For Complex Result, the numbers of components mentioned above is multiplied by two. They are presented in the following order:

The components are stored in single precision real values (float coded on 32 bits). This means that there is no advantage at using double precision real values in your programming as far as the manipulation of results is concerned.

I.4.1.3 Identification of Result objects

Besides the mapping from key to values, the Result objects contain information that allow their identification. The identification information is:

The methods used to access these member data are described in section I.4.6.1.

I.4.1.4 Other characteristics

A Result object is also characterized by two other integer values:

Methods used to manipulate these data are described in section I.4.6.1. These two integers are attributes of the class.

I.4.1.5 “FieldCS” Result

“FieldCS” Results is a special kind of Result corresponding to the concept of coordinate system defined element by element, node by node, element corner by element corner, etc. Each key of the Result is associated to a Value of nine components corresponding to the components of three local vectors associated to the key.

When defining the “FieldCS” Result one must be careful:

assembleFieldCSFrom3Vectors” method is specific to the construction of “FieldCS” type of Results. This method has three vectorial Result arguments. The key-value pairs of the three Result arguments must match.

I.4.2 FeResPost Results’ characteristics

When Results are read from a Result output file produced by a solver (Part III), the information found in these Result files are used to produce Results with characteristics that are defined according to FeResPost conventions. These characteristics are related to Result naming conventions, Result tensor type, sign conventions, layer associations...

We consider that Nastran solver as a reference for FeResPost solver’s support. Therefore, the naming conventions and other characteristics defined in section III.1.2 are considered as the reference (default) FeResPost Result’s characteristics.

Note also that the subcase names associated to Nastran Results read from XDB, OP2 or HDF files are also considered the reference for other solvers.

I.4.3 Extraction methods

The class “Result” defines several methods allowing the construction of a new Result object, or of a “ResKeyList” object from a previously existing Result by an appropriate selection on the keys. The extraction methods defined in class Result are defined in the following sections.

I.4.3.1 “extractResultOnEntities” method

extractResultOnEntities” method is used to extract a sub-set of keys and values from an existing Result object. The method returns the newly created Result object. The method has up to four arguments:

1.

The “Method” argument is a String object specifying the algorithm to be used to select the keys and values to be inserted in the new Result object. Possible values of this argument are provided in Table I.4.6.

2.

The “Target” argument is a Group containing the elements and/or nodes used by some of the algorithms described above to select sub-sets of Results.

3.

The “LayersList” argument is an Array containing the list of layers on which the pairs of key and value must be extracted. If the Array is void, then data corresponding to all layers are extracted. If the Array is not void, the elements must be String or integer objects

4.

The “SubLayersList” argument is an Array containing the list of sub-layers on which the pairs of key and value must be extracted. If the Array is void, then data corresponding to all sub-layers are extracted. If the Array is not void, the elements must be String or integer objects

The two last arguments are optional. Note that the “Method” argument described above is the same as the “Method” argument of the DataBase member method “getResultCopy” described in section I.1.3. Please refer to that part of the manual for more information on valid extraction data.

This method works for Real as well as for Complex Results.


Table I.4.6: The different Result extraction methods.
“Elements” All the values associated to the elements of Group “Target” are inserted in the values of the returned Result object. This means that the new Result contains both values at center of element and at corners.
“ElemCenters” All the values associated to the elements of Group “Target” but not associated to any node are inserted in the values of the returned Result object. This means that the extraction returns only values at center of the elements.
“ElemCorners” All the values associated to the elements of Group “Target” and associated to any node are inserted in the values of the returned Result object. The extraction returns only values at corner of the elements. Note that the list of nodes of the “Target” Group is irrelevant for this extraction operation.
“Nodes” All the values associated to the nodes of Group “Target” are inserted in the values of the returned Result object.
“NodesOnly” All the values associated to the nodes of Group “Target” but associated to no elements are inserted in the values of the returned Result object.
“ElemNodes” All the values associated to the elements of Group “Target” AND to the nodes of the same Group are inserted in the values of the returned Result object. This means that the new Result contains only values at corners of elements.
“MPCs” All the values associated to the MPCs (RBEs) of Group “Target” are inserted in the values of the returned Result object. (This extraction method has been added to deal with Grid Point Forces MPC Forces or Moments Results when the “RIGID=LAGR” option is used.)
“MPCNodes” All the values associated to the MPCs (RBEs) of Group “Target” AND to the nodes of the same Group are inserted in the values of the returned Result object. This means that the new Result contains only values at corners of elements. (This extraction method has been added to deal with Grid Point Forces MPC Forces or Moments Results when the “RIGID=LAGR” option is used.)

I.4.3.2 “extractResultOnLayers” method

extractResultOnLayers” method is used to extract a sub-set of keys and values from an existing Result object. The method returns the newly created Result object. The method has one “LayersList” argument: it is an Array containing the list of layers on which the pairs of key and value must be extracted. The elements of the Array argument are integers or String values.

This method works for Real as well as for Complex Results.

I.4.3.3 “extractResultOnSubLayers” method

extractResultOnSubLayers” method is used to extract a sub-set of keys and values from an existing Result object. The method returns the newly created Result object. The method has one “SubLayersList” argument: it is an Array containing the list of sub-layers on which the pairs of key and value must be extracted. The elements of the Array argument are integers or String values.

This method works for Real as well as for Complex Results.

I.4.3.4 “extractResultOnRkl” method

extractResultOnRkl method returns a Result object build by extraction of the values corresponding to the keys contained in the ResKeyList “Target” argument.

This method works for Real as well as for Complex Results.

I.4.3.5 “extractResultOnResultKeys” method

extractResultOnResultKeys” method returns a Result object build by extraction of the values corresponding to the keys contained in the Result “Target” argument. (This method is very similar to “extractResultOnRkl” method, except that the target is given by a Result argument.)

This method works for Real as well as for Complex Results.

I.4.3.6 “extractResultOnRange” method

extractResultOnRange” method returns a Result object build by extraction of the values selected by specifying a range. This method can be applied to scalar Result objects only as the range is specified by one or two Real values. The arguments of the method are:

1.

The “Method” String argument specifies the extraction algorithm that is used. Four values are possible:

  • “below”: extraction of the values below the “LowerBound” Real argument value.

  • “above”: extraction of the values above the “UpperBound” Real argument value.

  • “between”: extraction of the values between the “LowerBound” and “UpperBound” Real argument value.

  • “outside”: extraction of the values not between the “LowerBound” and “UpperBound” Real argument value.

2.

The “LowerBound” argument is a real value specifying the lower bound of the range. For some algorithms, this value may be unused and irrelevant.

3.

The “UpperBound” argument is a real value specifying the upper bound of the range. For some algorithms, this value may be unused and irrelevant.

This method works for Real Results only.

I.4.3.7 “extractResultForNbrVals” method

extractResultForNbrVals” method returns a Result object build by extraction of maximum “NbrVals” values. This method can be applied to scalar Result objects only and has two arguments:

1.

The “Method” String argument specifies the extraction algorithm that is used. Two values are possible:

  • “smallest” causes the method to keep the smallest values of the Result object.

  • “largest” causes the method to keep the largest values of the Result object.

2.

“NbrVals” is an integer argument corresponding to the number of values to be kept.

This method works for Real Results only.

I.4.3.8 “extractResultMin” method

extractResultMin” method returns a Result object build by extraction of the minimum value and corresponding key. This method can be applied to scalar Result objects only.

This method works for Real Results only.

I.4.3.9 “extractResultMax” method

extractResultMax” method returns a Result object build by extraction of the maximum value and corresponding key. This method can be applied to scalar Result objects only.

This method works for Real Results only.

I.4.3.10 “extractRklOnRange” method

extractRklOnRange” method works exactly as method “extractResultOnRange” described in section I.4.3.6 but returns a ResKeyList object instead of a Result object. This means that one returns only a list of keys, but not the associated values.

This method works for Real Results only.

I.4.3.11 “extractRklForNbrVals” method

extractRklForNbrVals” method works exactly as method “extractResultForNbrVals” described in section I.4.3.7 but returns a ResKeyList object instead of a Result object. This means that one returns only a list of keys, but not the associated values.

This method works for Real Results only.

I.4.3.12 “extractRklMin” method

extractRklMin” method returns a ResKeyList object build by extraction of the key corresponding to the minimum value. This method can be applied to scalar Result objects only.

This method works for Real Results only.

I.4.3.13 “extractRklMax” method

extractRklMax” method returns a ResKeyList object build by extraction of the key corresponding to the maximum value. This method can be applied to scalar Result objects only.

This method works for Real Results only.

I.4.3.14 “extractRkl” method

extractRkl” method returns a ResKeyList object build by extraction of all the keys of the Result object to which the method is applied.

This method works for Real as well as for Complex Results.

I.4.3.15 “extractGroupOnRange” method

extractGroupOnRange” method works exactly as method “extractResultOnRange” described in section I.4.3.6 but returns a Group object instead of a Result object. The Group contains the element and node entities for which values in the specified range have been found.

This method works for Real Results only.

I.4.3.16 “extractGroupForNbrVals” method

extractGroupForNbrVals” method works exactly as method “extractResultForNbrVals” described in section I.4.3.7 but returns a Group object instead of a Result object. The Group contains the element and node entities for which values in the specified range have been found.

This method works for Real Results only.

I.4.3.17 “extractGroup” method

extractGroup” method returns a Group object containing the elements and nodes that are referenced in the Result object. This method has no argument.

This method works for Real as well as for Complex Results.

I.4.3.18 “extractLayers” method

extractLayers” method returns an Array of String and integers corresponding to the layers that are referenced in the Result object. This method has no argument.

This method works for Real as well as for Complex Results.

I.4.3.19 “extractSubLayers” method

extractSubLayers” method returns an Array of String and integers corresponding to the sub-layers that are referenced in the Result object. This method has no argument.

This method works for Real as well as for Complex Results.

I.4.4 Derivation monadic methods

All the methods presented in this section are devoted to the production of new results by performing operations on the values of the Result object to which they are applied. Each method produces Results with as many pairs “key-values” as in the Result object to which it is applied, but the number of components associated to each key may be different than the original number of components. Indeed, the original Result and derived Result have not necessarily a same tensor order.

Most of the methods presented below have only one argument: a Method String object corresponding to the algorithm of derivation. The use of the methods defined below leads sometimes to very heavy notations for simple or very often used operations. Therefore, short-cuts to some methods have been defined in the “Post” module (Chapter I.6).

I.4.4.1 “deriveScalToScal” method

deriveScalToScal” method builds a new Result object by performing an operation on all the values of the Result object to which it is applied. Both Result objects correspond to scalar values. The Possible values of the “Method” argument are:

The method works for Real Results as well as Complex Results. However, some of the methods are not available for Complex Results: “asin”, “acos”, “atan” and “sgn” can be used with Real Results only. Note that when used with a Complex Result object, the method returns a Complex Result object. There is however one exception to this rule: the “abs” derivation method returns a Real Result.

I.4.4.2 “deriveScalPerComponent” method

deriveScalPerComponent” method builds a new Result object by performing a scalar operation on all the values of the Result object to which it is applied. The Result object can be scalar, vectorial or tensorial. In case, of vectorial or tensorial Result, the scalar operation is performed component-per-component, regardless of the coordinate system in which the values are expressed. The Possible values of the “Method” argument are the same as for deriveScalToScal method. The method works for Real Results only. (Complex Results are not accepted and an exception is raised.)

I.4.4.3 “deriveVectorToOneScal” method

deriveVectorToOneScal” method builds a new Result object by performing an operation on all the values of the Result object to which it is applied. The Result object to which the method is applied must be vectorial. The created Result object is scalar. Possible values of the “Method” String argument are:

This method works for Real Results as well as for Complex Results. When applied to a Complex Result object, the method works as follows:

I.4.4.4 “deriveVectorToVector” method

deriveVectorToVector” method builds a new Result object by performing an operation on all the values of the Result object to which it is applied. The Result object to which the method is applied must be vectorial. The created Result object is vectorial too. Possible values of the “Method” String argument are:

This method works for Real Results as well as for Complex Results.

I.4.4.5 “deriveVectorToTensor” method

deriveVectorToTensor” method builds a new Result object by performing an operation on all the values of the Result object to which it is applied. The Result object to which the method is applied must be vectorial. The created Result object is tensorial too. Possible values of the “Method” String argument are:

This method works for Real Results as well as for Complex Results.

I.4.4.6 “deriveTensorToOneScal” method

deriveTensorToOneScal” method builds a new Result object by performing an operation on all the values of the Result object to which it is applied. The Result object to which the method is applied must be tensorial. The created Result object is scalar. Possible values of the “Method” String argument are:

All the methods listed above work for Real Tensorial Results. For Complex Results, only the methods of Component extractions can be used.

I.4.4.7 “deriveTensorToTwoScals” method

deriveTensorToTwoScals” method returns an Array of two Result objects derived from the tensorial Result object on which the method is applied. The returned Results are scalar. Possible values of the “Method” String argument are:

This method works for Real Results only.

I.4.4.8 “deriveTensorToThreeScals” method

deriveTensorToThreeScals” method returns an Array of three Result objects derived from the tensorial Result object on which the method is applied. The returned Results are scalar. Possible values of the “Method” String argument are:

This method works for Real Results only.

I.4.4.9 “eigenQR” method

eigenQR” method returns an Array of six Result objects derived from the tensorial Result object on which the method is applied. The method has no argument and the six Results returned correspond to:

1.

The first eigen-value.

2.

The first eigen-vector.

3.

The second eigen-value.

4.

The second eigen-vector.

5.

The third eigen-value.

6.

The third eigen-vector.

Eigen-values and vectors are sorted by order of increasing eigen-values. This method works for Real Results only.

I.4.4.10 “deriveByRemapping” method

deriveByRemapping” method returns a Result object obtained by remapping the values of the Result object to which the method is applied. This method takes three parameters:

1.

“FromTo”: a String object specifying the correspondence between the keys of the old Result object and the keys of the new Result object. Eleven different values of the “FromTo” argument are allowed:

  • “CentersToElemsAndNodes”: one selects all the values at center of elements (i.e. the key of which has an elemId, but no nodeId), then one produce a new Result object with values associated to the corners and edges of those elements.

  • “CentersToNodes”: one selects all the values at center of elements (i.e. the key of which has an elemId, but no nodeId), then one produce a new Result object with values associated to the nodes of those elements (i.e. the key of which has no elemId but has a nodeId).

  • “CentersToCorners”: one selects all the values at center of elements (i.e. the key of which has an elemId, but no nodeId), then one produce a new Result object with values associated to the corners of those elements.

  • “CentersToCornerNodes”: one selects all the values at center of elements (i.e. the key of which has an elemId, but no nodeId), then one produce a new Result object with values associated to the corner nodes of those elements (i.e. the key of which has no elemId but has a nodeId).

  • “NodesToCenters”: one selects all the values associated to nodes and produces a new Result in which the values are associated to the centers of the elements touching this node.

  • “NodesToElemsAndNodes”: one selects all the values associated to nodes and produces a new Result in which the values are associated to the elements touching this node, but one keeps the association to the initial node.

  • “CornersToCenters”: one selects all the values associated to corners (i.e. the key of which has both an elemId and a nodeId corresponding to a corner of this element), and one builds a Result object with values associated to the center of elements.

  • “CornersToNodes”: one selects all the values associated to corners (i.e. the key of which has both an elemId and a nodeId that corresponds to an element corner), and one builds a Result object with values associated to the corresponding nodes.

  • “MergeLayers”: one produces a Result object in which for each pair of Element, Node and SubLayer only one Layer is kept. The layerId of each key of the produced Result object is kept uninitialized (i.e. set to -1).

  • “MergeLayersKeepId”: one produces a Result object in which for each pair of Element, Node and SubLayer only one Layer is kept. The layerId of each key of the produced Result object is the one of the selected key-value of the original Result. For this option only “min” and “max” selection methods are accepted.

  • “MergeSubLayers”: one produces a Result object in which for each pair of Element, Node and Layer only one SubLayer is kept. The subLayerId of each key of the produced Result object is kept uninitialized (i.e. set to 0).

  • “MergeSubLayersKeepId”: one produces a Result object in which for each pair of Element, Node and Layer only one SubLayer is kept. The subLayerId of each key of the produced Result object is the one of the selected key-value of the original Result. For this option only “min” and “max” selection methods are accepted.

  • “MergeAll” merges all the keys and produces a Result object with a single “key-value” pair. The “sum”, “average”, “min” and “max” selection methods are accepted.

  • “NodesToCorners”: one selects all the values associated to nodes and produces a new Result in which the values are associated to the elements touching this node and of which the node is a corner, and one keeps the association to the initial node.

  • “CornersToElemsAndNodes”: one selects the values associated to element corners and produces a new Result in which values are associated to all the nodes defining the element. Values are associated to element ID and node IDs.

  • “ElemsAndNodesToCenters”: one selects all the values associated to elements and nodes (i.e. the key of which has both an elemId and a nodeId), and one builds a Result object with values associated to the center of elements.

  • “ElemsAndNodesToNodes”: one selects all the values associated to corners (i.e. the key of which has both an elemId and a nodeId), and one builds a Result object with values associated to the corresponding nodes but not to the elements.

  • “ElemsAllToCenters”: one selects all the values associated to elements corners and center, and one builds a Result object with values associated to the center of elements.

  • “CornersToElemsAllNodes”: reinterpolates the result values at element corners to other element nodes (typically edge nodes, or node at element center). The available methods are “average” and “sum”. (See below.) Currently, this method is available for Nastran results only.

The different “fromTo” parameters are summarized in Table I.4.7. Remark that one distinguishes the “CornerNodes” (Result keys associated to elements and nodes at corner of elements) and the “ElemsAndNodes” (Result keys associated to elements and nodes of elements but not necessarily at their corners).

2.

“Method”: a String object used to specify the way values associated to different keys are merged into a single value (if this happens). An example of situation in which the case may occur is for example when one uses the “NodesToCenters” option and that the values of several nodes are merged into the value of a single element. Five values of “Method” argument are allowed:

  • “average”: each merged value is defined as the average of its different contributions.

  • “sum”: each merged value is defined as the sum of its different contributions.

  • “min”: one keeps the smallest value. This option can be used for scalar Results only.

  • “max”: one keeps the largest value. This option can be used for scalar Results only.

  • “NONE”: this option is used when one is sure that no merging of several values is possible.

Note that when vectorial or tensorial Results are merged (“sum” or “average” options, their respective coordinate systems must be identical. Otherwise an error message is issued.

3.

“DB”: a DataBase object used by the method to recover the association of node and elements. This association is often needed to perform the remapping.

The “deriveByRemapping” method can be used with Real as well as Complex Results. Only, for Complex Results, there are some restriction about the type of “Method” argument for merging values: the “min” and “max” values are not accepted for Complex Results.


Table I.4.7: The different “fromTo” arguments for “derivebyRemapping” method.
“fromTo” argument Source target Target key types
“CentersToCorners” Element Centers Element Corners EN**
“CentersToNodes” Element Centers Nodes of Elements -N**
“NodesToCenters” Nodes Element Centers E-**
“NodesToCorners” Nodes Element corners EN**
“CornersToCenters” Element Corners Element Centers E-**
“CornersToNodes” Element Corners Nodes of Elements -N**
“MergeLayers” Layers - EN-*
“MergeLayersKeepId” Layers Layers EN**
“MergeSubLayers” Sub-layers - EN*-
“MergeSubLayersKeepId” Sub-layers Sub-layers EN**
“MergeAll” All keys - —-
“CentersToElemsAndNodes”Element Centers Element Nodes EN**
“CornersToElemsAndNodes”Element Corners Element Nodes EN**
“CentersToCornerNodes” Element CentersElement Corner Nodes -N**
“ElemsAndNodesToCenters” Element Nodes Element Centers -N**
“ElemsAndNodesToNodes” Element Nodes Nodes -N**
“NodesToElemsAndNodes” Nodes Element Nodes EN**

I.4.5 Dyadic derivation method

Presently, only one such method is defined: the “deriveDyadic” method. This method returns a new Result object corresponding to the dyadic derivation. This method has two arguments:

Possible values for the “Method” argument are:

Note that several of the methods above for dyadic derivation have corresponding short-cuts in the “Post” module.

The different methods listed above are available for real Results. For Complex Results, only the methods “vectProduct”, “sumVectProduct”, “merge”, “mergeKeepFirst” and “mergeKeepLast” can be used. Of course, if the ”Second” argument is a Real object, the “deriveDyadic” method cannot be invoked on a Complex Result object.

Note also that all the dyadic derivation methods discussed here are invoked on a Result object which is the first argument. Dyadic derivation methods that allow to replace the first argument by a real or vector object are also defined in the Post module. (See section I.6.3.)

I.4.6 Methods modifying the object

One presents here methods that modify the Result object to which they are applied.

I.4.6.1 Access to and modification of Result data

Each Result object is also characterized by two integer and two real identifiers. Different methods allow to retrieve or modify the Result data.

For the four last methods listed above, the value of index argument can be 0 or 1. Note that several of the methods listed above correspond to the “Name”, “Format” and “TensorOrder” attributes.

All these methods can be used with Real Results as well as with Complex Results.

I.4.6.2 “setRefCoordSys”

setRefCoordSys” is used to attribute a reference coordinate system to the values of a Result. The method has one argument that can have to types:

Note that only the coordinate system ids of the pairs of key and values are modified. The components of the vectorial or tensorial values are left unchanged.

This method can be used with Real Results as well as with Complex Results and returns the modified “Result” object.

I.4.6.3 “renumberLayers”

renumberLayers” is a method used to renumber the layer integer ids of Result keys. The method has one Hash argument corresponding to the pairs of “old integers IDs” and “new integer IDs”.

This method can be used with Real Results as well as with Complex Results and returns the modified “Result” object.

I.4.6.4 “renumberSubLayers”

renumberSubLayers” is a method used to renumber the sub-layer integer ids of Result keys. The method has one Hash argument corresponding to the pairs of “old integers IDs” and “new integer IDs”.

This method can be used with Real Results as well as with Complex Results and returns the modified “Result” object.

I.4.6.5 “removeLayers”

removeLayers” is a method used to remove pairs of key and values selected on the basis of the layer ID of the key. The method has one “LayersList” argument: it is an Array containing the list of layers for which the pairs of key and value must be removed. The elements of the Array argument are integer or String values.

This method can be used with Real Results as well as with Complex Results and returns the modified “Result” object.

I.4.6.6 “removeSubLayers”

removeSubLayers” is a method used to remove pairs of key and values selected on the basis of the layer ID of the key. The method has one “SubLayersList” argument: it is an Array containing the list of sub-layers for which the pairs of key and value must be removed. The elements of the Array argument are integer or String values.

This method can be used with Real Results as well as with Complex Results and returns the modified “Result” object.

I.4.6.7 “modifyRefCoordSys”

modifyRefCoordSys” is used to modify the reference coordinate system wrt which the components of a vectorial or a tensorial Result are applied. If the Result is vectorial it can represent any vectorial quantities except the coordinates. For coordinate vectorial Result, the method “modifyPositionRefCoordSys” must be used. This method has no effect on scalar Results.

The methods returns nil (no new Result object is created) and takes two, three or five arguments:

1.

A DataBase object.

2.

An object corresponding to the definition of the coordinate system to which one switches. This object may have different types:

(a)

A String object with one of the following values: “elemCS”, “nodeCS”, “matCS”, “plyCS”, “elemIJK”, “lamCS”. All those coordinate systems are local to an element or to a node.

More information about the peculiarities of “matCS”, “plyCS” and “lamCS” coordinate system transformations is given in section X.B.5.

(b)

The argument may by a CoordSys object. Then it must be defined wrt a coordinate system defined in the DataBase argument.

(c)

The argument may by a Results object. This should then be a FieldCS Result. (See I.4.1.5.)

(d)

The argument may also be an integer larger than or equal to 0. Then the coordinate system must be defined in the DataBase.

3.

The third argument is the direction vector used to build the projected coordinate system on surfacic elements. The vector is given by an Array of three real objects, and is expressed wrt to the coordinate system given in second argument. If one does not wish to transform into a projected coordinate system, then the third argument must be omitted or nil. (However if arguments 4 and 5 are provided, the third argument cannot be omitted.)

4.

An object corresponding to the definition of the coordinate system from which one switches. This object may have the same values as the second argument.

5.

The last argument is a direction vector used to build the projected coordinate system on surfacic elements. The vector is given by an Array of three real objects, and is expressed wrt to the coordinate system given in second argument. If one does not wish to transform into a projected coordinate system, then the third argument must be nil.

The reason why a DataBase object is given as argument is that for curvilinear coordinate systems, much information about the location of Result value is necessary to perform a correct transformation of the components. Also, all coordinate systems are stored in the DataBase object. Therefore, it is very important that the programmer keeps in mind that all Results are related to a DataBase.

Note that some transformation vectorial or tensorial coordinate systems cannot be reversed. For example, once a Result is expressed in a projected coordinate system. Also, if a conversion has been done in a coordinate system that is not defined in the DataBase, the conversion is impossible. After transformation, the coordinate system referenced in Result values is altered (section I.4.1.2).

If arguments 4 and 5 are provided, the method assumes that the values are expressed in that coordinate system definition. This means that the CsId found in each pair “key-values” pair of the Result object is totally disregarded. The use of arguments 4 and 5 may allow the modification of Results expressed in a user or projected coordinate system.

More information on the transformation of coordinate systems is given in section X.B.4.

This method can be used with Real Results as well as with Complex Results and returns the modified “Result” object.

I.4.6.8 “modifyPositionRefCoordSys” method

modifyPositionRefCoordSys” method is used to modify the reference coordinate system wrt which vectorial Results corresponding to coordinates are expressed. The Results must be vectorial.

The method returns nil (no new Result object is created) and takes two arguments:

1.

A DataBase object.

2.

An integer object corresponding to the index of the coordinate system to which one switches. This index must be larger than or equal to 0 and defined in the DataBase argument. One can also provide a CoordSys object instead of the integer argument.

For the reason of the presence of the DataBase argument, see section I.4.6.7.

This method can be used with real Results only and returns the modified “Result” object.

I.4.6.9 Linear combination of Results

setToCombili” method fills the values of the Result object on which the method is called with the linear combination of the elementary Results given as arguments. The arguments are defined as follows:

1.

An Array of Real values containing the factors of the linear combination.

2.

An Array containing the elementary Results.

The lengths of the two Array arguments must match. Also the type of elementary Results (scalar, vectorial or tensorial) must be identical and the coordinate systems must be the same for a same key.

This method can be used with Real Results as well as with Complex Results. Also, the real factors of the linear combination can be replaced by Complex values. However, all the elements of the Array must be of the same type (Real or Complex).

The “setToCombili” method returns the modified “Result” object.

setToCombiliPerComponent” method fills the values of the Result object on which the method is called with the linear combination of the elementary Results given as arguments. The difference with “setToCombili” method is that the factors of the linear combination are given component-per-component. Practically, the “factors” argument is a 2D Array (Array of Arrays):

I.4.7 Operators

Five elementary operators on Result objects have been defined. Also, their corresponding assignment method have been defined. Unless otherwise specified, in the examples given below, x, y and z are Result objects. One of the two operands can be replaced by a “constant” value in most cases, but at least one of the operands must be a Result object:

By “constant” value, one means a scalar real value, a scalar complex value, a real vector (Array of three real values), a complex vector (Array of three complex elements), or a real matrix (Array of 3 × 3 real values). These arguments can be used in addition, substraction and multiplication operations. Note that no constant complex matrix is supported.

For the division operation, y can be replaced by a scalar real or complex argument, but not by a vector or a matrix. on the other hand, x can be replaced by constant scalar, vectorial or matrix, real or complex (except for the matrix).

For the exponentiation operator, the two Results must be scalar. Either x or y can be replaced by a constant real value.

One can make a few general remarks:

The support for Complex Result operators depends on the type of dyadic operation. See the sub-sections below for more information.

I.4.7.1 Addition operator

The addition operator can be used as follows:

z = x + y.

In the previous expression, the Results x and y must have the same tensorial order. Of course, the returned z object is also of the same tensor order as x and y.

I.4.7.2 Substraction operator

The substraction operator can be used as follows:

z = x - y.

In the previous expression, the Results x and y must have the same tensorial order. Of course, the returned z object is also of the same tensor order as x and y.

I.4.7.3 Multiplication operator

The multiplication operator can be used as follows:

z = x * y.

The meaning of this operation depends on the tensorial orders of x and y. The various possibilities are summarized in Table I.4.8 with a short explanation of the meaning of the operation when deemed necessary.


Table I.4.8: Possible arguments of the Result multiplication operator, returned value, and meaning of the operation.
zxy meaning
S S S
V S V
M S M
V V S
S V V scalar product of two vectors
V V M left multiplication of a matrix by a vector
M M S
V M V right multiplication of a matrix by a vector

I.4.7.4 Division operator

The division operator can be used as follows:

z = xy.

In the last expression x can have any tensorial order. The tensorial order of the returned Result z is identical to the tensorial order of x. The argument y can be either a scalar Result object, or a real value.

Complex Results are partially supported by the division operator. The limitations of the operator for complex arguments are the same as for the multiplication operator.

I.4.7.5 Exponent operator

The exponentiation operator can be used as follows:

z = x **y.

In the last expression x must be a scalar Result. The tensorial order of the returned Result z is identical to the tensorial order of x. The argument y can be either a scalar Result object, or a real value. Complex Results cannot be arguments to this operator. The real values of first Result argument must also be positive.

The three following expressions are equivalent:

            z=x**y
            z=Post.pow(x,y)
            z=Post.opPow(x,y)

I.4.8 “calcResultingFM” method

calcResultingFM” method is a class method used to estimate the total force and moment corresponding to a distribution of forces and moments on several points. The method has between 4 and 6 arguments:

1.

A DataBase object containing the model used to calculate the total forces and moments.

2.

A first Result object corresponding to the vectorial forces.

3.

A second Result object corresponding to the vectorial moments.

4.

An object corresponding to the coordinate system in which results and position of recovery point are expressed. If the argument is an integer, it must correspond to the index of a CoordSys object defined in the dataBase. The argument can also be a CoordSys object, but its definition must refer a coordinate system defined in the dataBase.

5.

A vector (Array of three real values) corresponding to the position of the point wrt which the total force and moment are calculated. The position of the point is defined wrt the coordinate system corresponding to the previous argument. (This may different than what other post-processing tools like Patran do.)

6.

A Result object corresponding to the coordinates of the connections that are used to estimate the global moment. (See additional remarks below.)

Note that the two last arguments are optional:

The sixth parameter containing the coordinates must be associated to the same Result keys as the forces Result. The parameter can be very useful when the forces are not associated to nodes. This is, for example, the case when the forces correspond to CBUSH element forces. For example, let us assume that the coordinate Results have been generated in the database:

        db.generateCoordResults("COORDS","COORDS","coords")

The coordinates corresponding to the forces can be obtained as follows:

        coords=db.getResultCopy("COORDS","COORDS","coords",forces.extractRkl())

And the global force and moment calculated as follows:

        fm=Result::calcResultingFM(db,forces,moments,csId,nil,Coords)

If argument Results are in Real format, the method returns an Array containing two vectors (i.e. two Arrays of Real objects). These vectors correspond to the total force and total moment respectively. Note that the method produces no new Result object.

If argument Results are Complex, the method returns an Array containing two Complex vectors (i.e. two Arrays of Complex objects). Note However that the Complex values in the resultants are always given in rectangular format (real and imaginary parts). This is true even when the argument Results are in polar (magnitude-phase) format.

I.4.9 Complex Results

Several methods correspond to operations specific to complex Results. These methods are described below.

I.4.9.1 Rectangular-Polar conversions

Two methods allow to tranform Complex Results expressed in real-imaginary format to magnitude-phase format, and reversely:

For these two methods, no complex conversion is performed if the Result is already in the requested format.

I.4.9.2 Conjugate Complex Result

conjugate” produces a Result by initializing its values to conjugate of other values (z z¯). The method has 0 or 1 argument. If the method has one argument, the object on which the method is called is set to the rectangular complex values of its argument. Otherwise, the object on which the methods is called is modified. Note that the method can also be called on a Real Result but has then no effect.

I.4.9.3 Rotation of Complex Result

The method “rotateBy” is used to modify the values of a Complex Result by adding an angle specified in degrees to the corresponding phases. However, the method can be used indifferently with Complex Results in rectangular or in polar formats. The method may have one or two arguments:

Note that the rotation is done by multiplying the Result by a Complex value obtained as follows:

z = eiθ = cos θ + i sin θ.

Angle θ is always given in .

I.4.9.4 Extractions from Complex Results

Four methods produce Real Results from Complex Results by extracting the appropriate components:

These methods must be called on Complex Results. The polar or rectangular format of the Complex Results does not matter: if needed a polar-rectangular conversion of the components is done before the extraction.

The two methods “getR” and “getI” may have an optional Real argument that corresponds to a rotation applied to the Result before extracting the Real or Imaginary component Result. More precisely, each component of each value is multiplied by eiθ before extracting the real or imaginary component. Angle θ is always given in . Note that the Result on which the method is called is left unmodified.

I.4.9.5 Assembling Complex from Real Results

The “assembleComplex” method is used to assemble a Complex Result object from two Real Results. The method is called on a Result object and has three arguments:

1.

An integer corresponding to the format of the new Complex Result. The accepted values are 2 (real-imaginary or rectangular format) or 3 (polar or magnitude-phase format).

2.

A first Result object that will correspond to the real or magnitude components of the assembled Result.

3.

A second Result object that will correspond to the imaginary of phase components of the assembled Result.

Note that the two Result arguments must satisfy several requirements:

An example of valid (but not very useful) call to “assembleComplex” follows:

    resR=res2.getR
    resI=res2.getI

    resRI=Result.new
    resRI.assembleComplex(2,resR,resI)

(At the end, resRI should be the same as res2.)

I.4.10 “getData”

The getData method returns an Array of Arrays containing the data stored in a Result object. The returned Array may actually be considered as a two-dimensional Array with as many lines as there are pairs of key-value in the Result object. Each line of the Array contains 6, 8 or 11 elements:

1.

The first element corresponds to the elemId.

2.

The second element corresponds to the nodeId of the key.

3.

The third element corresponds to the layerId of the key.

4.

The fourth element corresponds to the subLayerId of the key.

5.

The fifth element corresponds to the coordinate system in which the value components are associated. The possible values are summarized in Table I.4.9.

6.

The other elements are real values corresponding to the components (1, 3 or 6 values for a scalar, vectorial or tensorial Result respectively). For the precise meaning of the returned value corresponding to coordinate system, see also section I.4.1.2.

The method may have 5, 4, 3, 2, 1 or no argument. The arguments correspond to the type of the Array elements corresponding to elemId, nodeId, layerId, subLayerId or coordSysId. In the returned Array, these elements may be of String or Integer types. Correspondingly the arguments are Strings the value of which can be "int", "string" or any other String. If any other String is used as argument (for example a void string), the default Integer or String type elements are returned.

For element, node and layer ids, the negative values correspond to “special” values. (See Tables I.4.2 to I.4.4.)


Table I.4.9: Correspondence between the integer in C++ “value” class and the value returned by Result member method “getData”.
integer in C++ “value” classreturned value in ruby
-9999 nil
-2000 "userCS"
-1000 "projCS"
-5 "elemIJK"
-4 "plyCS"
-3 "matCS"
-2 "nodeCS"
-1 "elemCS"
any other integer the same integer

I.4.11 “BLOBs”

Result objects can be saved in SQL database as “BLOB” objects.

Two methods are defined in Result class to convert object to and from Blobs:

I.4.12 Iterators

Three iterators are defined in the class:

For the meaning of the arguments, see more information in section I.4.10. One difference between the “each” iterator and the getData method is that the key and values elements are separated into two Arrays in the block. So the iterator is to be used as follows:

    strain.each("int","int","int") do |key,values|
        ...
    end
    ...
    strain.each("int","int","string","string") do |key,values|
        ...
    end

Note that, as the “each_key” and “each_values” iterators return Arrays, one can indifferently recover an Array argument, or its elements in the arguments of the block that follows the iterator. For example, in the following lines:

    stress.each_key do |stressKey|
        ...
    end

“stressKey” is an Array of three elements. However in the following lines:

    stress.each_key("int","int","int") do |elemId,nodeId,layerId|
        ...
    end

the arguments correspond to the different identifiers of the Result key.

I.4.13 A few singleton (static) methods

Four singleton methods allow to convert layers and sub-layers string/integer IDs:

I.4.14 Other methods

One gives here a list of methods that do not fit in any category listed above.

I.4.14.1 “new”

new” method is used to create a new Result object.

I.4.14.2 “initialize”

initialize” method initializes or clears a Result object.

I.4.14.3 “clone”

clone” method returns a Copy of the Result object to which it is applied.

I.4.14.4 “cloneNoValues”

cloneNoValues” method returns a Copy of the Result object to which it is applied, except that no values are inserted. Practically, it means that one copies attributes like the name, the tensor order, the format...

I.4.14.5 “initZeroResult”

initZeroResult” method is used to initialize a Result with zero values using the keys of an existing Result object. The Method has four arguments:

1.

A String corresponding to the Name of the Result.

2.

An integer corresponding to the tensor order (0, 1 or 2).

3.

An integer corresponding to the Format of the Result.

4.

A Result object that provides the keys to which the zero values of the new Result object will be associated.

The method returns the Result object on which it has been called.

I.4.14.6 “Size” attribute

Size” returns an integer containing the numbers of pairs “key-value” contained in the Results object. This method has no argument. It corresponds to the “Size” read-only attribute.

I.4.14.7 “to_s”

to_s” method is used for printing the Result object.

Chapter I.5
The “ResKeyList” class

A ResKeyList object is basically a set of Result keys (see Chapter I.4). Actually, a ResKeyList object is a kind of Result with no values associated to the keys.

One shows in section I.4.3 that several methods of class Result allow to build ResKeyList objects from Results, and to extract Results from other Results using ResKeyList objects.

A list of the methods defined in “ResKeyList” class is given in Table I.5.1.

Table I.5.1: The different methods that have been defined in “ResKeyList” class. Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
Method Name DescriptionExample
Creation and initialization
new (s) I.5.1 IV.2.5.1
initialize I.5.1
clone I.5.1
insert I.5.1
getData I.5.6
Size I.5.7
Identification
Name= I.5.7
Name I.5.7
Extractions
extractLayers I.5.2
extractSubLayers I.5.2
extractGroup I.5.2
Layers and sub-layers manipulation
renumberLayers I.5.3.1
renumberSubLayersI.5.3.2
removeLayers I.5.3.3
removeSubLayers I.5.3.4
Operators
+ I.5.4
- I.5.4
* I.5.4
/ I.5.4
Iterators
each_key I.5.5
Printing
to_s I.5.7
Attributes
Name I.5.7
Size I.5.7 (read only)

I.5.1 Creating and filling ResKeyList object

The usual “new” and “initialize” singleton methods are defined in the ResKeyList class. These methods have no arguments. The class member method “clone” has no argument and returns a copy of the object.

The user can fill its one ResKeyList object with the “insert” method. This method takes one Array Argument with between 1 and 4 elements corresponding to the element identifier, the node identifier, the layer identifier and the sub-layer identifier. Each element can be a String or an integer.

I.5.2 Extraction functions

Two extraction functions have been defined:

These methods have no arguments.

I.5.3 Methods modifying the object

The two methods described below correspond with the methods with identical names defined in “Result” class.

I.5.3.1 “renumberLayers” method

renumberLayers” is a method used to renumber the layer integer ids of ResKeyList keys. The method has one Hash argument corresponding to the pairs of “old integers IDs” and “new integer IDs”.

I.5.3.2 “renumberSubLayers”

renumberSubLayers” is a method used to renumber the sub-layer integer ids of ResKeyList keys. The method has one Hash argument corresponding to the pairs of “old integers IDs” and “new integer IDs”.

I.5.3.3 “removeLayers”

removeLayers” is a method used to remove keys selected on the basis of the layer ID of the key. The method has one “LayersList” argument: it is an Array containing the list of layers for which the keys must be removed. The elements of the Array argument are integer or String values.

I.5.3.4 “removeSubLayers”

removeSubLayers” is a method used to remove keys selected on the basis of the layer ID of the key. The method has one “SubLayersList” argument: it is an Array containing the list of sub-layers for which the keys must be removed. The elements of the Array argument are integer or String values.

I.5.4 Dyadic operators

Eight such operators have been defined. One first explains the meaning and behavior of the four elementary dyadic operations.

I.5.5 Iterators

One “each_key” iterator is defined in the class: it iterates on the data and produces Arrays of three elements corresponding to keys. The iterator may have between 0 and 4 arguments argument. The arguments are Strings that specify whether some of the data are to be returned in String or integer format.

Actually, the “each_key” iterator of ResKeyList class is identical to the “each_key” iterator of Result class.

I.5.6 “getData” method

getData” method returns an Array of Arrays containing the data stored in a ResKeyList object. The returned Array may actually be considered as a two-dimensional Array with as many lines as there are pairs of keys in the ResKeyList object. Each line of the Array contains four elements:

1.

The first element corresponds to the elemId.

2.

The second element corresponds to the nodeId of the key.

3.

The third element corresponds to the layerId of the key.

4.

The fourth element corresponds to the subLayerId of the key.

The method may have 4, 3, 2, 1 or no argument. The arguments correspond to the type of the Array elements corresponding to elemId, nodeId, layerId or subLayerId. In the returned Array, these elements may be of String or Integer types. Correspondingly the arguments are Strings the value of which can be "int", "string" or any other String. If any other String is used as argument (for example a void string), the default Integer or String type elements are returned.

Actually, this method corresponds to the “getData” method of Result class (See section I.4.10). The special key names are the same as those listed in Tables I.4.2 to I.4.4.

I.5.7 Other methods

One gives here a list of methods that do not fit in any category listed above:

Chapter I.6
The “Post” module, and other topics...

The “Post” module contains the definition of methods belonging to no particular class. These methods are all devoted to manipulation of Results or Groups.

A list of the methods defined in “Post” module is given in Table I.6.1.

Table I.6.1: The different methods that have been defined in “Post” module.
(FeResPost list of classes is given in Table 1 page 11.)
Method Name DescriptionExample
Manipulation of FeResPost standard output
setInfoStreamToKeep I.6.1
setInfoStreamToNone I.6.1
setInfoStreamToClientStream I.6.1
setInfoStreamToCppStream I.6.1
setInfoStreamToCppFile I.6.1
getInfoStreamContent I.6.1
clearInfoStreamContent I.6.1
getAndClearInfoStreamContentI.6.1
writeAboutInformation I.6.1
writeMsgOutputLine I.6.1
Monadic functions for new Result creation
exp I.6.2
log I.6.2
exp10 I.6.2
log10 I.6.2
abs I.6.2
inv I.6.2
sq I.6.2
sqrt I.6.2
sgn I.6.2
Dyadic functions for new Result creation
min I.6.3
max I.6.3
cmp I.6.3
merge I.6.3
mergeKeepFirst I.6.3
mergeKeepLast I.6.3
pow I.6.3
atan2 I.6.3
vectProduct I.6.3
sumVectProduct I.6.3
Dyadic operator functions
opAdd I.6.4
opSub I.6.4
opMul I.6.4
opDiv I.6.4
opPow I.6.4
Groups and Patran session files
readGroupsFromPatranSession I.6.5 I.6.5
writeGroupsToPatranSession I.6.5 I.6.5
Control of verbosity for debugging purposes
setVerbosityLevel I.6.6
getVerbosityLevel I.6.6
Conversion of CLA identifiers
convertIdfierToString I.6.7
convertStringToIdfier I.6.7
BLOBs for SQL
convertBlob I.6.8
Random
calcRandomResponse I.6.9 IV.2.4.7
Predefined criteria
calcPredefinedCriterion I.6.10IV.2.4.3 and chapter X.E.4
Loading the HDF5 shared library
loadHdf5Library I.6.11
Exceptions
getLastErrorMessage I.6.12

I.6.1 Manipulation of FeResPost standard output

Several methods of “Post” Module allow to manipulate the information and warning messages issued by FeResPost. In C++ code, the messages are saved into a C++ ostrstream object. At the end of each FeResPost method, the content of this stream is flushed into the the output selected by the client. Several methods allow to control how information and warning messages are output:

The default standard output generally corresponds to clients (ruby, in this case) standard output. This selection is done when FeResPost library is loaded.

The redirection of standard output is useful when FeResPost is not run in “console” mode. Moreover, it is sometimes handy to separate the outputs of FeResPost from those of the ruby post-processing program. Two methods allow adding content in the selected output stream:

I.6.2 Monadic functions for new Result creation

In section I.4.4, one defines functions that allow the creation of new Result objects from existing ones. Here, one present short-cuts to some of these functions (for the following functions, x and y are Result objects):

I.6.3 Dyadic functions for new Result creation

In section I.4.4, one defines functions that allow the creation of new Result objects from existing ones. Here, one present short-cuts to some of these functions (for the following functions, x, y and z are Result objects):

Also other functions that have no correspondence in Result class methods can be used to define new Results

Most of the dyadic functions insert a pair “key-value” in the created Result only if the corresponding key is found in the two Result arguments. “Post.min”, “Post.max” and the ‘Post.merge” methods are an exception: if a given key is found in only one of the two argument it is inserted in the new Result.

I.6.4 “Operator” methods

Five “operator” methods (functions) are defined in the “Post” module: “opAdd”, “opSub”, “opMul”, “opDiv” and “opPow”. The four first methods correspond to the four “+”, “-”, “*” and “/” operators defined in “Result”, “Group” and “ResKeyList” classes:

The “opPow” method is an alias to the “pow” method and at least one of its arguments must be a “Result” object.

I.6.5 Reading and writing of Groups

Method “readGroupsFromPatranSession” reads Groups from a Patran session file and returns a Hash containing the list of Groups. The keys are Group names, and the values are the Groups. The method has two arguments:

1.

A String corresponding to the name of the session file.

2.

A DataBase. This argument is optional. If it is provided, the reading method removes from the created Groups all the entities undefined in the DataBase argument.

The session file from which Groups are read is as defined in section I.1.2.1. Examples of use of the method follow:

        ...
        h=Post::readGroupsFromPatranSession("groups.ses")
        ...
        h=Post::readGroupsFromPatranSession("groups.ses",DB)
        ...

Method “writeGroupsToPatranSession” is used to save groups in a Patran session file. This method does the inverse of method “Post::readGroupsFromPatranSession”. The method has two arguments:

1.

The first argument of the method is a String containing the name of the output session file.

2.

The second argument if the list of Groups. This can be a Hash similar to the one produced by method “Post::readGroupsFromPatranSession”, or an Array of Group objects.

When the second argument is a Hash, the String keys are used as reference names for the groups. If the second argument is an Array of Groups, their names are used in the session file.

The following statements:

        ...
        h=Post::readGroupsFromPatranSession("groups.ses")
        ...
        Post::writeGroupsToPatranSession("hash.ses",h)
        Post::writeGroupsToPatranSession("values.ses",h.values)
        ...

produce equivalent Patran session files, but the order in which the Groups are defined may differ.

I.6.6 Setting verbosity for debugging purposes

Two methods allow to set the verbosity level of several operations. The level of verbosity is a parameter global for FeResPost and may be used to write several information messages during operations in which the risk of inconsistent data has been deemed high. These information messages may be used to debug FeResPost, or your programs using FeResPost. Actually, the majority of programming errors you will find will be related to your own program, but the printing of FeResPost messages may help you to help find your errors. The two methods defined in “Post” Module are:

The verbosity level may presently range from 0 to 2. 0 corresponds to no information messages. The amount of information messages increases with verbosity level.

Presently, the operations influenced by the verbosity level are the operations related to reading finite element models, accessing Results in disk files, Gmsh output...

I.6.7 Conversion of CLA idfiers

Two methods are defined to convert CLA identifiers to Strings, or Strings to CLA identifiers. (See chapter II.0 for the notion of identifier.) The two methods are defined in the “Post” Module:

Examples of valid Strings corresponding to CLA identifiers:

      "testLam",
      "15",
      "[15,testLam]",
      ...

I.6.8 SQL“BLOB” methods

The methods “convertBlob” returns a “Result” or “Group” object corresponding to a String argument. The String must correspond to a valid FeResPost BLOB object produced by method “toBlob” of one of the FeResPost classes.

I.6.9 Random or PSD integration methods

Method “calcRandomResponse” is used to calculate a PSD and/or integrate a PSD and/or a transfert function. We summarize here the theoretical background extracted from [Sof10] that is necessary to understand what the method does. Reader is referred to [Sof10] for more information.

The purpose of a random calculation is to assess structural response as power spectral density assuming that structure behavior to a given type of excitation is known by its transfert function, and that the excitation is specified as an input power spectral density (PSD).

More precisely, one assumes that a unique excitation a is present, and one calculates the response at output location j:

Sja = |Hja| 2S a.

In previous expression:

Note that the input and output PSD have always positive real values for all components.

Once a PSD is calculated, an equivalent RMS output can be calculated as follows:

u¯j = 0Sja(f)df.

Practically, FeResPost calculates the integral on a finite range of frequencies:

u¯j = f minfmaxSja(f)df.

Practically, the transfert function is known by its values at different frequencies fi, i = 1...N. Then the integrations above are replaced by integrations on smaller frequency ranges:

0S ja(f)df i=1N-1fifi+1 Sja(f)df.

Assuming a log-log dependence of Sja(f) between fi and fi+1, one has

Sja(f) = Sja(fi) fiα fα with f i < f < fi+1,

in which

α = log (Sja(fi+1)Sja(fi)) log (fi+1fi) .

The integral in range [fi,fi+1] is then calculated by:

If one assumes that function Sja(f) varies linearly between fi and fi+1, then the integral in range [fi,fi+1] becomes simply:

fifi+1 Sja(f)df = (Sja(fi) + Sja(fi + 1)) (fi+1 - fi) 2 .

Note that in Nastran, the assumption of log-log or linear interpolation on each frequency interval is managed by the option RMSINT. In FeResPost , the “integTyp” parameter of method “calcRandomResponse” allows choosing the type of integration. (See below.)

“calcRandomResponse” method in “Post” Module can be used to calculate output PSD from a transfert function, to integrate the PSD, and/or calculate the RMS value. The method is called as follows:

        ...
        arr=Post.calcRandomResponse(bOutputPsd,bOutputIntPsd,
            inputResults,freqs,psdIn,integType,addRes)
        psdOut=arr[0]
        intPsdOut=arr[1]
        rms=arr[2]
        ...

The method has 6 or 7 arguments:

1.

bOutputPsd” is a logical parameter that specifies whether the output PSD must be returned by the method.

2.

bOutputIntPsd” is a logical parameter that specifies whether the integration of the output PSD at each frequency must be returned by the method. (If one does not require the value at each frequency, only the last value is returned.)

3.

inputResults” is an Array of Result objects containing the transfert function Hja (complex Result) or only its magnitude |Hja| (Real result).

4.

freqs” is an Array of real values corresponding to the frequencies at which the transfert function and input PSD have been discretized. The size of this array must correspond to the size of the “inputResults” Array.

5.

psdIn” is an Array of real values corresponding to the input PSD level (excitation) at discretization frequencies. The number of elements in this Array must match the number of elements in “inputResults” and “freqs” Arrays.

6.

integType” is a String that specifies the interpolation and integration rule on frequency intervals. Possible values are “LogLog” or “LinLin”. If another value is provided, “calcRandomResponse” raises an exception.

7.

addRes” is a Real Result that must be considered as the initial value from which the integration of output PSD starts. (This parameter can be very useful when integration is “sliced” on sub-ranges of the entire frequency range.) If no starting value is specified, parameter can be omitted. If parameter is “nil”, one also considers that no starting value is specified.

Note that the different Result arguments must have the same size and keys. The method returns an Array of 3 elements:

1.

The first element corresponds to the output PSD. It is an Array of Result objects that is filled if “bOutputPsd” argument is true. Otherwise, “nil” is returned.

2.

The second element corresponding to the integrated output PSD:

  • If “bOutputIntPsd” is true, then this element is an Array of Result object corresponding to the integration at each frequency.

  • If “bOutputIntPsd” is false, then this element is a Result object corresponding to the last value of the integrated output PSD.

Note that the optional “addRes” parameter defines the start for the integration.

3.

The third output corresponds to the RMS value of the output PSD. This is a Result object. Practically, the components of the output RMS are calculated as the square root of the corresponding component of the integrated output PSD. (Or the last value of the integrated output PSD, if “bOutputIntPsd” is set to “true”.)

I.6.10 Predefined criteria

Method “calcPredefinedCriterion” allows to calculate a pre-defined criterion “hard-coded” in C++. The parameters of the method are:

The method returns an Array of “OutputValues” similar to the Array of input arguments.

Note that the arguments that are passed by reference in function calcPredefinedCriterion can be modified in the predefined criterion. Each predefined criterion should be documented, and the possible side effects of the method should be clearly explained.

Some advantages of using predefined criteria are listed below:

Of course, the adoption of pre-defined criteria has also some disadvantages:

So far, only a limited number of predefined criteria have been included in FeResPost. They are presented in Appendix X.C.2.

I.6.11 Loading HDF5 library

Method “loadHdf5Library” is used to load the HDF5 shared library. It is simply used as follows:

    Post.loadHdf5Library("C:/NewProgs/HDF5/HDF5-1.8.20-win32/bin/hdf5.dll")

This method has been introduced in the “Post” Module, even though it is presently used only as prelude to loading results from HDF5 files in Nastran Database. We hope actually that other solves like Samcef will have the good idea to use this file format for their results.

I.6.12 Exceptions

When something wrong happens, FeResPost raises an exception with a message providing some information about the problem. Exception information can be displayed, for example, by the following code:

    begin
        db.readBdf("unit_xyz_V1.bdf",["../../MODEL/MESH/"],"bdf",{},true)
    rescue Exception => x then
        printf("\n\nMaybe you should modify the two first include statements in main file!\n")
        printf("**********************************************************************\n\n")

        printf("We have an exception with the following information:\n\n")
        puts x.message
    end

Method “getLastErrorMessage” of the “Post” module retrieves the message associated to last exception raised by FeResPost.

Chapter I.7
Arguments coercion for “Result” class operators

This chapter concerns the ruby extension only!

One class and some ruby methods are directly defined in ruby language. This part of the programming concerns the operators in which the second argument is a “Result” object, but the first argument has another type (Real, Complex, Array...). Then, a ruby type coercion is performed thanks to the “Result” class “coerce” method. This small part of code allows to perform the operations using the different “Post.op???” methods.

It seems that the built-in “Array” class defines its own “coerce” method, which conflicts with the “Result” coerce mechanism. Therefore, a modification of the “Array” class is restored in version 4.4.4 of FeResPost. (See below.)

This part of FeResPost is programmed in the “FeResPost.rb” file. content looks as follows:

# encoding: utf-8

require "FeResPost.so"

module FeResPost
    class ROpResult
        @x=nil
        def initialize(res)
            @x=res
        end
        def +(other)
            return Post.opAdd(other,@x)
        end
        def -(other)
            return Post.opSub(other,@x)
        end
        def *(other)
            return Post.opMul(other,@x)
        end
        def /(other)
            return Post.opDiv(other,@x)
        end
        def **(other)
            return Post.pow(other,@x)
        end
    end
    class Result
        def coerce(x)
            [ROpResult.new(self),x]
        end
    end # Result
end # FeResPost

class Array
    alias _FeFesPost_old_opAdd +
    alias _FeFesPost_old_opSub -
    alias _FeFesPost_old_opMul *
    def +(second)
        if second.class==Result then
            return Post.opAdd(self,second)
        else
            return self._FeFesPost_old_opAdd(second)
        end
    end
    def -(second)
        if second.class==Result then
            return Post.opSub(self,second)
        else
            return self._FeFesPost_old_opSub(second)
        end
    end
    def *(second)
        if second.class==Result then
            return Post.opMul(self,second)
        else
            return self._FeFesPost_old_opMul(second)
        end
    end
    def /(second)
        if second.class==Result then
            return Post.opDiv(self,second)
        else
            raise "Invalid second operand for / operator"
        end
    end
end # Array
                                                                                      

                                                                                      

puts "End \"FeResPost\" module initialization.\n"
puts "\n\n"

Part II
Composite Reference Manual

Chapter II.0
Introduction

Four classes specific to Classical Laminate Analysis calculations have been defined in FeResPost module:

Throughout the composite manual pages, the concept of identifier is often used. An identifier can be:

This concept is introduced to provide a general way to identify and access materials, laminates or loads stored in a ClaDb object. Indeed, the methods used to access those data must be compatible with several software (ESAComp or finite element solvers...). As entities manipulated by these software are sometimes identified by integers, sometimes by strings and sometimes by both an integer and a String, this peculiar way to identify the entities in a ClaDb object had to be developed. For example, if a ClaLam object has been stored in a ClaDb, it can be retrieved with:

   ...
   db.insertLaminate(lam1)
   ...
   lam2=db.getLaminateCopy(5)
   ...
   lam2=db.getLaminateCopy("panel1")
   ...
   lam2=db.getLaminateCopy([5,"panel1"])
   ...

Note however that the identifier used to retrieve lam2 must match exactly the identifier of lam1. For example, if lam1 has [5,"panel1"] identifier, only the third “getLaminateCopy” statement works.

This leads us to a last remark about interfaces with other software. The composite classes are meant to be used with the rest of FeResPost. Among other things, it allows:

The composite capabilities programming is based on the Classical Laminate Analysis as presented widely in literature. The programmer based its developments on [Gay97]. For the in-plane and flexural parts of laminate response, the approximations done in the development of equations are common to what has been found in the rest of literature. On the other hand, few references have been found about the out-of-plane shear behavior of laminates. In [Gay97], this aspect of laminate analysis is presented with a few assumptions. For example, Gay assumes a mirror symmetry of the laminate. This is obviously not a characteristic of all laminates. Therefore, the out-of-plane shear responses calculated by composite classes should be used with care.

More information about the conventions used for FeResPost composite calculations are given in Chapter II.1.

II.0.1 Remarks and limitations

One presents below a list of limitations, which should not be considered as exhaustive:

1.

When a mechanical loading is applied to a laminate, this loading is also characterized by an angle λ giving the orientation of the loading wrt the laminate. Then the definition of the loading angle λ follows the same conventions as the ply angle ξ represented in Figure II.1.2. This convention for the definition of loading angle may be different of conventions used in other software. For example, ESAComp seems to consider that the angle provided for loading is the angle of the laminate wrt loading. This results in a change of sign of the corresponding angle.

2.

As the composite classes are under development, modifications of ruby functions related to the composite classes are still possible (and likely).

Chapter II.1
Theoretical background

The purpose of this Chapter is to summarize the classical laminate theory, and to provide the information needed by the user of composite classes to understand a few conventions that have been assumed for the programming of Classical Laminate Analysis in FeResPost (axes, angles, numbering of layers,...).

The programmer will find a presentation of the classical laminate theory that follows closely what is programmed in C++ language in FeResPost. However those who are interested in studying the theory, or who are not familiar with it are referred to more extensive presentations of the classical laminate theory [Gay97Pal99]. Only for the out-of-plane shear behavior of the laminate, is the presentation original, even though inspired by information found in [Sof04a].

The Chapter is organized as follows:

II.1.1 Conventions

Figure II.1.1 represents some of the conventions used for the definition of laminate in FeResPost. The laminate coordinate system is defined in such a way that the z axis is perpendicular to laminate surface and points from bottom to top surface. x and y vectors are parallel to the laminate plies. Plies are numbered from the bottom to the top surface. If k is the index of a ply, one considers that it is limited by z coordinates zk-1 and zk. The origin of the coordinate system is located at mid laminate thickness so that if t is the laminate total thickness and the laminate has N plies, top surface of the laminate is located at zN = +t2 and bottom surface at z0 = -t2. (The plies are numbered from 1 to N.)


PICT

Figure II.1.1: Conventions for the numbering of plies in a laminate and for the definition of the laminate coordinate system. (A six plies laminate is represented.)

In the laminate, the plies are characterized by their material, thickness and by their angle in the laminate. Figure II.1.2 shows the convention for the orientation of a ply in a laminate. 1, 2 and 3 are the ply axes; x, y and z are the laminate axes. Of course, because only 2D laminates are considered here, one has always z = 3. If ξ is the angle of the ply in the laminate, this angle is as represented in Figure II.1.2: a positive angle corresponds to a rotation from axis x to axis y. If the angle is 0, the first ply axis 1 is parallel to the first laminate axis x.


PICT

Figure II.1.2: Conventions for the orientation of plies in the laminate.)

II.1.2 Rotation in XY plane and algebraic notations

One common operation in classical laminate analysis is to rotate vectors, tensors and matrices. One summarizes here the operations one uses in the rest of this Chapter and in FeResPost. This rotation is represented in Figure II.1.3.


PICT

Figure II.1.3: Rotation of angle θ around the origin in O12 plane.

II.1.2.0.1 Rotation of base vectors

For such a rotation, the vectors ex and ey are expressed as a function of e1 and e2 as:

( ex ey ) = ( cos θ sin θ - sin θ cos θ ) (e1 e2 ) .

To simplify the notations, one introduces the symbols c = cos θ and s = sin θ. Also, one prefers to write the more general 3D version of the transformation:

( ex ey ez ) = ( c s0 - s c 0 0 01 ) (e1 e2 e3 ) .
(II.1.1)

The inverse relation corresponds to a rotation of angle - θ and is obtained by changing the signs of the sinuses in the rotation matrix:

( e1 e2 e3 ) = ( c - s0 s c 0 0 0 1 ) (ex ey ez ) .
(II.1.2)

II.1.2.0.2 Transformation of vector and tensor components

The expressions (II.1.1) and (II.1.2) can be used to transform the components of vectors. For example:

( V x V y V z ) = ( c s0 - s c 0 0 01 ) (V 1 V 2 V 3 ) .
(II.1.3)

For the transformation of 2D tensors, the transformation matrix is used twice. For example, a Cauchy stress tensor is transformed as follows:

( σxxσxyσzx σxyσyyσyz σzxσyzσzz ) = ( c s0 - s c 0 0 01 ) (σ11σ12σ31 σ12σ22σ23 σ31σ23σ33 ) (c - s0 s c 0 0 0 1 ) .
(II.1.4)

II.1.2.0.3 Matricial notations

As the Cauchy stress tensor is symmetric, expression (II.1.4) is more conveniently written in a matricial form as follows:

( σxx σyy σzz τyz τzx τxy ) = ( c2 s200 0 2cs s2 c200 0 - 2cs 0 0 10 0 0 0 0 0 c - s 0 0 0 0s c 0 - cscs00 0 c2 - s2 ) (σ11 σ22 σ33 τ23 τ13 τ12 ) .
(II.1.5)

The same expression applies to the components of the strain tensor, which is also symmetric:

( ϵxx ϵyy ϵzz ϵyz ϵzx ϵxy ) = ( c2 s200 0 2cs s2 c200 0 - 2cs 0 0 10 0 0 0 0 0 c - s 0 0 0 0s c 0 - cscs00 0 c2 - s2 ) (ϵ11 ϵ22 ϵ33 ϵ23 ϵ13 ϵ12 ) .

However, unfortunately, the classical laminate analysis is universally written using angular shear components for the strain tensor:

γij = 2ϵij(ij).

Using the angular components, the matricial expression to be used for the rotation becomes:

( ϵxx ϵyy ϵzz γyz γzx γxy ) = ( c2 s2 00 0 cs s2 c2 00 0 - cs 0 0 10 0 0 0 0 0 c - s 0 0 0 0s c 0 - 2cs2cs00 0 c2 - s2 ) (ϵ11 ϵ22 ϵ33 γ23 γ13 γ12 ) .
(II.1.6)

An interesting aspect of the transformations (II.1.5) and (II.1.6) is that one can apply the transformation separately on sub-groups of components:

This contributes to justify some of the simplifications of the classical laminate analysis; among others, the decoupling of in-plane and flexural deformation of the laminate on one hand from the out-of-plane shear on the other hand. The third direction is systematically neglected: σ33 = ϵ33 = 0. The inverse of relation (II.1.7) is obviously;

( σ11 σ22 τ12 ) = ( c2 s2 - 2cs s2 c2 2cs cs - csc2 - s2 ) (σxx σyy τxy ) ,
(II.1.9)

( ϵ11 ϵ22 γ12 ) = ( c2 s2 - cs s2 c2 cs 2cs - 2csc2 - s2 ) (ϵxx ϵyy γxy )

II.1.2.0.4 Introduction of a short notation

In order to simplify the notations, one introduces the following notations:

[T+] (θ) = ( c2 s2 - 2cs s2 c2 2cs cs - csc2 - s2 ) ,

[T-](θ) = ( c2 s2 2cs s2 c2 - 2cs - cscsc2 - s2 ) ,

[T+] (θ) = ( c2 s2 cs s2 c2 - cs - 2cs2csc2 - s2 ) ,

[T-] (θ) = ( c2 s2 - cs s2 c2 cs 2cs - 2csc2 - s2 ) ,

[S-](θ) = ( c - s s c ),

[S+] (θ) = ( c s - s c ).
(II.1.10)

These matrices are not independent. For example:

[T-](θ) = ( [T+] (θ)) -1 = [T +] (-θ),

[T-](θ) = ( [T+] (θ)) -1 = [T +] (-θ),

[T+] (θ) = ( [T+] (θ)) T ,

[S-](θ) = ( [S+] (θ)) T = ( [S +] (θ)) -1 = ( [S +] (-θ)) .

The transformations of the components of strain tensor (II.1.8) and stress tensor (II.1.9) are then written:

{ϵ}xy = [T+] (θ) {ϵ}12,

{σ}12 = [T+] (θ) {σ}xy,

{ϵ}12 = [T-] (θ) {ϵ}xy,

{σ}xy = [T-](θ) {σ}12.

Similarly, for the out-of-plane shear stresses and strains one writes the following relations:

{γs} xy = [S+] (θ) {γs} 12,

{τs} xy = [S+] (θ) {τs} 12,

{γs} 12 = [S-](θ) {γs} xy,

{τs} 12 = [S-](θ) {τs} xy.

II.1.3 Materials and plies

One summarizes in this section a few results that are commonly found in composite literature.

II.1.3.1 Plies

Each ply is defined by:

The orientation of the ply is given by an angle θ.

II.1.3.2 Materials and constitutive equations

When a material is used in the definition of a laminate, assumptions are done about the axes defined in the laminate. Axes 1 and 2 are parallel to the laminate plane and axis 3 is orthogonal to the laminate.

The classical laminate analysis is based on the assumption that the relation between stress and strain tensors is linear. Then, as these two tensors are symmetric, a 6 × 6 matrix contains all the elastic coefficients defining the material:

( σ11 σ22 σ33 τ23 τ13 τ12 ) = ( C1111C1122C1133C1123C1131C1112 C2211C2222C2233C2223C2231C2212 C3311C3322C3333C3323C3331C3312 C2311C2322C2333C2323C2331C2312 C1311C1322C1333C1323C1331C1312 C1211C1222C1233C1223C1231C1212 ) (ϵ11 ϵ22 ϵ33 γ23 γ31 γ12 ) .
(II.1.11)

One shows that, because the peculiar choice of angular strain tensor components, the matrix [Cijkl] containing the elastic coefficients is symmetric. Therefore, the matrix has only 21 independent coefficients. [Cijkl] is the stiffness matrix of the material.

Equation (II.1.11) can be reversed as follows:

( ϵ11 ϵ22 ϵ33 γ23 γ31 γ12 ) = ( c1111c1122c1133c1123c1131c1112 c2211c2222c2233c2223c2231c2212 c3311c3322c3333c3323c3331c3312 c2311c2322c2333c2323c2331c2312 c1311c1322c1333c1323c1331c1312 c1211c1222c1233c1223c1231c1212 ) (σ11 σ22 σ33 τ23 τ13 τ12 ) + ΔT ( α11 α22 α33 α23 α13 α12 ) + ΔH ( β11 β22 β33 β23 β13 β12 ) .(II.1.12)

In expression (12), one added the thermo-elastic and moisture expansion terms in previous expression. They are characterized by CTE and CME tensors noted {αkl} and {βkl} respectively. Note that shear components of these two tensors are angular components. Practically, it does not matter much as most materials have zero shear components for CTE or CME tensors. [cijkl] is the compliance matrix of the material. Obviously [cijkl] = [Cijkl] -1. One often defines laminates with orthotropic materials:

For an isotropic material, the definition of E and either G or ν is sufficient to characterize the material. Then one has:

E1 = E2 = E3 = E,

G12 = G23 = G13 = G,

ν12 = ν23 = ν13 = ν.

E, G and ν satisfy the following relation:

E - 2G(1 + ν) = 0.

Finally, one introduces shorter notations that allow to rewrite expressions (II.1.11) and (12) respectively as follows:

{ϵ} = [c] {σ} + ΔT {α} + ΔH {β},
(II.1.17)

{σ} = [C] {ϵ} -ΔT [C] {α} -ΔH [C] {β}.

One introduces also the “Mechanical Strain Tensor” estimated as follows:

{ϵMech} = [c] {σ}.
(II.1.18)

This new strain tensor differs from the one defined by (II.1.17) by the fact that no thermo-elastic or hygro-elastic contribution is taken into account to estimate its components. It is the strain that corresponds to the actual material stress, when no thermo-elastic or hygro-elastic expansion is considered. This “Mechanical Strain Tensor” is also sometimes called “Equivalent Strain Tensor”.

II.1.3.3 In-plane properties

One considers the properties of the ply in a plane parallel to the laminate. Then the constitutive equation (16) reduces to:

( ϵ11 ϵ22 γ12 ) = ( c1111c1122c1112 c2211c2222c2212 c1211c1222c1212 ) (σ11 σ22 τ12 )+ΔT ( α11 α22 α12 )+ΔH ( β11 β22 β12 ) .
(II.1.19)

The indices in this notation are integers and indicate that the corresponding properties are given in ply coordinate system. The equation (II.1.19) is written more shortly as follows:

{ϵ}ply = [c]ply {σ}ply + ΔT {α}ply + ΔH {β}ply.
(II.1.20)

One introduces in (II.1.20) the material in-plane compliance matrix [c] ply. In order to avoid too complicated notations, one uses the same notations as for the 6 × 6 full material compliance matrix introduced in (II.1.17). This will be done systematically for the in-plane matricial and vectorial quantities in the rest of the document ( [c], [C], {α}, {β}, {ϵ},...

The inverse of expression (II.1.20) is noted:

{σ}ply = [C]ply {ϵ}ply -ΔT [C]ply {α}ply -ΔH [C]ply {β}ply.
(II.1.21)

In (II.1.21) one introduces the in-plane stiffness matrix [C] ply = [c]ply-1.

Plies are characterized by their orientation in the laminate. Let ξ be the angle of the ply in the laminate axes. Then, the laminate axes are obtained by rotating the ply axes by an angle - ξ. Equations (II.1.20) and (II.1.21) are expressed in the laminate coordinate system as follows:

{ϵ}lam = [T+] (-ξ) [c]ply [T+] (-ξ) {σ}lam + ΔT [T+] (-ξ) {α}ply + ΔH [T+] (-ξ) {β}ply,

{σ}lam = [T-](-ξ) [C]ply [T-] (-ξ) {ϵ}lam -ΔT [T-](-ξ) [C]ply {α}ply -ΔH [T-](-ξ) [C]ply {β}ply.(II.1.22)

This leads to the new expression in laminate axes:

{ϵ}lam = [c]lam {σ}lam + ΔT {α}lam + ΔH {β}lam,

{σ}lam = [C]lam {ϵ}lam -ΔT [C]lam {α}lam -ΔH [C]lam {β}lam,

where one introduces new notations for in-plane ply properties rotated by an angle - ξ (in laminate axes):

[c]lam = [T+] (-ξ) [c]ply [T+] (-ξ),
(II.1.23)

{α}lam = [T+] (-ξ) {α}ply,
(II.1.24)

{β}lam = [T+] (-ξ) {β}ply,
(II.1.25)

[C]lam = [T-](-ξ) [C]ply [T-] (-ξ),
(II.1.26)

[C]lam {α}lam = [T-](-ξ) [C]ply {α}ply,

[C]lam {β}lam = [T-](-ξ) [C]ply {β}ply.

When a matrix is transformed as in (II.1.23) or a vector as in (II.1.24), one says that they are rotated with [T+] (-ξ) rotation matrix.

II.1.3.4 Out-of-plane shear properties

One makes developments similar to those in the previous section. The out-of-plane shear constitutive equations are written as follows:

{τs} ply = [g]ply {γs} ply -ΔT [g]ply {αs} ply -ΔH [g]ply {βs} ply,
(II.1.27)

{γs} ply = [g-1] ply {τs} ply + ΔT {αs} ply + ΔH {βs} ply.
(II.1.28)

If ξ is the angle of the ply in the laminate, the previous relations can be written in laminate axes by rotating them by an angle - ξ . For example:

{γs} lam = [S+] (-ξ) {γs} ply,

{τs} lam = [S+] (-ξ) {τs} ply,

{αs} lam = [S+] (-ξ) {αs} ply,

{βs} lam = [S+] (-ξ) {βs} ply,

{γs} ply = [S-](-ξ) {γs} lam = [S+] (ξ) {γs} lam,

{τs} ply = [S-](-ξ) {τs} lam = [S+] (ξ) {τs} lam,

{αs} ply = [S-](-ξ) {αs} lam = [S+] (ξ) {αs} lam,

{βs} ply = [S-](-ξ) {βs} lam = [S+] (ξ) {βs} lam.

Then, one makes consecutive transformations of relations (II.1.27) as follows:

[S+] (ξ) {τs} lam = [g]ply [S+] (ξ) {γs} lam -ΔT [g]ply [S+] (ξ) {αs} lam -ΔH [g]ply [S+] (ξ) {βs} lam, (II.1.29)

{τs} lam = [S+] (-ξ) [g]ply [S+] (ξ) {γs} lam -ΔT [S+] (-ξ) [g]ply [S+] (ξ) {αs} lam -ΔH [S+] (-ξ) [g]ply [S+] (ξ) {βs} lam, (II.1.30)

{τs} lam = [g]lam {γs} lam -ΔT [g]lam {αs} lam -ΔH [g]lam {βs} lam,

where one introduced:

[g]lam = [S+] (-ξ) [g]ply [S+] (ξ).

One says that tensor [g] is rotated by matrix [S+] (-ξ) which corresponds to the expression of the shear stiffness tensor in a new coordinate system obtained by rotating the previous one by an angle - ξ.

The transformation of the out-of-plane shear compliance tensor by the same angle - ξ is made with the same expression as for the stiffness tensor:

[g-1] lam = [S+] (-ξ) [g-1] ply [S+] (ξ).

II.1.4 Thickness and mass of laminate

The total laminate thickness is the sum of the thickness of each of its plies:

tlam = k=1Ne k.

Correspondingly the surfacic mass is given by:

smlam = k=1Nρe k.

And the laminate average density is:

ρlam = smlamtlam.

II.1.5 In-plane and flexural laminate behavior

The classical laminate analysis is based on the assumption that in-plane and flexural behavior of the laminate is not related to out-of-plane shear loading. The corresponding laminate properties can be studied separately. The same remark is true for the load response calculation. In this section, the in-plane and flexural behavior of laminates are studied.

In this section the thermal and moisture expansions are not taken into account. The out-of-plane shear properties and loading of laminates is also discussed in a separate section. One summarizes the results of classical laminate analysis. The reader shall refer to the literature if more information on the developments that lead to these results are needed. In this section, the different equations are written in laminate axes and the corresponding indices are noted x and y.

Laminate compliance and stiffness matrices relate the in-plane forces and bending moments on one hand to the average strain and curvatures on the other hand. Those different quantities are defined as follows:

Note that average strain tensor, as well as the true tensor are not “real” tensors because their shear components (i.e. non-diagonal components are angular components.)

The relations between the four tensors are then given by two equations:

{N }lam = [A]lam {ϵ0} lam + [B]lam {κ}lam,

{M }lam = [B]lam {ϵ0} lam + [D]lam {κ}lam.

One defines below the different matrices and vectors introduced in these equations:

All the new matrices and vectors are obtained by summation of the ply contributions. In order to obtain the ply stiffness matrix in laminate axes [C]lamk and the ply thermo-elastic CTE coefficients in thermo-elastic axes {α} lamk, one uses the transformations (II.1.24) and (II.1.26) respectively. Note however that if a ply is characterized by an orientation θ wrt to laminate axes, the rotation of ply properties must be of an angle - θ.

The laminate compliance matrices [a]lam, [b] lam and [d] lam are obtained by inversion of the 6 × 6 [ABBD] lam matrix:

[ [a]lam [b]lam [b]T lam [d]lam ] = [ [A]lam [B]lam [B]lam [D]lam ] -1,
(II.1.33)

Then the average laminate strain and its curvature tensor can be calculated as follows:

{ϵ0} lam = [a]lam {N }lam + [b]lam {M }lam,

{κ}lam = [b]T lam {N }lam + [d]lam {M }lam.

One often calculates equivalent moduli corresponding to the calculated stiffness matrices A and D. We follow the expressions presented in [Pal99]:

II.1.6 Out-of-plane shear of laminate

One presents one version of the out-of-plane shear theory for laminates based on information found in Chapter 13 of [Sof04a]. Only, one presents here a more general version of the calculation that takes xy and yz components of the out-of-plane shear stress into account at the same time.

II.1.6.1 Out-of-plane shear equilibrium equations

In Chapter 13 of [Sof04a] one considers the equilibrium in direction x of a small portion of the material (Figure II.1.4) of lengths dx and dz respectively:

τxz z + σxx x = 0.

Similarly, the equilibrium of a portion dx of the full laminate is given globally by the expression:

Qxz -Mxx x = 0.

PICT

Figure II.1.4: Out-of-plane XZ shear equilibrium in a laminate (from [Sof04a]).

Then, in Chapter 13 of [Sof04a], developments are done to calculate the relations between Qxz and τxz. All the developments are based on the local x equilibrium relation.

In this document, a more general presentation of the out-of-plane shear behavior of laminates is done. The x and y components of in-plane local equilibrium are written as follows:

σxx,x + τxy,y + τxz,z = 0,
(II.1.34)

τxy,x + σyy,y + τyz,z = 0.
(II.1.35)

Correspondingly, a global equilibrium is expressed by the two equations:

Mxx,x + Mxy,y = Qxz,
(II.1.36)

Mxy,x + Myy,y = Qyz.
(II.1.37)

Those equations shall be developed and will ultimately allow the calculation of τxz and τyz from the global shear Qxz and Qyz.

II.1.6.2 Triangular distribution of in-plane stresses

In most expressions below, the components of tensors are expressed in laminate axes. Therefore, the “lam” underscore is often added to the different quantities used in the equations.

First, one calculates the components of Cauchy stress tensor. However, a few simplifying assumptions shall be done. The strain tensor components are calculated from the laminate average strain tensor and curvature as follows:

{ϵ}lam = {ϵ0} lam + z {κ}lam,

{ϵ0} lam = [a]lam {N }lam + [b]lam {M }lam,

{κ}lam = [b]T lam {N }lam + [d]lam {M }lam.

(The thermo-elastic contributions have been neglected.) In most out-of-plane shear theories presented in the literature, one assumes a decoupling between in-plane load response and out-of-plane shear response. This allows us to neglect a few terms in the equations:

{ϵ0} lam [b]lam {M }lam,

{κ}lam [d]lam {M }lam.

One then writes a simple expression of the in-plane laminate deformation tensor:

{ϵ}lam = {ϵ0} lam + z {κ}lam.

Then, the components of Cauchy stress tensor are given by:

{σ}lam(x,y,z) = [C]lam(z) ( [b]lam + z [d]lam) {M }lam(x,y).
(II.1.38)

In this last expression, the 3 × 3 matrix [C]lam(z) corresponds to the plies in-plane moduli expressed in laminate axes. It depends on z because the components generally change from one ply to another. However, one shall assume that the components of the moduli matrix are constant in each ply.

Note that, in the local and global equilibrium relations (II.1.34) to (II.1.37), only partial derivatives of bending moments and Cauchy stress tensor components appear. One assumes the decoupling between the out-of-plane shear behavior and the absolute bending in laminate. However, as shown by expressions (II.1.36) and (II.1.37), the out-of-plane shear is related to the gradient of bending moment. One derives equation (II.1.38) wrt to x and y:

{ σxx,x(x,y,z) σyy,x(x,y,z) τxy,x(x,y,z) } lam = [C]lam(z) ( [b]lam + z [d]lam) {Mxx,x(x,y) Myy,x(x,y) Mxy,x(x,y) } lam,

{ σxx,y(x,y,z) σyy,y(x,y,z) τxy,y(x,y,z) } lam = [C]lam(z) ( [b]lam + z [d]lam) {Mxx,y(x,y) Myy,y(x,y) Mxy,y(x,y) } lam.

At this point, one no longer needs to assume a dependence of the gradient of bending moments wrt x and y. The same is true for the gradient of Cauchy stress tensor. One also introduces a new notation:

[F ]lam(z) = [C]lam(z) ( [b]lam + z [d]lam) .

Then, the components of Cauchy stress tensor gradient are obtained from the components of bending moments gradient with the following expression:

{ σxx,x(z) σyy,x(z) τxy,x(z) σxx,y(z) σyy,y(z) τxy,y(z) } lam = [ [F ]lam(z) 000 0 0 0 000 000 0 0 0 000 [F ]lam(z) ] {Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam.
(II.1.39)

II.1.6.3 Out-of-plane shear stress partial derivative equations

Note that the global equilibrium equation (II.1.36) and (II.1.37) do not contain the components Mxx,y and Myy,x of the bending moments tensor. Similarly, the local equilibrium equations do not contain the components σxx,y and σyy,x of the Cauchy stress tensor. Then, these components can be considered as nil without modifying the result of the developments. The corresponding lines and columns could be removed from the equations (II.1.39).

Actually, one can do better than that. The local equilibrium equations (II.1.34) and (II.1.35) are rewritten as follows:

{ τxz,z(z) τyz,z(z) } lam = [ - 10 00 0 - 1 0 0 - 1 0 - 1 0 ] {σxx,x(z) σyy,x(z) τxy,x(z) σxx,y(z) σyy,y(z) τxy,y(z) } lam.
(II.1.40)

The substitution of (II.1.39) in (II.1.40) leads to the following expression:

{ τxz,z(z) τyz,z(z) } lam = [ - 10 00 0 - 1 0 0 - 1 0 - 1 0 ] [ [F ]lam(z) 000 0 0 0 000 000 0 0 0 000 [F ]lam(z) ] {Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam.(II.1.41)

This allows to find a new expression of the relation between bending moment gradients and out-of-plane shear stress. One first calculates a new matrix as follows:

[J ]lam(z) = - [100001 0 0 1 0 1 0 ] [ [F ]lam(z) 000 0 0 0 000 000 0 0 0 000 [F ]lam(z) ] .

[J ]lam(z) is a 2 × 6 matrix that relates the out-of-plane shear stress components partial derivatives wrt z to the in-plane bending moment components:

{ τxz,z(z) τyz,z(z) } lam = [J ]lam(z) {Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam.
(II.1.42)

The matrix [J ]lam(z) depends on z for two reasons: because of the triangular distribution of strains through the thickness, and because material moduli depend on plies material and orientation. In a given ply of index k, one has:

[Jk] lam(z) = [J0k] lam + z [J1k] lam,

in which the components of the two matrices [J0k] lam and [J1k] lam are constant. Similarly one can write a polynomial expression for [F ]lam(z) if one splits the definition by plies:

[Fk] lam(z) = [Ck] lam ( [b]lam + z [d]lam) , = ( [Ck] lam [b]lam) + ( [Ck] lam [d]lam) z, = [F0k] lam + [F1k] lamz.

Of course, one has the two relations:

[J0k] lam = - [P1] [ [F0k] lam 000 0 0 0 000 000 0 0 0 000 [F0k] lam ] ,

[J1k] lam = - [P1] [ [F1k] lam 000 0 0 0 000 000 0 0 0 000 [F1k] lam ] .

II.1.6.4 Integration of out-of-plane shear stress equation

The out-of-plane shear stress components are obtained by integration of expression (II.1.42) along the thickness. This leads to:

{ τxz(z) τyz(z) } lam = (z0z [J ] lam(z) dz) {Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam+ { τxz(z0) τyz(z0) } lam.

One assumes zero shear stress along the bottom surface of the laminate. This corresponds to a free surface, or at least to a surface that receives no contact forces in direction x and y. This assumption leads to the following expression:

{ τxz(z) τyz(z) } lam = (z0z [J ] lam(z) dz) {Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam, = [V ]lam(z) {M }lam, (II.1.43)

in which one introduces a new matrix notation:

[V ]lam(z) =z0z [J ] lam(z) dz,

and a new vector notation for the gradient of bending moments:

{M }lam = { Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam.

The new matrix [V ]lam(z) is of course a 2 × 6 matrix.

An explicit expression of the integrated matrix is calculated ply-by-ply, from bottom layer to top layer. If zk-1 z zk:

[V ]lam(z) = [V k] lam(z), =z0z [Jk] lam(z) dz, = [V k] lam(zk-1) +zk-1z [Jk] lam(z) dz, = [V k] lam(zk-1) +zk-1z [J 0k] lam + z [J1k] lam dz, = [V k] lam(zk-1) + [J0k] lam (z - zk-1) + [J1k] lamz2 - z k-12 2 , = [V 0k] lam + [V 1k] lamz + [V 2k] lamz2. (II.1.44)

In expression (II.1.44), one introduced new matrices that are calculated as follows:

[V 0k] lam = [V k] lam(zk-1) - [J0k] lamzk-1 - [J1k] lamzk-12 2 ,

[V 1k] lam = [J0k] lam,
(II.1.45)

[V 2k] lam = [J1k] lam 2 .

Note that the expression above involve the a priori unknown quantity [V k] lam(zk-1). To calculate this expression, one uses the continuity of [V k] lam(z) across ply interfaces:

[V k] lam(zk-1) = [V k-1] lam(zk-1).

This relation corresponds to the continuity of out-of-plane shear stress at each interface between two consecutive plies. One develops the relation as follows.

[V 0k] lam = [V k-1] lam(zk-1) - [J0k] lamzk-1 - [J1k] lamzk-12 2 , = [V 0k-1] lam + [V 1k-1] lamzk-1 + [V 2k-1] lamzk-12 - [J 0k] lamzk-1 - [J1k] lamzk-12 2 , = [V 0k-1] lam + ( [V 1k-1] lam - [J0k] lam) zk-1 + ( [V 2k-1] lam - [J1k] lam 2 ) zk-12. (II.1.46)

The last line of this development allows to calculate recursively the components of [V 0k] lam from bottom ply to top ply. For bottom ply, the condition τxz(z0) = τyz(z0) = 0 leads to the following expressions:

[V 1] lam(z0) = [V 01] lam + [V 11] lamz0 + [V 21] lamz02 = 0.

[V 01] lam = - [V 11] lamz0 - [V 21] lamz02, = - [J01] lamz0 - [J11] lam 2 z02. (II.1.47) Then, it becomes possible to calculate recursively the [V 0i] lam matrices.

One checks easily that the condition τxz(z0) = τyz(z0) = 0 ensures also that τxz(zN) = τyz(zN) = 0. Indeed, one has:

[V ]lam(zN) =z0zN [J ]lam(z) dz, = - [P1] z0zN [ [F ]lam(z) 000 0 0 0 000 000 0 0 0 000 [F ]lam(z) ] dz, = - [P1] [ z0zN [F ]lam(z) dz 000 0 0 0 000 000 0 0 0 000 z0zN [F ]lam(z) dz ].

The last line of previous equation contains twice the integral of [F ]lam(z) along the laminate thickness. One develops this integral as follows:

z0zN [F ]lam(z) dz =z0zN [C]lam(z) ( [b]lam + z [d]lam) dz, = (z0zN [C]lam(z) dz) [b]lam + (z0zN z [C]lam(z) dz) [d]lam, = [A]lam [b]lam + [B]lam [d]lam.

On the other hand, equation (II.1.33) allows to write:

[ [A] [B] [B ] [D] ] [ [a] [b] [b ] T [d] ] = [ [A] [a] + [B] [b]T [A] [b] + [B] [d] [B] [a] + [D] [b]T [B] [b] + [D] [d] ], = [ [I] [0] [0 ] [I] ].

(The “lam” subscript has been omitted for concision sake.) The identification of the right upper corner of the last expression with the integration of [F ]lam(z) along the laminate thickness shows that this integral must be zero. Consequently, one also has:

[V ]lam(zN) = 0, τxz(zN) = 0, τyz(zN) = 0.

It is interesting to remark that the ply out-of-plane shear moduli have not been used in the calculations to obtain (II.1.43). The out-of-plane shear stresses depend only on laminate in-plane bending moments and ply in-plane material properties. One shows in section II.1.6.6 that on the other hand, the calculation of out-of-plane shear strains caused by out-of-plane shear forces requires the knowledge of ply out-of-plane material constants.

II.1.6.5 Approximations with out-of-plane shear forces

Expression (41) shows that out-of-plane shear stresses in the laminate are related to partial derivatives of bending moment components, but not directly to out-of-plane shear force components. Intuitively, one would have expected a dependence of out-of-plane shear stresses on laminate out-of-plane shear forces:

In the end, we propose a calculation method based on out-of-plane shear force components because this is what most software do. The rest of this section is devoted to the presentation of different approaches to calculate dependence on shear forces.

II.1.6.5.1 The “(μx,μy)” approach

One would like to eliminate the six x and y partial derivative of bending moment tensor components in the previous expression. For this, one uses the global equilibrium equations (II.1.36) and (II.1.37). This leaves some arbitrary choice in the determination of dependence wrt out-of-plane shear. For example:

Mxx,x = μxQxz, Myy,x = 0, Mxy,y = (1 - μx)Qxz, Mxx,y = 0, Myy,y = μyQyz, Mxy,x = (1 - μy)Qyz.

{ Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam = [ μx 0 0 0 0 (1 - μx) 0 0 0 μ y (1 - μy) 0 ] {Qxz Qyz } lam. The choice μx = μy = 12 gives more symmetry to the relation between {τ }lam(z) and {Q}lam(z). Indeed, this choice leads to: { τxz,z(z) τyz,z(z) } lam = [J ]lam(z) {Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam, = [J ]lam(z) [ μx 0 0 0 0 (1 - μx) 0 0 0 μ y (1 - μy) 0 ] {Qxz Qyz } lam, = -1 2 [ 100001 0 0 1 0 1 0 ] [ [F ]lam(z) 000 0 0 0 000 000 0 0 0 000 [F ]lam(z) ] [10 0 0 01 0 0 01 1 0 ] {Qxz Qyz } lam.

It seems however that the choice μx = μy = 1 is more common.

If the (μx,μy) approach is adopted, one can introduce a new 2 × 2 matrix:

[X]lam(z) = [J ]lam(z) [ μx 0 0 0 0 (1 - μx) 0 0 0 μ y (1 - μy) 0 ] , = - [100001 0 0 1 0 1 0 ] [ [F ]lam(z) 000 0 0 0 000 000 0 0 0 000 [F ]lam(z) ] [ μx 0 0 0 0 (1 - μx) 0 0 0 μ y (1 - μy) 0 ] .

This matrix allows to write a simple relation between out-of-plane shear stresses in laminate and the total out-of-plane shear force:

{ τxz,z(z) τyz,z(z) } lam = [X]lam(z) {Qxz Qyz } lam.

The [V ]lam(z) 2 × 6 matrix introduced in equation (II.1.43) also allows to introduce a new 2 × 2 matrix:

[Y ]lam(z) = [V ]lam(z) [ μx 0 0 0 0 (1 - μx) 0 0 0 μ y (1 - μy) 0 ] , =z0z [X] lam(z) dz. (II.1.48)

II.1.6.5.2 “Uncoupled X-Y” approach

The presentation of laminate out-of-plane shear theory in Nastran Reference Manual [Sof04a] is based on a kind of beam theory in which laminate shear response is calculated separately in directions X and Y. This corresponds to a simplification of our (μx,μy) approach in which:

We investigated different ways to reproduce Nastran out-of-plane shear stress calculations with FeResPost and found a few modifications that allow the calculation of out-of-plane shear stresses very similar to those produced by Nastran. We modify the calculation method as follows:

1.

The 6 × 6 [ABBD]lam matrix is modified in such a way that one no longer has a coupling between XX, Y Y and XY compnents. Practically, this is done by setting matrix components responsible for this coupling to zero:

[ABBD2] lam = [ A11 0 0 0 A22 0 0 0 A33 B11 0 0 0 B22 0 0 0 B33 B11 0 0 0 B22 0 0 0 B33 D11 0 0 0 D22 0 0 0 D33 ] .

(The non-diagonal components of the four 3 × 3 matrices have been set to zero.) Note that the membrane-flexural coupling is maintained by this modification.

2.

Corresponding to this [ABBD2] lam matrix, we calculate a compliance matrix:

[abbd2] lam = [ABBD2] lam-1.

This new matrix has the same structure as [ABBD2] lam. (XX, Y Y and XY compnents are also mutually decoupled.)

3.

Uncoupling of XX, Y Y and XY components is also done for the 3 × 3 material stiffness matrix [C]lam(z):

[C2] lam(z) = [ C11lam(z) 0 0 0 C22lam(z) 0 0 0 C33lam(z) ] .
4.

Then, a new version of the [F ]lam(z) matrix is calculated:

[F2] lam(z) = [C2] lam(z) ( [b2] lam + z [d2] lam) .

This new matrix also uncouples XX, Y Y and XY components of the equations.

5.

And in the end, one no longer needs XY components in the calculation. Practically, this means that equation (II.1.40) becomes

{ τxz,z(z) τyz,z(z) } lam = [ - 1000 00 0 0 0 0 - 1 0 ] {σxx,x(z) σyy,x(z) τxy,x(z) σxx,y(z) σyy,y(z) τxy,y(z) } lam,

and the relation between gradient of moments tensor, and out-of-plane shear forces can be written

{ Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam = [ 10 0 0 00 0 0 01 0 0 ] {Qxz Qyz } lam.
6.

The uncoupling also affects the calculation of out-of-plane shear stiffness matrix. (See section II.1.6.6.) In the corresponding equations in sections II.1.6.3 and II.1.6.4, matrix [F ]lam(z) is replaced by [F2] lam(z). A consequence of this approximation is that the out-of-plane shear stiffness matrix [G]lam is diagonal.

The “Uncoupled X-Y” approach is an impoverished version of the “(μx,μy)” approach.

II.1.6.5.3 “Resolution in shear force axes” approach

Using “(μx,μy)” approaches, one decides that laminate axes have a special physical meaning for the composite. This choice is arbitrary however. For example, one can also write the relation between bending moments and out-of-plane shear force in a coordinate system related to the shear loading direction.

Let us define a coordinate system associated to shear loading defined as follows:

eshrx = 1 Q { Qxz Qyz } ,

eshry = 1 Q { - Qyz Qxz } .

In which Q is shear force magnitude. In this new coordinate system, the shear force vector has only one non zero component:

Qshr = { Q 0 } .

Then, one can assume a simple relation between bending moments and out-of-plane shear force:

Mxx,x = Q,

all the other components of bending moments gradient being zero. As the gradient of bending moments tensor is an order 3 tensor, previous relation can be written in laminate axes as follows:

{ Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam = 1 Qxzlam Qxzlam + Qyzlam Qyzlam { Qxzlam Q xzlam Q xzlam Qyzlam Q yzlam Q xzlam Qxzlam Q yzlam Q xzlam Qxzlam Q xzlam Q yzlam Qyzlam Q yzlam Q yzlam Qxzlam Q yzlam Q yzlam } .
(II.1.49)

One checks easily that this relation between shear forces and bending moments is non-linear. For example:

{ Qyz Qxz } lam = { 1 0 }  leads to  { Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam = { 1 0 0 0 0 0 } ,
(II.1.50)

{ Qyz Qxz } lam = { 0 1 }  leads to  { Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam = { 0 0 0 0 1 0 }
(II.1.51)

and

{ Qyz Qxz } lam = { 1 1 }  leads to  { Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam = { 0.5 0.5 0.5 0.5 0.5 0.5 } .
(II.1.52)

Clearly, the gradient of bending moments tensor in (II.1.52) is not the sum of corresponding tensors in (II.1.50) and (II.1.51), but the out-of-plane shear force in (II.1.52) is the sum of corresponding vectors in (II.1.50) and (II.1.51). This demonstrates the non-linearity of an approach based on a calculation in shear loading axes.

II.1.6.5.4 Comparison of the three approaches

The main disadvantage of (μx,μy) approach is that the laminate out-of-plane shear equations lose their objectivity wrt rotations of the laminate axes around axis z as illustrated by the example described in section IV.3.5. (This example also allows to estimate the effects of the approximation on the precision of results given by the theory.)

On the other hand, (μx,μy) approach leads to linear calculations, which is an advantage compared to the “resolution in shear force axes” approach. Actually, resolution in shear force axes approach is a little paradoxical wrt this aspect, as in many cases the laminate out-of-plane shear stress will be the only non-linear response of an otherwise linear problem.

This means that none of the three approaches is perfect, and the imperfections result from the fact that both approaches are approximations of the reality. Both approaches are inaccurate, and it is not possible to decide which one is better. In practical problems, one expects the three approaches give good results however.

To simplify the notations, we rewrite equation (II.1.49) as follows:

{M }lam = {M }lam ( {Qs} lam) .

Actually, this notation also applies to the (μx,μy) approach except that the function is then linear:

{M }lam = {M }lam ( {Qs} lam) , = [ μx 0 0 0 0 (1 - μx) 0 0 0 μ y (1 - μy) 0 ] {Qxz Qyz } lam, = [P2] lam (μx,μy) {Qxz Qyz } lam.

Finally, we summarize below our recommendations regarding the calculation of out-of-plane shear in laminates:

But again, the three approaches are approximate, and none of the thre appraoch is better than the other ones as far as results accuracy is concerned.

II.1.6.6 Out-of-plane laminate shear stiffness

One assumes a linear relation between out-of-plane shear components of strain tensor and the corresponding components of Cauchy stress tensor:

{ γxz(z) γyz(z) } lam = [g]lam-1(z) {τxz(z) τyz(z) } lam.

To this relation should correspond a relation between the average out-of-plane shear strains and the out-of-plane shear force:

{ Γxz Γyz } lam = [G]lam-1 {Qxz Qyz } lam.
(II.1.53)

One attempts in this section to justify the calculation of [G] lam-1 matrix in previous expression.

II.1.6.6.1 Limitations of shear stiffness calculation

By writing equation (II.1.53), one makes implicitly the assumption that there is a linear relation between the average out-of-plane shear strain tensor components and the out-of-plane shear forces tensor components. We have seen however in section II.1.6.5 that the calculation of laminate out-of-plane shear stress tensor in out-of-plane shear forces loading axes leads to a non-linear dependence of shear stresses on shear forces. A consequence of this non-linear dependence is that expression (II.1.53) is not valid if laminate out-of-plane shear equilibrium equations are solved in shear loading axes.

The developments in current section II.1.6.6 assume that the (μx,μy) approach of section II.1.6.5 is adopted for stiffness calculations. This does not prevent us to use the “out-of-plane shear forces loading axes” approach for the calculation of ply out-of-plane shear stresses however:

As the purpose of FeResPost and of its composite classes is to post-process finite element results, it makes sense to adopt approaches similar to those of other finite element solvers. Remark however that other composite calculation software, like ESAComp, sometimes adopt other approaches.

II.1.6.6.2 Introduction of new notations

In the definition of loadings, the out-of-plane components of shear force Q can be replaced by average out-of-plane shear stress τ¯. Then the conversion between these two types of components is done simply by multiplication or division by laminate total thickness t:

τ¯ = Q t .

One introduces notations that simplifies the writing of equations:

{Γs} * = { Γxz Γyz } *,

{Qs} * = { Qxz Qyz } *,

{τs¯} * = { τ¯xz τ¯yz } *.

In these expressions the * subscripts can be replaced by a symbol specific to the coordinate system in which the components of the vector are expressed (for example "load", "ply", "lam"...).

II.1.6.6.3 Energetic approach

The components of matrix [g]lam(z) are easily obtained from the orientation and material of plies. The components of [G] lam are obtained by a calculation of out-of-plane shear strain surface energy. One first calculates an estimate of this surface energy using the local expression of shear strains:

Wshearlocal = 1 2z0zN {γs(z)}T lam {τs(z)} lam dz, = 1 2z0zN {τs(z)}T lam [g]lam-1(z) {τ s(z)} lam dz, = 1 2z0zN {Qs}T lam [Y ]T lam(z) [g]lam-1(z) [Y ] lam(z) {Qs} lam dz, = 1 2 {Qs}T lam [z0zN [Y ]T lam(z) [g]lam-1(z) [Y ] lam(z) dz]lam {Qs} lam. (II.1.54)

Note that we have used the [Y ]lam(z) introcuded by equation (II.1.48) in section II.1.6.5. This is possible only because we use the (μx,μy) approach.

Surface energy can also be estimated from the out-of-plane shear global equation:

Wshearglobal = 1 2 {Γs(z)}T lam {Qs} lam, = 1 2 {Qs}T lam [G]lam-1 {Q s} lam. (II.1.55)

Then, as there is only one surfacic energy, Wshearglobal = Wshearlocal and one should have

[G]lam-1 =z0zN [Y ]T lam(z) [g]lam-1(z) [Y ] lam(z) dz, =z0zN [U ]lam(z) dz.

Here again, the integration can be calculated ply-by-ply. More precisely, one calculates on ply k:

[Uk] lam(z) = [Y k]T lam(z) [gk] lam-1 [Y k] lam(z), = [U0k] lam + [U1k] lamz + [U2k] lamz2 + [U 3k] lamz3 + [U 4k] lamz4.

where

[U0k] lam = [Y 0k]T lam [gk] lam-1 [Y 0k] lam, [U1k] lam = [Y 0k]T lam [gk] lam-1 [Y 1k] lam + [Y 1k]T lam [gk] lam-1 [Y 0k] lam, [U2k] lam = [Y 0k]T lam [gk] lam-1 [Y 2k] lam + [Y 1k]T lam [gk] lam-1 [Y 1k] lam + [Y 2k]T lam [gk] lam-1 [Y 0k] lam, [U3k] lam = [Y 1k]T lam [gk] lam-1 [Y 2k] lam + [Y 2k]T lam [gk] lam-1 [Y 1k] lam, [U4k] lam = [Y 2k]T lam [gk] lam-1 [Y 2k] lam.

Then the integral above develops as follows:

[G]lam-1 =z0zN [U ]lam(z) dz, = k=1Nzk-1zk [Uk] lam(z) dz, = k=1Nzk-1zk ( i=04 [U ik] lamzi) dz, = k=1N ( i=04 [U ik] lamzk-1zk zi dz), = k=1N i=04 ( [U ik] lamzki+1 - z k-1i+1 i + 1 ) .

One notes the stiffness matrix [G]lam and the compliance matrix [G-1] lam. Note that once the laminate out-of-plane shear stiffness and compliance matrices are known, the laminate out-of-plane shear equivalent moduli are calculated from the components of the compliance matrix with the following expressions:

Gxz = 1 t [G-1] 11,

Gyz = 1 t [G-1] 22,

in which the [G-1] lam matrix has first been rotated into the appropriate axes.

II.1.6.7 Calculation algorithm for shear stiffness

One describes below the calculation sequences that is used to calculate the laminate out-of-plane shear stiffness properties, and the out-of-plane shear stresses related to a given loading of the laminate.

The calculation sequence is described below. It involves two loops on the laminate layers.

1.

Calculate laminate in-plane and flexural properties. This is necessary because one needs the matrices [b]lam and [d]lam to calculate out-of-plane shear properties.

2.

One initializes the 2 × 2 matrix [G]lam-1 to zero.

3.

Then for each layer k with 1 k N, one performs the following sequence of operations:

(a)

One estimates the 3 × 3 matrix of in-plane stiffness coefficients in laminate axes [Ck] lam. For other calculations, one also need properties like the laminate thickness t and the positions zk of different layer interfaces.

(b)

This matrix is used to calculate the two matrices [F0k] lam and [F1k] lam. (See section II.1.6.3 for more details.) One has:

[Fk] lam(z) = [F0k] lam + z [F1k] lam.
(c)

Then, one calculates two other 2 × 2 matrices [X0k] lam and [X1k] lam. (See section II.1.6.3.) One has:

[Xk] lam(z) = [X0k] lam + z [X1k] lam.
(d)

Then one calculates the [Y ik] lam 2 × 2 matrices:

[Y 0k] lam = [Y 0k-1] lam + ( [Y 1k-1] lam - [X0k] lam) zk-1 + ( [Y 2k-1] lam - [X1k] lam 2 ) zk-12,

[Y 1k] lam = [X0k] lam,

[Y 2k] lam = [X1k] lam 2 .

As the expression of [Y 0k] lam is recursive, one needs another expression for the first value. The expression is:

[Y 01] lam = - [Y 11] lamz0 - [Y 21] lamz02. = - [X01] lamz0 -1 2 [X11] lamz02.
(e)

One calculates the [Uik] lam 2 × 2 matrix. (See the end of section II.1.6.6 for the expressions to be used.) Then to [G]lam-1, one adds one term:

[G]lam-1 = [G] lam-1 + i=04 ( [U ik] lamzki+1 - z k-1i+1 i + 1 ) .
4.

At the end of the loop on layers, the shear stiffness matrix [G]lam is calculated by inversion of [G]lam-1.

One also defines an out-of-plane shear compliance matrix calculated as follows:

[g]lam = [G]lam-1.

This matrix allows to calculate the laminate out-of-plane shear moduli:

Gxz = 1 t g11,

Gyz = 1 t g22,

Note that the values calculated above do not correspond to an out-of-plane shear stiffness of a material equivalent to the defined laminate. To convince yourself of this you can define a laminate with a single ply of orthotropic material. Then, you will observe that Gxz = Gyz = 5G6 in which G is material shear modulus. (The usual 56 factor in shell theory is recovered.)

II.1.6.8 Ply out-of-plane shear stresses

II.1.6.8.1 With (μx,μy) approach

When the (μx,μy) approach is adopted, [Y k] lam(z) matrices allow the calculation of out-of-plane shear stress from the global out-of-plane shear force:

[Y k] lam(z) = [Y 0k] lam + [Y 1k] lamz + [Y 2k] lamz2,

{τs(z)} lam = [Y ]lam(z) {Qs} lam.

Actually, one is interested in stresses in ply axes, rather than in laminate axes. If ξ is the orientation of the ply in laminate axes, then:

{τs(z)} ply = [S+] (ξ) {τs(z)} lam.

Then, one has simply:

{τs(z)} ply = [S+] (ξ) [Y ]lam(z) {Qs} lam, = [Y ]plylam(z) {Qs} lam.

One stores a 2 × 2 matrix [Y ]plylam for each station through laminate thickness where out-of-plane shear stress might be requested. Actually it is done at top, mid and bottom surfaces in each ply. This means that 3N 2 × 2 matrices [Y j] plylam are stored in the ClaLam object.

II.1.6.8.2 With “resolution in shear force axes” approach

One first estimates the components of bending moments gradient in laminate axes with equation (II.1.49):

{M }lam = { Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam = 1 Qxzlam Qxzlam + Qyzlam Qyzlam { Qxzlam Q xzlam Q xzlam Qyzlam Q yzlam Q xzlam Qxzlam Q yzlam Q xzlam Qxzlam Q xzlam Q yzlam Qyzlam Q yzlam Q yzlam Qxzlam Q yzlam Q yzlam } .

Then, the laminate out-of-plane shear stresses can be estimated by an expression like (II.1.43):

{ τxz(z) τyz(z) } lam = [V ]lam(z) {M }lam.

In this expression, [V ]lam(z) is given by (II.1.44):

[V ]lam(z) = [V 0k] lam + [V 1k] lamz + [V 2k] lamz2.

The three 2 × 6 matrices [V 0k] lam, [V 1k] lam and [V 2k] lam are calculated recursively using the expressions (II.1.46), (II.1.45) and (II.1.45):

[V 0k] lam = [V 0k-1] lam + ( [V 1k-1] lam - [J0k] lam) zk-1 + ( [V 2k-1] lam - [J1k] lam 2 ) zk-12.

[V 1k] lam = [J0k] lam,

[V 2k] lam = [J1k] lam 2 .

To resolve the recursion for [V 0k] lam one need an estimate for the first ply. One uses (II.1.47):

[V 01] lam = - [V 11] lamz0 - [V 21] lamz02.

Again, one is more interested in the out-of-plane shear stresses in ply axes than in laminate axes.

{τs(z)} ply = [S+] (ξ) [V ]lam(z) {M }lam, = [V ]plylam(z) {M }lam.

One stores a 2 × 6 matrix [V ]plylam for each station through laminate thickness where out-of-plane shear stress might be requested. Actually it is done at top, mid and bottom surfaces in each ply. This means that 3N 2 × 6 matrices [V j] plylam are stored in the ClaLam object.

II.1.7 CTE and CME calculations

One assumes a linear dependence of the temperature on the location through the laminate thickness:

T(z) = T0 + zT,z.

Similarly, the water uptake depends linearly on z:

H(z) = H0 + zH,z.

The calculation of laminate response to hygrometric loading is very similar to its response to thermo-elastic loading. Therefore, the following developments are done for thermo-elastic loading only. Later, they are transposed to hygrothermal solicitations.

II.1.7.1 In-plane and flexural thermo-elastic behavior

One calculates the stresses induced in plies for a thermo-elastic loading assuming that the material strain components are all constrained to zero. Equation (II.1.21) becomes:

{σ}ply = -ΔT [C]ply {α}ply.

In laminate axes, the equation is rewritten:

{σ}lam = -ΔT [C]lam {α}lam.

One substitutes in the equation the assumed temperature profile:

{σ}lam = -[(T0 - Tref) + zT,z] [C]lam {α}lam.

The corresponding laminate in-plane force tensor is obtained by integrating the Cauchy stress tensor along the thickness:

{N }lam =-h2h2 {σ} lam dz, = --h2h2[(T 0 - Tref) + zT,z] [C]lam {α}lam dz, = - (-h2h2 [C] lam {α}lam dz) (T0 - Tref) - (-h2h2z [C] lam {α}lam dz)T,z, = - {αEh}lam(T0 - Tref) - {αEh2} lamT,z.

In the previous expression, two new symbols have been introduced that are calculated as follows:

{αEh}lam =-h2h2 [C] lam {α}lam dz, = k=1N [C] lamk {α} lamk (z k - zk-1) . (II.1.56)

{αEh2} lam =-h2h2z [C] lam {α}lam dz, = k=1N [C] lamk {α} lamk (zk2 - z k-12 2 ) . (II.1.57) Similarly the bending moment tensor is obtained by integrating the Cauchy stress tensor multiplied by z along the thickness: {M }lam =-h2h2z {σ} lam dz, = --h2h2z[(T 0 - Tref) + zT,z] [C]lam {α}lam dz, = - (-h2h2z [C] lam {α}lam dz) (T0 - Tref) - (-h2h2z2 [C] lam {α}lam dz)T,z, = - {αEh2} lam(T0 - Tref) - {αEh3} lamT,z.

In the previous expression, one new symbol has been introduced:

{αEh3} lam =-h2h2z2 [C] lam {α}lam dz, = k=1N [C] lamk {α} lamk (zk3 - z k-13 3 ) . (II.1.58)

Because of the linearity of all the equations, the thermo-elastic loading may be considered as an additional loading applied to the laminate, and if one considers an additional imposition of average in-plane strain and of a curvature, the laminate in-plane forces and bending moments are given by:

{ {N }lam {M }lam } = [ [A]lam [B]lam [B]lam [D]lam ] { {ϵ0} lam {κ } lam } - { {αEh}lam {αEh2} lam } (T0 - Tref) - { {αEh2} lam {αEh3} lam } T,z.(II.1.59)

Using relation (II.1.33), the previous expression is reversed as follows:

{ {ϵ0} lam {κ } lam } = [ [a]lam [b]lam [b]T lam [d]lam ] { {N }lam {M }lam } + [ [a]lam [b]lam [b]T lam [d]lam ] { {αEh}lam {αEh2} lam } (T0 - Tref) + [ [a]lam [b]lam [b]T lam [d]lam ] { {αEh2} lam {αEh3} lam } T,z.(II.1.60)

In the last expression, four new quantities can be identified:

{α0ϵ} lam = [a]lam {αEh}lam + [b]lam {αEh2} lam,
(II.1.61)

{α1ϵ} lam = [a]lam {αEh2} lam + [b]lam {αEh3} lam,
(II.1.62)

{α0κ} lam = [b]T lam {αEh}lam + [d]lam {αEh2} lam,
(II.1.63)

{α1κ} lam = [b]T lam {αEh2} lam + [d]lam {αEh3} lam.
(II.1.64)

So that finally, the “compliance” equation is:

{ {ϵ0} lam {κ } lam } = [ [a]lam [b]lam [b]T lam [d]lam ] { {N }lam {M }lam } + { {α0ϵ} lam {α 0κ} lam } (T0 - Tref) + { {α1ϵ} lam {α 1κ} lam } T,z.(II.1.65)

II.1.7.2 Out-of-plane shear thermo-elastic behavior

Starting with the out-of-plane shear constitutive equation (II.1.28) and of the expression defining the out-of-plane shear force vectors {Qs} lam one makes developments similar to those of section II.1.7.1 and defines the following quantities:

{αsGh}lam =-h2h2 [g] lam {αs} lam dz, = k=1N [g] lamk {α s} lamk (z k - zk-1) . (II.1.66)

{αsGh2} lam =-h2h2z [g] lam {αs} lam dz, = k=1N [g] lamk {α s} lamk (zk2 - z k-12 2 ) . (II.1.67) They are used in the expression:

{Q}lam = [G]lam {Γ} lam - {αsGh}lam(T0 - Tref) - {αsGh2} lamT,z.
(II.1.68)

Correspondingly, one estimates the laminate out-of-plane shear CTE vectors:

{α0s} lam = [G]lam-1 {αGh} lam
(II.1.69)

{α1s} lam = [G]lam-1 {αGh2} lam
(II.1.70)

These two expressions allow to write the expression of the inverse of (II.1.68):

[Γ] lam = [G]lam-1 {Q} lam + {α0s} lam(T0 - Tref) + {α1s} lamT,z.

II.1.7.3 Hygrometric behavior of laminates

One transposes below the results for thermo-elastic behavior. It is done simply by replacing the CTE α by the CME β in the definitions and equations.

{βEh}lam = k=1N [C] lamk {β} lamk (z k - zk-1) , (II.1.71)

{βEh2} lam = k=1N [C] lamk {β} lamk (zk2 - z k-12 2 ) , (II.1.72) {βEh3} lam = k=1N [C] lamk {β} lamk (zk3 - z k-13 3 ) , (II.1.73)

{ {N }lam {M }lam } = [ [A]lam [B]lam [B]lam [D]lam ] { {ϵ0} lam {κ } lam } - { {βEh}lam {βEh2} lam } (H0 - Href) - { {βEh2} lam {βEh3} lam } H,z, (II.1.74)

{β0ϵ} lam = [a]lam {βEh}lam + [b]lam {βEh2} lam,
(II.1.75)

{β1ϵ} lam = [a]lam {βEh2} lam + [b]lam {βEh3} lam,
(II.1.76)

{β0κ} lam = [b]T lam {βEh}lam + [d]lam {βEh2} lam,
(II.1.77)

{β1κ} lam = [b]T lam {βEh2} lam + [d]lam {βEh3} lam,
(II.1.78)

{ {ϵ0} lam {κ } lam } = [ [a]lam [b]lam [b]T lam [d]lam ] { {N }lam {M }lam } + { {β0ϵ} lam {β 0κ} lam } (H0 - Href) + { {β1ϵ} lam {β 1κ} lam } H,z, (II.1.79)

{βsGh}lam =-h2h2 [g] lam {βs} lam dz, = k=1N [g] lamk {β s} lamk (z k - zk-1) , (II.1.80)

{βsGh2} lam =-h2h2z [g] lam {βs} lam dz, = k=1N [g] lamk {β s} lamk (zk2 - z k-12 2 ) , (II.1.81)

{Q}lam = [G]lam {Γ} lam - {βsGh}lam(H0 - Href) - {βsGh2} lamH,z,

{β0s} lam = [G]lam-1 {βGh} lam
(II.1.82)

{β1s} lam = [G]lam-1 {βGh2} lam
(II.1.83)

[Γ] lam = [G]lam-1 {Q} lam + {β0s} lam(H0 - Href) + {β1s} lamH,z.

II.1.7.4 Full sets of equations

Finally, the full set of constitutive equation written with stiffness matrices looks like:

[ [A]lam [B]lam [B]lam [D]lam ] { {ϵ0} lam {κ } lam } = { {N }lam {M }lam } + { {αEh}lam {αEh2} lam } (T0 - Tref) + { {αEh2} lam {αEh3} lam } T,z + { {βEh}lam {βEh2} lam } (H0 - Href) + { {βEh2} lam {βEh3} lam } H,z, (II.1.84)

[G]lam {Γ} lam = {Q}lam + {αsGh}lam(T0 - Tref) + {αsGh2} lamT,z + {βsGh}lam(H0 - Href) + {βsGh2} lamH,z.(II.1.85)

The two previous expressions are inversed as follows:

[ [a]lam [b]lam [b]T lam [d]lam ] { {N }lam {M }lam } = { {ϵ0} lam {κ } lam } + { {α0ϵ} lam {α 0κ} lam } (T0 - Tref) + { {α1ϵ} lam {α 1κ} lam } T,z + { {β0ϵ} lam {β 0κ} lam } (H0 - Href) + { {β1ϵ} lam {β 1κ} lam } H,z, (II.1.86)

[G]lam-1 {Q} lam = [Γ] lam - {α0s} lam(T0 - Tref) - {α1s} lamT,z - {β0s} lam(H0 - Href) - {β1s} lamH,z.(II.1.87)

II.1.8 Calculation of load response

One always considered a decoupling of in-plane and flexural of laminates on one side, and the out-of-plane shear of laminates on the other side. These two aspects are discussed in sections II.1.8.1 and II.1.8.2 respectively.

II.1.8.1 In-plane and flexural response

Beside thermo-elastic or hygro-elastic loading, the composite classes of FeResPost allows the definition different types of mechanical loads:

The type of loading is specified component-by-component. This means that a single loading may have some components imposed as normal forces and bending moments, with other components imposed as average strains, and other components as average stresses or flexural stresses. The mechanical part of loading is also characterized by a direction λ wrt laminate axes. The subscript “load” indicates that the components are given in loading axes. One explains below how the laminate response is calculated.

1.

The solver first checks if average or flexural stresses are imposed. If such components of the loading are found, they are converted to in-plane forces and bending moments with the following equations:

{N }load = h {σ0} load,

{M }load = h2 6 {σf} load,

in which h is the laminate thickness.

2.

The mechanical part of loading is characterized by a direction wrt laminate axes. This direction is given by an angle λ. In order to have laminate properties and loading given in the same coordinate system, the laminate stiffness matrices and CTE vectors are calculated in this new coordinate system. (It is more convenient for the elimination of components imposed as average strains or curvatures.) More precisely, the stiffness matrices and CTE vector are rotated with the following expressions:

[A]load = [T-](λ) [A]lam [T-] (λ),

[B]load = [T-](λ) [B]lam [T-] (λ),

[D]load = [T-](λ) [D]lam [T-] (λ),

{αEh}load = [T-](λ) {αEh}lam,

{βEh3} load = [T-](λ) {βEh3} lam.

The calculation of CTE and CME related quantities is done only if the corresponding temperature or moisture contributions have been defined in the loading. The system of equations looks like:

[ [A]load [B]load [B]load [D]load ] { {ϵ0} load {κ } load } = { {N }load {M }load } + { {αEh}load {αEh2} load } (T0 - Tref) + { {αEh2} load {αEh3} load } T,z + { {βEh}load {βEh2} load } (H0 - Href) + { {βEh2} load {βEh3} load } H,z.(II.1.88)

(Here again the CTE and CME related terms are optional.) Actually, one can write a single set of 6 equations with 6 unknowns. The general form of this system is

j=1nK ijuj = bi, i = 1...n.
3.

Now, one considers a case in which one component of vector uj is constrained to be a certain value. For example uk = a. This equation replaces the kth equation of the system:

j=1nK ijuj = bi, i = 1...n,ik uk = a.

The unknown uk can be easily eliminated from the linear

j=1,jknK ijuj = bi - Kika, i = 1...n,ik uk = a.

The first line above corresponds to a new linear system of n - 1 equations with n - 1 unknowns. The set of two lines define the algebraic operations that are performed in FeResPost when one imposes an average strain or curvature component.

Actually, the operation can be simplified. It is sufficient to replace line k in the linear system of equations by the constraint equation uk = a and perform the “usual” Gaussian elimination to solve the linear system of equations.

4.

When all the components of loading imposed as average strains or curvature have been eliminated from the linear system, a classical Gaussian elimination algorithm calculates the other unknowns of the system.

Then the components of tensors {ϵ0} and {κ} are known in loading axes.

5.

The normal forces and bending moments are then calculated in loading axes with the following equations:

{N }load = [A]load {ϵ0} load + [B]load {κ}load - {αEh}load(T0 - Tref) - {αEh2} loadT,z - {βEh}load(H0 - Href) - {βEh2} loadH,z, (II.1.89)

{M }load = [B]load {ϵ0} load + [D]load {κ}load - {αEh2} load(T0 - Tref) - {αEh3} loadT,z - {βEh2} load(H0 - Href) - {βEh3} loadH,z.(II.1.90)

(The CTE and CME related terms are optional.)

6.

If λ is the angle characterizing the loading orientation wrt laminate axes a rotation of - λ of the two vectors gives the average strain and curvature tensors in laminate axes: {ϵ0} lam and {κ}lam.

{ϵ0} lam = [T+] (-λ) {ϵ0} load,

{κ}lam = [T+] (-λ) {κ}load.

Similarly, the normal forces and bending moments components are re-expressed in laminate axes:

{N }lam = [T-](-λ) {N }load,

{M }lam = [T-](-λ) {M }load.
7.

For each ply, one calculates (if required) the stresses and strains as follows:

(a)

One rotates the laminate average strain and curvature tensors to obtain them in ply axes. If the ply is characterized by an angle ξ wrt laminate axes, the two tensors are rotated by the same angle ξ:

{ϵ0} ply = [T+] (ξ) {ϵ0} lam,

{κ}ply = [T+] (ξ) {κ}lam.

Note that, even though the components of these two tensors are now given in one of the plies coordinate system, they correspond to strain or curvature of the laminate at mid-thickness.

(b)

At the different stations through the thickness at which strains and stresses are required, the strain components are calculated with:

{ϵ}ply(z) = {ϵ0} ply + z {κ}ply.
(II.1.91)

In FeResPost z may have the values zinf, zmid, zsup. Then the stress components are given by:

{σ}ply(z) = [C]ply {ϵ}ply(z) - [C]ply ( {α}ply(T0 - Tref + zT,z) + {β}ply(H0 - Href + zH,z)) .(II.1.92)

(Here again the CTE and CME related terms are optional.) A peculiar version of the ply strain tensor that corresponds to ply stresses, but without thermo-elastic or moisture contribution is calculated as follows:

{ϵMech} ply(z) = [c]ply {σ}ply(z).

This version of the strain tensor is called the “Mechanical Strain Tensor” or “Equivalent Strain Tensor”. This is the version of the strain tensors that is used for the strain failure criteria. Note however that a “Total Strain” version of the criteria is proposed as well.

At the end of the calculations, the laminate object which has been used to perform those calculations stores a few results:

The ply results may be used later to calculate failure indices or reserve factors.

II.1.8.2 Out-of-plane shear response

Some of the quantities calculated above, and stored in the ClaLam object are used to estimate laminate shear loading response.

The different steps of the calculation are described below:

1.

The first step of the calculation is to resolve the loading in out-of-plane shear forces in loading axes {Q}load (or {Γ} load). For this, one proceeds as in section II.1.5, but with the following differences: the conversion of average out-of-plane shear strain to out-of-plane shear force components requires the knowledge of out-of-plane shear stiffness matrix in loading axes. This one is readily obtained by transforming the corresponding matrix in laminate axes:

[G]load = [S+] (λ) [G]lam [S-](λ).
2.

The out-of-plane shear loading can be expressed by specifying the out-of-plane shear forces, or the out-of-plane average shear strain, or a combination of the two. In all cases, the components are specified in loading axes.

If out-of-plane average shear forces are specified, the resolution of the following linear system of equations allows to calculate the corresponding out-of-plane shear strains:

[G]load {Γ} load = {Q}load + {αsGh}load(T0 - Tref) + {αsGh2} loadT,z + {βsGh}load(H0 - Href) + {βsGh2} loadH,z.(II.1.93)

(The CTE and CME related terms are optional.) The resolution of this equation is done following the same approach as for the in-plane and bending loading. One performs a Gaussian elimination in a 2 × 2 matrix. Constraints can be imposed if out-of-plane shear strains are specified for some components of the loading instead of out-of-plane lineic shear force.

3.

At this stage, whatever the type of loading applied to the laminate, {Γ} load is known. One can obtain the lineic out-of-plane shear forces with

[Q]load = [G]load {Γ} load - {α0s} load(T0 - Tref) - {α1s} loadT,z - {β0s} load(H0 - Href) - {β1s} loadH,z.(II.1.94)

(The CTE and CME related terms are optional.) Once {Q}load and {Γ} load are known, the corresponding loading in laminate axes is obtained with:

{Q}lam = [S-](λ) {Q}load,

{Γ} lam = [S-](λ) {Γ} load.
4.

For the calculation of ply out-of-plane shear stresses, one makes a distinction depending on the calculation approach that has been adopted:

(a)

With (μx,μy) approach ply out-of-plane shear stress components are calculated at the different requested locations by:

{τsj(z)} ply = [Y j(z)] plylam {Q s} lam,

in which the matrix [Y j] plylam is relative to the station at which the stress is requested.

(b)

If the “resolution in shear force axes” approach is adopted, one first calculates an estimate of the gradient of bending moments tensor with equation (II.1.49):

{ Mxx,x Myy,x Mxy,x Mxx,y Myy,y Mxy,y } lam = 1 Qxzlam Qxzlam + Qyzlam Qyzlam { Qxzlam Q xzlam Q xzlam Qyzlam Q yzlam Q xzlam Qxzlam Q yzlam Q xzlam Qxzlam Q xzlam Q yzlam Qyzlam Q yzlam Q yzlam Qxzlam Q yzlam Q yzlam } .

Then, ply stresses are given by

{τsj(z)} ply = [V j(z)] plylam {M } lam,

in which the matrix [V j] plylam is relative to the station at which the stress is requested.

5.

Finally, for the stations where out-of-plane shear stresses have been calculated the out-of-plain shear strain is also calculated using the corresponding ply material coefficients:

{γs(z)} ply = [g]ply-1 {τ s(z)} ply + ( {α}ply(T0 - Tref + zT,z) + {β}ply(H0 - Href + zH,z)) .(II.1.95)

(The CTE and CME related terms are optional. One takes benefits of the “decoupling of out-of-plane shear” assumption.)

II.1.8.3 Out-of-plane T/C deformation

The Classical Lamination Theory is based on the assumption that σ33 = 0. Consequently, ϵ33 and ϵ33Mech are generally not zero. These strain tensor components can be estimated from (12):

ϵ33Mech = c 3311σ11 + c3322σ22 + c3333σ33 + c3323σ23 + c3331σ31 + c3312σ12,

ϵ33 = ϵ33Mech + α 33ΔT + β33ΔH.

II.1.9 Accelerating the calculation of load response

In section II.1.8, one explained the different steps to solve the laminate load response equation, and estimate ply stresses and strains. The number of operations involved in these calculations is very important, and when repetitive calculation of laminate load response is done, the computation time can increase unacceptably. This is the case, for example, when laminate load response analysis is performed on loads extracted from finite element model results.

However, many operations described in section II.1.8 will be the same for each different loading. This means that these operations could be done only once for the different laminate loads considered in the analysis. We investigate in this section the possible accelerations of laminate load response analysis.

II.1.9.1 Calculation of laminate loads and strains

We explain in this section how the laminate load response calculation can be accelerated. In particular, when the calculation of laminate load response is done repititively with similar loading, the benefit of simplifying the sequence of operations to estimate laminate loading becomes obvious.

One explains the calculation of laminate in-plane and flexural load response in section II.1.8.1. The sequence of operations results in the building of 6 × 6 matrix K that depends on laminate definition and loading angle. For all the calculations done with a common laminate and loading angle, the operations can be simplified as follows:

1.

The matrix K is assembled.

2.

The components of loading that are specified as in-plane strain, or curvature lead to the imposition of constraints on matrix K. For example, if one imposes uk = a, it is sufficient to replace the elements of line k in matrix K by 0, except Kkk=1. When all the constraints have been imposed, one obtains a new 6 × 6 matrix that we call Kconstr.

3.

Finally, this matrix is inversed, and on obtained the 6 × 6 matrix Kconstr-1.

This Kconstr-1 matrix is the same for all the loadings that we apply with on the same laminate, with the same loading angle θ, and with the same constraints. When calculating load response, this matrix is used as follows:

1.

For each laminate load, one assembles the 6 components vector bconstr as explained in section II.1.8.1. The components usually correspond to shell forces or moments, but the “constrained components” (components specified as strains or curvature) are replaced by components of shell in-plane strains or curvatures.

2.

Shell in-plane strains and curvatures in loading axes are obtained by calculating the following matricial product:

{ {ϵ0} load {κ} load } = Kconstr-1bconstr.
3.

Then, the shell strains and curvature components can be expressed in laminate axes by performing the following matricial operation:

{ {ϵ0} lam {κ } lam } = [ [T+] (-λ) [0] [0] [T+] (-λ) ] { {ϵ0} load {κ } load } , = [ [T+] (-λ) [0] [0] [T+] (-λ) ] Kconstr-1 bconstr.(II.1.96)

Finally, the last expression leads to the definition of a new 6 × 6 matrix

Kconstr, lam-1 = [ [T+] (-λ) [0] [0] [T+] (-λ) ]Kconstr-1,

that allows to write

{ {ϵ0} lam {κ} lam } = Kconstr, lam-1bconstr.
(II.1.97)

This matrix can be constructed once and for all for a given laminate, loading angle and loading characteristics.

A similar approach can be used for the simplification of the laminate out-of-plane shear response calculation:

1.

The construction of a 2 × 2 Kconstr-1 matrix allows to write:

[Γ] load = Kconstr-1 bconstr,

in which bconstr corresponds to the out-of-plane shear loads (forces or strains).

2.

Then

[Γ] lam = [S-](λ) [Γ] load.
3.

And this leads to the definition of a new 2 × 2 matrix that allows to write:

Kconstr, lam-1 = [S -](λ) Kconstr-1,

[Γ] lam = Kconstr, lam-1 bconstr.
(II.1.98)

Finally, now that the laminate strains and curvatures have been estimated in laminate axes, the corresponding laminate forces and moments are estimated as follows:

{ {N }lam {M }lam } = [ [A]lam [B]lam [B]lam [D]lam ] { {ϵ0} lam {κ } lam } - { {αEh}lam {αEh2} lam } (T0 - Tref) - { {αEh2} lam {αEh3} lam } T,z - { {βEh}lam {βEh2} lam } (H0 - Href) - { {βEh2} lam {βEh3} lam } H,z,(II.1.99)

[Q]lam = [G]lam {Γ} lam - {α0s} lam(T0 - Tref) - {α1s} lamT,z - {β0s} lam(H0 - Href) - {β1s} lamH,z.(II.1.100)

One can substitute (II.1.97) and (II.1.98) in expressions (99) and (100). This leads to the following expressions:

{ {N }lam {M }lam } = [ [ [A]lam [B]lam [B]lam [D]lam ] Kconstr, lam-1 - { {αEh}lam {αEh2} lam } - { {αEh2} lam {αEh3} lam } - { {βEh}lam {βEh2} lam } - { {βEh2} lam {βEh3} lam } ] { bconstr T0 - Tref T,z H0 - Href H,z } , = [ Kconstr, lamNM ] {bconstrFM} ,(II.1.101)

[Q]lam = [ [G]lam Kconstr, lam-1 - {α 0s} lam - {α1s} lam - {β0s} lam - {β1s} lam ] { bconstr T0 - Tref T,z H0 - Href H,z } , = [ Kconstr, lamQ ] {bconstrQ} .(II.1.102)

From equations (II.1.97), (II.1.98), (101) and (102), one identifies four matrices and four vectors that allow the calculation of laminate stress/strain state in laminate axes:

The four matrices depend on laminate definition, angle θ of the loading wrt laminate axes, and on the set of components that are constrained to strain or curvature values. The four vectors also depend on the values of the particular loading that is examined. This means that the four matrices can be calculated once and for all the particular loadings. On the other-hand the four vectors must be re-estimated for each element defining the load.

II.1.9.2 Calculation of plies stresses and strains

The calculation of ply stresses and strains from the laminate loads is easily accelerated. Indeed, let us consider a laminate loading corresponding to:

These quantities correspond to 16 real values that characterize entirely the laminate loading. For a given ply, the stresses can be calculated at a given height (z value) from these 16 real values. All the calculations are linear.

If one defines a vector with 16 components as follows:

{LLd}lam = { {ϵ0} lam {κ } lam {M } lam T 0 - Tref T,z H0 - Href H,z } .

That contains all the laminate loading, there must be a matrix [Kσ] ply(zi) that allows to calculate ply stresses as follows:

{σ}ply(zi) = [Kσ] ply(zi) {LLd}lam.

Matrix [Kσ] ply(zi) is a 6 × 16 matrix that depends only on laminate definition. This means that this matrix can be calculated once and for all when laminate is created in the database.

Similarly one can also define matrices [Kϵ] ply(zi) and [KϵMech] ply(zi) for the calculations of {ϵ}ply(zi) and {ϵMech} ply(zi) respectively. We explain here, how these three matrices can be constructed.

II.1.9.2.1 Loading in ply axes

The first step of ply stresses or strain calculations consists in expressing the laminate loading in ply axes. The following operations are performed:

{ϵ0} ply = [T+] (ξ) {ϵ0} lam,

{κ}ply = [T+] (ξ) {κ}lam,

{τsj(z)} ply = [V j(z)] plylam {M } lam.

The four real values corresponding to laminate temperature and moisture loading are not affected by the modification of coordinate system. The three relations above allow us to write the following equation:

{ {ϵ0} ply {κ} ply {τsj(z)} ply T0 - Tref T,z H0 - Href H,z } = [ [T+] (ξ) [0] [0] 0000 [0] [T+] (ξ) [0] 0000 [0] [0] [V j(z)] plylam0000 [0] [0] [0] 1000 [0] [0] [0] 0100 [0] [0] [0] 0010 [0] [0] [0] 0001 ] { {ϵ0} lam {κ } lam {M } lam T 0 - Tref T,z H0 - Href H,z } .
(II.1.103)

Note that the out-of-plane shear response is now expressed as out-of-plane shear stresses at the specified height in selected ply and no longer as laminate out-of-plane shear forces.

The strains, temperatures and moisture at height z in selected ply is easily obtained with the following expressions:

{ϵ}ply(z) = {ϵ0} ply + z {κ}ply,

T(z) - Tref = T0 - Tref + zT,z,

H(z) - Href = H0 - Href + zH,z.

The combination of these three expressions in a single matricial expression gives:

{ {ϵ}ply(z) {τsj(z)} ply T(z) - Tref H(z) - Href } = [ [δ3] [δ3] z[0]0000 [0] [0] [δ2]0000 [0] [0] [0]1z00 [0] [0] [0]001z ] { {ϵ0} ply {κ } ply {τsj(z)} ply T0 - Tref T,z H0 - Href H,z } .
(II.1.104)

( [δ3] and [δ2] are 3 × 3 and 2 × 2 unit matrices respectively.) Then, considering equation (92), one writes:

{ {σ}ply(z) {τsj(z)} ply T(z) - Tref H(z) - Href } = [ [C]ply[0] - [C]ply {α}ply - [C]ply {β}ply [0] [δ2] {0} {0} [0] [0] 1 0 [0] [0] 0 1 ] { {ϵ}ply(z) {τsj(z)} ply T(z) - Tref H(z) - Href } .
(II.1.105)

The vector at left hand side of expression (II.1.105) contains all the ply stress components. One can remove the two lower lines of the equation as follows:

{ {σ}ply(z) {τsj(z)} ply } = [ [C]ply[0] - [C]ply {α}ply - [C]ply {β}ply [0] [δ2] {0} {0} ] { {ϵ}ply(z) {τsj(z)} ply T(z) - Tref H(z) - Href } .
(II.1.106)

Then, the components can be reordered as follows:

{σ}mat(z) = ( σ11 σ22 σ33 τ23 τ13 τ12 ) (z) = [ 10000 0 1 0 0 0 00000 0 0 0 0 1 00010 0 0 1 0 0 ] { {σ}ply(z) {τsj(z)} ply } .
(II.1.107)

One will also use:

( {σ}mat(z) T(z) - Tref H(z) - Href ) = ( σ11 σ22 σ33 τ23 τ13 τ12 T - Tref H - Href ) (z) = [ 1000000 0 1 0 0 0 0 0 0000000 0 0 0 0 1 0 0 0001000 0 0 1 0 0 0 0 0000010 0 0 0 0 0 0 1 ] { {ϵ}ply(z) {τsj(z)} ply T(z) - Tref H(z) - Href } .
(II.1.108)

One uses (12) to estimate the strain tensor:

{ϵ}mat(z) = ( ϵ11 ϵ22 ϵ33 γ23 γ31 γ12 ) (z) = ( [cijkl] {α}mat {β}mat ) ( {σ}mat(z) T(z) - Tref H(z) - Href ) .
(II.1.109)

The vector that appears in right-hand-side of the previous expression The so-called “mechanical strain tensor” is given by:

{ϵ}matMech(z) = ( ϵ11Mech ϵ22Mech ϵ33Mech γ23Mech γ31Mech γ12Mech ) (z) = [cijkl] {σ}mat(z).
(II.1.110)

All the operations (II.1.103) to (II.1.110) reduce to matricial products. The characteristics of the matrices used in these operations are summarized in Table II.1.1. Two of these matrices are “re-ordering” metrices, and do not depend on the ply material or position accross laminate thickness. The other matrices depend on the ply material. Only two of the matrices depends on height z.


Table II.1.1: Summary of the matrices that have been defined for the acceleration of ply stresses and strains calculation.
Matrix Reference Size Dependence on
[K1](II.1.103)12 × 16Ply angle, material and height z
[K2](II.1.104)7 × 12 Height z
[K3](II.1.105)7 × 7 Ply material
[K4](II.1.106)5 × 7 Ply material
[K5 ](II.1.107)6 × 5
[K6 ](II.1.108)8 × 7
[K7 ](II.1.109)6 × 8 Ply material
[K8 ](II.1.110)6 × 6 Ply material

In the end, one writes:

{σ}mat(z) = [K5] [K4] [K2] (z) [K1] (z) {LLd}lam, = [Kσ] (z) {LLd}lam. (II.1.111)

{ϵ}mat(z) = [K7] [K6] [K3] [K2] (z) [K1] (z) {LLd}lam, = [Kϵ] (z) {LLd}lam. (II.1.112) {ϵ}matMech(z) = [K8] {σ}mat(z), = [K8] [Kσ] (z) {LLd}lam, = [KϵMech] (z) {LLd} lam. (II.1.113)

We have shown that if one wishes to calculate stresses and strains in plies from the laminate loading {LLd} lam, at the three “bot” “mid” and “sup” heights of laminate plies, one needs to calculate 3 × 3 = 9 matrices per ply. Each of the matrices has 6 × 16 size and depends only on the laminate definition. This means that these matrices can be calculated once and for all when laminate is defined.

Note that the acceleration matrices for the ply stresses and strains calculation must be re-estimated each time the laminate or one of its materials is modified. This is the reason why method “reInitAllPliesAccelMatrices” has been added to the “ClaLam” and “ClaDb” classes.

Finally, as usual, the out-of-plane shear calculation approach will influence the results, because the gradient of bending tensor can be calculated different ways:

The adoption of the first or second approach affects only the corresponding components of {LLd} lam vector. Matrices [Kσ] (z), [Kϵ] (z) and [KϵMech] (z) remain the same.

II.1.10 Failure theories

When stresses and strains have been calculated in plies (or some of the plies), the failure indices can be estimated too. One presents below the different failure theories that are proposed in FeResPost, and how these failure theories can be used to estimate laminate reserve factors.

In this section, one conventionally uses integer subscripts to denote that tensor components are given in ply axes and Roman subscripts to indicate principal components. Often, only in-plane components of ply stress or strain tensors are used to estimate criteria. Then, the principal components are estimated as follows:

σI,II = 1 2 (σ11 + σ22) ±1 4 (σ11 + σ22) 2 + τ122.

In the rest of this section all the allowables used in failure criteria have positive values. Even the compressive allowables are 0.

Table II.1.2 summarizes the criteria available in FeResPost. For each criterion, the Table provides:

1.

A String corresponding to the argument that identifies the selected criterion when derivation is asked.

2.

A description of the type of material (metallic or isotropic, unidirectional tape, fabric,...).

3.

A reference to the section in which the criterion is presented and discussed.

4.

Specification whether an equivalent stress for this criterion can be derived in FeResPost or not.

5.

One specifies whether a failure index can be derived with FeResPost. Generally, the failure index is calculated according to the “usual” definition in litterature. when no such standard failure index definition is available, one provides a default definition which corresponds to the inverse of the reserve factor calculated with FoS = 1.

6.

One specifies whether a reserve factor and/or strength ratio can be calculated with FeResPost:

  • The “reserve factor” (RF) can be defined as the factor by which laminate loads can be multiplied to reach the threshold of composite failure according to the selected failure criterion. A safety factor is included in the calculation of reserve factor.

  • The “strength ratio” (SR) is defined as the inverse of the reserve factor. Here again; the factor of safety is taken into account for the calculation of strength ratio.


Table II.1.2: Summary of failure criteria available in FeResPost and information on what can be calculated.
Criterion Material Section Derived
Name Type Number Stress F.I.R.F. and S. R.
“Tresca2D” metallic II.1.10.1 yes yes yes
“VonMises2D” metallic II.1.10.2 yes yes yes
“VonMises3D” metallic II.1.10.3 yes yes yes
“MaxStress” tape or fabricII.1.10.4 no yes yes
“MaxStress3D” tape or fabricII.1.10.5 no yes yes
“MaxStrain” tape or fabricII.1.10.6 no yes yes
“MaxStrain3D” tape or fabricII.1.10.7 no yes yes
“CombStrain2D” tape or fabricII.1.10.8 no yes yes
“MaxTotalStrain” tape or fabricII.1.10.6 no yes yes
“MaxTotalStrain3D” tape or fabricII.1.10.7 no yes yes
“CombTotalStrain2D”tape or fabricII.1.10.8 no yes yes
“TsaiHill” fabric II.1.10.9 no yes yes
“TsaiHill_b” fabric II.1.10.10 no yes yes
“TsaiHill_c” fabric II.1.10.11 no yes yes
“TsaiHill3D” fabric II.1.10.12 no yes yes
“TsaiHill3D_b” fabric II.1.10.13 no yes yes
“TsaiWu” fabric II.1.10.14 no yes yes
“TsaiWu3D” fabric II.1.10.15 no yes yes
“Hoffman” fabric II.1.10.16 no yes yes
“Puck” tape II.1.10.17 no yes yes
“Puck_b” tape II.1.10.18 no yes yes
“Puck_c” tape II.1.10.19 no yes yes
“Hashin” tape II.1.10.20 no yes yes
“Hashin_b” tape II.1.10.20 no yes yes
“Hashin_c” tape II.1.10.20 no yes yes
“Hashin3D” tape II.1.10.21 no yes yes
“Hashin3D_b” tape II.1.10.21 no yes yes
“Hashin3D_c” tape II.1.10.21 no yes yes
“YamadaSun” tape II.1.10.22 no yes yes
“YamadaSun_b” fabric II.1.10.23 no yes yes
“Honey3D” honeycomb II.1.10.24 no yes yes
“HoneyShear” honeycomb II.1.10.25 no yes yes
“HoneyShear_b” honeycomb II.1.10.26 yes yes yes
“Ilss” all II.1.10.27 yes yes yes
“Ilss_b” all II.1.10.27 yes yes yes

Note that many of the criteria presented here are particular cases of a general quadratic criterion that requires first the calculation of a failure index:

f = F11σ112 + F 22σ222 + F 33σ332 + F 44σ232 + F 55σ312 + F 66σ122 + 2F12σ11σ22 + 2F23σ22σ33 + 2F31σ33σ11 + F1σ11 + F2σ22 + F3σ33 + F4σ23 + F5σ31 + F6σ12, (II.1.115)

then a test is done on the calculated value:

f 1.

This means that no failure occurs if f 1 (ply or laminate passes the failure test) and one has failure if f > 1.

Several failure theories discussed below are obtained by expressing the coefficients in the expressions above by expressions depending on the material allowables. Also for the Tsai-Wu criteria discussed in section II.1.10.14 and II.1.10.15, the parameters Fij are directly characterized for the material.

Note that the 2D criteria defined in this section often correspond to the failure criteria defined in ESAComp.


Table II.1.3: Correspondence between the ESAComp failure criteria and the failure criteria defined in CLA module.
ESAComp failure criterion CLA criterion ID section
“Maximum Shear Stress (Tresca)” “Tresca2D” II.1.10.1
“Von Mises” “VonMises2D” II.1.10.2
“Maximum Strain” (in ply axes) “MaxStrain” II.1.10.6
“Maximum Stress” (in ply axes) “MaxStress” II.1.10.4
“Tsai-Wu” “TsaiWu” II.1.10.14
“Tsai-Hill” “TsaiHill” II.1.10.9
“Hoffman” “Hoffman” II.1.10.16
“Simple Puck” “Puck” II.1.10.17
“Modified Puck” “Puck_b” II.1.10.17
“Hashin” “Hashin” II.1.10.20

II.1.10.1 Tresca criterion (2D)

Using the stress tensor components a scalar equivalent shear stress is given by:

τeqTresca2D = max (1 2 |σI - σII| , 1 2 |σI| , 1 2 |σII|) .

Ply passes the failure criterion if

τeqTresca2D σtall.

This equivalent shear stress allows to define a Tresca failure index as follows:

FITresca2D = 2 τeqTresca2D σtall ,

The reserve factor is given by:

RFTresca2D = 1 FoS FITresca2D = σtall FoS 2 τeqTresca2D,

and the strength ratio by:

SRTresca2D = FoS FITresca2D = FoS 2 τeqTresca2D σtall .

This criterion is referred to as “Tresca2D” criterion in FeResPost.

II.1.10.2 Von Mises criterion (2D)

Using the stress tensor components a scalar equivalent shear stress is given by:

σeqVonMises2D = σ11 2 + σ22 2 - σ11 σ22 + 3τ12 2.

Ply passes the failure criterion if

σeqVonMises2D σtall.

The corresponding failure index is:

FIVonMises2D = σeqVonMises2D σtall ,
(II.1.116)

The reserve factor is given by:

RFVonMises2D = 1 FoS FIVonMises2D = σtall FoS σeqVonMises2D,
(II.1.117)

and the strength ratio by:

SRVonMises2D = FoS FIVonMises2D = FoS σeqVonMises2D σtall .
(II.1.118)

This criterion is referred to as “VonMises2D” criterion in FeResPost.

II.1.10.3 Von Mises criterion (3D)

Using the stress tensor components a scalar equivalent shear stress is given by:

σeqVonMises3D = σ11 2 + σ22 2 + σ33 2 - σ11 σ22 - σ22 σ33 - σ33 σ11 + 3τ12 2 + 3τ23 2 + 3τ31 2.

Ply passes the failure criterion if

σeqVonMises4D σtall.

As for the 2D version, the corresponding failure index is given by II.1.116, the reserve factor by II.1.117 and the strength ratio by II.1.118. This criterion is referred to as “VonMises3D” criterion in FeResPost.

II.1.10.4 Maximum stress criterion

The failure index is calculated as follows:

FIMaxStress = max ( | σ11 σ11all | , | σ22 σ22all | , | τ12 τ12all |) ,

in which the σ11all and σ22all allowables depend on the sign of σ11 and σ22 respectively. (Generally, tensile and compressive allowables are different for orthotropic materials.) Ply passes the test if the three following conditions are satisfied:

|σ11| σ11all,

|σ22| σ22all,

|τ12| τ12all.

The reserve factor is calculated as follows:

RFMaxStress = 1 FoS FIMaxStress,

and the strength ratio is given by:

SRMaxStress = FoS FIMaxStress.

This criterion is referred to as “MaxStress” criterion in FeResPost.

II.1.10.5 Maximum stress criterion (3D)

The failure index is calculated as follows:

FIMaxStress3D = max ( | σ11 σ11all | , | σ22 σ22all | , | σ33 σ33all | , | τ12 τ12all | , | τ23 τ23all | , | τ31 τ31all |) ,

in which the σ11all, σ22all and σ33all allowables depend on the sign of σ11, σ22 and σ33 respectively. (Generally, tensile and compressive allowables are different for orthotropic materials.) Ply passes the test if the six following conditions are satisfied:

|σ11| σ11all,

|σ22| σ22all,

|σ33| σ33all,

|τ12| τ12all,

|τ23| τ23all,

|τ31| τ31all.

The reserve factor is calculated as follows:

RFMaxStress3D = 1 FoS FIMaxStress3D,

and the strength ratio is given by:

SRMaxStress3D = FoS FIMaxStress3D.

This criterion is referred to as “MaxStress3D” criterion in FeResPost.

II.1.10.6 Maximum strain criteria (2D)

The criterion is very similar to maximum stress criterion, except that it is calculated from the mechanical (or equivalent) strain tensor components. The failure index is calculated as follows:

FIMaxStrain = max ( |ϵ11Mech ϵ11all | , |ϵ22Mech ϵ22all | , |γ12Mech γ12all |) ,

in which the ϵ11all and ϵ22all allowables depend on the sign of ϵ11Mech and ϵ22Mech respectively. Ply or laminate passes the test if the three following conditions are satisfied:

|ϵ11| ϵ11all,

|ϵ22| ϵ22all,

|γ12| γ12all.

The reserve factor is calculated as follows:

RFMaxStrain = 1 FoS FIMaxStrain,

and the strength ratio is given by:

SRMaxStrain = FoS FIMaxStrain.

This criterion is referred to as “MaxStrain” criterion in FeResPost.

FeResPost proposes a second version of the criterion where the “total” strain tensor {ϵ} is used instead of the mechanical strain tensor {ϵMech}. This version of the criterion is referred to as “MaxTotalStrain” criterion in FeResPost.

II.1.10.7 Maximum strain criterion (3D)

The criterion is very similar to maximum stress criterion, except that it is calculated from the mechanical (or equivalent) strain tensor components. The failure index is calculated as follows:

FIMaxStrain3D = max ( |ϵ11Mech ϵ11all | , |ϵ22Mech ϵ22all | , |ϵ33Mech ϵ33all | , |γ12Mech γ12all | , |γ23Mech γ23all | , |γ31Mech γ31all |) .

in which the ϵ11all, ϵ22all and ϵ33all allowables depend on the sign of the corresponding mechanical strain tensor component. Ply or laminate passes the test if the six following conditions are satisfied:

|ϵ11| ϵ11all,

|ϵ22| ϵ22all,

|ϵ33| ϵ33all,

|γ12| γ12all,

|γ23| γ23all,

|γ31| γ31all.

The reserve factor is calculated as follows:

RFMaxStrain3D = 1 FoS FIMaxStrain3D,

and the strength ratio is given by

SRMaxStrain3D = FoS FIMaxStrain3D.

This criterion is referred to as “MaxStrain3D” criterion in FeResPost.

FeResPost proposes a second version of the criterion where the “total” strain tensor {ϵ} is used instead of the mechanical strain tensor {ϵMech}. This version of the criterion is referred to as “MaxTotalStrain3D” criterion in FeResPost.

II.1.10.8 Combined strain criterion (2D)

The criterion is a strain criterion that uses a combination of several components of the strain tensor. This criterion can be considered as a Tsai-type criterion adapted to strain tensor. The combined strain failure index is calculated as follows:

FICombStrain2D = max [ (ϵ11 Mech ϵ11all ) 2 + (γ12Mech γ12all ) 2, (ϵ22 Mech ϵ22all ) 2 + (γ12Mech γ12all ) 2] ,

in which the ϵ11all and ϵ22all allowables depend on the sign of ϵ11Mech and ϵ22Mech respectively. (The criterion is calculated from the mechanical or equivalent strain tensor components.) Ply or laminate passes the failure criterion if the two following conditions are respected:

(ϵ11Mech ϵ11all ) 2 + (γ12Mech γ12all ) 2 1,

(ϵ22Mech ϵ22all ) 2 + (γ12Mech γ12all ) 2 1.

The reserve factor is calculated as follows:

RFCombStrain2D = 1 FoS FICombStrain2D,

and the strength ratio is given by:

SRCombStrain2D = FoS FICombStrain2D.

This criterion is referred to as “CombStrain2D” criterion in FeResPost.

FeResPost proposes a second version of the criterion where the “total” strain tensor {ϵ} is used instead of the mechanical strain tensor {ϵMech}. This version of the criterion is referred to as “CombTotalStrain2D” criterion in FeResPost.

II.1.10.9 Tsai-Hill criterion

The Tsai-Hill criterion is a quadratic criterion. The 2D version of this criterion has a failure index calculated as follows:

FITsaiHill = ( σ11 σ11all ) 2 + ( σ22 σ22all ) 2 + ( τ12 τ12all ) 2 - σ11σ22 (σ11all) 2.

Here again, the allowables σ11all and σ22all depend on the signs of σ11 and σ22 respectively. Ply passes the failure criterion if

FITsaiHill 1.

The Tsai-Hill failure index depends quadratically on the different components of the stress tensor. Therefore, the reserve factor is calculated as follows:

RFTsaiHill = 1 FoSF ITsaiHill,
(II.1.119)

and the strength ratio is given by:

SRTsaiHill = FoSF ITsaiHill.
(II.1.120)

This criterion is referred to as “TsaiHill” criterion in FeResPost.

II.1.10.10 Tsai-Hill criterion (version b)

This criterion is very similar to the one described in section II.1.10.10. It differs by the fact that only the tensile allowables σ11t,all and σ22t,all are considered for the calculations.

The calculation of reserve factor is as for the more classical Tsai-Hill criterion (II.1.119) and (II.1.120). This criterion is referred to as “TsaiHill_b” criterion in FeResPost.

II.1.10.11 Tsai-Hill criterion (version c)

This criterion is very similar to the one described in section II.1.10.9. The criterion has a failure index calculated as follows:

FITsaiHill_c = ( σ11 σ11all ) 2 + ( σ22 σ22all ) 2 + ( τ12 τ12all ) 2 - σ11σ22 (σ11all) 2.

The criterion differs from the previous one by the fact that the allowable σ11all is used in the calculation. This allowable is set to σ11t,all or σ11c,all depending on the sign of σ11σ22.

The calculation of reserve factor is as for the more classical Tsai-Hill criterion (II.1.119) and (II.1.120). This criterion is referred to as “TsaiHill_c” criterion in FeResPost.

II.1.10.12 Tsai-Hill criterion (3D)

The Tsai-Hill criterion is a quadratic criterion. The 3D version of this criterion has a failure index calculated as follows:

FITsaiHill3D = ( σ11 σ11all ) 2 + ( σ22 σ22all ) 2 + ( σ33 σ33all ) 2 + ( τ12 τ12all ) 2 + ( τ23 τ23all ) 2 + ( τ31 τ31all ) 2 - ( 1 (σ11all) 2 + 1 (σ22all) 2 - 1 (σ33all) 2 ) σ11σ22 - ( 1 (σ22all) 2 + 1 (σ33all) 2 - 1 (σ11all) 2 ) σ22σ33 - ( 1 (σ33all) 2 + 1 (σ11all) 2 - 1 (σ22all) 2 ) σ33σ11.(II.1.121)

The allowables σ11all, σ22all and σ33all depend on the signs of σ11, σ22 and σ33 respectively. Ply passes the failure criterion if

FITsaiHill3D 1.

The Tsai-Hill failure index depends quadratically on the different components of the stress tensor. The reserve factor is calculated as follows:

RFTsaiHill3D = 1 FoSF ITsaiHill3D,
(II.1.122)

and the strength ratio is given by:

SRTsaiHill3D = FoSF ITsaiHill3D.
(II.1.123)

This criterion is referred to as “TsaiHill3D” criterion in FeResPost.

II.1.10.13 Tsai-Hill criterion (3D version b)

This criterion is very similar to the one described in section II.1.10.13. It differs by the fact that only the tensile allowables σ11t,all, σ22t,all and σ33t,all are considered for the calculations.

The calculation of reserve factor is as for the more classical Tsai-Hill criterion (II.1.122) and (II.1.123). This criterion is referred to as “TsaiHill3D_b” criterion in FeResPost.

II.1.10.14 Tsai-Wu criterion

The Tsai-Wu criterion is a quadratic criterion. The 2D version of this criterion has a failure index calculated as follows:

FITsaiWu = σ112 σ11t,allσ11c,all + σ222 σ22t,allσ22c,all + ( τ12 τ12all ) 2 + ( 1 σ11t,all - 1 σ11c,all ) σ11 + ( 1 σ22t,all - 1 σ22c,all ) σ22 + 2F12TWσ 11σ22.(II.1.124)

In this expression, F12TW is a material parameter to be obtained by characterization tests. This parameter must satisfy the following relation:

(F12TW) 2 < 1 σ11t,allσ11c,allσ22t,allσ22c,all.
(II.1.125)

Its units are, for example, [Pa-2]. Sometimes the corresponding dimensionless parameter is used instead:

F12* = F 12TWσ 11t,allσ11c,allσ22t,allσ22c,all.
(II.1.126)

This dimensionless parameter must satisfy the relation:

-1 F12* 1.
(II.1.127)

The value F12* = -12 corresponds to a generalized Von Mises criterion. The value

F12TW = - 1 2σ11t,allσ11c,all
(II.1.128)

leads to the Hoffman criterion discussed in section II.1.10.16. Ply passes the failure criterion if

FITsaiWu 1.

In some of the terms of expression (124) the components of Cauchy stress tensor appear linearly, and other terms, they appear quadratically. Therefore, the reserve factor expression is a little more complicated. FeResPost calculates it as follows:

a = σ112 σ11t,allσ11c,all + σ222 σ22t,allσ22c,all + ( τ12 τ12all ) 2 + 2F 12TW σ 11σ22,

b = ( 1 σ11t,all - 1 σ11c,all ) σ11 + ( 1 σ22t,all - 1 σ22c,all ) σ22,

c = -1,

RFTsaiWu = - b + b2 - 4ac 2 FoS a ,

and the strength ratio is given by:

SRTsaiWu = 1 RFTsaiWu.

This criterion is referred to as “TsaiWu” criterion in FeResPost.

II.1.10.15 Tsai-Wu criterion (3D)

The 3D version of Tsai-Wu failure criterion leads to the following expression of the failure index:

FITsaiWu3D = σ112 σ11t,allσ11c,all + σ222 σ22t,allσ22c,all + σ332 σ33t,allσ33c,all + ( τ12 τ12all ) 2 + ( τ23 τ23all ) 2 + ( τ31 τ31all ) 2 + ( 1 σ11t,all - 1 σ11c,all ) σ11 + ( 1 σ22t,all - 1 σ22c,all ) σ22 + ( 1 σ33t,all - 1 σ33c,all ) σ33 + 2F12TWσ 11σ22 + 2F23TWσ 22σ33 + 2F31TWσ 33σ11.(II.1.129)

The values of F23TW and F31TW are submitted to the same limitations as F12TW in section II.1.10.14. Ply passes the failure criterion if

FITsaiWu3D 1.

The RF calculation is done as follows:

a = σ112 σ11t,allσ11c,all + σ222 σ22t,allσ22c,all + σ332 σ33t,allσ33c,all + ( τ12 τ12all ) 2 + ( τ23 τ23all ) 2 + ( τ31 τ31all ) 2 + 2F12TWσ 11σ22 + 2F23TWσ 22σ33 + 2F31TWσ 33σ11, (II.1.130)

b = ( 1 σ11t,all - 1 σ11c,all ) σ11 + ( 1 σ22t,all - 1 σ22c,all ) σ22 + ( 1 σ33t,all - 1 σ33c,all ) σ33,

c = -1,

RFTsaiWu3D = - b + b2 - 4ac 2 FoS a ,

and the strength ratio is given by:

SRTsaiWu3D = 1 RFTsaiWu3D.

This criterion is referred to as “TsaiWu3D” criterion in FeResPost.

II.1.10.16 Hoffman criterion

The Hoffman criterion is very similar to the Tsai-Wu criterion. Only the last term of failure index is different:

FIHoffman = σ112 σ11t,allσ11c,all + σ222 σ22t,allσ22c,all + ( τ12 τ12all ) 2 + ( 1 σ11t,all - 1 σ11c,all ) σ11 + ( 1 σ22t,all - 1 σ22c,all ) σ22 - σ11σ22 σ11t,allσ11c,all.(II.1.131)

Ply passes the failure criterion if

FIHoffman 1.

In some of the terms of previous expression the components of Cauchy stress tensor appear linearly, and other terms, they appear quadratically. Therefore, the reserve factor expression is a little more complicated. FeResPost calculates it as follows:

a = σ112 σ11t,allσ11c,all + σ222 σ22t,allσ22c,all + ( τ12 τ12all ) 2 - σ11σ22 σ11t,allσ11c,all,

b = ( 1 σ11t,all - 1 σ11c,all ) σ11 + ( 1 σ22t,all - 1 σ22c,all ) σ22,

c = -1,

RFHoffman = - b + b2 - 4ac 2 FoS a ,

and the strength ratio is given by:

SRHoffman = 1 RFHoffman.

This criterion is referred to as “Hoffman” criterion in FeResPost.

II.1.10.17 Puck criterion

This criterion is adapted to the justification of laminates with unidirectional plies. This criterion distinguishes two failure mode: one fiber failure mode in direction 1 and one matrix failure mode. One distinguishes three versions of the Puck criterion.

The first version of Puck failure index is calculated as follows:

FIPuck = max ( | σ11 σ11all | , ( σ22 σ22all ) 2 + ( τ12 τ12all ) 2) ,

in which the allowables σ11all and σ22all depend on the signs of σ11 and σ22 respectively. Ply passes the failure criterion if the two following conditions are satisfied

|σ11| σ11all,

( σ22 σ22all ) 2 + ( τ12 τ12all ) 2 1.

The reserve factor is simply given by:

RFPuck = 1 FoS max ( | σ11 σ11all | , ( σ22 σ22all ) 2 + ( τ12 τ12all ) 2) ,

and the strength ratio is given by:

SRPuck = FoS max ( | σ11 σ11all | , ( σ22 σ22all ) 2 + ( τ12 τ12all ) 2) .

This criterion is referred to as “Puck” failure criterioncriterion in FeResPost.

II.1.10.18 Puck “b” criterion

A modified version of Puck criterion is defined as follows:

FIPuck_b = max ( | σ11 σ11all | , σ222 σ22c,allσ22t,all + ( τ12 τ12all ) 2 + σ 22 ( 1 σ22t,all - 1 σ22c,all )) .

Ply passes the failure criterion if the two following conditions are satisfied

|σ11| σ11all,

σ222 σ22c,allσ22t,all + ( τ12 τ12all ) 2 + σ 22 ( 1 σ22t,all - 1 σ22c,all ) 1.

The reserve factor is calculated as follows:

RFa = σ11all FoS σ11,

a = σ222 σ22c,allσ22t,all + ( τ12 τ12all ) 2,

b = σ22 ( 1 σ22t,all - 1 σ22c,all ) ,

c = -1,

RFb = - b + b2 - 4ac 2 FoS a ,

RFPuck_b = min (RFa,RFb) .

The calculation of failure index is based on the calculation of the reserve factor:

FIPuck_b = 1 RFPuck_2,

in which the safety factor used in the calculation of the RF is 1. The advantage of this new expression is that the failure index is proportional to the components of stress tensor. This criterion is referred to as “Puck_b” criterion in FeResPost.

For the strength ratio, one uses the same expression, but the safety factor is not set to 1:

SRPuck_b = 1 RFPuck_2.

II.1.10.19 Puck “c” criterion

Sometimes, an additional term is given in the expression corresponding to the fiber failure and the modified version of Puck criterion is defined as follows:

FIPuck_c = max ( | σ11 σ11all | , ( σ11 2σ11t,all ) 2 + σ222 σ22c,allσ22t,all + ( τ12 τ12all ) 2 + σ 22 ( 1 σ22t,all - 1 σ22c,all )) .

Ply passes the failure criterion if the two following conditions are satisfied

|σ11| σ11all,

( σ11 2σ11t,all ) 2 + σ222 σ22c,allσ22t,all + ( τ12 τ12all ) 2 + σ 22 ( 1 σ22t,all - 1 σ22c,all ) 1.

The calculation of reserve factor is done as for version “b” of Puck criterion, but one uses a modified expression for a parameter:

a = ( σ11 2σ11t,all ) 2 + σ222 σ22c,allσ22t,all + ( τ12 τ12all ) 2.

This criterion is referred to as “Puck_c” criterion in FeResPost.

II.1.10.20 Hashin criteria

This criterion is meant to be used for uni-directional materials. Direction 1 is assumed to be direction of fibers. One first presents the way the reserve factor is calculated:

Finally, the reserve factor is given by:

RFHashin = min (RFb,RFc) .

Here again, the calculation of failure index is based on the calculation of the reserve factor:

FIHashin = 1 RFHashin,

in which the safety factor used in the calculation of the RF is 1, and the strength ratio is calculated as

SRHashin = 1 RFHashin,

in which one keeps the value of safety factor.

The criterion presented above is referred to by “Hashin” criterion in FeResPost. Correspondingly, one defines version “Hashin_b” in which only the fiber failure is checked and “Hashin_c” in which only the matrix failure is checked. (These correspond to the values RFb and RFc calculated above.)

II.1.10.21 Hashin criteria (3D)

A 3D version of the 2D criterion defined in section II.1.10.20 is defined as follows

Finally, the reserve factor is given by:

RFHashin3D = min (RFb,RFc) .

Here again, the calculation of failure index is based on the calculation of the reserve factor:

FIHashin3D = 1 RFHashin3D,

in which the safety factor used in the calculation of the RF is set to 1, and the strength ratio is calculated as

SRHashin3D = 1 RFHashin3D,

in which one keeps the value of safety factor.

The criterion presented above is referred to by “Hashin3D” criterion in FeResPost. Correspondingly, one defines version “Hashin3D_b” in which only the fiber failure is checked and “Hashin3D_c” in which only the matrix failure is checked. (These correspond to the values RFb and RFc calculated above.)

II.1.10.22 Yamada-Sun criterion

The Yamada-Sun criterion is a kind of Tsai criterion adapted to tape (unidirectional) materials. Its failure index is calculated as follows:

FIYamadaSun = ( σ11 σ11all ) 2 + ( τ12 τ12all ) 2.

The allowable σ11all depends on the sign of σ11. Ply passes the failure criterion if the following condition is satisfied

( σ11 σ11all ) 2 + ( τ12 τ12all ) 2 1.

The reserve factor is calculated as follows:

RFYamadaSun = 1 FoSF IYamadaSun,

and the strength ratio is given by:

SRYamadaSun = FoSF IYamadaSun.

This criterion is referred to as “YamadaSun” in FeResPost.

II.1.10.23 Yamada-Sun criterion (version b)

A second version of Yamada-Sun criterion more adapted to fabrics is proposed. The “tape” version of Yamada-Sun criterion is calculated in two directions, and the worst direction is considered for failure. The failure index is calculated as follows:

FIYamadaSun_b = max [ ( σ11 σ11all ) 2 + ( τ12 τ12all ) 2; ( σ22 σ22all ) 2 + ( τ12 τ12all ) 2] .

The allowables σ11all and σ22all depends on the signs of σ11 and σ22 respectively. Ply passes the failure criterion if the two following conditions are satisfied:

( σ11 σ11all ) 2 + ( τ12 τ12all ) 2 1,

( σ22 σ22all ) 2 + ( τ12 τ12all ) 2 1.

The reserve factor is calculated as follows:

RFYamadaSun_b = 1 FoSF IYamadaSun_b,

and the strength ratio is given by:

SRYamadaSun_b = FoSF IYamadaSun_b.

This criterion is referred to as “YamadaSun_b” in FeResPost.

II.1.10.24 3D honeycomb criterion

A general honeycomb criterion uses the out-of-plane tension/compression and the two out-of-plane shear components of the Cauchy stress tensor. The criterion read as follows:

FIHoney3D = ( σ33 σ33all ) 2 + ( τ23 τ23all ) 2 + ( τ31 τ31all ) 2.

The allowable σ33all depends on the sign of σ33 (Generally, the compressive allowable is significantly smaller than the tensile one). The honeycomb material is generally defined in such a way that the allowable τ31all = τ L is in ribbon direction (longitudinal allowable) and τ23all is the transverse allowable τW . Core passes the failure criterion if the following condition is satisfied

( σ33 σ33all ) 2 + ( τ23 τ23all ) 2 + ( τ31 τ31all ) 2 1.

The reserve factor is calculated as follows:

RFHoney3D = 1 FoS FIHoney3D,

and the strength ratio is given by:

SRHoney3D = FoS FIHoney3D.

This criterion is referred to as “Honey3D” in FeResPost.

II.1.10.25 Honeycomb shear criterion

Depending of the modeling, the component σ33 of Cauchy stress tensor is sometimes zero. Then a simplified “shear” criterion is often used:

FIHoneyShear = ( τ23 τ23all ) 2 + ( τ31 τ31all ) 2.

Core passes the failure criterion if the following condition is satisfied

( τ23 τ23all ) 2 + ( τ31 τ31all ) 2 1.

The reserve factor is calculated as follows:

RFHoneyShear = 1 FoS FIHoneyShear,

and the strength ratio is given by:

SRHoneyShear = FoS FIHoneyShear.

This criterion is referred to as “HoneyShear” in FeResPost.

II.1.10.26 Honeycomb simplified shear criterion

Sometimes, one simplifies the criterion described in section II.1.10.25 by using the smallest shear allowable τW . This new criterion is referred to as “HoneyShear_b”.

As a single allowable is used, an equivalent shear stress can be defined:

τshear = τ13 2 + τ23 2.
(II.1.132)

The failure index is then calculated as follows:

FIHoneyShear_b = τshear τ23all .

Core passes the failure criterion if the following condition is satisfied

τ132 + τ232 τ23all.

The reserve factor is calculated as follows:

RFHoneyShear_b = 1 FoS FIHoneyShear_b,

and the strength ratio is given by:

SRHoneyShear_b = FoS FIHoneyShear_b.

This criterion is referred to as “HoneyShear_b” in FeResPost.

II.1.10.27 Inter-laminar shear criterion

The inter-laminar shear criterion is based on the comparison of inter-laminar shear stress with resin shear allowable:

FIIlss = τinter-laminar τinter-laminarall,

In which the inter-laminar shear stress is a scalar stress calculated as follows:

τinter-laminar = τxz 2 + τyz 2.
(II.1.133)

An interface between two plies passes the failure criterion if the following condition is satisfied

τxz2 + τyz2 τinter-laminarall.

The reserve factor is of course:

RFIlss = 1 FoS FIIlss,

and the strength ratio is given by:

SRIlss = FoS FIIlss.

This criterion is different from the other criteria in this that it does not use ply material allowables. Instead, the ply ilss allowable or the laminate ilss allowable is used.

Note also that FeResPost calculates the inter-laminar shear criterion on the lower face of plies only. This criterion is referred to as “Ilss” in FeResPost.

A second version of the inter-laminar shear stress criterion, referred to as “Ilss_b” criterion in FeResPost, is defined in FeResPost. This criterion differs from the more usual “Ilss” criterion by the fact that its calculation is not limited to the lower face of laminate plies. It can also be calculated at mid-ply or ply upper face. This can be handy when one wishes to evaluate the ILSS criterion on finite element results that are extracted at mid ply thickness only. (Actually, the calculation of ILSS failure criterion using stresses extracted from FE results, or calculated from FE shell forces and moments, is the reason that has justified the introduction of this second version of ILSS criterion.)

II.1.11 Temperature diffusion in laminates

The thermal conservation equation in a solid material is written as follows:

ρCpT t = -q + r,

where T is the temperature, Cp is the heat capacity of the material and vector q is the heat flux. Note that Cp and ρ are used for transient thermal calculations only. Generally, the heat flux is related to the gradient of temperature by Fourrier’s law:

q = -λT T,

where λT is the tensor of thermal conductivity coefficients. We consider that thermal conductivity tensor is symmetric. A justification of this symmetry can be found in [LLK+86] with part of the demonstration in [LL13].

When thermal conductivity calculations are performed with laminates, two homogenized quantities must first be calculated:

These two quantities are obtained by integrating material properties along laminate thickness.

II.1.11.1 Material thermal parameters

Two scalar parameters influence the transient thermal behavior of laminates: the density ρ and the heat capacity (per unit of mass) Cp. As these two parameters are scalar, their characteristics do not depend on the possible anisotropy of the material.

On the other hand, the thermal conductivity λT is a 2nd order tensor. Generally, for an anisotropic material, the thermal conductivity equation can be written as follows:

( q1 q2 q3 ) = - (λ11T λ 12T λ 31T λ12T λ 22T λ 23T λ31T λ 23T λ 33T )T.

For an orthotropic material, the previous equations reduces to:

( q1 q2 q3 ) = - (λ11T 0 0 0 λ22T 0 0 0 λ33T )T.

Then, only three material parameters define the thermal conductivity. Finally, for an isotropic material the thermal conductivity is defined by a single parameter λT :

( q1 q2 q3 ) = - (λT 0 0 0 λT 0 0 0 λT )T.

II.1.11.2 In-plane and out-of-plane components

As has been done for the motion equations, one assumes a decoupling of in-plane laminate thermal conductivity and out-of-plane conductivity. Therefore, the thermal flux is separated into an in-plane flux:

{q12} = ( q1 q2 ) ,

and the out-of-plane component q3.

Correspondingly, the tensor of thermal conductivity coefficients is separated into an in-plane conductivity tensor:

[λT ] 12 = ( λ11T λ 12T λ12T λ 22T ) ,

and the out-of-plane conductivity λ33T . The “shear” components λ31T and λ23T are neglected in the homogenization theory. (This means that out-of-plane and in-plane conductivities are decoupled.)

II.1.11.3 In-plane rotations of vectorial and tensorial properties

The material scalar properties are left unmodified by in-plane rotations. The same is true for the out-of-plane quantities q3 and λ33T . The transformation of components for {q} and [λT ] is noted with the transformation matrices defined in expressions (II.1.10) to (II.1.10):

[λT ] 12 = [S-](θ) [λT ] xy [S+] (θ),

[λT ] xy = [S+] (θ) [λT ] 12 [S-](θ),

{q}xy = [S+] (θ) {q}12,

{q}12 = [S-](θ) {q}xy.

II.1.11.4 Integration along the laminate thickness

One considers separately the laminate thermal in-plane conductivity, thermal out-of-plane conductivity and thermal capacity.

II.1.11.4.1 In-plane conductivity

To calculate the laminate in-plane thermal conductivity properties, one assumes that temperature is constant along the laminate thickness. Consequently, the temperature gradient does not depend on z. The thermal flux {q}xy however depends on z because the thermal conductivity does:

{q}xy(z) = [λT ] xy(z) {T }xy.

The laminate in-plane thermal conductivity is calculated as follows:

{Q}xy =-h2-h2 {q} xy(z) dz, =-h2-h2 [λT ] xy(z) {T }xy dz, = (-h2-h2 [λT ] xy(z) dz) {T }xy, = (-h2-h2 [S +] (θ)(z) [λT ] 12(z) [S-](θ)(z) dz) {T }xy, = [ΛT ] xy {T }xy.

In the previous equation, one introduced the laminate in-plane thermal conductivity:

[ΛT ] xy =-h2-h2 [S +] (θ)(z) [λT ] 12(z) [S-](θ)(z) dz, = k=1N [S +] (θk) [λkT ] 12 [S-](θk)ek,

where ek is the thickness of ply k.

II.1.11.4.2 Out-of-plane conductivity

One assumes that out-of-plane thermal flux is constant across laminate thickness. Then, as thermal conductivity depends on z, so will the out-of-plane gradient of temperature:

Tz = qz λ33T .

The integration across the thickness gives the difference of temperature between upper and lower laminate surfaces:

Tsup - Tinf =-h2-h2T z dz, =-h2-h2 qz λ33T dz, = (-h2-h2 1 λ33T dz)qz, = R33T q z.

In previous expression, one introduced the out-of-plane thermal resistance:

R33T =-h2-h2 1 λ33T dz, = k=1N 1 (λ33T )kek.

II.1.11.4.3 Thermal capacity

To estimate the laminate thermal capacity, one again assumes a temperature constant across the laminate thickness. Then, the heat energy stored per unit of surface is:

U =-h2-h2ρC pT dz, = (-h2-h2ρC p dz)T, = (ρCph)lamT.

In previous expression, one introduced the surfacic thermal capacity

(ρCph)lam =-h2-h2ρC p dz, = k=1N (ρC p) kek.

Note that in Nastran, when a thermal material MAT4 or MAT5 is defined, the density ρ and the heat capacity per unit of mass Cp are defined separately. So it is the responsibility of the user to select appropriate values for these two quantities. Also, in Nastran, the thickness is defined separately in the PSHELL property card. (PCOMP or PCOMPG cards do not accept thermal materials.)

II.1.12 Moisture diffusion in laminates

The moisture conservation equation in a solid material is written as follows:

M t = -qM,

where M is the moisture content (for example in [kg/m3]) and vector qM is the massic flux of moisture (in [kg/m2s]). When several materials are present in a structure, as often in laminates, it is more practical to work with moisture percentage H (in [%w]). The moisture percentage is related to moisture content by the following expression:

M = c H,

where c is the moisture coefficient in [kg/(m3%w)].

Generally, the moisture flux is related to the gradient of moisture by Fick’s law, and the moisture diffusion equation can be written:

H t = (λH H).

Here λH is the tensor of moisture conductivity coefficients. This expression is very similar to the equation of thermal diffusion:

As one works with moisture percentages, nothing equivalent to the laminate thermal capacity (ρCph) lam is defined for moisture.

II.1.13 Units

All the quantities introduced in this Chapter have been given without dimensions. Since version 3.0.1, units can be attributed to all the CLA quantities defined in FeResPost, except of course the dimensionless quantities. This allows the user to express all the CLA quantities in a units system compatible, for example, with the unit system used for finite element modeling.

An engineer should be able to figure out the units of the different quantities introduced in this Chapter from the definitions given for the quantities or from the expressions used for their calculations. However, we think it might be useful to remind the units of the different quantities to avoid ambiguities.

In the rest of the section, one assumes a consistent set of units compatible with MKS system is used. This is what we recommend for FeResPost, as well as finite element models. The default “base” units are:

One notes that units have been defined for force and energy, despite the fact that they can be derived from mass, length and time units. Practically, the definition of additional base units for the force and energy are of interest for mechanical engineers.

All the other units of FeResPost are obtained by combining these base units. The most important ones are summarized in Tables II.1.4, II.1.5 and II.1.6.

If one of the base units above is modified, the user is responsible for modifying the derived units coherently. For example, we expressed the moisture content in [%w]. This influences the units of moisture content H as well as the units of coefficients of moisture expansion β.


Table II.1.4: Units of the different quantities related to loading, stresses or load responses.
Quantities Symbols Units
Strains ϵ, γ or Γ [L/L] or [-]
Stresses σ or τ [F/L2]
Curvatures κ [1/L]
Forces {N} or {Q} [F/L]
Moments {M} [FL/L] or [F]
Temperatures T [T]
Moistures H [W] (always [%w])
Failure indices F I []
Reserve factors RF []


Table II.1.5: Units of the different quantities related to material properties.
Quantities Symbols Units
Materials stiffnesses or moduli Cijkl, [C], E or G [F/L2]
Materials compliance matrices cijkl, [c], [g] [L2/F] ]
Poisson coefficients νij [-]
Thermal conductivity λijT [E/(LT)]
Coefficients of thermal expansion α [L/(LT)] or [1/T]
Moisture conductivity λij H [1/(Lt)]
Coefficients of moisture expansion β [L/(LW)] or [1/W]
Density ρ [M/L3]
Heat specific capacity Cp [E/(MT)]
Coefficients of quadratic failure criteria F i [L2/F]
Coefficients of quadratic failure criteria F ij [L4/F2]


Table II.1.6: Units of the different quantities related to laminate properties.
Quantities Symbols Units
Thicknesses t [L]
Membrane stiffness matrix [A] [F/L]
Membrane-bending coupling stiffness matrix [B] [F]
Bending stiffness matrix [D] [FL]
Out-of-plane shear stiffness matrix [G] [F/L]
Membrane compliance matrix [a] [L/F]
Membrane-bending coupling compliance matrix[b] [1/F]
Bending compliance matrix [d] [1/(FL)]
Out-of-plane shear compliance matrix [g] [L/F]
In-plane thermal conductivity matrix [ΛT ] [E/(tT)]
Out-of-plane thermal resistance R33 T [L2Tt/E]
Surfacic heat capacity (ρCp h ) lam [E/L2/T]
In-plane moisture conductivity matrix [ΛH ] [1/t]
Out-of-plane moisture resistance R33 H [L2t]

Other units systems can be used with the CLA classes. Each CLA object has an attribute corresponding to the units system in which all its characteristics are defined.

The units of CLA object can be obtained with “getUnits” method that returns a Hash containing pairs of Strings. The first String describes the kind of dimension: “L” for length, “M” for mass, “t” for time, “T” for temperature, “E” for energy, “W” for moisture and “F” for force. The second String corresponds to one of the unit listed above for the selected quantity.

The units of a CLA object can also be modified by calling “setUnits” or “changeUnits” methods:

Both “setUnits” and “changeUnits” methods have an Hash argument corresponding to the object returned by “getUnits” method.

When laminate calculations are done, the properties of material used in laminate layup definition are converted in laminate system of units if necessary. The same is true for loading units for the calculation of laminate load response. The ply results (shell forces, shell moments, stresses, temperatures...) are expressed in laminate system of units. When a failure criterion is calculated, calculations are done in laminate system of units. This means that ply allowables are first convered to the laminate system of units. Of course, the use of a consistent system of units for all the composite calculations is recommended, as it reduces the risk of errors and the calculation time.

Chapter II.2
The “ClaDb” class

A ClaDb object may be considered as an object in which collections of materials, laminates and loads are stored. The ClaDb Class also provides the “glue” that bonds the objects of the other composite Classes together.

Table II.2.1 gives the list of methods defined in “ClaDb” class.

II.2.1 Creation of an object

The singleton method “new” is used to create ClaDb objects. This method has no argument. (Nor has the “initialize” method an argument.)

II.2.2 Identifying a ClaDb

Two methods allow the manipulation of the identifier of ClaDb objects (“Id” attribute):

II.2.3 Manipulating entities stored in a ClaDb

The ClaDb class provides three methods to insert objects in the collections, and three methods to retrieve objects stored in the collections:

The six methods described above create copies of the entities they store to, or retrieve from the ClaDb.

Internally, the ClaDb manages 3 associative containers that associate identifiers to materials, laminates or loads respectively. When an object is stored into the ClaDb, the key which allows to retrieve the object is the identifier one attributed to it with the “Id” attributes. (See Chapters II.3 to II.5.) Note that the identifier used to retrieve an object from the ClaDb must match exactly the key to which the object is associated. For example, if the identifier of a load is [17,"QS_and_bending"], then 17 or "QS_and_bending" will not allow to retrieve a copy of the object. [17,"QS_and_bending"] must be used as argument of the ‘getMaterialCopy” method.

When a ClaLam object is stored into the ClaDb, its properties are calculated automatically. (Stiffness matrix and <αEh> vector.)

Note also that when a CLA object is extracted from the database, or inserted into the database, the object keeps the units that are attributed to it. These units may be different than the database units. (See also section II.2.4.)

II.2.4 Management of Units

Units are associated to the database, and to all the entities stored in the database. The units associated to the stored entities are independent of each other, and of the database units.

The “ClaDb” class defines several methods for the management of units:

The Hash arguments or return values mentioned above have String keys and values as explained in section II.1.13. The difference between the “setUnits” and “changeUnits” methods is also explained in the same section.

II.2.5 Saving to or retrieving from a disk file

Presently, three interface functions are defined:

Note that the neutral data files (“ndf” files) mentioned above are files with a format specific to the FeResPost.

II.2.6 Saving or initializing with NDF lines

Two methods allow to save or read ClaDb objects from an Array of Strings in neutral format. For each of these two methods, instead of reading or saving the lines from or to a disk file, each line is saved or read from or to an Array of Strings. The two methods are:

II.2.7 Iterators

The ClaDb class provides 6 iterators:

These iterators have no argument.

II.2.8 Other methods

clone” method has no argument and returns a copy of the ClaDb object.

Chapter II.3
The “ClaMat” class

The “ClaMat” class is used to store the materials used in the definition of laminates. Each material is characterized by:

Several methods of the ClaMat class allow to access to data stored in an object. Table II.3.1 gives the list of methods defined in the class.

Table II.3.1: The different methods that have been defined in “ClaMat” class. Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
Method Name DescriptionExample
Creation and initialization methods
new (s) II.3.1 IV.3.2
initialize II.3.1
clone II.3.7
Manipulation of data defining ClaMat object
clearModuli II.3.3
insertModuli II.3.3
fillModuli II.3.3 IV.3.2
getDataModuli II.3.3
clearCTEs II.3.3
insertCTEs II.3.3
fillCTEs II.3.3 IV.3.2
getDataCTEs II.3.3
clearCMEs II.3.3
insertCMEs II.3.3
fillCMEs II.3.3
getDataCMEs II.3.3
clearAllowables II.3.3
insertAllowables II.3.3
fillAllowables II.3.3
getDataAllowables II.3.3
clearThermalData II.3.3
insertThermalData II.3.3
fillThermalData II.3.3 IV.3.3
getThermalData II.3.3
clearMoistureData II.3.3
insertMoistureData II.3.3
fillMoistureData II.3.3
getMoistureData II.3.3
Extraction of calculated material properties
getCompliance II.3.4 “EX12/testCla.rb”
getStiffness II.3.4 IV.3.2
getInPlaneComplianceII.3.4“EX13/extendedCLA.rb”
getInPlaneStiffness II.3.4“EX13/extendedCLA.rb”
getInPlaneAlfaE II.3.4“EX13/extendedCLA.rb”
getInPlaneBetaE II.3.4“EX13/extendedCLA.rb”
getInPlaneAlfa II.3.4“EX13/extendedCLA.rb”
getInPlaneBeta II.3.4“EX13/extendedCLA.rb”
getOOPSCompliance II.3.4“EX13/extendedCLA.rb”
getOOPSStiffness II.3.4“EX13/extendedCLA.rb”
getOOPSAlfaG II.3.4“EX13/extendedCLA.rb”
getOOPSBetaG II.3.4“EX13/extendedCLA.rb”
getOOPSAlfa II.3.4“EX13/extendedCLA.rb”
getOOPSBeta II.3.4“EX13/extendedCLA.rb”
getInPlaneLambdaT II.3.4 IV.3.3
getRho II.3.4 IV.3.3
getCp II.3.4 IV.3.3
getRhoCp II.3.4 IV.3.3
getInPlaneLambdaH II.3.4
Management of units methods
getUnits II.3.5
setUnits II.3.5
changeUnits II.3.5
Attributes
Id II.3.2
Type II.3.2
TypeName II.3.2 (read only)
NDF lines
initWithNeutralLines II.3.6
getNeutralLines II.3.6

II.3.1 Creation of an object

The singleton method “new” is used to create ClaMat objects. This method has no argument. (Nor has the “initialize” method an argument.)

II.3.2 Identifier and type

Two attributes are defined for the “ClaMat” object: “Id” and “Type”. Five methods allow the manipulation of the identifier of material and of its type:

Note that for the type definition, the integers are 0, 1, 2 or 3 and correspond to "NONE", "isotropic", "orthotropic" or "anisotropic" respectively.

II.3.3 Manipulating Data

Twelve methods allow to set moduli and Poisson’s coefficients, thermal expansion coefficients and allowables. These methods have one Hash argument that associates String keys to real values.

1.

clearModuli” has no arguments and erases all the moduli stored in a ClaMat object.

2.

insertModuli” is used to specify moduli and Poisson coefficients of the material. The keys used to insert mechanical data depend on the type of material:

  • For an orthotropic material, the different possible keys are: "E1", "E2", "E3", "G12", "G23", "G31", "nu12", "nu23", "nu31".

  • For isotropic materials the possible keys are "E", "nu" and "G".

  • For anisotropic materials the components of matrix [C] as defined by (II.1.11) are specified. The keys can be "C1111", "C1122", "C1133"... (Note that when a non-diagonal component of the matrix is defined, its symmetric value is initialized too.)

3.

fillModuli” is used to set material moduli and Poisson coefficients. This method has the same arguments as “insertModuli” but differs by the fact that moduli and Poisson coefficients are re-initialized before insertion of values.

4.

clearCTEs” has no arguments and erases all the CTEs stored in a ClaMat object.

5.

insertCTEs” is used to define different components of the thermal expansion coefficients. For orthotropic and anisotropic materials, possible keys are "alfa1", "alfa2", "alfa3", "alfa12", "alfa23" and "alfa31". For isotropic materials, key "alfa" only can be used.

6.

fillCTEs” is used to set material CTEs. This method has the same arguments as “insertCTEs” but differs by the fact that CTEs are re-initialized before insertion of values.

7.

clearCMEs” has no arguments and erases all the CMEs stored in a ClaMat object.

8.

insertCMEs” is used to define different components of the moisture expansion coefficients. For orthotropic and anisotropic materials, possible keys are "beta1", "beta2", "beta3", "beta12", "beta23" and "beta31". For isotropic materials, key "beta" only can be used.

9.

fillCMEs” is used to set material CMEs. This method has the same arguments as “insertCMEs” but differs by the fact that CMEs are re-initialized before insertion of values.

10.

clearAllowables” has no arguments and erases all the allowables stored in a ClaMat object.

11.

insertAllowables” is used to add material allowables. The possible keys are "sc", "st", "ss", "ec", "et", "gs", "s1c", "s1t", "s2c", "s2t", "s12", "s23", "s31", "e1c", "e1t", "e2c", "e2t", "e3c", "e3t", "g12", "g23", "g31", "F12", "F23" and "F31". "st" is used to calculate isotropic stress criteria or reserve factors. "F12" "F23" and "F31" correspond to the F12TW, F23TW and F31TW of the Tsai-Wu failure criteria (sections II.1.10.14 and II.1.10.15). Note that the "ilss" allowable defined at material level has no effect because for Ilss criterion calculation, the allowable is always extracted from the laminate definition. (More precisely, the ilss laminate allowable, or the ply allowables are used.)

12.

fillAllowables” is used to set material allowables. This method has the same arguments as “insertAllowables” but differs by the fact that material allowables are re-initialized before insertion of values.

13.

clearThermalData” has no arguments and erases all the thermal data stored in a ClaMat object.

14.

insertThermalData” is used to define the thermal data. For orthotropic and anisotropic materials, possible keys are "lambdaT1", "lambdaT2", "lambdaT3", "lambdaT12", "lambdaT23" and "lambdaT31". For isotropic materials, key "lambdaT" only can be used. For all types of materials "rho" and "Cp" keys can be used.

15.

fillThermalData” is used to set material thermal data. This method has the same arguments as “insertThermalData” but differs by the fact that thermal data are re-initialized before insertion of values.

16.

clearMoistureData” has no arguments and erases all the Moisture data stored in a ClaMat object.

17.

insertMoistureData” is used to define the moisture data. For orthotropic and anisotropic materials, possible keys are "lambdaH1", "lambdaH2", "lambdaH3", "lambdaH12", "lambdaH23" and "lambdaH31". For isotropic materials, key "lambdaH" only can be used.

18.

fillMoistureData” is used to set material Moisture data. This method has the same arguments as “insertMoistureData” but differs by the fact that moisture data are re-initialized before insertion of values.

The type of ClaMat object must have been set prior to the use of any of the three previous methods. (See “Type” attribute described in section II.3.2.) Several methods allow to retrieve the data that define a material:

1.

getDataModuli” returns the moduli that define the ClaMat object.

2.

getDataCTEs” returns the CTEs that define the ClaMat object.

3.

getDataCMEs” returns the CMEs that define the ClaMat object.

4.

getDataAllowables” returns the allowables that characterize the ClaMat object.

5.

getThermalData” returns the thermal data that define the ClaMat object.

6.

getMoistureData” returns the moisture data that define the ClaMat object.

Each of these “get” methods returns a Hash that associates String and Real objects. (See the “fill” corresponding methods for possible values.)

Obviously, the different data inserted in, or retrieved from the ClaMat object should be consistent with the set of units attributed to the same object. This set of units can be attributed to the object after initialization of the data.

II.3.4 Calculated results

Several methods allow to recover stiffness, compliance or conductivity matrices in a specified direction.

All these methods have one optional argument: an angle corresponding to the direction of observation wrt material axes, and in which the components of the matrix are expressed.

On the other hand, three methods return material scalar characteristics and have no argument:

The different calculated results from the ClaMat object are expressed in the units system associated with the object.

II.3.5 Management of Units

The “ClaMat” class defines three methods for the management of units:

The Hash arguments or return values mentioned above have String keys and values as explained in section II.1.13. The difference between the “setUnits” and “changeUnits” methods is also explained in the same section.

II.3.6 Saving or initializing with NDF lines

Two methods allow to save or read ClaMat objects from an Array of Strings in neutral format. These two methods are “initWithNeutralLines” and “getNeutralLines” that work in a similar way as the corresponding methods in “ClaDb” class (section II.2.6).

However, the lines transmitted to “initWithNeutralLines” or returned by “getNeutralLines” correspond to a single ClaMat object definition.

II.3.7 Other methods

clone” method has no argument and returns a copy of the ClaMat object.

Chapter II.4
The “ClaLam” class

The “ClaLam” class is used to store lay-ups and calculate laminate mechanical properties and load responses. They are characterized by the lay-up the define.

Table II.4.1 gives the list of methods defined in “ClaLam” class.

Table II.4.1: The different methods that have been defined in “ClaLam” class. Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
Method Name DescriptionExample
Creation and initialization methods
new (s) II.4.2 IV.3.2
initialize II.4.2
clone II.4.13
Class methods
setMuxMuy II.4.1
getMuxMuy II.4.1
setOopsApproach II.4.1
getOopsApproach II.4.1
Manipulations of the laminate plies
clearPlies II.4.4
addPly II.4.4 IV.3.2
setNbrPlies II.4.4
setPly II.4.4
getNbrPlies II.4.4
getPlyData II.4.4
Other laminate data
clearAllowables II.4.5
insertAllowables II.4.5 IV.3.6
fillAllowables II.4.5
getDataAllowables II.4.5
setRefT II.4.5
getRefT II.4.5
setRefH II.4.5
getRefH II.4.5
setLaminateIlss II.4.5 IV.3.4.3
setAllPliesIlss II.4.5 IV.3.4.3
Laminate properties
calcLaminateProperties II.4.6 IV.3.3
get_thickness II.4.6
get_surfacicMass II.4.6
get_averageDensity II.4.6
get_ABBD II.4.6 IV.3.2
get_G II.4.6 IV.3.5
get_alfaEh1 II.4.6 IV.3.2
get_alfaEh2 II.4.6
get_alfaEh3 II.4.6
get_alfaGh1 II.4.6
get_alfaGh2 II.4.6
get_betaEh1 II.4.6
get_betaEh2 II.4.6
get_betaEh3 II.4.6
get_betaGh1 II.4.6
get_betaGh2 II.4.6
get_abbd_complMat II.4.6
get_g_complMat II.4.6
get_alfae0 II.4.6
get_alfae1 II.4.6
get_alfak0 II.4.6
get_alfak1 II.4.6
get_alfas0 II.4.6
get_alfas1 II.4.6
get_betae0 II.4.6
get_betae1 II.4.6
get_betak0 II.4.6
get_betak1 II.4.6
get_betas0 II.4.6
get_betas1 II.4.6
get_engineering II.4.6 IV.3.4.1
get_LambdaT II.4.6 IV.3.3
get_R33T II.4.6 IV.3.3
get_RhoCpH II.4.6 IV.3.3
get_LambdaH II.4.6
get_R33H II.4.6
Laminate load response
calcResponse II.4.7.1IV.3.4.2
isThermalLoadingDefined II.4.7.2
getDeltaT II.4.7.2IV.3.4.1
getT0 II.4.7.2
getGradT II.4.7.2
isMoistureLoadingDefined II.4.7.2
getDeltaH II.4.7.2
getH0 II.4.7.2
getGradH II.4.7.2
isMechanicalLoadingDefined II.4.7.2
getNormalForces II.4.7.2IV.3.4.1
getMoments II.4.7.2IV.3.4.1
getShearForces II.4.7.2IV.3.4.1
getNormalStrains II.4.7.2IV.3.4.1
getCurvatures II.4.7.2IV.3.4.1
getShearStrains II.4.7.2IV.3.4.1
getAverageInPlaneStresses II.4.7.2IV.3.4.1
getFlexuralStresses II.4.7.2IV.3.4.1
getAverageShearStresses II.4.7.2IV.3.4.1
getAverageInPlaneStrains II.4.7.2IV.3.4.1
getFlexuralStrains II.4.7.2IV.3.4.1
getAverageShearStrains II.4.7.2IV.3.4.1
getPliesStrains II.4.7.3IV.3.4.1
getPliesStresses II.4.7.3IV.3.4.1
getPliesMechanicalStrains II.4.7.3IV.3.4.1
getPliesStrainsWrtLamAxes II.4.7.3
getPliesStressesWrtLamAxes II.4.7.3
getPliesMechanicalStrainsWrtLamAxesII.4.7.3
getPliesT II.4.7.4
getPliesDeltaT II.4.7.4
getPliesH II.4.7.4
getPliesDeltaH II.4.7.4
getDerived II.4.7.5IV.3.4.1
getMaxDerived II.4.7.5
getMinDerived II.4.7.5
getFailureIndices II.4.7.5IV.3.4.1
getMaxFailureIndices II.4.7.5
getMinFailureIndices II.4.7.5
getReserveFactors II.4.7.5IV.3.4.1
getMaxReserveFactors II.4.7.5
getMinReserveFactors II.4.7.5
getStrengthRatios II.4.7.5IV.3.4.1
getMaxStrengthRatios II.4.7.5
getMinStrengthRatios II.4.7.5
calcFiniteElementResponse II.4.8.1
reInitAllPliesAccelMatrices II.4.8.2
calcFiniteElementCriteria II.4.9 IV.3.6
Management of units methods
getUnits II.4.10
setUnits II.4.10
changeUnits II.4.10
Iterators
each_ply II.4.12 IV.3.5
NDF lines
initWithNeutralLines II.4.11
getNeutralLines II.4.11
Attributes
Id II.4.3

II.4.1 Class Methods

One shows in section II.1.6 that two arbitrary parameters μx and μy define the relations between x and y partial derivatives of laminate bending moment components and out-of-plane shear forces when the (μx,μy)” approach is adopted. The default values of these parameters are μx = μy = 1. Two Class Methods allow the manipulation of these parameters:

As these methods are Class methods, the modification of μx or μy affects all the laminates defined in all the CLA databases.

Similarly, one methods allows to select the laminate out-of-plane shear calculation approach. The method is called “setOopsApproach” and has onesString parameter that has three acceptable values: “Standard”, “UncoupledXY” and “InShearLoadingAxes”. These values correspond to the calculation approaches discussed in section II.1.6.5. “Standard” is the default approach. Method “getOopsApproach” allows to check which approach has been selected. Here again, “setOopsApproach” affects all the laminates defined in all the CLA databases.

“setMuxMuy” and “setOopsApproach” should be used (if used) only once before they creation of the first laminate by FeResPost. Otherwise unexpected behaviour is possible. Indeed, intermediate matrices are stored in C++ laminate objects and the modification of the calculation approach after laminates have been created may lead to mixture of matrices and vectors obtained via different approaches.

II.4.2 Creation of an object

The singleton method “new” is used to create ClaLam objects. This method has no argument. Nor has the “initialize” method an argument.)

II.4.3 Identifying a laminate

Two methods allow the manipulation of the identifier of ClaLam objects (“Id” attribute):

II.4.4 Manipulation of plies

The “clearPlies” method has no argument and erases all the plies defining a ClaLam object. After the method has been called, the number of plies of the laminate is zero.

One way to define the plies of the laminate is to add successively all the plies defined in the laminate starting at the bottom layer. The “addPly” method allows to insert plies in a ClaLam. This method has four or five arguments.

The sequence of plies in the laminate corresponds to the order of addition of the plies by calls to the “addPly” method. Of course each call of the method “addPly” increases the number of plies of the laminate by one.

Instead of defining the sequence of plies sequentially by successive calls to “addPly” method, the data of each ply can also be defined in random order by calls to “setPly” method. Its arguments are nearly the same as those of the “addPly” method:

As the “PlyId” second argument is optional, the method has 5 or 6 arguments. The “setPly” method is very handy when one defines a new laminate by modifying a few plies from a previously existing one. Of course, an entirely new laminate can also have its ply data initialized with “setPly” method, but then the number of plies must first be set... “setNbrPlies” method has one argument and sets the number of plies. Note that the ply definition data previously stored in the laminate may have random values after using this method.

Two methods allow to access and examine the plies stored in a ClaLam object:

Obviously, the different data inserted in, or retrieved from the ClaLam object should be consistent with the set of units attributed to the same object. This set of units can be attributed to the object after initialization of the data.

II.4.5 Other data

The reference temperature of a laminate is accessed with the two following methods:

Note that an ILSS criterion is calculated, the allowables are always extracted from the laminate definition. When no ClaDb argument is provided for the calculation of the criterion, the laminate “ilss” allowable is used; when a ClaDb argument is provided, the ply “ilss” allowables are used. This means that the “ilss” allowable provided in ClaMat materials is never used.

Obviously, the different data inserted in, or retrieved from the ClaLam object should be consistent with the set of units attributed to the same object. This set of units can be attributed to the object after initialization of the data.

II.4.6 Laminate properties

The method “calcLaminateProperties” calculates the laminate properties of the ClaLam object. This means that the stiffness and compliance matrices, the thermal-expansion vectors are estimated and stored into the laminate object. This method can be called only after all the plies of the laminate have been inserted into the object. The method has one argument: a ClaDb object in which all the materials used in the lay-up definition have to be stored (otherwise, an exception is raised). Note that when a ClaLam object is inserted into a ClaDb, the “calcLaminateProperties” method is called automatically, with this ClaDb object as argument.

Six methods allow to retrieve the properties of a laminate:

These five methods have one optional Real argument that corresponds to a rotation angle wrt laminate axes. If the argument is omitted, zero value is assumed and the engineering constants are calculated in laminate axes. The angle is specified in o.

Four methods return Real scalar values:

These methods have no arguments.

The different calculated results from the ClaLam object are expressed in the units system associated with the object.

II.4.7 Laminate load response for a simple loading

The calculation of the laminate response to a specified loading is always done in two steps:

1.

The laminate load response is calculated for a specific loading. This calculation is used to estimate laminate in-plane forces, bending moments, average strains, curvature, temperature variations... Also layered results are calculated if required. (See description of method “calcResponse” in section II.4.7.1.)

All these results are stored in the ClaLam object and remembered until the next calculation is performed.

2.

Then, the laminate can be “interrogated” to obtain a restitution of stored results, or the calculation of new results from the information stored since the last calculation. (See the methods described in sections II.4.7.2, II.4.7.3 and II.4.7.5.)

This way of working allows at the same time much flexibility in the recovery of results at an acceptable computational cost.

The different calculated results retrieved from the ClaLam object are expressed in the units system associated to laminate object. This means that even if the loading units or the material units differ from laminate units, FeResPost performs the conversions needed to obtain stresses, forces, moments and other results in the units system associated to laminate.

II.4.7.1 Calculation of the load response

The method “calcResponse” is used to calculate the laminate response to a specified loading. When this method is called, several results are systematically calculated and stored: in-plane forces, bending moments, average strains, curvature and temperature variation. The calculation and storage of ply results is optional and commanded by the Boolean arguments of the method.

The “calcResponse” may have from 3 up to 6 arguments:

The three last parameters are optional and default to false (no calculation of the corresponding layered results).

II.4.7.2 Laminate internal loads and strains

Several methods allow to recover results calculated at laminate level. All these results correspond to the laminate results for the last call to method “calcResponse”:

The optional rotation is specified as an angle expressed in degrees. When the parameter is omitted, a zero value is assumed. When a tensor is returned the three components are given in the following order: XX, YY and XY.

II.4.7.3 Ply stresses and strains

Three methods give access to the ply results stored in ClaLam object:

These three methods:

The methods return an Array of which each element corresponds to the stresses/strains at one given location in the thickness of the laminate. More precisely, each element is an Array of 2+6=8 elements containing:

To the three methods listed above correspond three other methods that return the ply stresses or strains with components expressed in a coordinate system defined wrt the laminate, and not expressed in ply axes. The three methods are called:

The first argument of these three methods are a real value corresponding to the rotation of restitution coordinate system wrt laminate axes. The following arguments are the same as those of the three first methods defined above.

II.4.7.4 Temperatures and moistures at ply level

Four methods give access to the temperature and moisture ply results stored in ClaLam object:

The arguments are the same as those of the method described in section II.4.7.3: they correspond to the identifiers of layers at which ply results are recovered. The methods return an Array of which each element corresponds to a layered Result. More precisely, each element is an Array of 3 elements containing:

II.4.7.5 Other ply results

Several methods of the ClaLam class allow to estimate values from the stored ply stresses and strains. Three such methods return the values calculated for several plies:

getDerived” and “getFailureIndices” have the same parameters:

So for example, “getFailureIndices” method may be called as follows:

     criteria=["TsaiHill2D","MaxStress2D"]
     ...
     fiRes=getFailureIndices(criteria)
     ...
     fiRes=getFailureIndices(db,criteria)
     ...
     fiRes=getFailureIndices(db,criteria,[4,"Sup"],[7,"Inf"])
 

Note that several criteria can be calculated by a single call.

Methods “getReserveFactors” and “getStrengthRatios” have one additional parameter: the factor of safety. This parameters is a Real value provided after the list of criteria and before the optional layer identifiers. For example

     criteria=["TsaiHill2D","MaxStress2D"]
     ...
     rfRes=getReserveFactors(db,criteria,1.25,[4,"Sup"],[7,"Inf"])

Each of the four methods described above returns an Array containing two elements:

1.

The first element is an Array of Strings containing the list of criteria that have been calculated. Indeed, the criteria are calculated only if the criterion is available. This Array has X elements.

2.

The second element contains the new layered results. Each element of this Array contains 2+X elements:

  • The two first elements of the sub-array identify the layer to which the calculated results correspond.

  • The X elements 3 to 2+X of the sub-array contain the Real calculated values. These X elements correspond to the X Strings referred to above in the list of criteria returned by the method.

The four methods “getDerived”, “getFailureIndices”, “getReserveFactors” and “getStrengthRatios” have “Min” and “Max” variants. This makes six additional methods: “getMinDerived”, “getMinFailureIndices”, “getMinReserveFactors”, “getMinStrengthRatios”, “getMaxDerived”, “getMaxFailureIndices”, “getMaxReserveFactors” and “getMaxStrengthRatios”. These methods have the same parameters as their basic corresponding methods and are used to return values associated to the most critical ply. (The ply leading to maximum or minimum calculated criterion.) The returned Array, however, is different. The returned value is an Array of which each element is an Array of four elements:

1.

The calculated criterion (String).

2.

Two elements identifying the critical layer (an integer and string value).

3.

A Real object corresponding to the critical value.

The criteria presently available are summarized in Table II.1.2.

II.4.8 Laminate finite element load response

II.4.8.1 Calculation of laminate loads, stresses and strains

The “calcFiniteElementResponse” method allows the calculation of finite element load response. More precisely the method calculates several Result objects containing finite laminate finite element results, from loading of which some components are finite element results. The method has up to nine arguments:

1.

The first argument is a “ClaDb” object in which the materials used in the laminate definition are stored.

2.

The second argument, “theta”, is a real value corresponding to the angle in degrees of loading wrt laminate axes. In most cases, this angle will be zero. Note that the same angle is used to calculate laminate load response for all elements and nodes on which it is required.

3.

The third argument is a ClaLoad object in which the loading is defined. This ClaLoad object must have some components defined as finite element results.

4.

The fourth argument is an Array of three logical values. Each logical value corresponds to the request of results at bottom, mid and top location respectively, in each ply. (The components are similar to three of the arguments of “calcResponse” method described in section II.4.7.1.)

5.

The fifth parameter is an Array of Strings specifying the non-layered laminate results that will be returned by the method.

6.

The sixth parameter is an Array of Strings specifying the layered laminate results that will be returned by the method. (Results at ply level.)

7.

The seventh parameter is a Real object corresponding to the safety factor. This parameter is used by the method only for the calculation of reserve factors, or strength ratios. (See the following argument.)

8.

The eighth parameter is an Array of Arrays describing the failure indices, reserve factors or equivalent scalar derived values requirements. Each element of the first Array is an Array of up to five elements:

(a)

A String corresponding to the key by which the corresponding result shall be referred in the Hash returned by “calcFiniteElementResponse” method.

(b)

A String corresponding to the name of the criterion. This name must one of the names defined in Table II.1.2.

(c)

A string defining the type of Result that shall be defined. Values can be “FI”, “RF”, “SR” or “EQ”. They correspond to the calculation of Failure Indices, Reserve Factors, Strength Ratios or Scalar Derived values respectively. If a Reserve Factor or Strength Ratio is required, the factor of safety parameter is used for the calculation.

(d)

A logical value specifying whether the laminate allowables are used for the calculation of Result values. If this value is false, then the ply material allowables are used in the calculations.

(e)

A logical value specifying if Result values are required for all the plies. If the argument is “false”, the critical layer value only is inserted in the returned Result.

The Logical parameters are optional. If not defined, “false” values are assumed.

9.

An Array containing the list of plies on which stresses, strains or scalar failure indices are to be calculated. (For example, an Array of integers corresponding to ply idfiers.)

The method returns a Hash object containing pairs of Strings and Results. One can make a few remarks that should help to understand Results returned by the method:

The requirements for laminate non-layered and layered Results are summarized in Table II.4.2 and Table II.4.3 respectively.

An example of use of the method follows:

    criteria = []
    criteria << ["TS FI","TsaiHill2D","FI",true,true]
    criteria << ["TW FI","TsaiWu2D","FI",true,true]
    criteria << ["TW FI Critical","TsaiWu2D","FI",true,false]
    criteria << ["ILSS FI Critical","Ilss","FI",true,false]
    theta=0.0

    outputs=lam.calcFiniteElementResponse(compDb,theta,ld,[true,true,true],
        ["Shell Forces","Shell Moments", "Shell Curvatures",
         "Average Strain Tensor"],
        ["Stress Tensor","Strain Tensor","Mechanical Strain Tensor",
         "Ply Temperature Variation"],
        1.5,criteria)


Table II.4.2: Laminate non-layered Results requirements.
Requirement Finite Element Result
“Shell Forces” “Shell Forces”
“Shell Moments” “Shell Moments”
“Shell Curvatures” “Shell Curvatures”
“Average Strain Tensor”“Average Strain Tensor”


Table II.4.3: Laminate non-layered Results requirements.
Requirement Finite Element Result
“Stress Tensor” “Stress Tensor”
“Strain Tensor” “Strain Tensor”
“Mechanical Strain Tensor” “Mechanical Strain Tensor”
“Ply Temperature” “Ply Temperature”
“Ply Temperature Variation”“Ply Temperature Variation”
“Ply Moisture” “Ply Moisture”
“Ply Moisture Variation” “Ply Moisture Variation”

Note that the same method with exactly the same arguments has been defined in the DataBase class. (See section I.1.5.)

II.4.8.1.1 Units

The different calculated results from the ClaLam object are expressed in the units system associated with the object.

II.4.8.2 Acceleration

One explains in section II.1.9.2 how the plies stresses and strains calculation can be significantly accelerated by calculating once and for all intermediate acceleration matrices for each ply. These matrices must be recalculated each time the laminate or one of its materials is modified.

Method “reInitAllPliesAccelMatrices” has been added to the “ClaLam” class to re-initialize the laminate plies acceleration matrices. This ensures that the matrices will be re-calculated next time they are required.

II.4.9 Calculation of criteria from FE stresses or strains

The “calcFiniteElementCriteria” method allows the calculation of ply failure criteria, reserve factors or equivalent stress or strain from layered Results. The method has four arguments:

The method returns a Hash object containing pairs of Strings and Results. In this case, only scalar Result objects are returned.

The different calculated results from the ClaLam object are expressed in the units system associated with the object.

II.4.10 Management of Units

The “ClaLam” class defines three methods for the management of units:

The Hash arguments or return values mentioned above have String keys and values as explained in section II.1.13. The difference between the “setUnits” and “changeUnits” methods is also explained in the same section.

II.4.11 Saving or initializing with NDF lines

Two methods allow to save or read ClaLam objects from an Array of Strings in neutral format. These two methods are “initWithNeutralLines” and “getNeutralLines” that work in a similar way as the corresponding methods in “ClaDb” class (section II.2.6).

However, the lines transmitted to “initWithNeutralLines” or returned by “getNeutralLines” correspond to a single ClaLam object definition.

II.4.12 One iterator

The ClaLam class provides the iterator “each_ply” that iterates on the plies. This iterator returns pairs of elements corresponding to the ply index, and the ply definition. The ply definition is an Array of 5 elements identical to the one returned by “getPlyData” method.

II.4.13 Other methods

clone” method has no argument and returns a copy of the ClaLam object.

Chapter II.5
The “ClaLoad” class

The “ClaLoad” class is used to define, store and manipulate loadings to be applied to laminates. A loading is characterized by:

A list of the methods defined in “ClaLoad” class is given in Table II.5.1.

II.5.1 Creation of an object

The singleton method “new” is used to create ClaLoad objects. This method has no argument. (Nor has the “initialize” method an argument.)

II.5.2 Identifying a ClaLoad

Two methods allow the manipulation of the identifier of ClaLoad objects (“Id” attribute):

II.5.3 Thermo-elastic and hygro-elastic contributions

Ten methods allow the manipulation of scalar characteristics of the loadings. (The scalar characteristics are the thermo-elastic and hygro-elastic contributions to loading.) The methods are:

Obviously, the different data inserted in, or retrieved from the ClaLoad object should be consistent with the set of units attributed to the same object. This set of units can be attributed to the object after initialization of the data.

II.5.4 Setting and getting mechanical parts

Three methods are used to set the mechanical part of loading stored in the ClaLoad object:

Each of the three “set” methods described above has a corresponding “get” method:

Each of these three “get” methods returns an Array containing the arguments of the respective “set” methods. The first element of this Array is an Array of 3 or 2 Real values. Then follow 3 or 2 Strings corresponding to the types of solicitation of each component.

Obviously, the different data inserted in, or retrieved from the ClaLoad object should be consistent with the set of units attributed to the same object. This set of units can be attributed to the object after initialization of the data.

II.5.5 Linear combinations of loads

setToCombili” method allows to define a ClaLoad as a linear combination of pre-defined ClaLoads. This method has four arguments:

1.

A reference temperature. This Real parameter is necessary because the top and bottom temperatures of the combined ClaLoad are calculated as follows:

Ttot = Tref + i=1Nf i (Ti - Tref) .
2.

A reference moisture. (Same remarks as for the reference temperature.)

3.

An Array of Reals corresponding to the coefficients of the linear combination.

4.

An Array of ClaLoad objects.

The sizes of the two Array arguments must match. Also the types of the different components of mechanical part of the loadings must be the same.

II.5.6 Finite element Results

Eighteen methods are devoted to the manipulation of loading components defined as finite element Results. Six member data correspond to these methods: “Shell Forces”, “Shell Moments”, “Shell Strains”, “Shell Curvatures”, “Shell Temperatures” and “Shell Moistures”.

The mechanical components of loading correspond to non-layered Results. “Shell Temperatures” and “Shell Moistures” are defined at Shell lower and upper surfaces (layers “Z1” and “Z2” respectively). When calculating laminate load response, FeResPost does not check or considers the coordinate system to which mechanical loading components are associated. This means that all the components are assumed to be given in loading axes. It is the responsibility of the user to first transform the components in such a way that their use by FeResPost makes sense.

Three methods allow the manipulation of Shell Forces stored in the ClaLoad object:

1.

setShellForces” inserts a copy of the Result argument inside the ClaLoad object.

2.

getShellForcesCopy” has no argument and returns a copy of the “Shell Forces” Result stored in the ClaLoad object. The method returns “Nil” if the “Shell Forces” are not initialized.

3.

clearShellForces” erases the “Shell Forces” Result stored in the ClaLoad object.

For the other Results, the manipulation methods are build similarly. The other methods are:

Obviously, the different data inserted in, or retrieved from the ClaMat object should be consistent with the set of units attributed to the same object. This set of units can be attributed to the object after initialization of the data.

II.5.7 Management of Units

The “ClaLoad” class defines three methods for the management of units:

The Hash arguments or return values mentioned above have String keys and values as explained in section II.1.13. The difference between the “setUnits” and “changeUnits” methods is also explained in the same section.

II.5.8 Saving or initializing with NDF lines

Two methods allow to save or read ClaLoad objects from an Array of Strings in neutral format. These two methods are “initWithNeutralLines” and “getNeutralLines” that work in a similar way as the corresponding methods in “ClaDb” class (section II.2.6).

However, the lines transmitted to “initWithNeutralLines” or returned by “getNeutralLines” correspond to a single ClaLoad object definition.

II.5.9 Other methods

clone” method has no argument and returns a copy of the ClaLoad object.

Part III
Solver Preferences

Chapter III.0
Introduction

In this Part of the document, one describes the preferences for the different solvers supported by FeResPost. Most preferences are defined as methods and member data of the classes specializing the “DataBase” class defined Chapter I.1. Presently two solvers are supported: Nastran and Samcef. The corresponding classes specializing “DataBase” class are “NastranDb” and “SamcefDb” classes. The corresponding preferences are described in Chapters III.1 and III.2 respectively. The diagram of Figure I.1.1 representing the “DataBase” hierarchy can be more precisely represented as in Figure 1.


PICT

Figure 1: Finite element DataBase classes hierarchy.

Chapter III.1
Nastran Preferences

Most methods peculiar to the post-processing of Nastran finite element Results and models are defined in class “NastranDb” that inherits the “DataBase” class. This class is described in section III.1.1. A list of the methods defined in “NastranDb” class is given in Table III.1.1.

Table III.1.1: The different methods that have been defined in “NastranDb” class. See also the methods defined in generic DataBase class (Table I.1.1). Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
(See also methods in generic DataBase class.)
Method Name DescriptionExample
Creation and initialization methods
new (s) III.1.1 IV.2.2.1
initialize III.1.1
Reading model or Results
readBdf III.1.1.1 IV.2.2.1
readOp2 III.1.1.2, III.1.1.8 IV.2.4.1
readOp2FilteredResults III.1.1.8 IV.2.4.1
readOp22H III.1.1.2, III.1.1.8
readOp2FilteredResults2H III.1.1.8
getXdbLcNames (s) III.1.1.9
getXdbScNames (s) III.1.1.9
getXdbResNames (s) III.1.1.9
getXdbLcScNames (s) III.1.1.9
getXdbLcScResNames (s) III.1.1.9 IV.2.4.6
getXdbLcInfos (s) III.1.1.9 IV.2.4.6
printXdbDictionnary (s) III.1.1.9
readXdb III.1.1.9 IV.2.4.6
readXdb2H III.1.1.9
XDB attachments
attachXdb III.1.1.10
detachXdb III.1.1.10
removeAllAttachments III.1.1.10
getNbrAttachments III.1.1.10
getAttachmentNames III.1.1.10
checkAttachmentExists III.1.1.10
getAttachmentWordsSize III.1.1.10 IV.2.8
getAttachmentSwapEndianness III.1.1.10 IV.2.8
getAttachmentLcInfos III.1.1.10
getAttachmentNbrLoadCases III.1.1.10
getAttachmentLcNames III.1.1.10
getAttachmentLcScNames III.1.1.10
getAttachmentLcScResNames III.1.1.10
getAttachmentNbrSubCases III.1.1.10
getAttachmentScNames III.1.1.10
getAttachmentNbrResults III.1.1.10
getAttachmentResIds III.1.1.10
getAttachmentResNames III.1.1.10
getAttachmentResults III.1.1.10
importAttachmentResults III.1.1.10
getAttachmentResultsCombili III.1.1.10
getAttachmentDesVarHistory III.1.1.10 IV.2.7
getAttachmentConstrDefinitions III.1.1.10 IV.2.7
getAttachmentConstrHistory III.1.1.10 IV.2.7
getAttachmentObjectiveHistory III.1.1.10 IV.2.7
getAttachmentDesRespHistory III.1.1.10
setStorageBufferMaxCapacity (s) III.1.1.10
getStorageBufferMaxCapacity (s) III.1.1.10
getAttachmentElementExtId III.1.1.10.7
getAttachmentNodeInfo III.1.1.10.7
getAttachmentDictKeys III.1.1.10.7
getAttachmentDictionnary III.1.1.10.7
each_xdbRaw III.1.1.10.7 IV.2.8
each_xdbBinRaw III.1.1.10.7 IV.2.8
binDataToValues (s) III.1.1.10.7 IV.2.8
HDF attachments. (See also section I.6.11.)
readHdf III.1.1.11
readHdf2H III.1.1.11
attachHdf III.1.1.11 IV.2.9
detachHdf III.1.1.11
removeAllHdfAttachments III.1.1.11
getNbrHdfAttachments III.1.1.11
getHdfAttachmentNames III.1.1.11
checkHdfAttachmentExists III.1.1.11
getHdfAttachmentLcInfos III.1.1.11 IV.2.9
getHdfAttachmentNbrLoadCases III.1.1.11
getHdfAttachmentLcNames III.1.1.11 IV.2.9
getHdfAttachmentLcScNames III.1.1.11
getHdfAttachmentLcScResNames III.1.1.11
getHdfAttachmentNbrSubCases III.1.1.11
getHdfAttachmentScNames III.1.1.11 IV.2.9
getHdfAttachmentNbrResults III.1.1.11
getHdfAttachmentResIds III.1.1.11
getHdfAttachmentResNames III.1.1.11 IV.2.9
getHdfAttachmentResults III.1.1.11
readHdfAttachmentResults III.1.1.11 IV.2.9
getHdfAttachmentDataSets III.1.1.11 IV.2.10
getHdfAttachmentCompoundMemberNames III.1.1.11 IV.2.10
getHdfAttachmentDataSetNbrItems III.1.1.11 IV.2.10
each_hdfAttachmentNasSetItem III.1.1.11 IV.2.10
getHdfAttachmentDataSet III.1.1.11 IV.2.10
Enabling/Disabling bulk cards or Results
enableBulkCards (s) III.1.1.8
disableBulkCards (s) III.1.1.8
getBulkCardsEnableInfos (s) III.1.1.8
enableOp2ResElems (s) III.1.1.8
disableOp2ResElems (s) III.1.1.8
getOp2ResElemsEnableInfos (s) III.1.1.8
enableXdbTables (s) III.1.1.9
disableXdbTables (s) III.1.1.9
getXdbTablesEnableInfos (s) III.1.1.9
Coordinate system methods
getCoordSysCopy III.1.1.6
addCoordSys III.1.1.6
makeAllCoordSysWrt0 III.1.1.6
Group manipulation methods
getNodesAssociatedToElements III.1.1.7 IV.2.5.3
getNodesAssociatedToRbes III.1.1.7
getElementsAssociatedToNodes III.1.1.7 IV.2.5.3
getRbesAssociatedToNodes III.1.1.7
getElementsAssociatedToMaterials III.1.1.7
getElementsAssociatedToPlies III.1.1.7
getElementsAssociatedToProperties III.1.1.7
Iterators
each_coordSysId III.1.1.13
each_elemId III.1.1.13 IV.2.3
each_nodeId III.1.1.13
each_rbeId III.1.1.13
each_mpcId III.1.1.13
each_materialId III.1.1.13
each_propertyId III.1.1.13
each_nodeOfElement III.1.1.13 IV.2.3
each_cornerNodeOfElement III.1.1.13
each_xdbRaw III.1.1.10.7 IV.2.8
each_xdbBinRaw III.1.1.10.7 IV.2.8
each_bdfCard (s) III.1.1.13
each_hdfAttachmentNasSetItem III.1.1.11 IV.2.2
Write methods
writeBdfLines III.1.1.4
writeNastranCard (s) III.1.1.4 IV.2.5.1
writeNastranCards (s) III.1.1.4 IV.2.5.1
writeNastranCardToVectStr (s) III.1.1.4
writeNastranCardsToVectStr (s) III.1.1.4 IV.2.10
Other methods (access to FEM definition and FEM modification)
getMpcNodes III.1.1.14
getMpcDependentNodes III.1.1.14
getMpcIndependentNodes III.1.1.14
getRbeNodes III.1.1.14
getRbeDependentNodes III.1.1.14
getRbeIndependentNodes III.1.1.14
getElementPropertyId III.1.1.14
getNodeRcId III.1.1.14
getNodeAcId III.1.1.14
getNodeCoords III.1.1.14
fillCard III.1.1.5 IV.2.2, IV.2.3 and IX.1.3
fillCards III.1.1.5
insertCard III.1.1.5
insertCards III.1.1.5 IV.2.2
Superelements
SEID III.1.1.3 IV.2.11
RefCounter III.1.1.3 IV.2.11
NbrSuperElements III.1.1.3 IV.2.11
getMaster III.1.1.3 IV.2.11
getSuperElementIdFromPos III.1.1.3 IV.2.11
getSuperElementFromId III.1.1.3 IV.2.11
getSuperElementFromPos III.1.1.3 IV.2.11
removeResultsAllSE III.1.1.3 IV.2.11
removeAllResultsAllSE III.1.1.3 IV.2.11
Other attributes
NbrRbes III.1.1.15
NbrMpcs III.1.1.15

III.1.1 “NastranDb” class

A “NastranDb” object can be created by a statement using “new” method like:

    db=NastranDb.new()

Method “initialize” initializes or clears a NastranDb object. This class is a specialization of the FeResPost “DataBase” class.

The model can be defined by reading a bulk Data File, or an op2 file. (See the corresponding methods below.)

III.1.1.1 Reading a BDF

The finite element model can be imported from a Nastran Bulk Data File with method “readBdf”. The method has up to six arguments.

1.

A String containing the name of the main Nastran Bulk Data File.

2.

An Array of Strings containing the list of directories in which files specified by “include” statements shall be searched. Its default value is a void Array.

3.

The name of an extension that may be added to the file names specified in include statements. Its default value is a void String. (This argument corresponds to the jidtype in Nastran.)

4.

A Hash with String keys and values corresponding to the list of “symbols” that can be used in “include” statements in the Bulk Data Files. The default value is a void Hash.

5.

A Logical that specifies verbosity for the reading of the Nastran Bulk Data File. Its default value is “false”. This parameter is redundant with “setVerbosityLevel” of “Post” Module: to set the parameter to “true” is equivalent to set “Post” verbosity level to 1.

6.

A Logical that specifies whether the file contains only Bulk Data Section lines. Its default value is “false”. If the parameter is “true”, the “BEGIN BULK” and “ENDDATA” lines are ignored, and all the input lines, except comments, are interpreted. (See also the remarks below.)

Only the first argument of the method is mandatory. More information about the method is given in section III.1.1.1. Examples of valid “readBdf” statements follow:

    db.readBdf("../../MODEL/MAINS/unit_xyz.bdf",
                  [],"",{},true)
    db.readBdf("Z:/RD/ALCAS/TESTSAT/MODEL/MAINS/unit_xyz.bdf",
                  [],"",{},true)
    db.readBdf("//CALC01/TESTSAT/MODEL/MAINS/unit_xyz.bdf",
                  [],"",{},true)
    db.readBdf("//CALC01/TESTSAT/MODEL/MAINS/unit_xyz.bdf",
                  [],"",{},true,true)

The format of Nastran cards defined in a bulk data file is described in [Sof04b]. The user must take the following limitations of the interface into account:

At the end of reading, the method issues an information message with a list of cards that have been skipped.

The correct working of method “readBdf” has not been tested for many of the Nastran cards listed above. So, bugs are possible when testing FeResPost for new finite element models. In order to reduce the severity of such bugs, Four singleton methods defined in NastranDb class to disable or (re-)enable some of the Nastran cards. See section III.1.1.8 for the use of that method. Note that the disabling of Nastran cards also influences the “readOp2” method when model entities are read.

III.1.1.2 “OP2” methods for reading a FEM

It is also possible to read a finite element model from an “op2” file with “readOp2” method. The model stored in the file is imported into the NastranDb if the second string argument of the method is “Model” or “Model/Results”. The first String argument is the name of the “op2” file.

The format of these files is described in [Rey04]. One describes in section III.1.1.2 the reading of finite element entities, and in section III.1.1.8 the reading of Results. The reading of 32bits as well as 64bits “op2” files is possible. However there is no advantage in reading 64bits version. Actually, these files are larger and may take a longer time to read.

Note that the reading of “op2” files also checks the endianness of the file and, if needed, does corrections to the binary data. For example, it can switch the reading from little endians to big endians or reversely. This allows “op2” files produced on a machine to be read on another machine with different “endianness” so that the portability of results is improved. Also, the 32/64 bits version is checked when the file is opened.

Finite element entities are read into the NastranDb with method “readOp2” if one specifies “Model” or “Model/Results” for the entities to read. The finite element entities recognized by the method corresponding to the Nastran cards supported by the “readBdf” method (see section III.1.1.1). The corresponding Data Blocks in the “op2” file are “GEOM1”, “GEOM2”, “GEOM3”, “GEOM4”, “EPT” and “MPT” (see [Rey04]).

Note that one generally prefers to read FE entities from a Bulk Data File than from an “op2” file because the data stored are sometimes ambiguous in the “op2” file (orientation of material properties on 2D elements,...). However, the reading of op2 files is faster than the reading of BDF files.

The correct working of method “readOp2” has not been tested for many of the Nastran cards listed above. So, bugs are likely to occur when testing FeResPost for new finite element models. In order to reduce the gravity of such bugs, The NastranDb class allows to disable or enable some of the Nastran cards. See section III.1.1.8 for the use of the corresponding singleton methods. Note that the disabling of Nastran cards also influences the “readBdf” method.

III.1.1.3 Superelements

Since version 5.0.5 of FeResPost, Nastran superelements are partially supported. More precisely, PART and external superelements are supported. (See [Hex22] for a definition of the different types of superelements.) The support is limited to the reading of models containing superelements from BDF or op2 files, and to the reading of corresponding Results from op2, xdb or hdf5 files. The purpose of FeResPost is not to generate models, superelements, or manage the assembly of a model divided in several partitions.

The following Nastran BDF cards or instructions related to super elements are supported:

Other cards related to the management of superelements are unsupported: “SELABEL”, “SELOC”, “SECONCT”, “SEEXCLD”, “SEMPLN’, “SETREE”’...

A finite element model can also be read from a Nastran op2 file, even though this is not recommended. The reading of op2 file identifies the different partitions and builds the corresponding superelement databases.

When a model containing several partitions is read, the corresponding NastranDb object contains sub-databases corresponding to the different superelements. Each database is a distinct NastranDb object. The main database is the “master” database. The sub-databases correspond to the different partitions. Several methods allow to obtain a superelement database from the master database. Also, it is possible to retrieve the master database from a superelement NastranDb object. Each database, including the master database, is identified by a positive integer SEID. For master database SEID=0.

To ease the management of NastranDb objects, a reference counter is added to the C++ nastran::database class. It ensures that the master database and the superelement databases are destroyed at the same time when all references to any of the database for a given model have been freed.

The following methods of the NastranDb class are related to the management of superelements:

The behaviour of ther methods is affected by the presence of superelements:

Examples discussed in section IV.2.11 should clarify the management of models and Results with superelements, and the information provided here.

III.1.1.4 Writing Bulk lines

Method “writeBdfLines” is used to output the model or part of the model into a text file with a format compatible with Nastran BDF cards. The method has 5 or 6 arguments :

1.

A string containing the name of the file to which the Nastran cards are printed.

2.

A string corresponding to the opening mode for the file. Valid values are “w” and “w+” (for append mode).

3.

A first format String argument specifying whether the fields in the cards output are left or right aligned. This argument may have three values: “left”, “right” or a void String. If the String is void, the format defaults to “left”.

4.

A second format String argument specifying whether the fields in the cards output are narrow or wide. This argument may have three values: “short”, “wide” or a void String. If the String is void, the format defaults to “short”.

5.

A third String argument corresponding to the type of entities that must be printed. The method scans the String argument and searches sub-strings that specify whether an entity type is to be printed or not. The sub-strings that are searched are “All”, “CoordSys”, “Nodes”, “Elements”, “RBEs”, “MPCs”, “Properties”, “Materials”.

6.

The last argument is optional and corresponds to the Group for which cards are to be printed. It can be a String or a Group argument. If its type is String, then the corresponding Group defined in the DataBase is considered. Note that “Properties” and “Materials” are not printed if the Group argument is provided.

The “writeBdfLines” method must be used for debugging purposes only. The user must keep in mind that some entities are not totally supported and their output may be problematic.

One first singleton method may be used to output formatted Nastran cards. This method can be used, for example, to produce Nastran cards for inclusion in a Bulk Data File. The method name is “writeNastranCard” and has five or six arguments (the “output card name” argument is optional):

1.

A String containing the name of the file to which the Nastran card is printed.

2.

A String corresponding to the opening mode for the output file. Valid values are “w” and “w+” (for append mode).

3.

A first format String argument specifying whether the fields in the card output are left or right aligned. This argument may have three values: “left”, “right” or a void String. If the String is void, the format defaults to “left”.

4.

A second format String argument specifying whether the fields in the card output are narrow or wide. This argument may have three values: “short”, “wide” or a void String. If the String is void, the format defaults to “short”.

5.

A String corresponding to the name of the output card. This name cannot have more than 8 characters and should correspond to a valid Nastran BDF card name. THIS ARGUMENT IS OPTIONAL.

6.

An Array containing the fields to be printed. Possible types for the elements of this Array are Real, Integer and String:

  • If the previous “output card name” argument is omitted (5 arguments), then the first element of the Array must be a String corresponding to the output card name (Nastran card field 1).

  • if the previous “output card name” argument is given (method is called with 6 arguments), then the Array values start with Nastran card field 2 content.

Examples of calls to the method follow:

   NastranDb.writeNastranCard("output.bdf","w+","right","short",card)
   NastranDb.writeNastranCard("output.bdf","w+","right","short","RBE2",card)

Another singleton method called “writeNastranCards” allows to output several Nastran cards. This method has the same arguments as “writeNastranCard” except that the last argument is an Array of Arrays, each element of the “big” Array corresponding to one Nastran card. The other arguments are the same, which means:

Remark that when “writeNastranCards” is called with 5 arguments, it is possible, with a single call, to output different types of Nastran cards (“FORCE”, “MOMENT”,...). This is not possible when the method is called with 6 arguments. Examples of calls to the method follow:

   NastranDb.writeNastranCards("output.bdf","w+","right","short",cards)
   NastranDb.writeNastranCards("output.bdf","w+","right","short","RBE2",cards)

The use of “writeNastranCard” and “writeNastranCards” methods is clarified in section IV.2.5.1.

Method “writeNastranCardToVectStr” is similar to “writeNastranCard”. It produces a formatted BDF output but returns it in an Array of Strings, each String corresponding to one line in the output. The three or four arguments of the method are as follows:

1.

A first format String argument specifying whether the fields in the card output are left or right aligned. This argument may have three values: “left”, “right” or a void String. If the String is void, the format defaults to “left”.

2.

A second format String argument specifying whether the fields in the card output are narrow or wide. This argument may have three values: “short”, “wide” or a void String. If the String is void, the format defaults to “short”.

3.

A String corresponding to the name of the output card. This name cannot have more than 8 characters and should correspond to a valid Nastran BDF card name. HERE AGAIN, THE ARGUMENT IS OPTIONAL.

4.

An Array containing the fields to be printed. Possible types for the elements of this Array are Real, Integer and String:

  • If the previous “output card name” argument is omitted (3 arguments), then the first element of the Array must be a String corresponding to the output card name (Nastran card field 1).

  • if the previous “output card name” argument is given (method is called with 4 arguments), then the Array values start with Nastran card field 2 content.

Examples of calls to these two methods follow:

   lines=[]
   lines+=NastranDb.writeNastranCardToVectStr("right","short",card)
   lines+=NastranDb.writeNastranCardToVectStr("right","short","RBE2",card)
   lines+=NastranDb.writeNastranCardsToVectStr("right","short",cards)
   lines+=NastranDb.writeNastranCardsToVectStr("right","short","RBE2",cards)
   puts lines

As has been done for the “writeNastranCard” method, a “writeNastranCardsToVectStr” singleton method is defined in the “NastranDb” class. A single call to the method allows the output of several Nastran cards in an Array of Strings. The last argument of the method is an Array or Arrays.

III.1.1.5 Accessing FEM information or modifying the FEM

The “fillCard” method allows to retrieve an Array corresponding to the a Nastran BDF card. The method has two arguments:

1.

A String corresponding to the type of entity of which one requires the definition. Possible values of the argument are “CoordSys”, “Element”, “Node”, “RBE”, “MPC”, “Property” and “Material”.

2.

An integer corresponding to the ID of the FEM item of which one searches the definition.

The method returns the definition in an Array:

Note that Nastran model may contain several material cards sharing a common ID, or several MPC cards with the same ID. When this case occurs, an exception is thrown. Therefore, for MPC or material cards, it is advised to use “fillCards” method instead of “fillCard”. An exception is also thown when no FEM item matching specified ID is found.

The “fillCards” method allows to retrieve an Array containing BDF cards as those returned by “fillCard” method. (This means that “fillCards” method returns an Array of Arrays.) The method has two or three arguments:

1.

A String corresponding to the type of entity of which one requires the definition. Possible values of the argument are “CoordSys”, “Element”, “Node”, “RBE”, “MPC”, “Property” and “Material”.

2.

An integer corresponding to the minimum ID of the FEM items of which one searches the definitions.

3.

An integer corresponding to the maximum ID of the FEM items of which one searches the definitions.

Third argument is optional. When omitted, one considers that maximum ID = minimum ID. In such cases, the method generally returns maximum one BDF card. However, for materials and MPCs, a single ID may correspond to several items. The method returns the definition in an Array of Arrays. Each element of the main Array is a Nastran BDF card as those returned by “fillCard” method.

Method “insertCard” performs the reverse operation: it allows to update the “NastranDb” database by insertion of FEM entity (coordinate system, node, element, RBE, material...). The method “insertCard” has one argument: an Array containing the different fields of the card. The conventions for the components of the Array are exactly the same as for the Array returned by method “fillCard” discussed above. (This means that first element of the Array, of index 0, is a String corresponding to the name of the Nastran card.)

Method “insertCards” corresponds to “insertCard” but allows to insert several cards with a single call to the method. The argument of the method is then an Array of Arrays.

Remarks about the insertion methods:

III.1.1.6 “CoordSys” methods

The “CoordSys” class allows the manipulation of coordinate systems for post-processing purpose. This class is presented in Chapter I.2. One presents below the methods of NastranDb class devoted to the manipulation of coordinate systems.

III.1.1.6.1 “getCoordSysCopy”

The “getCoordSysCopy” method returns a CoordSys object which is a copy of a coordinate system stored in the DataBase. The method has one integer argument which is the index of the coordinate system.

Note that the CoordSys returned by the method may be a “generic” CoordSys as presented in Chapter I.2, or a Nastran coordinate system.

III.1.1.6.2 “addCoordSys”

The “addCoordSys” method is used to add a coordinate system to the DataBase. The argument of the method is the CoordSys object. In the DataBase, the object is referenced by its index.

If a coordinate system with the same index already exists in the NastranDb, it is replaced by the new coordinate system. In that case, the user is responsible for all the modifications involved in the finite element model by the possible modification of the NastranDB coordinate system. Therefore, it is considered as a good practice not to modify a coordinate involved in the finite element model definition.

Note that the coordinate system index must be a strictly positive integer. Also, the CoordSys inserted by the method may be a “generic” CoordSys as presented in Chapter I.2, or a Nastran coordinate system.

III.1.1.6.3 “makeAllCoordSysWrt0”

This method updates the definition wrt 0 (most basic coordinate system) of all the coordinate systems stored in a NastranDB. This operation is necessary when a coordinate system of the NastranDB has been modified, because the definitions of other coordinate systems wrt 0 may be affected.

III.1.1.7 Construction of Groups by associations

The list of “NastranDb” methods returning Groups defined by association follows:

III.1.1.8 “OP2” methods for reading Results

Several methods allow the reading of results from an “op2” file or to tune the behavior of reading this file. These methods are described below. The reading of 32bits as well as 64bits “op2” files is possible. However there is no advantage in reading 64bits version. Actually, these files are larger and may take a longer time to read.

Note that one strongly advises to attribute an integer ID, and a name to each sub-case defined in Nastran BDF file. For example, in the following example, the sub-case integer ID is 201, and its name is “ORBIT_ONE_MS2_X”:

      SUBCASE 201
         SUBTITLE=ORBIT_ONE_MS2_X
         SPC=702001
         LOAD=601001

Presently, only some of the result data blocks of the file can be read:

The correspondence between the Nastran output requests and the DMAP data blocks written in the “op2” file is given in Tables III.1.7 to III.1.14. Also one gives in the Tables the type names of Results generated in the NastranDb by “readOp2” method. The solution sequences for which Results can be read from an “op2” are:

III.1.1.9 “XDB” methods for extracting XDB information

Several methods allow the reading of Result entities or characteristics stored in an xdb file. Real Results as well as Complex ones can be read from xdb files. This last format of Results can for example be read from a Nastran “xdb” result file corresponding to a SOL107, SOL108 or SOL111.

The reading of 64bits XDB files, as well as 32bits XDB files is possible. Note however that the results that are read are stored in 32bits integer/real values so that there is no advantage in using 64bits XDB files with FeResPost. (It probably slows down the XDB access.)

The use of Nastran "DBCFACT=4" parameter is supported. This parameter generates XDB files with BBBT index (Binary Blocked Balanced Tree Method of entry key storage), instead of Hash storage. The default Nastran seems to be "DBCFACT=0" and corresponds to an Hash Key (HK) of key storage.

Remark: one strongly advises to attribute an integer ID, and a name to each sub-case defined in Nastran BDF file. For example, in the following example, the sub-case integer ID is 201, and its name is “ORBIT_ONE_MS2_X”:

      SUBCASE 201
         SUBTITLE=ORBIT_ONE_MS2_X
         SPC=702001
         LOAD=601001

For all the methods listed in this section, the first argument is a String containing the path to the XDB file. The methods do not require the XDB file to be attached to the Nastran database. However the corresponding methods exist for XDB result files that have been attached to a database. (The corresponding methods with XDB attachments are described in section III.1.1.10.)

The supported elements for extraction of Results is summarized in Table III.1.2. Note that the CPYRAM element does not appear in Table III.1.2. It seems that MSC Nastran outputs no stress/strain results in XDB file, despite the fact that results are saved in OP2 and HDF files.


Table III.1.2: Supported elements for the reading of results from XDB files.
Element Nastran MSC. AccessFeResPost
Name Element ID Element ID Element Id
CBAR 12 34 1
CQUAD4 1 33 2
CTRIA3 4 74 3
CHEXA 2 67 4
CROD 9 1 5
CBEAM 10 2 6
CPENTA 6 68 7
CBUSH 47 102 8
CTETRA 14 39 9
CTRIA6 7 75 10
CQUAD8 3 64 11
CQUAD4(X) 95 171 12
CELASi 16...19 11...14 13
CONM1 30 29 14
CONM2 31 30 15
CFAST ??? ??? 16
CONROD 8 10 17
CSHEAR 11 4 18
CGAP 15 38 19
CQUADR 29 82 20
CTRIAR 34 70 21
CWELD 53 200 22
CBAR(X) 13 100 23

III.1.1.9.1 “getXdbLcNames” method

getXdbLcNames” singleton method returns an Array of String containing the list of load cases to which Results found in an xdb file correspond. The arguments are:

1.

A String specifying the access path to the xdb file.

2.

A Boolean value specifying whether one forces the swap of endianness when reading the XDB file.

The second argument is optional.

III.1.1.9.2 “getXdbScNames” method

getXdbScNames” singleton method returns an Array of String containing the list of sub-cases to which Results found in an xdb file correspond. The arguments are:

1.

A String specifying the access path to the xdb file.

2.

A Boolean value specifying whether one forces the swap of endianness when reading the XDB file.

The second argument is optional.

III.1.1.9.3 “getXdbResNames” method

getXdbResNames” singleton method returns an Array of String containing the Result type names to which Results found in an xdb file correspond. The arguments are:

1.

A String specifying the access path to the xdb file.

2.

A Boolean value specifying whether one forces the swap of endianness when reading the XDB file.

The second argument is optional.

III.1.1.9.4 “getXdbLcScNames” method

getXdbLcScNames” singleton method returns an Array of two elements containing:

1.

An Array of Strings containing the list of load cases to which Results found in the xdb file correspond.

2.

An Array of Strings containing the list of sub-cases to which Results found in the xdb file correspond.

The arguments are:

1.

A String specifying the access path to the xdb file.

2.

A Boolean value specifying whether one forces the swap of endianness when reading the XDB file.

The second argument is optional.

III.1.1.9.5 “getXdbLcScResNames” method

getXdbLcScResNames” singleton method returns an Array of three elements containing:

1.

An Array of Strings containing the list of load cases to which Results found in the xdb file correspond.

2.

An Array of Strings containing the list of sub-cases to which Results found in the xdb file correspond.

3.

An Array of Strings containing the list of Result types to which Results found in the xdb file correspond.

The arguments are:

1.

A String specifying the access path to the xdb file.

2.

A Boolean value specifying whether one forces the swap of endianness when reading the XDB file.

The second argument is optional.

III.1.1.9.6 “getXdbLcInfos” method

getXdbLcInfos” singleton method returns information about the load cases and sub-cases for which Results are stored in a xdb file. The arguments are:

1.

A String specifying the access path to the xdb file.

2.

A Boolean value specifying whether one forces the swap of endianness when reading the XDB file.

The second argument is optional.

The method returns an Array of Arrays. Each element of the Array contains the information for one load case and sub-case identification:

III.1.1.9.7 “printXdbDictionnary” method

printXdbDictionnary” singleton method prints the dictionnary of an XDB file. The arguments are:

1.

A String specifying the access path to the XDB file.

2.

A String specifying the access path to an output file.

3.

A Boolean value specifying whether one forces the swap of endianness when reading the XDB file.

The second and third arguments are optional. If the second argument is omitted or a void String, the dictionnary is printed on standard output.

This method has been added for debugging purpose: it helps to identify the XDB tables that are read, and those which are not.

III.1.1.9.8 “readXdb” method

The “readXdb” method is used to read Results into the DataBase from an “xdb” file generated by Nastran. (Only Results can be read from a Nastran “xdb” file.) The method has up to five arguments:

1.

A String argument that corresponds to the name of the file from which Results are read.

2.

A String or an Array of Strings corresponding to the names of load cases for which Results are imported into the DataBase. If the Array is void or the parameter is omitted, all load cases in xdb result files are considered when results are read.

3.

A String or an Array of Strings corresponding to the names of subcases for which Results are imported into the DataBase. If the Array is void or the parameter is omitted, all sub-cases in xdb result files are considered when results are read.

4.

A String or an Array of Strings corresponding to the identifiers of Results for which Results are imported into the DataBase. If the Array is void or the parameter is omitted, all Results of xdb result files are considered when results are read.

5.

A Boolean value specifying whether one forces the swap of endianness when reading the XDB file.

All parameters, except the first one, can be omitted. Then the method assumes that a void Array has been passed as argument.

Results that can be read are listed below:

Composite failure indices do not seem to be output in the xdb file. Only a few elements are supported. However, the most important ones are read:

The different characteristics of imported Results correspond to the characteristics of corresponding Results read from “op2” files.

Note however, that Complex Results can also be read from xdb files. Generally, the complex Results are the same as the real Results. More information can be found in section X.C.2.

Four methods devoted to the enabling or disabling composite layered Results are defined in the generic “DataBase” class. These methods are presented in section I.1.3.2.

III.1.1.9.9 “readXdb2H” method

The “readXdb2H” method is used to read Results from an “xdb” file generated by Nastran and returns the Results in a Hash object. Arguments are the same as those of “readXdb” method.

III.1.1.9.10 A note on “endianness”

MSC.Nastran is distributed with “TRANS” and “RECEIVE” tools that allow to exchange XDB files on machines with different ENDIAN conventions. This is sometimes necessary, for example, when Patran and Nastran are run on different machines. On the other hand, FeResPost allows the identification of endianness in XDB files (in most cases). In some cases, the user must “force” the choice.

The different methods devoted to XDB files access allow to specify a force on swap endianness. When the corresponding parameter is set to “TRUE”, FeResPost considers that the endianness of binary XDB file does not correspond to the endianness of the machine on which FeResPost executes. Then, a swap of endianness is performed when the binary file is read.

If the “SwapEndianness” parameter is set to false, no modification of endianness is done when the file is read.

If the “SwapEndianness” parameter is not given, FeResPost checks the endiannes of the file and, if needed, does corrections to the binary data that are read. The test is done as follows:

III.1.1.9.11 XDB tables activation

Three singleton methods allow to activate or deactivate the reading of Results from XDB files. More precisely, the XDB results are presented in different tables that correspond to:

Each type of Table can be enabled or disabled separately. This can be useful to filter the importation of Results. Also, if there is a FeResPost bug in the reading of a given Result table, the disabling of this table allows to continue to work with the other results while the development team works to fix the problem.

The three singleton methods devoted to XDB table activation are:

1.

enableXdbTables” is used to re-enable an XDB Result table for XDB Result reading.

2.

disableXdbTables” is used to disable an XDB Result table for XDB Result reading.

3.

getXdbTablesEnableInfos” returns a Hash with String keys and Boolean values that associates the enabled/disabled status of the different XDB tables. (This method also gives you the names of the different XDB tables that can be read from XDB files.)

The two enable/disable methods take one String, or an Array of Strings argument. The Strings correspond to the names of the entities that must be disabled or enabled. The “enable info” method has no argument.

III.1.1.10 Attaching “XDB” files to a Nastran DataBase

Since version 3.4.0, FeResPost allows a random access to XDB result files. This method is more efficient than the methods that import XDB Results into the DataBase, and extracting copies of these Results. A peculiar case in which the random access methods will be more efficient is when only some small parts of the XDB file are of interest to the programmer.

The principle of random access is the same as the attachment of XDB files to a Patran DataBase:

The different methods called to perform these operations are described in the following sub-sections. These methods correspond more or less to the methods described in section III.1.1.9.

III.1.1.10.1 Managing XDB file attachments

The method “attachXdb” is used to attach an XDB file to the Nastran DataBase. This method has up to two arguments:

1.

The first argument is a String containing the name of the XDB file. (Full path name must be provided.)

2.

The second argument is an optional Boolean parameter specifying whether the endianness must be swapped when XDB file content is read. If the parameter is not given, the endianness of the file is automatically detected. Note however that this check might fail. (See also page 578 for more information.)

Several other methods are used to manage the Xdb attachments to a DataBase:

III.1.1.10.2 Extracting information of XDB file attachments

The following methods extract information related to the Results stored in an XDB file attached to the DataBase:

All these methods have a single String argument containing the name of the XDB file that must have been previously attached to the DataBase. On the other hand, the following methods have one or two arguments:

The first argument is the name of the XDB file that must have been previously attached to the DataBase. The second argument is optional and corresponds to the name of a load case found in the attached XDB file. If the argument is not provided, all the load cases are investigated to build the list of sub-cases or Result names or IDs. If the argument is provided, only the sub-cases or Results of the corresponding load case are considered. If the provided load case does not exist in XDB attachment an error message is issued.

III.1.1.10.3 Extracting Results From XDB file attachments

The method “getAttachmentResults” is used to read Results from the XDB file. The Results are directly returned by the method to the caller in a Hash object. They are not inserted in the DataBase from which the method is called.

The method has minimum four arguments:

1.

A String corresponding to the name of XDB file attachment from which Results are read. (This file must have been previously attached to the DataBase.)

2.

A String corresponding to the name of the load case for which Results are read.

3.

A String or an Array of Strings corresponding to the names of sub-cases for which Results are read.

4.

A String or an Array of Strings corresponding to the names of Results for which Results are read. The Result name provided as arguments must be considered as “filters” or “hints” indicating which kind of Results are extracted. Practically, FeResPost checks whether possible extracted Results contain one of the Strings provided as argument. For example, that the Request “Stress Tensor” matches several Results:

  • “Stress Tensor”,

  • “Stress Tensor (RI)”,

  • “Stress Tensor (MP)”.

On the other hand, the request “Stress Tensor (RI)” matches only “Stress Tensor (RI)”, and not “Stress Tensor” or “Stress Tensor (MP)”.

The other arguments are optional and correspond to the specification of target entities for which Results are read. Actually, the reading operation from an XDB combines the reading and some of the extraction operations described in section I.4.3. For example:

If only four parameters are provided in the call to “getAttachmentResults” method, all the pairs of key-values found in the XDB file are inserted in the list of returned Results.

Only lists below the list of valid calls to “getAttachmentResults”:

    h=db.getAttachmentResults(xdbName,lcName,scNames,resNames,
            method,grpTarget[,layers[,subLayers]])
    h=db.getAttachmentResults(xdbName,lcName,scNames,resNames,
            resTarget)
    h=db.getAttachmentResults(xdbName,lcName,scNames,resNames,
            rklTarget)
    h=db.getAttachmentResults(xdbName,lcName,scNames,resNames
            [,layers[,subLayers]])

When Results are extracted from an XDB attachment on a Group, the “Method” argument may influence the efficiency of Results extraction. When possible, a real random access is performed, otherwise, entire tables must be read to ensure that all eligible Result values are loaded. For example:

It is the responsibility of the post-processing programmer to try to provide the arguments in order to select the most efficient algorithm for Results extraction.

Note that “Grid Point Forces” are always sorted by nodes. This is true for the applied loads, the MPC/SPC forces and moments, as well as for the internal forces and moments. (Even though these last contain forces by elements and nodes.) This mean that for the selection of extraction algorithm, “Grid Point Forces” should always be considered as nodal Results.

As several Result types, and sub-case names can be given as argument to “getAttachmentResults” method, this method can return several Results. This is why Results are returned in a Hash:

For example, the list of extracted Result sizes can be printed with the following statements:

    h=db.getAttachmentResults(xdbFileName,lcName,scNames,resNames,"Nodes",grp)
    h.each do |id,res|
        lcName=id[0]
        scName=id[1]
        resName=id[2]
        size=res.Size
        STDOUT.printf("%s - %s - %s : %d\n",lcName,scName,resName,size)
        #~ Util::printRes(STDOUT,"brol",res)
    end

The method “getAttachmentResultsCombili” is used to extract linear combinations of elementary Results found in one or several XDB files. As for method “getAttachmentResults” the Results are directly returned by the method to the caller. They are not inserted in the DataBase from which the method is called. This method is more or less a combination of the methods “getAttachmentResults” and “buildLoadCasesCombili” of the generic DataBase class.

Practically, the main difference between “getAttachmentResults” and “getAttachmentResultsCombili” is that the first argument is no longer an Xdb file name. This argument is removed. Instead, one provides a “Combili” argument that describes the linear combination corresponding to extracted Results. This “Combili” argument is the second argument. The first argument is the “LcName” argument corresponding to the load case name attributed to the generated Results. This load case name is unsupposed to correspond to any load case name found in the attached XDB file(s).

The method has minimum four arguments:

1.

A String corresponding to the name of the load case for which Results are read.

2.

A “Combili” Array containing the description of the linear combination of elementary load case Results. The Array is an Array of Arrays. Each secondary Array contains three elements:

  • A Real value corresponding to the factor in the linear combination.

  • A String corresponding to the name of the XDB file from which elementary Results are read. This file must have been previously attached to the Nastran DataBase.

  • A String corresponding to the name of the load case for which Results are extracted.

3.

A String or an Array of Strings corresponding to the names of sub-cases for which Results are read.

4.

A String or an Array of Strings corresponding to the names of Results for which Results are read.

The other arguments are optional and correspond to the specification of target entities for which Results are read. Actually, the reading operation from an XDB combines the reading and some of the extraction operations described in section I.4.3. For example:

If only four parameters are provided in the call to “getAttachmentResultsCombili” method, all the pairs of key-values found in the XDB file are inserted in the returned Results.

Only lists below the list of valid calls to “getAttachmentResultsCombili”:

    h=db.getAttachmentResultsCombili(xdbFileName,lcName,combili,
            scNames,resNames,
            method,grpTarget[,layers[,subLayers]])
    h=db.getAttachmentResultsCombili(xdbFileName,lcName,combili,
            scNames,resNames,
            resTarget)
    h=db.getAttachmentResultsCombili(xdbFileName,lcName,combili,
            scNames,resNames,
            rklTarget)
    h=db.getAttachmentResultsCombili(xdbFileName,lcName,combili,
            scNames,resNames
                [,layers[,subLayers]])

The Hash object returned by the method has a structure identical to the one returned by “getAttachmentResults” and can be manipulated the same way.

III.1.1.10.4 Importing Results From XDB file attachments

The method “importAttachmentResults” is used to read Results from the XDB file. Instead of being returned to the caller in a Hash object, the results are imported into the list of results stored into the Nastran DataBase. The method has four arguments:

    db.importAttachmentResults(xdbName,lcName,scNames,resNames)

III.1.1.10.5 Getting optimization data from XDB

It is possible to obtain some of the Nastran optimization (SOL200) results from an XDB attachment. Four methods have been defined in NastranDb class:

1.

getAttachmentDesVarHistory” returns the history of design variables and has three parameters:

  • “xdbFileName”, a String corresponding to the name of the attached XDB file.

  • “iSteps”, an Array of integers corresponding to the list of steps for which one wishes to obtain results.

  • “iDesVarIds”, an array of integers corresponding to the list of design variable IDs for which one wishes to obtained the results.

Parameters 2 and 3 are optional and can be omitted or replaced by a “nil” argument or a void Array. If they are not defined, all the steps or design variables are returned in the results. The method returns a N*3 array. For each line, the three columns correspond to:

  • The first element is an integer corresponding to the optimization step ID.

  • The second element is an integer corresponding to identifier of the design variable.

  • The third element is a float containing the design variable value.

2.

getAttachmentConstrDefinitions” returns the definition of constraints and has two arguments:

  • “xdbFileName”, a String corresponding to the name of the attached XDB file.

  • “iConstrIds”, an array of integers corresponding to the list of constrain IDs.

Parameters 2 is optional and can be omitted or replaced by a “nil” argument. The method returns a N*6 array. For each line, the three columns correspond to:

  • The first element is an integer corresponding to an internal ID for the considered constrain equation.

  • The second element is an integer, the Nastran Design Constrain ID.

  • The third element is an integer corresponding to the internal response ID.

  • The fourth element is an integer corresponding to RTYPE. (I dot not know what is is.)

  • The fifth element is an integer corresponding to the LUFLAG. Its value is 1 or 2 (">" or ">").

  • The sixth element is a float corresponding to the bound.

3.

getAttachmentConstrHistory” returns the history of constrains and has three parameters:

  • “xdbFileName”, a String corresponding to the name of the attached XDB file.

  • “iSteps”, an Array of integers corresponding to the list of steps for which one wishes to obtain results.

  • “iIRIds”, an array of integers corresponding to the list of internal response IDs for which one wishes to obtained the results.

Parameters 2 and 3 are optional and can be omitted or replaced by a “nil” argument. If they are not defined, all the steps or design responses are returned in the results. The method returns a N*3 array. For each line, the three columns correspond to:

  • The first element is an integer corresponding to the optimization step ID.

  • The second element is an integer corresponding to identifier of the design response.

  • The third element is a float containing the design response value.

4.

getAttachmentObjectiveHistory” returns the history of constrains and has two parameters:

  • “xdbFileName”, a String corresponding to the name of the attached XDB file.

  • “iSteps”, an Array of integers corresponding to the list of steps for which one wishes to obtain results.

Parameter 2 is optional and can be omitted or replaced by a “nil” argument. If it is not defined, all the steps are returned in the results. The method returns a N*3 array. For each line, the three columns correspond to:

  • The first element is an integer corresponding to the optimization step ID.

  • The second element is a float corresponding to the value of objective.

  • The third element is an integer containing the identifier of an internal response.

  • The fourth element is a float containing the value of the maximum constraint equation (corresponding to the previous internal response).

5.

getAttachmentDesRespHistory” returns the history of design responses and has three parameters:

  • “xdbFileName”, a String corresponding to the name of the attached XDB file.

  • “iSteps”, an Array of integers corresponding to the list of steps for which one wishes to obtain results.

  • “iDesRespIds”, an array of integers corresponding to the list of design responses IDs for which one wishes to obtained the results.

Parameters 2 and 3 are optional and can be omitted or replaced by a “nil” argument. If they are not defined, all the steps or design variables are returned in the results. The method returns a N*3 array. For each line, the three columns correspond to:

  • The first element is an integer corresponding to the optimization step ID.

  • The second element is an integer corresponding to identifier of the design response.

  • The third element is a float containing the design response value.

So far, the reading of optimization results is experimental and might be changed in future version.

III.1.1.10.6 Storage buffers for XDB result files random access

In order to reduce the number of accesses to disk, it may be useful to store some of the blocks read from binary result files into memory. FeResPost provides an algorithm that allows to store the blocks most recently read for later usage. Two singleton methods of the “NastranDb” class allow the to tune the capacity of the buffer area:

Note that all buffers are now common to all the methods that provide random access to XDB result files. In particular, the method is used in management of the binary file access for XDB attachment or reading. This means that if one Result file attached to one DataBase is more used, the storage will contain a majority of buffers for this Result file and progressively delete the other buffers.

The default capacity for storage buffer is 0Mb. Note that the two methods described above can be called from any class derived from the generic “DataBase” class.

III.1.1.10.7 “Raw” access to XDB file content

So far, the XDB access methods that have been described allow the extraction of Results only when the corresponding programming has been done in FeResPost source code. Sometimes, this limitation can be frustrating. For that reason, several methods allowing a “low level” or “raw access” to XDB content have been added.

Before listing these methods, one gives some information about the XDB content:

1.

The XDB file is a binary file divided in pages. Each page has a fixed size specified by a given number of words. (This number of words per page is given in the file by the first word of the file.) A word may correspond to 4 or 8 bytes depending whether the XDB file is output in single or double precision.

2.

The XDB file contains different tables corresponding to finite element model, results,... A “dictionnary” allows to identify and retrieve the different tables stored in an XDB file. In FeResPost, each XDB table is identified with a “ String-Integer key”:

  • The String corresponds to the type of the table. (For example “FBARR” for the Real CBAR element forces.)

  • As several tables of the same type can be defined in an XDB file, FeResPost also uses an integer index that allows to retrieve the right one.

Each table contains fields that can be distributed into several pages. A field corresponds for example to the forces and moments on one CBAR element, and for a given load case and sub-case. The naming conventions for the table types are given in MSC.Access Manual [Nas05]. The dictionnary keys allow to retrieve information from the dictionnary that can be used to retrieve the table content. This information is given in an Array of 22 integers that correspond for example to

  • The index of the first page containing the table,

  • The index of the last page of the table,

  • The size of the fields in the table (15th element of the table, or element of index 14 when the indices numbering starts with 0),

  • The number of fields,

  • The minimum and maximum key IDs,

  • The number of pages of the table...

(For the reading operations, one generally needs the field size.) You may find more information on the meaning of these 22 integers in MSC.Access Manual [Nas05]. The access to dictionnary is done by calling “getAttachmentDictKeys” and “getAttachmentDictionnary” methods.

3.

When results associated to elements are read from an XDB file, the values are associated to a key that corresponds to the element ID. However, this integer does not correspond to the Nastran integer ID of the element. Instead, there is in the XDB file, an “EQEXINE” table that contains the correspondence between the XDB IDs and the Nastran element IDs:

  • The first argument of the method is the Access element type which does not correspond to the Nastran element type. A table of correspondence between the XDB Access element types and Nastran element types is given in section “Differences from MSC.Nastran” (sub-section of “BLOCK DATA DESCRIPTIONS”) of the MSC.Access manual [Nas05]. Part of the Access element IDs is given in the source code in method “xdb::getAccessType” (File “NASTRAN/xdb/xdb_equiv.cpp”).

  • The second argument of the method is the XDB element ID. For each type of element, Nastran generates a sequential XDB numbering starting at 1. The “EQEXINE” table allows to retrieve the corresponding Nastran element ID.

Method “getAttachmentElementExtId” allows to retrieve the Nastran element ID, if you know the type of the element, and its internal ID. The type of the element is the “MSC.Access Element Type” associated to XDB file format. The numbering of element types can be found in [Nas05].

4.

Similarly, the XDB file also contains an “EQEXING” table that allows to retrieve node information. The Access internal node ID numbering starts at 1 and is also sequential. Each node internal ID is associated to three “external” integers:

(a)

The Nastran “external” ID of the node that appears in the GRID card definition.

(b)

The node type is always “1” in the tests we have done. (We presume it corresponds to usual Nastran GRIDs.)

(c)

The Analysis Coordinate System of the GRID. This information is useful as it allows to associate the vectorial results components to a coordinate system.

Method “getAttachmentNodeInfo” is used to retrieve this information when reading nodal results.

The ‘NastranDb” class methods that give a “raw” access to XDB attachment content are:


Table III.1.3: Interpretation of the binary data translation String.
Char Conversion Action
“i” or “l” One word is converted to a single precision integer
“u” One word is converted to a single precision unsigned integer
“I” or “L” 8 bytes (one or two words) are converted to a long long (8 bytes integer)
“U” 8 bytes (one or two words) are converted to an unsigned long long (8 bytes unsigned integer)
“f” or “d” One word is converted to a float (single precision real value)
“F” or “D” 8 bytes (one or two words) are converted to a double (double precision real value)
“s” One word is converted to a String
“S” 8 bytes (one or two words) are converted to a String
“x” One word is skipped and a nil value is generated
“X” 8 bytes (one or two words) are skipped and a nil value is generated
“y” One word is skipped and no value is generated
“Y” 8 bytes (one or two words) are skipped no value is generated

III.1.1.11 Attaching “HDF” files to a Nastran DataBase

Since version 4.5.0 of FeResPost, it is possible to read results from Nastran HDF5 files. The operation is done in several steps:

The different methods called to perform these operations are described in the following sub-sections.

III.1.1.11.1 Reading Results fron an HDF file

The “readHdf” method is used to read Results into the DataBase from an “hdf” file generated by Nastran. (Only Results can be read from a Nastran “hdf” file.) The method has up to four arguments:

1.

A String argument that corresponds to the name of the file from which Results are read.

2.

A String or an Array of Strings corresponding to the names of load cases for which Results are imported into the DataBase. If the Array is void or the parameter is omitted, all load cases in hdf result files are considered when results are read.

3.

A String or an Array of Strings corresponding to the names of subcases for which Results are imported into the DataBase. If the Array is void or the parameter is omitted, all sub-cases in hdf result files are considered when results are read.

4.

A String or an Array of Strings corresponding to the identifiers of Results for which Results are imported into the DataBase. If the Array is void or the parameter is omitted, all Results of hdf result files are considered when results are read.

All parameters, except the first one, can be omitted. Then the method assumes that a void Array has been passed as argument.

This method is a kind of wrapper to several methods described above. If necessary, FeResPost attaches the HDF file, imports the results into the database, and closes the attachment. If the HDF is alread attached, no attachment/detachment is done.

The “readHdf2H” method is used to read Results from an “hdf” file generated by Nastran and return them into an Hash object. Arguments are the same as those of “readHdf” method.

III.1.1.11.2 Managing HDF file attachments

The method “attachHdf” is used to attach an HDF file to the Nastran DataBase. This method has up one argument: a String containing the name of the HDF file. (Full path name must be provided.)

Several other methods are used to manage the Hdf attachments to a DataBase:

III.1.1.11.3 Extracting information from HDF file attachments

The following methods extract information related to the Results stored in an HDF file attached to the DataBase:

All these methods have a single String argument containing the name of the HDF file that must have been previously attached to the DataBase. On the other hand, the following methods have one or two arguments:

The first argument is the name of the HDF file that must have been previously attached to the DataBase. The second argument is optional and corresponds to the name of a load case found in the attached HDF file. If the argument is not provided, all the load cases are investigated to build the list of sub-cases or Result names or IDs. If the argument is provided, only the sub-cases or Results of the corresponding load case are considered. If the provided load case does not exist in HDF attachment an error message is issued.

III.1.1.11.4 Extracting Results From HDF file attachments

Two methods are used to extract results from Nastran HDF files:

The two methods have up to four arguments:

1.

A String corresponding to the name of HDF file attachment from which Results are read. (This file must have been previously attached to the DataBase.)

2.

A String or an Array of Strings corresponding to the names of load cases for which Results are read.

3.

A String or an Array of Strings corresponding to the names of sub-cases for which Results are read.

4.

A String or an Array of Strings corresponding to the names of Results for which Results are read.

One lists below valid calls to “getHdfAttachmentResults”:

    h=db.getHdfAttachmentResults(hdfName,lcNames,scNames,resNames)
    h=db.getHdfAttachmentResults(hdfName,lcNames,scNames)
    h=db.getHdfAttachmentResults(hdfName,lcNames)
    h=db.getHdfAttachmentResults(hdfName)

Similar calls work for “readHdfAttachmentResults” method:

    db.readHdfAttachmentResults(hdfName,lcNames,scNames,resNames)
    db.readHdfAttachmentResults(hdfName,lcNames,scNames)
    db.readHdfAttachmentResults(hdfName,lcNames)
    db.readHdfAttachmentResults(hdfName)

When one of the “lcNames”, “scNames” or “resNames” is missing, nil or an empty Array, all the load cases, sub-cases or result types are read. “getHdfAttachmentResults” method is very similar to the “getAttachmentResults” method used to extract Results from Nastran XDB result files.

III.1.1.11.5 Raw access to HDF Datasets

Several methods can be used to obtain a “raw” access to Nastran HDF Datasets:

Remarks:

III.1.1.12 GMSH outputs

The method “writeGmshMesh” defined in DataBase Class exports nodes, elements and RBEs into the mesh file. RBEs are exported with a negative integer ID. The three tags attributed to the elements are the property ID (twice) and the laminate ID. This means that the three tags have sometimes the same value.

III.1.1.13 Iterators

A first group of iterators iterate on finite element entities of the finite element model stored in the DataBase.

The elements produced by the iterator are single integers. Each of these iterators has 0, 1 or 2 arguments. The two optional arguments are the integer bounds considered for the iteration: “IdMin” and “IdMax”.

Two iterators loop on the nodes defining an element:

These two iterators have one integer argument corresponding to the index of the element. They iterate on the integer indices of nodes.

Iterator “each_xdbRaw” is discussed in section III.1.1.10.7. Iterator “each_bdfCard’ allows to read the content of one (or several) BDF file(s), without trying to import the corresponding FEM entities in a NastranDb database. This is a singleton method, which means that the method is to be called directly from NastranDb class. The arguments of the method are the same as those of “readBdf” method described in section III.1.1.1:

1.

A String containing the name of the main Nastran Bulk Data File.

2.

An Array of Strings containing the list of directories in which files specified by “include” statements shall be searched. Its default value is a void Array.

3.

The name of an extension that may be added to the file names specified in include statements. Its default value is a void String. (This argument corresponds to the jidtype in Nastran.)

4.

A Hash with String keys and values corresponding to the list of “symbols” that can be used in “include” statements in the Bulk Data Files. The default value is a void Hash.

5.

A Logical that specifies verbosity for the scanning of the Nastran Bulk Data File. Its default value is “false”. This parameter is redundant with “setVerbosityLevel” of “Post” Module: to set the parameter to “true” is equivalent to set “Post” verbosity level to 1.

6.

A Logical that specifies whether the file contains only Bulk Data Section lines. Its default value is “false”. If the parameter is “true”, the “BEGIN BULK” and “ENDDATA” lines are ignored, and all the input lines, except comments, are interpreted. (See also the remarks below.)

For example, the iterator can be used as follows:

    NastranDb.each_bdfCard("../../MODEL/MAINS/unit_xyz.bdf") do |crd|
        puts crd
    end

III.1.1.14 Other methods

Several other methods allow to obtain model information.

III.1.1.15 Attributes

Two attribute “getters” allow to access information in the model:

III.1.2 Nastran Result characteristics

When a Result object is read from an “op2” or an “xdb” file, integer and/or real identifiers are associated to the object. These identifiers depend on the solution sequence to which the Results correspond:

The “load case name” identifier associated to read or accessed results correspond to the “SUBTITLE” associated to the SUBCASE defined in Nastran data file. If this SUBTITLE is not define, the SUBCASE ID is used to generate a default load case identifier as follows:

 lcName="Load Case "+ID

The subcase names are automatically generated by FeResPost when the Results are read from output files. Table III.1.5 lists possible subcase names generated by FeResPost when Nastran Results are read from OP2, XDB or HDF files. The integer and real values associated to the Results for each Nastran solution type are listed in Table III.1.4.

Table III.1.4: Integer and Real IDs associated to the different solution types
Analysis Type Int ID 1 Int ID 2 Real ID 1 Real ID 2
Linear Static LCID -1 -1.0 -1.0
Modal (Real) LCID Mode ID Frequency -1.0
Random LCID Freq. output ID Frequency -1.0
Transient LCID Time Step ID Time -1.0
Buckling LCID Mode ID Critical Load -1.0
Nonlinear LCID Output Step ID “Time” -1.0
Frequency Response LCID Freq. output ID Frequency -1.0
Modal (Complex) LCID Mode ID Freq. (real) Freq. (imaginary)

Table III.1.5: Subcase names generated by FeResPost when Nastran Results are read from OP2, XDB or HDF files.
SOL 101 (Linear Statics)
C++ ret=“Statics”
Example “Statics”
SOL 103 (Modal Analysis)
C++ sprintf(buf,“Mode %d (f = %.4f)”,intId1,realId1);
Example “Mode 3 (f = 15.3684)”
SOL 105 (Buckling Analysis)
C++ sprintf(buf,“Mode %d (eig = %.4f)”,intId1,realId1);
Example “Mode 1 (eig = 2.5463)”
SOL 106 or SOL 400 (Non-linear Statics)
C++ sprintf(buf,“Step %d (s = %.4f)”,intId1,realId1);
Example “Step 1 (s = 1.2563)”
SOL 107 (Complex eigen-values)
C++ if (realId2>=0.0)
sprintf(buf,“Mode %d (eig = %.4f+%.4f*i)”,intId1,realId1,realId2);
else
sprintf(buf,“Mode %d (eig = %.4f%.4f*i)”,intId1,realId1,realId2);
Example “Mode 7 (eig = 2.5463-3.5897*i)”
SOL 108 or SOL 111 (Frequency response)
C++ sprintf(buf,“Output %d (f = %.4f)”,intId1,realId1);
Example “Output 58 (f = 43.2568)”
Random Results
C++ sprintf(buf,“Random PSD Output %d (f = %.4f)”,intId1,realId1);
Example “Random PSD Output 58 (f = 43.2568)”
C++ sprintf(buf,“Random ATOC Output %d (f = %.4f)”,intId1,realId1);
Example “Random ATOC Output 58 (f = 43.2568)”
C++ sprintf(buf,“Random CRMS Output %d (f = %.4f)”,intId1,realId1);
Example “Random CRMS Output 58 (f = 43.2568)”
C++ ret=“Random RMS”
Example “Random RMS”
C++ ret=“Random NOC”
Example “Random NOC”

Finally, the results found in the op2 file are presented by blocks corresponding to the different “result element types”. Unfortunately, those element types do not correspond exactly to the element bdf cards presented in section III.1.1.1. The supported result element types are: “ROD”, “BEAM”, “TUBE”, “SHEAR”, “CONROD”, “ELAS1”, “ELAS2”, “ELAS3”, “ELAS4”, “DAMP1”, “DAMP2”, “DAMP3”, “DAMP4”, “VISC”, “MASS1”, “MASS2”, “MASS3”, “MASS4”, “CONM1”, “CONM2”, “PLOTEL”, “QUAD4”, “BAR”, “GAP”, “TETRA”, “BUSH1D”, “QUAD8”, “HEXA”, “PENTA”, “BEND”, “TRIAR”, “TRIA3”, “TRIA6”, “QUADR”, “TETRANL”, “GAPNL”, “TUBENL”, “TRIA3NL”, “RODNL”, “QUAD4NL”, “PENTANL”, “CONRODNL”, “HEXANL”, “BEAMNL”, “QUAD4LC”, “QUAD8LC”, “TRIA3LC”, “TRIA6LC”, “BUSH”, “FAST”, “QUAD144”, “QUADRNL”, “TRIARNL”, “ELAS1NL”, “ELAS3NL”, “BUSHNL”, “QUADRLC” and “TRIARLC”. (More information on the result element types can be found in [Rey04].)

Here again, some of the element result types can be disabled or enabled (section III.1.1.1). The arguments given to the enabling or disabling methods correspond to a String object, or an Array of Strings, the values of Strings corresponding to some of the Result element types given just above.

The negative node values corresponding to Results on specific Nastran elements are summarized in Table III.1.6. (This Table is a complement to Table I.4.2.) These keys can be used when Results are read from “OP2” or “XDB” files. Note that the “CbarGrdA” and “CbarGrdB” are used only to associate values to CBAR end nodes when the definition of CBAR element has not been found in the DataBase.


Table III.1.6: Correspondence between special nodes for element Results and their integer ids (peculiar to Nastran solver).
For Nastran CSHEAR element
"F4to1" -201
"F2to1" -202
"F1to2" -203
"F3to2" -204
"F2to3" -205
"F4to3" -206
"F3to4" -207
"F1to4" -208
"kickOn1" -211
"kickOn2" -212
"kickOn3" -213
"kickOn4" -214
"shear12" -221
"shear23" -222
"shear34" -223
"shear41" -224
For Nastran CBEAM element (or CBAR element with intermediate stations)
"CbeamSt01" to "CbeamSt40" -101 to -140
For Nastran CBAR element
"CbarGrdA" -151
"CbarGrdB" -152

III.1.2.1 General Results

The correspondence between the Nastran output requests and the DMAP data blocks written in the “op2” file is given in Tables III.1.7 to III.1.16. Note that in all the examples presented in Part IV, the results are printed in the “op2” file with “SORT1” option. This means that no test has been done with “SORT2” option.


Table III.1.7: Correspondence between the Nastran output cards and the “op2” result data blocks. (Displacements read from OUG data blocks.)
Nastran “op2” Generated
StatementData Block Result
DISPL OUG “Displacements, Translational” “Displacements, Rotational” “Displacements, Scalar”
VELO OUG “Velocities, Translational” “Velocities, Rotational” “Velocities, Scalar”
ACCEL OUG “Accelerations, Translational” “Accelerations, Rotational” “Accelerations, Scalar”


Table III.1.8: Correspondence between the Nastran output cards and the “op2” result data blocks. (Applied loads read from OPG data blocks.)
Nastran “op2” Generated
StatementData Block Result
OLOAD OPG “Applied Loads, Forces” (2, 3) “Applied Loads, Moments” (2, 3)


Table III.1.9: Correspondence between the Nastran output cards and the “op2” result data blocks. (MPC and SPC forces read from OQG data blocks.)
Nastran “op2” Generated
Statement Data Block Result
MPCFORCES OPG “MPC Forces, Forces” (2, 3) “MPC Forces, Moments” (2, 3) “MPC Forces, Scalar” (2, 3)
SPCFORCES OPG “SPC Forces, Forces” (2, 3) “SPC Forces, Moments” (2, 3) “SPC Forces, Scalar” (2, 3)


Table III.1.10: Correspondence between the Nastran output cards and the “op2” result data blocks. (Grid point forces read from OGF data blocks.)
Nastran “op2” Generated
Statement Data Block Result
GPFORCES OGF “Grid Point Forces, Internal Forces” “Grid Point Forces, Internal Moments” “Grid Point Forces, MPC Forces” (2) “Grid Point Forces, MPC Moments” (2) “Grid Point Forces, MPC Internal Forces” (4) “Grid Point Forces, MPC Internal Moments” (4) “Grid Point Forces, SPC Forces” (2) “Grid Point Forces, SPC Moments” (2) “Grid Point Forces, Applied Forces” (2) “Grid Point Forces, Applied Moments” (2)


Table III.1.11: Correspondence between the Nastran output cards and the “op2” result data blocks. (Strains read from OES data blocks and corresponding to “STRAIN” output requests..)
Nastran “op2” Generated
StatementData Block Result
STRAIN OES “Strain Tensor” (5, 2) “Beam Axial Strain for Axial Loads” “Beam Axial Strain for Bending Loads” “Beam Axial Strain for Total Loads” (9) “Beam Shear Strain for Torsion Loads” “Beam Deformations” (15) “Beam Velocities” (15) “Beam Stations” (18) “Gap Forces” (16) “Gap Deformations” (16) “Gap Slips” (16) “Spring Scalar Strain” “Bush Forces Strain Tensor” (13 and 14) “Bush Moments Strain Tensor” (13 and 14) “Bush Plastic Strain” (13 and 14) “Curvature Tensor” (5, 8) “Shear Panel Strain, Max” “Shear Panel Strain, Average”


Table III.1.12: Correspondence between the Nastran output cards and the “op2” result data blocks. (Stresses read from OES data blocks and corresponding to “STRESS” output requests.)
Nastran “op2” Generated
StatementData Block Result
STRESS OES “Stress Tensor” (1 in section III.1.2.2) “Beam Axial Stress for Axial Loads” “Beam Axial Stress for Bending Loads” “Beam Axial Stress for Total Loads” (9) “Beam Shear Stress for Torsion Loads” “Beam Forces” (13 and 14) “Beam Moments” (13 and 14) “Beam Deformations” (15) “Beam Velocities” (15) “Beam Stations” (18) “Gap Forces” (16) “Gap Deformations” (16) “Gap Slips” (16) “Spring Scalar Stress” “Bush Forces Stress Tensor” (13 and 14) “Bush Moments Stress Tensor” (13 and 14) “Bush Stress, Axial” (15) “Bush Strain, Axial” (15) “Bush Plastic Strain” (15) “Shear Panel Stress, Max” “Shear Panel Stress, Average”


Table III.1.13: Correspondence between the Nastran output cards and the “op2” result data blocks. (Nonlinear stresses read from OES data blocks and corresponding to “NLSTRESS” or other output requests (19).)
Nastran “op2” Generated
Statement Data Block Result
NLSTRESS OES “Nonlinear Stress Tensor” (6) “Nonlinear Strain Tensor” (6) “Nonlinear Effective Plastic Strain” (6) “Nonlinear Effective Creep Strain” (6) “Nonlinear Spring Scalar Strain” “Nonlinear Spring Scalar Stress” “Nonlinear Beam Axial Strain for Axial Loads” “Nonlinear Beam Axial Stress for Axial Loads” “Nonlinear Beam Axial Strain for Total Loads” “Nonlinear Beam Axial Stress for Total Loads” “Nonlinear Beam Forces” “Nonlinear Beam Moments” “Beam Stations” (18) “Nonlinear Bush Forces Stress Tensor” (13 and 14) “Nonlinear Bush Moments Stress Tensor” (13 and 14) “Nonlinear Bush Forces Strain Tensor” (13 and 14) “Nonlinear Bush Moments Strain Tensor” (13 and 14) “Nonlinear Gap Forces” (16) “Nonlinear Gap Deformations” (16) “Nonlinear Gap Slips” (16)


Table III.1.14: Correspondence between the Nastran output cards and the “op2” result data blocks. (Element forces read from OEF data blocks or other “FORCE” output.)
Nastran “op2” Generated
Statement Data Block Result
FORCE (1, 15) OEF “Shell Forces” “Shell Moments” (7) _______________________________________________ “Beam Forces” (10, 11,12) “Beam Moments” (10, 11,12) “Beam Warping Torque” “Beam Deformations” “Beam Velocities” “Beam Stations” (18) “Gap Forces” (16) “Gap Deformations” (16) “Gap Slips” (16) “Spring Scalar Forces” “Bush Plastic Strain”


Table III.1.15: Correspondence between the Nastran output cards and the “op2” result data blocks. (Element forces read from OEE data blocks or “ESE”, “EKE” and “EDE” output.)
Nastran “op2” Generated
StatementData Block Result
ESE OEE “Element Strain Energy” “Element Strain Energy (Density)” “Element Strain Energy (Percent of Total)”
EKE OEE “Element Kinetic Energy” “Element Kinetic Energy (Density)” “Element Kinetic Energy (Percent of Total)”
EDE OEE “Element Energy Loss” “Element Energy Loss (Density)” “Element Energy Loss (Percent of Total)”


Table III.1.16: Nastran Results for thermal calculations.
Nastran “op2” Generated
Statement Data Block Result
TEMPERATURE OUG “Temperature”
FLUX OEF “Temperature Gradient”
FLUX OEF “Conductive Heat Flux”

One can make a few remarks about the information given in Tables III.1.7 to III.1.16:

1.

The Nastran “CELASi” and “CDAMPi” elements produce scalar forces or moments that are stored in “Beam Scalar Forces” Results.

2.

“Applied Loads” are available both with the “OLOAD” and “GPFORCE” Nastran statements. A similar remark can be done for “MPC Forces” and “SPC Forces”.

3.

When forces or moments corresponding to “Applied Loads”, “MPC Forces” or “SPC Forces” are read by FeresPost, key-values pairs are inserted only when at least one of the components is not zero. This has been done to avoid the creation of Result objects filled with a lot of zero values.

4.

When the option “RIGID=LAGR” is activated, the contributions of rigid body elements and MPCs are included in “Grid Point Forces, MPC Forces” and “Grid Point Forces, MPC Moments” and not in “Grid Point Forces, Internal Forces” and “Grid Point Forces, Internal Moments”:

  • For the Results “Grid Point Forces, MPC Forces” and “Grid Point Forces, MPC Moments” The ElemId of each key is set to “NONE”. (These Results are pure nodal Results.)

  • For the “Grid Point Forces, Internal Forces” and “Grid Point Forces, Internal Moments” Results, The ElementId associated to each vector corresponds to the MPC ID of the RBE element. This means that one must be careful when extracting these Results on Groups of MPCs.

5.

The shear components of strain tensor output by Nastran are the angular deformations: γij = 2ϵij. When these results are imported in a NastranDb, the corresponding components are divided by two in such a way that a “physical” tensor is stored into the NastranDb. The same remark applies for the non-diagonal components of the curvature tensor (shell elements).

The “STRAIN” Nastran output statement with “FIBER” option outputs the strain tensor at Z1 and Z2, but do not produce the curvature tensor.

6.

The Nonlinear stresses and strains are available for CHEXA, CPENTA, CTETRA, CQUAD4 and CTRIA3 elements. Plastic deformation results are produced for non-linear results only.

7.

When shell bending moments are imported from Nastran finite element results, the sign of each component is changed. This has been done to ensure that a positive component of the bending moment results in a positive value of the corresponding stress tensor component on the upper face of the shell. In other words, a positive bending corresponds to tension stress in shell upper face. (See equation II.1.31 for the definition of bending moments tensor components.)

8.

When Nastran shell curvature Results are imported, two modifications are brought to the components:

  • The signs of all the components are changed,

  • The shear components of the tensor are divided by two.

This is done because FeResPost considers that positive curvature components correponds to positive strain components in upper face of the shell, and negative components in lower face of the shell. (See equation II.1.32 for the definition of curvature tensor components.)

9.

“Axial Strain” or “Axial Stress” for “Total Loads” and CBAR elements are produced by combined axial loads to bending loads. This has been done to harmonize CBAR Results with CBEAM Results. For CBEAM Results, Stresses or Strains are recovered on the extremities only.

10.

Nastran “BEAM” type elements (CBAR, CBEAM, CBEND,...) do not output vectorial or tensorial forces or moments. Instead, the different components are expressed in different coordinate systems (axial, plane 1 and plane 2). When importing these Results, a conversion into tensorial format is done as follows:

F = ( FxxFxyFxz Fxy 0 0 Fxz 0 0 ) = ( FaxialV 1V 2 V 1 0 0 V 2 0 0 ) ,

M = ( MxxMxyMxz Mxy 0 0 Mxz 0 0 ) = ( Mtorsion - M2M1 - M2 0 0 M1 0 0 ) .
11.

Nastran CBUSH elements produce forces and moments corresponding to the loads applied by Grid B of the element to Grid A. By analogy with the what is done for “BEAM” type of elements, one produces “Beam Forces” and “Beam Moments” filled as follows:

F = ( FxxFxyFxz Fxy 0 0 Fxz 0 0 ) = ( FxFyFz Fy 0 0 Fz 0 0 ) ,

M = ( MxxMxyMxz Mxy 0 0 Mxz 0 0 ) = ( MxMyMz My 0 0 Mz 0 0 ) .

The choice of considering bush forces and moments as beams is questionable, and we justify this choice as follows:

  • When grids A and B are not coincident, the definition of CBUSH element axes can be done the same way as for CBEAM elements (Figure III.1.1.a). The ex vector points from grid A to grid B, and X component of force vector is positive when the CBUSH element is in tension, and the analogy between CBUSH element and CBEAM elements perfect, and the tensorial character of CBUSH element forces and moments is obvious.

  • It is no longer true when the CBUSH orientation is specified with a coordinate system as represented in Figure III.1.1.a. In such a case, X component of force vector no longer can be interpreted as a tension in CBUSH element. It is only the force applied by grid B to grid A, and projected on CBUSH coordinate system X axis.

CBUSH elements are often used in the modeling of connections. Whatever the type of coordinate system definition, is is always possible to obtain vectorial forces and moments by a contracted multiplication of the vectorial result with a unit vector:

f = ( FxxFxyFxz Fxy 0 0 Fxz 0 0 ) (1 0 0 ) = ( Fxx Fxy Fxz ) ,

m = ( MxxMxyMxz Mxy 0 0 Mxz 0 0 ) (1 0 0 ) = ( Mxx Mxy Mxz ) .

This is generally the first operation performed when CBUSH loads are used for the sizing of connections. This also works when connection forces are extracted from CBEAM or CBAR elements.


PICT
(a)
PICT
(b)

Figure III.1.1: CBUSH element axes definition. (Pictures extracted from [Sof04b].)

12.

For CBAR elements, “Beam Forces” are always produced at the center of elements, and “Beam Moments” at the two end nodes. For CBEAM elements, “Beam Forces” and “Beam Moments” can be requested at different stations long the element. A minimum is then the production of outputs at the two ends of the element; Therefore, “Beam Forces” are output at element end nodes, as a minimum. But generally, no “Beam Forces” are output at element centers.

13.

Bush result types for OEF and OES outputs depend on the kind of BUSH elements to which they correspond:

  • Nastran “CBUSH” elements for linear analyses produce vectorial or tensorial results in OEF and OES blocks.

  • Nastran “CBUSH” elements for non-linear analyses produce vectorial or tensorial results in OES blocks. No results are produced in OEF blocks.

The element forces and moments are stored in “Beam Forces” and “Beam Moments” tensorial Results.

14.

The result types generated for CFAST elements are the same as for CBUSH elements.

Note that FeResPost cannot determine the CFAST element coordinate system when grids A and B are coincident. This may cause problems when transformation of reference coordinate systems are required. (This is the case when gmsh outputs of results are requested.) Note also that Patran also seems to experience some difficulties to calculate CFAST element axes.

15.

Nastran “CBUSH1D” elements produce scalar results in OEF and OES blocks. By this we means that each type of result has only one single component. However, the scalar force is stored in “Beam Forces” tensorial result. Most components of the tensor are zero:

F = ( Fxx00 0 00 0 0 0 ) .

No bending moments are produced by “CBUSH1D” elements.

16.

Nastran “CGAP” elements produces various results. These Results are read from OES or OEF data blocks. These Results are tensorial and:

  • Gap forces results are stored in “Gap Forces” tensorial Result. The value of the axial component is multiplied by “-1.0”, because it is a compression component.

  • Gap deformations are stored in “Gap Deformations” tensorial Result. Here again the value of the axial component is multiplied by “-1.0”.

  • “Gap Slips” is identical to “Gap Deformations” except that the axial component is set to “0.0”.

17.

Various Nastran elements refer scalar points instead of grids. Nevertheless, Nastran considers the scalar point as a kind of element rather than as a kind of grid. This is, in our opinion, an unfortunate choice! FeResPost considers SPOINT and EPOINT objects as a peculiar type of GRID. This has implications for the definition of keys when importing Results with from Nastran op2 files. One hopes that this will not lead to problems!

18.

The “Beam Stations” scalar result is produced when stresses, strains or forces are read for CBEAM or CBAR elements:

  • This Result corresponds to the location of beam load recovery along the 1D element and varies between 0 and 1. It is scalar and has always a real format.

  • Intermediate stations, differing from 0 or 1, are produced by CBEAM elements, or CBAR elements if associated to a CBARAO card.

  • Up to 40 intermediate stations are supported by FeResPost. Beyond this value, Beam results are not read. This limit should be sufficient as Nastran Manuals recommend that no more than 6 intermediate stations are defined by CBARAO bulk card, and as CBEAM element allow up to 9 intermediate stations.

  • The node IDs to which intermediate station values are associated correspond to the “CbeamSt01” to “CbeamSt40” IDs defined in Table III.1.6.

19.

“Nonlinear” outputs may result from various output requests as “NLSTRESS”, “STRESS”, “STRAIN”, “FORCE”... The “Nonlinear” character of Results is more related to the type of Nastran solution than to the output request. For example, Nastran SOL 106 or SOL 400 analyses are likely to produce “Nonlinear” outputs.

III.1.2.2 Composite Results

This section is more specifically devoted to the composite Results (failure indices). Failure indices can be imported from “op2” files only. The different Results that can be imported from Nastran are summarized in Table III.1.17. One can make a few remarks about the information given in those Tables:

1.

Since version 3.4.2, the stress tensor in plies is produced in “Mid” sub-layer only. This means that the out-of-plane shear stress that Nastran calculates at bottom skin of each ply is displaced at mid-thickness of the ply. This is an approximation. (This out-of-plane shear stress can be used to calculate inter-laminar shear stress in composite.)

A rotation of the out-of-plane shear components is done in such a way that all components are given wrt ply axes. (Nastran outputs these components in laminate axes.)

2.

When Nastran composite strains are read, values are produced for Mid thickness of each ply only. Nothing is produced on ply upper or lower faces.

3.

The remarks done about the conversion of angular shear strain components to tensorial shear strain components are of course also valid for layered strain Results.

4.

Failure indices can be read from “op2” files only. Corresponding Results do not seem to be stored in “xdb” files.

The indices given in Table III.1.17 refer to the remarks above.

Four methods devoted to the enabling or disabling of composite layered Results are defined in the generic “DataBase” class. These methods are presented in section I.1.3.2.


Table III.1.17: Correspondence between the Nastran output cards and composite stresses and strains
Nastran “op2” Generated
StatementData Block Result
STRAIN OES “Strain Tensor” (2, 3)
STRESS OES “Stress Tensor” (1)

The correspondence between the failure indices read from Nastran “op2” files and Results produced by CLA classes is as in Table III.1.18.


Table III.1.18: Correspondence between the Nastran failure indices imported from “op2” files and the failure criteria defined in CLA module.
Nastran Result CLA criterion ID section
“Composite Failure Index, Tsai-Hill” “TsaiHill_c” II.1.10.11
“Composite Failure Index, Tsai-Wu” “TsaiWu” II.1.10.14
“Composite Failure Index, Hoffman” “Hoffman” II.1.10.16
“Composite Failure Index, Maximum Strain, CompMax” “MaxStrain” II.1.10.6
“Composite Failure Index, Interlaminar Shear Stress” “Ilss” II.1.10.27

III.1.3 Interaction with CLA classes

When a PCOMP or a PCOMPG property card is translated into a ClaLam object by a call to “getClaDb” method, the value of LAM parameter is not taken into account. This means that the values of this parameter set to “MEM”, “BEND”, “SMEAR” or “SMCORE” is without effect. There is one exception to this rule: the value “SYM” is taken into account in PCOMP property cards. (But not in PCOMPG cards for which this parameter value is illegal.)

Chapter III.2
Samcef Preferences

Most methods peculiar to the post-processing of Samcef finite element Results and models are defined in class “SamcefDb” that inherits the “DataBase” class. This class is described in section III.2.1.

Table III.2.1: The different methods that have been defined in “SamcefDb” class. See also the methods defined in generic DataBase class (Table I.1.1). Methods marked with “(s)” are singleton methods.
(FeResPost list of classes is given in Table 1 page 11.)
(See also methods in generic DataBase class.)
Method Name DescriptionExample
Creation and initialization methods
new (s) III.2.1 III.2.1
initialize III.2.1
Reading model or Results
readSamcefDat III.2.1.1
readDesFac III.2.1.4
readDesFac2H III.2.1.4
desFacResetFlags (s) III.2.1.4
desFacSetFlag (s) III.2.1.4
desFacUnsetFlag (s) III.2.1.4
desFacGetFlag (s) III.2.1.4
enableSamcefResCodes (s) III.2.1.4
disableSamcefResCodes (s) III.2.1.4
attachDesFac III.2.1.5
detachDesFac III.2.1.5
getNbrAttachments III.2.1.5
getAttachmentNames III.2.1.5
checkAttachmentExists III.2.1.5
removeAllAttachments III.2.1.5
getAttachmentLcInfos III.2.1.5
getAttachmentNbrLoadCases III.2.1.5
getAttachmentLcNames III.2.1.5
getAttachmentLcScNames III.2.1.5
getAttachmentLcScResNames III.2.1.5
getAttachmentNbrLayers III.2.1.5
getAttachmentLayerIds III.2.1.5
getAttachmentLayerNames III.2.1.5
getAttachmentNbrSubLayers III.2.1.5
getAttachmentSubLayerIds III.2.1.5
getAttachmentSubLayerNames III.2.1.5
getAttachmentNbrSubCases III.2.1.5
getAttachmentScNames III.2.1.5
getAttachmentNbrResults III.2.1.5
getAttachmentResIds III.2.1.5
getAttachmentResNames III.2.1.5
getAttachmentResults III.2.1.5
getAttachmentResultsCombili III.2.1.5
setStorageBufferMaxCapacity (s) III.2.1.5
getStorageBufferMaxCapacity (s) III.2.1.5
Coordinate system methods
getCoordSysCopy III.2.1.2
addCoordSys III.2.1.2
makeAllCoordSysWrt0 III.2.1.2
Group manipulation methods
getNodesAssociatedToElements III.2.1.3
getNodesAssociatedToRbes III.2.1.3
getElementsAssociatedToNodes III.2.1.3
getElementsAssociatedToMaterials III.2.1.3
getRbesAssociatedToMaterials III.2.1.3
getElementsAssociatedToPlies III.2.1.3
getElementsAssociatedToLaminatesIII.2.1.3
getElementsAssociatedToAttr1s III.2.1.3
getElementsAssociatedToAttr2s III.2.1.3
Generation of additional Results
generateShellOffsetsResult III.2.1.7
Iterators
each_coordSysId III.2.1.8
each_elemId III.2.1.8
each_nodeId III.2.1.8
each_materialId III.2.1.8
each_samcefPlyId III.2.1.8
each_samcefLaminateId III.2.1.8
each_samcefMatIdName III.2.1.8
each_samcefMatNameId III.2.1.8
each_nodeOfElement III.2.1.8
each_cornerNodeOfElement III.2.1.8
Methods added to “Post” module
readGroupsFromSamcefDat III.2.3
Other methods
getNodeRcId III.2.1.9
getNodeAcId III.2.1.9
getNodeCoords III.2.1.9
Attributes
NbrRbes III.2.1.10

III.2.1 “SamcefDb” class

A “SamcefDb” object can be created by a statement using “new” method like:

    db=SamcefDb.new()

Method “initialize” initializes or clears a SamcefDb object. This class is a specialization of the FeResPost “DataBase” class.

III.2.1.1 Reading Samcef models

Method “readSamcefDat” of the SamcefDb class is used to import the model in a SamcefDb. This function has up to three arguments:

The model can be split into several files loaded in a main file by input statements. However, the user should try to be conservative when splitting its model. For example:

Here is a few examples of valid input statements:

    input "../SPLIT_1/grids.dat"
    input "../SPLIT_1/elements.dat"
    input.beginC "../SPLIT_1/props.dat"
    input.beginB "../SPLIT_1/geom.dat"
    input "/home/ferespost/SAM_SPLIT/SPLIT_1/mecano.dat"

Note that for a reason unknown, the “.sauve banque” bacon command outputs the list of abbreviations defined in a database at the end of the banque after a “return” statement. This “return” statement must be removed or commented out if the abbreviations are to be imported in the database by the “readSamcefDat” command.

Finally, Since version 4.5.7 of FeResPost, we have been trying to better support the Samcef input files produced directly by Siemens NX software. This has been done by working with a limited number of example files, and modifying the C++ sources until correct FeResPost reading is obtained. We do not guaranty that all features exported by NX are supported by FeResPost. This means that the reading of a file obtained via the “.sauve banque” Bacon command remains the safest way to read successfully a Samcef model. So, for NX users, our recommendations are:

And you will help us to improve FeResPost by providing NX files that FeResPost fails to read.

Note also that the use of non-ASCII characters in Samcef file names, or in the names of directories via which inut files are included should be avoided. (See more details regarding this rule in section III.1.1.1 in Nastran solver reference for more details.)

III.2.1.2 “CoordSys” methods

The “CoordSys” class allows the manipulation of coordinate systems for post-processing purpose. This class is presented in Chapter I.2. One presents below the methods of SamcefDb class devoted to the manipulation of coordinate systems.

III.2.1.2.1 “getCoordSysCopy”

The “getCoordSysCopy” method returns a CoordSys object which is a copy of a coordinate system stored in the DataBase. The method has one integer argument which is the index of the coordinate system.

Note that the CoordSys returned by the method may be a “generic” CoordSys as presented in Chapter I.2, or a Samcef frame.

III.2.1.2.2 “addCoordSys”

The “addCoordSys” method is used to add a coordinate system to the DataBase. The argument of the method is the CoordSys object. In the DataBase, the object is referenced by its index.

If a coordinate system with the same index already exists in the SamcefDb, it is replaced by the new coordinate system. In that case, the user is responsible for all the modifications involved in the finite element model by the possible modification of the SamcefDb coordinate system. Therefore, it is considered as a good practice not to modify a coordinate involved in the finite element model definition.

Note that the coordinate system index must be a strictly positive integer. Also, the CoordSys inserted by the method may be a “generic” CoordSys as presented in Chapter I.2, or a Samcef frame.

III.2.1.2.3 “makeAllCoordSysWrt0”

makeAllCoordSysWrt0 method updates the definition wrt 0 (most basic coordinate system) of all the coordinate systems stored in a NastranDB. This operation is necessary when a coordinate system of the NastranDB has been modified, because the definitions of other coordinate systems wrt 0 may be affected.

III.2.1.3 Construction of Groups by association operations

The list of “SamcefDb” methods returning Groups defined by association is given below:

III.2.1.4 Methods related to Results importation

WARNING: due to compiler limitations, the reading of large FAC files (size>2Gb) with FeResPost 32bits library is likely to end up with an exception. If this happens, user should switch to a 64bits version of the library.

III.2.1.4.1 “readDesFac” method

readDesFac” method is used to import Samcef Results. The files that are read are the “des” and the “fac” files. The method may have 2, 3, 4, 5, 6 or 7 arguments:

1.

The first argument is a String containing the name of the “des” file. This argument is mandatory.

2.

The second argument is a String containing the name of the “fac” file. This argument is also mandatory. Of course the two “des” and “fac” files must correspond.

3.

The third argument is optional. It is an Array of integers corresponding to the identifiers of the Load Cases for which Results are to be imported. If the argument is omitted, the Results for all load cases are imported.

4.

The fourth argument is optional and may be present only if the third argument is defined. It corresponds to the names that will be attributed to the load case attribute of Results imported. These names are provided in an Array of Strings. If this argument is not used, the default load case names will be attributed to the Results created in the SamcefDb.

For example, without the fourth argument, the importation of asef Results with several load cases leads to LoadCase attributes named “LoadCase 1”, “LoadCase 2”,... This may be unpractical for many problems.

5.

The fifth argument is optional and corresponds to the names of the sub-cases for which values shall be imported. These names are provided in a String or an Array of Strings. If the Array is void or the parameter is omitted, all the sub-cases are read.

6.

The sixth argument is optional and corresponds to the names of the Results for which values shall be imported. These names are provided in a String or an Array of Strings. Possible values are "Stress Tensor", "Strain Tensor",... If the Array is void, all Result types are considered. If the Array is void or the parameter is omitted, all the Results are read.

7.

The seventh argument is an Array of integers corresponding to the Samcef Result Codes to be considered when Results are imported.

Note that when the third and fourth arguments are used, the number of elements of the two Arrays must be the same. For more information about arguments 4, 5 and 6, see the description of “readOp2” method in “NastranDb” class.

Note that the reading of “fac” files also checks the endianness of the file and, if needed, does corrections to the binary data.

At the end of reading the method “readDesFac” prints a list of the Samcef Result Codes that have been skipped.

Presently, the method allows the reading of Results for the following Samcef modules:

III.2.1.4.2 “readDesFac2H” method

readDesFac2H” method is used to read Samcef Results from “des” and the “fac” files. The method does not read the Results into the dataBase, but returns them into a Hash. For example:

    ...
    h=db.readDesFac("~/FERESPOST/TEST_SAMCEF/mySatellite_as.des",\
                      "~/FERESPOST/TEST_SAMCEF/mySatellite_as.fac",\
                      [1],["accel_XYZ"])
    ...

III.2.1.4.3 Flags for reading of Results

Flags influencing the behavior of “readDesFac” method can be defined. The following singleton methods have been defined to manipulate the flags:

1.

desFacResetFlags” resets all the flags to false (default values). This method has no arguments.

2.

desFacSetFlag” sets one flag to true. This method has one String argument. An example of use of this method follows:

          ...
          DataBase.desFacSetFlag("ANGULAR_STRAIN_BUG")
          db.readDesFac("~/FERESPOST/TEST_SAMCEF/mySatellite_as.des",\
                            "~/FERESPOST/TEST_SAMCEF/mySatellite_as.fac",\
                            [1],["accel_XYZ"])
          ...

3.

desFacUnsetFlag” sets one flag to false. This method has one String argument.

4.

desFacGetFlag” returns a Logical value corresponding to the value of the flag. This method has one String argument.

When one of these methods has one String argument, this argument is the name of the considered flag. Among the above methods, only the last one returns a value.

Two such flags have been defined:

Similarly, two singleton methods allow to enable or disable Samcef Result codes:

The argument of these two methods are an integer or an Array of integer corresponding to Samcef Result Codes.

Four methods devoted to the enabling or disabling of composite layered Results are defined in the generic “DataBase” class. These methods are presented in section I.1.3.2.

III.2.1.5 Attaching “DES/FAC” files to a Samcef DataBase

Since version 3.5.0, FeResPost allows a random access to DES/FAC result files. This method is more efficient than the methods that import Results into the DataBase, and extracting copies of these Results. A peculiar case in which the random access methods will be more efficient is when only some small parts of the Result file are of interest to the programmer.

The principle of random access is as follows:

The different methods called to perform these operations are described in the following sub-sections.

Note that the content of DES file is read only when the DES/FAC files are attached to the DataBase. After that, the DES file is closed. This is why when information is extracted from a peculiar attachment, the attachment is identified by the name of the FAC file.

III.2.1.5.1 Managing DES/FAC file attachments

The method “attachDesFac” is used to attach a DES/FAC file to the Samcef DataBase. This method has between two and four arguments:

1.

A String containing the name of the DES file. (Full path name must be provided.)

2.

A String containing the name of the FAC file. (Full path name must be provided.)

3.

An integer or an Array of integers identifying load cases.

4.

A String or an Array of Strings corresponding to the names that are attributed to the load cases and which shall be used to retrieve corresponding Results.

The arguments 3 and 4 are optional. They correspond to arguments 3 and 4 of the “readDesFac” method discussed in section III.2.1.4.

Several other methods are used to manage the DES/FAC attachments to a DataBase:

III.2.1.5.2 Extracting information from DES/FAC attachments

The following methods extract information related to the Results stored in DES/FAC files attached to the DataBase:

All these methods have a single String argument containing the name of the FAC file that must have been previously attached to the DataBase. On the other hand, the following methods have one or two arguments:

The first argument is the name of the FAC file that must have been previously attached to the DataBase. The second argument is optional and corresponds to the name of a load case found in the attached FAC file. If the argument is not provided, all the load cases are investigated to build the list of sub-cases or Result names or IDs. If the argument is provided, only the sub-cases or Results of the corresponding load case are considered. If the provided load case does not exist in FAC attachment an error message is issued.

III.2.1.5.3 Extracting Results from attachments

The method “getAttachmentResults” is used to read Results from the FAC file. The Results are directly returned by the method to the caller. They are not inserted in the DataBase from which the method is called.

The method has minimum four arguments:

1.

A String corresponding to the name of FAC file attachment from which Results are read. (This file must have been previously attached to the DataBase.)

2.

A String corresponding to the name of the load case for which Results are read.

3.

A String or an Array of Strings corresponding to the names of sub-cases for which Results are read.

4.

A String or an Array of Strings corresponding to the names of Results for which Results are read.

The other arguments are optional and correspond to the specification of target entities for which Results are read. Actually, the reading operation from a FAC file combines the reading and some of the extraction operations described in section I.4.3. For example:

One can extract Results without specifying the ResKeyList, Result or Group argument. However, it is still possible to specify a list of layers, a list of sub-layers, and a location to filter the values that are inserted in Results. The “Location” argument corresponds to the “Method” argument when Results are extracted on Groups. Possible values of this parameter are “Elements”, “ElemCenters", “ElemCorners”...

Only lists below the list of valid calls to “getAttachmentResults”:

        h=db.getAttachmentResults(facName,lcName,scNames,resNames,
                method,grpTarget[,layers[,subLayers]])
        h=db.getAttachmentResults(facName,lcName,scNames,resNames,
                resTarget)
        h=db.getAttachmentResults(facName,lcName,scNames,resNames,
                rklTarget)
        h=db.getAttachmentResults(facName,lcName,scNames,resNames
                [,layers[,sub-Layers[,location]]])

As several Result types, and sub-case names can be given as argument to “getAttachmentResults” method, this method can return several Results. This is why Results are returned in a Hash:

For example, the list of extracted Result sizes can be printed with the following statements:

    h=db.getAttachmentResults(facName,lcName,scNames,resNames,"Nodes",grp)
    h.each do |id,res|
        lcName=id[0]
        scName=id[1]
        resName=id[2]
        size=res.Size
        STDOUT.printf("%s - %s - %s : %d\n",lcName,scName,resName,size)
        #~ Util::printRes(STDOUT,"brol",res)
    end

The method “getAttachmentResultsCombili” is used to extract linear combinations of elementary Results found in one or several attached FAC files. As for method “getAttachmentResults” the Results are directly returned by the method to the caller. They are not inserted in the DataBase from which the method is called. This method is more or less a combination of the methods “getAttachmentResults” and “buildLoadCasesCombili” of the generic DataBase class.

Practically, the main difference between “getAttachmentResults” and “getAttachmentResultsCombili” is that the first argument is no longer a FAC file name. This argument is removed. Instead, one provides a “Combili” argument that describes the linear combination corresponding to extracted Results. This “Combili” argument is the second argument. The first argument is the “LcName” argument corresponding to the load case name attributed to the generated Results. This load case name is not supposed to correspond to any load case name found in the attached FAC file(s).

The method has minimum four arguments:

1.

A String corresponding to the name of the load case for which Results are read.

2.

A “Combili” Array containing the description of the linear combination of elementary load case Results. The Array is an Array of Arrays. Each secondary Array contains three elements:

  • A Real value corresponding to the factor in the linear combination.

  • A String corresponding to the name of the FAC file from which elementary Results are read. This file must have been previously attached to the Samcef DataBase.

  • A String corresponding to the name of the load case for which Results are extracted.

3.

A String or an Array of Strings corresponding to the names of sub-cases for which Results are read.

4.

A String or an Array of Strings corresponding to the names of Results for which Results are read.

The other arguments are optional and correspond to the specification of target entities for which Results are read. Actually, the reading operation from a FAC file combines the reading and some of the extraction operations described in section I.4.3. For example:

One can extract Results without specifying the ResKeyList, Result or Group argument. However, it is still possible to specify a list of layers, a list of sub-layers, and a location to filter the values that are inserted in Results. The “Location” argument corresponds to the “Method” argument when Results are extracted on Groups. Possible values of this parameter are “Elements”, “ElemCenters", “ElemCorners”...

Only lists below the list of valid calls to “getAttachmentResultsCombili”:

        h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames,
                method,grpTarget,layers)
        h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames,
                method,grpTarget)
        h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames,
                resTarget)
        h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames,
                rklTarget)
        h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames,
                layers)
        h=db.getAttachmentResultsCombili(lcName,combili,scNames,resNames)

The Hash object returned by the method has a structure identical to the one returned by “getAttachmentResults” and can be manipulated the same way.

III.2.1.5.4 Storage buffers for result files random access

In order to reduce the number of accesses to disk, it may be useful to store some of the blocks read from binary result files into memory. FeResPost provides an algorithm that allows to store the blocks most recently read for later usage. Two singleton methods of the “SamcefDb” class allow the to tune the capacity of the buffer area:

Note that all buffers are now common to all the methods that provide random access to XDB and FAC result files. In particular, the method is used in management of the binary file access for XDB and FAC attachment or reading. This means that if one Result file attached to one DataBase is more used, the storage will contain a majority of buffers for this Result file and progressively delete the other buffers.

The default capacity for storage buffer is 0Mb. Note that the two methods described above can be called from any class derived from the generic “DataBase” class.

III.2.1.6 GMSH outputs

The method “writeGmshMesh” defined in DataBase Class exports nodes and elements into the mesh file. The three tags attributed to the elements are the first and second element attributes and the laminate ID.

III.2.1.7 Production of additional Results

The method “generateShellOffsetsResult” defined in SamcefDb Class generates a Result corresponding to shell offsets for 2D elements. The method has no argument or three arguments. The arguments correspond to the key to which the Result object is associated in the SamcefDb object. (load case name, subcase name, and result name respectively.) If the String arguments are omitted, one assumes “”, “” and “Coordinates” for the Result key.

III.2.1.8 Iterators

A first group of iterators iterate on finite element entities of the finite element model stored in the DataBase.

The elements produced by the iterator are single integers. Each of these iterators has 0, 1 or 2 arguments. The two optional arguments are the integer bounds considered for the iteration: “IdMin” and “IdMax”.

Two methods allow the iteration on the elements of associative containers used to record the correspondence between integer and String identifiers of the samcef Groups stored in the DataBase:

Two iterators loop on the nodes defining an element:

These two iterators have one integer argument corresponding to the index of the element. The return the integer indices of nodes.

III.2.1.9 Other methods

Several other methods allow to obtain model information.

III.2.1.10 Attributes

One attribute “getter” allows to access information in the model:

III.2.2 Samcef Results characteristics

One makes here the distinction between general Results and composite Results.

III.2.2.1 General Results

General Results (by opposition to Composite Results) are presented in Tables III.2.2 to III.2.4. (One makes the distinction between Scalar, Vectorial and Tensorial Results.) About the Results described, one can make the following comments:

1.

The shear components of strain tensor output by Samcef should be (and generally are) components of a tensor (ϵij = γij2). The same convention is used for all the tensors manipulated in FeResPost. So, no manipulation of the shear components is made when importing strain tensors from Samcef Results.

Note however that because of a bug in Samcef, strain results given at center of elements may be wrong and use the “angular deformation” convention. So the use should be careful when manipulating strain tensor Results imported from Samcef.

A flag influencing the importation of Results with “readDesFac” method allows the modification of shear components of 2D elements strain tensor: the ‘ANGULAR_STRAIN_BUG” flag. When set to “true”, the shear components of Strain tensor are divided by two. This division by two is done for the result codes 3421, 3445 and 3446. It is the responsibility of the user to check whether the setting of the flag is necessary or not.

See more information about the methods used to manipulate the flags in section III.2.1.4.

2.

The ”Mechanical Strain Tensor” Result corresponds to the Strain Tensor estimated from Stress Tensor without considering thermo-elastic or hygro-elastic effects into account.

3.

All result codes corresponding to Von Mises stress are skipped. However, Von Mises stress can always be generated by derivation from stress tensor Results.

4.

The Result “Shell Forces” contains the contributions of several Samcef Result codes: the shell element normal forces (code x437) and the shell element shear forces (code x251).

5.

Samcef “beam” type elements do not output vectorial or tensorial forces or moments. Instead, the different components are expressed in different coordinate systems. When importing these Results, a conversion into tensorial format is done as follows:

F = ( FxxFxyFxz Fxy 0 0 Fxz 0 0 ) = ( N T1T2 T1 0 0 T2 0 0 ) ,

M = ( MxxMxyMxz Mxy 0 0 Mxz 0 0 ) = ( M - F2F1 - F2 0 0 F1 0 0 ) .

(One uses here the notation of the Samcef manual for the components stored in “fac” file: N corresponds to the axial component of force, T to the shear forces, M to the torsion moment and F to the bending moment.)

Beam forces and moments are also saved in “fac” file for bushing elements. Then, the longitudinal axis may be z if axisymmetric properties are attributed to the element. Then, the components are inserted in 2D tensors as follows:

F = ( 0 0 Fxz 0 0 Fyz FxzFyzFzz ) = ( 0 0 F1 0 0 F2 F1F2F3 ) ,

M = ( 0 0 Mxz 0 0 Myz MxzMyzMzz ) = ( 0 0 M1 0 0 M2 M1M2M3 ) .


Table III.2.2: Correspondence between Samcef Result Codes and Scalar Results generated in FeResPost.
Samcef Result Code Generated Result
334 “Element Strain Energy (Density)”
335 “Element Kinetic Energy (Density)”
3234 “Element Strain Energy (Percent of Total)”
3235 “Element Kinetic Energy (Percent of Total)”
1305 “Contact, Contact Pressure”
1306 “Contact, Friction Stress”
1307 “Contact, Normal Distance”
2051 “Contact, Nodal Distance”
1440, 3440 “Beam Axial Stress for Total Loads”
1450, 3450 “Beam Shear Stress for Total Loads”


Table III.2.3: Correspondence between Samcef Result Codes and Vectorial Results generated in FeResPost.
Samcef Result Code Generated Result
153 “Coordinates”
163 “Displacements, Translational”
191 “Displacements, Rotational”
221 “Reaction Forces, Forces”, “Reaction Forces, Moments”
1439, 3439, 1524, 3524 “Beam Forces” (5)
1439, 3439, 1525, 3525 “Beam Moments” (5)
1532 “Grid Point Forces, Reaction Forces”
1533 “Grid Point Forces, Reaction Moments”
1534 “Grid Point Forces, Internal Forces”
1535 “Grid Point Forces, Internal Moments”


Table III.2.4: Correspondence between Samcef Result Codes and Tensorial Results generated in FeResPost. (Stars “*” can be replaced by 1, 2 or nothing and are related to the sub-layer IDs.)
Samcef Result Code Generated Result
*1411, *1413, 1431, 1435, 1436, *3411, *3413, 3431, 3435, 3436, “Stress Tensor”
*1421, 1445, 1446, *3421, 3445, 3446 “Strain Tensor” (1)
*1423, *3423 “Mechanical Strain Tensor” (2)
1251, 1437, 3251, 3437 “Shell Forces” (4)
1438, 3438 “Shell Moments”


Table III.2.5: Correspondence between Samcef Result Codes for Mecano Thermal Results.
Samcef Result Code Generated Result
120 “Temperature”
121 “Temperature Variation Rate”
1379, 3379 “Specific Heat Energy”
1511, 3511 “Conductive Heat Flux”
1801, 3801 “Applied Heat Flux”

III.2.2.2 Composite Results

One presents below a few comments above the composite Results presented in Tables III.2.6 to III.2.8:

1.

Composite Results have non-linear dependence on the primary unknowns (displacements and rotations). Therefore, composite Results obtained by linear combination of elementary Results are false.

2.

With Samcef, it is also possible to output ply Results in the upper and lower layers of each ply (codes 1xxxx and 2xxxx). FeResPost reads results at mid layer of each ply only. The other Results are skipped. (Note that most composite calculation methods usually use the forces in plies recovered at mid-thickness.)

3.

Even though the maximum stress and strain failure indices are presented in Samcef and FeResPost as tensorial Results, the six components for each location are not the components of a tensor. Therefore, the user must be very careful when using those Results. In particular transformations of coordinate systems for those Results are meaningless.

4.

Composite critical ply failure indices give for each element the maximum failure index in one of the plies. Also, the evaluation is done at the Gauss points of each ply and each elements and the maximum is collected.

Four methods devoted to the enabling or disabling of composite layered Results are defined in the generic “DataBase” class. These methods are presented in section I.1.3.2.


Table III.2.6: Correspondence between Samcef Result Codes for Scalar failure indices generated in FeResPost (4). (Stars “*” can be replaced by 1, 2 or nothing and are related to the sub-layer IDs.)
Samcef Result Code Generated Result
*1621, *3621 “Composite Failure Index, Tsai-Hill Version 1”
*1622, *3622 “Composite Failure Index, Tsai-Hill Version 2”
*1623, *3623 “Composite Failure Index, Tsai-Hill Version 3”
*1624, *3624 “Composite Failure Index, Tsai-Wu”
*1625, *3625 “Composite Failure Index, Hashin Version 1”
*1626, *3626 “Composite Failure Index, Hashin Version 2”
*1627, *3627 “Composite Failure Index, Hashin Version 3”
*1630, *3630 “Composite Failure Index, Stress Ratio”
*1631, *3631 “Composite Failure Index, Strain Ratio”
*1632, *3632 “Composite Failure Index, Rice and Tracey”
*7621 “Composite Critical Ply Failure Index, Tsai-Hill Version 1”
*7622 “Composite Critical Ply Failure Index, Tsai-Hill Version 2”
*7623 “Composite Critical Ply Failure Index, Tsai-Hill Version 3”
*7624 “Composite Critical Ply Failure Index, Tsai-Wu”
*7625 “Composite Critical Ply Failure Index, Hashin Version 1”
*7626 “Composite Critical Ply Failure Index, Hashin Version 2”
*7627 “Composite Critical Ply Failure Index, Hashin Version 3”
*7628 “Composite Critical Ply Failure Index, Maximum Strain, CompMax”
*7629 “Composite Critical Ply Failure Index, Maximum Stress, CompMax”
*7630 “Composite Critical Ply Failure Index, Stress Ratio”
*7631 “Composite Critical Ply Failure Index, Strain Ratio”
*7632 “Composite Critical Ply Failure Index, Rice and Tracey”


Table III.2.7: Correspondence between Samcef Result Codes for Scalar critical plies generated in FeResPost (4).
Samcef Result Code Generated Result
8621 “Composite Critical Ply, Tsai-Hill Version 1”
8622 “Composite Critical Ply, Tsai-Hill Version 2”
8623 “Composite Critical Ply, Tsai-Hill Version 3”
8624 “Composite Critical Ply, Tsai-Wu”
8625 “Composite Critical Ply, Hashin Version 1”
8626 “Composite Critical Ply, Hashin Version 2”
8627 “Composite Critical Ply, Hashin Version 3”
8628 “Composite Critical Ply, Maximum Strain, CompMax”
8629 “Composite Critical Ply, Maximum Stress, CompMax”
8630 “Composite Critical Ply, Stress Ratio”
8631 “Composite Critical Ply, Strain Ratio”
8632 “Composite Critical Ply, Rice and Tracey”


Table III.2.8: Correspondence between Samcef Result Codes for Tensorial failure indices generated in FeResPost (3).
Samcef Result Code Generated Result
1628, 3628 “Composite Failure Index, Maximum Strain”
1629, 3629 “Composite Failure Index, Maximum Stress”

The correspondence between the failure indices read from Samcef result files and Results produced by CLA classes is as in Table III.2.9. Sometimes a single Samcef Result corresponds to two different CLA failure criteria. Then, the type of element (2D or 3D) allows the identification of the appropriate CLA criterion.


Table III.2.9: Correspondence between the Samcef failure indices imported from “des/fac” files and the failure criteria defined in CLA module.
Samcef Result CLA criterion ID section
“Composite Failure Index, Tsai-Hill Version 1” (2D elements) “TsaiHill_b” II.1.10.10
“Composite Failure Index, Tsai-Hill Version 1” (3D elements) “TsaiHill3D_b” II.1.10.13
“Composite Failure Index, Tsai-Hill Version 2” (2D elements) “TsaiHill” II.1.10.9
“Composite Failure Index, Tsai-Hill Version 2” (3D elements) “TsaiHill3D” II.1.10.12
“Composite Failure Index, Tsai-Hill Version 3” “TsaiHill” II.1.10.9
“Composite Failure Index, Tsai-Wu” “TsaiWu3D” II.1.10.15
“Composite Failure Index, Hashin Version 1” “Hashin3D” II.1.10.21
“Composite Failure Index, Hashin Version 2” “Hashin3D_b” II.1.10.21
“Composite Failure Index, Hashin Version 3” “Hashin3D_c” II.1.10.21
“Composite Failure Index, Hoffman” “Hoffman” II.1.10.16
“Composite Failure Index, Maximum Strain, CompMax” “MaxStrain3D” II.1.10.7
“Composite Failure Index, Maximum Stress, CompMax” “MaxStress3D” II.1.10.5
“Composite Failure Index, Interlaminar Shear Stress” “Ilss” II.1.10.27

Important remarks must be done about the coordinate system associated to each value in the Result objects:

III.2.3 Methods defined in “Post” module

The method “readGroupsFromSamcefDat” reads Groups from a Samcef Bacon data file and returns a Hash containing the list of Groups. (This method is similar to “readGroupsFromPatranSession” also defined in “Post” module.) The keys are Group names, and the values are the Groups. The method has two arguments:

1.

A String corresponding to the name of the session file.

2.

A DataBase. This argument is optional. If it is provided, the reading method removes from the created Groups all the entities undefined in the DataBase argument.

The definition of Groups must be done according to the “.SEL” command of the Bacon files. Only the lines in the “.SEL” commands are considered. More model definition command may be present in the file but they are ignored. Examples of use of the method follow:

      ...
      h=Post::readGroupsFromSamcefDat("groups.dat")
      ...
      h=Post::readGroupsFromSamcefDat("groups.dat",DB)
      ...

Part IV
FeResPost Examples with RUBY Extension

Chapter IV.0
Introduction

This Part of the document is devoted to the presentation of examples illustrating various aspects of FeResPost All the FeResPost example are done with a model and Nastran results corresponding to a very simplified and imaginary satellite represented in Figure IV.1.1. This Part is organized as follows:

All the examples are delivered in “TESTSAT” directory. This directory contains four subdirectories:

1.

“MODEL” contains the definition “testSat” finite element model. The splitting of this model into several files and its organization in sub-directories is described in section IV.1.6.

2.

“OTHER_EXECS” contains Nastran example BDF files not related to the “testSat” small satellite finite element model. In general, these examples illustrate technicalities of Nastran and FeResPost.

3.

“RUBY” contains the small examples described in Chapter IV.2. The sub-directories in “RUBY” are:

  • The different “EX??” directories containing the small examples.

  • “PROJECT” is the main directory of the modular program described in chapter IV.4. Each

  • “PROJECTa” is the main directory of the modular program described in Appendix X.D.2. Each

  • “PROJECTb” is the main directory of the object oriented program described in Appendix X.E.4.

4.

Finally, a “EXEC_OP2” directory has been defined in “MODEL” directory. The main bulk data files have been copied in this directory and the calculations with Nastran must be performed in that directory.

5.

Similarly a “EXEC_XDB” directory has been defined in “MODEL” directory. There, the main bulk data files have been modified to produce “xdb” result outputs.

Of course, before running the examples, you must compile ruby or its shared library, and produce the Nastran finite elements results.

IV.0.1 Accessing the ruby extension

Typically, one imports the FeResPost Classes and Modules with the two following statements:

     require "FeResPost"
     include FeResPost

Note however that it works only if the different environment variables have been initialized correctly. Typically, in our Windows examples, this is done through the batch files (on Windows computers) or bash files (on UNIX and LINUX computers) that are used to launch the example scripts, and the following variables are generally initialized:

    set LIB=
    set INCLUDE=
    set RUBYPATH=C:/NEWPROGS/RUBY/ruby-3.0.0-1-x64/bin
    set REDISTRPATH=C:/Users/ferespost/Documents/SRC/OUTPUTS/REDISTR
    set RUBYLIB=C:/Users/ferespost/Documents/SRC/OUTPUTS/RUBY/RUBY_30
    set PATH=%RUBYPATH%;%REDISTRPATH%;C:/Windows/System32

On Windows machines, the examples are defined in such a way that the environment is defined in file “RUBY/ENV/env.bat” included in the script used to launch ruby program. In the example above, not that the “PATH” environment variable refers to tree directories:

For example, the example “EX03/makeGravForces.rb” is launched in “RUBY/EX06” directory with command:

    makeGravForces.bat

in which “exec” refers to the “exec.bat” file with following content:

    setlocal
    call "../ENV/env.bat"
    ruby -I. makeGravForces.rb
    endlocal

Of course the different paths you will initialize in “ENV/env.bat” will have to be adapted to you peculiar installation, and to the version of Ruby you are using.

On unix, the BASH file looks as follows:

    #!/bin/bash
    source ../ENV/env.bash
    ruby --version
    ruby -I. -I$RUBYLIB makeGravForces.rb

in which“../ENV/env.bash” content looks like:

    RUBYLIB=/home/progs/Documents/FERESPOST/SRC/OUTPUTS/RUBY/RUBY_25
    PATH=/home/PGR/RUBY/I64//RUBY_251/bin

Chapter IV.1
A small satellite

In this Chapter, one describes the finite element model used in all the examples. The Chapter is organized as follows:

IV.1.1 Presentation of the structure and its modeling

An overall view of the satellite’s FE model is presented in Figure IV.1.1. Basically, the structure is composed of an hexahedral lower box and of an upper panel supported by six struts. The hexahedral lower box is made of six sandwich panels connected on 12 metallic bars along their edges. The metallic bars are connected to eight corner nodes. A view of the lower box metallic frame, without the sandwich panels is given in Figure IV.1.2. The corner nodes, and the connections of sandwich panels are modeled with RBE2 elements. However, for thermo-elastic calculations these RBE2 elements are replaced by very stiff CBAR elements.


PICT

Figure IV.1.1: Overall view of the satellite’s finite element model.


PICT

Figure IV.1.2: Metallic frame of the satellite lower box.

The sandwich panels are generally modeled with volumic elements for the honeycomb and surfacic elements for the skins (Figure IV.1.3). A surfacic modeling of a sandwich panel with layered (PCOMPG) element properties has been chosen for only one of the panels: the bottom panel.

To ensure a good transfer of loads to the panels, in particular of the bending moments at connections, small traversing elements have been introduced in the panels modeled with 3D elements. Those elements represent the inserts and connect the two skins. A global view of all the traversing elements is given in Figure IV.1.4.


PICT

Figure IV.1.3: Volumic modeling of sandwich panels.


PICT

Figure IV.1.4: Traversing elements for inserts’ modeling.

The struts are modeled with CBAR elements. The struts are connected to the upper panel and to the box +Z panel through metallic fittings modeled with CONM2 and RBE2 elements. (The RBE2 elements are replaced by very stiff CBAR elements for thermo-elastic calculations). The connections of struts to the fittings are ball-bearing connections (only translational degrees of freedom are transmitted, except on the lower side, where the rotation of each strut around its axis is blocked).

The equipments connected to the sandwich panels are modeled with CONM2 and RBE2 elements. (The RBE2 elements are replaced by very stiff CBAR elements for thermo-elastic calculations). A view of some equipments is presented in Figure IV.1.5. On some panels small equipments are modeled by adding a NSM (non-structural mass) to PSHELL properties.


PICT

Figure IV.1.5: Open view of the satellite with modeling of equipments.

IV.1.2 Satellite FEM materials and properties

In the satellite FE model, only seven material cards are defined. The most relevant parameters of material cards are given in Tables IV.1.1, IV.1.2 and IV.1.3.


Table IV.1.1: Isotropic materials used in the finite element model (MAT1 property cards).
Material name MIDE (GPa)να (K-1)ρ (kg/m3)
Al-7075-T7351 2 72.1 0.33 23.6 10-6 2796.0
Al-7010-T7451 1 71.7 0.33 23.6 10-6 2820.0
Al-2024-T3 clad 3 69.0 0.33 23.6 10-6 2768.0
(thermo-elastic) 5001 72.1 0.33 23.6 10-6 0.0


Table IV.1.2: 3D anisotropic materials used in the finite element model (MAT9 property cards).
Material type Honeycomb 50 Honeycomb 72
MID 5 6
G 11 (MPa) 0.670 0.760
G 22 (MPa) 0.670 0.760
G 33 (MPa) 669.0 1276.0
G 44 (MPa) 0.207 0.310
G 55 (MPa) 138.0 193.0
G 66 (MPa) 310.0 483.0
ρ (kg/m 3 ) 50 72
α (K -1 )23.6 10-623.6 10-6


Table IV.1.3: 2D anisotropic materials used in the finite element model (MAT8 property card).
Material type Honeycomb 50 2D CFRP 2D
MID 4 10000
E 1 (MPa) 0.500 290000
E 2 (MPa) 0.500 5600
ν 12 0.3 0.33
G 12 (MPa) 0.500 3000
G 1Z (MPa) 310.0 1100
G 2Z (MPa) 138.0 1100
ρ (kg/m3) 50 1670
α1 (K -1 )23.6 10-6- 1 10-6
α2 (K -1 )23.6 10-631 10-6
S 1t (MPa) 0.050 1600
S 1c (MPa) 0.050 500
S 2t (MPa) 0.050 25
S 2c (MPa) 0.050 140
S s (MPa) 0.050 55

All CBAR elements receive PBARL properties:

All skins, except those of bottom panel, are made of Aluminum 2024 T3 and have a thickness of 0.5 mm. The honeycomb used in sandwich panels has a density of 50 kg/m3. Only in the +Z panel of the box a 72 kg/m3 honeycomb has been used. The bottom panel is modeled with surface elements, and has correspondingly a PCOMPG property card (PID=6). Each skin of the bottom sandwich panel is made of CFRP laminated material with plies 0.1 mm thick. The properties are defined as follows:

PCOMPG    6                  50.779    30.+6    HILL    20.        0.
            2008     10000  1.-4      0.        YES
            2007     10000  1.-4      45.      YES
            2006     10000  1.-4     -45.      YES
            2005     10000  1.-4      90.      YES
            2004     10000  1.-4      90.      YES
            2003     10000  1.-4     -45.      YES
            2002     10000  1.-4      45.      YES
            2001     10000  1.-4      0.        YES
            100      4        .0284     0.        YES
            3001     10000  1.-4      0.        YES
            3002     10000  1.-4      45.      YES
            3003     10000  1.-4     -45.      YES
            3004     10000  1.-4      90.      YES
            3005     10000  1.-4      90.      YES
            3006     10000  1.-4     -45.      YES
            3007     10000  1.-4      45.      YES
            3008     10000  1.-4      0.        YES

For sandwich panels modeled with solid elements, the honeycomb is oriented in such a way that the direction Z is perpendicular to the panel. Direction X is vertical for vertical panels and oriented towards +X of coordinate system 1001 for horizontal panels.

IV.1.3 Conventions for numbering and groups

In order to ease the writing of post-processing scripts and the management of FE model, one defines numbering ranges for various parts of the model. The main numbering ranges are given in Table IV.1.4 with the associated groups, when a corresponding group exists. These groups are defined in the Patran session file “groups.ses”.


Table IV.1.4: Numbering ranges and corresponding group names.
Part group name numbering range
panel -X “pan_MX” 20000:24999
panel -Y “pan_MY” 40000:44999
panel -Z “pan_MZ” 60000:64999
panel +X “pan_PX” 30000:34999
panel +Y “pan_PY” 50000:54999
panel +Z “pan_PZ” 70000:74999
upper panel “pan_SUP” 90000:94999
metallic frame 80000:84999
struts “struts_ALL” 85000:89999

Other groups are defined in the session file:

IV.1.4 Loads and Boundary conditions

One give here information on the various loads and boundary conditions used in the examples presented in Chapter IV.2.

IV.1.4.1 Loads

One makes the distinction between load cases corresponding to quasi-static accelerations or forces applied on the structure and thermo-elastic loads cases.

First, three load cases corresponding to quasi-static accelerations applied to the entire satellite structure are defined in file “unit_accel.bdf”. These accelerations are defined by Nastran “GRAV” cards and are oriented in directions X, Y and Z. Their Load identifiers are 601001, 601002 and 601003 respectively.

Then loads corresponding to quasi-static acceleration on parts of the structure are created by defining the appropriate force fields. The method used to defined those force fields is explained in the example presented in section IV.2.5.1. Six files contain these force fields:

One also defines temperature fields for thermo-elastic load cases calculations:

The method used to defined these temperature fields is explained in the example presented in section IV.2.5.2.

IV.1.4.2 Boundary conditions

Only two different fixations of the satellite are used in the examples of Chapter IV.2:

IV.1.5 Main data files

In the definition of main data files, one tried to avoid the definition of too many load cases one the structure. Therefore, one defines elementary load cases on the structure. The Results of these load cases can be recombined at post-processing level to produce the recombined Results.

The elementary load cases are defined in the following sections. One also summarizes the additional calculations that have been performed with Nastran to allow the testing of Result importation for other Nastran Solution Sequences.

IV.1.5.1 Acceleration unit loads on entire structure

One defines two data files corresponding to unit accelerations applied to the entire structure. These data files correspond to the static and thermo-elastic versions of the model respectively. On the static model, the corresponding load case names are:

These load cases are defined in file “unit_xyz.bdf”. Correspondingly, one defines unit load cases on the thermo-elastic version of the model in file “orbit_unit_xyz.bdf”:

IV.1.5.2 Acceleration unit loads on parts of the structure

Two data files corresponding to the local unit acceleration fields defined in section IV.1.4.1. These files are named “unit_xyz_pan_pz.bdf” and “unit_xyz_upper.bdf” respectively. They define the following load cases:

IV.1.5.3 Thermo-elastic load cases

One defines also two data files corresponding to the definition of thermo-elastic load cases on the structure. The file “temp_disc.bdf” defines four load cases in which discontinuous temperature fields are applied to the structure. The four load cases are defined as follows:

The file “temp_grad.bdf” defines three load cases corresponding to gradients of 100 C/m applied on the entire satellite:

IV.1.5.4 Other solution sequences

Several main Bulk Data Files defined in “MAINS” directory are provided to allow the testing of result importations for different Nastran solution sequences:

IV.1.6 Organization of FEM in files and directories

One gives here information on the way the model has been split into several files and the organization of the files into different directories.

The files are located in six different directories:

Note also that each file include in a “.bdf” main data file can itself include other files.

The directory “PATRAN” contains a Patran session file that can be used to import the definition of groups in a Patran or FeResPost DataBase.

Chapter IV.2
A few small examples

In this Chapter, one presents very small examples of data files performing simple operations with the FE model and Results. This allows to familiarize the reader to the use of FeResPost, and possibly to ruby also.

The examples are divided four categories:

IV.2.1 Utilities Module

In file“"RUBY/UTIL/util.rb”, one defines the “Util” Module that contains several useful methods:

IV.2.2 Examples without Results

One presents here several examples illustrating the manipulation of Groups in FeResPost. They show how the Groups defined in the DataBase can be inspected, and how new Groups can be constructed and added to the DataBase.

IV.2.2.1 Reading Bulk Data

The first example illustrates different versions of the call to “readBdf” method:

    require "FeResPost"
    include FeResPost

# Creates  and initializes the DataBase :

    db=NastranDb.new()
    db.Name="tmpDB1"
    db.readBdf("../../MODEL/MAINS/unit_xyz.bdf")

The first call to “readBdf” is the default instruction used to read the Bulk file in most examples.

A second bdf read operation is performed as follows:

    db=NastranDb.new()
    db.Name="tmpDB2"
    begin
        db.readBdf("unit_xyz_V1.bdf",[],"bdf",{},true)
    rescue Exception => x then
        printf ("\n\nMaybe you should modify the two first include statements in main file!\n")
        printf ("**********************************************************************\n\n")
        raise x
    end

The revised version reads main file “unit_xyz_V1.bdf” that illustrates several possible interpretation of the “include” statements in Nastran Bulk Data Files. The user must uncomment the corresponding statement, and modify the absolute paths in the include statements of “unit_xyz_V1.bdf” file. (The “begin” and “rescue” statements have been added to remind the user of this necessary modification. An error message is issued if the reading fails.)

Include statement in the data file look as follows:

include ’/home/ferespost/Documents/FERESPOST/TESTSAT/
    MODEL/MESH/coordSys.bdf’
include /home/ferespost/Documents/FERESPOST/    ,
          TESTSAT/MODEL/MATS/mats.bdf
include ’../../MODEL/PROPS/props.bdf’
$
include ../../MODEL/MESH/elemNodes_pan_MX.bdf
    include ../../MODEL/MESH/elemNodes_pan_MY.bdf
include     ../../MODEL/MESH/elemNodes_pan_MZ.bdf
include ../../    MODEL/MES    H/elemNod    es_pan_PX.bdf
include ../../MODEL/MESH/    elemNodes_pan_PY.bdf

The example is given in file “RUBY/EX01/readBdf.rb”.

Another version of the example is given in file “RUBY/EX01/readBdf_V2.rb”. It illustrates the reading of Bulk Data Files containing include statements in which symbols are used. In that example, the call to “readBdf” looks as follows:

    symbols=Hash.new
    symbols["INCDIR"]="../../MODEL"

    db=NastranDb.new()
    db.Name="tmpDB2"
    db.readBdf("unit_xyz_V2.bdf",[],"bdf",symbols,true)

The variable “symbols” is a Hash containing the list of symbols that must be substituted in the include statements. (Only one symbol is defined in this case.) The include statements of the BDF file look as follows:

include INCDIR:/MESH/elemNodes_pan_MX.bdf
    include INCDIR:/MESH/elemNodes_pan_MY.bdf
include     INCDIR:/MESH/elemNodes_pan_MZ.bdf
include ../../    MODEL/MES    H/elemNod    es_pan_PX.bdf
include INCDIR:/MESH/    elemNodes_pan_PY.bdf

The example “readBdf_V3” proposes a slightly more complicated case of file inclusions in a main BDF.

In Example “readBdf_V7” one proposes to illustrate several functions allowing the manipulation of the database FEM entities. A list of Nastran cards corresponding to the FEM definition is build as follows:

    cards=[]
    db.each_coordSysId do |id|
        cards << db.fillCard("CoordSys",id)
    end
    db.each_nodeId do |id|
        cards << db.fillCard("Node",id)
    end
    db.each_elemId do |id|
        cards << db.fillCard("Element",id)
    end
    db.each_rbeId do |id|
        cards << db.fillCard("RBE",id)
    end
    db.each_materialId do |id|
        cards << db.fillCard("Material",id)
    end
    db.each_propertyId do |id|
        cards << db.fillCard("Property",id)
    end

Then, one builds a new database using these cards:

    db3=NastranDb.new()
    db3.Name="tmpDB3"
    db3.insertCards(cards);

Finally, one checks the content of the new database:

    db3.writeBdfLines("out.bdf","w","left","short","All");

    vectStr=NastranDb.writeNastranCardsToVectStr("left","short",cards);
    vectStr.each do |line|
        puts line
    end

Example “readBdf_V8” illustrates the reading of a model by several calls to “readBdf” methods:

    db.readBdf("D:/SHARED/FERESPOST/TESTSAT/MODEL/MESH/coordSys.bdf",nil,nil,nil,true,true)
    db.readBdf("D:/SHARED/FERESPOST/TESTSAT/MODEL/MATS/mats.bdf",nil,nil,nil,true,true)
    db.readBdf("../../MODEL/PROPS/props.bdf",nil,nil,nil,true,true)

    ...

    db.readBdf("../../MODEL/FIXAS/launch.bdf",nil,nil,nil,true,true)
    db.readBdf("../../MODEL/LOADS/unit_accel.bdf",nil,nil,nil,true,true)

This approach can be used to modify finite element model stored in a database during script execution.

IV.2.2.2 Group examples

IV.2.2.2.1 Printing the list of a DataBase’s Groups

It shows how it is possible to obtain the list of Groups contained in a DataBase. This may be useful if one wants to check whether all Groups read from a session file have been correctly integrated in the DataBase. The ruby program looks like:

# Creates  and initializes the DataBase :

   db=NastranDb.new()
   db.Name="tmpDB"
   db.readBdf("../../MODEL/MAINS/unit_xyz.bdf")
   db.readGroupsFromPatranSession("../../MODEL/PATRAN/groups.ses")

# Prints all the group names :

   puts db.getAllGroupNames()

The last line performs the printing of the names of all Groups contained in the DataBase. The other lines are for DataBase creation and initialization.

The example is given in file "RUBY/EX02/printGroupNames.rb".

IV.2.2.2.2 Content of DataBase’s Groups

In the previous example one simply printed the list of the names of Groups contained in a DataBase. In this new examples, one also print information on the content of each Group. Practically, this is done as follows:

The program looks like this:

# Creates  and initializes the DataBase :

   db=NastranDb.new()
   db.Name="tmpDB"
   db.readBdf("../../MODEL/MAINS/unit_xyz.bdf")
   db.readGroupsFromPatranSession("../../MODEL/PATRAN/groups.ses")

# Prints Groups’ data :

   printf("%20s%10s%10s%10s%10s\n","groupName","Nodes",\
      "Elements","RBEss","CoordSys")
   db.each_groupName do |groupName|
      grp = db.getGroupCopy(groupName)
      nodesNbr = grp.NbrElements
      elementsNbr = grp.NbrNodes
      rbesNbr = grp.NbrRbes
      coordNbr = grp.NbrCoordsys
      printf("%20s%10d%10d%10d%10d\n",groupName,nodesNbr,\
         elementsNbr,rbessNbr,coordNbr)
   end

The example is given in file "RUBY/EX02/printGroups.rb".

IV.2.2.2.3 Printing a Patran session file

The third example prints Groups defined in a Patran session file without importing them into a DataBase. Groups are directly read into a Hash object with the following statement:

   h=Post.readGroupsFromPatranSession("../../MODEL/PATRAN/groups.ses")

Then, for each Group, the entities are printed as lists of integer. One shows below how it is done for the nodes:

   nbrEntitiesPerLine=8

   h.each do |id,grp|
      os.printf("Group \"%s\":\n\n",id)

      ...

      nbr=grp.getNbrEntitiesByType("Node")
      os.printf("   Nbr Nodes: %d",nbr)
      counter=0
      grp.each_node do |id|
         if (counter%nbrEntitiesPerLine==0) then
            os.printf("\n      ")
         end
         os.printf("%8d",id)
         counter+=1
      end
      os.printf("\n\n")

      ...

   end

The example is given in file "RUBY/EX02/writeGroupEntities.rb".

IV.2.2.3 Manipulating Group entities

The entities stored in a Group can be manipulated. For example, the following statements:

   grpList=[]

   grp=Group.new
   grp.addEntities("Element 20000:24999 Node 20000:24999")
   grp.Name="pan_MX"
   grp.matchWithDbEntities(db)
   grpList << grp

create a Group, add elements and nodes into it, remove the elements and nodes undefined in the db DataBase and insert the created Group into an Array.

It is also possible to add or remove entities with range defined with steps:

   grp=Group.new
   grp.addEntities("Element 20000:24999:7 Node 20000:24999:7")
   grp.removeEntities("Element 20000:24999:28 Node 20000:24999:28")
   grp.Name="pan_MX_7_28"
   grp.matchWithDbEntities(db)
   grpList << grp

At the end of the example, the Groups are saved into a Patran session file:

   Post::writeGroupsToPatranSession("groups.ses",grpList)

The example is given in file "RUBY/EX03/manipGroups.rb".

IV.2.2.4 Adding Groups to a DataBase

In the examples of section IV.2.2.2, one initialized a DataBase and examined its Groups and the content of the Groups. In this example, one shows how the Groups can be manipulated, and the DataBase modified during the execution of the program.

The groups contained in session file “groups.ses” are not sufficient to suit our post-processing requirements. Indeed, it would be very practical if for each panel, a distinction between the skins and honeycomb could be made. We decide that it shall be done by adding new Groups to the DataBase. This problem can be solved in four steps:

1.

Initialization of a DataBase.

2.

Creation of Groups by association to materials.

3.

Creation of Groups by intersections and insertion in the DataBase.

4.

Printing of the Groups contained in the DataBase (for checking the result of the operation).

Steps 1 and 4 above correspond to the operation of the example presented in section IV.2.2.2. Therefore, one does not present those parts of the program here. One only gives explanation on steps 2 and 3.

The creation of “material Groups” is done by calling the DataBase “getElementsAssociatedToMaterialId” method. Three Groups are created, corresponding to honeycomb 50 kg/m3, honeycomb 72 kg/m3 and Aluminum 2024 T3 respectively. Practically this is programmed as follows:

# Groups created by Materials :

   tmpGroup_Honey_50  = db.getElementsAssociatedToMaterialId(5)
   tmpGroup_Honey_50 += db.getElementsAssociatedToMaterialId(4)
   tmpGroup_Honey_50.Name="Honey_50"

   tmpGroup_Honey_72 = db.getElementsAssociatedToMaterialId(6)
   tmpGroup_Honey_72.Name="Honey_72"

   tmpGroup_Al_2024 = db.getElementsAssociatedToMaterialId(3)
   tmpGroup_Al_2024.Name="Al_2024"

   tmpGroup_CFRP = db.getElementsAssociatedToMaterials(10000)
   tmpGroup_CFRP.Name="CFRP"

   matGroups = Array.new()
   matGroups << tmpGroup_Honey_50
   matGroups << tmpGroup_Honey_72
   matGroups << tmpGroup_Al_2024
   matGroups << tmpGroup_CFRP

   db.addGroupCopy(tmpGroup_Honey_50)
   db.addGroupCopy(tmpGroup_Honey_72)
   db.addGroupCopy(tmpGroup_Al_2024)
   db.addGroupCopy(tmpGroup_CFRP)

One can make a few remarks about the previous ruby lines:

After the creation of material Groups, one creates the other Groups by intersection (step 3). This is done as follows:

# Groups created by intersection :

   panelGroupNames = Array.new()
   panelGroupNames << "pan_MX"
   panelGroupNames << "pan_MY"
   panelGroupNames << "pan_MZ"
   panelGroupNames << "pan_PX"
   panelGroupNames << "pan_PY"
   panelGroupNames << "pan_PZ"
   panelGroupNames << "pan_SUP"

   for panelGroupName in panelGroupNames
      panelGroup = db.getGroupCopy(panelGroupName)
      for matGrp in matGroups
         newGrp = panelGroup * matGrp
         newGrp.Name=panelGroupName+"_"+matGrp.Name
         if newGrp.getEntitiesByType("Element").size > 0
            db.addGroupCopy(newGrp)
         end
      end
   end

Here again, a few commentaries can be done:

The example is given in file “RUBY/EX03/makeMatGroups.rb”.

IV.2.3 Examples with iterators

One presents one example illustrating the use of some of the iterators defined in DataBase class. The following lines print the elements connectivity:

   db.each_elemId do |elemId|
      STDOUT.printf(" %d =>",elemId)
      db.each_nodeOfElement(elemId) do |nodeId|
         STDOUT.printf(" %d",nodeId)
      end
      STDOUT.printf("\n")
   end

Two iterators have been used in the calculation: “each_elemId” and “each_nodeOfElement”. A second version of the loop restricts the printing of connectivity to corner nodes only.

The example is given in file “RUBY/EX16/elemConnectivity.rb”.

An iterator is also used in example “RUBY/EX03/properties.rb”. In that example, one uses the “fillCard” method of NastranDb class to obtain the definition of the properties in the model:

    db.each_propertyId do |id|
        puts "Property",id
        card=db.fillCard("Property",id)
        puts card
    end

(See section III.1.1.5 for the definition of “fillCard” method.)

IV.2.4 Examples with Results

IV.2.4.1 Inspecting Results contained in a DataBase

The following example prints the information on Results available in the DataBase. It starts with the following lines:

   require "FeResPost"
   include FeResPost

   #DataBase::disableLayeredResultsReading
   #DataBase::disableSubLayersReading("Bottom")
   #DataBase::disableSubLayersReading("Mid")
   #DataBase::disableSubLayersReading("Top")

The commented lines are methods that disable partially or entirely the reading of composite element layered Results. After reading the corresponding manual in section I.1.3.2, you may un-comment some of these instructions to check the effect on the reading of composite Results.

The main part of the example program looks like this:

# Reading or generating Results :

   db.readOp2("../../MODEL/EXEC_OP2/unit_xyz.op2","Results")

   db.generateCoordResults
   db.generateCoordResults("Fake Coords Case","No SubCase","coords")

# Inspecting and reading Results :

   db.each_resultKeyCaseId do |lcName|
      printf("LOADCASE: \"%s\"\n",lcName)
   end
   db.each_resultKeySubCaseId do |scName|
      printf("SUBCASE: \"%s\"\n",scName)
   end
   db.each_resultKeyLcScId do |lcName,scName|
      printf("LOADCASE and SUBCASE: \"%s\" - \"%s\"\n",lcName,scName)
   end
   db.each_resultKeyResId do |resName|
      printf("RESULT: \"%s\"\n",resName)
   end

   db.each_resultKey do |lcName,scName,tpName|
      tmpRes=db.getResultCopy(lcName,scName,tpName)
      printf("%-20s%-15s%-50s%-10d\n",lcName,scName,tpName,\
             tmpRes.Size)
   end

It works as follows:

The example is provided in file “RUBY/EX04/printResLists.rb”.

Another example illustrating the reading of Results from a Nastran OP2 file is provided in file “RUBY/EX04/printResLists_filter.rb”. This example illustrates the use of “readOp2FilteredResults” method.

IV.2.4.2 Calculations with Results

One shows here how calculations can be performed with Result objects. One first initializes the DataBase and imports Results with function “readOp2”. In this example, one works with the thermo-elastic version of the model, but its initialization is vey similar to the initialization in other examples. One also add addition Groups corresponding to skins and honeycomb of the sandwich panels, like in the example of section IV.2.2.4. Those parts are not described here.

One first describes the manipulation of results that lead to the calculation of maximum equivalent Von Mises stress in the skins of upper panel. The corresponding ruby lines look like this:

   targetGrp = db.getGroupCopy("pan_PZ_Al_2024")
   stress =  db.getResultCopy("ORBIT_ONE_MS2_Z","Statics",\
      "Stress Tensor","ElemCorners",targetGrp,[])
   scalar = stress.deriveTensorToOneScal("VonMises")

   maxScalar = scalar.extractResultMax
   maxRkl = maxScalar.extractRkl
   maxStress = stress.extractResultOnRkl(maxRkl)
   maxScalarData = maxScalar.getData()[0]
   maxStressData = maxStress.getData()[0]

   puts
   puts "Maximum Von Mises stress in panel +Z skins :"
   puts
   printf("   %.2f Pa on element %d (layer=\"%s\").\n",
      maxScalarData[5],maxScalarData[0],maxScalarData[2])
   printf("      Sxx = %.2f, Syy = %.2f, Szz = %.2f,\n",maxStressData[5],\
             maxStressData[6],maxStressData[7])
   printf("      Sxy = %.2f, Syz = %.2f, Szx = %.2f\n",maxStressData[8],\
             maxStressData[9],maxStressData[10])

Basically, the process can be divided into three parts:

1.

Actual calculation of Von Mises stress. One recovers the Cauchy stress tensor corresponding to the selected load case and selected Group. Then one derives a scalar equivalent Von Mises stress.

2.

Selection of the data corresponding to the maximum Von Mises stress. This is done as follows:

  • First, a call to “extractResultMax” is done to build a Result object containing the maximum Von Mises stress.

  • Then one recovers the ResKeyList object corresponding to this maximum stress. The ResKeyList object contains only one Result key.

  • One recovers the Cauchy stress tensor corresponding to the maximum stress.

  • Finally, one recovers the values contained in the selected maximum equivalent Von Mises stress and corresponding Cauchy stress values. Remark the “[0]” at the end of calls to “getData” methods. The reader must remember that this method returns an Array of Arrays. But in this particular case, the returned Array has only one Array element.

3.

Printing of the Results. The reader will understand by himself how it works.

In the same file, one also calculates a maximum out of plane shear stress in the honeycomb of the +Z panel. The calculation of this stress is done as follows:

   targetGrp = db.getGroupCopy("pan_PZ_Honey_72")
   stress = db.getResultCopy("ORBIT_ONE_MS2_Z","Statics",\
      "Stress Tensor","ElemCorners",targetGrp,[])
   sXZ = stress.deriveTensorToOneScal("Component XZ")
   sYZ = stress.deriveTensorToOneScal("Component YZ")
   scalar = Post.sqrt(sXZ*sXZ+sYZ*sYZ)

Similarly, one calculates the “MaxShear” stress (obtained from the eigen values of the Cauchy stress tensor):

   targetGrp = db.getGroupCopy("pan_PZ_Honey_72")
   stress =  db.getResultCopy("ORBIT_ONE_MS2_Z","Statics",\
      "Stress Tensor","ElemCorners",targetGrp,[])
   scalar = stress.deriveTensorToOneScal("MaxShear")

In the same data file, one shows how the bar stresses are recovered:

   targetGrp = db.getGroupCopy("strut_A")
   stress =  db.getResultCopy("ORBIT_ONE_MS2_X","Statics",\
      "Beam Axial Stress for Bending Loads","ElemCorners",targetGrp,[])
   scalar = Post.abs(stress)

   maxScalar = scalar.extractResultMax
   maxRkl = maxScalar.extractRkl
   maxStress = stress.extractResultOnRkl(maxRkl)
   maxScalarData = maxScalar.getData()[0]
   maxStressData = maxStress.getData()[0]

   puts
   puts "Maximum bar stress in strut A :"
   puts
   printf("   %.2f Pa on element %d (layer=\"%s\").\n",
      maxScalarData[5],maxScalarData[0],maxScalarData[2])
   printf("      Sxx = %.2f\n",maxStressData[5])
   puts
   puts

Note that the way maximum stress is recovered from FE Results is different because Nastran calculates only the longitudinal component of the stress tensor at four locations in the cross-section. The shear stress is not taken into account in this calculation. More complicated calculations have to be performed to take into account all the components of the stress tensor for bar and beam elements.

These examples are provided in file “RUBY/EX05/printStressMax.rb”. Another example illustrating the calculation of tensorial results eigen-values and eigen-vectors is presented in file “RUBY/EX05/eigenQR.rb”.

IV.2.4.3 Using predefined criteria

The example given in file “RUBY/EX05/calcHoneyAccel.rb” explains how a predfined criterion can be calculated. This is done for the “HoneycombAirbusSR” predefined criterion presented in detail in section X.D.1.2. The operations can be sorted in three steps:

Note that the seventh element of the “output” Array above is the only Result object created and returned by the predefined criterion. The same object could be obtained by a few ruby statements like:

        shearL=@@stressTensor.deriveTensorToOneScal("Component XZ")
        shearW=@@stressTensor.deriveTensorToOneScal("Component YZ")
        tmp=sq(shearL/allL)+sq(shearW/allW)
        sr=fos*sqrt(tmp)

The computational cost of these few statement can be very important however. Indeed, several FeResPost Result objects are created by these few lines. One creates consecutively the following result objects:

1.

One “shearL” scalar Result by extraction of XZ component.

2.

One “shearW” scalar Result by extraction of YZ component.

3.

One “shearL/allL” scalar Result (division by real value).

4.

One “shearW/allW” scalar Result (division by real value).

5.

One “sq(shearL/allL)” scalar Result (scalar Result to the square).

6.

One “sq(shearW/allW)” scalar Result (scalar Result to the square).

7.

One “tmp” Result obtained by summation of two scalar Results.

8.

One “sqrt(tmp)” Result obtaiend by extracting the square root of a scalar Result.

9.

And finally, the “sr” Result, which is the only one that shall be kept.

This means that 8 intermediate Result objects have been created and are discared at the end. Each of the 8 intermediate Result creation involves a loop on all the key-value pairs of the operations argument(s), and insertion in the new Result. If the initial Cauchy Stress Tensor Result contains a large number of key-value pairs, the computation cost of this criterion can be very important.

In the same ruby file, one provides a second computation of the Airbus criterion using the “interaction” approach:

      lStress=stress.deriveTensorToOneScal("Component XZ")
      wStress=stress.deriveTensorToOneScal("Component YZ")
      criterionData=[]
      criterionData << Post.abs(lStress)*(1.5625/2.41e6)
      criterionData << 2.0
      criterionData << Post.abs(wStress)*(1.5625/1.41e6)
      criterionData << 2.0
      #~ output=Post.calcPredefinedCriterion("Interaction_2_SR",criterionData)
      output=Post.calcPredefinedCriterion("Interaction_N_SR",criterionData)
      srMax=output[1].extractResultMax()
      maxData=srMax.getData("int","int","int","int","int")[0];

Of couse, this calculation method is less efficient than the previous one. It illustrates however the calculation of Strength Ratios via interaction of failure criteria.

IV.2.4.4 Printing Results’ content

One presents here an example in which Results corresponding to the STRAIN Nastran output statement are printed. Note that the non-diagonal components of the Nastran tensors corresponding to STRAIN statement are multiplied by two by Nastran. So, when imported into a DataBase, one divides the corresponding components by two (see remark 5 page 654 in Chapter III.1).

The preliminary part of the program is similar to the previous one: one initializes a DataBase, imports a Nastran model, produces the Groups and read Results. Then, the strain tensor in the honeycomb of +Z panel is output. This is done as follows:

   targetGrp = db.getGroupCopy("pan_PZ_Honey_72")
   strain =  db.getResultCopy("TEMP_GRAD_X","Statics",\
      "Strain Tensor","ElemCenters",targetGrp,[])

   puts
   puts "Strain tensor in panel +Z honeycomb :"
   puts
   strain.each("int","int","int") do |key,values|
      for j in 0..3
         printf("%10s",key[j].to_s)
      end
      if (values[0]) then
         printf("%10s",values[0].to_s)
      else
         printf("%10s","nil")
      end
      for j in 1..6
         printf("%14f",values[j])
      end
      printf("\n")
   end

The "each" iterator is used with three "int" parameters. This leads to a printed output in which the layers are output with integer values.

In surface elements, two Results correspond to the STRAIN Nastran output statement: the strain tensor and the curvature tensor. The way components of the strain tensor are printed is similar as for the honeycomb. For the curvature tensor, the print is done as follows:

   targetGrp = db.getGroupCopy("pan_PZ_Al_2024")
   strain =  db.getResultCopy("TEMP_GRAD_X","Statics",\
      "Strain Tensor","ElemCenters",targetGrp,[])

   puts
   puts "Strain tensor in panel +Z skins :"
   puts
   strain.each do |key,values|
      for j in 0..3
         printf("%10s",key[j].to_s)
      end
      if (values[0]) then
         printf("%10s",values[0].to_s)
      else
         printf("%10s","nil")
      end
      for j in 1..6
         printf("%14f",values[j])
      end
      printf("\n")
   end

This example is provided in file "RUBY/EX08/printStrain.rb".

Similarly, one print Results corresponding to Forces and Moments in CBAR elements. The interesting part is given below:

   targetGrp = db.getGroupAllFEM

   forces = db.getResultCopy("LAUNCH_ONE_MS2_X","Statics",\
      "Beam Forces","Elements",targetGrp,[])

   moments = db.getResultCopy("LAUNCH_ONE_MS2_X","Statics",\
      "Beam Moments","Elements",targetGrp,[])

   Util::printRes(STDOUT,"Forces",forces)
   Util::printRes(STDOUT,"Moments",moments)

The reader will observe in Results that “Beam Forces” in CBAR elements are given at the center of elements only, while “Beam Moments” are printed at the two end nodes of each element.

This example is provided in file "RUBY/EX08/printBeamForces.rb".

IV.2.4.5 Coordinate system transformations

One first presents an example, in which one modifies the coordinates of a point, and the components of a vector and of a tensor attached to this point. One first extracts the coordinate systems that are used in this example, and one defines the entities that shall be transformed:

    cs5=db.getCoordSysCopy(5)
    cs6=db.getCoordSysCopy(6)

    x=[5.0,0.0,0.0]
    v=[1.5,3.2,-4.0]
    m=[[2.0,3.0,-7.0],[1.0,0.0,0.0],[0.0,0.0,1.0]]

One assumes that the coordinates and components of the vector and tensor defined above are given in coordinate system 5. Coordinates and components can be expressed in basic coordinate system as follows:

    x0=cs5.changeCoordsA20(x)
    v0=cs5.changeCompsA20(x,v)
    m0=cs5.changeCompsA20(x,m)

Then, the coordinates and components can be re-expressed wrt coordinate system 5 using the following transformations:

    x5=cs5.changeCoords02B(x0)
    v5=cs5.changeComps02B(x0,v0)
    m5=cs5.changeComps02B(x0,m0)

Coordinates and components can also be transformed directly from coordinate system 5 to 6:

    x6=cs5.changeCoordsA2B(x5,cs6)
    v6=cs5.changeCompsA2B(x5,v5,cs6)
    m6=cs5.changeCompsA2B(x5,m5,cs6)

and then back to coordinate system 5:

    x5=cs6.changeCoordsA2B(x6,cs5)
    v5=cs6.changeCompsA2B(x6,v6,cs5)
    m5=cs6.changeCompsA2B(x6,m6,cs5)

The entire example is given in file "RUBY/EX09/modifCS.rb".

One presents below an example that illustrates the transformations of coordinate system in which Result components are expressed. One loads results on elements with PCOMP properties. Then the components are printed after several transformations:

The transformations are performed with the following instructions:

   ...
   stress.modifyRefCoordSys(db,0)
   ...
   stress.modifyRefCoordSys(db,"elemIJK")
   ...
   stress.modifyRefCoordSys(db,7)
   ...
   stress.modifyRefCoordSys(db,"matCS")
   ...
   stress.modifyRefCoordSys(db,0,[1.0, 0.0, 0.0])
   ...
   stress.modifyRefCoordSys(db,0,[0.0, 1.0, 0.0])
   ...
   stress.modifyRefCoordSys(db,"elemCS")
   ...

Two versions of the sequence of transformations are proposed:

1.

In the first version, the transformations are done from the native Results. This means that the Result object to be transformed is reloaded from the DataBase prior to each transformation. One also presents an example of use of the “each” iterator of Result class.

2.

In the second version, the transformation is done successively on the same Result object which has been loaded only once. One also presents examples of the use of “each”, “each_key” and “each_values” of the Result class. For example, two versions of the use of “each_key” iterator are presented:

            ...
            stress.each_key do |stressKey|
               for j in 0..3
                  printf("%10s",stressKey[j].to_s)
               end
               printf("\n")
            end
      
            stress.each_key("int","int","int","int") do |elemId,nodeId,layerId,subLayerId|
               printf("%10s",elemId.to_s)
               printf("%10s",nodeId.to_s)
               printf("%10s",layerId.to_s)
               printf("%10s",subLayerId.to_s)
               printf("\n")
            end
            ...

The example ends with an error message for the second version because it is not possible to transform a Result object if stored values are already expressed in a projected coordinate system.

This example is provided in file "RUBY/EX09/modifCS2D.rb". A second version of the example with transformation of results on 3D elements is given in file "RUBY/EX09/modifCS3D.rb".

A third version involving the use of user defined coordinate systems is provided in file "RUBY/EX09/modifCS2Db.rb". This version illustrate the manipulation of CoordSys objects.

Finally, a fourth version of the 2D example is obtained by addition new arguments to the “modifyRefCoordSys” method in such a way that Results expressed in user or projected coordinate systems can further be modified without resulting in error messages. The successive transformation of coordinate systems become:

   ...
   stress.modifyRefCoordSys(db,0)
   ...
   stress.modifyRefCoordSys(db,"elemIJK")
   ...
   stress.modifyRefCoordSys(db,7)
   ...
   stress.modifyRefCoordSys(db,"matCS")
   ...
   stress.modifyRefCoordSys(db,0,[1.0, 0.0, 0.0])
   ...
   stress.modifyRefCoordSys(db,0,[0.0, 1.0, 0.0],0,[1.0, 0.0, 0.0])
   ...
   stress.modifyRefCoordSys(db,"elemCS",nil,0,[0.0, 1.0, 0.0])
   ...

This last version is given in file "RUBY/EX09/modifCS2Dc.rb".

Finally, one proposes in "RUBY/EX09/modifCS2Dd.rb" a version of the example in which a “FieldCS” Result is used to modify the components of stress tensor. The FieldCS Result is defined as follows, from the stress tensor Result:

    fldCS=Result.new()
    fldCS.Format=1
    fldCS.TensorOrder=-10
    fldCS.insertRklVals(stress,[5,1.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,1.0])
    fldCS.modifyRefCoordSys(db,0)

(Note that the FieldCS is often constructed from the Result object of which it is meant to modify the components by calling modifyRefCoordSys mehtod.) The “fieldCS” Result is then simply used in a coordinate system transformation as follows:

    ...
        when 3 then
            puts
            puts "FieldCS"
            puts
            stress.modifyRefCoordSys(db,fldCS)
    ...

IV.2.4.6 Manipulation of Complex Results

In this example, Complex Results will be read from a Nastran xdb file. One first examines the information stored in the result file, in order to extract only the Results on needs to illustrate the manipulation of Complex Results.

IV.2.4.6.1 Extracting xdb lists of load cases and Results

The part of interest looks as follows:

   xdbFileName="../../MODEL/EXEC_XDB/sol111_ri_xyz.xdb"
   tab=NastranDb.getXdbLcScResNames(xdbFileName)
   lcNames=tab[0]
   scNames=tab[1]
   resNames=tab[2]

The lists of load cases, sub-cases and result types stored in the xdb file are saved into three Arrays of Strings that can be printed or used for other purposes.

IV.2.4.6.2 Extracting xdb Results information

The part of interest looks as follows:

   xdbFileName="../../MODEL/EXEC_XDB/sol111_ri_xyz.xdb"
   infos=NastranDb.getXdbLcInfos(xdbFileName)

   infos.each do |tab|
      STDOUT.printf("%-20s %-25s %-6d %-6d %-15g %-15g\n",
                    tab[0],tab[1],tab[3],tab[4],tab[5],tab[6])
   end

One extracts the information about the load cases and sub-cases to which Results are associated in the xdb file. Then, the name of load cases, sub-cases and associated integer and real data are printed. (Note, that the third String ID, which is always void, is not printed.) The example is provided in file "RUBY/EX17/printXdbLcInfos.rb".

IV.2.4.6.3 Manipulation of Complex Results

The results of "printXdbLcInfos.rb" are used to select load cases and sub-cases for which Results are imported into the DataBase. One also selects some of the Results:

   lcNames=[]
   lcNames << "SINUS_X"

   scNames=[]
   scNames << "Output 70 (f = 119.0000)"
   scNames << "Output 30 (f = 79.0000)"
   scNames << "Output 1 (f = 50.0000)"

   resNames=[]
   resNames << "Accelerations, translational (MP)"
   resNames << "MPC Forces, Forces (MP)"
   resNames << "MPC Forces, Moments (MP)"
   resNames << "Accelerations, translational (RI)"
   resNames << "MPC Forces, Forces (RI)"
   resNames << "MPC Forces, Moments (RI)"

Note that the selection of sub-cases to be imported into the DataBase is useful even when all the load cases are to be post-processed. Indeed the post-processing of a limited number of load cases at the same time reduces the amount of memory required to store all the Results. However, this means that several Result importations might be necessary, and this increases the time needed for disk IO operations.

Then the results are imported from xdb files corresponding to SOL111 Nastran calculations. One reads two files: one in which the Results are saved in rectangular format, and one in which they are saved in polar format:

   xdbFileName="../../MODEL/EXEC_XDB/sol111_ri_xyz.xdb"
   db.readXdb(xdbFileName,lcNames,scNames,resNames)

   xdbFileName="../../MODEL/EXEC_XDB/sol111_mp_xyz.xdb"
   db.readXdb(xdbFileName,lcNames,scNames,resNames)

To illustrate the manipulation of Results, the extraction is done for one particular load case, one particular sub-case, and on a small Group of 11 nodes only:

   tmpGroup=Group.new
   tmpGroup.setEntities("Node 60100:60110")

   lcName="SINUS_X"
   scName="Output 30 (f = 79.0000)"

Only the “Accelerations” Result is studied:

   resRI=db.getResultCopy(lcName,scName,"Accelerations, translational (RI)",
                          "Nodes",tmpGroup,[])
   Util::printRes(STDOUT,"Accelerations resRI",resRI)

   resMP=db.getResultCopy(lcName,scName,"Accelerations, translational (MP)",
                          "Nodes",tmpGroup,[])
   Util::printRes(STDOUT,"Accelerations resMP",resMP)

The following statements illustrate the polar-rectangular formats conversions:

   calcMP=Result.new
   calcMP.set2MP(resRI)
   Util::printRes(STDOUT,"Accelerations calcMP",calcMP)

   calcRI=Result.new
   calcRI.set2RI(resMP)
   Util::printRes(STDOUT,"Accelerations calcRI",calcRI)

And here, one shows how Real Results can be extracted from complex ones:

   resR=calcMP.getR
   resM=calcMP.getM
   resI=calcMP.getI
   resP=calcMP.getP
   Util::printRes(STDOUT,"Accelerations resR",resR)
   Util::printRes(STDOUT,"Accelerations resM",resM)
   Util::printRes(STDOUT,"Accelerations resI",resI)
   Util::printRes(STDOUT,"Accelerations resP",resP)

Of course, the reverse operation can be done too. Here is how Complex Results can be assembled from one pair of Real Results:

   assyRI=Result.new
   assyMP=Result.new
   assyRI.assembleComplex(2,resR,resI);
   assyMP.assembleComplex(3,resM,resP);

   Util::printRes(STDOUT,"Accelerations assyRI",assyRI)
   Util::printRes(STDOUT,"Accelerations assyMP",assyMP)

Finally, FeResPost allow to perform operations on Results that have Complex number arguments. For example, a Result object may be multiplied by a Complex number:

   require "complex"

   Z=Complex.new(3.0,2.0)

   multRI=resRI.clone
   multRI*=Z
   Util::printRes(STDOUT,"Accelerations multRI",multRI)

   multMP=resMP.clone
   multMP*=Z
   Util::printRes(STDOUT,"Accelerations multMP",multMP)

IV.2.4.6.4 Working with XDB attachments

The example “printXdbLcScResSizes.rb” illustrates the extraction of Results from an XDB attachment. The advantage of this method for accessing Results, is that they must no be a priori loaded into a NastranDb object. The attachment is done as follows:

   xdbFileName="../../MODEL/EXEC_XDB/sol111_ri_xyz.xdb"
   db.attachXdb(xdbFileName)

One then selects the load case, the list of sub-cases, and the Result types for the extraction:

   lcName="SINUS_X"

    scNames=[]
    scNames << "Output 13 (f = 62.0000)"
    scNames << "Output 14 (f = 63.0000)"
    scNames << "Output 15 (f = 64.0000)"
    scNames << "Output 16 (f = 65.0000)"
    scNames << "Output 17 (f = 66.0000)"
    scNames << "Output 18 (f = 67.0000)"

    resNames=[]
    resNames << "Accelerations, Rotational (RI)"
    resNames << "Accelerations, Translational (RI)"
    resNames << "Displacements, Rotational (RI)"
    resNames << "Displacements, Translational (RI)"

The extraction is then done with a call like this one:

    h=db.getAttachmentResults(xdbFileName,lcName,scNames,resNames,"Nodes",grp)

Finally, the Results that have been returned in h (a Hash object) can be retrieved as follows:

   h.each do |id,res|
        lcName=id[0]
        scName=id[1]
        resName=id[2]
        size=res.Size
        STDOUT.printf("%s - %s - %s : %d\n",lcName,scName,resName,size)
    end

IV.2.4.7 Manipulation of XDB attachments

This section illustrates the manipulation of XDB attachments. All the examples are to be found in directory “RUBY/EX19”. The different examples are in increasing order of difficulty.

In order to reduce the size of extracted Results, the extractions are done on the nodes of a small Group in all the examples below. Note however that other extractions could have been done. Also, if the two last parameters of the extraction functions are omitted, all the Result values are returned by the extraction methods.

IV.2.4.7.1 Extracting information from XDB attached file

In the example “attachedXdbLcInfos.rb”, one shows how content information can be extracted from an attached XDB file. The XDB file must first be attached to the DataBase:

   xdbFileName="../../MODEL/EXEC_XDB/sol111_ri_xyz.xdb"
   db.attachXdb(xdbFileName)

Then, the information is extracted and printed exactly as in one of the examples of section IV.2.4.6:

   infos=db.getAttachmentLcInfos(xdbFileName)
   infos.each do |tab|
      STDOUT.printf("%-20s %-25s %-6d %-6d %-15g %-15g\n",
                    tab[0],tab[1],tab[3],tab[4],tab[5],tab[6])
   end

It is also possible to extract other information like the list of Result names, sub-case names or load cases names. One shows below how the list of result names can be printed:

   resNames=db.getAttachmentResNames(xdbFileName)
   resNames.each do |resName|
      STDOUT.printf("%-20s\n",resName)
   end

IV.2.4.7.2 Extracting Results from XDB attached file

The example “attachedXdbResults.rb” shows how Results can be extracted from an XDB attachment. As in the previous example, the file is first attached. Then, one decides which result types and for which load case Results are extracted:

   lcName="SINUS_Z"
   resName="Accelerations, Translational (RI)"

Remember than only one load case name can be specified. However, an Array of result names can be provided. In this case, one decides to extract only one result type: “Accelerations, Translational (RI)”. On the other hand, an Array of sub-cases can be specified for the extraction of Results. In this case, the Array is first obtained by calling the “getAttachmentScNames” method:

   scNames=db.getAttachmentScNames(xdbFileName)

Then, the Results are extracted as follows:

   results=db.getAttachmentResults(xdbFileName,lcName,scNames,resName,
        "Nodes",grp)

The results are returned in a Hash object that contains pairs of Result keys, and the corresponding Results. The Results can be printed as follows:

   results.each do |key,res|
       Util::printRes(STDOUT,key[1]+" ==> "+key[2],res)
   end

Note that at the beginning of the script, the buffer total maximum capacity is set to 1Mb as follows:

  NastranDb::setStorageBufferMaxCapacity(1.0)

Another example of Results extraction from an XDB attachment is presented in file “attachedXdbExtract.rb”. There several Result types are extracted for a single load case and a single sub-case:

   lcName="LAUNCH_ONE_MS2_Y"
   scName="Statics"
   resNames=[]
   resNames << "Shell Forces"
   resNames << "Shell Moments"
   resNames << "Strain Tensor"
   resNames << "Curvature Tensor"

   location="ElemCenters"
   grp=db.getGroupCopy("pan\_MZ")
   layers="NONE"

   results=db.getAttachmentResults(xdbFileName,lcName,scName,resNames,
        location,grp,layers)

Four Result types have been selected. The list of layers is set to “NONE” to avoid the extraction of Strains on each ply of each element. (One is interested only in the laminate average Strain.)

Results can then be accessed, individually by extracting the elements of the Hash object returned by the “getAttachmentResults” method. For example:

   key=[lcName,scName,"Shell Moments"]
   shMoments=results[key]
   key=[lcName,scName,"Shell Forces"]
   shForces=results[key]
   key=[lcName,scName,"Strain Tensor"]
   shAvrgStrains=results[key]
   key=[lcName,scName,"Curvature Tensor"]
   shCurvatures=results[key]

IV.2.4.7.3 Extracting linear combination of Results from XDB

In order to save time and simplify the programming of post-processing, it is also possible to extract linear combinations of Results. This is presented in example “attachedXdbCombili.rb”.

The linear combination is defined as an Array defining the factors and elementary load cases to consider:

   scName="Statics"
   resName="Displacements, Translational"
   lcNames=["LAUNCH_ONE_MS2_X","LAUNCH_ONE_MS2_Y","LAUNCH_ONE_MS2_Z"]
   factors=[100.0, 50.0, 20.0]

   ...

   combili=[]
   (0..2).each do |i|
      combili << [factors[i], xdbFileName, lcNames[i]]
   end

Then, the linearly combine Results are extracted as follows:

   lcName="CombiLC"
   results=db.getAttachmentResultsCombili(lcName,combili,scName,resName,
        "Nodes",grp)

Note that in this case, one single Result object is returned in the “results” Hash object. For example, in this case, one could have provided an Array of Result names instead of the “resName” String argument.

In example “attachedXdbDynamCombili.rb” the same operation is performed for dynamic Results, and an Array of String is provided as list of sub-cases argument. This illustrates the use of “getAttachmentResultsCombili” method returning several Results.

IV.2.4.7.4 Random analysis or integration of PSD functions

Example “EX19/attachedXdbRandom.rb” illustrates the use of method “calcRandomResponse” in “Post” Module. One calculates the RMS equivalent for a random response.

The calculation is done using the XDB file corresponding to a SOL111 Nastran analysis. The RMS values for accelerations are calculated. The example defines two functions:

The first part of “computeRms” function identifies the subcase names in XDB file, for the selected load case, recovers the corresponding frequencies, and sorts the sub-case names by order of increasing frequency:

    infos=db.getAttachmentLcInfos(xdbFileName)
    h={}
    infos.each do |tab|
        if tab[0]==lcName then
            f=tab[5]
            scName=tab[1]
            h[f]=scName
        end
    end
    allFreqs=h.keys.sort
    totalNbrFreqs=allFreqs.size

Then, the integration is calculated by slices. The “addRes” output of a call to “calcRandomResponse” is used as argument for the next call to the same method. This “addRes” corresponds to the last PSD integration Result object:

   idMin=idMax=0
    addRes=nil
    res=nil
    while idMax<totalNbrFreqs
        idMin=idMax
        idMax=[idMin+maxNbrFreqsPerSlice-1,totalNbrFreqs].min
        freqs=allFreqs[idMin..idMax]
        scNames=[]
        psdInput=[]
        freqs.each do |f|
            scName=h[f]
            scNames << scName
            psdInput << psdFunction(f)
        end
        results=db.getAttachmentResults(xdbFileName,lcName,scNames,
            resName,method,grp)
        sortedResults=[]
        scNames.each do |scName|
            sortedResults << results[[lcName,scName,resName]]
        end
        ret=Post.calcRandomResponse(false,false,sortedResults,freqs,
            psdInput,integType,addRes)
        addRes=ret[1]
        res=ret[2]
    end

IV.2.5 A few useful tools

One presents in this section a few examples that provide at the same time, tools that can be useful in many projects.

IV.2.5.1 Definition of acceleration fields

When sizing a satellite’s structure, one is often asked to define load cases corresponding to quasi-static accelerations on sub-parts of the structure. For example, at system level, dynamic analyses have shown that the upper part of the structure may be submitted to more severe accelerations than the rest of the satellite.

Unfortunately, Nastran does not allow the definition of quasi-static accelerations on sub-parts of the structure. The “GRAV” card, only allows the definition of accelerations globally on the whole structure.

It is possible to solve the problem in two steps:

1.

One calculates with Nastran three elementary load cases corresponding to unit accelerations of 1 ms2 applied on the entire structure oriented on the three structural axes respectively. The definition of these loads is done with Nastran “GRAV” cards.

2.

Then one recovers the finite element Results of the Nastran “op2” file, and after performing some operations on the Results, one performs an appropriate printing of the Results to produce “FORCE” Nastran Bulk cards. Two different results can be used to perform this operation: the applied loads provided by “OLOAD” output, or the applied loads obtained from “GPFORCE” output.

This method is equivalent to the production of a force field.

In this examples, one defines several functions. Therefore, a module “Grav” has also be created, and all functions are placed in the module. A first utility function is used to add to a DataBase a new Group created by performing a union of elementary Groups:

   def Grav.AddNewGroupsByUnions(db,totalGroupName,elemGroupNames)
      totalGroup=Group.new()
      for i in 0...elemGroupNames.size
         elemGroup=db.getGroupCopy(elemGroupNames[i])
         totalGroup+=elemGroup
      end
      totalGroup.Name=totalGroupName
      db.addGroupCopy(totalGroup)
   end

The first argument is the DataBase from which the elementary Groups are Retrieved and to which the new Group is created. The second argument is a String object the value of which is the new Group name. The last argument is an Array of Strings containing the names of the elementary Groups.

Another function is devoted to the printing of the “FORCE” Nastran Bulk Data Cards in a file. The function is defined as follows:

def Grav.writeForce(fileName,lcId,coordSysId,forces)
    print "creating file "
    puts fileName

    table=forces.getData()
    cards=[]
    for oneRes in table
        values=[]
        values << lcId;
        values << oneRes[1]
        values << coordSysId
        x=oneRes[5]
        y=oneRes[6]
        z=oneRes[7]
        norm=Math.sqrt(x*x+y*y+z*z)
        if (norm>1.0e-10) then
            values << norm
            values << x/norm
            values << y/norm
            values << z/norm
        end
        cards << values
    end
    NastranDb.writeNastranCards(fileName,"w","left","short","FORCE",cards);
end

This function has four arguments:

1.

A String corresponding to the name of the file in which the cards are printed.

2.

An integer corresponding to the load case identifier.

3.

An integer corresponding to the coordinate system in which the components of the “FORCE” vectors are given.

4.

A Result object containing the nodal forces. The Result must be vectorial and defined at nodes. Also the forces should be expressed in the coordinate system identified by the third argument.

The function works as follows:

This version of the method is proposed in “RUBY/EX06/makeGravForces.rb”file.

Another version of the function, provided in “RUBY/EX06/makeGravForcesB.rb” reads as follows:

def Grav.writeForce(fileName,lcId,coordSysId,forces)
    print "creating file "
    puts fileName

    table=forces.getData()
    cards=[]
    for oneRes in table
        values=[]
        values << "FORCE"
        values << lcId;
        values << oneRes[1]
        values << coordSysId
        x=oneRes[5]
        y=oneRes[6]
        z=oneRes[7]
        norm=Math.sqrt(x*x+y*y+z*z)
        if (norm>1.0e-10) then
            values << norm
            values << x/norm
            values << y/norm
            values << z/norm
        end
        cards << values
    end
    NastranDb.writeNastranCards(fileName,"w","left","short",cards);
end

Remark that one uses the “5 arguments” version of “writeNastranCards” method. (The “cardName” argument is omitted.) On the other hand, each “values” Array has one additional element. The first element of the Array is the “FORCE” card name.

The function “Grav.genAllGravFields” is the function that performs the extraction of force fields from the Results stored in the DataBase:

   def Grav.genAllGravFields(db,data)
      nbr=data.size
      for i in 0...data.size
         groupName=data[i][0]
         extName=data[i][1]
         baseLID=data[i][2]
         csId=1001

         target=db.getGroupCopy(groupName)

         forces1=db.getResultCopy("LAUNCH_ONE_MS2_X","Statics",\
            "Applied Loads, Forces","Nodes",target,[])
         forces1.modifyRefCoordSys(db,csId)
         forces2=db.getResultCopy("LAUNCH_ONE_MS2_Y","Statics",\
            "Applied Loads, Forces","Nodes",target,[])
         forces2.modifyRefCoordSys(db,csId)
         forces3=db.getResultCopy("LAUNCH_ONE_MS2_Z","Statics",\
            "Applied Loads, Forces","Nodes",target,[])
         forces3.modifyRefCoordSys(db,csId)

         Grav.writeForce("force1_"+extName+".bdf",baseLID+1,csId,forces1)
         Grav.writeForce("force2_"+extName+".bdf",baseLID+2,csId,forces2)
         Grav.writeForce("force3_"+extName+".bdf",baseLID+3,csId,forces3)

         GC.start()
      end
   end

This function receives two arguments:

1.

The DataBase from which the Results are extracted.

2.

An Array of Arrays containing the information necessary for the production of the different force fields. Each element Array contains three elements:

(a)

A String object containing the name of the Group on which the Result forces are retrieved.

(b)

A String containing the name of the extension to be added to the output file name.

(c)

An integer corresponding to the base of the load identifier by which the force field shall be referred in the bulk data file. (Actually, three force fields are produced for each Group in the directions X, Y and Z respectively. The corresponding identifiers are produced by adding 1, 2 or 3 respectively to the base identifier of the load.

The function performs a loop on all the elements of the “data” Array argument. For each element

Finally The “main” function looks like this:

   def Grav.main()

   # Creation of the dataBase :

      db=NastranDb.new()
      db.Name="tmpDB"
      db.readBdf("../../MODEL/MAINS/unit_xyz.bdf")
      db.readGroupsFromPatranSession("../../MODEL/PATRAN/groups.ses")

      Grav.AddNewGroupsByUnions(db,"upper_set",\
         ["pan_SUP", "struts_ALL", "fittings_ALL"])

   # Reading of results :

      db.readOp2("../../MODEL/EXEC_OP2/unit_xyz.op2","Results")

   # Production of force fields :

      data=Array.new()
      data.push(["pan_MX",    "PAN_MX", 611000])
      data.push(["pan_MY",    "PAN_MY", 612000])
      data.push(["pan_MZ",    "PAN_MZ", 613000])
      data.push(["pan_PX",    "PAN_PX", 614000])
      data.push(["pan_PY",    "PAN_PY", 615000])
      data.push(["pan_PZ",    "PAN_PZ", 616000])
      data.push(["upper_set", "UPPER",  617000])

      Grav.genAllGravFields(db,data)

   end

It works as follows:

The program is executed by a call to main function:

   Grav.main()

Note that some of the output files produced by this example are used in the definition of loads for Nastran calculations in Chapter IV.1.

These examples are provided in files "RUBY/EX06/makeGravForces.rb" and "RUBY/EX06/makeGravForcesB.rb".

IV.2.5.2 Definition of temperature fields

This example is similar to the previous one, but instead of generating “FORCE” fields, one generates temperature fields with “TEMP” Nastran cards. Also, the example differs by the fact that no Results are read from an “op2” file.

One writes two functions devoted to the printing of “TEMP” cards in a Bulk Data File. The first function writes a constant temperature field on a Group:

   def Therm.writeConstTempCards(fileName,lcId,target,constT)
      print "creating file "
      puts fileName

      nodes = target.getEntitiesByType("Node")
      index = 0
      cards=[]
      while index < nodes.size
         if (nodes.size-index>=3) then
            values = []
            values << lcId
            for i in 0..2
               values << nodes[index]
               values << constT
               index+=1
            end
         else
            values = []
            values << lcId
            for i in 0...(nodes.size-index)
               values << nodes[index]
               values << constT
               index+=1
            end
         end
         cards << values
      end
      NastranDb.writeNastranCards(fileName,"w+","left","short",
         "TEMP",cards);
   end

The principle of the function is that one recovers the list of nodes contained in the Group. Then for each node, one writes a “TEMP” entry. The second printing function prints a temperature field corresponding to a scalar Result object:

   def Therm.writeFieldTempCards(fileName,lcId,tempField)
      print "creating file "
      puts fileName

      tempData = tempField.getData
      index = 0
      size = tempData.size
      cards=[]
      while index < size
         if (size-index>=3) then
            values = []
            values << lcId
            for i in 0..2
               values << tempData[index][1]
               values << tempData[index][5]
               index+=1
            end
         else
            values = []
            values << lcId
            for i in 0...(size-index)
               values << tempData[index][1]
               values << tempData[index][5]
               index+=1
            end
         end
         cards << values
      end
      NastranDb.writeNastranCards(fileName,"w+","left","short",
         "TEMP",cards);
   end

The principle of the function is very similar to the principle of function “FORCE” field printing function described in section IV.2.5.1.

The main function begins with an initialization of the DataBase:

      db=NastranDb.new()
      db.Name="tmpDB"
      db.readBdf("../../MODEL/MAINS/orbit_unit_xyz.bdf")
      db.readGroupsFromPatranSession("../../MODEL/PATRAN/groups.ses")

Then one defines constant temperature fields on parts of the structure. One defines four cases obtained by a combination of cold or hot temperatures, and application to two Groups. The second Group is build by assembling the lateral panels. This part of the main functions looks like:

      # Generation of temperature fields on panel +Z :

      tmpGrp = db.getGroupCopy("pan_PZ")
      Therm.writeConstTempCards("temp_P120_PAN_PZ.bdf",621001,tmpGrp, 120.0)
      Therm.writeConstTempCards("temp_M100_PAN_PZ.bdf",621001,tmpGrp,-100.0)

      # Generation of temperature fields on lateral panels :

      tmpGrp = db.getGroupCopy("pan_PX")
      tmpGrp += db.getGroupCopy("pan_PY")
      tmpGrp += db.getGroupCopy("pan_MX")
      tmpGrp += db.getGroupCopy("pan_MY")
      Therm.writeConstTempCards("temp_P120_PAN_LAT.bdf",622001,tmpGrp, 120.0)
      Therm.writeConstTempCards("temp_M100_PAN_LAT.bdf",622002,tmpGrp,-100.0)

One also defines temperature fields by production of a corresponding Result object. In this case, the Result is build from the coordinates:

      # Generation of a temperature gradient field :

      tmpGrp = Group.new
      tmpGrp.setEntities("Node 1:99999")
      tmpGrp.matchWithDbEntities(db)
      db.generateCoordResults

      coords=db.getResultCopy("","","Coordinates","NodesOnly",tmpGrp,[])
      coords.modifyPositionRefCoordSys(db,1001)
      tGradX=coords*[100.0,   0.0,   0.0]
      Therm.writeFieldTempCards("temp_GRAD_X.bdf",623001,tGradX)
      tGradY=coords*[  0.0, 100.0,   0.0]
      Therm.writeFieldTempCards("temp_GRAD_Y.bdf",623002,tGradY)
      tGradZ=coords*[  0.0,   0.0, 100.0]
      Therm.writeFieldTempCards("temp_GRAD_Z.bdf",623003,tGradZ)

Note that the previous ruby lines illustrate the use of several capabilities of FeResPost:

Note that the temperature fields printed in BDF files are used in the definition of loads for Nastran calculations in Chapter IV.1.

The example is provided in file "RUBY/EX07/makeTempFields.rb".

IV.2.5.3 Calculation of a total force and moment

One explains here how the resulting global force and moment can be calculated from distributed force and moments. This example illustrates the use of method “calcResultingFM” in class “Result”.

The ruby function that performs the calculation of the total force and moments looks like follows:

def calcOneGlobFM(db,lcName,scName,elemGrp,nodeGrp,locCS,coords)

   # Target Group :

      targetGrp = Group.new()
      tmpNodeGrp=db.getNodesAssociatedToElements(elemGrp)
      targetGrp = tmpNodeGrp * nodeGrp
      tmpElemGrp=db.getElementsAssociatedToNodes(targetGrp)
      targetGrp += tmpElemGrp * elemGrp

   # Inspecting and reading Results :

      tpNameF = "Grid Point Forces, Internal Forces"
      tpNameM = "Grid Point Forces, Internal Moments"

      tmpF =  db.getResultCopy(lcName,scName,tpNameF,"ElemNodes",targetGrp,[])
      tmpM =  db.getResultCopy(lcName,scName,tpNameM,"ElemNodes",targetGrp,[])

      resFM = Result.calcResultingFM(db,tmpF,tmpM,locCS,coords)
      return resFM

end

The arguments of the function are:

1.

“db”, the DataBase given as argument to “calcResultingFM”.

2.

“lcName”, a String containing the name of the load case for which the results are retrieved.

3.

“scName”, a String containing the name of the sub-case for which the results are retrieved.

4.

“elemGrp”, a Group containing the elements from which one recovers the local forces and moments.

5.

“nodeGrp”, a Group containing the nodes on which the forces will be recovered.

6.

“locCS”, the coordinate system in which results are recovered. Its value can be of integer or CoordSys type.

7.

“coords”, an Array of three Real values containing the coordinates of the recovery point expressed in the coordinate system.

The function builds a Group called “targetGrp” containing the list of elements and nodes on which Grid Point Forces and Moments are recovered. To reduce the computation cost, the targetGrp object contains only the elements and nodes on which the results are recovered. One this Group is defined, one recovers the corresponding Force and Moment fields, and an appropriate call to “Result.calcResultingFM” calculates the resulting total force and moment which are returned by the function.

The main part of the example consists in building the DataBase, loading the Results and performing the calculations for any combination of three load cases and six interfaces. The definition of load cases and interfaces are done as follows:

   lcNames = ["LAUNCH_ONE_MS2_X", "LAUNCH_ONE_MS2_Y", "LAUNCH_ONE_MS2_Z"]
   scName = "Statics"

   interfaces=Array.new()
   interfaces << ["pan_PZ", "fitting_PXMYMZ",1001,[ 0.440000,-0.440, 0.6445]]
   interfaces << ["pan_PZ", "fitting_MXMZ",  1001,[-0.426667, 0.000, 0.6445]]
   interfaces << ["pan_SUP","fitting_MXMYPZ",1002,[ 0.310835,-120.0, 1.4000]]
   interfaces << ["pan_SUP","fitting_PXPZ",  1002,[ 0.310835,   0.0, 1.4000]]
   interfaces << ["pan_SUP","fitting_MXPYPZ",1002,[ 0.310835, 120.0, 1.4000]]
   interfaces << ["pan_PZ", "fitting_PXPYMZ",1001,[ 0.440000, 0.440, 0.6445]]

Then the loops on data are performed, with the calls to “calcOneGlobFM”, and the results are printed:

   for lcName in lcNames
      printf "\n   %s :\n\n",lcName
      for interf in interfaces
         elemGrp = db.getGroupCopy(interf[0])
         nodeGrp = db.getGroupCopy(interf[1])
         cs=interf[2]
         coords=interf[3]

         fm = calcOneGlobFM(db,lcName,scName,elemGrp,nodeGrp,cs,coords)
         f=fm[0]
         m=fm[1]

         printf "%20s%20s%10d%10.3f%10.3f%10.3f%10.3f%10.3f%10.3f\n",\
                   elemGrp.Name,nodeGrp.Name,cs,\
                   f[0],f[1],f[2],m[0],m[1],m[2]
      end
   end
   printf "\n"

Typically, the calculation of global force and moment for a given interface can be used to estimate loads to be used to calculate a detailed model (of a metallic fitting, for example). It can also be used for post-processing (for example to calculate margins of safety for a global sliding of an interface).

The example is provided in file "RUBY/EX10/makeTempFields.rb".

IV.2.5.4 Outputting a Gmsh file

This example illustrates the creation of a Gmsh file for later visualization with Gmsh. The part of the data file specific to the “writeGmsh” function call is as follows:

   # Group creation :

   meshGrp=db.getGroupAllFEM

   targetGrp = db.getGroupCopy("pan_PZ_Al_2024")
   targetGrp2 = db.getGroupCopy("pan_PZ")

   # Stress data in skins :

   stress = db.getResultCopy("TEMP_GRAD_X","Statics",\
      "Stress Tensor","ElemCenters",targetGrp,[])
   stress2 = db.getResultCopy("TEMP_GRAD_X","Statics",\
      "Stress Tensor","ElemCorners",targetGrp,[])

   displ = db.getResultCopy("TEMP_GRAD_X","Statics",\
      "Displacements, Translational","Nodes",targetGrp2,[])
   norm = displ.deriveVectorToOneScal("abs")

   # Stress data in honeycomb :

   targetGrp =tmpGroup_Honey_72
   honeyStress=db.getResultCopy("TEMP_GRAD_X","Statics",\
      "Stress Tensor","ElemCenters",targetGrp,[])

   # Gmsh output :

   db.writeGmshMesh("brol.msh",0,meshGrp,false)
   db.writeGmsh("brol.gmsh",0,[[stress,"stress","ElemCenters"],\
                               [stress2,"stress2","ElemCorners"],\
                               [honeyStress,"honeyStress","ElemCenterPoints"],\
                               [displ,"displ","Nodes"],\
                               [norm,"norm","Nodes"]],\
                              [[db.getGroupCopy("pan_PZ"),"mesh pan_PZ"],\
                               [db.getGroupCopy("pan_MZ"),"mesh pan_MZ"],\
                               [db.getGroupCopy("pan_PX"),"mesh pan_PX"]],\
                              [[meshGrp,"skel sat"]])

Actually, only the last function call is new. The example is provided in file "RUBY/EX11/writeGmsh.rb".

IV.2.6 Saving and retrieving Results from an SQL database

“Result” and “Group” objects can be saved into SQL BLOBs for storing or manipulation in SQL databases. This feature has been introduced to allow the management of persistence of intermediate results calculated with FeResPost.

One proposes here a small example illustrating this feature. The example deals with Nastran dynamic analysis Results that are store into an SQLite database. This type of operation may be handy, as the access to dynamic analysis results from an XDB file may sometimes be very unpractical. In particular, the insertion table is organized in such a way that Results can be accessed separately by subcases.

This example is based on SQLite database system but the adaptation to other SQL database systems should not be a problem. To run the example you must first install the “sqlite3” ruby gem on your computer.

IV.2.6.1 Saving objects in an SQLite database

To use SQLite, one first requires the corresponding ruby gem:

    require "rubygems"
    require "sqlite3"

Then, the database can be created:

    fName="brol.fdb"
    if (File::exists?(fName))
        sqldb = SQLite3::Database.open( fName )
    else
        sqldb = SQLite3::Database.new( fName )
sqldb.execute <<SQL
    PRAGMA auto_vacuum = FULL
SQL
    end

In this case only one SQL table is created in the database. The columns correspond to several data associated with each individual Results, and the BLOB corresponding to the Result itself:

sqldb.execute <<SQL
    CREATE TABLE IF NOT EXISTS dynam_results_1 (
        lcName TEXT,
        scName TEXT,
        resName TEXT,
        tensorOrder INTEGER,
        intId1 INTEGER,
        intId2 INTEGER,
        realId1 REAL,
        realId2 REAL,
        size INTEGER,
        result BLOB,
        PRIMARY KEY(lcName,scName,resName)
    );
SQL

Finally, one loops on xdb attachment Results. For each load case and Result name, one extracts the Results corresponding to each subcase, and inserts it into the database:

    db.attachXdb(xdbFileName)

    lcNames=db.getAttachmentLcNames(xdbFileName)
    scNames=db.getAttachmentScNames(xdbFileName)
    resNames=db.getAttachmentResNames(xdbFileName)

    lcNames.each do |lcName|
        resNames.each do |resName|
            results=db.getAttachmentResults(xdbFileName,lcName,scNames,resName)
            if (results) then
                results.each do |key,res|
                    puts key
                    sqldb.execute( "insert or replace into
                        dynam_results_1 values (?,?,?,?,?,?,?,?,?,?)",
                        lcName,key[1],resName,res.TensorOrder,
                        res.getIntId(0),res.getIntId(1),
                        res.getRealId(0),res.getRealId(1),res.Size,
                        SQLite3::Blob.new(res.toBlob()))
                end
            else
                puts "NO FOR" + lcName + resName
            end
        end

The example is provided in file "RUBY/EX20/rehashDynamicResults.rb"

IV.2.6.2 Retrieving objects from an SQLite database

This example, uses the database created in the example of section IV.2.6.1 and retrieves Results or deletes some of the data. An example of statements that allow to retrieve Results is given below:

    sqldb.query("select * from dynam_results_1 where lcName = ? and realId1 = ?",
            ["SINUS_X",97.0] ).each do |tab|
        puts tab[0],tab[1],tab[2],tab[8]
        res=Post.convertBlob(tab[9])
        puts res.Size()
    end

Items can be deleted from database by statements of this type:

    sqldb.execute("delete from dynam_results_1 where resName = ?",
            "Strain Tensor (RI)" )
    sqldb.execute("delete from dynam_results_1 where resName = ?",
            "Applied Loads, Forces (RI)" )
    sqldb.execute("delete from dynam_results_1 where resName = ?",
            "Applied Loads, Moments (RI)" )
    sqldb.execute("delete from dynam_results_1 where resName = ?",
            "Accelerations, Rotational (RI)" )
    sqldb.execute("delete from dynam_results_1 where resName = ?",
            "Velocities, Rotational (RI)" )
    sqldb.execute("delete from dynam_results_1 where resName = ?",
            "Displacements, Rotational (RI)" )
    sqldb.execute("delete from dynam_results_1 where realId1 < ?",
            90.0 )

The example is provided in file "RUBY/EX20/deleteSomeResults.rb"

IV.2.7 Reading optimization results

One provides here an example for the reading of optimization results. The first steps of the example consists in the creation of a NastranDb object, and the attachment of an XDB file:

    db=NastranDb.new()
    db.Name="tmpDB"
    #~ db.readBdf("../../MODEL/EXEC_XDB/sol200_a.bdf")

    xdbFileName="../../MODEL/EXEC_XDB/sol200_a.xdb"
    #~ xdbFileName="../../MODEL/EXEC_XDB/sol200_b.xdb"
    db.attachXdb(xdbFileName)

Remark, that the reading of the Nastran finite element model from a BDF file is not necessary to access optimization results.

In the Nastran examples, one provides two optimization runs:

The two runs lead to similar kinds of outputs, including the history of design variables. Only, the topometric optimization generates automatically design variables (for example, one variable per element). Then, the numbering of design variables kind by awkward.

The printing of design variables history is done with the following ruby instructions:

    x=db.getAttachmentDesVarHistory(xdbFileName,nil,nil)
    STDOUT.printf("%14s%14s%14s\n","STEP","DVID","VALUE")
    x.each do |tab|
        STDOUT.printf("%14d%14d%14f\n",tab[0],tab[1],tab[2])
    end

In this case, one prints the history of all design variables, and for all steps. (“nil” values are passed for corresponding arguments of the “getAttachmentDesVarHistory” method.) If you do the same with “sol200_b.xdb”, file, you will obtain a very long output as the number of design variables can be very large for topometric optimization.

The definition of constraints is printed as follows:

    x=db.getAttachmentConstrDefinitions(xdbFileName)
    STDOUT.printf("%8s%8s%8s%8s%8s%14s\n","IDCID","DCID","IRID","TYPE","LUFLAG","BOUND")
    x.each do |tab|
        str=""
        if tab[4]==1 then
            str=">"
        elsif tab[4]==2 then
            str="<"
        end
        STDOUT.printf("%8d%8d%8d%8d%8s%14f\n",tab[0],tab[1],tab[2],tab[3],str,tab[5])
    end

And the corresponding histories are obtained as follows:

    x=db.getAttachmentConstrHistory(xdbFileName)
    STDOUT.printf("%8s%8s%14s\n","STEP","IDCID","VALUE")
    x.each do |tab|
        STDOUT.printf("%8d%8d%14f\n",tab[0],tab[1],tab[2])
    end

Here, the history is printed for all optimization steps, as the corresponding parameter is not provided.

And similarly, the objective history is printed as follows:

    x=db.getAttachmentObjectiveHistory(xdbFileName)
    STDOUT.printf("%8s%14s%8s%14s\n","STEP","OBJ.","IRID","Cst. VALUE")
    x.each do |tab|
        STDOUT.printf("%8d%14f%8d%14f\n",tab[0],tab[1],tab[2],tab[3])
    end

You can remark that when a topometric optimization is calculated by Nastran as a design variable optimization. (Nastran defines automatically one design variable per element.)

The example is provided in file "RUBY/EX21/printSol200Infos.rb".

IV.2.8 “Raw” access to XDB file content

In directory “RUBY/EX22”, one presents several examples with Ruby extension that illustrates the raw access to XDB files. (The corresponding examples for COM component and .NET assembly are provided in directories “COMEX/EX13” and “NETEX/EX22”.)

IV.2.8.1 Utilities

In file “dictPrint.rb” one defines two methods that print the list of dictionnary keys, and/or the entire dictionnary. These methods are:

(These two methods are called in the different examples.)

IV.2.8.2 Printing Coordinate System Table Matrix

The example is provided in “RUBY/EX22/recoverCSTM.rb”. The interesting part of the example is the use of the iterator:

db.iter_xdbRaw(xdbFileName,["CSTM",0],"iiffffffffffffifffffffff").each do |tab|
    STDOUT.printf("Coordinate system ID: %d\n",tab[0])
    STDOUT.printf("Coordinate system type: %d\n",tab[1])
    STDOUT.printf("Coordinate system origin (wrt 0): %14g %14g %14g\n",
            tab[2],tab[3],tab[4])
    STDOUT.printf("Coordinate system V1 (wrt 0)    : %14g %14g %14g\n",
            tab[5],tab[6],tab[7])
    STDOUT.printf("Coordinate system V2 (wrt 0)    : %14g %14g %14g\n",
            tab[8],tab[9],tab[10])
    STDOUT.printf("Coordinate system V3 (wrt 0)    : %14g %14g %14g\n",
            tab[11],tab[12],tab[13])
end

Note that the CSTM table correspond to a FEM modeling table and not to a result table. This shows that the raw access to XDB file can be used to access modeling information.

Generally, maximum one table per type is defined in XDB file, if the table corresponds to modeling information. However, this is sometimes different. For example FEM modeling table may correspond to an output of optimization run.

One also presents an example in which the ‘each_xdbBinRaw” iterator is used with “binDataToValues” singleton method to interpret the content of XDB file. The example is provided in “RUBY/EX22/recoverBINRAW.rb” script and its main part looks as follows:

    wdSize=db.getAttachmentWordsSize(xdbFileName)
    bSwap=db.getAttachmentSwapEndianness(xdbFileName)
    policy=0
    if (bSwap) then
        policy=1
    end

    bAutoSwap=true
    cards=[]
    db.each_xdbBinRaw(xdbFileName,["CQD4",0],bAutoSwap) do |str|
        arri=NastranDb.binDataToValues(str,wdSize,"iiiiiiii iiiii".delete(’ ’),policy)
        arrf=NastranDb.binDataToValues(str,wdSize,"iiiiiiff fiiii".delete(’ ’),policy)
    puts arri.size()

        card=["CQUAD4"]+arri
        #~ puts arri,arrf
        cards << card
    end

    NastranDb.writeNastranCards("output.bdf","w","right","wide",cards)

Note that we output the read values into a kind of BDF file, but you will notice that the cards do not really match the corresponding CQUAD4 card definition. you may notice that we also use the getAttachmentWordsSize and getAttachmentSwapEndianness methods to determine the endianness policy for binary data translation.

IV.2.8.3 Accessing results

We give here an example, in which CBAR element forces are read from the XDB file. This is done to illustrate the extraction of element results. Otherwise, there is no practical use to this example, as the corresponding extractions can be done by the “usual” XDB result extraction methods. The example is provided in file “RUBY/EX22/recoverFBAR.rb”.

One first attempts to access the definition of load cases:

db.each_xdbRaw(xdbFileName,["SUBCASES",0],"iiiiiiii") do |tab|
    puts tab
end

str="i"
(0..95).each do |i|
    str+="s"
end
db.each_xdbRaw(xdbFileName,["SUBCTITL",0],str) do |tab|
    STDOUT.printf("%d\n",tab[0])
    (0..2).each do |j|
        str=""
        (1..32).each do |i|
            str+=tab[32*j+i]
        end
        str.strip!
        STDOUT.printf("%s\n",str)
    end
end

The integers extracted from “SUBCASES” table correspond to sub-case integer ID, the corresponding load ID, the SPC ID... The access to “SUBCTITL” shows how strings must be concatenated when they correspond to several words.

The reading of CBAR forces is done as follows:

modulo=-1;
db.each_xdbRaw(xdbFileName,["FBARR",2],"iiiiiiiii") do |tab|
    if (tab[0]==0) then
        modulo=tab[1]
    end
    break;
end
db.each_xdbRaw(xdbFileName,["FBARR",2],"iffffffff") do |tab|
    accessType=12
    if (tab[0]>0) then
        elemIntId=tab[0]/modulo
        elemExtId=db.getAttachmentElementExtId(xdbFileName,accessType,elemIntId)
        STDOUT.printf("%30s : %d\n","Element ID",elemExtId)
        STDOUT.printf("%30s : %g\n","M bending A 1",tab[1])
        STDOUT.printf("%30s : %g\n","M bending A 2",tab[2])
        STDOUT.printf("%30s : %g\n","M bending B 1",tab[3])
        STDOUT.printf("%30s : %g\n","M bending B 2",tab[4])
        STDOUT.printf("%30s : %g\n","F shear 1",tab[5])
        STDOUT.printf("%30s : %g\n","F shear 2",tab[6])
        STDOUT.printf("%30s : %g\n","F axial",tab[7])
        STDOUT.printf("%30s : %g\n\n","M torque",tab[8])
    end
end

One must add a few explanations:

IV.2.8.4 Producing a “clean” model from topometric optimization

We provide here an example where modeling information is read from the XDB file. The modeling information corresponds to the last output of a topometric optimization. The purpose of the script is to produce a “clean” FEM corresponding to the topometric optimization. The example is given in “RUBY/EX22/recoverTopometricModel.rb”.

The reading of PSHELL cards is done as follows:

pshellCards={}
db.each_xdbRaw(xdbFileName,["PSHELL",49],"iifififfffi") do |tab|
    card=[]
    card << "PSHELL"
    (0...10).each do |i|
        if (tab[i].class==Float&&tab[i].nan?) then
            card << ""
        else
            card << tab[i]
        end
    end
    if (tab[10]==0) then
        card << ""
    else
        card << tab[10]
    end
    pshellCards[tab[0]]=card
end

Remark that:

In the rest of the script, one generates renumbered PSHELL cards. Each PSHELL PID will be the same as the element ID of the CQUAD4 that refers to the property. The CQUAD4 elements are modified accordingly. The new Nastran cards are output in “newModel.bdf” file, and a GMSH file corresponding to the modified thicknesses is output:

outputCards=[]
propRemap={}
elemIds=cquad4Cards.keys.sort
elemIds.each do |elemId|
    elemCard=cquad4Cards[elemId].clone
    propId=elemCard[2]
    if propId>1000000 then
        elemCard[2]=elemId
        propRemap[propId]=elemId
    end
    outputCards << elemCard[0..7]
end

propIds=pshellCards.keys.sort
res=Result.new
res.TensorOrder=0
res.Format=1
propIds.each do |propId|
    propCard=pshellCards[propId].clone
    if propRemap.has_key?(propId) then
        propCard[1]=propRemap[propId]
        res.insert([propCard[1]],["NONE",propCard[3]])
    end
    outputCards << propCard[0..8]
end
NastranDb::writeNastranCards("newModel.bdf","w","right","short",outputCards)
#~ Util::printRes($stdout,"brol",res)
db.writeGmsh("thicknesses.gmsh",0,[[res,"thickness","ElemCenters"]])

Note that the example could be improved. For example, you could also consider the CTRIA3 elements in the model generation.

IV.2.8.5 Reading and saving the temperature distributions

In order to calculate laminate load response from the distribution of shell forces and moments, it is sometimes also necessary to know the temperature distribution for each load case.

Example “RUBY/EX22/recoverTEMP.rb” reads the “TEMP” cards from the XDB files and stores them in an SQLite database. More precisely, function “getXdbTemperature”:

Method “saveResultsInSqlite” is used to save the temperature fields into a SQLite database. The table is called “element_temperatures” and associates integer keys (the Nastran temperature load ID) to BLOB objects corresponding to the temperature fields (FeResPost Result object).

These temperature fields can be used in other post-processing scripts to estimate laminate load response analysis from finite element model results. The SQLite database is here called “sqliteResults.db3”.

An example showing how the temperature fields stored in the SQLite database can be used is presented in section VII.4.4.3

IV.2.9 Reading Results From Nastran HDF file

Example “RUBY/EX23/testHDF.rb” illustrates the reading of Nastran HDF file results. First, the library must be loaded:

    Post.loadHdf5Library("C:/NewProgs/HDF5/HDF5-1.8.20-win32/bin/hdf5.dll")

Then, the different methods described in section III.1.1.11 are used to access results stored in the HDF file. In the example below, HDF file is attached to the database, the available load case names, subcase name and result names are retrieved, and some of the Results are read into the database.

    db.attachHdf(hdfName)
    lcNames=db.getHdfAttachmentLcNames(hdfName)
    lcName=lcNames[0]
    scNames=db.getHdfAttachmentScNames(hdfName,lcName)
    scName=scNames[0]
    resNames=db.getHdfAttachmentResNames(hdfName,lcName)
    hdfResNames=resNames.clone

    db.getHdfAttachmentLcInfos(hdfName).each do |info|
        os.printf("%s%30s%8d%8d%14f%14f\n",
            info[0],info[1],info[3],info[4],info[5],info[6])
    end

    db.readHdfAttachmentResults(hdfName,lcName,scName,resNames)

IV.2.10 Raw reading of Nastran HDF file’s content

Example “RUBY/EX26/hdf_dataset_iteration.rb” illustrates the raw reading of Nastran HDF file content. First, the library must be loaded:

    Post.loadHdf5Library("C:/NewProgs/HDF5/HDF5-1.8.20-win32/bin/hdf5.dll")

Then, HDF5 file is attached and different methods are called to obtain information on the content of the file. In particular, one identifies the different Datasets contained in the file, and their characteristics (Compound members, and number of items).

   db.attachHdf(h5Path)
   dsets=db.getHdfAttachmentDataSets(h5Path)
   dsets.each do |dsPath|
       members=db.getHdfAttachmentCompoundMemberNames(h5Path,dsPath)
       nbrLines=db.getHdfAttachmentDataSetNbrItems(h5Path,dsPath)
       printf("%s (%d*%d)\n",dsPath,nbrLines,members.size)
       members.each do |str|
           printf("%20s\n",str)
       end
   end

In the end, one interates on content with insractions as

   db.each_hdfAttachmentNasSetItem(h5Path,dsets[2],iMin,iMax) do |x|
       puts x
       $stdout.printf("\n\n")
   end

The raw reading of Dataset content in an Array is shown in example “TESTSAT/RUBY/EX26/hdf_dataset_array.rb”.

IV.2.11 Superelements

One discusses in this section the example provided in directory “TESTSAT/RUBY/EX27” and that illustrate the management of Results when model contains superelements. (See section III.1.1.3 for the presentation of the theory.)

All the examples presented here are based on the reading of models in directory “TESTSAT/OTHER_EXECS/msc_seug_chapter2_Jet" and of associated results in OP2, XDB or HDF files. The Nastran BDF files have been obtained modifying MSC Nastran example
“doc/seug/chapter2/jet101.dat” in Nastran installation directory. This example is discussed in [Hex22]. Modifications have been done to obtain the OP2, XDB or HDF output files with results associated to the different superelements of the model. The following subsections IV.2.11.1 to IV.2.11.4 explain how the model and corresponding results can be manipulated. The examples presented here have been tested with Python, COM and .NET assembly.

IV.2.11.1 Reading BDF file and accessing superelements

Example “TESTSAT/RUBY/EX27/readBdf.rb” illustrates the reading of superelements from a BDF file, and the identification of the superelements that have been read.

One first examines a NastranDb object, before reading the model from a BDF file:

   db=NastranDb.new()
   printf("db = %s\n",db.to_s)
   printf("   db.SEID = %d\n",db.SEID)
   printf("   db.refCounter = %d\n",db.RefCounter)
   printf("   db.NbrSuperElements = %d\n",db.NbrSuperElements)

These instructions produce the following output:

db = DataBase: 0309CDD8
   db.SEID = -1
   db.refCounter = 1
   db.NbrSuperElements = 0

As no model has been read, the number of superelements in the database is necessarily zero. SEID=-1, because the model is not yet “initialized” (read from a BDF or an OP2 file).

The output is different when our example model is read:

db=NastranDb.new()
db.readBdf(bdfPath)
printf("db = %s\n",db.to_s)
printf("   db.SEID = %d\n",db.SEID)
printf("   db.refCounter = %d\n",db.RefCounter)
printf("   db.NbrSuperElements = %d\n",db.NbrSuperElements)

These instructions produce the following output:

db = DataBase: 030BF618
   db.SEID = 0
   db.refCounter = 1
   db.NbrSuperElements = 8

After reading the model, the SEID is set to 0, which means that “db” points to a master DB (corresponding to residual model). The master database contains 8 superelements.

The following instructions:

   db2=db.getMaster()
   printf("db2 = %s\n",db2.to_s)
   printf("db2.class = %s\n",db2.class.to_s)

lead to the following output:

   db2 =
   db2.class = NilClass

As “db” is a master database, the function “getMaster” returns a “nil” object.

On the other hand, the following instructions:

nbr=db.NbrSuperElements
(0...nbr).each do |pos|
    printf("   pos = %d\n",pos)
    id=db.getSuperElementIdFromPos(pos)
    printf("   id = %d\n",id)
    sdb=db.getSuperElementFromPos(pos)
    if pos==3 then
        sdb3=sdb
        db2=sdb3.getMaster()
    end
    GC.start
    printf("   sdb = %s\n",sdb.to_s)
    printf("   db2 = %s\n",db2.to_s)
    printf("   db.SEID = %d\n",db.SEID)
    printf("   sdb.SEID = %d\n",sdb.SEID)
    if db2 then
        printf("   db2.SEID = %d\n",db2.SEID)
    end
    printf("   refCounter = %d\n",db.RefCounter)
end

produce information for the different superelement databases contained in the master database. For example, for pos=5, the output lines are:

   pos = 5
   id = 12
   sdb = DataBase: 0312C6E0
   db2 = DataBase: 030BF618
   db.SEID = 0
   sdb.SEID = 12
   db2.SEID = 0
   refCounter = 4

“sdb” points to the superelement at position 5 in the list of superelements. Superelement ID is 12. “db2” is the master database of superelement at position 3 in the list of superelements (fourth superelement as first superelement is at position 0). This means that “db2” points to the master database that has been read from the BDF file.

The database references counter is printed at several places in the script. This has been done to check and debug reference counting. It works as expected with ruby extension. Note however that reference counting management is a little more tricky with Python, .NET assembly and COM component. We made some tests to check these and believe there is no program leak related to reference counting.

IV.2.11.2 Superelements and OP2 files

The first test with OP2 files involves the reading of Results only. Test is provided in file “RUBY/EX27/readOp2.rb”.

The NastranDb object is initialized by reading model from BDF file as explained in section IV.2.11.1. One builds a list of superelement IDs as follows:

   nbr=db.NbrSuperElements
   seIds=[0]
   (0...nbr).each do |pos|
       seIds << db.getSuperElementIdFromPos(pos)
   end

Note that the master database with SEID=0 is considered in the seIds Array.

Results are read from an OP2 file:

   printf("\n\n   0) Reading all the results in the DataBase : \n\n")
   db.readOp2(op2FileName,"Results")

The following instructions produce only the title line. No Results are associated to the master database. (This is normal as all GRIDs and elements are defined in superelements and not in the residual model):

   printf("\n\n   A) Getting results from the main database : \n\n")
   db.each_resultKey do |lcName,scName,tpName|
      tmpRes=db.getResultCopy(lcName,scName,tpName)
      printf("%-20s%-25s%-60s%-10d\n",lcName,scName,tpName,tmpRes.Size)
   end

With the following instructions we print the characteristics of Results stored in the master database and all its superelements:

   printf("\n\n   B) Getting all the results from all databases : \n\n")
   seIds.each do |seId|
       currentDb=nil
       if seId>0 then
           currentDb=db.getSuperElementFromId(seId)
       else
           currentDb=db
       end
       printf("currentDb.SEID = %d\n",currentDb.SEID)
       currentDb.each_resultKey do |lcName,scName,tpName|
           res=currentDb.getResultCopy(lcName,scName,tpName)
           $stdout.printf("A) %s - %s - %s : %d\n",lcName,scName,tpName,res.Size)
       end
   end

This produces an output that looks as follows:

   B) Getting all the results from all databases :

   currentDb.SEID = 0
   currentDb.SEID = 1
   B) Load Case 1 - Statics - Applied Loads, Forces : 8
   B) Load Case 1 - Statics - Displacements, Rotational : 88
   B) Load Case 1 - Statics - Displacements, Translational : 88
   B) Load Case 1 - Statics - Reaction Forces, Forces : 5
   B) Load Case 1 - Statics - Reaction Forces, Moments : 5
   B) Load Case 1 - Statics - SPC Forces, Forces : 5
   B) Load Case 1 - Statics - SPC Forces, Moments : 5
   B) Load Case 1 - Statics - Stress Tensor : 256
   currentDb.SEID = 2
   B) Load Case 1 - Statics - Applied Loads, Forces : 20
   B) Load Case 1 - Statics - Displacements, Rotational : 24
   B) Load Case 1 - Statics - Displacements, Translational : 24
   B) Load Case 1 - Statics - Stress Tensor : 32
   currentDb.SEID = 3
   B) Load Case 1 - Statics - Applied Loads, Forces : 18
   ...

Again, no Result is produced for master DB. On the other hand, superelements contain Results that are retrieved from database using “getResultCopy” method.

We end the example by cleaning the results and erasing the NastranDb object:

   db.removeAllResultsAllSE()
   db=nil
   GC.start()

A model can also be read from an OP2 file, even though it is not recommended practice. The “readOp2” can also be used to read both the model and Results:

   db=NastranDb.new()
   db.readOp2(op2FileName,"Model/Results")

We verify in the ruby script that the same Results are associated to the master database and its superelements, and that the superelements are correctly read from the OP2 file.

IV.2.11.3 Getting superelement Results from XDB files

We illustrate how the Results can be retrieved from XDB files when model contains superelements in file “RUBY/EX27/readXdb.rb”. As the model cannot be read from XDB file, database is initialized by reading a BDF file. Results are read into master database and its superelement databases using readXdb method:

   printf("\n\n   0) Reading all the results in the DataBase : \n\n")
   db.readXdb(xdbFileName)

As master database contains no nodes or elements, no Results are associated to master database, and the following lines produce no output, except the title line:

   printf("\n\n   A) Getting results from the main database : \n\n")
   db.each_resultKey do |lcName,scName,tpName|
      tmpRes=db.getResultCopy(lcName,scName,tpName)
      printf("A) %-20s%-25s%-60s%-10d\n",lcName,scName,tpName,tmpRes.Size)
   end

On the other hand, the following lines produce the same output as the corresponding ruby lines in the “OP2” example in section IV.2.11.2:

   printf("\n\n   B) Getting all the results from all databases : \n\n")
   seIds.each do |seId|
       currentDb=nil
       if seId>0 then
           currentDb=db.getSuperElementFromId(seId)
       else
           currentDb=db
       end
       printf("currentDb.SEID = %d\n",currentDb.SEID)
       currentDb.each_resultKey do |lcName,scName,tpName|
           res=currentDb.getResultCopy(lcName,scName,tpName)
           $stdout.printf("B) %s - %s - %s : %d\n",lcName,scName,tpName,res.Size)
           if (res.Name=="Displacements, Translational"||res.Name=="Stress Tensor") then
               if (bDebug) then
                   str=format("%s on SEID %d",res.Name,seId)
                   Util::printRes($stdout,str,res)
               end
           end
       end
   end

XDB files can be attached to a NastranDb object:

   printf("\n\n   1) Attaching XDB file to the database : \n\n")
   db.attachXdb(xdbFileName)

Then, information can be retrieved from XDB file, as is done when no superelement is present in the model. This information can be dependent on the superelement too, so that corresponding superelement database must be used to obtain the information. For example:

   sdb3=db.getSuperElementFromId(3)
   puts sdb3.getAttachmentNodeInfo(xdbFileName,1)
   puts sdb3.getAttachmentNodeInfo(xdbFileName,2)
   puts sdb3.getAttachmentNodeInfo(xdbFileName,3)
   puts sdb3.getAttachmentElementExtId(xdbFileName,7,1)
   puts sdb3.getAttachmentElementExtId(xdbFileName,7,5)
   puts sdb3.getAttachmentElementExtId(xdbFileName,7,8)

Remark that the XDB file is attached to master database, but accessed from one of the superelement database.

One obtains information from XDB attachment calling different methods from “db” object:

   printf("\n\n   C) Attachment information : \n\n")
   db.getAttachmentLcInfos(xdbFileName).each do |info|
       $stdout.printf("%s%30s%8d%8d%14f%14f\n",
           info[0],info[1],info[3],info[4],info[5],info[6])
   end
   $stdout.printf("nbr load cases = %d\n",db.getAttachmentNbrLoadCases(xdbFileName))
   lcNames=db.getAttachmentLcNames(xdbFileName)
   scNames=db.getAttachmentScNames(xdbFileName)
   resNames=db.getAttachmentResNames(xdbFileName)
   puts lcNames,scNames,resNames

Previous lines produce the following output:

      C) Attachment information :

   Load Case 1                       Statics       1     101     -1.000000     -1.000000
   nbr load cases = 1
   Load Case 1
   Statics
   Applied Loads, Forces
   Applied Loads, Moments
   Displacements, Rotational
   Displacements, Translational
   Reaction Forces, Forces
   Reaction Forces, Moments
   SPC Forces, Forces
   SPC Forces, Moments
   Stress Tensor

Note that tree “lcNames”, “scNames” and “resNames” Arrays are filled by these instrutions. These arrays are used later in the rest of the script.

Again, no Results can be obtained from the master database, so that the following lines produce no output except the title line:

   printf("\n\n   D) Getting Attachment results from the main database : \n\n")
   lcNames.each do |lcName|
       scNames.each do |scName|
           resNames.each do |resName|
               h=db.getAttachmentResults(xdbFileName,lcName,scName,resName)
               if (h) then
                   h.each do |key,res|
                       str1,str2,str3=key
                       $stdout.printf("D) SEID %d - %s - %s - %s : %d\n",db.SEID,str1,str2,str3,res.Size)
                   end
               end
           end
       end
   end

On the other hand, the following lines output Results obtained using “getAttachmentResults” for the superelement databases:

   printf("\n\n   E) Getting Attachment results from all databases : \n\n")
   seIds.each do |seId|
       currentDb=nil
       if seId>0 then
           currentDb=db.getSuperElementFromId(seId)
       else
           currentDb=db
       end
       printf("currentDb.SEID = %d\n",currentDb.SEID)
       lcNames.each do |lcName|
           scNames.each do |scName|
               resNames.each do |resName|
                   h=currentDb.getAttachmentResults(xdbFileName,lcName,scName,resName)
                   if (h) then
                       h.each do |key,res|
                           str1,str2,str3=key
                           $stdout.printf("E) SEID %d - %s - %s - %s : %d\n",currentDb.SEID,str1,str2,str3,res.Size)
                       end
                   end
               end
           end
       end
   end

In the same script, one also outputs the characteristics of Results obtained by calling the method “readXdb2H” on master and superelement databases.

IV.2.11.4 Getting superelement Results from HDF files

As far as Results extraction is concerned, the behaviour of HDF read or attachment functions is very similar to the behaviour of corresponding XDB functions. For example in “RUBY/EX27/readHdf5.rb” script, one prints characteristics of Results obtained from an HDF attachment and from different superelements with the following instructions:

   printf("\n\n   E) Getting Attachment results from all databases : \n\n")
   seIds.each do |seId|
       currentDb=nil
       if seId>0 then
           currentDb=db.getSuperElementFromId(seId)
       else
           currentDb=db
       end
       printf("currentDb.SEID = %d\n",currentDb.SEID)
       lcNames.each do |lcName|
           scNames.each do |scName|
               resNames.each do |resName|
                   h=currentDb.getHdfAttachmentResults(hdfName,lcName,scName,resName)
                   if (h) then
                       h.each do |key,res|
                           str1,str2,str3=key
                           $stdout.printf("E) SEID %d - %s - %s - %s : %d\n",currentDb.SEID,str1,str2,str3,res.Size)
                       end
                   end
               end
           end
       end
   end

IV.2.12 Other tests

Most of the “Other tests” have been written to check new developments at some time. They are kept in the list of examples distributed with FeResPost as they illustrate FeResPost capabilities and allow to check new versions of FeResPost.

IV.2.12.1 Reading RBE Results with Lagrange option

In the two examples in directory “RUBY/EX24”, we test the correct reading of MPC Forces and MPC Moments when Nastran “Lagrange” option is used for the analysis.

IV.2.12.2 Reading nonlinear analysis Results from HDF5 files

In example “RUBY/EX25/readNonLinear.rb”, we test the reading of nonlinear Results from HDF5 files.

IV.2.12.3 Testing MPC Results

In Examples of directory “RUBY/EX28”, one verifies that the reading of Results at “MPCs” and “MPCNodes” works. This was necessary since on distinguishes MPCs and RBEs in version 5.0.0.

IV.2.13 CBEAM and CBAR intermediate stations

In example “RUBY/EX29/writeGmsh.rb”, one tests the reading of beam stations from BDF files, the correct association of Result key to station node Ids when Results are read from an OP2 file, and the production of GSM Result files at an appropriate output location. To do this, a modifie FEM has been created in “../../MODEL/EXEC_OP2/unit_xyz_stations.bdf”. This FEM includes a modified definition of struts that define different version of intermediate stations for CBAR elements (with CBARAO cards), or CBEAM elements (with appropriate definitions of PBEAML or PBEAM properties).

The GMSH output allows to verify that GMSH markes are generated at the appropriate locations. This is done by plotting Beam Moments in the struts:

    strutsGrp=db.getGroupCopy("struts_ALL")
    strutsMoments=db.getResultCopy("LAUNCH_ONE_MS2_X","Statics",\
        "Beam Moments","Elements",strutsGrp,[])
    strutsMoments=strutsMoments*[1.0,0.0,0.0]
    Util::printGrp($stdout,"struts",strutsGrp)
    Util::printRes($stdout,"Beam Moments",strutsMoments)

    ...

    db.writeGmsh("brol.gmsh",0,[[stress,"stress","ElemCenters"],\
                                [stress2,"stress2","ElemCorners"],\
                                [honeyStress,"honeyStress","ElemCenterPoints"],\
                                [strutsMoments,"beamMoments","ElemNodePoints"],\
                                [displ,"displ","Nodes"],\
                                [norm,"norm","Nodes"]],\
                                [[db.getGroupCopy("pan_PZ"),"mesh pan_PZ"],\
                                [db.getGroupCopy("pan_MZ"),"mesh pan_MZ"],\
                                [db.getGroupCopy("pan_PX"),"mesh pan_PX"]],\
                                [[meshGrp,"skel sat"]],false)

In example “RUBY/EX29/readOp2.rb”, one verifies if the reading of model from OP2 file supports correctly the intermediate stations in CBEAM and CBAR elements. Remember however that reading FEM fronm OP2 file is not recommended. Reading BDF files is safer.

Note that another test for the correct interpretation of the intermediate stations is also done in the post-processing project discussed in chapter IV.4. Then, the purpose is to check whether the post-processing is correct when connections are modelled with CBAR, CBEAM or CBUSH elements and one extracts the corresponding Beam Forces and Beam Moments. Corresponding load cases, envelopes and Results are suffixed with “MOD” to distinguish this test from more normal calculations.

Chapter IV.3
Using the composite classes

One presents here small examples illustrating the use of FeResPost composite classes. As the classes are still under construction, the examples might be modified in future versions of the program. Also, additional examples will be presented when new feature of the composite classes are available.

IV.3.1 Importing and exporting data

The first examples are presented in directory “TESTSAT/RUBY/EX12” and illustrate the importation of data, and the saving of data.

One example is contained in file “testNeutral.rb”. The three first instructions, create a “ClaDb” object and initialize it by reading the ESAComp file “test.edf”. Then the content of the ClaDb object is saved into a neutral file.

   dbA=ClaDb.new
   dbA.readEdf("test.edf")
   dbA.writeNeutral("NeutralA.ndf")

Then, a new “ClaDb” object is created and initialized by reading the previously created neutral file.

   dbB=ClaDb.new
   dbB.readNeutral("NeutralA.ndf")
   dbB.writeNeutral("NeutralB.ndf")

We advise the reader to read and compare the two neutral files. A comparison with ESAComp file might be useful too.

Another example illustrates the possibility of defining a composite database corresponding to the materials and laminates defined in a finite element model. The example is programmed in file “testNastran.rb”. The model DataBase is produced “as usual”. Then the corresponding ClaDb object is returned:

   compDb=db.getClaDb

Finally, the composite database is saved in “nast.ndf” neutral file:

   compDb.writeNeutral("nast.ndf")

(In this case, the database is not a very interesting one because only one laminate is defined, and it is not a very interesting one.)

IV.3.2 Manipulating composite entities

The example illustrates the manipulation of objects of the classes defined in FeResPost. The example is presented in directory “TESTSAT/RUBY/EX12”, in file “testCla.rb”.

One first creates a ClaDb and initializes it by reading an ESAComp data file:

   db=ClaDb.new
   db.Id="testDB"
   db.readEdf("test.edf")

Then, a new ClaMat “mat1” is created. Its data are initialized by calls to the appropriate methods, and the material is inserted into the ClaDb:

   mat1=ClaMat.new
   mat1.Id="mat1"
   mat1.Type="isotropic"
   mat1.fillModuli({"E"=>72e9,"nu"=>0.33})
   mat1.fillCTEs({"alfa"=>2.3e-5})
   db.insertMaterial(mat1)

The ClaMat object previously stored into the ClaDb is retrieved into “mat2” variable. The material stiffness matrix is requested and its components are printed:

   mat2=db.getMaterialCopy("mat1")
   stiffMat = mat2.getStiffness
   printf("\n\n   stiffMat:\n\n")
   stiffMat.each do |line|
      line.each do |cell|
         printf("%14g",cell)
      end
      printf("\n")
   end

(Similarly, the compliance matrix is printed for the same material.) The following instructions illustrate the creation of a ClaLam object that is stored in the ClaDb:

   lam=ClaLam.new
   lam.Id="testLam"
   lam.addPly( 1,"mat1",0.00037,  0.0,30e6)
   lam.addPly( 2,"mat1",0.00037, 45.0,30e6)
   lam.addPly( 3,"mat1",0.00037,-45.0,30e6)
   lam.addPly( 4,"mat1",0.00037, 90.0,30e6)
   lam.addPly(15,"mat1",0.00037, 90.0,30e6)
   lam.addPly( 6,"mat1",0.00037,-45.0,30e6)
   lam.addPly( 7,"mat1",0.00037, 45.0,30e6)
   lam.addPly( 8,"mat1",0.00037,  0.0,30e6)
   lam.addPly(16,"mat1",0.00037,  0.0,30e6)
   db.insertLaminate(lam)

Then, characteristics of the laminate like the stiffness and compliance matrices are printed. the following lines illustrate the printing of the laminate ABBD (stiffness) matrix:

   ABBD = lam.get_ABBD
   printf("\n\n   ABBD:\n\n")
   ABBD.each do |line|
      line.each do |cell|
         printf("%14g",cell)
      end
      printf("\n")
   end

Note that the quantities can be printed in any direction wrt laminate axes. For example, the following lines illustrate the printing of laminate thermal expansion coefficient in direction 45 wrt laminate axes:

   alfaEh1 = lam.get_alfaEh1(45.0)
   printf("\n\n   alfaEh1 (45o):\n\n")
   alfaEh1.each do |cell|
      printf("%14g\n",cell)
   end

Similarly, the vector {α0ϵ} is printed. Finally, the ClaDb is saved into a neutral file. (This neutral file “test.ndf” is used in the other composite examples.)

IV.3.3 Composite thermal properties

The example illustrates the calculation of laminate thermal properties. The example is presented in directory “TESTSAT/RUBY/EX12”, in file “testClaTherm.rb”.

The following statements correspond to the introduction of isotropic thermal properties in a material:

   mat1=ClaMat.new
   mat1.Id="mat1"
   mat1.Type="isotropic"
   mat1.fillThermalData({"lambdaT"=>170.0,"rho"=>2700.0,"Cp"=>17.0})
   db.insertMaterial(mat1)

similarly, one defines an anisotropic material as follows:

   mat1=ClaMat.new
   mat1.Id="mat_aniso"
   mat1.Type="anisotropic"
   mat1.fillThermalData({"lambdaT1"=>170.0,"lambdaT2"=>17.0,
      "lambdaT3"=>17.0,"lambdaT12"=>0.0,"lambdaT23"=>0.0,
      "lambdaT31"=>0.0,"rho"=>50.0,"Cp"=>17.0})
   db.insertMaterial(mat1)

The thermal properties stored in a ClaMat object can be printed with the following statements:

   lambdaMat = mat2.getInPlaneLambdaT
   printf("\n\n   lambdaMat:\n\n")
   lambdaMat.each do |line|
      line.each do |cell|
         printf("%14g",cell)
      end
      printf("\n")
   end
   printf("\n")
   printf("   rho = %g\n",mat2.getRho)
   printf("   Cp = %g\n",mat2.getCp)
   printf("   rho * Cp = %g\n",mat2.getRhoCp)

One also defines a method that calculates and prints laminate thermal properties:

   def writeLamThermalProperties(os,lam,db)
      lam.calcLaminateProperties(db)
      mat = lam.get_LambdaT
      os.printf("\n\n   LambdaT:\n\n")
      mat.each do |line|
         line.each do |cell|
            os.printf("%14g",cell)
         end
         os.printf("\n")
      end
      os.printf("\n   R33T = %g\n",lam.get_R33T)
      os.printf("   RhoCpH = %g\n",lam.get_RhoCpH)
   end

This method is called with the following statement:

   writeLamThermalProperties(STDOUT,lam,db)

IV.3.4 Extending composite classes

In the example of section IV.3.2, one illustrated basically how the composite classes and their methods can be used to calculate composite properties. The example involved the printing of matrices and vectors corresponding to material or laminate properties.

To write the ruby lines devoted to the printing or manipulation of composite entities can be tedious because it is a repetitive task. As for many users, the same composite results are often requested, this may justify the development of Modules or Classes devoted to the most common operations.

One illustrates in this section the extension of the composite classes and of its classes. All these examples are to be found in “TESTSAT/RUBY/EX13” directory.

IV.3.4.1 Extension “extendedCLA.rb”

Presently, only “ClaMat” and “ClaLam” classes have been modified in “extendedCLA.rb”.

IV.3.4.1.1 Modification of “ClaLam” class

One adds methods devoted to the printing of stiffness and compliance matrices, laminate engineering constants... The list of these functions include:

Each of these diagnostic functions has two arguments: an ostream object corresponding to the File in which Results are printed, and a Real value corresponding to the angle wrt laminate axes for which the diagnostic is to be written. The following lines show the programming of “write_engineering” method:

   class ClaLam

      ...

      def write_engineering(os,theta=0.0)
         constants=get_engineering(theta)
         tab=["E_xx", "E_k0_xx", "E_f_xx",\
              "E_yy", "E_k0_yy","E_f_yy",\
              "G_xy", "G_k0_xy", "G_f_xy",\
              "nu_xy", "nu_k0_xy", "nu_f_xy",\
              "nu_yx", "nu_k0_yx", "nu_f_yx",\
              "G_xz", "G_yz"]
         counter=0
         tab.each do |elem|
            if (counter.modulo(3)==0) then
               os.printf("   ")
            end
            str=format("%s = %11g",elem,constants[elem])
            os.printf("%25s",str)
            counter+=1
            if (counter.modulo(3)==0||counter==tab.size) then
               os.printf("\n")
            end
         end
      end

      ...

   end # class ClaLam

The programming of the other diagnostic methods is very similar to this one.

The following method writes the laminate load response at laminate level (i.e. no ply results):

    def write_loadResponse(os,theta=0.0)
        if (!isMechanicalLoadingDefined()) then
            raise "No load response has been calculated."
        end

        if (isThermalLoadingDefined()) then
            deltaT=getDeltaT
            os.printf("   %14s%14g\n","deltaT",deltaT)
            t0=getT0()
            os.printf("   %14s%14g\n","T0",t0)
            gradT=getGradT
            os.printf("   %14s%14g\n\n","gradT",gradT)
        end

        if (isMoistureLoadingDefined()) then
            deltaH=getDeltaH
            os.printf("   %14s%14g\n","deltaH",deltaH)
            h0=getH0
            os.printf("   %14s%14g\n","H0",h0)
            gradH=getGradH
            os.printf("   %14s%14g\n\n","gradH",gradH)
        end

        os.printf("   %30s%14s%14s%14s\n","type","XX","YY","XY")
        f=getNormalForces(theta)
        m=getMoments(theta)
        s=getNormalStrains(theta)
        c=getCurvatures(theta)
        os.printf("   %30s%14g%14g%14g\n","Normal Forces",f[0],f[1],f[2])
        os.printf("   %30s%14g%14g%14g\n","Moments",m[0],m[1],m[2])
        os.printf("   %30s%14g%14g%14g\n","Normal Strains",s[0],s[1],s[2])
        os.printf("   %30s%14g%14g%14g\n","Curvatures",c[0],c[1],c[2])
        f=getAverageInPlaneStresses(theta)
        m=getFlexuralStresses(theta)
        s=getAverageInPlaneStrains(theta)
        c=getFlexuralStrains(theta)
        os.printf("   %30s%14g%14g%14g\n","Average in-plane stresses",f[0],f[1],f[2])
        os.printf("   %30s%14g%14g%14g\n","Flexural stresses",m[0],m[1],m[2])
        os.printf("   %30s%14g%14g%14g\n","Average strains",s[0],s[1],s[2])
        os.printf("   %30s%14g%14g%14g\n","Flexural in-plane strains",c[0],c[1],c[2])

        os.printf("\n   %30s%14s%14s\n","type","XZ","YZ")
        q=getShearForces(theta)
        g=getShearStrains(theta)
        os.printf("   %30s%14g%14g\n","Shear Forces",q[0],q[1])
        os.printf("   %30s%14g%14g\n","Shear Strains",q[0],q[1])
        q=getAverageShearStresses(theta)
        g=getAverageShearStrains(theta)
        os.printf("   %30s%14g%14g\n","Average shear stresses",q[0],q[1])
        os.printf("   %30s%14g%14g\n","Average shear strains",g[0],g[1])
   end

Again, in this case, the method has two arguments. Indeed, the components of Laminate load response can be obtained in any direction. Note that this method gives sensible results, only if the “calcResponse” method has been called on the ClaLam object. This remark is valid for all the methods that return information related to a peculiar loading.

The method “write_PliesInPlaneStrainsAndStresses” has only one argument and writes plies in-plane stresses and strains:

    def write_PliesInPlaneStrainsAndStresses(os)
        if (!isMechanicalLoadingDefined()) then
            raise "No load response has been calculated."
        end

        epsTab=getPliesStrains
        sigTab=getPliesStresses
        epsMechTab=getPliesMechanicalStrains
        os.printf("   %8s%5s","layer","loc")
        os.printf("%14s%14s%14s","eps_11","eps_22","gamma_12")
        os.printf("%14s%14s%14s","sig_11","sig_22","sig_12")
        os.printf("%14s%14s%14s","eps_mech_11","eps_mech_22","gamma_mech_12")
        os.printf("\n")
        (0...epsTab.size).each do |i|
            os.printf("   %8d%5s",epsTab[i][0],epsTab[i][1])
            os.printf("%14g%14g%14g",epsTab[i][2],epsTab[i][3],epsTab[i][7])
            os.printf("%14g%14g%14g",sigTab[i][2],sigTab[i][3],sigTab[i][7])
            os.printf("%14g%14g%14g",epsMechTab[i][2],epsMechTab[i][3],epsMechTab[i][7])
            os.printf("\n")
        end
    end

One also defines methods “write_PliesTemperatures” and “write_PliesMoistures” that write thermal and hygrometric laminate states at ply level. These methods are very similar to “write_PliesInPlaneStrainsAndStresses”.

Correspondingly, the ply failure indices and reserve factors can be calculated and written:

   def write_crit(os,db,criteria,fos=1.0)
        if (!isMechanicalLoadingDefined()) then
            raise "No load response has been calculated."
        end

        if (db==nil) then
            sdRes=getDerived(criteria)
            fiRes=getFailureIndices(criteria)
            rfRes=getReserveFactors(criteria,fos)
        else
            sdRes=getDerived(db,criteria)
            fiRes=getFailureIndices(db,criteria)
            rfRes=getReserveFactors(db,criteria,fos)
        end

        ...
   end

This last method has several arguments:

1.

“os” specifies where the results are written.

2.

“db” is the ClaDb that is used to calculate failure indices and reserve factors. This argument may be necessary to retrieve plies material allowables and calculate the failure indices. If the argument is nil, then the laminate allowables are used to estimate failure indices.

3.

“criteria” is an Array of strings corresponding to the criteria for which reserve factors and failure indices are requested.

4.

“fos” is an optional argument corresponding to the factor of safety used in the calculation of reserve factors. Its default value is 1.

Note that all the methods added to the ClaLam class perform write operations only. Obviously, methods returning values can also be defined and will ultimately be more useful. But the examples above show that FeResPost is highly customizable and can be adapted to the needs of nearly any user. For example, it should be possible to interface it with graphical packages like ImageMagick or Gnuplot, or with spreadsheets like excel through the win32ole package. Using the Tcl/Tk, it should even be possible to create an interactive program with graphical interfaces.

IV.3.4.1.2 Modification of “ClaMat” class

Similarly, in “ClaMat” class, several printing methods have been defined. A list of these methods follows:

Each of these methods has two arguments: an output stream object, and an optional angle θ. (Its default value is 0.)

IV.3.4.2 A very simple example of use

The following example illustrates the use of the new methods in ClaLam class:

require "FeResPost"
require "extendedCLA"
include FeResPost

   db=ClaDb.new
   db.Id="testDB"
   db.readEdf("test.edf")

   lam=db.getLaminateCopy("testLam2")
   ld=db.getLoadCopy("testFM")
   theta=10.0

   lam.calcResponse(db,theta,ld,true,false,true)
   lam.write_loadResponse(STDOUT,theta)
   lam.write_loadResponse(STDOUT,0.0)

   STDOUT.printf("\n")
   lam.write_PliesInPlaneStrainsAndStresses(STDOUT)
   STDOUT.printf("\n")

The main steps of the example are the following:

1.

One first requests the “FeResPost” module and the “extendedCLA” extension of the ClaLam class.

2.

A ClaDb object is created and initialized as usual.

3.

Then, one retrieves the laminate “testLam2” and the load “testFM” from the ClaDb.

4.

The laminate load response is calculated and some results are printed. (Note that the calculation of laminate load response is done first by the call to “calcResponse”.)

The example is contained in the ruby program file “testCla.rb”.

IV.3.4.3 Properties of the laminates defined in an ESAComp file

The second example, defined in file “testCla2.rb” illustrates the use of a iterators. For each laminate defined in a ClaDb, one prints several properties. These properties are printed in several directions by rotations of 30o. Part of the program is reproduced below:

def diagnostic(edfName,os)

   db=ClaDb.new
   db.Id="testDB"
   db.readEdf("test.edf")

   db.each_laminate do |lamId,lam|
      (0..360).step(30) do |i|
         theta=1.0*i

         os.printf("\nlaminate = \"%s\" -- theta = %g\n\n",lamId.to_s,theta)

         os.printf("\n   Stiffness matrix : \n\n");
         lam.write_ABBD(os,theta)
         os.printf("\n");

         ...
      end
   end
end

os=File.open("test.txt","w")
diagnostic("test.edf",os)
os.close

IV.3.4.4 Properties of the laminates defined in an ESAComp file

The third example, defined in file “testCla3.rb” illustrates the creation of a ClaLoad object and the calculation of corresponding ply stresses and strains. It is reproduced extensively below:

require "FeResPost"
require "extendedCLA"
include FeResPost

   db=ClaDb.new
   db.Id="testDB"
   db.readEdf("test.edf")

   tmpLoad=ClaLoad.new
   tmpLoad.Id="testF0T"
   tmpLoad.setT(20.0)
   tmpLoad.setMembrane([0.03,0.0,0.1],"SC","SC","SC")
   tmpLoad.setFlexural([0.000000e+00,0.000000e+00,0.000000e+00],"SC","SC","SC")
   tmpLoad.setOutOfPlane([100.0,200.0],"FM","FM")

   lam=db.getLaminateCopy("testLam2")
   lam.setAllPliesIlss(3.0e+7)
   lam.setLaminateIlss(3.0e+7)

   theta=45.0
   lam.calcResponse(db,theta,tmpLoad,true,false,true)
   lam.write_loadResponse(STDOUT,theta)
   STDOUT.printf("\n")
   lam.write_loadResponse(STDOUT,0.0)
   STDOUT.printf("\n")

   lam.write_PliesInPlaneStrainsAndStresses(STDOUT)
   STDOUT.printf("\n")
   lam.write_PliesTemperatures(STDOUT)
   STDOUT.printf("\n")

   criteria=["Tresca2D","VonMises2D","MaxStress","MaxStrain",\
      "TsaiHill","TsaiWu","Hoffman","Puck","Puck_b","Puck_c",\
      "Hashin","YamadaSun","CombStrain2D","Ilss"]
   lam.write_crit(STDOUT,db,criteria)
   STDOUT.printf("\n")

This example has been used for mainly debugging composite classes. It illustrates the calculation of failure indices, reserve factors and equivalent stresses in a laminate for a given loading. The reader should examine carefully the result for interlaminar shear.

Note that some criterion may give infinite or NaN values because all the material allowables have not been initialized. (See for example the failure indices of Tresca and Von Mises criteria.)

IV.3.4.5 Properties of the materials defined in an ESAComp file

Another example defined in file “testCla4.rb” illustrates the printing of material matrices and vectors as a function of the orientation. The most important lines look as follows:

   mat=db.getMaterialCopy("testPly2")

   (0..360).step(15) do |iAngle|
      theta=1.0*iAngle
      STDOUT.printf("Angle = %g\n\n",theta)

      STDOUT.printf("   In-plane compliance matrix :\n\n")
      mat.write_InPlaneCompliance(STDOUT,theta)
      STDOUT.printf("\n")

      STDOUT.printf("   In-plane alfa*E :\n\n")
      mat.write_InPlaneAlfaE(STDOUT,theta)
      STDOUT.printf("\n")

      STDOUT.printf("   In-plane alfa :\n\n")
      mat.write_InPlaneAlfa(STDOUT,theta)
      STDOUT.printf("\n")

      STDOUT.printf("   Out-of-plane compliance matrix :\n\n")
      mat.write_OOPSCompliance(STDOUT,theta)
      STDOUT.printf("\n")

      STDOUT.printf("\n")
   end

IV.3.5 Out-of-plane laminate shear response

The first example is presented in directory “TESTSAT/RUBY/EX14” and illustrates the out-of-plane shear calculations. The example is contained in file “testShear.rb”. This example has been developed for debugging purposes and is meant to compare the results of FeResPost with those of ESAComp. After some research one identified what ESAComp does and reproduced its behavior with FeResPost.

One first defines a function that calculations the ESAComp components of out-of-plane shear stiffness matrix kA_44, kA_55, kA_45:

   def getESACompG(db,lam,theta)
      tmpLam=ClaLam.new
      tmpLam.Id="tmpLam"
      lam.each_ply do |plyIndex,plyData|
         tmpLam.addPly(plyIndex,plyData[1],plyData[2],\
                       plyData[3]+theta,plyData[4])
      end
      tmpLam.calcLaminateProperties(db)
      shearMat=tmpLam.get_G
      ret={"kA_44"=>shearMat[1][1], "kA_55"=>shearMat[0][0],\
           "kA_45"=>shearMat[0][1]}
   end

The arguments of the function are:

The function returns a Hash containing the components of shear stiffness matrix associated to their names. The function works as follows: one defines a new ClaLam identical to the argument ClaLam, except that all the plies are rotated by the θ argument angle. Then the laminate properties are calculated and the stiffness matrix components are extracted at 0o (default direction in laminate axes for extraction function get_G).

Similarly, one defines a function supposed to return similar values in a more “classical” way (according to FeResPost philosophy):

   def getNormalG(db,lam,theta)
      lam.calcLaminateProperties(db)
      shearMat=lam.get_G(theta)
      ret={"kA_44"=>shearMat[1][1], "kA_55"=>shearMat[0][0],\
           "kA_45"=>shearMat[0][1]}
   end

The methods “getESACompG” and “getNormalG” are used to print the components of shear stiffness matrix according to the two calculation methods and as a function of the orientation θ. For example, one prints the ESAComp results with the following ruby lines:

   os.printf("\n")
   os.printf("Laminate stiffness as a function of theta :\n\n")
   os.printf("%14s%14s%14s%14s\n","Theta","kA_44","kA_55","kA_45")
   (-90..90).step(5) do |i|
      theta=1.0*i
      ret=getESACompG(db,lam,theta)
      os.printf("%14d%14g%14g%14g\n",i,ret["kA_44"],ret["kA_55"],\
                   ret["kA_45"])
   end
   os.printf("\n\n")

One observes differences between the results obtained with “getESACompG” and “getNormalG”:

1.

Note that in the “ESAComp” version the angle θ is the angle by which the laminate is rotated. In the “Normal” version, it is the angle at which the shear stiffness components are recovered (angle wrt laminate axes). So the ESAComp results for an angle θ should be compared to the “Normal” results for an angle - θ. However in this case the dependence on θ is even and no difference can be observed.

2.

For angles θ other than - 90o, 0o or 90o, the results obtained with “getESACompG” and “getNormalG” are different. This difference is explained by the approximation:

Qxz = Mxx,x,
(IV.3.1)

Qyz = Myy,y,
(IV.3.2)

that has been done in section II.1.6.3. The example illustrates one of the consequences of the approximation: the loss of objectivity in out-of-plane shear equations.

One also performs the calculation of out-of-plane shear stresses in laminate for a simple loading in three different directions: - 45o, 0o or 45o. Here again the loading is applied in two ways: with the “ESAComp” method or the “Normal” one. For example, the printing of ply stresses with “ESAComp” method is done as follows:

    def writeESACompShearStresses(os,db,lam,theta,ld)
        tmpLam=ClaLam.new
        tmpLam.Id="tmpLam"
        lam.each_ply do |plyIndex,plyData|
        tmpLam.addPly(plyIndex,plyData[1],plyData[2],\
            plyData[3]+theta,plyData[4])
        end

        tmpLam.calcLaminateProperties(db)
        tmpLam.calcResponse(db,0.0,ld,true,false,true)
        sigTab=tmpLam.getPliesStresses
        os.printf("   %8s%5s%14s%14s\n","Ply","Pos.","tau_13","tau_23")
        (0...sigTab.size).each do |i|
            os.printf("   %8d%5s",sigTab[i][0],sigTab[i][1])
            os.printf("%14g%14g",sigTab[i][6],sigTab[i][5])
            os.printf("\n")
        end
    end

The loading applied to laminate is defined by a pure out-of-plane shear force components Qxz = 1000000 and Qyz = 0. One also defines a corresponding loading rotated by 45o and defined by its components Qxz = Qyz = 707107. This new loading is tested for direction θ = 0o only. The ply stress results obtained with the different versions of loading and calculations methods can be compared and the following comments are made:

1.

Here again, the “ESAComp” results are obtained by rotating the laminate by an angle θ. For “Normal” results, the loading is rotated by an angle θ. Therefore “ESAComp” results at θ = -45o are to be compared to “Normal” results at θ = 45o (and vice versa).

2.

When θ = 0o, “ESAComp” results and “Normal” results for a same loading are identical. Otherwise, one observes difference between “ESAComp” results at θ = -45o “Normal” results at θ = 45o (and reversely).

3.

For “Normal” calculation method the loading ld45 at θ = 0o gives the same results as ld at θ = 45o. For “ESAComp” calculation method the loading ld45 at θ = 0o does not give the same results as ld at θ = -45o. “Normal” calculation method is more in line with usual expectations.

Actually, none of the two calculation methods can be considered as better than the other. (At least, as far as the precision of results is concerned.) We think however that “Normal” calculation method is better because it is likely to give unexpected results as shown in the example. Moreover, the associated computation cost is lower. (This will be important when finite element results are post-processed.) Note however, that the “Normal” calculation method also suffers from a lack of objectivity wrt to ply orientations in the laminate.

IV.3.6 Producing composite finite element Results

The examples presented in this section are presented in directory “TESTSAT/RUBY/EX15”.

One presents here an example in which composite classes interact with finite element Result class. One first defines a “bottom” Group containing four elements of the bottom panel, which has a PCOMPG property. A load object, some components of which correspond to finite element Results is defined:

   ld=ClaLoad.new
   ld.Id="testLoad"
   ld.setMembrane([0.03,0.0,0.1],"femFM","femSC","femFM")
   ld.setFlexural([0.0,0.0,0.0],"femFM","femSC","femSC")
   ld.setOutOfPlane([100.0,200.0],"femFM","femFM")

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Shell Forces",
                        "ElemCenters",bottom,[])
   res.modifyRefCoordSys(db,"lamCS")
   ld.setShellForces(res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Shell Moments",
                        "ElemCenters",bottom,[])
   res.modifyRefCoordSys(db,"lamCS")
   ld.setShellMoments(res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Strain Tensor",
                        "ElemCenters",bottom,["NONE"])
   res.modifyRefCoordSys(db,"lamCS")
   ld.setShellStrains(res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Curvature Tensor",
                        "ElemCenters",bottom,["NONE"])
   res.modifyRefCoordSys(db,"lamCS")
   ld.setShellCurvatures(res)

In the example, no thermal or moisture contribution has been taken into account in the loading. Only mechanical components have been defined. The example, is defined in such a way that all possible mechanical contributions are used: in-plane forces, out-of-plane forces, bending moments, average in-plane strain and curvature. All these components are defined as finite element Results. (This allows us later to compare the Results produced by FeResPost with those directly output by Nastran.) The modification of coordinate system is necessary because one wants the loading components to be expressed in laminate axes. (The Nastran shell forces, moments, curvatures... are given in element axes.)

For later comparison of Results, several Results directly extracted from Nastran “op2” file are directly output in file “Reference.txt”.

   os=File.open("Reference.txt","w")

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Shell Forces",
                        "ElemCenters",bottom,[])
   res.modifyRefCoordSys(db,"lamCS")
   Util::printRes(os,"Shell Forces",res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Shell Moments",
                        "ElemCenters",bottom,[])
   res.modifyRefCoordSys(db,"lamCS")
   Util::printRes(os,"Shell Moments",res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Strain Tensor",
                        "ElemCenters",bottom,["NONE"])
   res.modifyRefCoordSys(db,"lamCS")
   Util::printRes(os,"Strain Tensor",res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Curvature Tensor",
                        "ElemCenters",bottom,[])
   res.modifyRefCoordSys(db,"lamCS")
   Util::printRes(os,"Curvature Tensor",res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Stress Tensor",
                        "ElemCenters",bottom,[])
   Util::printRes(os,"Stress Tensor",res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Strain Tensor",
                        "ElemCenters",bottom,[])
   Util::printRes(os,"Strain Tensor",res)

   res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics",
                        "Composite Failure Index, Tsai-Hill",
                        "ElemCenters",bottom,[])
   Util::printRes(os,"Composite Failure Index, Tsai-Hill",res)

   os.close()

As laminate allowables are not defined in Nastran, one modifies the laminate corresponding to the unique PCOMPG property by adding laminate allowables to it. Then the modified ClaLam is reinserted in the database, where it replaces the original one:

   lam=compDb.getLaminateCopy(6)
   allowables={}
   allowables["sc"]=200.0e6
   allowables["s1c"]=200.0e6
   allowables["s2c"]=200.0e6
   allowables["st"]=300.0e6
   allowables["s1t"]=300.0e6
   allowables["s2t"]=300.0e6
   allowables["ss"]=100.0e6
   allowables["s12"]=100.0e6
   allowables["ilss"]=30.0e6
   lam.insertAllowables(allowables)
   compDb.insertLaminate(lam)

One also selects the failure indices that shall be calculated. The first one is calculated using ply material allowables, the others with the laminate allowables defined above. For the two last criteria, the most critical layer only is recovered for each element. The definition looks as follows:

   criteria = []
   criteria << ["TS FI","TsaiHill_c","FI",false,true]
   criteria << ["TW FI","TsaiWu","FI",true,true]
   criteria << ["TW FI Critical","TsaiWu","FI",true,false]
   criteria << ["ILSS FI Critical","Ilss","FI",true,false]

The following call to method “calcFiniteElementResponse” produces Results corresponding to the ClaLam object for which the method is called and writes Results in file “OneLaminate.txt”

   theta=0.0
   outputs=lam.calcFiniteElementResponse(ClaDb,theta,ld,[true,true,true],
      ["Shell Forces","Shell Moments", "Shell Curvatures",
       "Average Strain Tensor"],
      ["Stress Tensor","Strain Tensor","Mechanical Strain Tensor"],
      1.0,criteria)

   os=File.open("OneLaminate.txt","w")
   outputs.each do |id,res|
      Util::printRes(os,id,res)
   end
   os.close

The following sequence does the same operation, but the method “calcFiniteElementResponse” is called for the DataBase object “db”.

   theta=0.0
   outputs=db.calcFiniteElementResponse(compDb,theta,ld,[true,true,true],
      ["Shell Forces","Shell Moments", "Shell Curvatures",
       "Average Strain Tensor"],
      ["Stress Tensor","Strain Tensor","Mechanical Strain Tensor"],
      1.0,criteria)

   os=File.open("SeveralLaminates.txt","w")
   outputs.each do |id,res|
      Util::printRes(os,id,res)
   end
   os.close

For each element, “db” retrieves the property ID and selects in “compDb” the appropriate laminate with which the calculations are done. Of course, in this case, a single laminate is used and the Results should be the same as when the method is called for the “lam” laminate.

A few remarks can be done about the example:

A simplified variant of the example is presented in “testCriteria.rb” file. There the failure indices are calculated using directly layered stresses read from Nastran op2 file. For example, one calculates the failure indices using the ClaLam method as follows:

   outputs=lam.calcFiniteElementCriteria(compDb,stressRes,1.0,criteria)

IV.3.7 Modifying units

The example illustrates the manipulation of CLA objects units. The example is presented in directory “TESTSAT/RUBY/EX18’, in file “testMatUnits.rb”.

The sequence of operations is simple:

The two files “oldUnits.txt” and “newUnits.txt” may be compared. They should contain equivalent results.

The part of interest of the example is the modification units for all the materials in the database:

    oldUnits=db.getUnits

    newUnits=oldUnits.clone
    newUnits["F"]="lbf"
    newUnits["L"]="mm"
    newUnits["T"]="oF"

    puts oldUnits
    puts newUnits

    db.each_material do |id,mat|
        mat.changeUnits(newUnits)
        db.insertMaterial(mat)
    end

(Note that in the example, one deliberately decided not to use the “changeUnitsAllMaterials” method of the ClaDb class.)

The user may test the outputs with or without units systems modifications to verify if the results are affected by the modification of units. (They should not be modified.)

Chapter IV.4
Object-oriented post-processing

We present in this chapter an example of object-oriented post-processing programmed in ruby language. The structure of the post-processing presented here is very similar to the structure of post-processings we are currently using on actual “real” projects, and results from a long evolution driven by years of practice. Earlier versions of the post-processing project are presented and discussed in Appendixes X.D.2 and X.E.4 and in Chapter VII.4.

We summarize below the history of post-processings that are described in FeResPost User Manual:

The rest of this Chapter is organized as follows:

Note that the purpose of current chapter is to describe the main structure of the post-processing in a way that allows the reader to better understand source code. However, the understanding of the project will be achieved only by diving into the source code, which is described in section IV.4.1.

“DbAndLoadCases” module also acts as a server of Results for the post-processing objects discussed in section IV.4.1. Method “DbAndLoadCases.getResult” is programmed in such a way that the post-processing classes remain “unaware” of the solver or solution sequence that have produced the Results being post-processed:

We made reference above to the excel post-processing described in Chapter VII.4. Current project also uses Microsoft Office tools:

More informations about the final part of post-processing is provided in section IV.4.4. Note that the use of Microsoft Office tools, excel in particular has been reduced as much as possible in order to allow the running of most post-processing on Linux instead of Windows. This is why excel is used only for the preparation of CSV files, and for the extraction of results to be inserted into Word reports.

IV.4.1 Post-processing classes and modules

The post-processing project we are describing here does no use excel. It can be run on Windows computers as well as Linux computers. It requires only the following programs:

All the classes and modules defined here are defined in “PROJECT/PGR” sub-directory.

IV.4.1.1 Management of databases and load cases

Module “DbAndLoadCases” is devoted to the management of FEM databases and load cases. Three classes are defined in the module:

All the static load cases that have been defined in “DbAndLoadCases” module are not necessarily post-processed. The list of static load cases to be post-processed is specified via following instructions:

    DbAndLoadCases.addOneSelection(lcName,params)

The definition of databases, elementary and combined load cases, and of the selection of static load cases are a preliminary step in the post-processing project. This means that corresponding entities must be defined before the loop on static load cases which looks as follows:

    DbAndLoadCases.loopOnStaticCases() do |lcName|
        puts lcName
        postList.each do |p|
            begin
                p.initCalcSteps()
                p.calculate("Static")
            rescue Exception => x then
                printf("Failed Post object %s with ID %s\n",p.to_s,p.postID())
                PrjExcept.debug(x)
            end
        end
        DbAndLoadCases.saveMosResults(postList)
        DbAndLoadCases.saveSrResults(postList)
    end

For dynamic load cases (post-processing of Nastran SOL 111 analysis), no elementary or combined load cases are defined. Instead, the loop on the different sub-cases is done via instructions that look as follows:

    db=DbAndLoadCases::DB.new(dbName,"NASTRAN",bdfFileName,
        sesFileNames,claDbs,gmshFileName)
    DbAndLoadCases.databases[dbName]=db

    DbAndLoadCases.prepareDataBase(dbName)

    DbAndLoadCases.loopOnDynamSubCases(resFileType,resFileName,
            lcName,fMin,fMax,scNbrMax) do |lcNameA,lcNameB|
        puts lcNameB
        postList.each do |p|
            begin
                p.initCalcSteps()
                p.calculate("Dynamic Complex")
            rescue Exception => x then
                printf("Failed Post object %s with ID %s\n",p.to_s,p.postID())
                PrjExcept.debug(x)
            end
        end
        DbAndLoadCases.saveMosResults(postList)
        DbAndLoadCases.saveSrResults(postList)
    end

(The loop on sub-cases is obtained via an iterator directly defined in “DbAndLoadCases” without defining “ElemLc” or “CombiLc” objects.) Note that, another iterator is associated to dynamic (complex) 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

This iterator produces real Results from the complex Results , corresponding to different phases. (In out post-processing 12 phases are considered for each output frequency.) This iterator is called by the “calculate” method defined in “GenPost” class described in section IV.4.1.2.

“DbAndLoadCases” module also defines the methods that can be used to store results in an SQL database:

Note that “DbAndLoadCases” module is unaware of SQLite. All interactions with SQL database are done via “SqlWrap” module discussed in section IV.4.1.3. This has been done to ease the swap from SQLite to another SQL database system.

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:

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

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:

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. We consider it is user’s responsibility to write the code builds the post-processing objects with appropriate parameters. (See examples of definitions of data in section IV.4.2 for more details.)

Table IV.4.1: Parameters for the “PostCauchyStress” class.
Parameters for the extraction of Stress Tensor (“setData” parameters)
partName String The name of the part to which Excel results will be associated
loc String Location of extraction (“Elements”, “ElemCorners”, “ElemCenters”,...)
grpName String The name of Group on which stress tensor is extracted
layer(s) String, Integer or Array Layer(s) on which stress tensor is extracted
criteria Array Description of the derived criteria that must be calculated. (See below.)
Criteria and their parameters
Each criterion is defined in an Array of 5 elements
critName String Name of the criterion
gmshFileName String GMSH file name
gmshResName String GMSH result name
xlTableName String Name of the Excel worksheet in which results will be saved
critParams Hash Parameters for the derivation of criterion. (See below.)
Parameters if critName =“VonMises”
FoS Real Safety factor
All_VM Real Allowable
Parameters if critName =“MaxStress”
FoS Real Safety factor
All_MaxStress Real Allowable
Parameters if critName =“HoneyAirbus”
FoS Real Safety factor
All_L Real Core Shear Allowable (longitudinal direction)
All_W Real Core Shear Allowable (transverse direction)
Parameters if critName =“HoneyMaxShear”
FoS Real Safety factor
All_Shear Real Core Shear Allowable
Parameters if critName =“HoneyAxialComp”
FoS Real Safety factor
Comp_S String Axial Component (“XX”, “YY” or “ZZ”)
All_T Real Core Tensile Allowable
All_C Real Core Compression Allowable

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. We consider it is user’s responsibility to write the code builds the post-processing objects with appropriate parameters. (See examples of definitions of data in section IV.4.2 for more details.)

Table IV.4.2: Parameters for the “PostLaminate” class.
Parameters for the extraction of Stress or Strain Tensor (“setData” parameters)
partName String The name of the part to which Excel results will be associated
loc String Location of extraction (“Elements”, “ElemCorners”, “ElemCenters”,...)
grpName String The name of Group on which stress tensor is extracted
layer(s) String, Integer or Array Layers on which stress tensor is extracted
bCurvature Boolean This parameter is set to True if laminate Curvature Tensor is used in Classical Laminate Analysis. Otherwise, the Shell Moments are used. For laminate in plane and out-of-plane shear loading, one always use Shell Forces Tensor. (It is not possible in “PostLaminate” class to use the laminate average Strain Tensor.)
FoS Real Safety factor for all the failure criteria
criteria Array Description of the derived criteria that must be calculated. (See below.)
Criteria and their parameters
Each criterion is defined in an Array of 5 elements
critName String Name of the criterion
gmshFileName String GMSH file name
gmshResName String GMSH result name
xlTableName String Name of the Excel worksheet in which results will be saved
critParams Hash Parameters for the derivation of criterion.
None of the laminate failure criteria needs additional parameters. The same safety factor is considered for all failure modes, and allowables are found in the composite database associated with current load case.

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. We consider it is user’s responsibility to write the code builds the post-processing objects with appropriate parameters. (See examples of definitions of data in section IV.4.2 for more details.)

Note that:

Table IV.4.3: Parameters for the “PostConnect” class.
Parameters for the extraction of Stress Tensor (“setData” parameters)
ifName String The name of the interface to which Excel results will be associated
type String Description of the type of connection saved in Excel table of results. This parameter does not influence the calculation.
interfaceDef Hash This Hash contains information regarding the interface definition and how connection loads are retrieved from FEM results. Additional information is given below in te Table.
criteria Array The different extraction or failure criteria that will be processed at step 2 (or step 1 for “GlobFM” extraction).
How the “interfaceDef” Hash parameter defines the interface... Defines the extraction source and method, possible modification of coordinate system, direction vector for connection axis, optional parameters for bolt group redistribution of connection loads, ... Optional parameters are in parentheses.
ifName String The name of the interface for which connection loads are extracted. This should match the “ifName” argument of “setData” method discussed above.
grpNameA String The name of Group “A” defining the interface.
grpNameB String The name of Group “B” defining the interface. This second Group is not necessarily used but parameter is requested. It can be set to nil if the extraction method does not require Group “B”.
method String Identifies the loads extraction method. Possible values are “BMFRC”, “BSHFRC”, “GPFINT”, “GPFMPC”, “GPFSPC”, “MPCFRC”, “SPCFRC” and “APPFRC”. This corresponds to the specification of entities on which forces and moments are extracted. (See the sources of “PostConnect” class if you have doublts regarding the meaning of these parameters.)
csId String or Integer Specification of the coordinate system in which interface load components must be expressed before deriving axial forces, shear forces, bending moments...
direction Array Array of three Real values specifying connections’ axis. Components of this vector are given wrt the coordinate system identified by “csId” above.
bRedistr Boolean Specifies whether a bolt group redistribution is requested. The parameters that follow are optional and must be provided only if a bolt group redistribution is requested. (Theory is given in Appendix X.G.2.5.)
(bgCsId) Integer Identification of the coordinate system for bolt group redistribution
(kT) Real Translational stiffness of connections for bolt group redistribution
(kR) Real Rotational stiffness of connections for bolt group redistribution
(grpName3) String Name of a group of nodes defining the locations of connections onto which global loads are redistributed. If this argument is nil, the redistribution is done on locations corresponding to the FEM entities from which loads are extracted.
Criteria and their parameters
Each criterion is defined in an Array of 5 elements
critName String Name of the criterion
gmshFileName String GMSH file name
gmshResName String GMSH result name
xlTableName String Name of the Excel worksheet in which results will be saved
critParams Hash Parameters for the derivation of criterion. (See below.)
The different extraction or failure criteria are generally calculated in “calc_2” method of the post-processing object. “GlobFM” extraction criterion is the exception as this one is calculated at in “calc_1” method.
Parameters if critName =“GlobFM”
csId Integer Specifies the coordinate system considered for the calculation of interface global force and global moment. Note that this coordinate system may differ from the coordinate system specified in interface definition above, even though we use the same “csId” Hash key.
refPoint Array Array of three Real values specifying the coordinates of the point wrt which global force and moment are calculated. Coordinates are given wrt to coordinate system specified by “csId” above.
format String Specifies the format in which results are saved in Excel table. Possible values are “R”, “RI” or “MP”. This parameter matters when complex Results are post-processed (SOL 111 analysis).
This extraction is done in “calc_1” method. This is because for the post-processing of SOL 111 interface results the results are complex and one performs an extraction of complex components instead of one extraction for each phase that is post-processed.
Parameters if critName =“Sliding”
FoS Real Safety Factor
Pmin Real Minimum value of bolts’ pretension
Cf Real Friction coefficient between assembled parts
Parameters if critName =“Gapping”
FoS Real Safety Factor
Pmin Real Minimum value of bolts’ pretension
Lg Real Prying length for bending moment contribution
Parameters if critName =“Insert”
FoS Real Safety Factor
PSS Real Insert tensile allowable
QSS Real Insert shear allowable
Parameters if critName =“PullThru”
FoS Real Safety Factor
PSS Real Insert tensile allowable
Parameters if critName =“ShearBearing”
FoS Real Safety Factor
QSS Real Insert shear allowable
Parameters if critName =“IfLoads”
No parameter are provided for this criterion. (“critParams” is an empty Hash.) The failure criterion saves load components as they have been extract from FEM Results, according to “interfaceDef” Hash parameters. (See above in the table.)
Parameters if critName =“NasaStd5020”
FoS Real Safety factor
D Real Connection diameter. (Does not seem to be used in calculation of failure criterion.)
Lg Real Prying length considered to account for the bending moment
hsp Real ...
etaPhi Real ...
Pmax Real Maximum bolt pretension
Pt Real Bolt tensile allowable
Ps Real Bolt shear allowable
Pb Real Bolt bending allowable
bSpInThreads Boolean True if the shear plane is in threaded part of fastener
bPrldCombined Boolean True if the preload is considered in fastener shear or combined failure analysis. (According to section A.7 of [otNCE21], this preload can be neglected for some failure modes.)
Parameters if critName =“NasaStd5020_DBG”
This criterion is used for debugging purpose only and very close to “NasaStd5020’´. Corresponding parameters may be modified without notification and are therefore not described here.

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.

Table IV.4.4: Parameters for the “postExtract” class.
Parameters for the extraction (“setData” parameters)
extractName String The name of the extraction
params Hash Other parameters. (See below.)
Extraction parameters (“params” Hash object)
extractType String type of extraction
resName String Name of the Result being extracted
loc String FEM location for the extraction (“EC”, “EN” or “N”)
format String Format of the extraction (“RI”, “MP” or “R”)
elemId Integer or String Element on which results are extracted
nodeId Integer or String Node on which results are extracted
layerId Integer or String Layer on which results are extracted
csId Integer or StringCoordinate system in which components are given. (Use “None” or “AsIs” is no modification of coordinate system is requested.)
deriv String Derivation criterion. Identification of a Result derivation from tensorial, vectorial or scalar Result to scalar result.
xlTableName String Name of the Excel table in which extractions are saved

IV.4.1.3 Other modules and classes

Two classes provide various utilities. See below.

IV.4.1.3.1 “Util” module

“Util” module provides following methods. We list below the main methods:

IV.4.1.3.2 “SqlWrap” class

This class is very short. It is wrapping around SQLite::database class, and has been introduced in such a way that all SQL code specific to SQLite is contained in this class. The purpose of this class is to ease the transfer of post-processing project to another SQL database system, if necessary. The class proposes only three methods: “initialize”, “execute” and “timeStamp”.

IV.4.2 Definition of data

Most of the definition of data is done by functions defined in “PROJECT/DATA” sub-directory. The main data files are directly located in “PROJECT’ main directory however. The main data files are:

Data are interpreted by calling different ruby methods and build different kinds of objects:

The idea of using CSV files to store the definition of parameters is a legacy from the excel post-processing described in Chapter VII.4. It is also a very effective way to define the data. It improves the readability of data definition, and data definition in a combination of ruby code and CSV files ensures the flexibility needed to deal with specific cases.

Note that one of the post-processing data definition function does not involve the reading of a CSV file: “getSandwichData” method defines all the data in ruby code. This has been done because only one corresponding instance is created in the project. However, in more normal circumstances, it would be advantageous to define the data in a CSV file as well.

In general, the meaning of a parameter in a CSV file depends on the index of the column in which it is defined. Then, it is the responsibility of user to verify that the in each CSV data line, each value is inserted in the appropriate column, so that ruby code that interprets CSV lines fills the appropriate parameters for the construction of each “postConnect” object.

For the post-processing of connections, the CSV file “Interfaces.csv” that defines the data is formatted following conventions that differ from those adopted for the other types of post-processing criteria. Correspondingly the ruby method that reads the CSV lines and interprets them works differently. The CSV file is characterized by the insertion of directive lines that start with a keyword and specify how the following CSV lines must be interpreted:

An example of CSV lines with interpretation directives is presented in Figure IV.4.1. (Directive keywords are coloured in red in the excel worksheet.) We observe that the factor 0.001 is always associated to data specified in millimeters. This corresponds to the conversion of these values to meters.


PICT

Figure IV.4.1: Example of definition of data in excel CSV file for the postprocessing of interface data. The example corresponds to the definition of data for the calculation of bolts.

The approach for connection “post” objects construction is more flexible. It allows to consider several formats for the different lines of a CSV file. This is particularly appropriate for the definition of connection “post” objects, because the post-processing failure criteria may differ significantly depending on the interface considered.

IV.4.3 Sorting tools

In the post-processing example, all the outputs are saved in a single SQLite database. Some of the results can be accessed interactively via “SQLiteAdmin” program. This is for example the case for the excel-like tables in the database. SQLiteAdmin program allows to create views, export tables or views in excel. This means that part of the results saved in the database can directly be used to assess structure performance.

On the other hand, the “StrengthRatios” SQLite table, stores results in BLOB objects, and these cannot be visualized without specific conversion. One provides in the example, a ruby “‘final.rb” script that manipulates StrengthRatios content and performs the following operations:

Several of the methods called by “final.rb” script are programmed in “Manips” module stored in “PGR/manips.rb” file. (This file has been recently displaced from “DATA" to “PGR” directory.)


PICT

Figure IV.4.2: Example of definition of data for the calculation of different types of strength ratio envelopes.


PICT

Figure IV.4.3: Definition of the envelopes of load cases considered for the splitting of SR results and production of corresponding GMSH outputs.


PICT

Figure IV.4.4: Definition of the different criteria, parts and interfaces considered for the splitting of SR results and production of corresponding GMSH outputs.


Table IV.4.5: Correspondence of “location” specifications, SQLite DB keys in SR Results, Results extraction methods and GMSH output locations.
location SQLite DB key Result Extraction methodGmsh output location
ElemCenterPointsElemCenterPoints ElemCenters ElemCenterPoints
Elements Elements ElemCorners Elements
ElemStations ElemCenterPoints Elements ElemNodePoints
NodesOnly NodesOnly NodesOnly Nodes
Nodes Nodes Nodes Nodes

IV.4.4 Recovery of results in excel and reporting word

A “reportToExcelAndWord.xlsm” excel Workbook performs the final extractions to produce the final excel outputs, and the word report. This workbook contains several macros that automate the different worksheet buttons. The following operations are possible:

IV.4.5 A few tricks...

IV.4.5.1 Exceptions

Errors occuring during the execution of post-processing ruby scripts are often difficult to track. Generally, the exceptions raised by the different methods in the script do not convey useful information to identify the location of the error and its meaning. A majority of the errors are related to the definition of data, but one sometimes needs to go deep into the code, adding “print” statements to identify the mistake (wrong file name, reference to a non-existing group, missing parameter for an extraction of a failure criterion...).

To ease debugging, a “PrjExcept” class, deriving from ruby standard “Exception” class is defined in “PGR/prjExcept.rb” file. This class stored information related to the location of the exception, and optionnally additional information that may help to identify the source of the problem. The “dump” method of “PrjExcept” class writes to standard output stream the call stack and additional information related to an exception. For example, in “static.rb” script, one has the following code:

        postList.each do |p|
            begin
                p.initCalcSteps()
                p.calculate("Static")
            rescue Exception => x
                printf("Failed Post object %s with ID %s\n",p.to_s,p.postID())
                PrjExcept.debug(x)
            end
        end

The “PrjExcept.debug(x)” inscrution calls a class method in “PrjExcept” class that write to standard output detailed information about the exception. The information corresponds to the type of exception, the location in program where exception has been raised (call stack), and additional contextual messages.

An example of output provided by the “PrjExcept.debug(x)” statement is as follows:

Exception of class PrjExcept
DUMPING exception:
   PrjExcept CALL STACK (most recent call first):
         1: from static.rb:53:in ‘<main>’
         2: from C:/Users/ferespost/Documents/TESTSAT/RUBY/PROJECT/DATA/staticLoadCasesData.rb:251:in ‘loop’
         3: from C:/Users/ferespost/Documents/TESTSAT/RUBY/PROJECT/PGR/dbAndLoadCases.rb:453:in ‘loopOnStaticCases’
         4: from C:/Users/ferespost/Documents/TESTSAT/RUBY/PROJECT/PGR/dbAndLoadCases.rb:453:in ‘each’
         5: from C:/Users/ferespost/Documents/TESTSAT/RUBY/PROJECT/PGR/dbAndLoadCases.rb:488:in ‘block in loopOnStaticCases’
         6: from C:/Users/ferespost/Documents/TESTSAT/RUBY/PROJECT/DATA/staticLoadCasesData.rb:252:in ‘block in loop’
         7: from static.rb:64:in ‘block in <main>’
         8: from static.rb:64:in ‘each’
         9: from static.rb:67:in ‘block (2 levels) in <main>’
        10: from C:/Users/ferespost/Documents/TESTSAT/RUBY/PROJECT/PGR/post.rb:52:in ‘calculate’
        11: from C:/Users/ferespost/Documents/TESTSAT/RUBY/PROJECT/PGR/postConnect.rb:269:in ‘calc_0’
        12: from C:/Users/ferespost/Documents/TESTSAT/RUBY/PROJECT/PGR/postConnect.rb:249:in ‘extractConnectLoads’
   PrjExcept MESSAGES:
      Obtains nil resF Result for "MPCFRC"
      Failed to calculate calc_0
         param :  interfaceDef => {"ifName"=>"pan_MX/bar_MXPY (MPCFRC)", "grpNameA"=>"pan_MX", "grpNameB"=>"bar_MXPY", "method"=>"MPCFRC"}
         param :  bRedistr => false
         param :  csId => 5
         param :  direction => [0.0, 0.0, 1.0]
         param :  type => M6
         param :  criteria => [["Gapping", "Gapping.gmsh", "Gapping", "xl_Gapping", {"FoS"=>1.56, "Pmin"=>7200.0, "Lg"=>0.003}], ["Sliding", "Sliding.gmsh", "Sliding", "xl_Sliding", {"FoS"=>1.25, "Pmin"=>7200.0, "Cf"=>0.25}], ["Insert", "Insert.gmsh", "Insert", "xl_Insert", {"FoS"=>1.56, "PSS"=>3300.0, "QSS"=>4500.0}]]

Sometimes an exception is not related to an error in scripts or data definition. For example, when the justification involves structure configurations in which part of the structure is missing (panel removed) the corresponding post-processing may fail and raise an exception. Then, it is advisable to comment out the call to “PrjExcept.debug(x)” in order to keep stanndard output as clean as possible:

        postList.each do |p|
            begin
                p.initCalcSteps()
                p.calculate("Static")
            rescue Exception => x
                printf("Failed Post object %s with ID %s\n",p.to_s,p.postID())
                # PrjExcept.debug(x)
            end
        end

One can also decide to output debugging information only for a small selection of load cases and post-processing objects. To do this, appropriate tests must be inserted in the code above.

One can read the call stack and several messages that might help to understand the error. These messages are created in the different ruby methods where the exception is created. For example, the previous exception is created in “extractConnectLoads” of “PostConnect” class as follows:

        if resF==nil then
            raise PrjExcept.new(format("Obtains nil resF Result for \"%s\"",extractionMethod))
        end
        if resM==nil then
            raise PrjExcept.new(format("Obtains nil resM Result for \"%s\"",extractionMethod))
        end

The messages are added in “calc_0” method by the following instructions:

        ...
        rescue Exception => x
            x2=PrjExcept.new(x)
            x2.addLine(format("Failed to redistribute connection loads"))
            Util::addParamsToPrjExcept(x2,"   param : ",interfaceDef)
            raise x2
        ...

IV.4.5.2 Filtering the reading of Results

A post-processing shall be run several times. In many cases, the differnt runs differ by the data of part of the post-processing. For example, one may fix errors in the connections post-processing, or test design modifications (bigger fasteners). For this example, one would advise to re-run only the post-processing of connections. This can be done by commenting out the construction of other post-processing objects. For example, in “static.rb”:

    postList=[]
    #~ postList+=getAllStressData()
    #~ postList+=getSandwichData()
    postList+=getInterfacePostData()
    #~ postList+=getStaticExtractData()

this reduces somewhat the post-processing time.

But one can further reduce the post-processing by telling the “ResultsStorage” module that some of the Results must not be read from solver output files. For example:

    resFilter=[]
    resFilter << "Grid Point Forces, MPC Forces"
    resFilter << "Grid Point Forces, MPC Moments"
    resFilter << "Displacements, Translational"
    resFilter << "Displacements, Rotational"
    ResultsStorage.setResNamesFilter(resFilter)

The last statement specifies the list of Results that are read and/or generate by linear combinations of elementary Results. In above example, the reduction of time spent on reading is generally very significant.

IV.4.6 Conclusions

The post-processing object presented in this chapter is just an example of what can be done with FeResPost to manage calculations for a global project. It is improvable in many ways:

Part V
FeResPost Python bindings

Chapter V.0
Introduction

FeResPost is also distributed as a Python compiled library.

In general, the class names, their methods and attributes (properties), the parameters of these methods and attributes are the same as those available in the FeResPost ruby extension. The user is referred to Parts I, II, III and IV to find information on the use of the different classes and methods. In most cases, the information given there is sufficient to use the Python extension.

V.0.1 Accessing the Python extension

Typically, one imports the FeResPost Classes and Modules with a statement as:

    from FeResPost import *

Note however that it works only if the different environment variables have been initialized correctly. Typically, in our Windows examples, this is done through the batch files that are used to launch the example scripts, and the following variables are generally initialized:

    set LIB=
    set INCLUDE=
    set PYTHONPATH=C:/Users/ferespost/Documents/SRC/OUTPUTS/PYTHON/PYTHON_35
    set PYTHONINSTALLDIR=C:/NewProgs/PYTHON/PYTHON_35
    set REDISTRPATH=C:/Users/ferespost/Documents/SRC/OUTPUTS/REDISTR
    set PATH=%PYTHONINSTALLDIR%;%REDISTRPATH%;C:/Windows/System32

Of course the different paths you will initialize will have to be adapted to you peculiar installation, and to the version of Python you are using. See the description of ruby examples in chapter IV.0 for more explanations on the “PATH” variable definition.

V.0.2 Python versus ruby

Most of the differences of FeResPost Python and ruby libraries are directly related to the differences of the two languages, which are very similar as far as the different language concepts are concerned. Therefore, the adaptation of ruby examples to Python language should not be very difficult.

One highlights below some differences between Python and ruby extensions that are related to specific programmatic aspects of the two different systems.

V.0.2.1 Creating class instances

New instances of the FeResPost classes are obtained by calling the corresponding class constructor:

   ...
   from FeResPost import *
   ...
   db=NastranDb()
   ...

V.0.2.2 Associative containers and Arrays

The Python “list” object corresponds to ruby “Array”, and the Python ”Dictionary” corresponds to ruby “Hash” objects. One remarks however that the Python dictionary keys cannot be “list” objects. When this problem occurs, the ruby Array should be converted in a Python tuple instead of a Python list. (See for example the example “PYTHON/EX23/testHDF.py” in section V.1.2.)

V.0.2.3 Iterators

It is not possible to define several iterators in a given class in Python. Therefore, several special “Iterator” classes have been created in Python library. They are returned by the different FeResPost classes as is done for the COM component.

Let us illustrate it by an example... Consider the “each_ply” iterator defined in ClaLam class of FeResPost ruby extension. With the ruby extension, the iteration on the plies of a laminate may be performed as follows:

    ...
    lam.each_ply do |plyDescr|
        ...
    end
    ...

With Python, the code becomes:

    ...
    for ply in lam.iter_ply():
        ...
    ...

One could also write:

    ...
    x=lam.iter_ply()
    for ply in x:
        ...
    ...

As in the FeResPost ruby extension, each iterator method name starts with “each_”, correspondingly, the Python methods returning an Iterator object have a name that starts with “iter_”. The correspondence between ruby extension methods and COM component methods is obvious: “each_ply” becomes “iter_ply”, “each_material” becomes “iter_material”,...

V.0.2.4 “nil” arguments

With FeResPost ruby extension, an optional argument can be set to “nil” when not provided. The “nil” argument is to be replaced by “None” value in Python.

V.0.2.5 Exceptions

Python exceptions are managed as ruby exceptions. Only the message associated to standard exceptions is printed differently:

    try:
        db.readBdf("unit_xyz_V1.bdf",["../../MODEL/MESH/"],"bdf",{},True)
    except BaseException as x :
        print("\n\nMaybe you should modify the two first include statements in main file!")
        print("**********************************************************************\n")

        print("Got exception with following message:\n")
        print(str(x))

Chapter V.1
Python examples

As the adaptation from ruby to Python is straightforward, the current chapter is also very short. We only highlight some of the differences related to ruby and Python language differences.

V.1.1 Iterators

An example of an iterator with Python library is in “PYTHON/EX02/printGroups.py” and reads as follows:

for groupName in db.iter_groupName():
    grp = db.getGroupCopy(groupName)
    nodesNbr = grp.NbrElements
    elementsNbr = grp.NbrNodes
    rbesNbr = grp.NbrRbes
    coordNbr = grp.NbrCoordSys
    print("%20s%10d%10d%10d%10d"%(groupName,nodesNbr,elementsNbr,
        rbesNbr,coordNbr))

Note:

V.1.2 Accessing HDF and XDB results

An example of reading HDF Results with Python library is given in “PYTHON/EX23/testHDF.py” and corresponds to the ruby example described in section IV.2.9. The part related to HDF access looks as follows:

    Post.loadHdf5Library("C:/NewProgs/HDF5/HDF5-1.8.20-win32/bin/hdf5.dll")
...
    db.attachHdf(hdfName)

    lcNames=db.getHdfAttachmentLcNames(hdfName)
    lcName=lcNames[lcIndex]
    scNames=db.getHdfAttachmentScNames(hdfName,lcName)
    scName=scNames[scIndex]
    resNames=db.getHdfAttachmentResNames(hdfName,lcName)
    hdfResNames=list(resNames)

    db.readHdfAttachmentResults(hdfName,lcName,scName,resNames)
...

Note that the example also outputs Results read from an XDB file:

...
    results=db.getAttachmentResults(xdbName,lcName,scName,hdfResNames)
...
    for tpName in hdfResNames:
        print lcName,scName,tpName
        resKey=tuple((lcName,scName,tpName))
        tmpRes=None
        if resKey in results.keys():
            tmpRes=results[resKey]
        if (tmpRes):
            os.write("%-20s%-25s%-60s%-10d\n"%(lcName,scName,tpName,tmpRes.Size))
            os.write("%10d%10d%14g%14g : %s\n"%(tmpRes.getIntId(0),tmpRes.getIntId(1),tmpRes.getRealId(0),tmpRes.getRealId(1),tmpRes.Name))
            Util.printRes(os,tmpRes.Name,tmpRes)
        else:
            print lcName,scName,tpName
...

(Remark that the access to “results” dictionnary elements is done via “resKey” tuple.)

V.1.3 SQLite examples

The use of SQLite library is explained in Python documentation. With FeResPost, the BLOB object returned by “toBlob” method must be converted into a Python buffer using the corresponding function:

for lcName in lcNames:
    for resName in resNames:
        results=db.getAttachmentResults(xdbFileName,lcName,scNames,resName)
        if (results):
            for key,res in results.iteritems():
                print key
                sqldb.execute(
                    "insert or replace into dynam_results_1 values(?,?,?,?,?,?,?,?,?,?)",
                    [lcName,key[1],resName,res.TensorOrder,
                    res.getIntId(0),res.getIntId(1),
                    res.getRealId(0),res.getRealId(1),
                    res.Size,buffer(res.toBlob())])
            sqldb.commit()
        else:
            print "NO FOR" + lcName + resName

Note that the call to “buffer” method seems necessary with versions 2.* of Python, but must be removed for version 3.*.

V.1.4 Object-oriented post-processing

In directory “TESTSAT/PYTHON/PROJECTb” one presents an object-oriented post-processing. This project is the translation of the corresponding ruby example presented in chapter X.E.4.

Significant differences in the programming of the two projects deserve to be noted:

V.1.5 Superelements

The Python examples in directory “TESTSAT/PYTHON/EX27” are a simple translation of the ruby example discussed in section IV.2.11.

Part VI
FeResPost as COM component

Chapter VI.0
Introduction

On Windows OS, FeResPost is distributed at the same time as a ruby extension, and as a COM component. One describes in this Part several characteristics of FeResPost as a COM component.

In general, the class names, their methods and attributes (properties), the parameters of these methods and attributes are the same as those available in the FeResPost ruby extension. When necessary, modifications have been done in the ruby extension in order to maintain as much as possible the compatibility between the ruby extension and the COM component. Therefore, the user is referred to Parts I, II, III and IV to find information on the use of the different classes and methods. In most cases, the information given there is sufficient to use the COM component.

However, an exact match between the ruby extension and COM component is not possible. One details below the conventions that have been adopted when incompatibility problems were not solved. More generally, one explains here the specific aspects of the use of FeResPost as a COM component.

This Part of the document is organized as follows:

The present Chapter discusses the following points:

The installation (registration) of the COM component is described in section X.A.4.5).

VI.0.1 Accessing the COM component

One makes the distinction between the different programming languages and programming environments. The access to the component is always done by a request of the kind

   ‘‘create object’’ FeResPost_3_4_4.Application

in which the three integers correspond to the version of FeResPost. (Several versions of FeResPost can be installed simultaneously on a computer.) One intends to maintain the same conventions for the naming of the FeResPost COM component.

When the application is started, the corresponding window appears. This window can be made visible or invisible by setting the “Visible” property of the application object to True or False respectively. The window presents for each class a count of the number of objects available in the memory, and of the number of references to these objects. Note that when the property is set to True, the execution of the program might slow down significantly. Therefore, the property should be set to True for debugging only.

VI.0.1.1 Accessing the COM component in ruby

Even though FeResPost is first programmed as a ruby extension, the COM component can also be accessed from ruby language. For this, one first requires the “win32ole” ruby extension that allows the access to all the COM components installed on the computer. Then the FeResPost component can be accesses by requiring the corresponding application:

   require ’win32ole’

   ...

   frpApp = WIN32OLE.new("FeResPost_3_4_4.Application")

In the example, above one required the 3.4.4 version of the FeResPost COM component, and stores a reference to this application in “frpApp” variable.

Note that memory leakage has been observed in win32ole extension of ruby language. This can result in COM objects not being released when they should be. This bug, not related to FeResPost, is currently under investigation, and should be fixed in version 1.8.7 of ruby.

VI.0.1.2 Accessing the COM component in python

The access to the FeResPost COM component from python is similar to the access from ruby. A win32con extension must first be imported, then the component can be accessed:

 import win32con

 from win32com.client import Dispatch, constants

   ...

   frpApp = Dispatch("FeResPost_3_4_4.Application")

VI.0.1.3 Accessing the COM component in VBscript

In this case, no special extension is required because the OLE support is “build-in” the language. The application is simply accessed with the following statement:

   set frpApp= CreateObject("FeResPost_3_4_4.Application")

VI.0.1.4 Accessing the COM component in VBA

When programming in VBA, for example in excel, the component must first be referenced in the excel workbook. For this:

1.

Open the VBA editor from an excel workbook.

2.

Go to the “Tools” menu and select the “References” menu.

3.

There, you select the (or one of the) available FeResPost library. For example, for version 3.1.7, the library is referred to as “FeResPost 3.1.7 COM server”.

4.

Quit the “Tools/References” menu.

5.

Then, the server can be accessed from excel VBA code with a statement like:

              set frpApp= CreateObject("FeResPost_3_1_7.Application")

Once the FeResPost component library is activated, the different classes and the corresponding methods can be viewed in the object explorer. During the VBA program execution, the behavior of the different classes and methods can also be watched.

If you want to change the version of VBA used in an existing excel VBA project, proceed as follows:

1.

It may be practical to un-activate the execution of excel VBA macros before doing the following operations.

2.

Make sure that the new version of FeResPost is properly registered.

3.

Open the VBA editor from an excel workbook.

4.

Go to the “Tools” menu and select the “References” menu.

5.

Un-select the old version of FeResPost COM server. (The one you no longer want to use.)

6.

Quit the “Tools/References” menu.

7.

Re-enter into the “Tools” menu and select the “References” menu.

8.

Select the new version of FeResPost COM server you want to use in the workbook.

9.

Quit the “Tools/References” menu.

10.

Do not forget to modify the version of the server requested by “CreateObject” method in excel VBA code.

If you no longer need the old version of FeResPost COM server, you can un-register it and delete the corresponding files from your computer.

VI.0.1.5 Accessing the COM component in compiled languages

Section VII.1.1.4 shows an example of C++ program in which the component is accessed. This object shows that the use of COM component from compiled languages is significantly more difficult than from interpreted languages. This is related to the fact that the management of many operations has to be done by the programmer and is no longer dealt with by the interpreted language.

This example also shows that additional information should be added to the documentation to allow an easy access to the different methods and classes of the component by the compiled languages programmers. This documentation is still under development.

Actually, the example shows even more that the component that is being developed is adapted to the use with languages that support the Microsoft IDispatch interface. However, a library adapted to the use with C++ language should also be developed. Consequently we do not advise to use the component from C++ or C language.

VI.0.2 COM component versus ruby extension

One highlights below some differences between COM component and ruby extension that are related to specific programmatic aspects of the two different systems.

VI.0.2.1 Creating class instances

New instances of the FeResPost classes are obtained by calling the “newObject” method of FeResPost application. The argument of this method is a String containing the name of the class of which a new object is requested. For example, in ruby, the creation of new instances is done with statements like:

   ...
   frpApp = WIN32OLE.new("FeResPost_3_4_4.Application")
   ...
   db=frpApp.newObject("ClaDb")
   ...
   mat=frpApp.newObject("ClaMat")
   ...

The corresponding VBscript lines of code follow:

   ...
   set frpApp= CreateObject("FeResPost_3_4_4.Application")
   ...
   set db=frpApp.newObject("ClaDb")
   ...
   set mat=frpApp.newObject("ClaMat")
   ...

VI.0.2.2 Associative containers and Arrays

By default, COM does not define associative containers (i.e. containers that associate keys and values, like the “Hash” class of ruby language.) As in FeResPost ruby extension, Hash objects are often used as method arguments, or values returned by these methods, A convention must be agreed upon to determine the type of arguments that are to be used to replace these Hashes.

The convention that has been adopted is that each Hash is replaced by a 2D Array:

One notes that the indices used to access the elements of an Array start with 0 corresponding to the first element. This is a convention that has systematically been used for all the Array produced by FeResPost COM component. This convention is that same as the one of FeResPost ruby extension, and is consistent with C, C++, ruby and many other programming languages.

VI.0.2.3 Iterators

COM provides a standard interface that allows the writing of iterators on collections of different types. In FeResPost, the iteration is based on the IEnumVARIANT interface. One notes however, that it does not seem possible to implement a class that defines several enumerators. This is why, an additional class corresponding to the iteration has been created in FeResPost: the “Iterator” class.

The “Iterator” class is common to all the iterators of all the FeResPost classes. But an Iterator object behaves differently depending on the class that produces it and/or the method of the class that is used to produce it.

Let us illustrate it by an example... Consider the “each_ply” iterator defined in ClaLam class of FeResPost ruby extension. With the ruby extension, the iteration on the plies of a laminate may be performed as follows:

   ...
   lam.each_ply do |plyDescr|
      ...
   end
   ...

With FeResPost COM component, an Iterator must first be produced before iterating on the elements of the corresponding collection. This can be done as follows:

   ...
   plyIt = lam.iter_ply
   plyIt.each do |plyDescr|
      ...
   end
   ...

This examples illustrates the conventions that have been used when programming the FeResPost COM component to transpose the iterators proposed in the ruby extension:

1.

As in the FeResPost ruby extension, each iterator method name starts with “each_”, correspondingly, the COM component methods returning an Iterator object have a name that starts with “iter_”. The correspondence between ruby extension methods and COM component methods is obvious: “each_ply” becomes “iter_ply”, “each_material” becomes “iter_material”,...

2.

When the COM iteration method has no argument, it is a property “getter” that is used instead of a method. Otherwise, a method with argument is defined.

3.

In ruby using the COM component, the iteration on the Iterator object is done using “each” iteration method.

Note that to the ruby lines given as example above, one prefers the shorter notation:

   ...
   lam.iter_ply.each do |plyDescr|
      ...
   end
   ...

The corresponding code in python may be:

   ...
   for plyDescr in lam.iter_ply:
      ...
   ...

and in VBscript, one shall have:

   ...
   for each plyDescr in lam.iter_ply
      ...
   Next
   ...

VI.0.2.4 Operators

Operators are unsupported in COM. Therefore, the operators that are defined by ruby classes are replaced by methods in COM component:

For example, the following ruby statement:

   z=x+y

becomes, with COM component:

   z=x.opAdd(y)

Note that the different “operator” methods defined in ruby “Post” module are also defined in the “Application” class of COM component (section VI.2.1).

VI.0.2.5 Singleton methods

In ruby language, classes may define singleton methods that can be called directly from the class, and not from an instance of the class. Apparently, this capability is unsupported by COM classes.

Therefore, all the singleton methods defined in ruby extension are defined as instance methods in COM component. This means that before using such a method, an instance of the corresponding class must be defined first.

VI.0.2.6 “Clone” methods

When one class of the ruby extension defines a “clone” method, the corresponding method of the COM component defines a “makeCopy” method. This has been done to avoid method name conflicts when the COM component is used with ruby language.

VI.0.2.7 “Post” Module

In ruby extension, several methods are defined in “Post” Module. In COM component, these methods are defined in “Application” class.

VI.0.2.8 Complex arguments

In ruby extension, several methods have complex arguments. No standard “Complex” class exists in COM, even though the “Complex” class is available in most programming languages. In FeResPost COM component one decided that the convention is to represent Complex numbers by Arrays of two real numbers corresponding to the real and imaginary parts of the number.

VI.0.2.9 “nil” arguments

With FeResPost ruby extension, an optional argument can be set to “nil” when not provided. The “nil” argument also works when the COM component is used with ruby language. in VBA, the “nil” argument can be replaced by an unitialized Variant object (VT_EMPTY variant type).

VI.0.2.10 Exceptions

It is not possible to associate an error message to errors returned by COM component. But method “getLastErrorMessage” defined in FeResPost Application class allows to obtain the message associated to the last exception raised by FeResPost. This method can be used to retrieve and print the message. Here is a ruby example of exception management with COM component:

   begin
       db.readBdf("unit_xyz_V1.bdf",["../../MODEL/MESH/"],"bdf",nil,true)
   rescue Exception => x then
       printf("\n\nMaybe you should modify the two first include statements in main file!\n")
       printf("**********************************************************************\n\n")
       puts frpApp.getLastErrorMessage()
   end

VI.0.2.11 Selection of standard output for information messages

In general, the selection of output stream for the writing of FeResPost information messages follows the same rules as for ruby extension, as explained in section I.6.1. However, it is not possible to set FeResPost information output stream to COM client’s output streams. This is related to the fact that the type of output stream depends on the client language (ruby, python, VBA, C++...). This has two consequences:

1.

The equivalent to method “setInfoStreamToClientStream” does not exist in COM component.

2.

COM component default information stream is set to C++ std::cout output stream, and not to the client’s language standard output stream.

Chapter VI.1
CLA classes

The different classes described in this Chapter correspond to the classes described in Part II. The methods defined in FeResPost COM component CLA classes are the same as those defined in the FeResPost ruby extension CLA classes, except the peculiar problem of the iterators discussed in section VI.0.2.3, and of the “clone” methods that have been replaced by “makeCopy” methods.

Similarly, the arguments defined for the different methods of CLA classes are the same as those for the classes of FeResPost ruby extension, except for the remark done in section VI.0.2.2 for the “Hash” arguments or returned values.

In the rest of this Chapter, one makes a few remarks about the different classes. But otherwise, the reader is referred to the different chapters of Part II to find information on the use of COM component CLA classes.

VI.1.1 “ClaDb” class

This class corresponds to “IClaDb” interface. No peculiar remark is to be done except for the iterators:

The “makeCopy” method that returns a copy of the object.

VI.1.2 “ClaMat” class

This class corresponds to “IClaMat” interface.

Methods returning a 2D matrix, return a an Array with 2 dimensions. These methods are “getCompliance”, “getStiffness”, “getInPlaneCompliance”, “getInPlaneStiffness”, “getOOPSCompliance”, “getOOPSStiffness”, “getInPlaneLambdaT”, “getInPlaneLambdaH”. (In ruby extension, these methods return an array of arrays.)

The “makeCopy” method that returns a copy of the object.

VI.1.3 “ClaLam” class

This class corresponds to “IClaLam” interface.

Methods returning a 2D matrix, return a an Array with 2 dimensions. These methods are “get_ABBD”, “get_G”, “get_abbd_complMat”, “get_g_complMat”, “get_LambdaT”, “get_LambdaH”. (In ruby extension, these methods return an array of arrays.)

Methods that return Ply stresses, strains, temperature or moisture return 2D Arrays of size N*8 or N*3.

The “getDerived”, “getFailureIndices” and “getReserveFactors” methods return Arrays of 2 objects. The second object is a 2D Array in COM component.

Methods “getMaxDerived”, “getMinDerived”, “getMaxFailureIndices”, “getMinFailureIndices”, “getMaxReserveFactors” and “getMinReserveFactors” returns 2 dimensional Arrays of sizes N*3.

Iterator “each_ply” in ruby extension becomes “iter_ply”.

The “makeCopy” method that returns a copy of the object.

VI.1.4 “ClaLoad” class

This class corresponds to “IClaLoad” interface. No peculiar remark is to be done. The “makeCopy” method that returns a copy of the object.

Chapter VI.2
Generic FeResPost classes

Most classes defined in this chapter correspond to the same classes in ruby extension.

One class correspond to modules in ruby extension: the “Application” class described in section VI.2.1 corresponds more or less to the “FeResPost” module in ruby extension, even though its purpose is not exactly the same. This class also inherits the methods defined in “Post” module of ruby extension.

The two classes “Iterator” and “IterX” correspond to the iterators defined in the different classes of the COM component. These classes are not described in this chapter. Indeed, one considers that the explanations given in section VI.0.2.3 about the use of iterators is sufficient. Of course no corresponding class exists in the ruby extension.

VI.2.1 FeResPost Application class

This class corresponds to the “IApplication” interface. Only one object of the class Application can be created, even though several references to this object can be used in a program.

VI.2.1.1 Management of the Application

The “Visible” property can either be set or got. The value of this property specifies whether the Application main window is visible or not. The Application main window shows the number of FeResPost COM objects that have been created and the number of references to these object. This information is provided by class, and one also gives the summary for all classes in last “TOTAL” line.

Note that it is not because an Application is not “Visible” that it is not running.

VI.2.1.2 Creation of other objects

The method “newObject” is used to create objects for the different classes of the COM component. Its argument is a String corresponding to the name of the class for which an object is requested. The created object is the return value. For example, when the following statement is used:

   db=frpApp.newObject("NastranDb")

creates a new Nastran DataBase object and a reference is stored in “db” variable.

VI.2.1.3 Methods corresponding to “Post” module in ruby extension

All the methods which in ruby extension are defined in “Post” module, are defined in “Application” class for the COM component. Presently, these methods are

VI.2.1.4 Changing working directory

When working with “FeResPost.exe” out-of-proc solver, also called “local server” it may be interesting to change the working directory of the server, to match the one of the client, for example. Two methods have been added to the COM component:

These two methods are specific to the COM component. They are not defined in the .NET assembly, or the ruby extension.

For “in-proc” server (or dll server), these two methods have no effect.

VI.2.2 Generic DataBase class

This class corresponds to the generic DataBase class of ruby described in Chapter I.1. The class cannot be instantiated; only the interface “IDataBase” has been defined. The DataBase classes corresponding to the different solvers derive from the “IDataBase” interface.

The iterators of the DataBase class in ruby extension have also been defined in COM component: “iter_abbreviation”, “iter_groupName”, “iter_resultKey”, “iter_resultKeyCaseId”, “iter_resultKeySubCaseId”, “iter_resultKeyLcScId” and ‘iter_resultKeyResId” properties in COM component correspond to the “each_abbreviation”, “each_groupName”, “each_resultKey”,
“each_resultKeyCaseId”, “each_resultKeySubCaseId”, “each_resultKeyLcScId” and
“each_resultKeyResId” iterators in ruby extension.

The four singleton methods “enableLayeredResultsReading”, “disableLayeredResultsReading”, “enableSubLayersReading” and “disableSubLayersReading” in the ruby extension generic DataBase class are defined as instance methods. This means that an instance of the derived class must be created to use these singleton methods.

The same is true for methods “setStorageBufferMaxCapacity” and “getStorageBufferMaxCapacity”.

VI.2.3 Group class

Most methods of the “Group” class are exactly the same as the ones defined in the Group class of ruby extension (Chapter I.3). Several methods or properties are different however:

VI.2.4 CoordSys class

Methods of the “CoordSys” class are the same as the ones defined in the CoordSys class in ruby extension. The “makeCopy” method that returns a copy of the object.

VI.2.5 Result class

Most methods of the “Result” class are exactly the same as the ones defined in the Result class in ruby extension (Chapter I.4). Several methods or properties are different however:

VI.2.6 ResKeyList class

Methods of the “ResKeyList” class are the same as the ones defined in the ResKeyList class in ruby extension. Only the single iterator is different: However:

Chapter VI.3
Supported Solvers

The two classes that correspond to the two supported solvers (Nastran and Samcef) are complete.

VI.3.1 The “NastranDb” class

The “NastranDb” class stores a model and results corresponds to Nastran finite element solver. It corresponds to “INastranDb” interface that derives from the “IDataBase” interface described in section VI.2.2. Methods specific to the COM component are:

The reader is referred to Chapter III.1 for the description of the other methods.

VI.3.2 The “SamcefDb” class

The “SamcefDb” class stores a model and results corresponds to Samcef finite element solver. It corresponds to “ISamcefDb” interface that derives from the “IDataBase” interface described in section VI.2.2. The other methods that are available are:

The reader is referred to Chapter III.2 for the description of the other methods.

Part VII
FeResPost Examples with COM Component

Chapter VII.0
Introduction

COM examples can be run on Windows only. Therefore, these examples should be launched via batch scripts that define the environment variables needed for the execution. For example, in directory “COMEX/EX03”, one enters the command:

    exec ruby -I. makeGravForces.rb

or

    exec python printstressmax.py

The “exec.bat” script contains, for example, the following lines:

    setlocal
    call "../ENV/env.bat"
    echo %PATH%
    %*
    endlocal

in which the environment defines the variables specifying the version of python or ruby to be used, and the PATH to the directories containing executable and libraries used for the executation. For example:

    set WINLIBS=C:/Users/ferespost/Documents/SRC/OUTPUTS/REDISTR;C:/Windows/System32
    set PATH=C:/NewProgs/PYTHON/PYTHON_37;C:/NEWPROGS/RUBY/ruby-2.5.1-1-x86/bin;%WINLIBS%
    set PYTHONPATH=C:/Users/ferespost/Documents/SRC/OUTPUTS/PYTHON/PYTHON_37

The launch of excel examples is slightly different. For example, the script launching the classical laminate analysis with excel in directory “EX06” contains:

    setlocal
    call "../ENV/env.bat"
    LaminateAnalysis.xls
    endlocal

Chapter VII.1
COM examples with various languages

In this Chapter one shows examples illustrating the use of the COM component with interpreted or compiled languages. All the examples can work only if the COM component has been properly installed as explained in section X.A.4.5. Note also, that the examples presented below assume that you have installed version 3.4.0 of the FeResPost COM component. If another version is installed, some lines in the program must be adapted.

VII.1.1 Using COM component with several languages

In this section, one presents an example in which the FeResPost COM component is used to automate CLA analyses with different programming languages. The same calculations are done with different programming languages. This allows the user to identify the similarities and differences of FeResPost COM automation with different programming languages:

Section VII.1.1.5 was added to allow the presentation of an automation program in C. This has not been one yet, however.

VII.1.1.1 Using component with python

The file “COMEX/EX01/testClaCom.py” contains the python program lines for automation of CLA calculations with python. One gives below some explanation about how the program works.

First, some python standard packages must be imported to allow the OLE automation to be used in the program. Therefore, the following statements are added at the beginning of the program:

         import sys
         import win32con
         from win32com.client import Dispatch, constants
      

Then the program defines several methods that are used in the main program:

No “main” function is defined in the program. Instead, the last lines of the program file contain the instructions that perform the main analysis.

First the component must be accessed and a ClaDb object created and initialized. This is done as follows:

         frpApp = Dispatch("FeResPost_3_4_0.Application")
         db=frpApp.newObject("ClaDb")
         db.readNeutral("test.ndf")
      

Note that the access to the application requires the full name of the application that includes the version identification. This means that the name will have to be changed if another version of the component is used. The initialization of the ClaDb object involves the reading of “test.ndf” neutral data file.

The output of the results is done in a disk file:

         os=file("testClaCom_py.txt","w")
      

Note that the use of iterators with python is easy. For those who know python, to understand the following lines should not be a problem:

         for lamId in db.iter_laminateId:
            printLamProperties(db,os,lamId)
            for loadId in db.iter_loadId:
               printLoadResponse(db,os,lamId,loadId,0.0,criteria)
      

One first makes a loop on the laminates and prints their properties. Then, inside the loop on the laminates, a loop on the loads stored in the dataBase is done and the laminate load response is calculated and printed. The criteria that are calculated are: “TsaiHill”, “Ilss” and “YamadaSun”.

When the program is run, the FeResPost component application window exhibits the number of component objects referenced, and the number of references. You may stop the program at several locations to check this information. (By adding windows message boxes for example.)

VII.1.1.2 Using component with ruby

The file “COMEX/EX01/testClaCom.rb” contains the ruby program lines for automation of CLA calculations with ruby. The ruby program is very similar to the python program:

Note that the window created at the end of the program may show that some of the references to COM objects have not been released. Then this is a problem in “win32ole”extension of ruby, but not in FeResPost COM component.

VII.1.1.3 Using component with VBscript

The file “COMEX/EX01/testClaCom.vbs” contains the VBscript program lines for automation of CLA calculations with VBscript. The VBscript version of the example is rather short, and it does not work: there is a problem with the access to elements of 2D matrices. If someone can explain us what is wrong, we would appreciate.

We just show below how the component is accessed, and the ClaDb object initialized:

         set frpApp= CreateObject("FeResPost_3_4_0.Application")
         set db=frpApp.newObject("ClaDb")
         db.readNeutral "test.ndf"
      

VII.1.1.4 Using component with C++

The example is provided in the following files:

The batch file “COMEX/EX01/build.bat” is used to compile the example. The compilation messages should look as follows:

         g++ -c testClaCom.cpp -I"H:\OUTPUTS\COM\include"
         g++ -c util.cpp
         g++ -o testClaCom.exe testClaCom.o util.o \
            "H:\OUTPUTS\COM\lib\FeresPost.dll"  -lole32 -loleaut32 \
            -luuid -lstdc++
      

(You may have to change the compilation commands, options and files access to compile the program on your computer.)

In a C++ program, several headers must first be included in the program to have access to classes, methods and GUIDs declarations and/or definitions:

         #include <Application.hxx>
         #include <Application_i.c>

         #include <ClaDb.hxx>
         #include <ClaLam.hxx>
         #include <ClaMat.hxx>
         #include <ClaLoad.hxx>
         #include <IterX.hxx>
         #include <Iterator.hxx>
      

(The included files are distributed with the FeResPost COM library in the “include” directory.) The access to the component and the initialization is done as follow:

      if (!CoInitialize(0)){
         if ((hr = CoGetClassObject(CLSID_Application, CLSCTX_INPROC_SERVER,
                  0, IID_IClassFactory, (LPVOID *)&classFactory))) {
            MessageBox(0, "Can’t get IClassFactory", "CoGetClassObject error",
                  MB_OK|MB_ICONEXCLAMATION);
            cerr << hr << endl ;
            exit(-1);
         }
         else {
            if ((hr = classFactory->CreateInstance(0, IID_IApplication,
                     (LPVOID *)&frpApp))) {
               classFactory->Release();
               MessageBox(0, "Can’t create IApplication object",
                     "CreateInstance error",MB_OK|MB_ICONEXCLAMATION);
               return -1;
            }
            else {
               classFactory->Release();
               MessageBox(0, "SUCCESS", "SUCCESS", MB_OK|MB_ICONEXCLAMATION);
            }
         }
      }

      frpApp->newObject(BSTR_ClaDb,(IDispatch**)&db);
      string2variant("test.ndf",fileName);
      db->readNeutral(fileName);
      

As you can see, it is a little more complicated than in ruby or python.

The entire C++ example shows that it is significantly more complicated to use COM component with compiled languages than with interpreted languages that support COM automation. This is related to several factors:

Just to illustrate the points above, one gives below an example of the programming lines necessary to perform the iterations on laminate and load IDs and call the calculation functions:

         VARIANT lamId,loadId;
         IIterator *lamIt,*loadIt;
         IIterX *lamIterX,*loadIterX;
         ULONG pCeltFetched;

         ...

         db->get_iter_laminateId((IDispatch**)&lamIt);
         lamIt->get_newEnum((IUnknown**)&lamIterX);
         db->get_iter_loadId((IDispatch**)&loadIt);
         loadIt->get_newEnum((IUnknown**)&loadIterX);
         lamIterX->Reset();
         for (lamIterX->Next(1,&lamId,&pCeltFetched);pCeltFetched>0;
               lamIterX->Next(1,&lamId,&pCeltFetched)) {
            printLamProperties(db,os,lamId);
            loadIterX->Reset();
            for (loadIterX->Next(1,&loadId,&pCeltFetched);pCeltFetched>0;
                  loadIterX->Next(1,&loadId,&pCeltFetched)) {
                     printLoadResponse(db,os,lamId,loadId,0.0,criteria);
            }
         }
         lamIterX->Release();
         lamIt->Release();
         loadIterX->Release();
         loadIt->Release();
      

Actually, the example shows that the component that is being developed is adapted to the use with languages that support the Microsoft IDispatch interface. However, a library adapted to the use with C++ language should also be developed. Consequently we do not advise to use the component from C++ or C language.

VII.1.1.5 Using component with C

No C example is provided. But it is possible to program a C program using FeResPost COM component as well as a C++ program. This requires the same header files as those used in the C++ example. The program will not be significantly different than the C++ one. (Just a bit more complicated actually.)

VII.1.2 Testing the “NastranDb” and “Group” classes

The three examples described below are provided in directory “COMEX/EX02”. From now on, the access to the component is done by calling “getCurrentFrpApp” method defined in “Util” Module. (This reduces the amount of work necessary to update the examples when a new version of FeResPost is published.)

VII.1.2.1 Using iterators and “NastranDb” class

The file “COMEX/EX02/testNastranDb.py” contains python examples of the use of NastranDb class with the COM component. Each type of test is defined in a devoted python function that is called by the “main” program.

The example “COMEX/EX02/properties.rb” illustrates the access to FEM definition with “fillCard” method.

VII.1.2.2 Writing elements connectivity

The file “COMEX/EX02/elemConnectivity.rb” contains the ruby equivalent of the “testElemConnectivity” function in “COMEX/EX04/testNastranDb.py” example. The operations done in this ruby file correspond to the ones in example “RUBY/EX16/elemConnectivity.rb” except that the COM component is used instead of the ruby extension. The comparison of the two ruby files shows that the differences correspond to the access to the component, and to the use of iterators.

VII.1.2.3 Manipulation of Groups

The file “COMEX/EX02/testGroups.py” contains python examples of Groups manipulation with the COM component. Four functions performing different tests are defined:

The "main" function is defined at the bottom of the example file.

VII.1.3 Translating a few small “RUBY” Result examples

In the following sub-sections, one presents examples devoted to the manipulation of Result objects with FeResPost COM component. All these examples are the translation of examples of the “RUBY” directory for which the ruby extension was used. As descriptions of these examples with ruby extension are already given in Chapter IV.2, one highlights here only the peculiarities related to the use of the COM component.

Also, several of the ruby examples are translated in python. There, one also presents the peculiarities of the python programming with the COM component.

VII.1.3.1 Printing DataBase lists of Results

This example is stored in file “COMEX/EX03/printResLists.rb”. It corresponds to the example "RUBY/EX04/printResLists.rb" described in section IV.2.4. The differences between the two programs are related to the way FeResPost COM component is accessed, to the access to the objects of different classes, and to the use of iterators. (See corresponding explanations in section IV.2.4.1.)

The same example is also translated in python in file “COMEX/EX03/printResLists.py”. Here again, for explanations on the access to COM component and the use of iterators, the user is referred to section VII.1.4. One notes however differences in the use of iterators that return several values. The following ruby statements:

      db.iter_resultKey.each do |lcName,scName,tpName|
         tmpRes=db.getResultCopy(lcName,scName,tpName)
         printf("%-20s%-15s%-50s%-10d\n",lcName,scName,tpName,\
                tmpRes.Size)
      end

become in python:

      for tab in db.iter_resultKey:
         lcName=tab[0]
         scName=tab[1]
         tpName=tab[2]
         tmpRes=db.getResultCopy(lcName,scName,tpName)
         stdout.write("%-20s%-15s%-50s%-10d\n"%(lcName,scName,tpName,\
               tmpRes.Size)

(The differences are related to the fact that python has no syntax for iterators that return several values.)

VII.1.3.2 Printing maximum stress

This example is stored in file “COMEX/EX03/printStressMax.rb”. It corresponds to the example “RUBY/EX05/printStressMax.rb” described in section IV.2.4.2. This example illustrates the use of operators with COM component. For example, with ruby extension, the intersection of two Groups is calculated with the following statement:

         newGrp = panelGroup * matGrp

With COM component, the same instruction becomes:

         newGrp = panelGroup.opMul(matGrp)

So far, the difference is not very dramatic. However, the translation of expressions involving several dyadic operators can be more difficult. For example, the following expression with ruby extension:

         scalar = Post.sqrt(sXZ*sXZ+sYZ*sYZ)

becomes with COM component:

         scalar = frpApp.sqrt(sXZ.opMul(sXZ).opAdd(sYZ.opMul(sYZ)))

(Note also that the “sqrt” method is found in “frpApp” Application instead of “Post” module.) A python version of the example is also available in file “COMEX/EX03/printStressMax.py”.

VII.1.3.3 Generating Nastran GRAV cards

This example is stored in file “COMEX/EX03/makeGravForces.rb”. It corresponds to the example “RUBY/EX06/makeGravForces.rb” described in section IV.2.5.1. As a Module is defined in this example, one needs to store the application in a ruby global variable. This is done as follows:

         $frpApp = WIN32OLE.new("FeResPost_3_4_0.Application")

Then, in the different methods of the Module, the global variable can be used to access the different methods of the application. For example, objects of the different classes can be created with “newObject” method as follows:

         db=$frpApp.newObject("NastranDb")

VII.1.3.4 Printing beam forces

This example is stored in file “COMEX/EX03/printBeamForces.rb”. It corresponds to the example “RUBY/EX08/printBeamForces.rb” described in section IV.2.4.4. The example is also defined in the python file “COMEX/EX03/printBeamForces.py”.

No remark is to be done about these programs, except that the “UTIL” modules are used. These are defined in files “COMEX/Util/util.rb” and “COMEX/Util/util.py” for ruby and python respectively. When the ruby and python versions of the module are compared, one notes a difference in the use of iterators. The brackets are mandatory for iterators methods with arguments are used in python even when no argument is given. This means that the following ruby statement:

      res.iter.each do |key,values|

Becomes in python:

      for tab in res.iter():
         key=tab[0]
         values=tab[1]

(The void brackets in python first statement is related to the fact that the “iter” method of “Result” class may have up to five arguments.)

Note that the UTIL Modules in COM examples correspond to the UTIL module defined in file “RUBY/UTIL/util.rb” and described in section IV.2.1.

VII.1.3.5 Printing strain tensor

This example is stored in file “COMEX/EX03/printStrain.rb”. It corresponds to the example “RUBY/EX08/printStrain.rb” described in section IV.2.4.4. The example is also defined in the python file “COMEX/EX03/printStrain.py”. No remark is to be done about this example.

VII.1.3.6 Modification of reference coordinate systems

These examples are stored in files “COMEX/EX03/modifCS2D.rb”, “COMEX/EX03/modifCS2Db.rb”, “COMEX/EX03/modifCS2Dc.rb” and “COMEX/EX03/modifCS3D.rb” respectively. They correspond to the examples of directory “RUBY/EX09” described in section IV.2.4.5. The example “COMEX/EX03/modifCS2Db.rb” is also programmed in python in file “COMEX/EX03/modifCS2Db.py”. No remark is to be done about these examples.

VII.1.3.7 Calculation of global force and moment

This example is stored in file “COMEX/EX03/testGlobFM.rb”. It corresponds to the example “RUBY/EX08/testGlobFM.rb” described in section IV.2.5.3. The example is also defined in the python file “COMEX/EX03/testGlobFM.py”. No remark is to be done about this example.

VII.1.3.8 Writing GMSH mesh and Results

This example is stored in file “COMEX/EX03/writeGmsh.rb”. It corresponds to the example “RUBY/EX08/writeGmsh.rb” described in section IV.2.4.4. The example is also defined in the python file “COMEX/EX03/writeGmsh.py”. No remark is to be done about this example.

VII.1.3.9 Manipulation of XDB Result files

The examples described in the following sub-sections are devoted to the manipulation of XDB Result files. Only the second example deals with the manipulation of complex Results.

VII.1.3.9.1 Extraction of information from XDB Result file

The first example is stored in file “COMEX/EX04/printXdbLcScResNames.rb”. It corresponds to the example “RUBY/EX17/printXdbLcScResNames.rb” described in section IV.2.4.6. The second example is stored in file “COMEX/EX04/printXdbLcInfos.rb”. It corresponds to the example “RUBY/EX17/printXdbLcInfos.rb” described in section IV.2.4.6. No remark to be done about these examples.

VII.1.3.9.2 Manipulation of complex Results

This example is stored in file “COMEX/EX04/manipComplex.rb”. It corresponds to the example “RUBY/EX17/manipComplex.rb” described in section IV.2.4.6. Some of the methods in ruby extension involve Complex arguments. As complex numbers are not accepted by the COM component, these numbers are replaced by an Array of two real values corresponding to the real and imaginary parts of the complex number respectively. This means that the following statements, valid when FeResPost ruby extension is used:

            Z=Complex.new(3.0,2.0)

            multRI=resRI.clone
            multRI*=Z

become the following statements when the COM component is used:

            Z=Complex.new(3.0,2.0)

            multRI=resRI.makeCopy()
            multRI=multRI.opMul([Z.real,Z.image])

VII.1.4 Using component for CLA analyses

One presents in the following sub-sections various examples of programs in which the COM component is used to perform CLA analyses.

VII.1.4.1 Laminate shear properties and load response

This example is stored in file “COMEX/EX05/testShear.rb”. It corresponds to the example “RUBY/EX14/testShear.rb” described in section IV.3.5.

No remark to be done about this example.

VII.1.4.2 Laminate load response with FE Results

This example is stored in file “COMEX/EX05/testClaFem.rb”. It corresponds to the example “RUBY/EX15/testClaFem.rb” described in section IV.3.6. Just one remark about this example: the COM methods do not accept the ruby “Hash” arguments. Therefore, this argument must be translated into Arrays the elements of which are Arrays of two elements corresponding to the keys and values respectively. In ruby, this operation is done by calling the “to_a” method of Hash class. For example, the insertion of allowables in a Laminate is done as follows:

         lam=compDb.getLaminateCopy(6)
         allowables={}
         allowables["sc"]=200.0e6
         allowables["s1c"]=200.0e6
         ...
         allowables["s12"]=100.0e6
         allowables["ilss"]=30.0e6
         lam.insertAllowables(allowables.to_a)
         compDb.insertLaminate(lam)

The example is also translated in python in file “COMEX/EX05/testClaFem.py”. Then, the “items” method of “map” class is used to produce an Array suitable for allowables insertion:

         lam=compDb.getLaminateCopy(6)
         allowables={}
         allowables["sc"]=200.0e6
         allowables["s1c"]=200.0e6
         ...
         allowables["s12"]=100.0e6
         allowables["ilss"]=30.0e6
         lam.insertAllowables(allowables.items())
         compDb.insertLaminate(lam)

Note also the use of “Dispatch” method in python to retrieve Result objects from an Array like in the following statements:

         for tab in outputs:
            id=tab[0]
            res=Dispatch(tab[1])
            util.printRes(os,id,res)

(We presume that the “Dispatch” statement is necessary to convert a VARIANT.)

VII.1.4.3 Laminate failure criteria with FE stresses and strains

This example is stored in file “COMEX/EX05/testCriteria.rb”. It corresponds to the example “RUBY/EX15/testCriteria.rb” described in section IV.3.6. No remark is to be done about this example.

VII.1.5 Superelements

The COM examples in directory “TESTSAT/COM/EX27” are a simple translation of the ruby example discussed in section IV.2.11. COM examples are written in ruby language and do not differ much from the examples using ruby extension.

VII.1.6 Object-oriented post-processing

In directory “COMEX/EX07”, one presents the source files of an object-oriented post-processing using the COM component. This is a transposition of the “PROJECTb” post-processing described in Chapter X.E.4. Modifications in the ruby sources are done to adapt the instructions to the fact that COM component is used instead of ruby extension. Also a few calls to the garbage collector have been added.

VII.1.7 XDB attachment Results access with RUBY and COM

In directory “COMEX/EX08”, one presents the source files of examples illustrating the access to Results from XDB attached files. The four examples correspond exactly to the ones presented in section IV.2.4.7 for the use of ruby extension. Except for the few first lines, the examples are identical. One does not discuss the programming details here.

VII.1.8 Using COM component with excel

One advantage of programming FeResPost as a COM component, is that this allows to use the component from other applications. For example, FeResPost can be used from Excel provided one accepts to write some programming functions and subroutines in VBA. Several examples illustrate the benefits of using FeResPost from excel:

VII.1.9 An Excel workbook illustrating the use of SQL databases

This example is presented in excel workbook “blob_test.xlsm” in directory “TESTSAT/COMEX/EX11” correspond approximately to the ruby examples of section IV.2.6. In this case, one uses the “SQLite for Excel" extension found on “http://sqliteforexcel.codeplex.com/”. The corresponding libraries and VBA Module are distributed with the example in sub-directories. Very small modifications have been brought to the VBA code “SQLite for Excel" to deal with the blobs produced by FeResPost. (See the “SQLite3” module in the sources that correspond to the corresponding Module found on “http://sqliteforexcel.codeplex.com/” + a few modifications.

Worksheet “MANIP” in the workbook corresponds to two VBA macros that perform operations very similar to those of the ruby example of section IV.2.6. These macros and a few more are defined in Module “FeResPost_Results” that contains the code for the example.

More information on the use of FeResPost with VBA is given in Chapters VII.2, VII.3 and VII.4. Note also that the installation of “SQLite for Excel" extension in subdirectories of the example directory is not necessarily a good idea. The extension should be installed in a proper directory if you want to use it for other applications. Then a tuning of some directory names in VBA source code will be necessary.

Note also that COM wrappers of SQLite are also available and may be used with VBA language. (See the following address “http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers” if you are interested.) Of course, the use of databases other than SQLite is also possible (MySQL, PostGreSQL...).

Chapter VII.2
CLA analyses in excel

In the examples of section VII.1.4, one shows how the FeResPost COM component can be used to automate CLA calculations with different programming languages. However, the small programs done with these examples are not significantly different than the programs presented in Chapter IV.3.

One presents here an example in which the COM component is used in excel and allows to perform operations where the capabilities of excel and FeResPost are used together to produce a small application devoted to CLA calculations. The example is presented in excel spreadsheet “COMEX/EX06/LaminateAnalysis.xlsm”.

The presentation of the example is organized as follows:

The example is meant to be the presentation of a small application devoted to classical laminate analysis. This application is highly customizable provided the user is ready to adapt it to its needs by modifying the spreadsheets and the associated VBA programming.

VII.2.1 Preparing the application

Before using the excel workbook, the FeResPost COM component must be referenced. This is done as follows:

Once this has been done, you may save the excel workbook so that the references to FeResPost library shall be “remembered” the next time you open the workbook.

If a FeResPost COM server is already referenced in the workbook when you open it the first time. (As it probably will be the case with the workbook you download from FeResPost web site.) You must first un-select the old reference to FeResPost server, before selecting the new one. You will have to perform this operation each time you install a new version of FeResPost COM server on your computer.

When you change the version of FeResPost, you must also modify the variable “appName” in the VBA code associated to “ClaDbIds” spreadsheet of the workbook. The corresponding line looks like:

   Const appName As String = "FeResPost_4_5_4.Application"

VII.2.2 Workbook events

Two events are defined in the workbook:

VII.2.3 Spreadsheets

One presents below the different spreadsheets defined in the workbook. Most of these spreadsheets also contain associated VBA functions and variables. Generally, these are used for the spreadsheet buttons automation.

VII.2.3.1 Spreadsheet “HiddenData”

This spreadsheet is hidden. But you can make it “Visible” with the VBA editor. The spreadsheet contains the definition of several list that are used by the automation buttons of the other spreadsheets in the workbook. No VBA functions or variables are associated to “HiddenData” spreadsheet.

VII.2.3.2 Spreadsheet “NeutralLines”

This spreadsheet is hidden. But you can make it “Visible” with the VBA editor. The spreadsheet contains the neutral lines corresponding to a ClaDb object in NDF format. (See the presentation of “ClaDbIds” spreadsheet for more information.) No VBA functions or variables are associated to “NeutralLines” spreadsheet.

VII.2.3.3 Spreadsheet “ClaDbIds”

This is the spreadsheet that manages the access to the COM server and the ClaDb composite database used for calculations. This is the first spreadsheet in which you have to go to start the application.

The spreadsheet contains several buttons, and information on the entities available in the current dataBase appear in the cells: lists of materials, laminates and loads. Each entity in the current dataBase is characterized by:

The integer and string id correspond to the CLA idfier of the entity. The excel ID is a String representation of this idfier that allows to refer to the entities in the other spreadsheets. The spreadsheet defines several buttons:

Several macros are defined in the spreadsheet. Most of these macros perform the different operations done by the buttons. You can access to the macros by the VBA editor. At the beginning of VBA program lines, several variables are defined:

                Dim frpApp As Variant
                Dim db As Variant
                Dim maxEntitiesNbr As Long
                Const maxPliesNbr As Long = 100
                Const appName As String = "FeResPost_3_4_0.Application"
                Const logFileName As String = "FeResPost_LaminateAnalysis.log"

frpApp is the variable that contains a reference to the FeResPost COM server. db contains the ClaDb composite dataBase in which all composite entities are stored. Only one ClaDb dataBase can be opened in the workbook. The variable “appName” is a constant that corresponds to the name of the server. You will have to change this variable when you change the version of FeResPost.

The logFileName variable is used to redirect FeResPost output messages. This is necessary, as with excel, FeResPost is not run in console mode. Practically, the redirection is programmed as follows in “getApplication” method:

          fullLogName = ActiveWorkbook.Path + "\" + logFileName
          frpApp.openMsgOutputFile fullLogName, "w+"
          frpApp.writeAboutInformation

VII.2.3.4 Spreadsheet “DbUnitsEdit”

The spreadsheet allows to manipulate the units in which The CLA database and its entities are expressed:

Remember that the difference between the “SetUnits*” and “ChangeUnits*” methods is that the second group of methods perform units conversions between old and new units. The “SetUnits*” methods modifies the units associated to entities without modifying the values of the different quantities.

Presently, the workbook does not allow to modify the system of units of CLA entities individually. This could be done by the addition of a few buttons in the corresponding “MatEdit”, “LamEdit” and “LoadEdit” worksheets. We think however that it is a bad idea to try to define CLA entities with different units in a same database. Actually, the number of buttons defined in “DbUnitsEdit” spreadsheet is probably already too large.

VII.2.3.5 Spreadsheet “MatEdit”

This spreadsheet is used to edit materials defined in the current dataBase. New materials can also be added. The spreadsheet contains two buttons:

The material IDs and properties are defined by filling the different cells where appropriate.

VII.2.3.6 Spreadsheet “LamEdit”

This spreadsheet is used to edit laminates defined in the current dataBase. New laminates can also be added. The spreadsheet contains three buttons:

The laminate IDs and properties are defined by filling the different cells where appropriate.

VII.2.3.7 Spreadsheet “LoadEdit”

This spreadsheet is used to edit loads defined in the current dataBase. New loads can also be added. The spreadsheet contains two buttons:

The load IDs and properties are defined by filling the different cells where appropriate.

VII.2.3.8 Spreadsheet “MatProperties”

This spreadsheet calculates material properties for a material defined in the current composite dataBase. The two buttons allow to select an existing material and the orientation wrt which material properties are calculated.

The spreadsheet makes use of several functions defined in “calcMatProperties” VBA module.

VII.2.3.9 Spreadsheet “LamProperties”

This spreadsheet calculates laminate properties for a laminate defined in the current composite dataBase. The two buttons allow to select an existing laminate and the orientation wrt which laminate properties are calculated.

The spreadsheet makes use of several functions defined in “calcLamProperties” VBA module.

VII.2.3.10 Spreadsheet “LamText”

This spreadsheet allows to visualize the definition of laminates in a format suitable to inclusion in text documents. The spreadsheet makes use of “getLamDescr” function defined in “calcLamProperties” VBA module. This function has two arguments: the name of the laminate, and a list of acronyms that allow to replace material names in laminate description by a shorter name (typically a single letter).

VII.2.3.11 Spreadsheet “LamLoadResponse_A”

This spreadsheet calculates laminate load response for a laminate defined in the current composite dataBase, and a loading also defined in the current dataBase. The buttons allow to select:

The spreadsheet makes use of several functions defined in “calcLamLoadResponse” VBA module. These methods calculate laminate global stress/strain state, ply stresses and strains, and failure indices, reserve factors or equivalent stresses.

VII.2.3.12 Spreadsheet “LamLoadResponse_B”

This spreadsheet performs the same calculations as “LamLoadResponse_A” except that the loading is not extracted from the current composite dataBase. Instead the loading is defined in the spreadsheet by filling the appropriate cells. (No ClaLoad object defined in the composite database is used.) For all the quantities that appear in the spreadsheet, units are those of the laminate object.

VII.2.3.13 Spreadsheet “LamMinMaxCalcArray”

This spreadsheet is used to calculate laminate minimum or maximum reserve factors, failure indices or equivalent stresses for a selection of load cases and criteria. This is the “matricial” version of the calculation where a whole set of load responses are calculated by a single call to one function. This version is generally very efficient when a large number of load cases must be processed. The unit system for components of loading and results is the same as for the laminate.

VII.2.3.14 Spreadsheet “LamMinRfCalcScal”

This is the scalar version of the spreadsheet above. It is generally less efficient. On the other hand, when cells defining applied loads are modified, the amount of re-calculations is reduced. This allows to decrease the calculation time between each cell modification.

VII.2.4 VBA modules

Three VBA modules are defined. The modules define functions that can be used to obtain material properties, laminate properties, or laminate load response. These modules define functions that return results that are generally presented as 1D or 2D arrays, and can be used directly in excel spreadsheets with the appropriate arguments passed as selections of cells. The user should look at the VBA code to understand the different functions.

TIP: to enter a formula that returns a matricial function into an excel spreadsheet, select the target cell, enter the name of the function with the appropriate arguments and press “MAJ+ENTER” simultaneously.

VII.2.4.1 “calcMatProperties” module

These functions return different types of material properties like CMEs, CTEs, stiffness and compliance matrices... Examples of use of these functions are given in spreadsheet “MatProperties”.

VII.2.4.2 “calcLamProperties” module

These functions return different types of laminate properties like CMEs, CTEs, stiffness and compliance matrices... Examples of use of these functions are given in spreadsheets “LamProperties” and “LamText”.

VII.2.4.3 “calcLamLoadResponse” module

The functions calculate laminate load responses. Examples of use of the functions are given in spreadsheets “LamLoadResponse_A”, “LamLoadResponse_B”, “LamMinMaxCalcArray”, “LamMiMaxfCalcScal”.

Note that for several of the functions, the load can be specified different ways depending on the size of the range that defines the loading:

Chapter VII.3
Extraction and manipulation of Results with excel

In directory “COMEX/EX09”, one gives an excel workbook “PostXdbRandom.xlsm” devoted to the post-processing of finite element Results. More precisely, the excel workbook allows to access randomly Nastran XDB results attached to a NastranDb DataBase.

This spreadsheet is not very different than the one presented in Chapter VII.4. Indeed the global organization of the workbook is more or less the same with spreadsheets and modules devoted to specific tasks:

The excel workbook makes use of the FeResPost COM component. This means that the component must be registered and referenced in the workbook. More information on this subject is given in section VII.3.1.

A Samcef version of the workbook is also given in directory “COMEX/EX09” (file “PostDesFacRandom.xlsm”). Its functionalities and principles are very similar to those of Nastran version.

VII.3.1 Preparing the application

Before using the excel workbook, the FeResPost COM component must be referenced. This is done as follows:

Once this has been done, you may save the excel workbook so that the references to FeResPost library shall be “remembered” the next time you open the workbook.

If a FeResPost COM server is already referenced in the workbook when you open it the first time. (As it probably will be the case with the workbook you download from FeResPost web site.) You must first un-select the old reference to FeResPost server, before selecting the new one. You will have to perform this operation each time you install a new version of FeResPost COM server on your computer.

When you change the version of FeResPost, you will also have to modify the variable “appName” in the VBA code associated to “FemDbIds” spreadsheet of the workbook. (More information on this subject is given in section VII.3.1.)

VII.3.2 Accessing the FEM and Results

The spreadsheet is devoted to the management of finite element model and finite element Results. Several buttons can be used:

Note that the reading of a model and Results must be performed before using the other spreadsheets.

VII.3.3 Accessing the FEM and Results

This spreadsheet allows to manipulate the Groups stored in current DataBase. In columns “A” to “G”, one presents several automation buttons that allow to manipulate directly the entities stored in a Group:

Four buttons allow to build new Groups by topological operations on existing Groups. The operations correspond to the four topological operators defined in “Group” class. The “Group1” and “Group2” operands must be existing Groups of the current DataBase. The resulting “Group3” can be already existing in the current DataBase or a new Group set manually.

VII.3.4 Simple extraction of Results

This spreadsheet is used to perform simple extraction of Results but nothing more. (Except that modification of coordinate systems are also done.) Several ComboBoxes allow to define the parameters for the extraction:

When all the parameters have been defined, the “Extract” button performs the extraction and fills cells in the spreadsheet starting at line 15. More precisely, the following operations are done in the corresponding VBA subroutine:

1.

The current NastranDb DataBase is retrieved using method “getDb” of FemDbIds spreadsheet.

2.

The names of selected load case, sub case and result type are used to import Results into the current DataBase. (The XDB file name has been selected in “FemDbIds” spreadsheet.)

3.

The Group corresponding to the selected Group Name is retrieved from the current DataBase. (“getGroupCopy” method of NastranDb class.)

4.

This Group, the selected location and the names of load case, sub-case and result type are used to retrieve a Result from the DataBase using “getResultCopy” method.

5.

The Results stored in the DataBase are removed by calling method “removeAllResults”.

6.

If necessary, the components of the Result are expressed in a new coordinate system by calling “modifyRefCoordSys” of “Result” class.

7.

The previous results are erased.

8.

The data are extracted from the Result and pasted into the spreadsheet starting at line 16.

9.

A title line is added at line 15.

At different steps, an Error message is defined. This error message is printed at line 15 of the spreadsheet is an Error occurs during execution. In most cases, this error is related to inconsistencies in the definition of data. Then the error message should help the user to correct his data.

Note that this spreadsheet should work for real as well as complex Results.

VII.3.5 Extraction of linear combinations Results

The “ResExtractedCombili” worksheet allows the extraction of linear combinations of Results instead of elementary Results. In the VBA programming of the extraction this is simply done by calling method “getXdbAttachmentResultsCombili”. In this example, the linear combinations of Results extracted from the XDB files are limited to:

VII.3.6 Calculation of criteria

The spreadsheet “WorstResExtract” is very similar to “ResExtract”. It is used to illustrate the possibility of writing small post-processing spreadsheets.

In this case, no coordinate system can be specified. Instead, one can select a criterion among a small predefined selection, and an integer number between 1 and 100 corresponding to the number of values that shall be extracted.

When the “Extract” button is clicked, the following operations are performed:

1.

First, the same steps 1 to 5 as in section VII.3.4 are performed. The extracted Result is stored in “res” variable.

2.

The selected criterion is calculated by calling among the methods “deriveScalToScal”, “deriveVectorToScal” and “deriveTensorToScal” the of “Result” class the one that is appropriate. A “tmpRes” Result is created.

3.

One extracts the nbrVals largest values of this “tmpRes” Result by calling “extractResultForNbrVals” method.

4.

Correspondingly, one also extracts the critical values of “res” Result using “extractResultOnResultKeys” method.

5.

Finally, the data are printed in spreadsheet cells with appropriate title lines.

Instead of simply extracting FeResPost pre-defined scalar derived criteria, it should not be very difficult calculated more specific criteria by modifying the spreadsheet and associated VBA code. For example, you can try to modify the spreadsheet and calculate minimum reserve factors instead of maximum Von Mises stress.

The spreadsheet works with real Results only.

VII.3.7 Extraction of dynamic response Results

In this example, one shows how it is possible to use the COM component to investigate the Results of Nastran dynamic response analyses.

The main difference between this example and the simple result extraction of section VII.3.4, is that one no-longer selects a sub-case for Result extraction. Instead, the extraction is done for all the sub-cases corresponding to the specified load case. When Results are printed in the cells, each line corresponds to one sub-case (i.e. to one frequency).

The different entities are sorted in the columns of the spreadsheet. This limits somewhat the number of FE entities for which the Results can be retrieved. This is why the Group in this case is specified directly by defining the integer IDs of their elements and nodes. The Group is also defined by the specification of the type of entities that are inserted (“EntityTypeSelector” ComboBox).

One also decided to extract only one component for each value.

When all the parameters have been defined, the “Extract” button performs the following operations in the corresponding VBA subroutine:

1.

The current NastranDb DataBase is retrieved using method “getDb” of FemDbIds spreadsheet.

2.

The names of the different sub-cases found in the XDB file are retrieved by method “getXdbScNames” of “NastranDb” class and stored in an Array of Strings. This list of sub-case is used for the reading of Results from XDB file.

3.

The names of selected load case, sub case and result type are used to import Results into the current DataBase. (One imports the Results for one load case, one Result type and all the sub-cases.)

4.

The Group corresponding to the type of entities and the list of integers defined at left part of the spreadsheet is created. This Group shall be used to extract Results from the DataBase.

5.

One uses method “getXdbLcInfos” of “NastranDb” class to obtain information on the load cases and sub-cases defined in the XDB file. The advantage of this method is that it provides the Results by increasing order of frequency and allows to retrieve easily the sub-case names, and their associated frequencies.

6.

Then a loop is done on the difference sub-cases. For each sub-case:

(a)

One extracts the Result on the selected Group.

(b)

One modifies the reference coordinate system if necessary.

(c)

One extract the selected component.

(d)

One retrieves the magnitude and phase for the different entities.

An Array with the data is build. The lines of the Array correspond to the sub-cases. The columns correspond to the different entities and to the magnitude and phase. This Array is stored in variable “ret”.

7.

The previous spreadsheet results are erased.

8.

The content of “ret” Array is pasted into the spreadsheet starting at line 51.

9.

The Results stored in the DataBase are removed by calling method “removeAllResults”.

10.

The two graphics are updated to plot the magnitude and phase for the different entities.

The spreadsheet works with complex Results only.

VII.3.8 Current limitations

It is possible to modify the different spreadsheets described above in order to perform more complicated operations. For example:

(See also the Samcef version of the workbook is also given in directory “COMEX/EX09” and file “PostDesFacRandom.xlsm”.)

Chapter VII.4
An Excel workbook devoted to post-processing

In directory “COMEX/EX10”, one gives an excel workbook “PostProject.xlsm” devoted to the automation of stressing of the satellite.

This example shows how FeResPost COM component can be used to build an excel project defining post-processing methods and data. More precisely, the purpose of this example is to define with excel a post-processing similar to the example of Chapter X.E.4 FeResPost ruby extension.

The advantage of using Excel and COM component, is that it is now possible to use Excel to define the different data of the detailed calculation, and several formatting functions. Actually the definition of data is no longer dispersed in the ruby programming code. At the same time, The use of functions in excel allows to define many things as the sequencing of calculations, the formatting of results, the calculation and archive of results for load cases or not...

Here again, the example is defined in a workbook that contains both worksheets (section VII.4.2) and VBA modules (section VII.4.3).

VII.4.1 Preparing the application

VII.4.1.1 “Optimizing” excel

FeResPost is not programmed as a multi-threaded library, but some versions of excel are (2007 and later versions). Therefore, the multi-threaded calculation should be disabled in excel when FeResPost is used. (See the “advanced options” in excel.)

The use of FeResPost with excel “multi-threaded” option enabled may result in a multiplication of elapsed computing time by a factor 2 approximately.

VII.4.1.2 Referencing FeResPost in VBA

Before using the excel workbook, the FeResPost COM component must be referenced. This is done as follows:

Once this has been done, you may save the excel workbook so that the references to FeResPost library shall be “remembered” the next time you open the workbook.

If a FeResPost COM server is already referenced in the workbook when you open it the first time. (As it probably will be the case with the workbook you download from FeResPost web site.) You must first un-select the old reference to FeResPost server, before selecting the new one. You will have to perform this operation each time you install a new version of FeResPost COM server on your computer.

When you change the version of FeResPost, you will also have to modify the variable “appName” in “DbAndLoadCases” VBA module of the workbook.

VII.4.1.3 Installing “SQLite for Excel”

The application outputs an SQLite database that stores Results for different loadcases. (See “ResultsGMSH” module in section VII.4.3.5.) This means that the corresponding libraries must be installed on your computer. Note that these libraries are provided with the “TESTSAT/COMEX/EX11” example.

The variable “sqliteLibDirName” contains the path to the directory containing the “SQLite3” shared libraries. This variable must be adapted to match your installation.

VII.4.2 Worksheets

Several types of worksheets are defined in the workbook:

VII.4.2.1 “LcSelector” worksheet

This worksheet is used to select the definition of databases and load cases, and to select a sub-set of load cases that shall be post-processed. Two data must be entered “manually” (they appear in blue in the worksheet):

The worksheet also defines several automation buttons:

More information on the archiving of Results and the creation of GMSH files is provided in the sections devoted to the corresponding VBA modules.

VII.4.2.2 Worksheet for Definition of databases and load cases

One or several worksheets defining databases and load cases can be defined in the workbook. However, only one such worksheet can be selected in “LcSelector” worksheet. The content of the worksheet must comply with certain conventions:

VII.4.2.3 Worksheet for Selection of load cases and associated parameters

One or several worksheets define selections of load cases and associated parameters. The first line is a title line. It also defines the names of parameters that are defined for each selected load case. The following lines define the load cases and parameters:

One notes that one load case can be defined in different “selection” worksheets with identical or different parameter values. The “TempLoad” parameter is used here to associate a load case name to an integer ID corresponding to the name of the temperature field used by Nastran to load the structure. This value is used by some post-processing functions to retrieve the temperature fields stored in an SQLite database. (See the “recoverTemp.rb” example in section IV.2.8.5.)

The “FEMDB” parameter name is a reserved one. It allows to force the association of one or several load cases to a particular finite element database. This can be handy when one tries to avoid the definition of too many different databases. The associated value is a String corresponding to the identifier attributed to the database in the databases and load cases definition worksheet.

VII.4.2.4 Post-processing worksheets

Those are the worksheets in which the detailed data of post-processing are defined. Four such worksheets are defined so far: “post_connect” is devoted to the post-processing of connection loads, “post_sandwich” is devoted to the post-processing of stresses in sandwich panels, and “post_composite” uses the function “getCompositeRf” that calculates reserve factors using the classical laminate analysis. Worksheet “post_extract” has been added to illustrate the extraction of Results on lists of elements and/or nodes defined explicitly in ranges of cells.

These worksheets mainly use the functions defined in “ExtractionCriteria”, "ResultsExtraction", and “ResultsArchiver” modules. Basically, they define the data, and perform the call to functions of these modules. One makes several remarks about the use of these worksheets:

VII.4.2.5 “envelopeGMSH” worksheet

This worksheet is used to generate “manually” the GMSH files containing the envelopes of Results. More precisely, a selection of load cases is read, and the corresponding Results retrieved from “” SQLITE database are retrieved and used to generate envelopes of Results that shall be saved in GMSH files.

This is done by clicking the “Save GMSH envelope” button. The arguments of the corresponding subroutine are stored in two cells:

VII.4.3 VBA modules

One presents below the different modules that have been defined in the project.

VII.4.3.1 “DbAndLoadCases” VBA module

This module is closely related to the definition of databases and load cases. It manages the recovery of information needed to create the databases, and to generate and read the Results corresponding to the different load cases. Several variables corresponding to the lists of databases, elementary and combined load cases are defined in the module. For example:

Also this module provides functions that allow to retrieve Results or load case information. Several such functions deserve more explanation:

These methods are mentioned here because they are used in “ExtractCriteria” module to program post-processing operations. The user that wishes to modify the post-processing criteria will use these functions.

VII.4.3.2 “ExtractionCriteria” VBA module

Among other things, one defines in that module the different functions called in post-processing worksheets to perform specific post-processing operations. As this module defines many functions that can be called from post-processing worksheets, a separate section is specifically devoted to this module. (See section VII.4.4.)

VII.4.3.3 “ResultsExtraction” VBA module

The module defines the “extract” function that is used to extract values on selections of elements and nodes explicitly defined in the post-processing worksheet. This function is matricial as the different functions defined in “ExtractionCriteria” VBA module. The arguments of this function are:

1.

A String corresponding to the type of entities on which the values are extracted. Possible values are “E” for elements, “N” for nodes or “EN” for pairs of elements and nodes.

2.

A selection defining the list of entities on which the values are extracted. The values in the selection must be of integer type. The selection must have two columns if the first parameter is “EN”, one column otherwise.

The number of lines or the matrix returned by the function matches the number of lines of this selection.

3.

A String corresponding to the name of the current load case.

4.

A String corresponding to the type of Result that is requested.

5.

A String or Integer corresponding to the layer on which values are extracted.

6.

A String or Integer corresponding to the coordinate system in which the components are given.

7.

A String corresponding to the name of the component that is requested. If this argument is “NONE”, all the components are returned.

The use of this function is illustrated in “post_extract” worksheet. So far the example worksheet only performs extraction operations without using the extracted values in post-processing.

The actual exploitation of extracted Results could be done directly by calculations in the excel worksheet. ‘ResultsExtraction” VBA module corresponds to a type of operation that is very often done in aeronautics. For example, when wings or fuselages are stressed, one often works with finite element models characterized by a structured numbering of elements and nodes that allow to easily extract shell forces or stresses for panels, beam forces for elements representing stringers or frames... This allows to estimate loads on rows of connections, assess the risk for a panel to buckle...

VII.4.3.4 “ResultsArchiver” VBA module

This module and the associated variables manage the archiving of Results. One of the module variables is a collection of arrays called “archiveList”. Each element in the collection contains the information necessary to archive one Result for later re-use:

The elements of each array correspond actually to the arguments of function “saveToArchive” used in post-processing worksheets. ‘saveToArchive” function returns a string that allows a check of the validity of arguments. It is the calculation of these functions that fills the “archiveList” collection in the module. This means that a recalculation of the worksheets must be performed before the archiving of Results. (By pressing “ArchiveResults” button in “LcSelector” worksheet for example). Also, the calculation of worksheets must be redone after pushing “ReinitArchiveResults” button in “LcSelector” worksheet. Indeed, the “ReinitArchiveResults” button clears the “archiveList” collection. This “clearing” operation may be useful to re-create the “archiveList” collection after a modification of the post-processing worksheets.

VII.4.3.5 “ResultsGmsh” VBA module

This module is used in the management of Results to be saved in GMSH files. To some extent, this module is similar to “ResultsArchiver” VBA module: it manages a outputsList module collection that contains the characteristics of Results to be saved, and the Results themselves.

One difference with “ResultsArchiver” VBA module is that the methods of “ResultsGmsh” are never called directly from the post-processing worksheets. Instead, methods from other VBA modules in the project call the methods of “ResultsGmsh”. For example, nearly all the methods of “ExtractionCriteria” module use “ResultsGmsh” to save envelope of Results in GMSH files. Indirectly, the user defines associated parameters in optional arguments of the post-processing functions defined in “ExtractionCriteria” module. (See section VII.4.4.)

The module defines several global variables:

VII.4.3.6 “Sqlite3” VBA module

Sqlite3 VBA module contains the VBA code devoted to the management of SQLite databases in Excel. This module is exactly the same as the one used in Small COM example 11. The reader is referred to section VII.1.9 for more information.

In this workbook, “Sqlite3” VBA module is used to generate a database containing for each load case the maximum stress or “failure indices”. These can be read a posteriori to save envelopes generated “manually” in GMSH files.

Note that the SQLite3 module is used by “ResultsGmsh” VBA module. This module generates all the SQLite3 operations, from the generation to the exploitation.

VII.4.3.7 “UTIL” VBA module

This module defines subroutines and functions that can be used from several different locations in the VBA project. For example:

These methods are called from several locations in the VBA module, but should never be used directly from an excel spreadsheet of the project.

VII.4.4 “ExtractionCriteria” VBA module

The module defines several functions for extracting and manipulating Results. For example, the extraction of maximum Von Mises stress on a Group of elements, the calculation of honeycomb worst element and associated reserve factor, or the calculation of reserve factors for different connection criteria. One notes that:

The module is the one that the user is most likely to modify to define new post-processing criteria. However, one advises those who wish to create their own criteria to define a new module called for example “UserCriteria” to develop their own functions.

VII.4.4.1 Post-processing of stress Results

VII.4.4.1.1 “getVonMisesMax” function

Function “getVonMisesMax” in “ExtractionCriteria” VBA module extracts the maximum Von Mises equivalent stress on a Group of elements and on a selection of layers. The arguments of the function are:

1.

A String corresponding to the name of the load case for which stresses are extracted.

2.

A String corresponding to the location of extraction points on the elements. (For example: “Elements”, “ElemCenters” or “ElemCorners”.)

3.

A selection of layers. This is a range of cells containing Integer or String values that are converted to a list of layers by “layersFromRange” method of “UTIL” VBA module.

4.

A String corresponding to the Group of elements on which stresses are extracted.

5.

Two optional String arguments corresponding to the name of the GMSH file in which the envelope of maximum equivalent stress shall be saved, and the name of the Result by which the Result is referred to in GMSH.

The function returns an Array of one line and six columns:

1.

The element ID for maximum equivalent stress,

2.

The node ID for maximum equivalent stress,

3.

The layer ID for maximum equivalent stress,

4.

The sub-layer ID for maximum equivalent stress,

5.

The coordinate system ID which is always “NONE”,

6.

The maximum Von Mises equivalent stress.

The use of “getVonMisesMax” is illustrated in “post_sandwich” spreadsheet.

VII.4.4.1.2 “getShellVonMisesMax” function

Function “getShellVonMisesMax” in “ExtractionCriteria” VBA module extracts the maximum Shell Von Mises equivalent stress on a Group of elements and on a selection of layers. The arguments of the function are:

1.

A String corresponding to the name of the load case for which stresses are extracted.

2.

A String corresponding to the location of extraction points on the elements. (For example: “Elements”, “ElemCenters” or “ElemCorners”.)

3.

A String corresponding to the Group of elements on which stresses are extracted.

4.

Two optional String arguments corresponding to the name of the GMSH file in which the envelope of maximum equivalent stress shall be saved, and the name of the Result by which the Result is referred to in GMSH.

The function returns an Array of one line and six columns:

1.

The element ID for maximum equivalent stress,

2.

The node ID for maximum equivalent stress,

3.

The layer ID for maximum equivalent stress,

4.

The sub-layer ID for maximum equivalent stress,

5.

The coordinate system ID which is always “NONE”,

6.

The maximum Von Mises equivalent stress.

The difference between “getShellVonMisesMax” and “getVonMisesMax” is that one does not need to provide a selection of layers argument: the extraction is automatically done on layers “Z1” and “Z2”. The function returns a single value: the maximum Von Mises equivalent stress. The use of “getShellVonMisesMax” is illustrated in “post_sandwich” spreadsheet.

VII.4.4.1.3 “getHoneycombCoreAirbusRF” function

Function “getHoneycombCoreAirbusRF” in “ExtractionCriteria” VBA module calculates the minimum honeycomb reserve factor on a Group of elements using the so-called “Airbus” criterion:

RF = 1 FoS (τL σL ) 2 + (τW σW ) 2,

in which τL and τL are the honeycomb longitudinal and transverse shear components of Cauchy stress tensor and σL and σW the corresponding allowables.

The arguments of the function are:

1.

A String corresponding to the name of the load case for which Cauchy stress tensor is extracted.

2.

A String corresponding to the location of extraction points on the elements. (For example: “Elements”, “ElemCenters” or “ElemCorners”.)

3.

A String corresponding to the Group of elements on which stresses are extracted.

4.

A String corresponding to the layer on which stresses are extracted.

5.

A Real safety factor.

6.

A Real value corresponding to the honeycomb longitudinal shear stress allowable σL.

7.

A Real value corresponding to the honeycomb transverse shear stress allowable σW .

8.

Two optional String arguments corresponding to the name of the GMSH file in which the envelope of maximum equivalent stress shall be saved, and the name of the Result by which the Result is referred to in GMSH.

The function returns an Array of one line and eight columns:

1.

The element ID for minimum reserve factor,

2.

The node ID for minimum reserve factor,

3.

The layer ID for minimum reserve factor,

4.

The sub-layer ID for minimum reserve factor,

5.

The coordinate system ID for minimum reserve factor,

6.

The value of longitudinal shear stress τL for minimum reserve factor,

7.

The value of transverse shear stress τW for minimum reserve factor,

8.

The minimum reserve factor.

The use of “getHoneycombCoreAirbusRF” is illustrated in “post_sandwich” spreadsheet.

VII.4.4.1.4 “getHoneycombCoreMaxShearRF” function

Function “getHoneycombCoreMaxShearRF” in “ExtractionCriteria” VBA module calculates the minimum honeycomb reserve factor on a Group of elements using a maximum shear criterion:

MoS = σW FoS * τ - 1,

in which τ is the maximum shear stress and σW the transverse shear allowable.

The arguments of the function are:

1.

A String corresponding to the name of the load case for which Cauchy stress tensor is extracted.

2.

A String corresponding to the location of extraction points on the elements. (For example: “Elements”, “ElemCenters” or “ElemCorners”.)

3.

A String corresponding to the Group of elements on which stresses are extracted.

4.

A String corresponding to the layer on which stresses are extracted.

5.

A Real safety factor.

6.

A Real value corresponding to the honeycomb longitudinal shear stress allowable σL. (This allowable is not used in the calculation.)

7.

A Real value corresponding to the honeycomb transverse shear stress allowable σW . (Only this allowable is used in the calculation.)

8.

Two optional String arguments corresponding to the name of the GMSH file in which the envelope of maximum equivalent stress shall be saved, and the name of the Result by which the Result is referred to in GMSH.

The function returns an Array of one line and eight columns:

1.

The element ID for minimum reserve factor,

2.

The node ID for minimum reserve factor,

3.

The layer ID for minimum reserve factor,

4.

The sub-layer ID for minimum reserve factor,

5.

The coordinate system ID for minimum reserve factor,

6.

The value of longitudinal shear stress τL for minimum reserve factor,

7.

The value of transverse shear stress τW for minimum reserve factor,

8.

The minimum reserve factor.

The use of “getHoneycombCoreMaxShearRF” is illustrated in “post_sandwich” spreadsheet.

VII.4.4.2 Post-processing of connection loads

For the post-processing of connection loads, the first step of the calculations is always to estimate for each connection the axial force, the shear force, the torsional moment and the bending moment. Afterwards the criterion for the connection is calculated (sliding, gapping, insert, rivet...). More precisely, one calculates the critical connection (node or element) and the associated reserve factor.

VII.4.4.2.1 Calculation of the different components of connection loads

One explains here how the components of loading (axial and shear forces, torsional and bending moments) are first calculated for the different connections before the calculation of reserve factors for a selected criterion.

The parameters used for the calculation of these connection load components are always the first 6 parameters of the connection criterion function:

1.

The name of the load case for which the calculation is done.

2.

The name of a first Group (group1) corresponding generally to a part of the structure to which the connections are connected (sandwich panel, shell, metallic fitting...).

3.

The name of second Group (group2) of finite element entities corresponding generally to the modeling of the connections (For example RBE2 elements, CBAR or CBUSH elements...).

4.

A String corresponding to the type of operations done to build the different components of connection loads. This String determines which Results are first read from Result files, and how they are manipulated afterwards. More information about this parameter is given below.

5.

An integer or String value corresponding to the coordinate system in which the force and moment vectors are to be expressed before extracting the different force and moment components.

6.

A vector of three real values corresponding to the axis of the connection in the coordinate system given by the previous argument. The direction of this vector must be defined in such a way that a positive axial force corresponds to a tension in connection. For example, when internal forces are extracted from Grid Point Forces results, this is achieved by defining the vector pointing from grp2 to grp1 (to the direction of the group containing the elements from which Grid Point Forces are extracted.)

Presently, the available extraction methods for the load components, given by the fourth argument above are the following:

When the option “BMFRC” is adopted, the loads are extracted on the “beam-type” elements modeling the connections (CBUSH elements for example). This means that the only the second Group argument (third argument of the function) matters. The first Group argument is not considered. In all other cases, Group operations are done to obtain a list of nodes which is the intersection of the two Group arguments provided. More precisely, the Group “targetGrp” is build as follows:

    If extractionMethod = "BMFRC" Then
        Set targetGrp = grp2
    Else
        Set nodeGrp1 = db.getNodesAssociatedToRbes(grp1)
        Set tmpGrp1 = db.getNodesAssociatedToElements(grp1)
        nodeGrp1.importEntitiesByType "Node", tmpGrp1

        Set nodeGrp2 = db.getNodesAssociatedToRbes(grp2)
        Set tmpGrp2 = db.getNodesAssociatedToElements(grp2)
        nodeGrp2.importEntitiesByType "Node", tmpGrp2

        Set tmpGrp3 = nodeGrp1.opMul(nodeGrp2)
        Set tmpGrp2 = db.getElementsAssociatedToNodes(tmpGrp3)
        Set tmpGrp1 = grp1.opMul(tmpGrp2)
        Set targetGrp = tmpGrp1.opAdd(tmpGrp3)
    End If
        

Depending on the type of extraction, and on specific aspects of the problem, the correspondence between grp1 and grp2 on one side and the connections or assembled part may differ. For example:


PICTPICT

Figure VII.4.1: Example of assembly of different layers with a single connection.

All the operations are managed by subroutine “getConnectionLoads” of “ExtractionCriteria” VBA module. This subroutine is called by each of the connection post-processing function. This is why the six parameters (eight values) of these connection post-processing functions are always the same.

VII.4.4.2.2 “getSlidingRF” function

This function calculates reserve factors for the sliding criterion with the following expression:

RF = Cf * Pmin FoS * (Cf * max (Faxial, 0) + Fshear) ,

in which Cf is the friction coefficient between assembled elements and Pmin is an estimate of the minimum possible pretension of the bolt. Parameters specific to this function are:

The function returns an Array of one line and four columns containing:

VII.4.4.2.3 “getGappingRF” function

This function calculates reserve factors for the gapping criterion with the following expression:

RF = Pmin FoS * (max (Faxial, 0) + MbendingR),

in which R is a parameter that allows to take into account the prying effect related to the bending moment in the connection and Pmin is an estimate of the minimum possible pretension of the bolt. Parameters specific to this function are:

The function returns an Array of one line and four columns containing:

VII.4.4.2.4 “getInsertRF” function

This function calculates reserve factors for the insert criterion with the following expression:

RF = 1 FoS (Faxial PSS ) 2 + (Fshear QSS ) 2,

In which “PSS” is the axial allowable of the insert and “QSS” is its shear allowable. Parameters specific to this function are:

The function returns an Array of one line and four columns containing:

VII.4.4.2.5 “getShearBearingRF” function

This function calculates reserve factors for the shear-bearing failure mode with the following expression:

RF = ShrAll FoS * Fshear,

in which ShrAll is the shear bearing allowable. Parameters specific to this function are:

The function returns an Array of one line and three columns containing:

VII.4.4.2.6 “getPullThroughRF” function

This function calculates reserve factors for the pull-through failure mode with the following expression:

RF = PullAll FoS *max (Faxial,PullAll * 10-9) ,

in which PullAll is the pull-through tensile allowable. Parameters specific to this function are:

The function returns an Array of one line and three columns containing:

VII.4.4.3 composite post-processing

Function “getCompositeRF” of “ExtractionCriteria” VBA module calculates reserve factors using the classical laminate analysis. More precisely, the Shell Forces and Moments are recovered on shell elements with laminated properties (PCOMP or PCOMPG properties), and the layered reserve factors are calculated using “calcFiniteElementResponse” method of the generic Database class. Note however that one limitation of this post-processing function is that no thermo-elastic or hygro-elastic contribution is taken into account in the post-processing. Reserve factors are generally calculated at mid thickness of each layer. One exception is the inter-laminar shear stress reserve factor which is calculated at bottom sub-layer of the selected plies.

Function “getCompositeRF” has the following arguments:

1.

The name of the load case for which the calculation is done.

2.

The location(s) in elements of the points at which reserve factors will be calculated. (For example “ElemCenters” or “ElemCorners”.)

3.

The name of a Group on which the reserve factors are calculated.

4.

The name of the failure criterion for which reserve factors are calculated. (The list of available criteria is summarized in Table II.1.2.)

5.

A selection of cells containing the list of layers on which the composite criterion is to be estimated.

6.

The factor of safety.

7.

Two optional String arguments corresponding to the name of the GMSH file in which the envelope of inverse reserve factors shall be saved, and the name of the Result by which the Result is referred to in GMSH.

The function returns an Array of one line and five columns containing:

1.

The element ID for minimum reserve factor.

2.

The node ID for minimum reserve factor.

3.

The layer ID for minimum reserve factor.

4.

The sub-layer ID for minimum reserve factor.

5.

The minimum reserve factor.

The use of “getCompositeRF” function is illustrated in “post_composite” worksheet.

“getCompositeRF2” function defined in “UserCriteria” Module is a variant of “getCompositeRF” with two additional arguments:

Note that one explains in section IV.2.8.5 how the SQLite database containing the temperature Results can be produced.

“getCompositeRF3” function defined in “UserCriteria” Module is a variant of “getCompositeRF” that calculates laminate failure criteria directly from the stresses extracted from finite element model results. This function has been used to test the different variants of the functions calculating laminate criteria. The arguments of this function are the same as those of “getCompositeRF” function.

Part VIII
FeResPost as .NET assembly

Chapter VIII.0
Introduction

On Windows OS, FeResPost is distributed at the same time as a ruby extension, a COM component and as a .NET assembly. One describes in this Part several characteristics of FeResPost as a .NET assembly.

In general, the class names, their methods and attributes (properties), the parameters of these methods and attributes are the same as those available in the FeResPost ruby extension. When necessary, modifications have been done in the ruby extension in order to maintain as much as possible the compatibility between the ruby extension and the .NET assembly. Therefore, the user is referred to Parts I, II, III and IV to find information on the use of the different classes and methods. In most cases, the information given there is sufficient to use the .NET assembly.

However, an exact match between the ruby extension and .NET assembly is not possible. One details below the conventions that have been adopted when incompatibility problems were not solved. More generally, one explains here the specific aspects of the use of FeResPost as a .NET assembly.

This Part of the document is organized as follows:

The installation of the .NET assembly is described in section X.A.4.6.

In the different sections of this chapter, one describes conventions that have been adopted when translating the ruby extension into a .NET assembly. Information is given each time the ruby methods are modified to be implemented into the .NET assembly. For example, this is done for iterators, operators, “clone” method... Also one explains how objects are created with the assembly.

One highlights below some differences between .NET assembly and ruby extension that are related to specific programmatic aspects of the two different systems.

VIII.0.1 Accessing the .NET assembly

If FeResPost assembly is installed into global assembly cache, no peculiar operation is necessary to access it from IronRuby. If FeResPost is not installed in global assembly cache, a path must be provided to IronRuby to retrieve the library. This is done, for example, with the “-I” option.

When compiling a C# program, the library must be referenced at compile-time with the “-r” option. For example:

        csc.exe -r:../../../SRC/OUTPUTS/NET/FeResPost.dll ...

This referencing must be done, even if the library is installed in global assembly cache. Note however, that after compiling the C# client program, this program can be moved elsewhere independently of the FeResPost assembly, if this assembly has been installed in Global Assembly Cache.

We assume that was is true for IronRuby, shall be true for other .NET interpreted languages as well. Similarly, what is true for C# compiled programs is applicable for other CLI compiled languages (C++/CLI or VB/CLI).

VIII.0.2 Accessing FeResPost namespace

All classes of the FeResPost .NET assembly are defined in “FeResPost” namespace. To simplify the access to FeResPost classes and methods, it is recommended to give access to the content of the namespace.

In ruby, this is done by including FeResPost Module into the current workspace:

   ...
   include FeResPost
   ...

In C#, one uses using directives:

    ...
    using FeResPost ;
    ...

The same is true for C++.NET language, but with a different syntax:

    ...
    using namespace FeResPost ;
    ...

VIII.0.3 Creating class instances

The creation of FeResPost objects depends on the language with which .NET assembly is used. In all cases, the “new” operator is used. For example to create a ClaDb object in ruby, one writes:

    ...
    db=ClaDb.new
    ...

The same operation is done as follows in C#:

    ...
 ClaDb db;
    db=new ClaDb();
    ...

(Note that the variable db has been declared before being initialized.)

VIII.0.4 Basic types as arguments and returned values

In FeResPost .NET assembly, the following default types are used for parameters:

The different classes defined in FeResPost assembly are reference managed classes. The examples given in Part IX should clarify the use of arguments.

VIII.0.5 Associative containers and Arrays

When methods of ruby extension receive or return Array objects, .NET assembly also returns Arrays of different types of objects. The difference is that .NET Arrays may have several dimensions. For example, the C++/CLI definition of several methods of the ClaLam class reads as follows:

    ...
    array<float,2>^ get_ABBD(...array<float>^ varargs) ;
    array<float,2>^ get_G(...array<float>^ varargs) ;
    array<float>^ get_alfaEh1(...array<float>^ varargs) ;
    ...

The two first methods above return 2D arrays, instead of 1D arrays of 1D arrays, for ruby extension.

Similarly, when a FeResPost method of ruby extension receives or returns a Hash object, the corresponding method of .NET assembly deal with a Dictionary. For examples, the methods of CLA classes devoted to management of units are declared as follows:

    ...
    System::Collections::Generic::Dictionary<System::String^,
            System::String^>^ getUnits(void) ;
    void setUnits(System::Collections::Generic::Dictionary<
            System::String^,System::String^>^ Units) ;
    void changeUnits(System::Collections::Generic::Dictionary<
             System::String^,System::String^>^ Units) ;
    ...

VIII.0.6 Iterators

.NET provides a standard interface that allows the writing of iterators on collections of different types. In FeResPost, all the iterators are based on two classes:

As for the COM component, two classes devoted to iterations have been added because it does not seem possible to create a class that proposes several enumerators.

The “Iterator” class is common to all the iterators of all the FeResPost classes. But an Iterator object behaves differently depending on the class that produces it and/or the method of the class that is used to produce it.

Let us illustrate it by an example... Consider the “each_ply” iterator defined in ClaLam class of FeResPost ruby extension. With the ruby extension, the iteration on the plies of a laminate may be performed as follows:

   ...
   lam.each_ply do |plyDescr|
      ...
   end
   ...

With FeResPost .NET assembly and IronRuby, an Iterator must first be produced before iterating on the elements of the corresponding collection. This can be done as follows:

   ...
   plyIt = lam.iter_ply
   plyIt.each do |plyDescr|
      ...
   end
   ...

This examples illustrates the conventions that have been used when programming the FeResPost .NET assembly to transpose the iterators proposed in the ruby extension:

1.

As in the FeResPost ruby extension, each iterator method name starts with “each_”, correspondingly, the .NET assembly methods returning an Iterator object have a name that starts with “iter_”. The correspondence between ruby extension methods and .NET assembly methods is obvious: “each_ply” becomes “iter_ply”, “each_material” becomes “iter_material”,...

2.

When the .NET iteration method has no argument, it is a property “getter” that is used instead of a method. Otherwise, a method with argument is defined.

3.

In IronRuby using the .NET assembly, the iteration on the Iterator object is done using “each” iteration method.

Note that to the IronRuby lines given as example above, one prefers the shorter notation:

   ...
   lam.iter_ply.each do |plyDescr|
      ...
   end
   ...

VIII.0.7 Operators

Operators are defined in the different classes to which they apply (Group, Result, ResKeyList...). Note that C++/CLI allows to define in managed classes static operators the first operand of which is an object that is not an instantiation of the class. This allows, for example, to define dyadic operators the first operand of which is a float, and the second operand of which a Result object.

VIII.0.8 Singleton methods

Ruby “singleton” methods of FeResPost classes are defined as static functions of FeResPost managed classes.

VIII.0.9 “Clone” and “ToString” methods

Most FeResPost managed classes implement the “ICloneable” interface and define a “Clone” method that corresponds to ruby “clone” method in FeResPost ruby extension. “Post” static class does not derive from ICloneable, as this class can not be instantiated. Also, the classes deriving from “DataBase” (“NastranDb” and “SamcefDb” classes) do not implement the “Clone” method.

The “to_s” method of ruby extension are replaced by “ToString” method in .NET assembly.

VIII.0.10 “Post” static class

FeResPost does not define Modules. The ruby extension “Post” Module is replaced a static “Post” class in .NET assembly. More precisely, “Post” class defines only static methods and no constructor/destructor.

All the methods defined in “Post” module of ruby extension are defined in “Post” static class.

VIII.0.11 Complex arguments

Complex arguments are input as 1D Arrays of two float or double values.

VIII.0.12 FeResPost exceptions

.NET assembly defines a “FrpExcept” class corresponding to all the exceptions raised by FeResPost. The management of exceptions is as with ruby, but is also depends on the programming language. For example, with C#, the management of an exception may look like:

    try {
        NastranDb db=new NastranDb();
        db.Name="tmpDB1";
        //~ db.readBdf("../../MODEL/MAINS/unit_xyz.bdf");
        db.readBdf("../../MODEL/MAINS/brol.bdf");
    }
    catch (FrpExcept ex) {
        Console.WriteLine("\n\nGot an exception of type \"{0}\"\n",ex.GetType());
        Console.WriteLine("FeResPost error message is :\n\n{0}\n",ex.Message);
    }

VIII.0.13 Output for information messages

In general, the selection of output stream for the writing of FeResPost information messages follows the same rules as for ruby extension, as explained in section I.6.1. The default output stream for information messages is “System.IO.Console.Out”. Method “setInfoStreamToClientStream” accepts as argument anyclass that derives from “System.IO.Console.TextWriter” class. Valid arguments are for example a TextWriter object, a StreamWriter object, System.IO.Console.Out, System.IO.Console.Error...

Chapter VIII.1
CLA classes

The different classes described in this Chapter correspond to the classes described in Part II. The methods defined in FeResPost .NET assembly CLA classes are the same as those defined in the FeResPost ruby extension CLA classes, except the peculiar problem of the iterators discussed in section VIII.0.6, and of the “clone” methods that have been replaced by “makeCopy” methods.

Similarly, the arguments defined for the different methods of CLA classes are the same as those for the classes of FeResPost ruby extension, except for the remark done in section VIII.0.5 for the “Hash” arguments or returned values.

In the rest of this Chapter, one makes a few remarks about the different classes. But otherwise, the reader is referred to the different chapters of Part II to find information on the use of .NET assembly CLA classes.

VIII.1.1 “ClaDb” class

No peculiar remark is to be done except for the iterators:

The “Clone” method that returns a copy of the object.

VIII.1.2 “ClaMat” class

Methods returning a 2D matrix, return a an Array with 2 dimensions. These methods are “getCompliance”, “getStiffness”, “getInPlaneCompliance”, “getInPlaneStiffness”, “getOOPSCompliance”, “getOOPSStiffness”, “getInPlaneLambdaT”, “getInPlaneLambdaH”. (In ruby extension, these methods return an array of arrays.)

The “Clone” method that returns a copy of the object.

VIII.1.3 “ClaLam” class

Iterator “each_ply” in ruby extension becomes “iter_ply”.

Methods returning a 2D matrix, return a an Array with 2 dimensions. These methods are “get_ABBD”, “get_G”, “get_abbd_complMat”, “get_g_complMat”, “get_LambdaT”, “get_LambdaH”. (In ruby extension, these methods return an array of arrays.)

Methods that return Ply stresses, strains, temperature or moisture return 2D Arrays of size N*8 or N*3.

The “getDerived”, “getFailureIndices” and “getReserveFactors” methods return Arrays of 2 objects. The second object is a 2D Array in .NET assembly.

Methods “getMaxDerived”, “getMinDerived”, “getMaxFailureIndices”, “getMinFailureIndices”, “getMaxReserveFactors” and “getMinReserveFactors” returns 2 dimensional Arrays of sizes N*3.

The “Clone” method that returns a copy of the object.

VIII.1.4 “ClaLoad” class

No peculiar remark is to be done. The “Clone” method that returns a copy of the object.

Chapter VIII.2
Generic FeResPost classes

Most classes defined in this chapter correspond to the same classes in ruby extension.

The two classes “Iterator” and “IterX” correspond to the iterators defined in the different classes of the NET assembly. These classes are not described in this chapter. Indeed, one considers that the explanations given in section VI.0.2.3 for COM component iterators about the use of iterators is sufficient. No corresponding class exists in the ruby extension.

VIII.2.1 “Post” static class

The “Post” static class corresponds to Presently, these methods are

Note that no dyadic “operator” “op*” is defined in “Post” class, as was done in COM component or ruby extension. Instead, these operators are defined as static operators in the “Result”, “Group” and “ResKeyList” classes

VIII.2.2 Generic DataBase class

This class corresponds to the generic DataBase class of ruby described in Chapter I.1. The class cannot be instantiated; instead, the corresponding specialized classes “NastranDb” and “SamcefDb” that derive from DataBase can be instantiated.

The iterators of the DataBase class in ruby extension have also been defined in COM component: “iter_abbreviation”, “iter_groupName”, “iter_resultKey”, “iter_resultKeyCaseId”, “iter_resultKeySubCaseId”, “iter_resultKeyLcScId” and ‘iter_resultKeyResId” properties in COM component correspond to the “each_abbreviation”, “each_groupName”, “each_resultKey”,
“each_resultKeyCaseId”, “each_resultKeySubCaseId”, “each_resultKeyLcScId” and
“each_resultKeyResId” iterators in ruby extension.

The four singleton methods “enableLayeredResultsReading”, “disableLayeredResultsReading”, “enableSubLayersReading” and “disableSubLayersReading” in the ruby extension generic DataBase class are defined as static methods in NET assembly. No instance of the derived class must be created to use these singleton methods.

Similarly, methods“setStorageBufferMaxCapacity” and “getStorageBufferMaxCapacity” are defined as static methods in DataBase class.

VIII.2.3 Group class

Most methods of the “Group” class are exactly the same as the ones defined in the Group class of ruby extension (Chapter I.3). Several methods or properties are different however:

VIII.2.4 CoordSys class

Methods of the “CoordSys” class are the same as the ones defined in the CoordSys class in ruby extension. The “Clone” method that returns a copy of the object.

VIII.2.5 Result class

Most methods of the “Result” class are exactly the same as the ones defined in the Result class in ruby extension (Chapter I.4). Several methods or properties are different however:

VIII.2.6 ResKeyList class

Methods of the “ResKeyList” class are the same as the ones defined in the ResKeyList class in ruby extension. However:

Chapter VIII.3
Supported Solvers

The two classes that correspond to the two supported solvers (Nastran and Samcef) are complete.

VIII.3.1 The “NastranDb” class

The “NastranDb” class stores a model and results corresponds to Nastran finite element solver. Methods specific to the NET assembly are:

The reader is referred to Chapter III.1 for the description of the other methods.

VIII.3.2 The “SamcefDb” class

The “SamcefDb” class stores a model and results corresponds to Samcef finite element solver. The other methods that are available are:

The reader is referred to Chapter III.2 for the description of the other methods.

Part IX
FeResPost Examples with .NET Assembly

Chapter IX.1
Examples of use for .NET assembly

Presently, the examples of usage for the .NET assembly are limited mostly to C# language examples. These examples are provided in sub-directories of “TESTSAT/NETEX” and correspond to the small examples “TESTSAT/RUBY” of FeResPost ruby extension discussed in chapter IV.2.

In this chapter, one highlights the differences between ruby extension and .NET assembly. For that reason, only a few examples are discussed. For the other examples, the discussion of corresponding ruby examples in chapter IV.2 and refexamples.CLA.chap should be sufficient.

IX.1.1 Reading a Nastran model

IX.1.1.1 Reading a Nastran model with C-sharp

The first C# example is very simple and illustrates the use of .NET assembly with C# programming language. The example is provided in “TESTSAT/NETEX/EX01/readBdf.cs” source file. The compilation is done with script “readBdf.bat” that contains the following lines:

@SET FRP=../../../SRC/OUTPUTS/NET
C:/Windows/Microsoft.NET/Framework/v3.5/csc.exe -platform:x86 \
        -r:%FRP%/FeResPost.dll ..\UTIL\util.cs readBdf.cs
readBdf.exe

(You may have to change the “%FRP%” path to FeResPost .NET assembly before compiling the example.) Note also that one uses the 3.5 version of .NET Framework. This is not strictly necessary in this example, but it might be useful for some examples in which classes are extended with extension methods. Once the compilation is done, the compiled program is run by line “readBdf.exe”.

The file “readBdf.cs” begins with several “using” directives:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Text;
using System.Globalization;
using System.Threading;

using FeResPost ;
using std ;

These directives allow to reduce the length of type names used in the program. For example, the “using FeResPost” directive allows to use “NastranDb” keyword instead of “FeResPost.NastranDb”.

The first example is very simple and contains only one static “Main” function:

namespace ConsoleApplication1 {

    class readBdf {

        static void Main(string[] args) {

            ...

        } // static void Main(string[] args)

    } // class readBdf

} // namespace ConsoleApplication1

Note however, that the static function is contained in a class. (C# does not allow to define a function outside of a class.) The “readBdf” class is also contained in a “ConsoleApplication1” namespace.

The other lines defining the program are very simple and considered as “classical” C# programming:

            NastranDb db = new NastranDb();
            db.Name="tmpDB1";
            db.readBdf("../../MODEL/MAINS/unit_xyz.bdf");

            // A Second DataBase is created :

            db = new NastranDb();
            db.Name="tmpDB2";
            db.readBdf("unit_xyz_V1.bdf","../../MODEL/MESH/","bdf",
                    new Dictionary<string,string>(),true);

(The reader is referred to chapter III.1 for the description of “readBdf” arguments.) Note that in the second call to “readBdf”, one uses a void “Dictionary” instead of a ruby “Hash” object as parameter.

One presents in “readBdf_V2.cs” and “readBdf_V3.cs” variants on of this first example.

IX.1.1.2 Reading a Nastran model with IronRuby

“readBdf_V2_rb.rb” contains an IronRuby version of C# example “readBdf_V2.cs”. The first call to “readBdf is done as follows:

     ...
     bdfName=System::String.new("unit_xyz_V2.bdf")

    symbols=Hash.new
    symbols["INCDIR"]="../../MODEL"

    db=NastranDb.new()
    db.Name="tmpDB2"
    begin
        db.readBdf(bdfName,[],System.String("bdf"),symbols,true)
    rescue Exception => x then
        ...

Of course, this call fails because ruby standard Arrays or Hashes cannot be used as CLI Arrays or dictionaries. Instead, the following statements work:

     ...
     symbols=System::Collections::Generic::Dictionary[System::String,System::String].new
     symbols.Add("INCDIR","../../MODEL");

     db.readBdf(bdfName,System::Array[System::String].new(0),System::String.new("bdf"),symbols,true)
     ...

The example illustrates the difficulty of marshaling CLI data types with IronRuby. We expect this to be true for all interpreted languages.

IX.1.2 “printStressMax” example

The example is provided in “TESTSAT/NETEX/EX05/printStressMax.cs” source file. This example is worth discussing because it illustrates the difference between the value returned by “Result.getData” method in ruby extension and in C#.

In the example, one extracts the data on a Result which associates only one key-value pair, but the present principles are valid for more general Results. The following ruby lines make use of the ruby extension and extract and print the stress components :

    ...
    maxScalarData = maxScalar.getData()[0]
    maxStressData = maxStress.getData()[0]
    ...
    printf("   %.2f Pa on element %d (layer=\"%s\").\n",
            maxScalarData[5],maxScalarData[0],maxScalarData[2])
    printf("      Sxx = %.2f, Syy = %.2f, Szz = %.2f,\n",maxStressData[5],\
            maxStressData[6],maxStressData[7])
    printf("      Sxy = %.2f, Syz = %.2f, Szx = %.2f\n",maxStressData[8],\
            maxStressData[9],maxStressData[10])
    ...

The same operation is performed with .NET assembly by the following C# code:

    ...
    maxScalarData=maxScalar.getData();
    maxStressData=maxStress.getData();

    Console.WriteLine();
    Console.WriteLine("Maximum Von Mises stress in panel +Z skins :");
    Console.WriteLine();
    Console.Write("   {0:F2} Pa ",maxScalarData[0,5]);
    Console.Write("on element {0:D} ",maxScalarData[0,0]);
    Console.WriteLine("(layer=\"{0:S}\")",maxScalarData[0,2]);
    Console.Write("      Sxx = {0:F2}, ",maxStressData[0,5]);
    Console.Write("Syy = {0:F2}, ",maxStressData[0,6]);
    Console.WriteLine("Szz = {0:F2}, ",maxStressData[0,7]);
    Console.Write("      Sxy = {0:F2}, ",maxStressData[0,8]);
    Console.Write("Syz = {0:F2}, ",maxStressData[0,9]);
    Console.WriteLine("Szx = {0:F2} ",maxStressData[0,10]);
    ...

One notices that one no longer accesses element 0 of the array returned by “getData”. Indeed, in .NET assembly, the method returns a 2D Array, and not an Array of Arrays as in ruby extension.

IX.1.3 Accessing FEM data

In the “NETEX/EX02/properties.cs” example, one shows how one can access the properties in the finite element model. The C# code looks as follows:

    object[] card;
    foreach (int pid in db.iter_propertyId()) {
        os.Write("{0,8}",pid);
        os.Write("\n\n");

        card=db.fillCard("Property",pid);
        os.Write("{0,8}",card[0]);
        for (int i=1;i<card.Length;i++) {
            os.Write("{0,8}",card[i]);
            if (i%8==0&&i!=card.Length-1) {
                os.Write("\n");
                os.Write("{0,8}","");
            }
        }
        os.Write("\n\n");
    }

This example illustrates the use of “fillCard” method, already presented in sections III.1.1.5 and IV.2.3

IX.1.4 Extending CLA classes

The examples provided in “NETEX/EX13” illustrate the possibility to extend FeResPost classes in C# by defining “extension” methods. Note however that this capability exists only if a version 3 or above of the C# compiler is used.

In the following example, extracted from “NETEX/EX13/extendedCla.cs”, The ClaMat class is extended with method “write_Compliance”:

namespace extension {
    static class ext {
        ...
        public static void write_Compliance(this ClaMat m,
                StreamWriter os,float theta) {
            writeMat(os,m.getCompliance(theta));
        }
        ...

Note that the first argument is “this ClaMat m”, which indicates the class that is being extended. In file “NETEX/EX13/extendedCla.cs”, the extension methods are defined in “extension” namespace. A “using extension” statement must be present in the client program to access the extensions.

Note also, that many of the methods defined in C# differ from the ruby corresponding ruby methods with ruby extension. For example, the following C# source lines take into account that “getPliesStresses” method of .NET assembly returns a 2D Array:

    ...
    sigTab=l.getPliesStresses();
    nbrLines=sigTab.GetLength(0);
    os.Write("   {0,8}{1,5}","layer","loc");
    os.Write("{0,14}{1,14}{2,14}","sig_11","sig_22","sig_12");
    os.Write("\n");
    for (i=0;i<nbrLines;i++) {
        os.Write("   {0,8}{1,5}",sigTab[i,0],sigTab[i,1]);
        os.WriteLine("{0,14}{1,14}{2,14}",sigTab[i,2],
                     sigTab[i,3],sigTab[i,7]);
    }
    os.Write("\n");
    ...

Ruby extension returns an Array of Arrays and the corresponding lines would be:

    ...
    sigTab=getPliesStresses
    os.printf("   %8s%5s","layer","loc")
    os.printf("%14s%14s%14s","sig_11","sig_22","sig_12")
    os.printf("\n")
    (0...sigTab.size).each do |i|
        os.printf("   %8d%5s",sigTab[i][0],sigTab[i][1])
        os.printf("%14g%14g%14g",sigTab[i][2],sigTab[i][3],
                  sigTab[i][7])
        os.printf("\n")
    end
    ...

IX.1.5 Saving and retrieving Results from an SQL database

This example is presented in files “rehashDynamicResults.cs” and “deleteSomeResults.cs” of directory “TESTSAT/NETEX/EX20” correspond exactly to the ruby examples of section IV.2.6.

The access to SQLite .NET assembly, which must be installed on the computer is done by the following statement:

    using System.Data.SQLite ;

Note also the binding of parameters to SQLite command:

        cmd.CommandText = sql;
        cmd.Parameters.Clear();
        cmd.Parameters.AddWithValue("@lcName", id[0]);
        cmd.Parameters.AddWithValue("@scName", id[1]);
        cmd.Parameters.AddWithValue("@resName", id[2]);
        cmd.Parameters.AddWithValue("@tensorOrder", tensorOrder);
        cmd.Parameters.AddWithValue("@intId1", intId1);
        cmd.Parameters.AddWithValue("@intId2", intId2);
        cmd.Parameters.AddWithValue("@realId1", realId1);
        cmd.Parameters.AddWithValue("@realId2", realId2);
        cmd.Parameters.AddWithValue("@size", size);
        cmd.Parameters.AddWithValue("@result", resBlob);
        cmd.ExecuteNonQuery();

IX.1.6 Superelements

The NET examples in directory “TESTSAT/PYTHON/EX27” are a simple translation of the ruby example discussed in section IV.2.11. Example are written with C#.

Part X
Appendices

Appendix X.A
Installing FeResPost library

FeResPost is open source. Both the C/C++ sources and binaries are distributed.

X.A.1 Binaries

The binaries are distributed in archive containing the “OUTPUTS” directory and its sub-directories. These binaries can also be re-generated from the sources as described in section X.A.1.

Depending on the OS and on the type of the binaries you are using, part of the distribution is to be used.

File “OUTPUTS/COMPILER.TXT” contains information about the compiler that has been used to produce the binaries. File “build.log” contains additional information on the build environment.

Note that the C++ shared libraries are still distributed in “OUTPUTS/lib” directory to maintain compatibility with what was done with previous versions. The use of these binaries is however not recommended because:

If you intend to develop your own wrappers or use FeResPost classes in your own programs we recommend that you recompile FeResPost C++ library with you own compiler, and statically link your executables/libraries to FeResPost objects.

Table X.A.1 gives an idea of successful build, in particular of the different versions of ruby and Python for which FeResPost library has been compiled. Note however, that the success of failure of a compilation may depend on compiler version and that the list can change. The best way to check the availability of compiled library for a given version is to explore the corresponding archives.

X.A.1.1 Linux binaries (32 bits)

In archive “FeResPost_5.0.9_LINUX_32.7z” the binaries contain ruby wrappers and C++ library:

The ruby and python libraries must be used with the appropriate 32 bits distribution of ruby or python. (Note that 32 bits programs and libraries can be used on 32 bits or 64 bits LINUX installations.)

X.A.1.2 Linux binaries (64 bits)

In archive “FeResPost_5.0.9_LINUX_64.7z” the binaries contain ruby wrappers and C++ library:

The ruby and python libraries must be used with the appropriate 64 bits distribution of ruby or python.

X.A.1.3 Windows binaries (32 bits)

In archives “FeResPost_win32_5.0.9_*.7z” and “FeResPost_win32_5.0.9_gcc345_*.7z” the binaries contain ruby wrappers, COM component and C++ library:

The ruby and python libraries must be used with the appropriate 32 bits distribution of ruby or python. (Note that 32 bits programs and libraries can be used on 32 bits or 64 bits LINUX installations.) The “*” in archive name can be “w10” or “w11”, depending on the computer on which the libraries have been compiled (Winfows 10 or Windows 11).

“FeResPost_win32_5.0.9_gcc345_*.7z” archive contains libraries that have been compiled with an older version of GNU compiler (GCC 3.4.5). This older version of the library does not allow to compile FeResPost extension for ruby versions more recent than ruby 2.3.*. On the other hand, the C++ standard library to which FeResPost is linked allows a random access to XDB of FAC files of size larger than 2Gb. It seems that more recent versions of GNU compiler no longer allows this, and this is a regression.

We cond have decided not to distribute the 32bits Windows binaries as nowadays, most computers run 64bits operating systems. We think however that, at least for the COM component, the availability of 32bits binaries may be useful to many. Indeed, many Microsoft Office installations are still 32 bits, and FeResPost 32bits COM component is then necessary.

X.A.1.4 Windows binaries (64 bits)

In archive “FeResPost_win64_5.0.9_*.7z” the binaries contain ruby wrappers, COM component and C++ library:

The ruby and python libraries must be used with the appropriate 64 bits distribution of ruby or python. There is no issue related to random access to large XDB or FAC files with 64bits versions of FeResPost binaries. The “*” in archive name can be “w10” or “w11”, depending on the computer on which the libraries have been compiled (Winfows 10 or Windows 11).

X.A.1.5 Windows .NET assemblies

In archive “FeResPost_NET_5.0.9.7z” the assemblies are distributed in directory “OUTPUTS/NET”. Three versions of FeResPost .NET assembly are build:

X.A.1.6 HDF shared libraries

As explained in section III.1.1.11, to access HDF files, the first step is to load the HDF5 shared library. The libraries that have been used for the compilation of FeResPost are re-distributed in directory “HDF5_REDISTR”. (See the “Downloads” page on FeResPost web site.)

X.A.2 Building from sources

All the sources are delivered in an archive containing an SRC directory and several levels of sub-directories. The sources of the program are delivered with different Makefiles and BASH or BAT scripts that can be used for the compilation of the different targets:

Examples of builds follow:

        build_linux32.bash ruby
        build_linux32.bash ruby_23
        build_linux32.bash outputs
        build_mingw64.bat com
        build_mingw64.bat ruby
        build_mingw64.bat vbaruby
        build_mingw64.bat outputs
        build_python_27.bat
        buildbuild_python_win32
        buildbuild_python_win64
        ...

Note: for 32bits version 2.4.* of ruby, the “include/ruby/ruby.h” has been slightly modified: “DEPRECATE_BY” lines 1381 and 1390 have been commented. Otherwise, the compilation resulted in error messages. This has been done on Windows and on Linux.


Table X.A.1: Available compilation scripts, and associated “main” Makefiles and targets.

SCRIPT main Makefile targets
build_linux32.bash Makefile.LINUX_586ruby_31, ruby_30, ruby_27, ruby_26, ruby_25, ruby_24, ruby_23, ruby_22, ruby_21, ruby_20, ruby_19, ruby_18, python_26, python_27, python_30, python_31, python_32, python_33, python_34, python_35, python_36, python_37, python_38, python_39, python_310, develop
build_linux64.bash Makefile.LINUX_I64ruby_32, ruby_31, ruby_30, ruby_27, ruby_26, ruby_25, ruby_24, ruby_23, ruby_22, ruby_21, ruby_20, ruby_19, ruby_18, python_26, python_27, python_30, python_31, python_32, python_33, python_34, python_36, python_37, python_38, python_39, python_310, python_311, develop
build_mingw32.bat Makefile.WIN.32 com, ruby_27, ruby_26, ruby_25, ruby_24, ruby_22, ruby_21, ruby_20, ruby_19, ruby_18, vbaruby, develop, python_26, python_27, python_30, python_31, python_32, python_33, python_34, python_35, python_36, python_37, python_38, python_39
build_mingw32_345.bat Makefile.WIN.32 (345 targets)
HDF5 unsupported
com, ruby_23, ruby_22, ruby_21, ruby_20, ruby_19, ruby_18, vbaruby, develop, python_26, python_27, python_30, python_31, python_32, python_33, python_34, python_35, python_36, python_37, python_38, python_39
build_mingw64.bat Makefile.WIN.64 com, ruby_32, ruby_31, ruby_30, ruby_27, ruby_26, ruby_25, ruby_24, ruby_23, ruby_22, ruby_21, ruby_20, develop, python_30, python_31, python_32, python_33, python_34, python_35, python_36, python_37, python_38, python_39, python_310, python_311
build_net.bat Makefile.NET net
build_msvc_x86.bat Makefile.MSVC_X86com, ruby, python, vbaruby, develop (for debugging the sources)
build_msvc_x64.bat Makefile.MSVC_X64com, ruby, python, vbaruby, develop (for debugging the sources)
build_intel.bat Makefile.INTEL.X64com, python, vbaruby, develop (for debugging the sources)

X.A.3 Compilation options

In general, the binaries are compiled without the “-static” option. This means that when using the different shared libraries, the redistributable libraries in "OUTPUTS/REDISTR" directory must be in the PATH environment variable. Compilation is done this way because the “-static” option tends to break the C++ management of exception and associated error messages.

There is one exception: the Python Windows libraries are compiled with “-static” option. This seems not to lead to issues with the management of exceptions.

Of course, users that compile libraries from he sources are free to experiment other options.

X.A.4 Installation and configuration of binaries

One makes below the distinction between the installation of the ruby extension, the COM server and the .NET assembly. Actually, depending on what you want to do, only some parts of the binaries must be installed/configured. Table X.A.2 summarizes what you need to do. Before configuring FeResPost, always make sure that you are selecting the right version of the binaries. In particular:


Table X.A.2: Summary of the configuration operations you need to perform to use FeResPost.
If you want to...

You must...

Use FeResPost in ruby scripts

Install the corresponding FeResPost C++ ruby extension (section X.A.4.3)

Use FeResPost as COM component (Windows only)

Install and register the COM component (section X.A.4.5)

Use the .NET assembly

Install the assembly in GAC (global assembly cache) as explained in section X.A.4.6. An installation of the redistributable Microsoft Visual C++ libraries may also be necessary.

Develop you own wrapper around FeResPost C++ library, or write a program that directly uses the C++ library

Install the C++ library and corresponding header files (section X.A.4.2)

Modify and/or recompile the sources

Copy the sources and try to find inspiration in the information provided in section X.A.2


X.A.4.1 Redistributable libraries

In principle redistributable libraries are no longer needed as the Windows ruby and python extensions, and the COM component are now statically linked to GNU compiler libraries (“limb.a‘”, “libstdc++.a”,...). However, you might need the redistributable libraries if you used the C++ shared libraries to compile your own executables with FeResPost.

GNU C++ compiler the C++ developer’s library, the ruby extensions or the COM component. (See below.) With recent versions of the compiler, some of the C++ built-in libraries are not included in FeResPost “dll” or “so” library file. Then these libraries are provided in “REDISTR” directory. Then, the user must give access to these libraries to each script or application that uses FeResPost library. For example:

On Windows OS, your PATH environment variable can be modified in “Control Panel” –> “System and Security” –> “System” –> “Advanced system settings” –> “Environment variables”.

On your computer, you may run FeResPost from different environments (excel with VBA, ruby, python...) that can require sometimes a 32 bits version, or a 64 bits version of the library and associated redistributables. Or you may compare results obtained with different versions of FeResPost. Then, it may be handy to define the environment associated to each separate script. This can be done by providing the execution environment in a script (BAT file on windows, and bash or csh file on UNIX for example).

For example, on Windows, assuming you are using a 64 bits version of excel, and that the 64 bits version of the COM component has been properly registered, excel could be run by the following batch file:

    setlocal
    set PATH=D:/SHARED/FERESPOST/SRC/OUTPUTS/REDISTR;C:/NewProgs/RUBY/Ruby200_x64/bin;
        C:\Program Files (x86)\Microsoft Office\Office12
    excel LaminateAnalysis.xlsm
    endlocal

(This is just an example, you have to adapt the PATH variable to your installation.)

X.A.4.2 FeResPost C++ developer’s library and headers

One distinguishes the UNIX/LINUX OS and Windows OS:

(Note that the use of these shared libraries is no longer recommended. Instead, it is a better idea to statically link your libraries/executables to FeResPost objects.)

for the headers, just copy the “include” directory in a location that suits you, and adapt your compiler options to access the headers (for example, by editing your makefiles).

X.A.4.3 Ruby extensions

The shared library (FeResPost.so or FeResPost.dll) is delivered with “FeResPost.rb” ruby file. This file is the ‘main” file that loads the shared library and defines the elements that allow to “coerce” the arguments of “Result” class operators. (See section I.7.)

The files should be copied into the ruby installation library directory. The files can also be installed in another directory, but then the access path must be specified to ruby. (For example, with “-I” option.) You can also install them in any directory that suits you and ensure that “RUBYLIB” environment variable points to that directory.

X.A.4.4 Python extensions

The shared library (FeResPost.so or FeResPost.pyd) contain everything you need to run the examples. The files should be copied into the Python installation library directory. You can also copy Python library in you user site packages directory. This can be obtained via the command:

        python -l --user-site
    

The files can also be installed in another directory, but then the access path must be specified to Python.

You can also install them in any directory that suits you and ensure that “PYTHONPATH” environment variable points to that directory.

Note that the Python examples are provided with with “env*’ batch files that help you to define the approrpiate environment on Windows.

X.A.4.5 COM component

Two solutions are proposed for the registration or un-registraition of COM component. One can use “modifyRegistry.exe” program”. Registration or un-registration is also possible using “reg” files.

X.A.4.5.1 Registration of COM component with “modifyRegistry.exe” program

COM server must be registered before use. For that purpose, a program called “modifyRegistry.exe” is distributed with FeResPost library. This program is used to add keys to the Windows register. Follows some information:

The examples presented in Part VII require only the registration of in-proc library and type library (recommended configuration).

Figure X.A.1 shows the window created by the "modifyRegistry.exe" program. After clicking one of the registration buttons, the program shows an information message allowing to check the correct installation of COM component (Figure X.A.2 or X.A.3). In many cases, failure is related to the impossibility of loading FeResPost library.


PICT

Figure X.A.1: Registration of FeResPost COM component.


PICT

Figure X.A.2: Successful registration of FeResPost COM component.


PICT

Figure X.A.3: Failed registration of FeResPost COM component.

You may register either 32 bits version of the component, or 64 bits version of the component, or both 32 bits and 64 bits versions of the component:

X.A.4.5.2 Registration with “reg” files

FeResPost COM component is delivered with registration files in the “OUTPUTS/COM/REGFILES” directory. Four such files are available: “addAllUsers.reg”, “addCurrentUser.reg”, “removeAllUsers.reg” and “removeCurrentUser.reg”. The four files can be distinguished according to two criteria:

Before using the reg files that add information to Windows registry, you must ensure that the paths to “FeResPost.dll” and “FeResPost.tlb” match what their actual location on your computer. For example, the registry files delivered with COM binaries contain this kind of information:

 [HKEY_CURRENT_USER\Software\Classes\TypeLib\{0A88E969-53D5-492B-FABB-A0DF12862BE8}\1.0\0\win32]
 @="C:\\Users\\ferespost\\Documents\\SRC\\OUTPUTS\\COM\\lib\\FeResPost.tlb"
 ...
 [HKEY_CURRENT_USER\Software\Classes\CLSID\{52FEFC92-63E7-4500-768B-84B08E1262C1}\InprocServer32]
 @="C:\\Users\\ferespost\\Documents\\SRC\\OUTPUTS\\COM\\lib\\FeResPost.dll"
 "ThreadingModel"="apartment"

(Of course, the paths must be modified to match your installation.)

The sources come with a ruby script that is used to generate the registration files. The script can be used as follows:

 ruby bin/createRegFiles.rb  C:/Users/ferespost/Documents/SRC
   C:/Users/ferespost/Documents/SRC/OUTPUTS/COM 5.0.7 32

The three arguments of the ruby script are:

X.A.4.6 .NET assembly

FeResPost assembly should be installed in the global assembly cache. This can be done by copying the “FeResPost.dll” dynamic link library found in “NET’ directory to the Global Assembly Cache. On my computer, this can be done simply by a drag and drop of “FeResPost.dll” into “C:/Windows/assembly” directory. Note however that:

The advantage of installing FeResPost in the Global Assembly Cache is that this allows to use from a program anywhere without minding where to find it.

Appendix X.B
Coordinate system transformations

The modification of coordinate system into which the components of vectorial or tensorial results are expressed is a common operation performed when post-processing finite element results. To perform the transformation some vectorial and tensorial calculation is necessary. One gives in this Appendix, a summary of theoretical background necessary to understand the operations performed with FeResPost.

X.B.1 Components of vectors and tensors

When performing tensorial calculations, or post-processing results, one manipulates 1D or 2D arrays of real values corresponding to the components of vectors or tensors in a specified coordinate system. Higher order tensors also exist, but they are not manipulated in FeResPost and we do not present the theory for tensor order larger than 2.

X.B.1.1 Vectors in a Cartesian coordinate system

A vectorial force f can be expressed by its components {f1,f2,f3} in the Cartesian coordinate system {O,e1,e2,e3} characterized by its origin O and its three unit length mutually orthogonal vectors e1, e2 and e3. Then the vector f corresponds to:

f = i=13f iei.

In the rest of the text the components of a vector f are denoted fi and one uses the Bose-Einstein convention of summation on repeated indices so that the previous expression is simply written:

f = fiei.

X.B.1.2 Order 2 tensor in a Cartesian coordinate system

A Cauchy stress tensor σ is characterized by its components σij in the Cartesian coordinate system {O,ei}. (One uses the same notations as in section X.B.1.1).

σ = σij(ei ej).

The nine quantities (ei ej) can be considered as the basic tensors from which all the other tensors are obtained linear combinations. Note that the Cauchy stress tensor is always symmetrical so that σij = σji.

X.B.1.3 Cylindrical and spherical coordinate systems

In sections X.B.1.1 and X.B.1.2, one presented vector and tensor components in Cartesian coordinate systems. The same definition is also worthy in curvilinear coordinate systems. However, the director vectors depend on the point on which the vector or tensor is attached. Conventionally, one decides that the director vectors are chosen tangent to the coordinate lines and are of unit length.

For example, for a cylindrical coordinate system, the position p of a point depends on three coordinates r, z and θ. So one has:

p = p(r,z,θ).

Then three tangent vectors gi are obtained by deriving the position p wrt coordinates:

g1 = gr = p r, g2 = gθ = p θ, g3 = gz = p z.

Finally, the three tangent vectors are normalized as follows:

ei = gi gi .

This process to define base vectors at any point can be generalized to all curvilinear coordinate systems. However, the cylindrical and spherical coordinate systems have a peculiarity: at a given point, the three base vectors ei are mutually orthogonal. This is not a general characteristic of curvilinear coordinate systems.

The orthogonality property of the coordinate systems one uses in FeResPost simplifies the transformation of components from one coordinate system to another. Indeed such transformations reduce to transformations between Cartesian coordinate systems. There is only one difficulty in this process: to calculate the base vectors at every point.

X.B.2 Transformation of components

One considers only the peculiar case of two Cartesian coordinate systems with the same origin. In section X.B.1.3, one showed that even for cylindrical and spherical coordinate systems it is possible to reduce the complexity of the problem to a transformation of the components between two Cartesian coordinate systems.

X.B.2.1 Transformation of vector components

One considers a vectors v with components expressed in two Cartesian coordinate systems with base vectors ei and ei respectively. So one has:

v = viei = vie i.

In the last expression we introduce the notations vi and vi for the components of vector v in ei and ei respectively.

It is possible to decompose the vectors ei as a linear combination of vectors ej:

ei = A ijej.

The coefficients Aij are easily calculated. Indeed, the scalar multiplication of the previous equality by ek gives successively:

eie k = (Aijej ek) , eie k = (Aijδjk) , eie k = Aik,

or finally:

Aij = eie j.

By a similar calculation, it is possible to identify the relations between the components of vector v expressed in the two coordinate systems:

ekv = e k (v iei) = ek (v ie i), vi (eke i) = vi (e ke i), viAki = viδ ki, Akivi = vk,

Finally, one sees that the relation between base vectors and vector components are the same:

ei = A ijej,

vi = A ijvj.

That’s the reason why the transformation is called a covariant transformation. One also says that vi or vi are covariant components of vector v in coordinate systems ei and ei respectively. In the last vector component transformation one recognizes a classical algebraic result:

V = AV .

The matrix Aij is orthogonal: (Aij) -1 = A ji and the reverse relation for vector components is:

vj = Ajivi.

X.B.2.2 Transformation of tensor components

Similarly to what has been done for vectors in section X.B.2.1, one derives transformations of the components of tensors. One considers the components of tensor T in two coordinate systems:

T = Tkl(ek el) = Tij(e ie j).

Using the same definition of transformation matrix Aij as in section X.B.2.1, one writes:

ek = Aikei,

el = Ajlej.

Then, the substitution of the two expressions in the equations defining components gives:

T = Tkl(ek el) = Tij(e ie j), Tkl(Aikei A jlej) = T ij(e ie j), AikTklAjl(eie j) = T ij(e ie j).

The last expression allows us to extract a relation involving only the components of tensors, and not the base vectors:

Tij = A ikTklAjl.

Here again, one recognizes a classical matricial expression:

T = ATAt.

X.B.3 Rotation of a coordinate system

A transformation of coordinate systems commonly done is a rotation of the coordinate system around a specified axis passing through the origin of the coordinate system. The resulting coordinate system has the same origin, but its base vectors are modified. A classical use of this operation corresponds to the transformation of vector or tensor results in material, ply or element axes of 2D elements.

For example, let v be a unit vector defining the rotation axis and θ the rotation angle. Then the three transformed base vectors are given by:

ei = cos θe i + (1 - cos θ)(vei)v + sin θ(v×ei).
(X.B.1)

In particular, if v corresponds to e3, the three

e1 = cos θe 1 + (1 - cos θ)(e3 e1)e3 + sin θ(e3 ×e1), = cos θe1 + sin θ(e2), = cos θe1 + sin θe2.

e2 = cos θe 2 + (1 - cos θ)(e3 e2)e3 + sin θ(e3 ×e2), = cos θe2 + sin θ(-e1), = cos θe2 - sin θe1. e3 = cos θe 3 + (1 - cos θ)(e3 e3)e3 + sin θ(e3 ×e3), = cos θe3 + (1 - cos θ)(1)e3, = e3.

X.B.4 Modification of coordinate systems

One gives here additional information on the modification of coordinate systems with Result method “modifyRefCoordSys”. When developing the various transformations possible with this function, one tried to keep as much as possible, the correspondence with Patran (Patran 90) transformations. Sometimes, this process has been partially done by trials and guesses until an agreement was found.

In the rest of the section, one gives the information allowing the user to determine exactly the operations that are performed on finite element entities and coordinate systems to defined the transformed coordinate system. One makes the distinction between local, global and projected coordinate systems.

X.B.4.1 Local coordinate systems

Several types of local coordinate systems may be defined, and the operations performed to define the coordinate system depend on the case:

1.

The “elemIJK” coordinate system definitions may be found in Patran User Manual. It is also common to the element coordinate systems of most finite element programs. Usually, it is defined with the three first definition nodes of the element. Direction X corresponds to the vector from node 1 to node 3. Direction Y is determined from the position of node 3.

2.

The “plyCS” coordinate system is obtained on surfacic elements with “PCOMP” or “PCOMPG” properties by rotating the local material coordinate system with the appropriate angle around its axis Z. For other elements, the ”plyCS” coordinate system is identical to the material coordinate system.

3.

The “matCS” coordinate system definition depends on the type of element:

(a)

For 0D elements, no material coordinate system exists.

(b)

For 1D elements, the material coordinate system corresponds the element coordinate systems (i.e. Nastran element coordinate system).

(c)

For 2D elements, the material coordinate system can be defined by two methods:

i.

If the material coordinate system is defined by an integer, this integer corresponds to the index of the coordinate system defined in the DataBase. Then the new coordinate system as follows:

  • The First vector of the coordinate system is extracted.

  • It is projected on the XY plane defined by the Nastran element coordinate system. This gives the vector X of the local material Cartesian coordinate system.

  • The Vector Z of the local material Cartesian coordinate system is identical to the vector Z of Nastran element coordinate system.

ii.

if the material coordinate system is defined by a real argument, the value corresponds to a rotation angle θ. Then the local material Cartesian coordinate system is defined as follows:

  • One first builds the IJK Cartesian coordinate system.

  • Then the vector X of IJK coordinate system is rotated by an angle θ around axis Z of IJK coordinate system.

  • This rotated vector s projected on the XY plane defined by the Nastran element coordinate system. This gives the vector X of the local material Cartesian coordinate system.

  • The Vector Z of the local material Cartesian coordinate system is identical to the vector Z of Nastran element coordinate system.

(d)

For 3D elements, the material coordinate is generally identified by an integer in the “PSOLID” card. It is then retrieved from the DataBase. If no material coordinate system is specified in the “PSOLID” card, then the material coordinate system corresponds to the Nastran element coordinate system.

4.

The “nodeCS” coordinate system corresponds to the node analysis coordinate system. See Nastran reference guide for more information.

5.

The “elemCS” coordinate system corresponds to the Nastran local coordinate system. See Nastran reference guide for more information. Note that the construction of Nastran local coordinate system for CQUAD and 3D elements is complicated. (See sections X.B.4.4 and X.B.4.5 for more information.)

X.B.4.2 Global coordinate systems

Global coordinate systems correspond to CoordSys objects. However one makes the distinction between:

1.

The basic coordinate system identified with integer 0.

2.

Coordinate systems which have a correspondence in the DataBase from which they have been or may be extracted. Those coordinate systems are identified with an integer larger than 0.

3.

Other user defined coordinate systems which have no correspondence in the DataBase. They are identified with integer -2000.

Not that the user is responsible for the use he makes on coordinate systems defined in DataBase. In particular, it is true when several DataBases are used.

X.B.4.3 Projected coordinate systems

The projected coordinate system is a local Cartesian coordinate system the definition of which depends on the type of element:

1.

For 0D elements, no coordinate system is build.

2.

For 1D and 3D elements, the Nastran element coordinate system is returned.

3.

For 2D elements, the projection makes sense. The coordinate system is build as follows:

(a)

The Z vector is the normal to the surface of the 2D element. For a CTRIA3, the vector Z is constant on the element. But for a CQUAD4 the nodes of which are not co-planar, the vector Z depends on the location on the element.

(b)

The direction vector is projected on a plane perpendicular to Z and defines direction X. Note that the direction vector is associated to a coordinate system which may be curvilinear.

Note that for 2D elements, the definition of projected coordinate system is more general that in Patran. Indeed, in Patran, only the vector X of the specified coordinate system is projected.

X.B.4.4 Local coordinate systems of CQUAD4 elements

For CQUAD4 Nastran elements, the origin of the element coordinate system is defined to be the intersection of straight lines AC and BD( A, B, C, and D being the corners of the element). As long as the four defining nodes are co-planar, this definition is sufficient. But otherwise, the two straight lines do not intersection, and a generalization of the definition of the origin has to be found. We decide that the origin of the coordinate system shall be the point closest to the two straight lines AC and BD.

The two straight lines can be defined with corresponding parameterized equations:

x1 = (1 2 + ξ)xA + (1 2 - ξ)xC,

x2 = (1 2 + η)xB + (1 2 - η)xD.

So, one has to find the parameters ξ and η that minimize x1 -x2. The vector x1 -x2 can be developed as follows:

x1 -x2 = (xA -xB + xC -xD) + (xA -xC) ξ + (xD -xB) η, = v3 + v1ξ + v2η,

where

v1 = xA -xC, v2 = xD -xB, v3 = xA -xB + xC -xD.

The square of the norm defined above (x1 -x2) 2 depends on parameters ξ and η and is given by:

f(ξ,η) = v32 + 2v 3 v1ξ + 2v3 v2η + v12ξ2 + v 22η2 + 2v 1 v2ξη.

This function must be stationary at the optimum point. Therefore its first derivatives wrt ξ and η must be zero:

f,ξ(ξ,η) = f,η(ξ,η) = 0.

This leads to a system of two linear equations with the two unknowns ξ and η:

v3 v1 + v12ξ + v 1 v2η = 0,

v3 v2 + v1 v2ξ + v22η = 0.

These two equations may be rewritten as follows:

v1 (v3 + v1ξ + v2η) = 0,

v2 (v3 + v1ξ + v2η) = 0,

Or simply

v1 (x1 -x2) = 0,

v2 (x1 -x2) = 0.

This equation simply means that the vector connecting the two optimum points is perpendicular to both lines AC and BD. Finally, after resolution of the system of equations and various substitutions, on finds the origin of coordinate system at:

x0 = x1 + x2 2 , = xA + xB + xC + xD 4 + xA -xC 2 ξ + xB -xD 2 η.

X.B.4.5 Local coordinate systems of 3D elements

In Nastran, for 3D elements, the definition of the local element coordinate system is a little tricky, and it is not easy to interpret the information found in the reference manuals. One provides here the interpretation that has been used to build the coordinate systems of 3D elements in FeResPost.

The first step of the local element construction is to build three vectors R, S and T related to the geometry of the element. The way those three vectors are constructed depends on the 3D element that is being constructed. Then the R, S and T vectors are used to build a local Cartesian coordinate system. In Nastran Quick Reference Guide [Sof04b], on gives the following explanation for the CTETRA element:

The element coordinate system is chosen as close as possible to the R, S, and T vectors and points in the same general direction. (Mathematically speaking, the coordinate system is computed in such a way that, if the R, S, and T vectors are described in the element coordinate system, a 3x3 positive definite symmetric matrix would be produced.)

In FeResPost, one makes the assumption that this information is also true for the other 3D elements CHEXA and CPENTA. One gives here the mathematical development that leads us to the definition of local coordinate system.

First, let us introduce the notations: r1 = R, r2 = S, r3 = T. So the element coordinate system is {O,ei} and the three vectors R, S and T are denoted ri. Then one defines with matrix A corresponding to the description of vectors ri on the base ei. One has:

ri = Aijej,

Aij = ri ej.

The above statement is equivalent to state that matrix Aij must be symmetric. So the problem reduces to “find three base vectors ei such that:

ri ej = rj ei.

Note also that this condition makes us think to the polar decomposition theorem that states that a positive definite tensor can be decomposed in the product of an orthogonal tensor and a pure symmetric positive definite tensor. This means that any deformation of a continuum medium can be decomposed in a rigid rotation and a pure deformation. One is actually interested in the rigid rotation that can be expressed by its rotation vector (see section X.B.3). So considering an initial set of base vectors ei and the three vectors ri provided as data, one must find the three components of the vector w = θv such that the new base vector ei obtained with equation (X.B.1) satisfy the relation

ri ej-r j ei = 0.
(X.B.2)

This set of equations is non linear in the primary unknowns wi and one solves them by a Newton-Raphson in which successive approximations of the three vectors ei are calculated. One performs a Taylor expansion of the relation (X.B.2) stopped at the first order:

ej e j + Δej,

Δej Δw×ej.

Substituting the two previous expressions in (X.B.2), one obtains successively:

ri (ej + Δej) -rj (ei + Δei) = 0,

ri (ej + Δw×ej) -rj (ei + Δw×ei) = 0,

ri (Δw×ej) -rj (Δw×ei) = rj ei -ri ej,

(ej ×ri -ei ×rj) Δw = rj ei -ri ej.
(X.B.3)

This last expression allows to derive three independent linear equations, with three unknowns wi. The Newton-Raphson algorithm used looks as follows:

1.

Determine a first estimate of the three vectors ei. In FeResPost, one chooses e1 parallel to R, e2 perpendicular to plane defined by vectors R and T, and e3 perpendicular to e1 and e2.

2.

Then one iterates until convergence:

(a)

Vector Δw is obtained by solving (X.B.3).

(b)

One then obtains the rotation angle θ and unit rotation vector v:

θ = Δw,

v = Δw Δw.
(c)

New estimates of the base vectors are obtained using (X.B.1).

One assumes convergence if θ < 10-5.

X.B.5 Coordinate systems and laminate properties

Vectorial and tensorial components of Results are sometimes expressed in coordinate systems related to material properties. Of course, this is also the case when laminated properties are attributed to the elements. Then, three different coordinate systems can be used: “plyCS”, “lamCS” and “matCS”.

When vectorial or tensorial Results on composite elements are imported, they are expressed:

1.

In “plyCS” coordinate system if the values are associated to a laminate ply (layerId>0).

2.

In “lamCS” coordinate system for Nastran Results when the values are not associated to a ply (layerId<=0).

3.

In “matCS” coordinate system for Samcef Results when the values are not associated to a ply (layerId<=0).

The difference between Samcef and Nastran is related to the fact that Nastran does not make a difference between material and laminate coordinate systems. Then, one considers that “matCS” == “lamCS”.

When one modifies the reference coordinate system of a Result, the components are actually modified according to the rules presented in Table X.B.1.


Table X.B.1: New coordinate system associations to Results for different combination of modification of reference coordinate system, software, element property types, and layers to which the values are associated.
Software Prop. type layerId“matCS”“lamCS”“plyCS”
Nastran homogenous <0 “matCS”“matCS”“matCS”
Samcef homogenous <0 “matCS”“matCS”“matCS”
Nastran homogenous >0
Samcef homogenous >0
Nastran laminate <0 “lamCS”“lamCS”“lamCS”
Samcef laminate <0 “matCS”“lamCS”“lamCS”
Nastran laminate >0 “lamCS”“lamCS”“plyCS”
Samcef laminate >0 “matCS”“lamCS”“plyCS”

Appendix X.C
Results characteristics

One presents in this Appendix the different Results that are pre-defined in FeResPost. All these Results can be read from Results files produced by different finite element solvers described in Part III. The characteristics of the different Results are described in Tables X.C.1 to X.C.10. The following notations have been adopted:

In the description of Results, one makes the distinction between Real and Complex Results (section X.C.1 and X.C.2 respectively).

X.C.1 Real Results

A summary of the Results that can be read is given in TableX.C.1 to X.C.10.


Table X.C.1: Nodal Results
Result Target Tensor
Name Entities Type
“Coordinates” N V
“Displacements, Translational” N V
“Displacements, Rotational” N V
“Displacements, Scalar” N S
“Velocities, Translational” N V
“Velocities, Rotational” N V
“Velocities, Scalar” N S
“Accelerations, Translational” N V
“Accelerations, Rotational” N V
“Accelerations, Scalar” N S
“Applied Loads, Forces” N V
“Applied Loads, Moments” N V
“MPC Forces, Forces” N V
“MPC Forces, Moments” N V
“MPC Forces, Scalar” N S
“SPC Forces, Forces” N V
“SPC Forces, Moments” N V
“SPC Forces, Scalar” N S
“Reaction Forces, Forces” N V
“Reaction Forces, Moments” N V
“Reaction Forces, Scalar” N S
“Contact, Contact Pressure” N S
“Contact, Friction Stress” N S
“Contact, Nodal Distance” N S
“Contact, Normal Distance” N S
“Temperature” N S
“Temperature Variation Rate” N S


Table X.C.2: Grid Points Forces.
Result Target Tensor
Name Entities Type
“Grid Point Forces, Internal Forces” EN V
“Grid Point Forces, Internal Moments” EN V
“Grid Point Forces, MPC Forces” EN V
“Grid Point Forces, MPC Moments” EN V
“Grid Point Forces, SPC Forces” EN V
“Grid Point Forces, SPC Moments” EN V
“Grid Point Forces, Applied Forces” EN V
“Grid Point Forces, Applied Moments” EN V
“Grid Point Forces, Reaction Forces” EN V
“Grid Point Forces, Reaction Moments” EN V
“Grid Point Forces, Total Forces” EN V
“Grid Point Forces, Total Moments” EN V


Table X.C.3: Element General Results.
Result Target Tensor
Name Entities Type
“Mechanical Strain Tensor” (5) E, EN, EL, ENL T
“Strain Tensor” (5) E, EN, EL, ENL T
“Stress Tensor” E, EN, EL, ENL T
“Effective Plastic Strain” (10) E, EN, EL, ENL S
“Effective Creep Strain” (10) E, EN, EL, ENL S
“Element Strain Energy” E S
“Element Strain Energy (Density)” E S
“Element Strain Energy (Percent of Total)” E S
“Element Kinetic Energy” E S
“Element Kinetic Energy (Density)” E S
“Element Kinetic Energy (Percent of Total)” E S
“Element Energy Loss” E S
“Element Energy Loss (Density)” E S
“Element Energy Loss (Percent of Total)” E S


Table X.C.4: Beam element Results.
Result Target Tensor
Name Entities Type
“Beam Axial Strain for Axial Loads” (7) E, EN S
“Beam Axial Strain for Bending Loads” (7) E, EN S
“Beam Axial Strain for Total Loads” (7) E, EN S
“Beam Shear Strain for Torsion Loads” (7) E, EN S
“Beam Shear Strain for Total Loads” (7) E, EN S
“Beam Axial Stress for Axial Loads” (7) E, EN S
“Beam Axial Stress for Bending Loads” (7) E, EN S
“Beam Axial Stress for Total Loads” (7) E, EN S
“Beam Shear Stress for Torsion Loads” (7) E, EN S
“Beam Shear Stress for Total Loads” (7) E, EN S
“Beam Forces” (1) E, EN T
“Beam Moments” (1) E, EN T
“Beam Warping Torque” E, EN T
“Beam Deformations” (2) E, EN T
“Beam Velocities” (2) E, EN T


Table X.C.5: Bush, Gap and Scalar elements specific Results.
Result Target Tensor
Name Entities Type
“Gap Slips” (8) E, EN T
“Bush Forces Stress Tensor” (9) E T
“Bush Forces Strain Tensor” (9) E T
“Bush Moments Stress Tensor” (9) E T
“Bush Moments Strain Tensor” (9) E T
“Bush Plastic Strain” E, EN S
“Spring Scalar Strain” E, EN S
“Spring Scalar Stress” E, EN S
“Spring Scalar Forces” (3) E, EN S


Table X.C.6: Shell elements specific Results.
Result Target Tensor
Name Entities Type
“Curvature Tensor” E, EN T
“Shell Forces” E, EN T
“Shell Moments” E, EN T


Table X.C.7: Results specific to shear panels.
Result Target Tensor
Name Entities Type
“Shear Panel Strain, Max” E, EN T
“Shear Panel Strain, Average” E, EN T
“Shear Panel Stress, Max” E, EN T
“Shear Panel Stress, Average” E, EN T


Table X.C.8: Composite Results, layered failure indices (10).
Result Target Tensor
Name Entities Type
“Composite Failure Index, Tsai-Hill Version 1” EL, ENL S
“Composite Failure Index, Tsai-Hill Version 2” EL, ENL S
“Composite Failure Index, Tsai-Hill Version 3” EL, ENL S
“Composite Failure Index, Tsai-Wu” EL, ENL S
“Composite Failure Index, Hoffman” EL, ENL S
“Composite Failure Index, Hashin Version 1” EL, ENL S
“Composite Failure Index, Hashin Version 2” EL, ENL S
“Composite Failure Index, Hashin Version 3” EL, ENL S
“Composite Failure Index, Maximum Strain” EL, ENLT (11)
“Composite Failure Index, Maximum Strain, CompMax”EL, ENLS (11)
“Composite Failure Index, Maximum Stress” EL, ENLT (11)
“Composite Failure Index, Maximum Stress, CompMax”EL, ENLS (11)
“Composite Failure Index, Stress Ratio” EL, ENL S
“Composite Failure Index, Strain Ratio” EL, ENL S
“Composite Failure Index, Rice and Tracey” EL, ENL S
“Composite Failure Index, Interlaminar Shear Stress” EL, ENL S


Table X.C.9: Composite Results, critical ply failure indices (10).
Result Target Tensor
Name Entities Type
“Composite Critical Ply Failure Index, Tsai-Hill Version 1” E, EN S
“Composite Critical Ply Failure Index, Tsai-Hill Version 2” E, EN S
“Composite Critical Ply Failure Index, Tsai-Hill Version 3” E, EN S
“Composite Critical Ply Failure Index, Tsai-Wu” E, EN S
“Composite Critical Ply Failure Index, Hoffman” E, EN S
“Composite Critical Ply Failure Index, Hashin Version 1” E, EN S
“Composite Critical Ply Failure Index, Hashin Version 2” E, EN S
“Composite Critical Ply Failure Index, Hashin Version 3” E, EN S
“Composite Critical Ply Failure Index, Maximum Strain, CompMax” E, EN S (11)
“Composite Critical Ply Failure Index, Maximum Stress, CompMax” E, EN S (11)
“Composite Critical Ply Failure Index, Stress Ratio” E, EN S
“Composite Critical Ply Failure Index, Strain Ratio” E, EN S
“Composite Critical Ply Failure Index, Rice and Tracey” E, EN S
“Composite Critical Ply Failure Index, Interlaminar Shear Stress” E, EN S


Table X.C.10: Composite Results, critical plies (10).
Result Target Tensor
Name Entities Type
“Composite Critical Ply, Tsai-Hill Version 1” E, EN S
“Composite Critical Ply, Tsai-Hill Version 2” E, EN S
“Composite Critical Ply, Tsai-Hill Version 3” E, EN S
“Composite Critical Ply, Tsai-Wu” E, EN S
“Composite Critical Ply, Hoffman” E, EN S
“Composite Critical Ply, Hashin Version 1” E, EN S
“Composite Critical Ply, Hashin Version 2” E, EN S
“Composite Critical Ply, Hashin Version 3” E, EN S
“Composite Critical Ply, Maximum Strain, CompMax” E, EN S (11)
“Composite Critical Ply, Maximum Stress, CompMax” E, EN S (11)
“Composite Critical Ply, Stress Ratio” E, EN S
“Composite Critical Ply, Strain Ratio” E, EN S
“Composite Critical Ply, Rice and Tracey” E, EN S
“Composite Critical Ply, Interlaminar Shear Stress” E, EN S


Table X.C.11: Element Thermal Results.
Result Target Tensor
Name Entities Type
“Temperature Gradient” E, EN V
“Conductive Heat Flux” E, EN V
“Specific Heat Energy” E, EN S
“Applied Heat Flux” E, EN S

In the following remarks about the information given in Tables X.C.1 to X.C.10, one assumes that the international unit system is used.

1.

“Beam Forces” and “Beam Moments” are assumed in FeResPost to be tensorial Results expressed in N or Nm respectively. However several components of the tensor are systematically nil. The non-zero components are:

F = ( FxxFxyFxz Fxy 0 0 Fxz 0 0 ) ,M = ( MxxMxyMxz Mxy 0 0 Mxz 0 0 ) .

There is an approximation for the moments above because the torsional component is calculated wrt cross-section shear centre, and bending components are calculated wrt cross-section centre of inertia.

One assumes that the beam forces are calculated from the Cauchy stress tensor components as follows:

{F } = ( Fxx Fxy Fxz ) =Ω ( σxx τxy τxz ) dΩ.

In which Ω is the surface defined by a cross-section through the beam orthogonal to beam longitudinal axis. (One presumes here that the beam longitudinal direction corresponds to “x” axis.) Similarly, one assumes that the bending moments tensor is calculated from the Cauchy stress tensor components as follows:

{M } = ( Mxx Mxy Mxz ) =Ω ( (y - yC) τxz - (z - zC) τxy (z - z0) σxx - (y - y0) σxx ) dΩ.

In which y and z are the components of coordinates in Ω section, y0 and z0 correspond to the coordinates of center of gravity of the section, and yC and zC correspond to the shear center coordinates. Note also that “Beam Forces” and “Beam Moments” are Results that correspond to most 1D elements. (Bars, beams, rods, bushing elements...). However spring elements do not produce “Beam Forces” and “Beam Moments”.

These conventions ensure that beam forces and moments behave like real order 2 tensors when transformation of coordinates systems are performed. The vectorial forces and moments at the two extremities are easily obtained. Vectors

{F } = ( Fxx Fxy Fxz )  and  {M } = ( Mxx Mxy Mxz )

correspond to the forces and moments that must be applied on + x side of the beam. On the - x side of the beam the components of these vectors must be multiplied by -1.

2.

“Beam Deformations” is a tensorial Result corresponding to the difference of displacements of grids B and A of the beam element. The tensor is expressed in element axes. The “Beam Velocities” Result is the time derivative of the “Beam Deformations”.

3.

Spring forces are scalar. The units depend on the connected components: one has N for displacements and Nm for rotations. (Of course, it is also possible to define springs connecting translational and rotational degrees of freedom, but it is generally an error.)

4.

“Shell Forces” and “Shell Moments” are tensorial Results expressed in N/m or N respectively. These Results contain all the force and moment tensors produced by 2D elements. The non-zero components are:

F = ( FxxFxyQxz FxyFyyQyz QxzQyz 0 ) ,M = ( MxxMxy0 MxyMyy0 0 0 0 ) .

(Symbol Q has been used for the out-of-plane shear force.)

One assumes that the shell in-plane forces are calculated from the Cauchy stress tensor components as follows:

Fxx =-h2h2σ xx dz, Fxy =-h2h2σ xy dz, ...

Similarly, one assumes that the bending moments tensor is calculated using the distribution through the thickness of the Cauchy stress tensor components as follows:

Mxx =-h2h2zσ xx dz, Mxy =-h2h2zσ xy dz, ...

This is a usual convention for shell elements. For example, this is generally the convention used to present the theory of classical laminate analysis. When a component of the bending tensor is positive, the corresponding component is positive on the upper surface of the shell, and negative on the other face.

5.

The shear components of strain tensors Results stored in FeResPost are the ϵij = γij2.

6.

The shell curvature tensor is defined as follows:

{κ} = ( κxx κyy κxy ) = 12 h3-h2h2z ( ϵxx ϵyy ϵxy ) dz = ( w,xx0 w,yy0 w,xy0 ) .

Here again, a positive curvature means that the corresponding component of strain tensor is in tension on the upper face, and in compression on the lower face of the shell.

7.

Beam stresses and strains are always scalar Results corresponding either to the axial component, or to the norm of the shear components. Depending on the type of element, the axial stress may be calculated from the axial or bending loads, or to involve both contributions.

8.

Gap elements produce various results. Results are vectorial or tensorial and:

  • Gap forces results are stored in “Beam Forces” tensorial Result as indicated in remark 1. The value of the axial component is multiplied by “-1.0”, because it is a compression component.

  • “Beam Deformations” and “Beam Velocities” are tensorial Results containing the relative displacements or velocities of end nodes B and A in element coordinate system.

  • “Gap Slips” is identical to “Beam Deformations” except that the axial component is set to “0.0”.

9.

Bushing elements produce Stress and Strain tensors obtained by multiplying the Beam Forces and Beam Moments by specified constants. These constants are by default set to 1. Therefore, stresses and strains have often values identical to the forces and moments. Note that the meaning of modifications of coordinate systems for bush stresses and strains have may be discussed. This is particularly so for stresses and strains corresponding to moments.

10.

Composite Results have non-linear dependence on the primary unknowns (displacements). Therefore, composite Results obtained by linear combination of elementary Results are false. This remark applies to all non-linear Results, plastification Results...

11.

Actually “Maximum Strain” and “Maximum Stress” composite Results are not tensorial because each component is a separate scalar Result. So no modification of coordinate system can be done for these Results.

The corresponding “CompMax” scalar Results are obtained by selecting the maximum failure index value among the six components.

X.C.2 Complex Results

The Complex Result types are summarized in Tables X.C.12 to X.C.16.


Table X.C.12: Complex Nodal Results.
Result Target Tensor
Name Entities Type
“Displacements (RI), Translational” N V
“Displacements (RI), Rotational” N V
“Displacements (MP), Translational” N V
“Displacements (MP), Rotational” N V
“Velocities (RI), Translational” N V
“Velocities (RI), Rotational” N V
“Velocities (MP), Translational” N V
“Velocities (MP), Rotational” N V
“Accelerations (RI), Translational” N V
“Accelerations (RI), Rotational” N V
“Accelerations (MP), Translational” N V
“Accelerations (MP), Rotational” N V
“Applied Loads (RI), Forces” N V
“Applied Loads (RI), Moments” N V
“Applied Loads (MP), Forces” N V
“Applied Loads (MP), Moments” N V
“MPC Forces (RI), Forces” N V
“MPC Forces (RI), Scalar” N S
“MPC Forces (MP), Forces” N V
“MPC Forces (MP), Scalar” N S
“SPC Forces (RI), Forces” N V
“SPC Forces (RI), Moments” N V
“SPC Forces (MP), Forces” N V
“SPC Forces (MP), Moments” N V


Table X.C.13: Element Complex General Results.
Result Target Tensor
Name Entities Type
“Strain Tensor (RI)” (5) E, EN, EL, ENL T
“Stress Tensor (RI)” E, EN, EL, ENL T
“Strain Tensor (MP)” (5)E, EN, EL, ENL T
“Stress Tensor (MP)” E, EN, EL, ENL T


Table X.C.14: Beam element Complex Results.
Result Target Tensor
Name Entities Type
“Beam Axial Strain for Axial Loads (RI)” (7) E, EN S
“Beam Axial Strain for Bending Loads (RI)” (7) E, EN S
“Beam Axial Strain for Total Loads (RI)” (7) E, EN S
“Beam Shear Strain for Torsion Loads (RI)” (7) E, EN S
“Beam Axial Strain for Axial Loads (MP)” (7) E, EN S
“Beam Axial Strain for Bending Loads (MP)” (7) E, EN S
“Beam Axial Strain for Total Loads (MP)” (7) E, EN S
“Beam Shear Strain for Torsion Loads (MP)” (7) E, EN S
“Beam Axial Stress for Axial Loads (RI)” (7) E, EN S
“Beam Axial Stress for Bending Loads (RI)” (7) E, EN S
“Beam Axial Stress for Total Loads (RI)” (7) E, EN S
“Beam Shear Stress for Torsion Loads (RI)” (7) E, EN S
“Beam Axial Stress for Axial Loads (MP)” (7) E, EN S
“Beam Axial Stress for Bending Loads (MP)” (7) E, EN S
“Beam Axial Stress for Total Loads (MP)” (7) E, EN S
“Beam Shear Stress for Torsion Loads (MP)” (7) E, EN S
“Beam Forces (RI)” (1) E, EN T
“Beam Moments (RI)” (1) E, EN T
“Beam Warping Torque (RI)” E, EN T
“Beam Forces (MP)” (1) E, EN T
“Beam Moments (MP)” (1) E, EN T
“Beam Warping Torque (MP)” E, EN T


Table X.C.15: Bush, Gap and Scalar elements specific Complex Results.
Result Target Tensor
Name Entities Type
“Bush Forces Stress Tensor (RI)” (9) E T
“Bush Forces Strain Tensor (RI)” (9) E T
“Bush Moments Stress Tensor (RI)” (9) E T
“Bush Moments Strain Tensor (RI)” (9) E T
“Bush Forces Stress Tensor (MP)” (9) E T
“Bush Forces Strain Tensor (MP)” (9) E T
“Bush Moments Stress Tensor (MP)” (9) E T
“Bush Moments Strain Tensor (MP)” (9) E T
“Spring Scalar Strain (RI)” E, EN S
“Spring Scalar Stress (RI)” E, EN S
“Spring Scalar Forces (RI)” (3) E, EN S
“Spring Scalar Strain (MP)” E, EN S
“Spring Scalar Stress (MP)” E, EN S
“Spring Scalar Forces (MP)” (3) E, EN S


Table X.C.16: Shell elements specific Complex Results.
Result Target Tensor
Name Entities Type
“Curvature Tensor (RI)” E, EN T
“Shell Forces (RI)” E, EN T
“Shell Moments (RI)” E, EN T
“Curvature Tensor (MP)” E, EN T
“Shell Forces (MP)” E, EN T
“Shell Moments (MP)” E, EN T

Appendix X.D
Predefined criteria

The predefined criteria source code is located in file “SRC/Result/predfinedCriteria.cpp”. So far, five criteria are defined. They are presented in section X.D.1.

Note that the user can define its own criteria, and some preparatory work has already been done. Some explanation is given in section X.D.2.

X.D.1 List of the predefined criteria

Only five predefined criteria are available at the moment. They are presented and discussed in the sub-sections that follow. Additional information on what is done in the criterion can be obtained by reading “SRC/COMMON/result/predfinedCriteria.cpp” source file.

X.D.1.1 “HoneycombAirbusMoS” criterion

This criterion is used to calculate honeycomb core margin of safety according to the so-called “Airbus” core failure criterion than combines the two components of out-of-plane stress tensor. The margin of safety is calculated according to the following expression:

MoS = 1 FoS (τL σL ) 2 + (τW σW ) 2 - 1,

in which τL and τL are the honeycomb longitudinal and transversal shear components of Cauchy stress tensor and σL and σW the corresponding allowables.

The arguments of the criterion are given in Table X.D.1. The method returns an Array of 8 elements according to Table X.D.2:


Table X.D.1: Arguments of the “HoneycombAirbusMoS” predefined criterion
.
Pos. Name Type meaning can be modified?
1 dB DataBase DataBase (or derived) NO
2 fos Real factor of safety NO
3 allL Real shear allowable in L-direction NO
4 allW Real shear allowable in L-direction NO
5 stressRes Result Cauchy Stress Tensor NO


Table X.D.2: Outputs of the “HoneycombAirbusMoS” predefined criterion
.
Pos. Name Type meaning
1 ElemId Integer Critical Element ID
2 NodeId Integer Critical Node ID
3 LayerId Integer Critical Layer ID
4 SubLayerIdInteger Critical Sub-Layer ID
5 sigLmax Real L OOP shear component of stress tensor at critical location
6 sigWmax Real W OOP shear component of stress tensor at critical location
7 mosMin Real Critical margin of safety
8 mosRes Result All the margins of safety that have been calculated

X.D.1.2 “HoneycombAirbusSR” criterion

This criterion is used to calculate honeycomb core margin of safety according to the so-called “Airbus” core failure criterion than combines the two components of out-of-plane stress tensor. The margin of safety is calculated according to the following expression:

MoS = 1 FoS (τL σL ) 2 + (τW σW ) 2 - 1,

in which τL and τL are the honeycomb longitudinal and transversal shear components of Cauchy stress tensor and σL and σW the corresponding allowables. Actually, one calculates a strength ratio instead of a margin of safety. The relation between strength ratio, reserve factor and margin of safety is as follows:

SR = 1 RF = 1 MoS + 1.

This leads to the following expression for the strength ratio:

SR = FoS ( τL σL ) 2 + (τW σW ) 2,

(The display of strength ratios instead of margins of safety allows usually a better identification of critical areas. This is true,for example, when results are saved in GMSH format.)

The arguments of the criterion are given in Table X.D.3. Compared to the “HoneycombAirbusMoS” discussed in section X.D.1.1, two new parameters are defined: “strL” and “strW” String arguments. These arguments, allow to specify the Cauchy Stress Tensor components that should be considered for τL and τW respectively. Possible values are “XZ”, “ZX”, “YZ”, “ZY”, “XY” and “YX”. (This capability has been added to allow the post-processing of stress when the usual convention for honeycomb core material definition have not been followed.

The method returns an Array of 8 elements according to Table X.D.4:


Table X.D.3: Arguments of the “HoneycombAirbusSR” predefined criterion
.
Pos. Name Type meaning can be modified?
1 dB DataBase DataBase (or derived) NO
2 fos Real factor of safety NO
3 allL Real shear allowable in L-direction NO
4 allW Real shear allowable in L-direction NO
5 strL String shear allowable in L-direction NO
6 strW String shear allowable in L-direction NO
7 stressRes Result Cauchy Stress Tensor NO


Table X.D.4: Outputs of the “HoneycombAirbusSR” predefined criterion
.
Pos. Name Type meaning
1 ElemId Integer Critical Element ID
2 NodeId Integer Critical Node ID
3 LayerId Integer Critical Layer ID
4 SubLayerIdInteger Critical Sub-Layer ID
5 sigLmax Real L OOP shear component of stress tensor at critical location
6 sigWmax Real W OOP shear component of stress tensor at critical location
7 srMax Real Critical strength ratio
8 srRes Result All the strength ratios that have been calculated

X.D.1.3 “VonMisesMoS” criterion

This criterion is used to calculate Von Mises margin of safety. The margin of safety is calculated according to the following expression:

MoS = σall FoSσV M - 1,

σV M = (σxx - σyy )2 + (σyy - σzz )2 + (σzz - σxx )2 2 + 3σxy2 + 3σxz2 + 3σyz2.

The arguments of the criterion are given in Table X.D.5. The method returns an Array of 7 elements according to Table X.D.6:


Table X.D.5: Arguments of the “VonMisesMoS” predefined criterion
.
Pos. Name Type meaning can be modified?
1 dB DataBaseDataBase (or derived) NO
2 fos Real factor of safety NO
3 sigAll Real allowable stress NO
4 stressRes Result Cauchy Stress Tensor NO


Table X.D.6: Outputs of the “VonMisesMoS” predefined criterion
.
Pos. Name Type meaning
1 ElemId Integer Critical Element ID
2 NodeId Integer Critical Node ID
3 LayerId Integer Critical Layer ID
4 SubLayerIdInteger Critical Sub-Layer ID
5 vmMax Real Von Mises equivalent stress tensor at critical location
6 mosMin Real Critical margin of safety
7 mosRes Result All the margins of safety that have been calculated

X.D.1.4 “VonMisesSR” criterion

This criterion is used to calculate Von Mises strength ratios. The relation between strength ratio, reserve factor and margin of safety is as follows:

SR = 1 RF = 1 MoS + 1.

This leads to the following expression for the strength ratio:

SR = FoSσV M σall ,

in which

σV M = (σxx - σyy )2 + (σyy - σzz )2 + (σzz - σxx )2 2 + 3σxy2 + 3σxz2 + 3σyz2.

The arguments of the criterion are given in Table X.D.7. The method returns an Array of 7 elements according to Table X.D.8:


Table X.D.7: Arguments of the “VonMisesSR” predefined criterion
.
Pos. Name Type meaning can be modified?
1 dB DataBaseDataBase (or derived) NO
2 fos Real factor of safety NO
3 sigAll Real allowable stress NO
4 stressRes Result Cauchy Stress Tensor NO


Table X.D.8: Outputs of the “VonMisesSR” predefined criterion
.
Pos. Name Type meaning
1 ElemId Integer Critical Element ID
2 NodeId Integer Critical Node ID
3 LayerId Integer Critical Layer ID
4 SubLayerIdInteger Critical Sub-Layer ID
5 vmMax Real Von Mises equivalent stress tensor at critical location
6 srMax Real Critical strength ratio
7 srRes Result All the strength ratios that have been calculated

X.D.1.5 “SGI_SR” criterion

This criterion is used to calculate with a single call three connection failure criteria: sliding, gapping and insert. The calculation is done by calculating strength ratios. The relation between strength ratio, reserve factor and margin of safety is as follows:

SR = 1 RF = 1 MoS + 1.

In this case, three strength ratios are calculated:

In these expressions, various scalar values related to the connection force and moment vectors are calculated:

Faxial = Fd,

Fshear = F F - F axial 2,

Mtorsion = Md,

Mbending = M M - Mtorsion 2.

The arguments of the criterion are given in Table X.D.9:

The method returns an Array of 15 elements (5 elements for each criterion):


Table X.D.9: Arguments of the “SGI_SR” predefined criterion
.
Pos. Name Type meaning can be modified?
1 dB DataBase DataBase (or derived) NO
2 extractionMethod String Forces and Moments extraction method NO
3 fRes Result Vectorial Forces YES
4 mRes Result Vectorial Moments YES
5 csId String/Integer Reference coordinate system NO
6 vx Real X component of connection axis vector NO
7 vy Real Y component of connection axis vector NO
8 vz Real Z component of connection axis vector NO
9 FoSs Real Sliding criterion safety factor NO
10 FoSg Real Gapping criterion safety factor NO
11 FoSi Real Insert criterion safety factor NO
12 Pmin Real Bolt minimum pretension for sliding or gapping NO
13 Cf Real Friction coefficient for sliding criterion NO
14 Lg Real Prying length for gapping criterion NO
15 PSS Real Insert tensile allowable NO
16 QSS Real Insert shear allowable NO


Table X.D.10: Outputs of the “SGI_SR” predefined criterion
.
Pos. Name Type meaning
1 ssrMax Real/Boolean Maximum Strength Ratio (for sliding)
2 ENId Integer/Boolean Critical Element/Node ID (for sliding)
3 sfAxialMax Real/Boolean Axial force in critical connection (for sliding)
4 sfShearMax Real/Boolean Shear force in critical connection (for sliding)
5 ssrRes Result/Boolean All the strength ratios (for sliding)
6 gsrMax Real/Boolean Maximum Strength Ratio (for gapping)
7 ENId Integer/Boolean Critical Element/Node ID (for gapping)
8 gfAxialMax Real/Boolean Axial force in critical connection (for gapping)
9 gmBendingMax Real/Boolean Bending moment in critical connection (for gapping)
10 gsrRes Result/Boolean All the strength ratios (for gapping)
11 isrMax Real/Boolean Maximum Strength Ratio (for inserts)
12 ENId Integer/Boolean Critical Element/Node ID (for inserts)
13 ifAxialMax Real/Boolean Axial force in critical connection (for inserts)
14 ifShearMax Real/Boolean Shear force in critical connection (for inserts)
15 isrRes Result/Boolean All the strength ratios (for inserts)

X.D.1.6 Interaction criteria

One often finds in the literature semi-empirical failure criteria corresponding to the combination of elementary failure modes with different load components. For example, in [otNCE21], one finds two criteria for the verification of ultimate failure of bolt under combined tensile, shear and bending loads:

( Psu Psu-allow ) 2.5 + ( Ptu Ptu-allow + fbu Ptu-allow ) 1.5 1.
(X.D.1)

( Psu Psu-allow ) 2.5 + ( Ptu Ptu-allow ) 1.5 + ( fbu Ptu-allow ) 1.
(X.D.2)

The derivation of a reserve factor from expressions (X.D.1) or (X.D.2) is not straightforward. Statring from the definition of reserve factor (value by which loads can be multiplied to reach failure), one verifies that for (X.D.1) it corresponds to the value x such that

(x Psu Psu-allow ) 2.5 + [x ( Ptu Ptu-allow + fbu Ptu-allow )] 1.5 - 1 = 0.
(X.D.3)

Similarly, for interaction expression (X.D.2), RF is the solution in x of

(x Psu Psu-allow ) 2.5 + (x Ptu Ptu-allow ) 1.5 + (x fbu Ptu-allow ) - 1 = 0.
(X.D.4)

An analytic expression of the solution x of equations (X.D.3) or (X.D.4) as a function of the different parameters is generally not available. Then, one must try other ways to calcula x numerically. For the three methods “Interaction_2_SR”, “Interaction_3_SR” and “Interaction_N_SR”, we propose a dichotomic solver. The two first methods are specializations of the general case solved by predefined criterion “Interaction_N_SR”. This corresponds to the resolution in x of equation:

i=1N (α ix)βi - 1 = 0.
(X.D.5)

The 2N arguments of the “Interaction_N_SR” predefined criterion are parameters in the following order: α1, β1, α2... and βN:

(“Interaction_2_SR”, “Interaction_3_SR” criteria need 4 and 6 arguments respectively.) “Interaction_N_SR” predefined criterion returns an Array of two values:

A modified version of the “Interaction_abg_N_SR” predefined criterion corresponds to the resolution in x of the following equation:

i=1N (α ix + γi) βi - 1 = 0.
(X.D.6)

The 3N arguments of the “Interaction_abg_N_SR” predefined criterion are parameters in the following order: α1, β1, γ1, α2... and γN:

X.D.2 User predefined criteria

The use that wishes to define his own criteria can do it by inserting code in “SRC/Result/predfinedCriteria.cpp” source file and re-compiling the library. Three areas are to be modified:

Appendix X.E
A modular post-processing

In this Chapter, one presents an example of modular automated post-processing program using the “FeResPost” ruby library. This Chapter is organized as follows:

X.E.1 Global structure of the program

Different modules corresponding to the different concepts used in the post-processing.

X.E.1.1 The “LoadCases” module

The “LoadCase” modules corresponds to the concept of load case. In our post-processing program, a load case corresponds to the definition of a set of Results, and their association to a DataBase. The Results can be directly read from an “op2” Nastran Result file, or produced by linear combination of elementary Results.

LoadCase module has only one member data: @@dbList. This Hash contains a list of DataBases used for the post-processing.

Several methods are defined:

X.E.2 Two post-processing modules

One defines two-post-processing modules. The first module, described in section X.E.2.1 uses the Grid Point Forces and Moments to calculate connection margins of safety. The second module, presented in section X.E.2.3 uses the Cauchy stress tensor to calculate margins of safety.

X.E.2.1 One using the connection loads

The module “Post_Connect” defines a post-processing of connections considered individually. It builds the Results corresponding to forces and moments at connections. Then, up to three criteria can be calculated. The criteria correspond respectively to sliding, gapping, and failure of inserts.

X.E.2.1.1 Member data

The member data defined in class “Post_Connect” are given below:

   @@fAxial=nil
   @@fShear=nil
   @@mTorsion=nil
   @@mBending=nil

“fAxial”, “fShear”, “mTorsion” and “mBending” contain scalar Results corresponding to different components of the connection loads. These member data are set by method “calcOneInterface”.

X.E.2.1.2 “calcOneInterface” method

This methods builds the scalar Results corresponding to connection loads. It works in several phases:

1.

A Group on which the Results shall be retrieved from the DataBase is build:

            grpA = db.getGroupCopy(@@grpNameA)
            grpB = db.getGroupCopy(@@grpNameB)
            tmpGrp = grpA * grpB
            grpC = db.getElementsAssociatedToNodes(tmpGrp)
            grpC += tmpGrp
            grpC *= grpA

“grpC” is build in such a way that it contains all the elements and nodes necessary to recover the contributing Grid Point Forces (internal forces and moments). Note that, the Groups defined in the DataBase must be such that “grpA” contains all the contributing element and nodes, and “grpB” contains all the contributing nodes.

2.

Parameters are retrieved:

            params = getParameters(nil)
            csId = params["csId"]
            direction = params["direction"]
            norme=0.0
            for i in 0..2
               norme+=direction[i]*direction[i]
            end
            norme=Math.sqrt(norme)
            for i in 0..2
               direction[i]/=norme
            end
            criteriaList=params["criteriaList"]

Note that the list of failure criteria that shall be calculated for each connection is defined in the parameters that are retrieved.

3.

Then, Results are retrieved from the DataBase and used to build the four load components:

            tmpForces=db.getResultCopy(lcName,scName,\
               "Grid Point Forces, Internal Forces","ElemNodes",grpC,[])
            tmpMoments=db.getResultCopy(lcName,scName,\
               "Grid Point Forces, Internal Moments","ElemNodes",grpC,[])
      
            tmpForces.modifyRefCoordSys(db,csId)
            tmpMoments.modifyRefCoordSys(db,csId)
      
            tmpForces=tmpForces.deriveByRemapping("CornersToNodes",\
               "sum",db)
            tmpMoments=tmpMoments.deriveByRemapping("CornersToNodes",\
               "sum",db)
      
            @@fAxial=tmpForces*direction
            @@fShear=sqrt(sq(tmpForces)-sq(@@fAxial))
            @@mTorsion=tmpMoments*direction
            @@mBending=sqrt(sq(tmpMoments)-sq(@@mTorsion))

4.

Finally, the different criteria in “criteriaList” Array are calculated by calls to the appropriate methods:

            criteriaList.each do |critName|
               case critName
               when "sliding" then
                  crit_Sliding(db,lcName,scName)
               when "gapping" then
                  crit_Gapping(db,lcName,scName)
               when "insert" then
                  crit_Insert(db,lcName,scName)
               end
            end

Criteria methods are described below.

X.E.2.1.3 Sliding criterion

This criterion, defined by “crit_Sliding” method is used to calculate sliding margins of safety with the following expression:

MoS = Cf * Pmin FoS * (Cf * max (Faxial, 0) + Fshear) - 1,

in which Cf is the friction coefficient between assembled elements and Pmin is an estimate of the minimum possible pretension of the bolt.

One gives the lines used for the calculation of margins of safety:

      mos=(cf*pMin/fos)/(max(@@fAxial,0.0)*cf+@@fShear)-1.0
      mosMin=mos.extractResultMin
      rklMin=mosMin.extractRkl
      fAxialMin=@@fAxial.extractResultOnRkl(rklMin)
      fShearMin=@@fShear.extractResultOnRkl(rklMin)

Other programming lines are devoted to the extraction of parameters and printing of Results. One first checks whether the output file exists. If it exists, one opens it in “append” mode. If it does not exists, it is opened in “write” mode and a title line is printed:

      if (File.exist?(outputFile)) then
         os=File.open(outputFile,"a")
      else
         os=File.open(outputFile,"w")
         os.printf("%30s%40s%10s%8s%10s%8s%8s%14s%14s%8s\n",\
            "LoadCase ID","Interface","Elem ID","FoS",\
            "Type","Pmin","Cf","Faxial","Fshear","MoS")
      end

In either case, the critical margin and corresponding information is printed in the result file:

      interfStr=format("%s/%s",@@grpNameA,@@grpNameB)
      os.printf("%30s%40s%10s%8.2f%10s%8.1f%8.3f%14.1f%14.1f",\
                lcName,interfStr,mosData[1],fos,connectType,pMin,\
                cf,fAxialData[5],fShearData[5])
      if (mosData[5]>1000.0) then
         os.printf("%8s\n",">1000")
      else
         os.printf("%8.2f\n",mosData[5])
      end

Finally, the output stream is closed.

X.E.2.1.4 Gapping criterion

This criterion, defined by “crit_Gapping” method is used to calculate gapping margins of safety with the following expression:

MoS = Pmin FoS * (max (Faxial, 0) + MbendingR) - 1,

in which R is a parameter that allows to take into account the prying effect related to the bending moment in the connection and Pmin is an estimate of the minimum possible pretension of the bolt.

One only gives the lines used for the calculation of margins of safety:

         mos=(pMin/fos)/(max(@fAxial,0.0)+@mBending/radius)-1.0
         mosMin=mos.extractResultMin
         rklMin=mosMin.extractRkl
         fAxialMin=@fAxial.extractResultOnRkl(rklMin)
         mBendingMin=@mBending.extractResultOnRkl(rklMin)

Other programming lines are devoted to the extraction of parameters and printing of Results.

X.E.2.1.5 Insert criterion

This criterion, defined by “crit_Insert” method is used to calculate inserts margins of safety with the following expression:

MoS = 1 FoS (Faxial PSS ) 2 + (Fshear QSS ) 2 - 1,

In which “PSS” is the axial allowable of the insert and “QSS” is its shear allowable.

One only gives the lines used for the calculation of margins of safety:

         tmp = sq(@fAxial/pss)+sq(@fShear/qss)
         tmpMax = tmp.extractResultMax
         mosMin = (1.0/fos)/sqrt(tmpMax)-1.0
         rklMin = mosMin.extractRkl
         fAxialMin = @fAxial.extractResultOnRkl(rklMin)
         fShearMin = @fShear.extractResultOnRkl(rklMin)

Other programming lines are devoted to the extraction of parameters and printing of Results.

X.E.2.1.6 Definition of the list of interfaces

The interfaces (lists of pair of Groups) on which connection margins will be calculated are defined in “calcAll” method. This method corresponds to a definition of data. One first defines a list of pair of groups with statement like:

      list = []

      list << ["pan_MX","bar_MXMY"]
      list << ["pan_MX","bar_MXMZ"]
      list << ["pan_MX","bar_MXPY"]
      list << ["pan_MX","bar_MXPZ"]
      list << ["pan_MX","corner_MXMYMZ"]
      ...

Then a loop on these data is done, and method “calcOneInterface” is called for each interface:

      list.each do |groupNameA,groupNameB|
         @@grpNameA=groupNameA
         @@grpNameB=groupNameB
         calcOneInterface(db,lcName,scName)
      end

Parameters “@@grpNameA” and “@@grpNameB” are passed by member data of the module. The other parameters are passed as arguments of the call to “calcOneInterface”.

X.E.2.1.7 Definition of parameters

Some parameters depend on the interfaces. For example, the direction of connections, allowables... The method “getParameters” is used to produce the parameters corresponding to each interface.

This method has one parameter “critName” a String argument corresponding to the criterion that requires the parameters. If the argument is nil, one considers that the method is called by “calcOneInterface” and data corresponding to the different orientation of the connection are returned. If the method is called by a criterion method, the data returned correspond to allowables used in the calculation of margins of safety.

X.E.2.2 Critics on the previous post-processor

The “Post_Connect” module defines methods corresponding to the calculation operations, and methods than can be considered as definition of data. Of course, many different types of data definitions are possible. For example, the definition of interfaces, and of the calculation parameters could be read from a file.

The calculation methods as well as the data are defined in a single module. However, it could be interesting to split the definition of data into several files. This could be interesting, for example, when several persons work on the same project. At the same time, the copying of the methods corresponding to calculation methods into different data files is a poor way to use the object-oriented capabilities of ruby language.

One shows in section X.E.2.3 a different modular design that allows not to repeat the writing of calculation methods, and at the same time to split the module into separate smaller entities. More precisely, one defines a generic “Post_Cauchy” module that performs calculations based on the components of Cauchy stress tensor. Then two modules calculating honeycomb margins of safety and skin margins of safety are defined as two specialized modules using “Post_Cauchy” capabilities.

X.E.2.3 One using the Cauchy stress tensor

The module “Post_Cauchy” performs the post-processing of Results corresponding to the Cauchy stress tensor. Presently, three criteria corresponding to the stress tensor are available: an “Airbus” criterion for the calculation of honeycomb, a “MaxShear” criterion for the calculation of honeycomb, and a “VonMises” criterion for the calculation of metallic parts.

X.E.2.3.1 Member data

The class has three member data:

X.E.2.3.2 “calcOneGroup” method

This method has one more argument than the corresponding method in “Post_Connect” module:

   def Post_Cauchy::calcOneGroup(db,lcName,scName,paramsMethod)

“paramsMethod” is the method to be called when one wishes to retrieve calculation parameters.

“calcOneGroup” performs the building of “stressTensor” member data by retrieving the corresponding Results. The first operations performed by the method are programmed as follows:

      grp = db.getGroupCopy(@@groupName)

      params = paramsMethod.call(nil)
      interpolation = params["interpolation"]
      layers = params["layers"]
      criteriaList=params["criteriaList"]

      @@stressTensor=db.getResultCopy(lcName,scName,\
         "Stress Tensor",interpolation,grp,layers)

So far, the method is not very different than the corresponding method of “Post_Connect” module. Just note the way the parameters method is called.

The rest of the method is similar too:

      criteriaList.each do |critName|
         case critName
         when "airbus" then
            crit_HoneyAirbus(db,lcName,scName,paramsMethod)
         when "maxShear" then
            crit_HoneyMaxShear(db,lcName,scName,paramsMethod)
         when "vonMises" then
            crit_VonMises(db,lcName,scName,paramsMethod)
         end
      end

The different methods that performs the criteria calculations are called if necessary. Note that the method to be called to retrieve parameters is passed as argument to the different criteria methods.

X.E.2.3.3 Airbus criterion

This criterion, defined by “crit_HoneyAirbus” method is used to calculate margins of safety in the honeycomb with the following expression:

MoS = 1 FoS (τL σL ) 2 + (τW σW ) 2 - 1,

in which τL and τL are the honeycomb longitudinal and transversal shear components of Cauchy stress tensor and σL and σW the corresponding allowables.

As the programming of the criterion is not more complicated than the programming of “Post_Connect” module criteria, one does not describe the instructions.

X.E.2.3.4 MaxShear criterion

This criterion, defined by “crit_HoneyMaxShear” method is used to calculate margins of safety in the honeycomb with the following expression:

MoS = σW FoS * τ - 1,

in which τ is the maximum shear stress and σW the transverse shear allowable.

X.E.2.3.5 Von Mises criterion

This criterion, defined by “crit_VonMises” method is used to calculate margins of safety in the metallic parts with the following expression:

MoS = Ft FoS * σV M - 1,

in which σV M is the Von Mises equivalent stress and Ft the material tensile allowable.

X.E.2.3.6 “Post_honeycomb” specialization module

This module includes “Post_Cauchy” module:

module Post_honeycomb

   include Post_Cauchy

   ...

This means that the methods of “Post_Cauchy” module are now visible in “Post_honeycomb”. In this example, the module has two specific methods:

1.

“calcAll” defines the list of Groups on which honeycomb margins are calculated. Then, a loop on this list is done and the “calcOneGroup” of “Post_Cauchy”

            list = ["pan_MX_Honey_50", "pan_MY_Honey_50", "pan_PX_Honey_50",
                    "pan_PY_Honey_50", "pan_PZ_Honey_72", "pan_SUP_Honey_50"]
      
            list.each do |groupName|
               @@groupName=groupName
               Post_Cauchy::calcOneGroup(db,lcName,scName,method(:getParameters))
            end

Note that the call to “calcOneGroup” has a fourth parameter: the method that shall be called to retrieve the necessary data.

2.

This method “getParameters” is the second method defined in “Post_honeycomb” module. This method is similar to the corresponding method in “Post_Connect” module.

X.E.2.3.7 “Post_skins” specialization module

This module is very similar to ‘Post_honeycomb” module.

X.E.3 Main function

The file “testSat.rb” contains the “testSat” method that starts the loop on load cases, and where the different post-processing criteria done for each load case are selected.

The different modules that are used in the “testSat” method are made visible by several require statements:

require "util"
require "loadCases"

require "data_Post_Connect"
require "data_Post_honeycomb"
require "data_Post_skins"

Then, in “testSat” method, a loop on the load cases is started by calling the “each” iterator of “LoadCases” module with appropriate parameter:

   version="All"
   LoadCases.each(version) do |db,lcName,scName|
      PostConnect.calcAll(db,lcName,scName)
      Post_honeycomb.calcAll(db,lcName,scName)
      Post_skins.calcAll(db,lcName,scName)
      GC.start
   end

The different post-processing criteria are called in the block that follows the iterator. At the end of each load case calculation a call to the garbage collector cleans the memory.

X.E.4 Conclusions

One presented in the Chapter a finite element post-processing program written by defining modules. This post-processing works and it is possible to trick the language in order to prevent the rewriting of codes. (See the “Post_Cauchy” class.)

However, the program written in this example uses poorly the object-oriented capabilities of ruby. One presents in Chapter X.E.4 an example of object-oriented post-processing.

Appendix X.F
An object-oriented post-processing

This Chapter is devoted to the presentation of an object-oriented post-processing program. The purpose of the example is to illustrate the flexibility that object-oriented programming introduces in the development of post-processing. Note however, that this example requires a better knowledge of object-orientation, and of the ruby language.

The example is very similar to the example presented in Chapter X.D.2. Most programming lines are identical. When presenting the program one only present the different aspects that are specific to the object-orientation of the program. There is however one significant difference between versions “A” and “B” of the post-processing. Version “B” presents one possible programming of dynamic Results post-processing.

The example program is located under "PROJECTb" directory.

X.F.1 Difference in file organization

One characteristic of the new post-processing, is that it allows to better separate the definition of calculation operations and of the definition of data. Therefore, two directories have been created under "PROJECTb" directory:

1.

Directory "POST" contains the definition of classes used in the post-processing. It corresponds to the definition of calculation operations.

2.

Directory "Data" contains the definition of modules, classes and objects corresponding to the definition of data.

Directory "PROJECTb" still contains the main ruby file "testSat.rb".

X.F.2 Transformation of modules into classes

Two post-processing classes are defined: "PostCauchy" and "PostConnect". Each of these classes has been obtained by modifying slightly the corresponding post-processing modules of Chapter X.D.2. Note that for connections, new criteria have been defined.

Both classes inherit the generic post-processing class "GenPost". This class is very short, and its main purpose is to manage a list of all the post-processing objects that shall be created when the data are defined (see below). The programming of the class looks as follows:

class GenPost

    @@postList = []

    public

    def initialize
        @@postList << self
    end

    def GenPost::each
        @@postList.each do |current|
            yield current
        end
    end

end # class Post

The class also defines an iterator that loops on all the instances of the class that have been stored in class member data "@@postList".

X.F.2.1 Post-processing of Cauchy stress tensor

One presents below the class "Post_Cauchy" which has been more deeply modified than
"Post_Connect". The inheritance of "GenPost" is ensured by the use of following statements:

require "genPost"
class PostCauchy < GenPost

One decided also that member data are no-longer module or class member data. Instead, the become instance member data:

    @groupName
    @layerNames
    @stressTensor

    @currentMoSResult
    @minMosResults

For this post-processing, two member data have been added to allow the storage of results in the object between the different calls to its methods.

One also adds and initializes a method that defines the member data when an instance of the class is created:

    def initialize
        super

        @groupName = nil
        @layerNames = nil
        @stressTensor = nil

        @currentMoSResult = nil
        @minMosResults = {}
    end

Note the call to "super" that ensures that the corresponding initialize method of "GenPost" class shall be called too. This ensures that each time an instance of "Post_Cauchy" is created, the "GenPost" class is made aware of it, and a pointer to this object is added to its "@@postList" class member data.

Class "Post_Cauchy" defines a method used to write Gmsh result files:

    def writeGmshMinMosResults(db,fileName,skeleton)
        results=[]
        @minMosResults.each do |key,val|
            results << [val,key,"ElemCorners"]
        end
        db.writeGmsh(fileName,0,results,\
                         [[skeleton,"mesh_slat"]],\
                         [[skeleton,"skel_slat"]])
    end

the Results stored in the file correspond to those stored in the new member data "@minMosResults". This member data is a Hash that contains the pairs of String identifiers and Results corresponding to minimum margins of safety. This variable is updated at the end of each criterion calculation to contain maps of the minimum margins of safety:

            tmpStr=@groupName+"_"+critName
            if (@minMosResults.has_key?(tmpStr)) then
                tmpRes1=@minMosResults[tmpStr]
                tmpRes2=Post.min(tmpRes1,@currentMoSResult)
                @minMosResults[tmpStr]=tmpRes2
            else
                @minMosResults[tmpStr]=@currentMoSResult
            end

This method uses the last calculated margin mapping result, stored in "@currentMoSResult".

X.F.2.2 A composite post-processing

The Class “PostComposite” calculates composite failure indices and reserve factors for a specified failure criterion. The calculation is done with CLA classes using a loading using finite element “Shell Forces” and “Shell Moments” Results. Practically, one defines a loading as follows:

        ld=ClaLoad.new
        ld.Id="testLoad"
        ld.setMembrane([0.0,0.0,0.0],"femFM","femFM","femFM")
        ld.setFlexural([0.0,0.0,0.0],"femFM","femFM","femFM")
        ld.setOutOfPlane([0.0,0.0],"femFM","femFM")

        res=db.getResultCopy(lcName,scName,"Shell Forces",
                                    interpolation,grp,layers)
        res.modifyRefCoordSys(db,"lamCS")
        ld.setShellForces(res)

        res=db.getResultCopy(lcName,scName,"Shell Moments",
                                    interpolation,grp,layers)
        res.modifyRefCoordSys(db,"lamCS")
        ld.setShellMoments(res)

Then, the failure indices and reserve factors are calculated as follows:

        criteria=[]
        criteria << ["composite_RF",criterion,"RF",false,false]
        criteria << ["composite_FI",criterion,"FI",false,false]
        outputs=db.calcFiniteElementResponse(@compDb,0.0,ld,[false,true,false],
            [],[],fos,criteria)

        rfRes=outputs["composite_RF"]
        fiRes=outputs["composite_FI"]

Note that the calculation uses a composite database stored in “@compDb” member data. This ClaDb object must have been defined before. The class also records envelopes of failure indices in “@minMosResults” member data.

Note that there is a limitation to the post-processing: the thermo-elastic part of the laminate loading is not considered in this example. Therefore, the results might be inexact for thermo-elastic load cases (orbit load cases for example). The class is defined in file
“POST/post_Composite.rb”.

X.F.3 A new post-processing for dynamic Results

The new object-oriented structure for the post-processing also allows the post-processing of dynamic Results. One Presents below two examples of post-processing for dynamic Results.

X.F.3.1 Simple extraction of components

A new post-processing class is created to allow the presentation of dynamic Results. Actually, this class only extracts the magnitude and phase for one finite element entity and one component, and saves it into an Array, for later output in a text file. The class is called “PostExtract” and has only one member data: “extracts” in which the extracted Results shall be stored.

The “initialize” method calls the constructor of the parent class and initializes “extracts” to a void Hash:

    def initialize
        super
        @extracts = {}
    end

Then the sequence of operations to perform the extractions is described below. It is performed by the “calcOneGroup” method:

    def calcOneGroup(db,lcName,scName,refName,grpContent,resName,
                          extractMethod,csId,component)
        ...

The method has nine arguments:

Then the following sequence of operations:

The class “PostExtract” also defines a method for the final processing of the values stored in “extracts” member data. This method, called “gnuplot” outputs the Results in text files created in “OUT_DYNAM” directory. Also, a “dat” file containing the gnuplot commands to create graphical outputs is created in the same directory. The name of this command file is the argument of “gnuplot” method:

    def gnuplot(datName)
        gnuplotOs=File::open("OUT\_DYNAM/"+datName,"w")
        gnuplotOs.printf("\nset terminal png\n\n")
        @extracts.each do |key,tabs|
            fileName="OUT\_DYNAM/"+key+".txt"
            os=File::open(fileName,"w")
            tabs.each do |mode,freq,mag,phase|
                os.printf("%4d%15g%15g%15g\n",mode,freq,mag,phase)
            end
            os.close
            gnuplotOs.printf("set output \"%s_m.png\"\n",key)
            gnuplotOs.printf("plot \"%s.txt\" using 2:3 with lines\n",key)
            gnuplotOs.printf("set output \"%s_p.png\"\n",key)
            gnuplotOs.printf("plot \"%s.txt\" using 2:4 with points 1\n\n",key)
        end
        gnuplotOs.close
    end

X.F.3.2 Post-processing of composite dynamic Results

One also defines a modified version of “PostComposite” class devoted to the corresponding post-processing of dynamic results in Real-Imaginary format. This Class is defined in file “POST/post_DynamComposite.rb” and the Class is named “PostDynamComposite” Its definition is nearly the same as the corresponding static class. Only, for each frequency, an additional loop performs the calculation for Real Results extracted at different rotation angles:

        ...

        ld=ClaLoad.new
        ld.Id="testLoad"
        ld.setMembrane([0.0,0.0,0.0],"femFM","femFM","femFM")
        ld.setFlexural([0.0,0.0,0.0],"femFM","femFM","femFM")
        ld.setOutOfPlane([0.0,0.0],"femFM","femFM")

        forces=db.getResultCopy(lcName,scName,"Shell Forces (RI)",
                                        interpolation,grp,layers)
        forces.modifyRefCoordSys(db,"lamCS")

        moments=db.getResultCopy(lcName,scName,"Shell Moments (RI)",
                                    interpolation,grp,layers)
        moments.modifyRefCoordSys(db,"lamCS")

        critTheta=critElem=critNode=critLayer=critSubLayer=critFI=critRF=nil;

        (0..nbrAngles).step(1) do |i|
            theta=360.0*i/nbrAngles

            res=forces.getR(theta)
            ld.setShellForces(res)

            res=moments.getR(theta)
            ld.setShellMoments(res)

            ...

        end # Angles loop

Then, the critical angle is identified and the corresponding Results are printed in the a result file.

The calculation has one additional parameter: “nbrAngles”, which corresponds to the number of rotation angles to be tested in the post-processing.

X.F.4 Main function

"testSat" method is slightly more complicated than before:

def testSat
    db=LoadCases.getDb("LAUNCH")
    GenPost::each do |current|
        if current.respond_to?("preCalc") then
            current.preCalc(db)
        end
    end
    GC.start

    version="All"
    LoadCases.each(version) do |db,lcName,scName|
        GenPost::each do |current|
            if current.respond_to?("calcAll") then
                current.calcAll(db,lcName,scName)
            end
        end
        GC.start
    end

    db=LoadCases.getDb("LAUNCH")
    GenPost::each do |current|
        if current.respond_to?("postCalc") then
            current.postCalc(db)
        end
    end
    GC.start
end

The "GenPost" iterator is used to loop on the different object of class "GenPost" or of one of its derived classes. This iterator is called three times:

1.

The first time "GenPost" iterator is used, one checks the existence of “preCalc” method in each object to perform preliminary operations before the loop on load case.

2.

Then, the iterator is called inside the loop on load cases to perform the operations required for each load case.

3.

The third time the iterator is called, this is done outside the load cases loop. Then the instance method "postCalc" is called to perform the operations that are to be done at the very end of the program. In the example, this operation corresponds to the printing of the maps of critical margins.

Note that “preCalc”, “calcAll” and “postCalc” methods are now instance methods. This means they are specific to a particular instance of the classes. Note also, that the availability of these instance methods is tested before the method is called.

The “testSat” example is defined in “testSat.rb” file. Similarly, a “dynam.rb” file is defined to provide an example for dynamic analysis. ‘dynam.rb” is very similar to “testSat.rb”, but the file calls another version of the LoadCases and includes other data for post-processing:

require "DATA/data_Post_accel"
require "DATA/data_Post_cbush"

One should keep in mind that the data for dynamic Results post-processing are generally very different than the data for Static load cases post-processing. This justifies that separate “main” data files are written for these different categories of load cases.

X.F.5 Definition of data

X.F.5.1 Data for load cases

Those data are very similar to those defined in “A” version of the post-processing. One added however, new methods to the “LoadCase” module to allow the post-processing of dynamic Results (SOL108 and SOL111 of Nastran).

In iterator “LoadCases::each”, a new proc object called “makeDynamLoop” loops on all the dynamic sub-cases (frequency outputs) for a given load case name. The three argument of this loop are

The first operation performed by “makeDynamLoop” is to build a list of sub-cases in sorted in order of increasing frequencies:

            lcNames=[lcName]
            tmpList={}
            xdbInfos=db.getXdbLcInfos(fullXdbName)
            xdbInfos.each do |info|
                if (info[0]==lcName) then
                    tmpList[info[4]]=info[1]
                end
            end
            scList=tmpList.sort

In the previous instructions, one first loads the information about load cases and sub-cases stored in the xdb Result file. Then, the sub-cases corresponding to the selected load case name are selected. Finally, they are sorted and stored in the Array “scList”.

Then, a loop is done on the list of sub-cases stored in “scList”. A new Array “scNames” containing a list of sub-cases is filled. Each time its size reaches the values specified by the proc argument, one reads the Results, yields them, and finally erases them from the DataBase. This is done as follows:

            scNames=[]
            scList.each do |intId,scName|
                scNames << scName
                if (scNames.size==maxScNbr) then
                    db.readXdb(fullXdbName,lcNames,scNames)
                    scNames.each do |name|
                        yield([db,lcName,name])
                        db.removeResults("SubCaseId",name)
                        GC.start
                    end
                    scNames=[]
                end
            end

At the end, the remaining sub-cases are calculated the same way:

            db.readXdb(fullXdbName,lcNames,scNames)
            scNames.each do |name|
                yield([db,lcName,name])
                db.removeResults("SubCaseId",name)
                GC.start
            end
            GC.start
        end

An example of use of the “makeDynamLoop” proc follows:

        when "SINUS_Z" then
            db=getDb("LAUNCH")
            fullXdbName=getXdbDirName()+"/sol111_ri_xyz.xdb"
            makeDynamLoop.call(fullXdbName,"SINUS_Z",30)

In this case, the Results of “SINUS_Z” load case are required, and the maximum number of sub-cases loaded simultaneously in the DataBase is 30. Note that this number should be chosen with care: if it is too small, many readings of the Nastran xdb file will be necessary which increases the disk access time. On the other hand, if the number is too big, a larger amount of memory might be necessary to store the Results in the DataBase. This is important if you have limited resources. It is the responsibility of “LoadCases” module manager to select an appropriate value of this integer parameter.

Note that we voluntarily limit the example of dynamic Results post-processing to a simple extraction from an xdb file. Actually, the possibilities of FeResPost are larger that. For example, it should be possible to read simultaneously the Results for different load cases as “SINUS_X”, “SINUS_Y” and “SINUS_Z” and to yield linear combinations of these elementary Results for the different frequency outputs.

X.F.5.2 Data of post-processing

One presents the example of data for honeycomb calculation. Also examples of data for dynamic post-processing with “PostExtract” class are presented.

X.F.5.2.1 Static post-processing

The first operation consists in creating an instance object of class "PostCauchy":

require "post_Cauchy"
post_honeycomb=PostCauchy.new

Then, three instance methods are created. For example, the "calcAll" method definition looks as follows:

def post_honeycomb.calcAll(db,lcName,scName)
    list = ["pan_MX_Honey_50", "pan_MY_Honey_50", ...
end

One sees that the method is attached to the instance object created earlier, and not to its class.

The object also defines a "postCalc" method that defines several data and performs a call to writeGmshMinMosResults method:

def post_honeycomb.postCalc(db)
    skeleton=Group.new
    skeleton.setEntitiesByType("Element","Element 1:100000")
    skeleton.matchWithDbEntities(db)
    writeGmshMinMosResults(db,"OUT_STATICS/postSandwichHoney.gmsh",skeleton)
end

Note that object "post_skins" does not define the method "postCalc" and produces no Gmsh file.

In file “DATA/data_Post_TsaiHill.rb”, one defines the corresponding data for the calculation of Tsai-Hill criterion in panel -Z. Before doing a loop on the different load cases, one initializes the “@compDb” member data as follows:

def post_TsaiHill.preCalc(db)
    @compDb=db.getClaDb
end

At the end of the calculations, the envelopes of Results and the mesh are printed:

def post_TsaiHill.postCalc(db)
    skeleton=db.getGroupAllFEM()
    writeGmshMinMosResults(db,"OUT_STATIC/postTsaiHill.gmsh",skeleton)

    db.writeGmshMesh("OUT_STATIC/postTsaiHill.msh",0,skeleton)
end

X.F.5.2.2 Dynamic post-processing

A first instance of the “PostExtract” class is created. This instance is devoted to the printing of several nodal accelerations in Z direction. Basically, the method contains several calls to “calcOneGroup” method with the appropriate arguments that define the data:

def post_accel.calcAll(db,lcName,scName)
    resName="Accelerations (RI), translational"
    method="Nodes"
    csId=0
    component="Z"

    calcOneGroup(db,lcName,scName,"Accel_Node_500001", "Node 500001",
                     resName, method, csId, component)
    calcOneGroup(db,lcName,scName,"Accel_Node_20919", "Node 20919",
                     resName, method, csId, component)
    calcOneGroup(db,lcName,scName,"Accel_Node_20920", "Node 20920",
                     resName, method, csId, component)
    calcOneGroup(db,lcName,scName,"Accel_Node_40913", "Node 40913",
                     resName, method, csId, component)
    ...

A second instance of the method is used to output the launcher interface force recovered from the corresponding CBUSH element=

def post_cbush.calcAll(db,lcName,scName)
    resName="Beam Forces (RI)"
    method="Elements"
    csId=0
    component="XZ"

    calcOneGroup(db,lcName,scName,"Force_launcher", "Element 500003",
                     resName, method, csId, component)
end

Remember that the “calcAll” method is called for each load case or sub-case.

The final printing of values in “OUT_DYNAM” directory is called from “postCalc” method:

def post_accel.postCalc(db)
    gnuplot("post_accel.dat")
end

When the post-processing is finished, and if you have gnuplot on your computer, you can visualize the values by entering the “OUT_DYNAM” directory and typing:

    gnuplot < post_accel.dat
    gnuplot < post_cbush.dat

For example, the results obtained for the post-processing of CBUSH element forces are represented in Figure X.F.1 and X.F.2.


PICT

Figure X.F.1: Magnitude of launcher interface loads in direction Z for axial unit acceleration case.


PICT

Figure X.F.2: Phase of launcher interface loads in direction Z for axial unit acceleration case.

The data for the composite dynamic post-processing are defined in file
“DATA/data_Post_TsaiHillDynam.rb”. This file is very similar to the corresponding file for static post-processing. Only one selects 12 sub-divisions for the rotation angles.

X.F.6 Acceleration with predefined criterion

The “PostCauchy” class also defines two accelerated versions of the honeycomb and Von Mises criteria. These are defined by the “crit_HoneyAirbusAccel” and “crit_VonMisesAccel” methods of the class.

The data for the calculations of these versions of the criterion are defined in files “ DATA/data_Post_honeycomb2.rb” and “DATA/data_Post_skins2.rb”. The activation/deactivation of these calculations can be obtained by uncommenting or commenting the corresponding require statements in “testSat.rb” file:

     require "DATA/loadCases"
     require "DATA/data_Post_Interf"
     require "DATA/data_Post_honeycomb"
     #~ require "DATA/data_Post_honeycomb2"
     require "DATA/data_Post_skins"
     #~ require "DATA/data_Post_skins2"
     require "DATA/data_Post_TsaiHill"

X.F.7 Conclusions

We advise the use to play with the example and try to understand it. This post-processing program architecture is very flexible and should allow the developments of very sophisticated and powerful tools.

The example “dynam.rb” illustrating the post-processing of dynamic Complex Results is very preliminary and can be improved in several ways:

Appendix X.G
FeResPost ruby extension in excel

The description of FeResPost COM component in Part VI, and the corresponding examples in Part VII might suggest that the only way to use FeResPost in excel is to write VBA modules that use FeResPost COM component.

It is not true. One explains in this Appendix, how ruby can be embedded into excel, and how VBA calls may be marshaled to ruby interpreter. Then, the programming of post-processing can be done nearly entirely with ruby language and FeResPost ruby extension may be used instead of the COM component.

X.G.1 A VBA-ruby bridge

The technique we propose here makes use of excel/VBA capability to load dll libraries and of ruby language to be dynamically embedded into another application by loading the ruby interpreter dynamic library. A schematic representation of the process is given in Figure X.G.1:

In order to explain how the bridging works, one gives in section X.G.1.1 information about the programming of the bridge. In section X.G.2.1 one explains what is done in excel VBA modules to use the bridge and ruby programs.


PICTPICT

Figure X.G.1: Schematic representation of the connections existing between excel objects, VBA, VBA-ruby bridge, ruby and the external world inside excel memory.

X.G.1.1 Programming the VBA-ruby bridge

The sources are made of three C++ “cpp” files, three C++ header files and one “def” file that defines the four functions that will be exported into the dll library. More precisely:

One remarks that the bridge between VBA and ruby implicitly assumes that the ruby “win32ole” extension is present. (This extension is required in the “RubyInit” method.) It was not a priori mandatory. However, the early loading of “win32ole” extension helps the programming of the for COM automation types translations. As the manipulation of these types by ruby programs might be necessary, it is necessary to load the extension as early as possible. This means that the ruby distribution with which the bridge is used must contain the “win32ole” extension. (Of course, the bridge should be used only on Windows platforms on which Office is installed.)

The compilation of the library is straightforward. On my computer, it looks like this:

    g++ -O2 -IC:/NewProgs/RUBY/Ruby187/lib/ruby/1.8/i386-mingw32 \
        -c marshal.cpp
    g++ -O2 -IC:/NewProgs/RUBY/Ruby187/lib/ruby/1.8/i386-mingw32 \
        -c conversion.cpp
    g++ -O2 -IC:/NewProgs/RUBY/Ruby187/lib/ruby/1.8/i386-mingw32 \
        -c win32ole.cpp
    gcc -O2 -LC:/NewProgs/RUBY/Ruby187/bin \
        -fPIC -shared -static -m32 -Wl,--enable-auto-import \
        marshal.o conversion.o win32ole.o -lmsvcrt-ruby18 \
        -lws2_32 -luuid -lole32 -loleaut32 -lstdc++ -lm \
        marshal.def -o vbaruby.dll

Note that the “vbaruby.dll” is linked to the “msvcrt-ruby18.dll” dynamic library. This means that the ruby runtime library is automatically loaded into excel when “vbaruby.dll” is loaded. This also means that “msvcrt-ruby18.dll” must be located in a directory defined in the “PATH” environment variable. Also, the “vbaruby.dll” library is linked to a particular version of ruby runtime library. If another version of ruby is installed, the bridge may have to be re-compiled.

X.G.1.2 Requirements

One summarizes here the requirements to use the VBA-ruby bridge:

Note that the installation of FeResPost is not a requirement for the use of VBA-ruby bridge. Indeed the bridge is independent of FeResPost and can be used for any ruby post-processing.

X.G.2 An example

One presents in directory “TESTSAT/VBARUBYEX” an example that corresponds to the “PostProject.xlsm” example illustrating FeResPost COM component. (See section VII.4.) The programming of ruby modules is discussed in section X.G.2.1. Two VBA modules are defined in the excel workbook: “RubyMarshal” and “RubyFunctions”. These modules are discussed in section X.G.2.2 and section X.G.2.3 respectively. A few other points are discussed in section X.G.2.4.

X.G.2.1 Ruby programming

In this case, most of the VBA programming of post-processing operations has been replaced by corresponding code in “TESTSAT/VBARUBYEX/RUBY” directory. This code is loaded through the “main.rb” main file. This file looks as follows:

    $: << Dir.getwd+"/RUBY"
    $: << "D:/SHARED/FERESPOST/SRC/OUTPUTS/RUBY"
    $: << "D:/FERESPOST/BINARIES/FeResPost_4.0.10/RUBY"

    $stdout.reopen("main.log","w")
    $stdout.sync=true
    $stderr=$stdout

    require "dl"

    require "UTIL/util"
    require "UTIL/xls"

    require "POSTPROJECT/postProject"

One makes the following comments:

Note that the example we provide here depends on the availability of “FeResPost” and “sqlite3” ruby extensions. The example will not work on your computer if these two modules are not properly installed.

X.G.2.2 “RubyMarshal” VBA module

This VBA module performs the loading of dynamic libraries, and defines methods that can be called from anywhere in the VBA code and that dispatch the calls to corresponding ruby methods. The code begins as follows:

    Const vbaRubyLib As String = _
        "D:\SHARED\FERESPOST\SRC\OUTPUTS\VBARUBY\vbaruby.dll"
    ’
    Private Declare Function LoadLibrary Lib "kernel32" _
        Alias "LoadLibraryA" (ByVal lpLibFileName As String) As Long
    Private Declare Function FreeLibrary Lib "kernel32" _
        (ByVal hLibModule As Long) As Long
    ’
    Public Declare Function RubyInit _
        Lib "vbaruby" () As Long
    Public Declare Function RubyFinish _
        Lib "vbaruby" () As Long
    Public Declare Function RubyRequire _
        Lib "vbaruby" (ByVal param As Long) As Long
    Public Declare Function RubyLoad _
        Lib "vbaruby" (ByVal param As Long) As Long
    Public Declare Function RubyCallMethod _
        Lib "vbaruby" (ByVal objName As Long, _
            ByVal methodName As Long, ByVal args As Long, _
            ByVal ret As Long) As Long
    ’
    Private testLibrary As Long

In this library:

The VBA procedure “libInit” performs the loading of the bridge library and the require statement to ruby main file:

    Public Sub libInit()
        Dim rbFile As Variant
        If testLibrary = 0 Then
            testLibrary = LoadLibrary(vbaRubyLib)
            RubyInit
        End If
        rbFile = ThisWorkbook.Path + "\RUBY\main.rb"
        RubyRequire VarPtr(rbFile)
    End Sub

Note that the path to the main required ruby be file is defined in the subroutine. Other choices are possible. You can change the way of accessing the ruby programs according to your preferences.

The VBA function “CallMethod” calls the bridge method “RubyCallMethod”. Its three arguments are the receiver of the method call (the name of a volume or of a class), the name of the method, and a ParamArray VARIANT argument containing an optional number of arguments.

    Public Function CallMethod(obj As String, method As String, _
            ParamArray args() As Variant) As Variant
        Dim varObj As Variant, varMethod As Variant, _
            varArgs As Variant, ret As Variant
        Dim var As Variant
    ’
        varObj = obj
        varMethod = method
        varArgs = args
    ’
        RubyCallMethod VarPtr(varObj), VarPtr(varMethod), _
            VarPtr(varArgs), VarPtr(ret)
        CallMethod = ret
    End Function

Note that the arguments passed to the “RubyCallMethod” in bridge library are pointers to VARIANT objects. These pointers are obtained by calls to “VbaPtr” function. The last argument of call to “RubyCallMethod” is a pointer to “ret” VARIANT that shall contain the value returned by the called ruby method. Note that the creation of pointers to VARIANT arguments and the call to “RubyCallMethod” bridge function are the main things done by the function.

Note also that the solution one proposes allows to call methods defined in modules, or class methods. It is not possible to directly call methods on instances of a class.

A “CallMethodValue” method is also defined in “RubyMarshal” VBA module. This method is very similar to “CallMethod”. The difference is that each time a “Range” argument is found, it is replaced by an Array containing the correspond Cell values.

X.G.2.3 “RubyFunctions” VBA module

One defines in “RubyFunctions” VBA module functions and subroutines that can be called from other VBA modules, or directly used as formulas in spreadsheets. For example, the function “getParameter” returns a parameter calculated from the load case name, and the parameter name:

    Function getParameter(lcName As String, paramName As String)
        getParameter = CallMethodValue("PostProject::DbAndLoadCases", _
            "getParameter", lcName, paramName)
    End Function

The function “getShellVonMisesMax” calculates the maximum von Mises stress on a Group of shell elements:

    Function getShellVonMisesMax(lcName As String, method As String, _
            groupName As String, Optional gmshFileName As String = "", _
            Optional gmshResName As String = "") As Variant
        getShellVonMisesMax = CallMethodValue( _
            "PostProject::ExtractionCriteria", _
            "getShellVonMisesMax", lcName, method, groupName, _
            gmshFileName, gmshResName)
    End Function

Note that the ruby methods called from VBA may also correspond to subroutines, even though the distinction between subroutines and functions do not exist in ruby. Examples, of calls to subroutines can be found in the VBA code corresponding to “LcSelector” spreadsheet. For example, one presents below the code associated to the button “ReadDbAndLoadCases” in the spreadsheet:

    Public Sub ReadDbAndLoadCases_Click()
        On Error GoTo locError:
    ’
        Dim x As Variant
        x = CallMethod("PostProject::DbAndLoadCases", _
            "setWorkbook", ThisWorkbook)
        x = CallMethodValue("PostProject::DbAndLoadCases", _
            "readDbAndLoadCases", ActiveSheet.name, nbrReservedLines, _
                LcSelect)
        Exit Sub
    ’
    locError:
        MsgBox prompt:="Something wrong happened! check standard output file.", _
            Title:="ReadDbAndLoadCases_Click()"
        MsgBox prompt:=CurDir, Title:=CurDir()
    End Sub

X.G.2.4 Other tips

In the “ThisWorkbook” VBA code, two excel event subroutines are provided. When opening, the event “Workbook_Open” changes the excel execution directory to the directory containing the workbook, loads the vbaruby bridge library and initializes ruby by calling “libInit”, then calls the “PostProject::DbAndLoadCases::setWorkbook” method to initialize the corresponding variable of the ruby post-processing program:

    Sub Workbook_Open()
        ChDrive (Left(ActiveWorkbook.Path, 1))
        ChDir (ActiveWorkbook.Path)
        Application.Calculation = xlCalculationAutomatic
        Call libInit
        Dim x As Variant
        x = CallMethod("PostProject::DbAndLoadCases", "setWorkbook", ThisWorkbook)
 End Sub

This step is mandatory if one wants the “main.rb” file to be loaded correctly, because a path relative to the directory containing “PostProject.xlsm” is used in the “RubyMarshal” VBA module. (Sees section X.G.2.2.) It also ensures that the “main.log” file to which ruby standard output is redirected is located in the same directory as “PostProject.xlsm”. (See section X.G.2.1.)

When closing the excel workbook, the following method is called:

    Sub workbook_BeforeClose(cancel As Boolean)
        Application.Calculation = xlCalculationAutomatic
        Dim x As Variant
        x = CallMethodValue("PostProject", "clearModuleVariables")
   End Sub

This method is meant, among other things, to remove all references to excel automation objects, so that the closing of the application is cleanly done. Practically, it sometimes fail, so that you have to kill excel with the task manager. (If someone can explain me why...)

X.G.2.5 Things to do to match a particular configuration

In order to adapt the example to your configuration you must:

Appendix X.H
Bolt group redistribution of connection loads

Sometimes, the finite element model of part of a structure does not allow to obtain reliable estimates of connection loads. This is the case for example:

Then, bolt group re-distributions allow to produce smoother distribution of connection loads from an initial distribution produced by FEM solver.

We present here the equations that govern the redistribution of loads on a bolt group. The equations are inspired by similar equations developed in [eEL94] for the calculation of a solid motion.

X.H.1 Assumptions

We make several assumptions to simplify the developments that follow:

The calculation of bolt group center of gravity is made easier by the fact that connection translational stifnesses are scalar. If connection coordinates in the initial extraction Cartesian coordinate system are noted xji, center of gravity is calculated as follows:

xjCoG = i=1Nk T ix ji i=1NkT i .
(X.H.1)

Note that this simplification is possible only because connection translational stiffnesses are scalar (isotropy assumption). Once the center of gravity has been calculated, a new Cartesian coordinate system parallel to the initial one and with origin as center of gravity is defined. In this translated coordinate system, connection locations are simply calculated as:

xji = x ji- x jCoG
(X.H.2)

and all the following calculations will be done using these coordinates.

Note that the definition of a bolt group center of gravity is possible only because connection stiffnesses are scalar. Otherwsie, a different center of gravity would be calculated for each direction. Actually, it would be even worse that that: the deformation of the assembly in one direction could lead to a global force with a different direction. This means that no center of gravity could be calculated.

The total force and moment transmitted by an interface are calculated as follows:

F = i=1Nf FEMi,
(X.H.3)

M = i=1Nxi ×f FEMi + i=1Nm FEMi,
(X.H.4)

in which fFEMi and mFEMi are the connection loads extracted from FEM results before bolt group redistribution.

X.H.2 Group global stiffness

We have seen in section X.H.1 that the parts are assumed infinitely stiff compared to the conenctions. The only source of flexibility in the assembly is the flexibility of connections. Here, to fix the ideas, we consider that part “A” is fixed, and that only part “B” moves slightly. This means that only the motions of part “B” must be considered in the development of expressions leading to the estimation of group global stiffnesses.

As part “B” is rigid, its motion can be characterized by a vectorial translation T and a vectorial rotation Ω of components Tj and Ωj respectively. These components are expressed in bolt group center of gravity Cartesian coordinate system defined in section X.H.2. The motion of “B” side of connection i is then

Δxji = T j + ϵjklΩjxli,

in which we use the Bose-Einstein convention for the notation of components, except that no distinction is done between the covariant and contravariant types of components as coordinate system is a Cartesian one. Previous expression can also simply be written:

Δxi = T + Ω×xi.
(X.H.5)

This equation shows that the translational elongation of each connection depends on its location wrt bolt group center of gravity. On the other hand, all the rotational deformations are exactly equal to part “B” global rotation:

Δωi = Ω.
(X.H.6)

To these connection deformations correspond connection forces and moments:

fi = k T iΔxi = k T i (T + Ω×xi) .
(X.H.7)

mi = k RiΔωi = k RiΩ.
(X.H.8)

With these expressions for connection deformations, bolt group total strain energy can be developed as follows:

U = 1 2 i=1NΔxi fi + 1 2 i=1NΔωi mi, = 1 2 i=1Nk T i (Δxi) 2 + 1 2 i=1Nk Ri (Δωi) 2, = 1 2 i=1Nk T i [T + Ω×xi) (T + Ω×xi] + 1 2 i=1Nk RiΩ2, = 1 2 i=1Nk T i [TT + 2T (Ω×xi) + (Ω×xi) (Ω×xi)] + 1 2 i=1Nk RiΩ2, = 1 2 i=1Nk T iTT + i=1Nk T i (T×Ω)xi + 1 2 i=1Nk T i (Ω×xi) (Ω×xi) + 1 2 i=1Nk RiΩ2, = 1 2 i=1Nk T iTT + (T×Ω) i=1Nk T ixi + 1 2 i=1Nk T i (Ω×xi) (Ω×xi) + 1 2 i=1Nk RiΩ2, = 1 2 i=1Nk T iTT + 1 2 i=1Nk T i (Ω×xi) (Ω×xi) + 1 2 i=1Nk RiΩ2. (X.H.9)

In last expression, one term has been set to zero because i=1Nk T ixi = 0 (origin of coordinate system located at bolt group center of gravity). Finally, one develops this expression following similar development for the definition of interia tensor in chapter 32 of [eEL94]:

U = 1 2 i=1Nk T iTT + 1 2 i=1Nk T i (Ω×xi) (Ω×xi) + 1 2 i=1Nk RiΩ2, = 1 2 i=1Nk T iTT + 1 2 i=1Nk T i [Ω2 (xi xi) - (Ωxi) 2] + 1 2 i=1Nk RiΩ2, = 1 2 ( i=1Nk T i) T2 + 1 2Ω { i=1Nk T i [ (xi xi) δ-xixi]} Ω + 1 2 ( i=1Nk Ri) ΩδΩ. (X.H.10)

Last expression allows us to introduce one scalar and one tensorial quantities characterizing bolt group total stiffness:

kT BG = i=1Nk T i,
(X.H.11)

JBG = i=1Nk T i [ (xi xi) δ-xixi] + ( i=1Nk Ri) δ.
(X.H.12)

The scalar quantity corresponds to a interface global translational stiffness. The tensorial quantity is the interface total rotational stiffness. Using these expressions, the bolt group strain energy is given by

U = 1 2kT BGTT + 1 2ΩJBG Ω.

The strain energy is also given by:

U = 1 2FT + 1 2MΩ.

This allows to write an expression that relates the interface global force and moment to interface deformation:

( F M ) = ( kT BGδ 0 0 JBG ) ( T Ω ),

that can be inverted as follows:

( T Ω ) = ( 1 kTBGδ 0 0 1 JBG ) ( F M ).
(X.H.13)

We have assumed here that JBG can be inverted.

X.H.3 Distribution on a group of connections

The equations developed in section X.H.2 allow the definition of the different steps involved in bolt group redistribution of connection loads. We summarizes these steps below:

1.

Bolt group center of gravity is calculated using (X.H.1).

2.

This allows to calculate connection locations in a new coordinate system with origin on this center of gravity using expression (X.H.2)

3.

The bolt group global stiffnesses kT BG and JBG are calculated with expressions (X.H.11) and (X.H.12) respectively.

4.

The 6 × 6 compliance matrix in (X.H.13) can then be calculated. Let us remark that so far, the calculations do not depend on connection loads. This means that they can be performed only once before the actual post-processing of FEM results.

5.

For a given load case, connection loads fFEMi and mFEMi can be extracted from the soler result file.

6.

Bolt group global forces and moments are then calculated with (X.H.3) and (X.H.4).

7.

Expression (X.H.13) is used to calculated bolt group global translational and rotational deformation.

8.

Connection forces and moments are then calculated with expressions (X.H.7) and (X.H.8).

X.H.4 Final remarks

The values atributed to connection translational stiffness kT i can be an issue. Generally test results are not available. The estimation of connection stiffness via detailed FEM is a possibility, but this might prove very complicated and expensive. One notices however, that as far as the distributed loads are concerned, only the relative stiffnessesz of the different connections in an interface matter. This means that if all connections have common characteristics, the use of any common value kT i = k T for stiffnesses will lead to the same results. If bolt group involves several types of connections, the stiffnesses considered in the calculations should be estimated using reasonable assumptions. For example, one can consider a proportionality to bolt section area of the kind kT i = k T 0 (ΦiΦ 0) 2, in which Φi is the nominal diamter of connection i.

The bolt group equations that are developed in this Appendix consider connections that have translational and rotational stiffnesses. In many case, the rotational stiffness is not necessary to redistribute interface loads. Setting kRi = 0 will lead to a redistribution in which the connections of the interface are loaded with forces only (mi = 0). This approach works only when setting kRi = 0 does not lead to a singular matrix JBG. This will be the case when interface connections are not aligned along a straight line. Would the connections be distributed along a straight line, and the particular case of a group of two connections saisfies this condition, a rotational stiffness must be attributed to connections to allow a bolt group redistribution.

Then appears the issue of the rotational stiffness to be attributed to the connections. As test results are generally not available, we advice to put a rotational stiffness corresponding approximately to kRi 0.5 Φi k T i.

Appendix X.I
Copying FeResPost

X.I.1 Copyright

Copyright 2005-2024 Renaud Sizaire

This document is the User Manual of FeResPost.

FeResPost is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version.

FeResPost is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with FeResPost; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

X.I.2 GNU GENERAL PUBLIC LICENSE

GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007

Copyright © 2007 Free Software Foundation, Inc. http://fsf.org/

Everyone is permitted to copy and distribute verbatim copies of this

license document, but changing it is not allowed.

The GNU General Public License is a free, copyleft license for software and other kinds of works.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users’ freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.

Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.

The precise terms and conditions for copying, distribution and modification follow.

_______________________________________________________________________________________________________________________________________________________

TERMS AND CONDITIONS

0.

Definitions.

“This License” refers to version 3 of the GNU General Public License.

“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.

“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a work based on the Program.

To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.

1.

Source Code.

The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work’s System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

The Corresponding Source for a work in source code form is that same work.

2.

Basic Permissions.

All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.

Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.

3.

Protecting Users’ Legal Rights From Anti-Circumvention Law.

No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work’s users, your or third parties’ legal rights to forbid circumvention of technological measures.

4.

Conveying Verbatim Copies.

You may convey verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

5.

Conveying Modified Source Versions.

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

(a)

The work must carry prominent notices stating that you modified it, and giving a relevant date.

(b)

The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.

(c)

You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.

(d)

If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation’s users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

6.

Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

(a)

Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.

(b)

Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.

(c)

Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.

(d)

Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

(e)

Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.

A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.

7.

Additional Terms.

“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

(a)

Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or

(b)

Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or

(c)

Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or

(d)

Limiting the use for publicity purposes of names of licensors or authors of the material; or

(e)

Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or

(f)

Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

8.

Termination.

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.

9.

Acceptance Not Required for Having Copies.

You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.

10.

Automatic Licensing of Downstream Recipients.

Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.

An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party’s predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.

11.

Patents.

A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor’s “contributor version”.

A contributor’s “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.

Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.

If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient’s use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.

If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.

12.

No Surrender of Others’ Freedom.

If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.

13.

Use with the GNU Affero General Public License.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.

14.

Revised Versions of this License.

The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.

If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.

15.

Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16.

Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

17.

Interpretation of Sections 15 and 16.

If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.

END OF TERMS AND CONDITIONS

X.I.3 GNU LESSER GENERAL PUBLIC LICENSE

GNU LESSER GENERAL PUBLIC LICENSE

Version 3, 29 June 2007

Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.

0.

Additional Definitions.

As used herein, "this License" refers to version 3 of the GNU Lesser General Public License, and the "GNU GPL" refers to version 3 of the GNU General Public License.

"The Library" refers to a covered work governed by this License, other than an Application or a Combined Work as defined below.

An "Application" is any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library. Defining a subclass of a class defined by the Library is deemed a mode of using an interface provided by the Library.

A "Combined Work" is a work produced by combining or linking an Application with the Library. The particular version of the Library with which the Combined Work was made is also called the "Linked Version".

The "Minimal Corresponding Source" for a Combined Work means the Corresponding Source for the Combined Work, excluding any source code for portions of the Combined Work that, considered in isolation, are based on the Application, and not on the Linked Version.

The "Corresponding Application Code" for a Combined Work means the object code and/or source code for the Application, including any data and utility programs needed for reproducing the Combined Work from the Application, but excluding the System Libraries of the Combined Work.

1.

Exception to Section 3 of the GNU GPL.

You may convey a covered work under sections 3 and 4 of this License without being bound by section 3 of the GNU GPL.

2.

Conveying Modified Versions.

If you modify a copy of the Library, and, in your modifications, a facility refers to a function or data to be supplied by an Application that uses the facility (other than as an argument passed when the facility is invoked), then you may convey a copy of the modified version:

a)

under this License, provided that you make a good faith effort to ensure that, in the event an Application does not supply the function or data, the facility still operates, and performs whatever part of its purpose remains meaningful, or

b)

under the GNU GPL, with none of the additional permissions of this License applicable to that copy.

3.

Object Code Incorporating Material from Library Header Files.

The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

a)

Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License.

b)

Accompany the object code with a copy of the GNU GPL and this license document.

4.

Combined Works.

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following:

a)

Give prominent notice with each copy of the Combined Work that the Library is used in it and that the Library and its use are covered by this License.

b)

Accompany the Combined Work with a copy of the GNU GPL and this license document.

c)

For a Combined Work that displays copyright notices during execution, include the copyright notice for the Library among these notices, as well as a reference directing the user to the copies of the GNU GPL and this license document.

d)

Do one of the following:

1)

Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

2)

Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user’s computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

e)

Provide Installation Information, but only if you would otherwise be required to provide such information under section 6 of the GNU GPL, and only to the extent that such information is necessary to install and execute a modified version of the Combined Work produced by recombining or relinking the Application with a modified version of the Linked Version. (If you use option 4d0, the Installation Information must accompany the Minimal Corresponding Source and Corresponding Application Code. If you use option 4d1, you must provide the Installation Information in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.)

5.

Combined Libraries.

You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following:

a)

Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.

b)

Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.

6.

Revised Versions of the GNU Lesser General Public License.

The Free Software Foundation may publish revised and/or new versions of the GNU Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Library as you received it specifies that a certain numbered version of the GNU Lesser General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that published version or of any later version published by the Free Software Foundation. If the Library as you received it does not specify a version number of the GNU Lesser General Public License, you may choose any version of the GNU Lesser General Public License ever published by the Free Software Foundation.

If the Library as you received it specifies that a proxy can decide whether future versions of the GNU Lesser General Public License shall apply, that proxy’s public statement of acceptance of any version is permanent authorization for you to choose that version for the Library.

Appendix X.J
Summary of changes

Versions 1.*.*

Versions 1.0.*

Version 1.0.0

First issue of the library (2005/08/21). Creation of the manual.

Version 1.0.1

The new version of the library is issued 2005/08/28. A few bugs have been corrected:

Addition of new capabilities:

The modifications of the manual correspond to the modifications of the library and of the examples:

Version 1.0.2

The new version of the library is issued 2005/09/11.

The modifications of the manual correspond to the modifications of the library and of the examples:

Version 1.0.3

The new version of the library is issued 2005/11/06.

The modifications of the manual correspond to some of the modifications of the library, and a little more:

Version 1.0.4

The new version of the library is issued 2005/11/20.

The modifications of the manual correspond to some of the modifications of the library, and a little more:

Version 1.0.5

The new version of the library is issued 2005/12/02.

he modifications of the manual correspond to some of the modifications of the library, and a little more: an example, presented in section IV.2.4.5 illustrates the manipulation of coordinate systems.

Version 1.0.6

The new version of the library is issued 2006/01/02.

The modifications of the manual correspond to some of the modifications of the library, and a little more:

Version 1.0.7

The new version of the library is issued 2006/02/05.

The modifications of the manual correspond to some of the modifications of the library.

Version 1.0.8

The new version of the library is issued 2006/03/26.

The modifications of the manual correspond to some of the modifications of the library.

Versions 2.*.*

Versions 2.0.*

Version 2.0.0

The new version of the library is issued 2006/05/26.

The modifications of the manual correspond to some of the modifications of the library.

Versions 2.1.*

Version 2.1.0

The new version of the library is issued 2006/07/02.

The modifications of the manual correspond to some of the modifications of the library.

Versions 2.2.*

Version 2.2.0

The new version of the library is issued 2006/07/23.

The modifications of the manual correspond to some of the modifications of the library.

Versions 2.3.*

Version 2.3.0

The new version of the library is issued 2006/08/20.

The modifications of the manual correspond to some of the modifications of the library.

Versions 2.4.*

Version 2.4.0

The new version of the library is issued 2006/11/05.

The modifications of the manual correspond to some of the modifications of the library.

Versions 2.5.*

Version 2.5.0

The new version of the library is issued 2006/12/10.

The modifications of the manual correspond to some of the modifications of the library. Let us mention however:

Versions 2.6.*

Version 2.6.0

The new version of the library is issued 2006/12/18.

The modifications of the manual correspond to some of the modifications of the library. Let us mention however:

Versions 2.7.*

Version 2.7.0

The new version of the library is issued 2007/02/04.

The modifications of the manual correspond to some of the modifications of the library. Let us mention however:

Versions 2.8.*

Version 2.8.0

The new version of the library is issued 2007/02/18.

The modifications of the manual correspond to some of the modifications of the library.

Versions 2.9.*

Version 2.9.0

The new version of the library is issued 2007/04/15.

The modifications of the manual correspond to some of the modifications of the library.

Version 2.9.1

The new version of the library is issued 2007/05/01.

The modifications of the manual correspond to some of the modifications of the library (among other things the modifications of the thermo-elastic and hygrometric aspects of the CLA calculations). The theoretical Chapter has been deeply transformed.

Version 2.9.2

The new version of the library is issued 2007/05/06.

The modifications of the manual correspond to some of the modifications of the library.

Version 2.9.3

The new version of the library is issued 2007/05/13.

The modifications of the manual correspond to some of the modifications of the library.

Version 2.9.4

The new version of the library is issued 2007/05/20.

The modifications of the manual correspond to some of the modifications of the library.

Version 2.9.5

The new version of the library is issued 2007/07/01.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 2.9.6

The new version of the library is issued 2007/07/11.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 2.9.7

The new version of the library is issued 2007/07/29.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 2.9.8

The new version of the library is issued 2007/08/05.

The modifications of the manual correspond to some of the modifications of the library.

Version 2.9.9

The new version of the library is issued 2007/08/26.

The modifications of the manual correspond to some of the modifications of the library.

Version 2.9.10

The new version of the library is issued 2007/09/02.

The modifications of the manual correspond to some of the modifications of the library.

Version 2.9.11

The new version of the library is issued 2007/09/30.

The modifications of the manual correspond to some of the modifications of the library. A few examples illustrating the modification of CLA classes have been added. Several correction in CLA theory and classes descriptions.

Version 2.9.12

The new version of the library is issued 2007/10/07.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Versions 3.*.*

Versions 3.0.*

Version 3.0.0

The new version of the library is issued 2007/11/04.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 3.0.1

The new version of the library is issued 2008/01/01.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 3.0.2

The new version of the library is issued 2008/01/13.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 3.0.3

The new version of the library is issued 2008/01/20.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 3.0.4

The new version of the library is issued 2008/01/27.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 3.0.5

The new version of the library is issued 2008/02/03.

he modifications of the manual correspond to some of the modifications of the library.

Version 3.0.6

The new version of the library is issued 2008/02/10.

he modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 3.0.7

The new version of the library is issued 2008/02/24.

The modifications of the manual correspond to some of the modifications of the library.

Versions 3.1.*

Version 3.1.0

The new version of the library is issued 2008/03/30.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 3.1.1

The new version of the library is issued 2008/04/20.

The modifications of the manual correspond to some of the modifications of the library. Moreover:

Version 3.1.2

The new version of the library is issued 2008/04/27.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.1.3

The new version of the library is issued 2008/05/25.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.1.4

The new version of the library is issued 2008/06/08.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 3.1.5

The new version of the library is issued 2008/06/15.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.1.6

The new version of the library is issued 2008/07/06.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Versions 3.2.*

Version 3.2.0

The new version of the library is issued 2008/09/07.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.2.1

The new version of the library is issued 2008/10/06.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.2.2

The new version of the library is issued 2008/10/19.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Description of the “CLA in excel” example has been improved and the example modified.

Version 3.2.3

The new version of the library is issued 2008/10/26.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.2.4

The new version of the library is issued 2008/11/16.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. New examples illustrating the manipulation of Groups and the use of iterators with the COM component are given.

Version 3.2.5

The new version of the library is issued 2008/11/23.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.2.6

The new version of the library is issued 2008/12/07.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. The “CLA in excel” example has been modified to illustrate the use of new methods.

Version 3.2.7

The new version of the library is issued 2008/12/14.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Versions 3.3.*

Version 3.3.0

The new version of the library is issued 2009/01/04.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 3.3.1

The new version of the library is issued 2009/03/01.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 3.3.2

The new version of the library is issued 2009/03/08.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.3.3

The new version of the library is issued 2009/03/29.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Versions 3.4.*

Version 3.4.0

The new version of the library is issued 2009/05/24.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Moreover, excel examples using COM component have been improved. In particular, one added an example illustrating random access to XDB results. Also small ruby examples illustrating the use of random access have been added.

Version 3.4.1

The new version of the library is issued 2009/06/07.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.4.2

The new version of the library is issued 2009/06/21.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Moreover, a post-processing project in excel using COM component is presented. (See Chapter VII.4.)

Version 3.4.3

The new version of the library is issued 2009/07/12.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

The excel post-processing project has been improved.

Version 3.4.4

The new version of the library is issued 2009/08/02.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

The excel post-processing project has been improved and several corrections have been done in the manual.

Also the presentation of the examples has been improved. One separates the examples with FeResPost ruby extension on one side, and with FeResPost component on the other side. The excel examples are presented in separate chapters.

Versions 3.5.*

Version 3.5.0

The new version of the library is issued 2009/08/23.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Moreover:

Version 3.5.1

The new version of the library is issued 2009/11/08.

Version 3.5.2

The new version of the library is issued 2009/12/13.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Version 3.5.3

The new version of the library is issued 2010/01/03.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected.

Moreover:

Version 3.5.4

The new version of the library is issued 2010/01/24.

he modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 3.5.5

The new version of the library is issued 2010/01/31.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 3.5.6

The new version of the library is issued 2010/02/07.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 3.5.7

The new version of the library is issued 2010/02/21.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 3.5.8

The new version of the library is issued 2010/04/11.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 3.5.9

The new version of the library is issued 2010/05/02.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Versions 4.*.*

Versions 4.0.*

Version 4.0.0

The new version of the library is issued 2010/08/18.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 4.0.1

The new version of the library is issued 2010/10/17.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 4.0.2

The new version of the library is issued 2010/11/01.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 4.0.3

The new version of the library is issued 2010/11/14.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 4.0.4

The new version of the library is issued 2011/02/20.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 4.0.5

The new version of the library is issued 2011/03/13.

The modifications of the manual correspond to some of the modifications of the library and a few errors in the manual have been corrected. Moreover:

Version 4.0.6

The new version of the library is issued 2011/04/25.

Modification of the manual and examples:

Version 4.0.7

The new version of the library is issued 2011/06/05.

Modification of the manual and examples:

Version 4.0.8

The new version of the library is issued 2011/07/24.

Version 4.0.9

The new version of the library is issued 2011/09/18.

Version 4.0.10

The new version of the library is issued 2011/09/25.

Modification of the manual and examples:

Version 4.0.11

The new version of the library is issued 2011/11/06.

Modification of the manual and examples:

Version 4.0.12

The new version of the library is issued 2012/01/02.

Modification of the manual and examples:

Versions 4.1.*

Version 4.1.0

The new version of the library is issued 2012/02/26.

Modification of the manual and examples:

Version 4.1.1

The new version of the library is issued 2012/06/10.

Modification of the manual and examples:

Version 4.1.2

The new version of the library is issued 2012/06/17.

Version 4.1.3

The new version of the library is issued 2012/08/19.

Version 4.1.4

The new version of the library is issued 2012/11/04.

Version 4.1.5

The new version of the library is issued 2013/01/27.

Version 4.1.6

The new version of the library is issued 2013/02/17.

Version 4.1.7

The new version of the library is issued 2013/04/14.

Version 4.1.8

The new version of the library is issued 2013/05/19.

Version 4.1.9

The new version of the library is issued 2013/07/07.

Versions 4.2.*

Version 4.2.0

The new version of the library is issued 2013/08/04.

Version 4.2.1

The new version of the library is issued 2013/08/18.

Version 4.2.2

The new version of the library is issued 2013/09/22.

Version 4.2.3

The new version of the library is issued 2013/11/11.

Version 4.2.4

The new version of the library is issued 2014/01/04:

The examples are also modified:

Version 4.2.5

The new version of the library is issued 2014/02/02:

Version 4.2.6

The new version of the library is issued 2014/08/24:

Version 4.2.7

The new version of the library is issued 2015/01/01:

A few corrections in the User Manual.

Version 4.2.8

The new version of the library is issued 2015/01/18:

A few corrections in the User Manual.

Version 4.2.9

The new version of the library is issued 2015/04/06:

A few corrections in the User Manual.

Versions 4.3.*

Version 4.3.0

The new version of the library is issued 2015/04/19:

The major modification in this issue of FeResPost is that it is now distributed under the Lesser General Public License. Practically, this means that it is now allowed to distribute proprietary applications linked with the library. (See Appendix X.H.4 for more information.)

Version 4.3.1

The new version of the library is issued 2015/08/26:

Version 4.3.2

The new version of the library is issued 2015/11/22:

Version 4.3.3

The new version of the library is issued 2016/01/01:

A few corrections in the examples, and in the user manual.

Version 4.3.4

The new version of the library is issued 2016/03/06:

Some modifications on the manual and the distributed binaries:

Version 4.3.5

The new version of the library is issued 2016/06/05:

Version 4.3.6

The new version of the library is issued 2016/08/16:

Version 4.3.7

The new version of the library is issued 2016/11/01:

Version 4.3.8

The new version of the library is issued 2017/01/02:

Version 4.3.9

The new version of the library is issued 2017/03/19:

Version 4.3.10

The new version of the library is issued 2017/05/28:

Versions 4.4.*

Version 4.4.0

The new version of the library is issued 2017/08/27:

Version 4.4.1

The new version of the library is issued 2017/10/22:

Version 4.4.2

The new version of the library is issued 2018/01/01:

Version 4.4.3

The new version of the library is issued 2018/04/29:

Version 4.4.4

The new version of the library is issued 2018/08/05:

Versions 4.5.*

Version 4.5.0

The new version of the library is issued 2019/02/10:

Version 4.5.1

The new version of the library is issued 2019/03/02:

Version 4.5.2

The new version of the library is issued 2019/07/16:

Version 4.5.3

The new version of the library is issued 2020/01/01:

Version 4.5.4

The new version of the library is issued 2020/02/09:

Version 4.5.5

The new version of the library is issued 2020/03/15:

Version 4.5.6

The new version of the library is issued 2020/03/17:

Version 4.5.7

The new version of the library is issued 2020/07/27:

Version 4.5.8

The new version of the library is issued 2021/01/01. Modifications of the library:

Modification of the examples:

Versions 5.*.*

Versions 5.0.*

Version 5.0.0

The new version of the library is issued 2021/03/28. Modifications of the library:

Table X.J.1: FeResPost methods modifications that may correspond to a modification of users’ scripts.
Old Method New MethodComments
Methods in “Group” class
each_mpc each_rbe method is renamed
NbrMpcs NbrRbes method is renamed
Methods in “NastranDb” class
getNbrRbes NbrRbes Becomes an attribute “getter”
NbrMpcs New method
getMpcNodes getRbeNodes for rigid body elements
getMpcDependentNodes getRbeDependentNodes for rigid body elements
getMpcIndependentNodesgetRbeIndependentNodes for rigid body elements
getMpcNodes getMpcNodes for MPC/MPCADD cards
getMpcDependentNodes getMpcDependentNodes for MPC/MPCADD cards
getMpcIndependentNodesgetMpcIndependentNodes for MPC/MPCADD cards
fillCard fillCard RBE and MPC cards are distinguished
fillCards new method
each_mpcId New method
Methods in “SamcefDb” class
getNbrRbes NbrRbes Becomes an attribute “getter”

Version 5.0.1

The new version of the library is issued 2021/07/30. Modifications of the library:

Version 5.0.2

The new version of the library is issued 2022/01/01. Modifications of the library:

Version 5.0.3

The new version of the library is issued 2022/08/15. Modifications of the library:

Also a few corrections in User Manual.

Version 5.0.4

The new version of the library is issued 2023/01/01. Modifications of the library:

The ruby post-processing example is modified as follows:

Also a few corrections in User Manual.

Version 5.0.5

The new version of the library is issued 2023/04/10. Modifications of the library:

Version 5.0.6

The new version of the library is issued 2023/08/14. Modifications of the library:

Version 5.0.7

The new version of the library is issued 2024/01/01. Modifications of the library:

A few modifications in the ruby post-project:

Finally, the binaries are no longer compiled with the “static” option as it lead to problems in the management of C++ exceptions. The Windows libraries are compiled on two different computers with Windows 10 and Windows 11. corresponding archives are duffixed with “w10” and “w11” respectively. Let us hope that, provided you choose the appropriate archive, this will prevent dll compatibility issues when installed on your computer.

Version 5.0.8

The new version of the library is issued 2024/06/16. Modifications of the library:

Version 5.0.9

The new version of the library is issued 2024/08/24. Modifications of the library:

Several corrections have been done in the manual and a few examples illustrating new capabilities are presented. The description of ruby post-processing projects in chapter IV.4 has been improved:

Part XI
References

Bibliography

[eEL94]    L. Landau et E. Lifchitz. Physique Théorique, Volume 2 : Mécanique. Cinquième edition, 1994.

[Gay97]    Daniel Gay. Matériaux Composites. Hermès, 1997.

[Hex22]    Hexagon, editor. MSC Nastran 2022.4 Superelements and Modules User’s Guide. Hexagon, 2022.

[LL13]    L.D. Landau and E.M. Lifshitz. Statistical Physics: Volume 5. Number vol. 5. Elsevier Science, 2013.

[LLK+86]    L.D. Landau, E.M. Lifshitz, A.M. Kosevich, J.B. Sykes, L.P. Pitaevskii, and W.H. Reid. Theory of Elasticity: Volume 7. Course of Theoretical Physics. Elsevier Science, 1986.

[Nas05]    MSC.Access User’s Manual. MSC.Software Corporation, 2005.

[otNCE21]   Office of the NASA Chief Engineer. NASA-STD-5020-B, Requirements for the Threading Fastening Systems in Spaceflight Hardware. Nasa Technical Standard. NASA, 2021.

[Pal99]    Markku Palanterä, editor. Theoretical Background of ESAComp Analyses, Version 1.5. april 1999.

[Rey04]    Michael Reymond. MSC.Nastran 2005, DMAP Programmer’s Guide, volume 1. MSC.Software Corporation, 2004.

[Sof04a]    MSC Software, editor. MSC.Nastran 2004, Reference Manual. MSC.Software Corporation, 2004.

[Sof04b]    MSC Software, editor. MSC.Nastran 2005, Quick Reference Guide. MSC.Software Corporation, 2004.

[Sof10]    MSC Software, editor. MD/MSC. Nastran 2010, Dynamic Analysis User’s Guide. MSC.Software Corporation, 2010.




by Renaud Sizaire ;