FeResPost Manual

FeResPost
FeResPost User Manual

Version 4.5.1
2019/03/02
Renaud Sizaire
2
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:
• He has to take into account the possibility of modifications of the structure and of its
corresponding finite element model during the project.
• Also, the allowables may change during the course of the project.
• Sometimes, the calculation methods are imposed by a client or a methodology depart-

ment in the company, and these methods may also be modified, or be defined concur-
rently with the sizing activities.
• For long duration projects, the members of the calculation team are often displaced as the
work proceeds, and time is lost to transfer the information from one engineer to another.
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 auto-

mated post-processing. An example of such an object-oriented post-processing program
is given in Chapter IV.3.
3
4 INTRODUCTION
2. The FeResPost library is mainly written in C++, which is also an object-oriented lan-
guage. 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:
• As a ruby extension. Binaries are available for Windows and Linux distributions of ruby.
• As a Python copiled library on Windows and Linux.
• As a COM component on Windows. Then, the library can be used with different lan-
guages that support COM interface: C, C++, ruby, Python, VBA...
• As a .NET assembly that allows the programming with VB.NET, C++.NET, C#...
How to learn FeResPost?

One gives here some advice to people starting to use FeResPost. The order in which the knowl-
edge 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 lan-
guages 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.
INTRODUCTION 5
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 com-
plaints 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:
• In Part I one presents the various classes defined in FeResPost library, and their member
functions. One emphasizes the definition of the concepts to which they correspond, and
their relevance for the developments of post-processing tools.
• Part II is devoted to the presentation of the classes devoted to composite calculations with
the Classical Laminate Analysis Theory.
• Part III is devoted to the presentations of the preferences for the different solvers sup-
ported by FeResPost.
• In Part IV, several examples of post-processing written with the ruby library are pre-
sented.
• Part VI contains the description of FeResPost COM component. This Part is less detailed
as most methods in COM component have the same characteristics as the corresponding
methods in ruby extension.
• Examples of programs with the COM component are given in Part VII.
• Part VIII contains the description of FeResPost NET assembly. Here again, the descrip-
tion is shortet than for the ruby extension.
• Examples of programs with the NET assembly are given in Part IX.
• Part V contains the description of FeResPost Python library. Both the library and the
examples are described in that part which is vry short as the Python and ruby languages
are very similar.
• Part X contains the annexes.
• References are given in Part XI.
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.
6 INTRODUCTION
Table 1: Classes defined by FeResPost, and links to the corresponding lists of methods.
Class Chapter Table Page
“Common” Classes
DataBase I.1 I.1.1 32
CoordSys I.2 I.2.1 47
Group I.3 I.3.1 55
Result I.4 I.4.1 61
ResKeyList I.5 I.5.1 95
Post (module) I.6 I.6.1 99
Classical Laminate Analysis
ClaDb II.2 II.2.1 181
ClaMat II.3 II.3.1 187
ClaLam II.4 II.4.1 195
ClaLoad II.5 II.5.1 214
Solver Preferences
NastranDb III.1 III.1.1 225
SamcefDb III.2 III.2.1 271
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
Introduction 3
FeResPost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
How to learn FeResPost? . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Structure of the document . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Future developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Contents 7
Index 25
I FeResPost Reference Manual 27

I.0 Introduction 29
I.1 Generic “DataBase” class 31

I.1.1 Methods for FEM definition . . . . . . . . . . . . . . . . . . . . . . . . . 34
I.1.2 “Group” methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
I.1.2.1 Simple manipulation of Groups . . . . . . . . . . . . . . . . . 35
I.1.2.2 Construction of Groups by association operations . . . . . . . . 37
I.1.3 “Result” methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
I.1.3.1 Manipulation of Results . . . . . . . . . . . . . . . . . . . . . 38
I.1.3.2 Enabling composite Results reading operations . . . . . . . . . 40
I.1.4 Manipulation of abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 41
I.1.5 Composite methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
I.1.6 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
I.1.7 General purpose methods . . . . . . . . . . . . . . . . . . . . . . . . . . 44
I.1.8 “Gmsh” methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
I.2 The “CoordSys” class 47

I.2.1 The CoordSys object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
I.2.2 Construction or manipulation functions . . . . . . . . . . . . . . . . . . . 48
I.2.2.1 “initWith3Points” method . . . . . . . . . . . . . . . . . . . . 48
I.2.2.2 Three “initWithOViVj” methods . . . . . . . . . . . . . . . . . 49
I.2.2.3 “updateDefWrt0” method . . . . . . . . . . . . . . . . . . . . 50
I.2.3 Transformation of point coordinates . . . . . . . . . . . . . . . . . . . . . 50
I.2.3.1 “changeCoordsA20” method . . . . . . . . . . . . . . . . . . . 50
7
8 CONTENTS
I.2.3.2 “changeCoords02B” method . . . . . . . . . . . . . . . . . . . 50

I.2.3.3 “changeCoordsA2B” method . . . . . . . . . . . . . . . . . . . 51
I.2.4 Transformation of vector and tensor components . . . . . . . . . . . . . . 51
I.2.4.1 “changeCompsA20” method . . . . . . . . . . . . . . . . . . . 51
I.2.4.2 “changeComps02B” method . . . . . . . . . . . . . . . . . . . 52
I.2.4.3 “changeCompsA2B” method . . . . . . . . . . . . . . . . . . . 52
I.2.5 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
I.2.5.1 “initialize” method . . . . . . . . . . . . . . . . . . . . . . . . 53
I.2.5.2 “clone” method . . . . . . . . . . . . . . . . . . . . . . . . . . 53
I.2.5.3 “to_s” method . . . . . . . . . . . . . . . . . . . . . . . . . . 53
I.2.5.4 “Id” attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
I.3 The “Group” class 55

I.3.1 The concept of “Group” . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
I.3.2 Creation of a Group object . . . . . . . . . . . . . . . . . . . . . . . . . 56
I.3.3 Manipulation of entities stored in a Group . . . . . . . . . . . . . . . . . 56
I.3.4 Group operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
I.3.5 “BLOBs” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
I.3.6 Iterators of Group class . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
I.3.7 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
I.4 The “Result” class 61

I.4.1 The concept of “Result” . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
I.4.1.1 “Keys” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
I.4.1.2 “Values” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
I.4.1.3 Identification of Result objects . . . . . . . . . . . . . . . . . . 68
I.4.1.4 Other characteristics . . . . . . . . . . . . . . . . . . . . . . . 68
I.4.2 Extraction methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
I.4.2.1 “extractResultOnEntities” method . . . . . . . . . . . . . . . . 68
I.4.2.2 “extractResultOnLayers” method . . . . . . . . . . . . . . . . 69
I.4.2.3 “extractResultOnSubLayers” method . . . . . . . . . . . . . . 69
I.4.2.4 “extractResultOnRkl” method . . . . . . . . . . . . . . . . . . 70
I.4.2.5 “extractResultOnResultKeys” method . . . . . . . . . . . . . . 70
I.4.2.6 “extractResultOnRange” method . . . . . . . . . . . . . . . . . 70
I.4.2.7 “extractResultForNbrVals” method . . . . . . . . . . . . . . . 70
I.4.2.8 “extractResultMin” method . . . . . . . . . . . . . . . . . . . 71
I.4.2.9 “extractResultMax” method . . . . . . . . . . . . . . . . . . . 71
I.4.2.10 “extractRklOnRange” method . . . . . . . . . . . . . . . . . . 71
I.4.2.11 “extractRklForNbrVals” method . . . . . . . . . . . . . . . . . 71
I.4.2.12 “extractRklMin” method . . . . . . . . . . . . . . . . . . . . . 71
I.4.2.13 “extractRklMax” method . . . . . . . . . . . . . . . . . . . . . 71
I.4.2.14 “extractRkl” method . . . . . . . . . . . . . . . . . . . . . . . 72
I.4.2.15 “extractGroupOnRange” method . . . . . . . . . . . . . . . . . 72
I.4.2.16 “extractGroupForNbrVals” method . . . . . . . . . . . . . . . 72
I.4.2.17 “extractGroup” method . . . . . . . . . . . . . . . . . . . . . . 72
I.4.2.18 “extractLayers” method . . . . . . . . . . . . . . . . . . . . . 72
CONTENTS 9
I.4.2.19 “extractSubLayers” method . . . . . . . . . . . . . . . . . . . 72

I.4.3 Derivation monadic methods . . . . . . . . . . . . . . . . . . . . . . . . 72
I.4.3.1 “deriveScalToScal” method . . . . . . . . . . . . . . . . . . . 73
I.4.3.2 “deriveScalPerComponent” method . . . . . . . . . . . . . . . 74
I.4.3.3 “deriveVectorToOneScal” method . . . . . . . . . . . . . . . . 74
I.4.3.4 “deriveVectorToVector” method . . . . . . . . . . . . . . . . . 74
I.4.3.5 “deriveVectorToTensor” method . . . . . . . . . . . . . . . . . 75
I.4.3.6 “deriveTensorToOneScal” method . . . . . . . . . . . . . . . . 75
I.4.3.7 “deriveTensorToTwoScals” method . . . . . . . . . . . . . . . 76
I.4.3.8 “deriveTensorToThreeScals” method . . . . . . . . . . . . . . 76
I.4.3.9 “eigenQR” method . . . . . . . . . . . . . . . . . . . . . . . . 77
I.4.3.10 “deriveByRemapping” method . . . . . . . . . . . . . . . . . . 77
I.4.4 Dyadic derivation method . . . . . . . . . . . . . . . . . . . . . . . . . . 79
I.4.5 Methods modifying the object . . . . . . . . . . . . . . . . . . . . . . . . 80
I.4.5.1 Access to and modification of Result data . . . . . . . . . . . . 80
I.4.5.2 “setRefCoordSys” . . . . . . . . . . . . . . . . . . . . . . . . 82
I.4.5.3 “renumberLayers” . . . . . . . . . . . . . . . . . . . . . . . . 82
I.4.5.4 “renumberSubLayers” . . . . . . . . . . . . . . . . . . . . . . 82
I.4.5.5 “removeLayers” . . . . . . . . . . . . . . . . . . . . . . . . . 82
I.4.5.6 “removeSubLayers” . . . . . . . . . . . . . . . . . . . . . . . 83
I.4.5.7 “modifyRefCoordSys” . . . . . . . . . . . . . . . . . . . . . . 83
I.4.5.8 “modifyPositionRefCoordSys” method . . . . . . . . . . . . . 84
I.4.5.9 “setToCombili” . . . . . . . . . . . . . . . . . . . . . . . . . . 84
I.4.6 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
I.4.6.1 Addition operator . . . . . . . . . . . . . . . . . . . . . . . . . 85
I.4.6.2 Substraction operator . . . . . . . . . . . . . . . . . . . . . . . 86
I.4.6.3 Multiplication operator . . . . . . . . . . . . . . . . . . . . . . 86
I.4.6.4 Division operator . . . . . . . . . . . . . . . . . . . . . . . . . 86
I.4.6.5 Exponent operator . . . . . . . . . . . . . . . . . . . . . . . . 87
I.4.7 “calcResultingFM” method . . . . . . . . . . . . . . . . . . . . . . . . . 87
I.4.8 Complex Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
I.4.8.1 Rectangular-Polar conversions . . . . . . . . . . . . . . . . . . 88
I.4.8.2 Conjugate Complex Result . . . . . . . . . . . . . . . . . . . . 88
I.4.8.3 Rotation of Complex Result . . . . . . . . . . . . . . . . . . . 89
I.4.8.4 Extractions from Complex Results . . . . . . . . . . . . . . . . 89
I.4.8.5 Assembling Complex from Real Results . . . . . . . . . . . . . 89
I.4.9 “getData” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
I.4.10 “BLOBs” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
I.4.11 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
I.4.12 A few singleton (static) methods . . . . . . . . . . . . . . . . . . . . . . 92
I.4.13 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
I.4.13.1 “new” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
I.4.13.2 “initialize” . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
I.4.13.3 “clone” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
I.4.13.4 “cloneNoValues” . . . . . . . . . . . . . . . . . . . . . . . . . 93
I.4.13.5 “initZeroResult” . . . . . . . . . . . . . . . . . . . . . . . . . 93
10 CONTENTS
I.4.13.6 “Size” attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 93

I.4.13.7 “to_s” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
I.5 The “ResKeyList” class 95

I.5.1 Creating and filling ResKeyList object . . . . . . . . . . . . . . . . . . . 96
I.5.2 Extraction functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
I.5.3 Methods modifying the object . . . . . . . . . . . . . . . . . . . . . . . . 96
I.5.3.1 “renumberLayers” method . . . . . . . . . . . . . . . . . . . . 97
I.5.3.2 “renumberSubLayers” . . . . . . . . . . . . . . . . . . . . . . 97
I.5.3.3 “removeLayers” . . . . . . . . . . . . . . . . . . . . . . . . . 97
I.5.3.4 “removeSubLayers” . . . . . . . . . . . . . . . . . . . . . . . 97
I.5.4 Dyadic operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
I.5.5 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
I.5.6 “getData” method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
I.5.7 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
I.6 The “Post” module 99

I.6.1 Manipulation of FeResPost standard output . . . . . . . . . . . . . . . . . 100
I.6.2 Monadic functions for new Result creation . . . . . . . . . . . . . . . . . 101
I.6.3 Dyadic functions for new Result creation . . . . . . . . . . . . . . . . . . 101
I.6.4 “Operator” methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
I.6.5 Reading and writing of Groups . . . . . . . . . . . . . . . . . . . . . . . 103
I.6.6 Setting verbosity for debugging purposes . . . . . . . . . . . . . . . . . . 104
I.6.7 Conversion of CLA idfiers . . . . . . . . . . . . . . . . . . . . . . . . . . 104
I.6.8 SQL“BLOB” methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
I.6.9 Random or PSD integration methods . . . . . . . . . . . . . . . . . . . . 104
I.6.10 Predefined criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
I.6.11 Loading HDF5 library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
I.7 Arguments coercion for “Result” class operators 109
II Composite Reference Manual 111

II.0 Introduction 113
II.0.1 Remarks and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
II.1 Theoretical background 115

II.1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
II.1.2 Rotation in XY plane and algebraic notations . . . . . . . . . . . . . . . . 117
II.1.3 Materials and plies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
II.1.3.1 Plies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
II.1.3.2 Materials and constitutive equations . . . . . . . . . . . . . . . 121
II.1.3.3 In-plane properties . . . . . . . . . . . . . . . . . . . . . . . . 123
II.1.3.4 Out-of-plane shear properties . . . . . . . . . . . . . . . . . . 124
II.1.4 Thickness and mass of laminate . . . . . . . . . . . . . . . . . . . . . . . 125
II.1.5 In-plane and flexural laminate behavior . . . . . . . . . . . . . . . . . . . 126
CONTENTS 11
II.1.6 Out-of-plane shear of laminate . . . . . . . . . . . . . . . . . . . . . . . 128

II.1.6.1 Out-of-plane shear equilibrium equations . . . . . . . . . . . . 129
II.1.6.2 Triangular distribution of in-plane stresses . . . . . . . . . . . . 130
II.1.6.3 Out-of-plane shear stress partial derivative equations . . . . . . 131
II.1.6.4 Integration of out-of-plane shear stress equation . . . . . . . . . 134
II.1.6.5 Out-of-plane laminate shear stiffness . . . . . . . . . . . . . . 137
II.1.6.6 Calculation algorithm for shear stiffness . . . . . . . . . . . . . 139
II.1.7 CTE and CME calculations . . . . . . . . . . . . . . . . . . . . . . . . . 141
II.1.7.1 In-plane and flexural thermo-elastic behavior . . . . . . . . . . 141
II.1.7.2 Out-of-plane shear thermo-elastic behavior . . . . . . . . . . . 143
II.1.7.3 Hygrometric behavior of laminates . . . . . . . . . . . . . . . 144
II.1.7.4 Full sets of equations . . . . . . . . . . . . . . . . . . . . . . . 145
II.1.8 Calculation of load response . . . . . . . . . . . . . . . . . . . . . . . . . 146
II.1.8.1 In-plane and flexural response . . . . . . . . . . . . . . . . . . 146
II.1.8.2 Out-of-plane shear response . . . . . . . . . . . . . . . . . . . 149
II.1.8.3 Out-of-plane T/C deformation . . . . . . . . . . . . . . . . . . 150
II.1.9 Accelerating the calculation of load response . . . . . . . . . . . . . . . . 151
II.1.9.1 Calculation of laminate loads and strains . . . . . . . . . . . . 151
II.1.9.2 Calculation of plies stresses and strains . . . . . . . . . . . . . 154
II.1.10 Failure theories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
II.1.10.1 Tresca criterion (2D) . . . . . . . . . . . . . . . . . . . . . . . 160
II.1.10.2 Von Mises criterion (2D) . . . . . . . . . . . . . . . . . . . . . 160
II.1.10.3 Von Mises criterion (3D) . . . . . . . . . . . . . . . . . . . . . 161
II.1.10.4 Maximum stress criterion . . . . . . . . . . . . . . . . . . . . 161
II.1.10.5 Maximum stress criterion (3D) . . . . . . . . . . . . . . . . . . 161
II.1.10.6 Maximum strain criteria (2D) . . . . . . . . . . . . . . . . . . 162
II.1.10.7 Maximum strain criterion (3D) . . . . . . . . . . . . . . . . . . 162
II.1.10.8 Combined strain criterion (2D) . . . . . . . . . . . . . . . . . . 163
II.1.10.9 Tsai-Hill criterion . . . . . . . . . . . . . . . . . . . . . . . . . 163
II.1.10.10 Tsai-Hill criterion (version b) . . . . . . . . . . . . . . . . . . 164
II.1.10.11 Tsai-Hill criterion (version c) . . . . . . . . . . . . . . . . . . 164
II.1.10.12 Tsai-Hill criterion (3D) . . . . . . . . . . . . . . . . . . . . . . 164
II.1.10.13 Tsai-Hill criterion (3D version b) . . . . . . . . . . . . . . . . 165
II.1.10.14 Tsai-Wu criterion . . . . . . . . . . . . . . . . . . . . . . . . . 165
II.1.10.15 Tsai-Wu criterion (3D) . . . . . . . . . . . . . . . . . . . . . . 166
II.1.10.16 Hoffman criterion . . . . . . . . . . . . . . . . . . . . . . . . . 166
II.1.10.17 Puck criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
II.1.10.18 Hashin criteria . . . . . . . . . . . . . . . . . . . . . . . . . . 169
II.1.10.19 Hashin criteria (3D) . . . . . . . . . . . . . . . . . . . . . . . 170
II.1.10.20 Yamada-Sun criterion . . . . . . . . . . . . . . . . . . . . . . 171
II.1.10.21 Yamada-Sun criterion (version b) . . . . . . . . . . . . . . . . 171
II.1.10.22 3D honeycomb criterion . . . . . . . . . . . . . . . . . . . . . 172
II.1.10.23 Honeycomb shear criterion . . . . . . . . . . . . . . . . . . . . 172
II.1.10.24 Honeycomb simplified shear criterion . . . . . . . . . . . . . . 172
II.1.10.25 Inter-laminar shear criterion . . . . . . . . . . . . . . . . . . . 173
II.1.11 Temperature diffusion in laminates . . . . . . . . . . . . . . . . . . . . . 174
12 CONTENTS
II.1.11.1 Material thermal parameters . . . . . . . . . . . . . . . . . . . 174

II.1.11.2 In-plane and out-of-plane components . . . . . . . . . . . . . . 175
II.1.11.3 In-plane rotations of vectorial and tensorial properties . . . . . 175
II.1.11.4 Integration along the laminate thickness . . . . . . . . . . . . . 175
II.1.12 Moisture diffusion in laminates . . . . . . . . . . . . . . . . . . . . . . . 177
II.1.13 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
II.2 The “ClaDb” class 181

II.2.1 Creation of an object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
II.2.2 Identifying a ClaDb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
II.2.3 Manipulating entities stored in a ClaDb . . . . . . . . . . . . . . . . . . . 183
II.2.4 Management of Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
II.2.5 Saving to or retrieving from a disk file . . . . . . . . . . . . . . . . . . . 185
II.2.6 Saving or initializing with NDF lines . . . . . . . . . . . . . . . . . . . . 185
II.2.7 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
II.2.8 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
II.3 The “ClaMat” class 187

II.3.2 Identifier and type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
II.3.3 Manipulating Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
II.3.4 Calculated results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
II.3.7 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
II.4 The “ClaLam” class 195

II.4.1 Two Class Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
II.4.3 Identifying a laminate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
II.4.4 Manipulation of plies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
II.4.5 Other data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
II.4.6 Laminate properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
II.4.7 Laminate load response . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
II.4.7.1 Calculation of the load response . . . . . . . . . . . . . . . . . 203
II.4.7.2 Laminate internal loads and strains . . . . . . . . . . . . . . . . 204
II.4.7.3 Ply stresses and strains . . . . . . . . . . . . . . . . . . . . . . 205
II.4.7.4 Temperatures and moistures at ply level . . . . . . . . . . . . . 206
II.4.7.5 Other ply results . . . . . . . . . . . . . . . . . . . . . . . . . 207
II.4.8 Laminate finite element load response . . . . . . . . . . . . . . . . . . . 208
II.4.8.1 Calculation of laminate loads, stresses and strains . . . . . . . . 208
II.4.8.2 Acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
II.4.9 Calculation of criteria from FE stresses or strains . . . . . . . . . . . . . . 211
II.4.12 One iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
CONTENTS 13
II.4.13 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
II.5 The “ClaLoad” class 213

II.5.2 Identifying a ClaLoad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
II.5.3 Thermo-elastic and hygro-elastic contributions . . . . . . . . . . . . . . . 216
II.5.4 Setting and getting mechanical parts . . . . . . . . . . . . . . . . . . . . 217
II.5.5 Linear combinations of loads . . . . . . . . . . . . . . . . . . . . . . . . 217
II.5.6 Finite element Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
II.5.9 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
III Solver Preferences 221

III.0 Introduction 223
III.1 Nastran Preferences 225

III.1.1 “NastranDb” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
III.1.1.1 Reading a BDF . . . . . . . . . . . . . . . . . . . . . . . . . . 228
III.1.1.2 “OP2” methods for reading a FEM . . . . . . . . . . . . . . . . 231
III.1.1.3 Writing Bulk lines . . . . . . . . . . . . . . . . . . . . . . . . 232
III.1.1.4 Accessing FEM information or modifying the FEM . . . . . . . 235
III.1.1.5 “CoordSys” methods . . . . . . . . . . . . . . . . . . . . . . . 235
III.1.1.6 Construction of Groups by associations . . . . . . . . . . . . . 236
III.1.1.7 “OP2” methods for reading Results . . . . . . . . . . . . . . . 237
III.1.1.8 “XDB” methods for extracting XDB information . . . . . . . . 240
III.1.1.9 Attaching “XDB” files to a Nastran DataBase . . . . . . . . . . 245
III.1.1.10 Attaching “HDF” files to a Nastran DataBase . . . . . . . . . . 256
III.1.1.11 GMSH outputs . . . . . . . . . . . . . . . . . . . . . . . . . . 258
III.1.1.12 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
III.1.1.13 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . 259
III.1.2 Nastran Result characteristics . . . . . . . . . . . . . . . . . . . . . . . . 260
III.1.2.1 General Results . . . . . . . . . . . . . . . . . . . . . . . . . . 262
III.1.2.2 Composite Results . . . . . . . . . . . . . . . . . . . . . . . . 269
III.1.3 Interaction with CLA classes . . . . . . . . . . . . . . . . . . . . . . . . 270
III.2 Samcef Preferences 271

III.2.1 “SamcefDb” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
III.2.1.1 Reading Samcef models . . . . . . . . . . . . . . . . . . . . . 273
III.2.1.2 “CoordSys” methods . . . . . . . . . . . . . . . . . . . . . . . 274
III.2.1.3 Construction of Groups by association operations . . . . . . . . 275
III.2.1.4 Methods related to Results importation . . . . . . . . . . . . . 275
III.2.1.5 Attaching “DES/FAC” files to a Samcef DataBase . . . . . . . 278
III.2.1.6 GMSH outputs . . . . . . . . . . . . . . . . . . . . . . . . . . 283
III.2.1.7 Production of additional Results . . . . . . . . . . . . . . . . . 284
14 CONTENTS
III.2.1.8 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

III.2.1.9 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . 285
III.2.2 Samcef Results characteristics . . . . . . . . . . . . . . . . . . . . . . . . 285
III.2.2.1 General Results . . . . . . . . . . . . . . . . . . . . . . . . . . 285
III.2.2.2 Composite Results . . . . . . . . . . . . . . . . . . . . . . . . 288
III.2.3 Methods defined in “Post” module . . . . . . . . . . . . . . . . . . . . . 288
IV FeResPost Examples with RUBY Extension 293

IV.0 Introduction 295
IV.0.1 Accessing the ruby extension . . . . . . . . . . . . . . . . . . . . . . . . 296
IV.1 A small satellite 297

IV.1.1 Presentation of the structure and its modeling . . . . . . . . . . . . . . . . 297
IV.1.2 Satellite FEM materials and properties . . . . . . . . . . . . . . . . . . . 300
IV.1.3 Conventions for numbering and groups . . . . . . . . . . . . . . . . . . . 302
IV.1.4 Loads and Boundary conditions . . . . . . . . . . . . . . . . . . . . . . . 303
IV.1.4.1 Loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
IV.1.4.2 Boundary conditions . . . . . . . . . . . . . . . . . . . . . . . 304
IV.1.5 Main data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
IV.1.5.1 Acceleration unit loads on entire structure . . . . . . . . . . . . 305
IV.1.5.2 Acceleration unit loads on parts of the structure . . . . . . . . . 305
IV.1.5.3 Thermo-elastic load cases . . . . . . . . . . . . . . . . . . . . 305
IV.1.5.4 Other solution sequences . . . . . . . . . . . . . . . . . . . . . 306
IV.1.6 Organization of FEM in files and directories . . . . . . . . . . . . . . . . 306
IV.2 A few small examples 309

IV.2.1 Utilities Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
IV.2.2 Examples without Results . . . . . . . . . . . . . . . . . . . . . . . . . . 310
IV.2.2.1 Reading Bulk Data . . . . . . . . . . . . . . . . . . . . . . . . 310
IV.2.2.2 Group examples . . . . . . . . . . . . . . . . . . . . . . . . . 312
IV.2.2.3 Manipulating Group entities . . . . . . . . . . . . . . . . . . . 313
IV.2.2.4 Adding Groups to a DataBase . . . . . . . . . . . . . . . . . . 314
IV.2.3 Examples with iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
IV.2.4 Examples with Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
IV.2.4.1 Inspecting Results contained in a DataBase . . . . . . . . . . . 316
IV.2.4.2 Calculations with Results . . . . . . . . . . . . . . . . . . . . . 318
IV.2.4.3 Using predefined criteria . . . . . . . . . . . . . . . . . . . . . 320
IV.2.4.4 Printing Results’ content . . . . . . . . . . . . . . . . . . . . . 321
IV.2.4.5 Coordinate system transformations . . . . . . . . . . . . . . . . 323
IV.2.4.6 Manipulation of Complex Results . . . . . . . . . . . . . . . . 325
IV.2.4.7 Manipulation of XDB attachments . . . . . . . . . . . . . . . . 328
IV.2.5 A few useful tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
IV.2.5.1 Definition of acceleration fields . . . . . . . . . . . . . . . . . 332
IV.2.5.2 Definition of temperature fields . . . . . . . . . . . . . . . . . 337
CONTENTS 15
IV.2.5.3 Calculation of a total force and moment . . . . . . . . . . . . . 339

IV.2.5.4 Outputting a Gmsh file . . . . . . . . . . . . . . . . . . . . . . 341
IV.2.6 Saving and retrieving Results from an SQL database . . . . . . . . . . . . 342
IV.2.6.1 Saving objects in an SQLite database . . . . . . . . . . . . . . 342
IV.2.6.2 Retrieving objects from an SQLite database . . . . . . . . . . . 343
IV.2.7 Reading optimization results . . . . . . . . . . . . . . . . . . . . . . . . 344
IV.2.8 “Raw” access to XDB file content . . . . . . . . . . . . . . . . . . . . . . 345
IV.2.8.1 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
IV.2.8.2 Printing Coordinate System Table Matrix . . . . . . . . . . . . 346
IV.2.8.3 Accessing results . . . . . . . . . . . . . . . . . . . . . . . . . 346
IV.2.8.4 Producing a “clean” model from topometric optimization . . . . 348
IV.2.8.5 Reading and saving the temperature distributions . . . . . . . . 349
IV.2.9 Reading Results From HDF file . . . . . . . . . . . . . . . . . . . . . . . 350
IV.3 A modular post-processing 351

IV.3.1 Global structure of the program . . . . . . . . . . . . . . . . . . . . . . . 351
IV.3.1.1 The “LoadCases” module . . . . . . . . . . . . . . . . . . . . 351
IV.3.2 Two post-processing modules . . . . . . . . . . . . . . . . . . . . . . . . 354
IV.3.2.1 One using the connection loads . . . . . . . . . . . . . . . . . 354
IV.3.2.2 Critics on the previous post-processor . . . . . . . . . . . . . . 358
IV.3.2.3 One using the Cauchy stress tensor . . . . . . . . . . . . . . . 358
IV.3.3 Main function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
IV.3.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
IV.4 An object-oriented post-processing 363

IV.4.1 Difference in file organization . . . . . . . . . . . . . . . . . . . . . . . . 363
IV.4.2 Transformation of modules into classes . . . . . . . . . . . . . . . . . . . 363
IV.4.2.1 Post-processing of Cauchy stress tensor . . . . . . . . . . . . . 364
IV.4.2.2 A composite post-processing . . . . . . . . . . . . . . . . . . . 365
IV.4.3 A new post-processing for dynamic Results . . . . . . . . . . . . . . . . . 366
IV.4.3.1 Simple extraction of components . . . . . . . . . . . . . . . . . 366
IV.4.3.2 Post-processing of composite dynamic Results . . . . . . . . . 368
IV.4.4 Main function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
IV.4.5 Definition of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
IV.4.5.1 Data for load cases . . . . . . . . . . . . . . . . . . . . . . . . 370
IV.4.5.2 Data of post-processing . . . . . . . . . . . . . . . . . . . . . . 372
IV.4.6 Acceleration with predefined criterion . . . . . . . . . . . . . . . . . . . 375
IV.4.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
IV.5 Using the composite classes 377

IV.5.1 Importing and exporting data . . . . . . . . . . . . . . . . . . . . . . . . 377
IV.5.2 Manipulating composite entities . . . . . . . . . . . . . . . . . . . . . . . 378
IV.5.3 Composite thermal properties . . . . . . . . . . . . . . . . . . . . . . . . 379
IV.5.4 Extending composite classes . . . . . . . . . . . . . . . . . . . . . . . . 380
IV.5.4.1 Extension “extendedCLA.rb” . . . . . . . . . . . . . . . . . . 380
IV.5.4.2 A very simple example of use . . . . . . . . . . . . . . . . . . 385
16 CONTENTS
IV.5.4.3 Properties of the laminates defined in an ESAComp file . . . . . 385

IV.5.4.4 Properties of the laminates defined in an ESAComp file . . . . . 386
IV.5.4.5 Properties of the materials defined in an ESAComp file . . . . . 387
IV.5.5 Out-of-plane laminate shear response . . . . . . . . . . . . . . . . . . . . 387
IV.5.6 Producing composite finite element Results . . . . . . . . . . . . . . . . . 390
IV.5.7 Modifying units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
V FeResPost Python bindings 395

V.0 Introduction 397
V.0.1 Accessing the Python extension . . . . . . . . . . . . . . . . . . . . . . . 397
V.0.2 Python versus ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
V.0.2.1 Creating class instances . . . . . . . . . . . . . . . . . . . . . 398
V.0.2.2 Associative containers and Arrays . . . . . . . . . . . . . . . . 398
V.0.2.3 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
V.0.2.4 “nil” arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 399
V.1 Python examples 401

V.1.1 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
V.1.2 Accessing HDF and XDB results . . . . . . . . . . . . . . . . . . . . . . 401
V.1.3 SQLite examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
V.1.4 Object-oriented post-processing . . . . . . . . . . . . . . . . . . . . . . . 403
VI FeResPost as COM component 405

VI.0 Introduction 407
VI.0.1 Accessing the COM component . . . . . . . . . . . . . . . . . . . . . . . 408
VI.0.1.1 Accessing the COM component in ruby . . . . . . . . . . . . . 408
VI.0.1.2 Accessing the COM component in python . . . . . . . . . . . . 408
VI.0.1.3 Accessing the COM component in VBscript . . . . . . . . . . . 409
VI.0.1.4 Accessing the COM component in VBA . . . . . . . . . . . . . 409
VI.0.1.5 Accessing the COM component in compiled languages . . . . . 410
VI.0.2 COM component versus ruby extension . . . . . . . . . . . . . . . . . . . 410
VI.0.2.1 Creating class instances . . . . . . . . . . . . . . . . . . . . . 410
VI.0.2.2 Associative containers and Arrays . . . . . . . . . . . . . . . . 410
VI.0.2.3 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
VI.0.2.4 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
VI.0.2.5 Singleton methods . . . . . . . . . . . . . . . . . . . . . . . . 413
VI.0.2.6 “Clone” methods . . . . . . . . . . . . . . . . . . . . . . . . . 413
VI.0.2.7 “Post” Module . . . . . . . . . . . . . . . . . . . . . . . . . . 413
VI.0.2.8 Complex arguments . . . . . . . . . . . . . . . . . . . . . . . 413
VI.0.2.9 “nil” arguments . . . . . . . . . . . . . . . . . . . . . . . . . . 413
CONTENTS 17
VI.1 CLA classes 415

VI.1.1 “ClaDb” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
VI.1.2 “ClaMat” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
VI.1.3 “ClaLam” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
VI.1.4 “ClaLoad” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
VI.2 Generic FeResPost classes 417

VI.2.1 FeResPost Application class . . . . . . . . . . . . . . . . . . . . . . . . . 417
VI.2.1.1 Management of the Application . . . . . . . . . . . . . . . . . 417
VI.2.1.2 Creation of other objects . . . . . . . . . . . . . . . . . . . . . 417
VI.2.1.3 Methods corresponding to “Post” module in ruby extension . . 418
VI.2.1.4 Changing working directory . . . . . . . . . . . . . . . . . . . 418
VI.2.2 Generic DataBase class . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
VI.2.3 Group class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
VI.2.4 CoordSys class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
VI.2.5 Result class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
VI.2.6 ResKeyList class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
VI.3 Supported Solvers 421

VI.3.1 The “NastranDb” class . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
VI.3.2 The “SamcefDb” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
VII FeResPost Examples with COM Component 423

VII.1 COM examples with various languages 425
VII.1.1 Using COM component with several languages . . . . . . . . . . . . . . . 425
VII.1.1.1 Using component with python . . . . . . . . . . . . . . . . . . 425
VII.1.1.2 Using component with ruby . . . . . . . . . . . . . . . . . . . 428
VII.1.1.3 Using component with VBscript . . . . . . . . . . . . . . . . . 428
VII.1.1.4 Using component with C++ . . . . . . . . . . . . . . . . . . . 429
VII.1.1.5 Using component with C . . . . . . . . . . . . . . . . . . . . . 431
VII.1.2 Testing the “NastranDb” and “Group” classes . . . . . . . . . . . . . . . 431
VII.1.2.1 Using iterators and “NastranDb” class . . . . . . . . . . . . . . 431
VII.1.2.2 Writing elements connectivity . . . . . . . . . . . . . . . . . . 432
VII.1.2.3 Manipulation of Groups . . . . . . . . . . . . . . . . . . . . . 432
VII.1.3 Translating a few small “RUBY” Result examples . . . . . . . . . . . . . 432
VII.1.3.1 Printing DataBase lists of Results . . . . . . . . . . . . . . . . 432
VII.1.3.2 Printing maximum stress . . . . . . . . . . . . . . . . . . . . . 433
VII.1.3.3 Generating Nastran GRAV cards . . . . . . . . . . . . . . . . . 434
VII.1.3.4 Printing beam forces . . . . . . . . . . . . . . . . . . . . . . . 434
VII.1.3.5 Printing strain tensor . . . . . . . . . . . . . . . . . . . . . . . 434
VII.1.3.6 Modification of reference coordinate systems . . . . . . . . . . 434
VII.1.3.7 Calculation of global force and moment . . . . . . . . . . . . . 435
VII.1.3.8 Writing GMSH mesh and Results . . . . . . . . . . . . . . . . 435
VII.1.3.9 Manipulation of XDB Result files . . . . . . . . . . . . . . . . 435
18 CONTENTS
VII.1.4 Using component for CLA analyses . . . . . . . . . . . . . . . . . . . . . 435

VII.1.4.1 Laminate shear properties and load response . . . . . . . . . . 436
VII.1.4.2 Laminate load response with FE Results . . . . . . . . . . . . . 436
VII.1.4.3 Laminate failure criteria with FE stresses and strains . . . . . . 436
VII.1.5 Object-oriented post-processing . . . . . . . . . . . . . . . . . . . . . . . 437
VII.1.6 XDB attachment Results access with RUBY and COM . . . . . . . . . . 437
VII.1.7 Using COM component with excel . . . . . . . . . . . . . . . . . . . . . 437
VII.1.8 An Excel workbook illustrating the use of SQL databases . . . . . . . . . 437
VII.2 CLA analyses in excel 439

VII.2.1 Preparing the application . . . . . . . . . . . . . . . . . . . . . . . . . . 439
VII.2.2 Workbook events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
VII.2.3 Spreadsheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
VII.2.3.1 Spreadsheet “HiddenData” . . . . . . . . . . . . . . . . . . . . 440
VII.2.3.2 Spreadsheet “NeutralLines” . . . . . . . . . . . . . . . . . . . 440
VII.2.3.3 Spreadsheet “ClaDbIds” . . . . . . . . . . . . . . . . . . . . . 441
VII.2.3.4 Spreadsheet “DbUnitsEdit” . . . . . . . . . . . . . . . . . . . 442
VII.2.3.5 Spreadsheet “MatEdit” . . . . . . . . . . . . . . . . . . . . . . 443
VII.2.3.6 Spreadsheet “LamEdit” . . . . . . . . . . . . . . . . . . . . . . 443
VII.2.3.7 Spreadsheet “LoadEdit” . . . . . . . . . . . . . . . . . . . . . 444
VII.2.3.8 Spreadsheet “MatProperties” . . . . . . . . . . . . . . . . . . . 444
VII.2.3.9 Spreadsheet “LamProperties” . . . . . . . . . . . . . . . . . . 444
VII.2.3.10Spreadsheet “LamText” . . . . . . . . . . . . . . . . . . . . . 444
VII.2.3.11Spreadsheet “LamLoadResponse_A” . . . . . . . . . . . . . . 444
VII.2.3.12Spreadsheet “LamLoadResponse_B” . . . . . . . . . . . . . . 445
VII.2.3.13Spreadsheet “LamMinMaxCalcArray” . . . . . . . . . . . . . . 445
VII.2.3.14Spreadsheet “LamMinRfCalcScal” . . . . . . . . . . . . . . . 445
VII.2.4 VBA modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
VII.2.4.1 “calcMatProperties” module . . . . . . . . . . . . . . . . . . . 446
VII.2.4.2 “calcLamProperties” module . . . . . . . . . . . . . . . . . . . 446
VII.2.4.3 “calcLamLoadResponse” module . . . . . . . . . . . . . . . . 446
VII.3 Extraction and manipulation of Results with excel 447

VII.3.2 Accessing the FEM and Results . . . . . . . . . . . . . . . . . . . . . . . 448
VII.3.3 Accessing the FEM and Results . . . . . . . . . . . . . . . . . . . . . . . 449
VII.3.4 Simple extraction of Results . . . . . . . . . . . . . . . . . . . . . . . . . 449
VII.3.5 Extraction of linear combinations Results . . . . . . . . . . . . . . . . . . 451
VII.3.6 Calculation of criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
VII.3.7 Extraction of dynamic response Results . . . . . . . . . . . . . . . . . . . 452
VII.3.8 Current limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
VII.4 An Excel workbook devoted to post-processing 455

VII.4.1.1 “Optimizing” excel . . . . . . . . . . . . . . . . . . . . . . . . 455
VII.4.1.2 Referencing FeResPost in VBA . . . . . . . . . . . . . . . . . 455
CONTENTS 19
VII.4.1.3 Installing “SQLite for Excel” . . . . . . . . . . . . . . . . . . . 456

VII.4.2 Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
VII.4.2.1 “LcSelector” worksheet . . . . . . . . . . . . . . . . . . . . . 457
VII.4.2.2 Worksheet for Definition of databases and load cases . . . . . . 458
VII.4.2.3 Worksheet for Selection of load cases and associated parameters 460
VII.4.2.4 Post-processing worksheets . . . . . . . . . . . . . . . . . . . 461
VII.4.2.5 “envelopeGMSH” worksheet . . . . . . . . . . . . . . . . . . . 461
VII.4.3 VBA modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
VII.4.3.1 “DbAndLoadCases” VBA module . . . . . . . . . . . . . . . . 462
VII.4.3.2 “ExtractionCriteria” VBA module . . . . . . . . . . . . . . . . 462
VII.4.3.3 “ResultsExtraction” VBA module . . . . . . . . . . . . . . . . 463
VII.4.3.4 “ResultsArchiver” VBA module . . . . . . . . . . . . . . . . . 463
VII.4.3.5 “ResultsGmsh” VBA module . . . . . . . . . . . . . . . . . . 464
VII.4.3.6 “Sqlite3” VBA module . . . . . . . . . . . . . . . . . . . . . . 465
VII.4.3.7 “UTIL” VBA module . . . . . . . . . . . . . . . . . . . . . . . 465
VII.4.4 “ExtractionCriteria” VBA module . . . . . . . . . . . . . . . . . . . . . . 465
VII.4.4.1 Post-processing of stress Results . . . . . . . . . . . . . . . . . 466
VII.4.4.2 Post-processing of connection loads . . . . . . . . . . . . . . . 469
VII.4.4.3 composite post-processing . . . . . . . . . . . . . . . . . . . . 475
VIII FeResPost as .NET assembly 477

VIII.0Introduction 479
VIII.0.1.NET assembly versus ruby extension . . . . . . . . . . . . . . . . . . . . 480
VIII.0.1.1 Accessing the .NET assembly . . . . . . . . . . . . . . . . . . 480
VIII.0.1.2 Accessing FeResPost namespace . . . . . . . . . . . . . . . . . 480
VIII.0.1.3 Creating class instances . . . . . . . . . . . . . . . . . . . . . 481
VIII.0.1.4 Basic types as arguments and returned values . . . . . . . . . . 481
VIII.0.1.5 Associative containers and Arrays . . . . . . . . . . . . . . . . 481
VIII.0.1.6 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
VIII.0.1.7 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
VIII.0.1.8 Singleton methods . . . . . . . . . . . . . . . . . . . . . . . . 483
VIII.0.1.9 “Clone” and “ToString” methods . . . . . . . . . . . . . . . . . 483
VIII.0.1.10“Post” static class . . . . . . . . . . . . . . . . . . . . . . . . . 483
VIII.0.1.11Complex arguments . . . . . . . . . . . . . . . . . . . . . . . 483
VIII.1CLA classes 485

VIII.1.1“ClaDb” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
VIII.1.2“ClaMat” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
VIII.1.3“ClaLam” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
VIII.1.4“ClaLoad” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
VIII.2Generic FeResPost classes 487

VIII.2.1“Post” static class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
VIII.2.2Generic DataBase class . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
20 CONTENTS
VIII.2.3Group class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

VIII.2.4CoordSys class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
VIII.2.5Result class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
VIII.2.6ResKeyList class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
VIII.3Supported Solvers 491

VIII.3.1The “NastranDb” class . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
VIII.3.2The “SamcefDb” class . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
IX FeResPost Examples with .NET Assembly 493

IX.1 Examples of use for .NET assembly 495
IX.1.1 Reading a Nastran model . . . . . . . . . . . . . . . . . . . . . . . . . . 495
IX.1.1.1 Reading a Nastran model with C# . . . . . . . . . . . . . . . . 495
IX.1.1.2 Reading a Nastran model with IronRuby . . . . . . . . . . . . . 496
IX.1.2 “printStressMax” example . . . . . . . . . . . . . . . . . . . . . . . . . . 497
IX.1.3 Accessing FEM data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
IX.1.4 Extending CLA classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
IX.1.5 Saving and retrieving Results from an SQL database . . . . . . . . . . . . 499
X Appendices 501
X.A Installing FeResPost library 503
X.A.1 Binaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
X.A.1.1 Linux binaries (32 bits) . . . . . . . . . . . . . . . . . . . . . . 503
X.A.1.2 Linux binaries (64 bits) . . . . . . . . . . . . . . . . . . . . . . 504
X.A.1.3 Windows binaries (32 bits) . . . . . . . . . . . . . . . . . . . . 504
X.A.1.4 Windows binaries (64 bits) . . . . . . . . . . . . . . . . . . . . 505
X.A.1.5 Windows .NET assemblies . . . . . . . . . . . . . . . . . . . . 506
X.A.1.6 HDF shared libraries . . . . . . . . . . . . . . . . . . . . . . . 506
X.A.2 Building from sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
X.A.3 Installation and configuration of binaries . . . . . . . . . . . . . . . . . . 509
X.A.3.1 Redistributable libraries . . . . . . . . . . . . . . . . . . . . . 510
X.A.3.2 FeResPost C++ developer’s library and headers . . . . . . . . . 510
X.A.3.3 Ruby extensions . . . . . . . . . . . . . . . . . . . . . . . . . 511
X.A.3.4 Python extensions . . . . . . . . . . . . . . . . . . . . . . . . 511
X.A.3.5 COM component . . . . . . . . . . . . . . . . . . . . . . . . . 511
X.A.3.6 .NET assembly . . . . . . . . . . . . . . . . . . . . . . . . . . 514
X.B Coordinate system transformations 515

X.B.1 Components of vectors and tensors . . . . . . . . . . . . . . . . . . . . . 515
X.B.1.1 Vectors in a Cartesian coordinate system . . . . . . . . . . . . . 515
X.B.1.2 Order 2 tensor in a Cartesian coordinate system . . . . . . . . . 515
X.B.1.3 Cylindrical and spherical coordinate systems . . . . . . . . . . 516
X.B.2 Transformation of components . . . . . . . . . . . . . . . . . . . . . . . 516
CONTENTS 21
X.B.2.1 Transformation of vector components . . . . . . . . . . . . . . 517

X.B.2.2 Transformation of tensor components . . . . . . . . . . . . . . 518
X.B.3 Rotation of a coordinate system . . . . . . . . . . . . . . . . . . . . . . . 518
X.B.4 Modification of coordinate systems . . . . . . . . . . . . . . . . . . . . . 519
X.B.4.1 Local coordinate systems . . . . . . . . . . . . . . . . . . . . . 519
X.B.4.2 Global coordinate systems . . . . . . . . . . . . . . . . . . . . 520
X.B.4.3 Projected coordinate systems . . . . . . . . . . . . . . . . . . . 520
X.B.4.4 Local coordinate systems of CQUAD4 elements . . . . . . . . 521
X.B.4.5 Local coordinate systems of 3D elements . . . . . . . . . . . . 522
X.B.5 Coordinate systems and laminate properties . . . . . . . . . . . . . . . . 524
X.C Results characteristics 525

X.C.1 Real Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
X.C.2 Complex Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
X.D Predefined criteria 537

X.D.1 List of the predefined criteria . . . . . . . . . . . . . . . . . . . . . . . . 537
X.D.1.1 “HoneycombAirbusMoS” criterion . . . . . . . . . . . . . . . 537
X.D.1.2 “HoneycombAirbusSR” criterion . . . . . . . . . . . . . . . . 538
X.D.1.3 “VonMisesMoS” criterion . . . . . . . . . . . . . . . . . . . . 539
X.D.1.4 “VonMisesSR” criterion . . . . . . . . . . . . . . . . . . . . . 541
X.D.1.5 “SGI_SR” criterion . . . . . . . . . . . . . . . . . . . . . . . . 541
X.D.2 User predefined criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
X.E FeResPost ruby extension in excel 547

X.E.1 A VBA-ruby bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
X.E.1.1 Programming the VBA-ruby bridge . . . . . . . . . . . . . . . 547
X.E.1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
X.E.2 An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
X.E.2.1 Ruby programming . . . . . . . . . . . . . . . . . . . . . . . . 550
X.E.2.2 “RubyMarshal” VBA module . . . . . . . . . . . . . . . . . . 551
X.E.2.3 “RubyFunctions” VBA module . . . . . . . . . . . . . . . . . 552
X.E.2.4 Other tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553
X.E.2.5 Things to do to match a particular configuration . . . . . . . . . 554
X.F Copying FeResPost 555

X.F.1 Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
X.F.2 GNU GENERAL PUBLIC LICENSE . . . . . . . . . . . . . . . . . . . 555
X.F.3 GNU LESSER ENERAL PUBLIC LICENSE . . . . . . . . . . . . . . . 566
X.G Summary of changes 571

Version 1.0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Version 1.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Version 1.0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Version 1.0.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Version 1.0.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Version 1.0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
22 CONTENTS
Version 1.0.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573

Version 1.0.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Version 1.0.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Version 2.0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Version 2.1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Version 2.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Version 2.3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Version 2.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Version 2.5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Version 2.6.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Version 2.7.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Version 2.8.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Version 2.9.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Version 2.9.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Version 2.9.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Version 2.9.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Version 2.9.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
Version 2.9.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Version 2.9.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
Version 2.9.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Version 2.9.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Version 2.9.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Version 2.9.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Version 2.9.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Version 2.9.12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Version 3.0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Version 3.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Version 3.0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Version 3.0.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Version 3.0.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Version 3.0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
Version 3.0.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Version 3.0.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Version 3.1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Version 3.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Version 3.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Version 3.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Version 3.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
Version 3.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Version 3.1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Version 3.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Version 3.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Version 3.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Version 3.2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Version 3.2.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Version 3.2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
CONTENTS 23
Version 3.2.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

Version 3.2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Version 3.3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Version 3.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Version 3.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Version 3.3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
Version 3.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Version 3.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Version 3.4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Version 3.4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Version 3.4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Version 3.5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Version 3.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Version 3.5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Version 3.5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Version 3.5.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Version 3.5.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Version 3.5.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Version 3.5.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Version 3.5.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Version 3.5.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Version 4.0.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Version 4.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Version 4.0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Version 4.0.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Version 4.0.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Version 4.0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Version 4.0.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Version 4.0.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Version 4.0.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
Version 4.0.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Version 4.0.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Version 4.0.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
Version 4.0.12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Version 4.1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Version 4.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Version 4.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Version 4.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Version 4.1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Version 4.1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Version 4.1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Version 4.1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Version 4.1.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Version 4.1.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Version 4.2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Version 4.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
24 CONTENTS
Version 4.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611

Version 4.2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Version 4.2.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Version 4.2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Version 4.2.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Version 4.2.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Version 4.2.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Version 4.2.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Version 4.3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Version 4.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Version 4.3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Version 4.3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Version 4.3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Version 4.3.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Version 4.3.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Version 4.3.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Version 4.3.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Version 4.3.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Version 4.3.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Version 4.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Version 4.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Version 4.4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Version 4.4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Version 4.4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Version 4.5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Version 4.5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
XI References 625
Bibliography 627
Index
.NET 478–491, 494–500 DataBase, key 37

des 275–283
Abaqus 6 disable 239, 245, 277–278
abbreviations 41, 274 dynam 277
Acceleration of computation 107–108,
320–321, 375, 537–545 EDS 238
asef 276 enable 239, 245, 277–278
endiannes 244–246
Bacon 273, 459 EQEXINE 254
bacon 274 EQEXING 254
banque 273–274 Equivalent Strain 123, 149, 162, 163
BBBT see Binary Blocked Balanced Tree, see ESAComp 113, 185
Binary Blocked Balanced Tree excel 409, 437–453, 455–476, 547–554
big endian 244–246
Binary Blocked Balanced Tree 240 fac 275–283
BLOB 59, 91, 104, 342–344, 402, 437–438, FEM 237
456, 461–462, 464–465, 499–500 FeResPost 29
bridge 547–554 Fick 177
finite elements 29
C 431
Fourrier 174
C++ 56, 61, 64, 429–431
CLA 415–416, 485–486 General Public License 555–569
ClaDb 113, 181–186, 415, 485 Gmsh 44–46, 341–342, 456–459, 461–462,
ClaLam 113, 195–212, 416, 486 464–465, 539
ClaLoad 113, 213–219, 416, 486 GNU 506
ClaMat 113, 187–193, 415–416, 485–486 GPL 555–569
Classical Laminate Analysis 415–416, Group 29, 31, 35–37, 55–59, 72, 99, 236–237,
485–486 275, 312–316
code 286, 287, 289, 290
COM 406–421, 424–476, 547 Hash Key 240
Combined strain criterion 163 Hashin criteria 169–171
Complex, Complex 88–90 HD5 108, 350, 401–402
Component Object Model 406–421, 424–476 HDF 108, 256–258, 350, 401–402, 506
Composite 42–43, 112–219 HK see Hash Key, see Hash Key
CoordSys 29, 47–53, 235–236, 274–275, 325 Hoffman criterion 166–167
COPYING 555–569 Honeycomb criterion 172–173
DataBase 29, 31–46, 83, 84 I-DEAS 238

DataBase, flags, readDesFac 277 identifier 113
DataBase, flags, readDesFac 277 IDispatch 410, 431
25
26 INDEX
Ilss criterion 173 Result, Complex 88–90

Ilss_b criterion 173 Result, key 64–65, 68, 71, 84, 90–92, 95, 98,
include 230 318
instance method 372, 403 Result, layer 64–65
iterator 43–44, 59, 91–92, 97–98, 259, 284 Result, value 37, 64–67, 71, 90–92
iterators 316 Results 525–533
results 29
key see DataBase, key, see Result, key rfalter 230
rfinclude 230
lambda 403
RMSINT 106
layer see Result, layer
ruby 29, 61, 428
Lesser General Public License 555–569
LGPL 555–569 Samcef 41, 262, 271–291, 447, 453, 456,
little endian 244–246 458–460
scalar 67, 70, 71, 73–76, 78, 83, 84, 86, 87, 90
Makefile 506
SQL 59, 91, 104, 342–344, 402, 437–438,
Maximum strain criterion 162–163
456, 461–462, 464–465, 499–500
Maximum stress criterion 161–162
SQLite 342–344, 402, 437–438, 456,
mecano 276
461–462, 464–465, 499–500
Mechanical Strain 123, 149, 162, 163
stabi 277
Microsoft 410, 431
Strength Ratio 158
MINGW 506
Mohr 75, 76 tensorial 67, 75–78, 83, 84, 90
MSYS 506 Tresca criterion 160
Tsai-Hill criterion 163–165
Nastran 177, 225–270, 295 Tsai-Wu criterion 165–166
NET 478–491, 494–500 tuple 398, 402
op2 237–239, 260–270 Unigraphics 238
Patran 29, 35, 36, 55, 57, 87, 269, 302 value see Result, value
Post 29, 73, 80, 99–108 VBA 409, 437–453, 455–476, 547–554
post-processing 29 VBA-Ruby bridge 547–554
Predefined criterion 107–108, 320–321, 375, VBscript 428
537–545 vectorial 67, 74, 75, 78, 83, 84, 90
proc 370, 403 Von Mises 75, 76
PSD 104–107, 331–332 Von Mises criterion 160–161
Puck criteria 167–168
Python 396–403 xdb 240–256, 260–270, 401–402
python 425–427
Yamada-Sun criterion 171
random 104–107
random access 245–256, 278–283
Reserve Factor 158
ResKeyList 29, 65, 68, 70, 71, 95–98
Result 29, 31, 32, 37–41, 61–93,
95, 99, 101, 108, 240–258, 260–270,
278–283, 316–332
Part I
FeResPost Reference Manual
27
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:
• The “DataBase” class corresponds to the Patran concept of dataBase. It is used to store
the finite element model definition, the results, the groups,... It also allows to perform
operations on the corresponding objects. This class is presented in Chapter I.1.
• The “CoordSys” class allows the definition and manipulation of coordinate systems. This
class is very practical for some manipulation of Results. It is presented in Chapter I.2.
• The “Group” class corresponds to the Patran “group”. This class is presented in Chap-
ter I.3.
• The “Result” class is used to retrieve, store, transform finite element results. This class
is presented in Chapter I.4.
• The “ResKeyList” class is very useful to define lists of entities on which results are to
be retrieved. This class is presented in Chapter I.5. Actually, this class is still under
construction. However, the ResKeyList objects are already used for the manipulation of
Results (section I.4.2).
Finally, additional functions, not member of any class are defined in a module called “Post”.
29
30 INTRODUCTION
Chapter I.1
Generic “DataBase” class
Basically, a “DataBase” class is a container used to store a finite element model, Groups, Re-
sults, 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.
DataBase
Solver_1 ... Solver_n
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:
• All methods related to the definition of the model stored in the DataBase are defined in
the specialized classes.
• All methods related to the reading of Results from solvers output files are defined in the
specialized classes.
• Most methods for the manipulation of Groups and of Results are defined in the generic
“DataBase” class.
Throughout the Chapter one specifies for the different methods, in which class they are defined.
This Chapter is divided in several sections:
• One presents in section I.1.1 the methods devoted to the initialization of the finite element
model in the DataBase.
• Section I.1.2 is devoted to the DataBase’s methods devoted to the manipulation of Groups.
31
32 CHAPTER I.1. GENERIC “DATABASE” CLASS
• Section I.1.3 is devoted to the DataBase’s methods devoted to the manipulation of Re-
sults.
• In section I.1.4, the manipulation of abbreviations stored in the DataBase is described.
• The interaction of CLA classes with DataBase classes is discussed in section I.1.5.
• The iterators of Class DataBase are described in section I.1.6.
• Finally, general purpose methods are presented in section I.1.7.
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.
(FeResPost list of classes is given in Table 1 page 6.)

Method Name Description Example
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
Table I.1.1 – continued on next page
33
Table I.1.1 – continued from previous page

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 I.1.3.2
disableLayeredResultsReading I.1.3.2 IV.2.4
enableSubLayersReading I.1.3.2
disableSubLayersReading 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.5.1
calcFiniteElementResponse I.1.5 IV.5.6
calcFiniteElementCriteria I.1.5 IV.5.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
Attributes
Name I.1.7
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 special-
ized 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:
• “NbrCoordSys” attribute returns the number of coordinate systems stored in the DataBase.
• “NbrElements” attribute returns the number of elements stored in the DataBase.
• “NbrNodes” attribute returns the number of nodes stored in the DataBase.
Each of these methods has no argument and returns an integer. Other methods allow to check
the existence of finite element entities:
• “checkCoordSysExists” returns true if the specified coordinate system exists, false oth-
erwise.
• “checkElementExists” returns true if the specified element exists, false otherwise.
• “checkNodeExists” returns true if the specified node exists, false otherwise.

I.1.2. “GROUP” METHODS 35
• “checkRbeExists” returns true if the specified RBE exists, false otherwise.

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:
• “getElementType” returns an integer corresponding to the type ID of the element.
• “getElementTypeName” returns a string corresponding to the type name of the element.
• “getElementDim” returns an integer corresponding to the topological dimension of the

element.
• “getElementNbrNodes” returns an integer corresponding to the number of nodes defining

the element.
• “getElementNbrCornerNodes” returns an integer corresponding to the number of corner

nodes defining the element.
• “getElementNodes” returns an array of integers that corresponds to the element nodes.
• “getElementCornerNodes” returns an array of integers that corresponds to the element

corner nodes.
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 manipu-
lation 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 sec-
tion 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 de-
fined 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:
• “readGroupsFromPatranSession” reads one or several Groups from a Patran session file
obtained using the utility “Patran–>utilities–>groups–>exportToSessionFile”. The argu-
ment is a String corresponding to the name of the session file. The method returns nil. If
some of the entities read in the session file do not exist (for example, missing elements
or nodes), then the read entities will not be added to the Group. This corresponds to
the behavior of Groups in Patran. Therefore the session file containing the definition of
Groups should be read after the finite element model.
Note that, even though the method is related to an MSC software, it can be used with
DataBase related to different solvers. This is the reason why the method “readGroupsFromPatranSession”
is defined in generic DataBase class.
The method “readGroupsFromPatranSession” works as follows:
– It searches in the file the statements “ga_group_entity_add” and stores the while
PCL statement in a string.
– Then, the name of the Group being initialized is scanned from the string.
– Finally, the entity definition is scanned:
∗ The statement searches words like “Node”, “Element”, “MPC”, “CoordSys”.
∗ For any of the four first words, the method builds a list of integers correspond-
ing to the identifiers of the entities to be added to the Group. For the three last
words above, the method skips the entities.
The entities can be defined by a list of integers separated by blanks, or by pairs
of integers separated by “:” which defines a range of integers, or by groups
of three integers separated by two “:” which defines a range with a stepping
argument.
– Prior to storing the Group in DataBase, the method checks that the entities of the
Group are defined in the DataBase. If not, the are erased from the Group.
Note that the definition of Groups in Ruby by range specification uses the same kind of
formats as ”setEntities” method in Group class. (See section I.3.3.)
• “writeGroupsToPatranSession” writes the Groups stored in the DataBase in a text file

corresponding to a Patran session defining groups. This method is the reverse of method
“readGroupsFromPatranSession” an has one argument: the name of the Patran session
file.
• “addGroupCopy” is used to add a Group to a DataBase. The method returns nil and has
one argument: the Group object. Note that, when adding a Group to the DataBase, a
check is done to verify that all its entities are present in the DataBase. If not present, then
the corresponding entities are erased from the Group. As this involves the modification
of the Group definition, all operations are performed on a copy of the Group argument.
In the DataBase, the added Group is associated to the name of the group argument. If a
Group associated to the same name existed prior to adding the new Group, the method
replaces the former Group by the new one.
• “NbrGroups” attribute has no argument and returns the number of Groups stored in the
DataBase.
• “getAllGroupNames” has no argument and returns an Array of String objects correspond-

ing to the names of all the Groups contained in the DataBase on which the method is
called.
I.1.3. “RESULT” METHODS 37
• “checkGroupExists” allows to check whether a Group exists in the DataBase. The argu-
ment is a String object corresponding to the name of the Group. The returned value is
true if the Group has been found, false otherwise.
• “getGroupCopy” has one argument: a String object corresponding to the name of the
Group one tries to retrieve. The method returns a copy of the Group stored in the
DataBase, if the Group with the appropriate name exists. The method returns an error is
no Group with the appropriate name exists in the DataBase.
• “eraseGroup” erases a Group from the DataBase. The argument is a String object cor-
responding to the name of the Group to be erased. If the Group does not exist in the
DataBase, nothing is done.
• “eraseAllGroups” erases all Groups stored in the DataBase. This method has no argu-
ment.
• “getGroupAllElements” returns a Group containing all the elements that define the model
stored in the DataBase.
• “getGroupAllNodes” returns a Group containing all the nodes that define the model
• “getGroupAllRbes” returns a Group containing all the RBEs that define the model stored
in the DataBase.
• “getGroupAllCoordSys” returns a Group containing all the coordinate systems that de-
fine the model stored in the DataBase.
• “getGroupAllFEM” returns a Group containing all the elements, nodes, rbes and coordi-
nate systems that define the model stored in the DataBase.
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 asso-
ciation 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. In-
ternally, 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.
1
Note that the keys allowing to retrieve Results from a DataBase are not the same as the keys that allow to
retrieve values in a Result object, as explained in section I.4.1
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:
• “getResultLoadCaseNames” is a method without argument that returns an Array contain-

ing the names of all the load cases for which Results are stored in the DataBase.
• “getResultSubCaseNames” is a method without argument that returns an Array contain-

ing the names of all the subcases for which Results are stored in the DataBase.
• “getResultTypeNames” is a method without argument that returns an Array containing

all the Result identifiers for Results stored in the DataBase.
• “checkResultExists” is used to check whether a certain Result is present in the DataBase.

The method returns a Boolean value and has three String arguments corresponding to the
load case name, the subcase name, and the Result name.
• “getResultSize” returns the size of a Result object stored in the DataBase. The method
returns an integer value and has three String arguments corresponding to the load case
name, the subcase name, and the Result name. If the corresponding Result is not found,
“-1” is returned.
• “addResult” is used to add a Result to the DataBase. The arguments are three String
objects corresponding to the key (load case name, subcase name and Result type name),
and the Result object. If a Result with the same key is already present in the DataBase, it
is deleted and replaced by the new one.
• “generateCoordResults” has three String arguments and builds a Result corresponding

to Coordinates of elements and nodes. The arguments correspond to the key to which
the Result object is associated in the DataBase. (load case name, subcase name, and
Result name respectively.) If the String arguments are omitted, one assumes “”, “” and
“Coordinates” for the Result key.
• “generateElemAxesResults” has two or three arguments. The two first arguments are
the load case name and subcase name to which the produced Results will be associated.
These arguments are mandatory. The method produces several vectorial Results:
1. “Axis 1” corresponding to the first element axis.

2. “Axis 2” corresponding to the second element axis.
3. “Axis 3” corresponding to the third element axis.
4. “Normals” corresponding to the normals to 2D elements.
5. “Axis” corresponding to the first element axis of 1D elements.
6. “Coordinates” corresponding to the coordinate Results generated by “generateCoordResults”
method.
I.1.3. “RESULT” METHODS 39
By default, components are expressed in element axes, except for the “Coordinates”
Result which follow the conventions of “generateCoordResults” method. The third ar-
gument allows to modify this default behavior by expressing the components in another
coordinate system specified by a String or an integer argument. This argument is op-
tional. The use of this option leads to a very significant increase of the computation time
of the method.
Note also that the vectorial values are associated to element centers, and element corners.
For the “Coordinates” Result, values are also associated to nodes.
• “buildLoadCasesCombili” allows the definition of Result by linear combination of other

Results. The selection of the new Result and elementary Results is done by load case
names. The first argument is a String containing the new load case name of the Results
being created. The second argument contains an Array of real numbers corresponding to
the factors of the linear combination. The third argument is an Array of Strings contain-
ing the name of load cases to which elementary Results are associated. The lengths of
the two Array arguments must match.
• “renameResults” is used to modify the key by which Results stored in the DataBase can
be accessed. The method has two arguments:
1. An Array of three String objects corresponding to the identification of the Results

that must be renamed. If one of the String is void or replaced by nil, then all the
Results matching the non void Strings are renamed. Of course, at least one of the
three Strings must be non-void.
2. An Array of three Strings containing the new key identifiers. Strings must be void
or nil at the same time as the Strings of “From” argument.
• “copyResults” has the same arguments as “renameResults”, and performs nearly the
same operation. The difference is that the Result stored in the DataBase is now du-
plicated, and not simply renamed.
• “removeResults” is used to delete Results from the DataBase. This method has two
String arguments corresponding to the method of selection of Results and to an identifier
respectively. The “Method” argument has three possible values: “CaseId”, “SubCaseId”
or “ResId”. It specifies whether the Results to be deleted are identified by their load
case name, their subcase name or their Result type name. The second String argument
corresponds to the identifier of Results to be deleted.
• “removeAllResults” erases all Results stored in the DataBase. This method has no argu-
ment.
• “getResultCopy” returns a Result object containing a copy of a portion of a Result stored

in the DataBase. This method has generally six arguments (see below for other possibil-
ities):
1. A String argument corresponding to the load case name.

2. A String argument corresponding to the subcase name.
3. A String argument corresponding to the Result type name.

4. A String argument corresponding to the method of selection. Possible values of
this argument are: “Elements”, “ElemCenters”, “ElemCorners”, “Nodes”, “Nodes-
Only”, “ElemNodes”. A more detailed description of these different extraction
methods is given in section I.4.2. This “Method” string argument can be replaced
by a Result or ResKeyList object. Then it correspond to the target entities on which
the values are extracted. See remark below.)
5. A Group argument corresponding to the Target (selection of elements or nodes on
which the Results are recovered).
6. An Array corresponding to the list of layers on which results are to be recovered.
This Array can be void. If not void, its elements must be String or integer objects.
Some of the arguments given above are optional. For example, the function can be called
with 3 or 4 arguments only.
When the fourth argument is a Result or a ResKeyList object, the function must have
exactly four arguments. Then, it returns a new Result obtained by extracting the pairs of
key and values on the keys of the Result or ResKeyList argument.
Valid calls to the function are illustrated below:
res=db.getResultCopy(lcName,scName,resName,"ElemCenters",
targetGrp,layersList)
res=db.getResultCopy(lcName,scName,resName,layersList)
res=db.getResultCopy(lcName,scName,resName)
res=db.getResultCopy(LcName,ScName,ResName,targetRes)
res=db.getResultCopy(LcName,ScName,ResName,targetRkl)
res=db.getResultCopy(lcName,scName,resName,"ElemCenters",
targetGrp)
In the first example above, the extraction is done on the list of layers only; no selection
is done for the elements or nodes. In the second example, a copy of the Result stored in
the DataBase is returned, but not selection on the entities is made.
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 compos-
ite 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:
• “enableLayeredResultsReading” enables the reading of layered laminate Results (stresses,
strains, failure indices...). This method has no argument. Actually, this method is used to
re-enable the reading of layered laminate Results as this reading is enabled by default.
• “disableLayeredResultsReading” disables the reading of layered laminate Results (in-
verse of the previous method). Again, the method has no argument.
I.1.4. MANIPULATION OF ABBREVIATIONS 41
• “enableSubLayersReading” enables some sub-layers for the reading of composite lay-

ered Results from result files. The method has one argument: a String or an Array of
Strings chosen among “Bottom”, “Mid” and “Top”. Here again, as by default all the
sub-layers are enabled, the method is rather a “re-enabling” method.
• “disableSubLayersReading” disables some sub-layers for the reading of composite lay-

ered Results from result files. The method has one argument: a String or an Array of
Strings chosen among “Bottom”, “Mid” and “Top”.
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

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 re-
sponse has been added. This method called “calcFiniteElementResponse” has the same argu-
ments as the corresponding method defined in the “ClaLam” class. The method and the mean-
ing 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:
• The property ID or laminate ID corresponding to the element is identified. Then, the

algorithm tries to retrieve a laminate with the same ID from the ClaDb argument.
• If a laminate object has been identified and extracted, the algorithm performs the same
operations has for the method described in section II.4.8.
• Otherwise, no Result values are produced for the current key and one tries the next one.
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 pa-
rameter 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:
I.1.6. ITERATORS 43
...
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 spe-
cialized versions of the class are described in Part III.
• “each_abbreviation” loops on the abbreviations stored in the DataBase. It produces pairs

of Strings corresponding to the name of the abbreviation, and to the corresponding value
respectively. Again, one insists on the fact that this iterator is defined in generic DataBase
class.
• “each_groupName” loops on the Groups stored in the DataBase and produces String
elements containing Group names.
• The iterator “each_resultKey” produces Arrays containing the keys to which stored Re-
sults are associated. This iterator can be used in two different ways. Either:
db.each_resultKey do |lcName,scName,tpName|
...
end
or:
db.each_resultKey do |resKey|
...
end
In the second case, resKey is an Array containing three Strings.

• The following methods iterate on the CaseId, SubCaseId and ResultId corresponding to
the Results stored in the DataBase:
– “each_resultKeyCaseId”,
– “each_resultKeySubCaseId”,
– “each_resultKeyResId”.
Each iterator produces String elements.
• “each_resultKeyLcScId” iterator produces the pairs of load case names and subcase
names for which Results are stored in the DataBase. This iterator can for example be
used as follows:
db.each_resultLcScId do |lcName,scName|
...
end
However, if a single argument is passed in the block, it corresponds to an Array of two

Strings.
I.1.7 General purpose methods

A few more methods with general purpose are defined:
• “Name” attribute “setter” and “getter” allow the manipulate the identification of the
DataBase.
• Method “to_s” is used for printing the DataBase object.
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:
I.1.8. “GMSH” METHODS 45
• 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” and “ElemCenterPoints”. 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.
– “Elements” output location combines the outputs at “ElemCorners” and “El-
emCenters”. 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 ex-
pressed.
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.

new I.2.2 IV.2.4.5
initialize I.2.5
clone I.2.5
Definition
initWith3Points I.2.2.1 IV.2.4.5
initWithOV1V2 I.2.2.2
updateDefWrt0 I.2.2.2
Modifying point coordinates
changeCoordsA20 I.2.3.1 IV.2.4.5
changeCoords02B I.2.3.2 IV.2.4.5
changeCoordsA2B I.2.3.3 IV.2.4.5
Modifying vector or tensor components
changeCompsA20 I.2.4.1 IV.2.4.5
changeComps02B I.2.4.2 IV.2.4.5
changeCompsA2B I.2.4.3 IV.2.4.5
Printing
47
48 CHAPTER I.2. THE “COORDSYS” CLASS

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 modifi-
cation of reference coordinate systems to perform the transformations of components (sections
I.4.5.7 and I.4.5.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:
• A string argument corresponding to the type of coordinate system being build. Three
values are accepted: “CORDC”, “CORDR” and “CORDS”. (Remark that the “2” of
Nastran has disappeared.)
• A DataBase object that will allow the definition of coordinate system wrt the base coor-
dinate system.
• An integer argument corresponding to the reference coordinate system (coordinate sys-
tem wrt which the coordinates of points A, B and C are given). A coordinate system
corresponding to this integer must be defined in the DataBase passed as previous argu-
ment.
I.2.2. CONSTRUCTION OR MANIPULATION FUNCTIONS 49
• A vector containing the coordinates of point A. (Point A corresponds to the origin of the
coordinate system.)
• A vector containing the coordinates of point B. (Point B defines the axis Z of the coordi-
nate system. More precisely, point B is on axis Z.)
• A vector containing the coordinates of point C. (Point C defines the axis X of the co-
ordinate system. More precisely, the axis X of the coordinate system is defined in the
half-plane defined by the straight-line AB and the point C.)
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:
• A string argument corresponding to the type of coordinate system being build. Three
values are accepted: ‘CORDC”, “CORDR” and “CORDS”.
• A DataBase argument that provides the information needed to complete the definition of
the coordinate system.
• An integer argument corresponding to the reference coordinate system (coordinate sys-
tem wrt which the origin and direction vectors are specified).
• A vector containing the coordinates of the origin. This origin is specified with an Array
of three real values corresponding to the components of O wrt the reference coordinate
system identified with the integer argument.
• A vector (Array of three real values) corresponding to the direction i of the coordinate
system. The components of the vector are given wrt to the reference coordinate system
(estimated at point 0 if the reference coordinate system is curvilinear).
• A vector (Array of three real values) corresponding to the orientation of base vector j
of the coordinate system. The components of the vector are given wrt to the reference
coordinate system (estimated at point 0 if the reference coordinate system is curvilinear).
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 corre-
spondence 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 coordi-
nates 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 coordinate system on which the method is called is the coordinate system in which
the initial coordinates of the point are defined. (Coordinate system “A”.)
• The method has one “CoordA” argument: an Array of three real values corresponding to
the initial coordinates of the point in coordinate system “A”.
• The method returns a “Coord0” Array of three real values corresponding to the coordinate
of the same point, but expressed wrt basic coordinate system “0”.
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 coordi-
nate system “B”:
one wants to express the point coordinates (Coordinate system “B”.)
• The method has one “Coord0” argument: an Array of three real values corresponding to
the initial coordinates of the point in basic coordinate system “0”.
• The method returns a “CoordB” Array of three real values corresponding to the coordi-
nate of the same point, but expressed wrt coordinate system “B”.
coordsB=csB.changeCoords02B(coords0)
I.2.4. TRANSFORMATION OF VECTOR AND TENSOR COMPONENTS 51
I.2.3.3 “changeCoordsA2B” method

Method “changeCoordsA2B” is used to calculate the coordinates of a point wrt a given coordi-
nate system “B”. The initial coordinate system is a given “A” coordinate system:
• The coordinate system on which the method is called is the initial coordinate system in
which the point coordinates are expressed (Coordinate system “A”.)
• The first “CoordA” argument is an Array of three real values corresponding to the initial
coordinates of the point in coordinate system “A”.
• The second “CsB” argument is a “CoordSys” object wrt which one wants to calculate the
point new coordinates.
• The method returns a “CoordB” Array of three real values corresponding to the coordi-
nate of the point expressed wrt coordinate system “B”.
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:
• One modifies the components of a vector or of a tensor.
• A vector is defined as an Array of three real values. A tensor is defined as an Array of
three Arrays of three real values.
• If a vector argument is given, the method returns a vector. If a tensor argument is given,
the method returns a tensor.
• For each of the methods given here, the coordinates of the point at which the vector or
tensor argument is defined, are also given as argument. This means that the methods
have one additional argument compared to the corresponding methods of section I.2.3.3.
The position of the point matters when curvilinear coordinate systems are involved in the
transformation.
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 initial components are defined. (Coordinate system “A”.)
• The first “CoordA” argument is an Array of three real values corresponding to the coor-
dinates of the point in coordinate system “A”.
• The second “vmA” argument corresponds to the components of vector or tensor (matrix)
in coordinate system “A”. (An Array of three real values, or an Array of Arrays of three
real values.)
• The method returns the components of a vector or tensor, but expressed wrt basic coor-
dinate system “0”. (An Array of three real values, or an Array of Arrays of three real
values.)
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:
one wants to express the components. (Coordinate system “B”.)
• The first “Coord0” argument is an Array of three real values corresponding to the coor-
dinates of the point in coordinate system “0”.
• The second “vm0” argument corresponds to the components of vector or tensor (matrix)
in coordinate system “0”. (An Array of three real values, or an Array of Arrays of three
real values.)
dinate system “B”. (An Array of three real values, or an Array of Arrays of three real
values.)
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 initial components are defined. (Coordinate system “A”.)
• The first “CoordA” argument is an Array of three real values corresponding to the coor-
dinates of the point in coordinate system “A”.
• The second “vmA” argument corresponds to the components of vector or tensor (matrix)
in coordinate system “A”. (An Array of three real values, or an Array of Arrays of three
real values.)
• The third “CsB” argument is a “CoordSys” object wrt which one wants to calculate the
new components.
I.2.5. OTHER METHODS 53
dinate system “B”. (An Array of three real values, or an Array of Arrays of three real
values.)
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.

new I.3.2 IV.2.5.1
initialize I.3.7
clone I.3.7
Identification (attributes)
Name= I.3.7 IV.2.2.3
Name I.3.7
Manipulation of entities
getEntitiesByType I.3.3 IV.2.2.2
getNbrEntities I.3.3
getNbrEntitiesByType I.3.3 IV.2.2.2
setEntities I.3.3 IV.2.5.1
setEntitiesByType I.3.3
addEntities I.3.3
addEntitiesByType I.3.3
removeEntities I.3.3
removeEntitiesByType I.3.3
clearAllEntitiesByType I.3.3
matchWithDbEntities I.3.3 IV.2.5.1
importEntitiesByType I.3.3
containEntity I.3.3
Operators
55
56 CHAPTER I.3. THE “GROUP” CLASS

+ I.3.4 IV.2.5.1
- I.3.4
* I.3.4 IV.2.2.4
/ I.3.4
BLOBs for SQL
toBlob I.3.5
fromBlob I.3.5
Iterators
each_element I.3.6
each_mpc I.3.6
each_node I.3.6 IV.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
NbrMpcs 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
MPCs. At C++ level, for each type of entity, the class group manages a set of integers corre-
sponding 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 de-
scribed 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.
I.3.3. MANIPULATION OF ENTITIES STORED IN A GROUP 57
The modification of the Group’s content can be done by calls to the following methods:
• “setEntities” takes a String argument that contains the definition of Group entities in a
format similar to the format of the Patran Group session file (section I.1.2.1). All entities
previously stored in the Group are erased before the conversion of the String argument.
The function returns “self” (the modified Group object).
• “setEntitiesByType” has two arguments. The first argument, “TypeName” is a String

object that specifies the type of entities to be added to the Group. This first argument
may have four different values: “Node”, “Element”, “MPC” or “CoordSys”. Any other
argument is invalid. The second argument may have two different types:
1. The second argument may be a String object containing the definition of a group
in a format similar to the format of the Patran Group session file (section I.1.2.1.
However, in this case, only the entities of the type selected by the “TypeName”
argument are stored in the Group.
2. The second argument may also be an Array of integers. Then the integers corre-
spond to the entities added to the Group. The type of entities is specified by the
“TypeName” argument.
As for the “setEntities” method, all entities previously stored in the Group are erased
before inserting the new entities.
• “addEntities” is identical to “setEntities” but the entities stored in the Group are not
erased before adding the new entities.
• “addEntitiesByType” is identical to “setEntitiesByType” but the entities stored in the

Group are not erased before adding the new entities.
• “removeEntities” is identical to “addEntities” but the selected entities are removed from
the Group instead of being added to it.
• “removeEntitiesByType” is identical to “addEntitiesByType” but the selected entities are

removed from the Group instead of being added to it.
• “clearAllEntitiesByType” has one String argument corresponding to the type of entities

to be cleared from the Group. Possible arguments are “Node”, “Element”, “MPC” or
“CoordSys”.
• “importEntitiesByType” is used to insert entities in a Group by importing them from

another Group, or from the entities stored in a DataBase model. The method has two or
four arguments:
– The first argument is a String corresponding to the type of entities to be inserted.

Possible arguments are “Node”, “Element”, “MPC” or “CoordSys”.
– The Second argument is either a Group, or a DataBase.
– the third and four arguments are integers corresponding to the range of insertion
(idMin and idMax). If omitted, then all entities of the corresponding type are in-
serted.
• “matchWithDbEntities” is used to ensure that a Group contains only entities that are
defined in a DataBase. The function has one DataBase argument. After calling this
method, the entities that do not exist in the DataBase have been cancelled from the Group
too.
Presently, four methods devoted to the manipulation of entities and not modifying the Group
have been defined:
• “getEntitiesByType” receives one String argument corresponding to the type of entity

and returns an Array of integers containing the corresponding entity indices. The four
possible values of the argument are “Node”, “Element”, “MPC” and “CoordSys”.
• “getNbrEntitiesByType” receives one String argument corresponding to the type of en-

tity and returns an integer corresponding to the number of entities of the specified type
contained in the Group. The four possible values of the argument are “Node”, “Element”,
“MPC” and “CoordSys”.
• “getNbrEntities” has no argument and returns an Array of four integer corresponding to

the number of entities of each of the following types, and in the same order as: “Co-
ordSys”, “Element”, “Node” and “MPC”.
• “containEntity” allows to check whether a given entity belongs to the Group. The method
has two arguments:
– The first argument is a String corresponding to the type of entities to be inserted.

Possible arguments are “Node”, “Element”, “MPC” or “CoordSys”.
– The second integer argument is the entityId.
The function returns a bool value.
I.3.4 Group operators

Eight such operators have been defined. One first explains the meaning and behavior of the
four elementary dyadic operations.
• “+” operator returns the union of two Groups.
• “-” operator returns the difference of two Groups.
• “*” operator returns the intersection of two Groups.
• “/” operator: if x and y are two Groups, then x/y = (x + y) − (x ∗ y). (The operation is
equivalent to a logical “exclusive or” operation on the entities.)
I.3.5. “BLOBS” 59
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:
• “toBlob” has no argument and returns the BLOB in a String object.
• “fromBlob” has one String argument corresponding to the BLOB, and initializes the
Group according to Blob content.
I.3.6 Iterators of Group class

The class “Group” provides four iterators:
• method “each_element”,
• method “each_mpc”,
• method “each_node’,
• method “each_coordsys”.
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:
• Method “initialize” initializes or clears a Group object.
• Method “clone’ returns a Copy of the Group object to which it is applied.
• Attribute “Name” returns a String containing the name of the Group.
• Attribute “Name=” has one String argument and sets the name of the Group.
• Attribute “NbrElements” returns an integer containing the number of elements stored in
the Group.
• Attribute “NbrNodes” returns an integer containing the number of nodes stored in the
Group.
• Attribute “NbrMpcs” returns an integer containing the number of MPCs stored in the
Group.
• Attribute “NbrCoordsys” returns an integer containing the number of coordinate systems
stored in the Group.
• Method “to_s” is used for printing the Group object.
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 manip-
ulation 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.

new I.4.13 IV.2.4.6
initialize I.4.13
clone I.4.13 IV.2.4.6
cloneNoValues I.4.13
Manipulation of data
Name= I.4.5.1
Name I.4.5.1
clearData I.4.5.1
getData I.4.9 IV.2.4.2
Size I.4.13 IV.2.4.1
Format= I.4.5.1
61
62 CHAPTER I.4. THE “RESULT” CLASS

Format I.4.5.1
TensorOrder= I.4.5.1
TensorOrder I.4.5.1
setIntId I.4.5.1
getIntId I.4.5.1
setRealId I.4.5.1
getRealId I.4.5.1
insert I.4.5.1
insertRklVals I.4.5.1
insertResultValues I.4.5.1
removeKeysAndValues I.4.5.1
setComponent I.4.5.1
setRefCoordSys I.4.5.2
renumberLayers I.4.5.3
renumberSubLayers I.4.5.4
removeLayers I.4.5.5
removeSubLayers I.4.5.6
modifyRefCoordSys I.4.5.7 IV.2.4.5
modifyPositionRefCoordSys I.4.5.8 IV.2.5.2
setToCombili I.4.5.9
Extraction methods
extractResultOnEntities I.4.2.1
extractResultOnLayers I.4.2.2
extractResultOnSubLayers I.4.2.3
extractResultOnRkl I.4.2.4 IV.2.4.2
extractResultOnResultKeys I.4.2.5
extractResultOnRange I.4.2.6
extractResultForNbrVals I.4.2.7
extractResultMin I.4.2.8
extractResultMax I.4.2.9 IV.2.4.2
extractRklOnRange I.4.2.10
extractRklForNbrVals I.4.2.11
extractRklMin I.4.2.12
extractRklMax I.4.2.13
extractRkl I.4.2.14 IV.2.4.2
extractLayers I.4.2.18
extractSubLayers I.4.2.19
extractGroup I.4.2.17
extractGroupOnRange I.4.2.15
extractGroupForNbrVals I.4.2.16
63

Derivation methods
deriveScalToScal I.4.3.1 IV.2.4.2
deriveScalPerComponent I.4.3.2 IV.2.4.2
deriveVectorToOneScal I.4.3.3 IV.2.5.4
deriveVectorToVector I.4.3.4
deriveVectorToTensor I.4.3.5
deriveTensorToOneScal I.4.3.6
deriveTensorToTwoScals I.4.3.7
deriveTensorToThreeScals I.4.3.8 IV.2.4.2
eigenQR I.4.3.9 IV.2.4.2
deriveDyadic I.4.4
deriveByRemapping I.4.3.10
Global Force and Moment
calcResultingFM I.4.7 IV.2.5.3
Operators
+ I.4.6.1
- I.4.6.2
* I.4.6.3 IV.2.5.2
/ I.4.6.4
** I.4.6.5
BLOBs for SQL
toBlob I.4.10 IV.2.6, IX.1.5, VII.1.8
fromBlob I.4.10
Iterators
each I.4.11 IV.2.4.4
each_key I.4.11 IV.2.4.5
each_values I.4.11 IV.2.4.5
Complex Results manipulation
set2RI I.4.8.1 IV.2.4.6
set2MP I.4.8.1 IV.2.4.6
conjugate I.4.8.2
getR I.4.8.4 IV.2.4.6
getM I.4.8.4 IV.2.4.6
getI I.4.8.4 IV.2.4.6
getP I.4.8.4 IV.2.4.6
rotateBy I.4.8.3
assembleComplex I.4.8.5 IV.2.4.6
A few singleton methods
layerStr2Int I.4.12
layerInt2Str I.4.12

subLayerStr2Int I.4.12
subLayerInt2Str I.4.12
Attributes
Name I.4.5.1
Other methods
to_s I.4.13
Attributes
Name I.4.5.1
Size I.4.13 (read only)
Format I.4.5.1
TensorOrder I.4.5.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:
• The index of an element.
• The index of a node.
• A pair of integers corresponding to the indices of an element and of a node (for Results
given at corners of elements).
• A pair of integers corresponding to the indices of an element and of a layer (for example,
for layered Results corresponding to laminated properties).
• ...
So, at C++ level, each key is characterized by four integers:
• A 32bits integer corresponding to the element index,
• A 32bits integer corresponding to the node index,
• A 32bits integer corresponding to the layer index,

I.4.1. THE CONCEPT OF “RESULT” 65
• An 8bits char corresponding to the sub-layer index (rarely used).
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 corre-
sponds to groups of layers and are used to perform extraction operations:
• “Beam Points” is used to extract on layers “Point A”, “Point B”,...
• “Shell Layers” is used to extract on layers “NONE”, “Z1” and “Z2”.
• “All Plies ” is used to extract on all layers with positive Ids (i.e. laminate plies).
• “All Layers ” extracts on all layers.
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 ..." ...
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:
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
1
"Z0" -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
I.4.1. THE CONCEPT OF “RESULT” 67
• -9999 means that the results are not attached to a coordinate system. Their value corre-
sponds to String “NONE”.
• -2000 means that the values are expressed in a user defined coordinate system. This
means a coordinate system which is not identified by an integer to be later retrieved from
a DataBase. The corresponding String is “userCS”.
• -1000 means that the values are expressed in a coordinate system projected on surfacic
elements. This means also that the values are no longer attached to a peculiar coordinate
system defined in a DataBase. The corresponding String is “projCS”.
• -6 means the laminate coordinate system. The corresponding String is “lamCS”.
• -5 means the patran element IJK coordinate system which correspond to the element co-
ordinate system for most finite element software. The corresponding String is “elemIJK”.
• -4 means the ply coordinate system when the element has laminated properties. The
corresponding String is “plyCS”.
• -3 means the material coordinate system. The corresponding String is “matCS”.
• -2 means the nodal analysis coordinate system. Values must then be attached to a node
(nodeId of key). The corresponding String is “nodeCS”.
• -1 means the element coordinate system. The corresponding String is “elemCS”.
• Any integer greater than or equal to zero: a coordinate system defined in a DataBase
object. “0” denotes the base Cartesian coordinate system.
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:
• A “scalar” Result has one component.
• A “vectorial” Result has three components named “X”, “Y” and “Z” respectively.
• A “tensorial” Result has normally nine components. However, as all the tensors with
which one deals are symmetric, only six components are stored: “XX”, “YY”, “ZZ”,
“XY”, “YZ”, “ZX”.
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:
• First all the Real or Magnitude components are presented.
• Then all the Imaginary or Angular components follow. The angular components are
expressed in ◦ (Nastran convention).
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 name of the object (a String). This name can be set or retrieved with methods
“Name=” and “Name”. These methods correspond to “Name” attribute.
• Two integer identifiers that may contain information like the load case id, the mode num-
ber,... These member data can set or retrieved with methods “setIntId” and “getIntId”.
• Two real identifiers that may contain information related to the time for a transient cal-
culation, to continuation parameters, eigen-values,... These member data can set or re-
trieved with methods “setRealId” and “getRealId”.
The methods used to access these member data are described in section I.4.5.1.
I.4.1.4 Other characteristics

A Result object is also characterized by two other integer values:
• The tensorial order of the values it stores. This integer may be 0, 1 or 2 corresponding to
scalar, vectorial or (order 2) tensorial values.
• The format of the result. This value may be 1 (Real values), 2 (Complex Result in
rectangular format) or 3 (Complex Result in polar format).
Methods used to manipulate these data are described in section I.4.5.1. These two integers are
attributes of the class.
I.4.2 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.2.1 “extractResultOnEntities” method

“extractResultOnEntities” method is used to extract a sub-set of keys and values from an exist-
ing 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:
• “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.
I.4.2. EXTRACTION METHODS 69
• “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 associ-
ated 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.
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 “getResult” described in
section I.1.3.
This method works for Real as well as for Complex Results.
I.4.2.2 “extractResultOnLayers” method

“extractResultOnLayers” method is used to extract a sub-set of keys and values from an exist-
ing 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.
I.4.2.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.
I.4.2.4 “extractResultOnRkl” method

extractResultOnRkl method returns a Result object build by extraction of the values corre-
sponding to the keys contained in the ResKeyList “Target” argument.
I.4.2.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.)
I.4.2.6 “extractResultOnRange” method

“extractResultOnRange” method returns a Result object build by extraction of the values se-
lected 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 val-
ues 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 “Upper-
Bound” 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.2.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 argu-
ments:
I.4.2. EXTRACTION METHODS 71
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.

I.4.2.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.
I.4.2.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.
I.4.2.10 “extractRklOnRange” method

“extractRklOnRange” method works exactly as method “extractResultOnRange” described in
section I.4.2.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.
I.4.2.11 “extractRklForNbrVals” method

“extractRklForNbrVals” method works exactly as method “extractResultForNbrVals” described
in section I.4.2.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.
I.4.2.12 “extractRklMin” method

“extractRklMin” method returns a ResKeyList object build by extraction of the key correspond-
ing to the minimum value. This method can be applied to scalar Result objects only.
I.4.2.13 “extractRklMax” method

“extractRklMax” method returns a ResKeyList object build by extraction of the key corre-
sponding to the maximum value. This method can be applied to scalar Result objects only.
I.4.2.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.
I.4.2.15 “extractGroupOnRange” method

“extractGroupOnRange” method works exactly as method “extractResultOnRange” described
in section I.4.2.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.
I.4.2.16 “extractGroupForNbrVals” method

“extractGroupForNbrVals” method works exactly as method “extractResultForNbrVals” de-
scribed in section I.4.2.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.
I.4.2.17 “extractGroup” method

“extractGroup” method returns a Group object containing the elements and nodes that are ref-
erenced in the Result object. This method has no argument.
I.4.2.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.
I.4.2.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.
I.4.3 Derivation monadic methods

All the methods presented in this section are devoted to the production of new results by per-
forming 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 num-
ber of components. Indeed, the original Result and derived Result have not necessarily a same
tensor order.
I.4.3. DERIVATION MONADIC METHODS 73
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.3.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:
• “sin”: returns sin(arg) (angle in radians).
• “cos”: returns cos(arg) (angle in radians).
• “tan”: returns tan(arg) (angle in radians).
• “asin”: returns sin−1 (arg) (angle in radians).
• “acos”: returns cos−1 (arg) (angle in radians).
• “atan”: returns tan−1 (arg) (angle in radians).
• “exp”: returns earg .
• “log”: returns loge (arg).
• “exp10”: return 10arg .
• “log10”: returns log10 (arg).
• “abs”: returns |arg|.
• “inv”: returns 1/arg.
• “sinh”: returns sinh(arg).
• “cosh”: returns cosh(arg).
• “tanh”: returns tanh(arg).
• “sq”: returns arg2 .
√
• “sqrt”: arg.
• “sgn”: +1, 0 or -1 depending on the value of argument (arg>0, arg==0 or arg<0 respec-
tively).
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.3.2 “deriveScalPerComponent” method

“deriveScalPerComponent” method builds a new Result object by performing a scalar oper-
ation 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 per-
formed 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.3.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:
• “Component X”: returns the first component of the vector.
• “Component Y”: returns the second component of the vector.
• “Component Z”: returns the third component of the vector.
• “abs”: returns kargk.
• “sq”: returns kargk2 .
This method works for Real Results as well as for Complex Results. When applied to a Com-
plex Result object, the method works as follows:
• The three “Component” methods produce a Complex scalar Result object.
• The method “sq” produces the scalar product of the vector by its conjugate. This is a
Real scalar Result.
• The method “abs” produces the square root of the “sq” method. This is also a Real scalar
Result.
I.4.3.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:
• “normalize”: normalizes the vectorial values.
This method works for Real Results as well as for Complex Results.
I.4.3.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:
• “extSquare”: builds a tensor from a vector by calculating the external product of the
vector by himself. More precisely:
   
M11 M12 M13 v1 v1 v1 v2 v1 v3
 M21 M22 M23  =  v2 v1 v2 v2 v2 v3  .
M31 M32 M33 v3 v1 v3 v2 v3 v3
This method works for Real Results as well as for Complex Results.
I.4.3.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:
• “Component XX”: returns the corresponding component of the tensor.
• “Component XY”: returns the corresponding component of the tensor.
• “Component XZ”: returns the corresponding component of the tensor.
• “Component YX”: returns the corresponding component of the tensor.
• “Component YY”: returns the corresponding component of the tensor.
• “Component YZ”: returns the corresponding component of the tensor.
• “Component ZX”: returns the corresponding component of the tensor.
• “Component ZY”: returns the corresponding component of the tensor.
• “Component ZZ”: returns the corresponding component of the tensor.
• “VonMises”: returns the equivalent Von Mises stress assuming that the tensorial Result
is a stress.
• “MaxShear”: returns the maximum shear evaluated from the maximum and minimum
principal values according to Mohr’s theory.
• “MaxPrincipal”: returns the maximum principal value.
• “MinPrincipal”: returns the minimum principal value.
• “det” or “abs”: returns the determinant of the tensor.

• “2DMaxShear”: returns the maximum shear evaluated from the maximum and minimum
principal values according to Mohr’s theory, assuming that the tensor is a 2D tensor (all
components TiZ = TZj = 0).
• “2DMaxPrincipal”: returns the maximum principal value assuming that the tensor is a
2D tensor (all components TiZ = TZj = 0).
• “2DMinPrincipal”: returns the minimum principal value assuming that the tensor is a 2D
tensor (all components TiZ = TZj = 0).
• “VonMises2D”: returns the equivalent Von Mises stress assuming that the tensorial Result
is a stress. The calculation is done considering that Szz, Sxz and Syz components are
zero. (It is user’s responsibility to make sure that the stress tensor is expressed in a
coordinate system such that the call to method makes sense.)
All the methods listed above work for Real Tensorial Results. For Complex Results, only the
methods of Component extractions can be used.
I.4.3.7 “deriveTensorToTwoScals” method

“deriveTensorToTwoScals” method returns an Array of two Result objects derived from the ten-
sorial Result object on which the method is applied. The returned Results are scalar. Possible
values of the “Method” String argument are:
• “Principals2D”: returns the principal values of a tensorial Result assuming that the tensor
is a 2D tensor (all components TiZ = TZj = 0). The first Result contains minimum
principal values, and the second Result contains maximum principal Values.
• “PrincipalsMinMax”: returns the minimum and maximum principal values of a tenso-

rial Result. The first Result contains minimum principal values, and the second Result
contains maximum principal Values.
I.4.3.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. Possi-
ble values of the “Method” String argument are:
• “Principals”: returns the principal values of a tensorial Result sorted by order of increas-
ing values. (First Result contains minimum principal values, second Result corresponds
to second principal value, and third Result contains the maximum principal values.)

I.4.3.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.3.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 Re-
sult object and the keys of the new Result object. Eleven different values of the “FromTo”
argument are allowed:
• “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.
• “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).
• “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.
• “NodesToCorners”: one selects all the values associated to nodes and produces a
new Result in which the values are associated to the corners of the elements.
• “CornersToCenters”: 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 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), 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 El-
ement, 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 ac-
cepted.
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 merg-
ing values: the “min” and “max” values are not accepted for Complex Results.
I.4.4. DYADIC DERIVATION METHOD 79
I.4.4 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:
• The “Method” String argument corresponds to the name of the dyadic method that is
used for the calculation of new Result’s values.
• The ”Second” argument can be a Result object or a real value. The Result object is always
a valid argument if its tensor order is compatible of the operation being performed. The
“real” argument is valid only if the invoked method is “atan2” or “pow”.
Possible values for the “Method” argument are:
• “atan2” performs the “atan2” operation on its argument values (zi = tan−1 (xi /yi )). The
object on which the method is called must be a scalar Result object. The “Second”
argument must be either a scalar Result or a real value. For a real argument, one calculates
zi = tan−1 (xi /y)
• “pow” performs the “pow” operation on its argument (zi = xyi i ). The object on which the
method is called must be a scalar Result object. The “Second” argument must be either
a scalar Result or a real value. For a real argument, one calculates zi = xyi for each i.
• “vectProduct” calculates the vectorial product of its arguments. Several types of argu-
ments are accepted:
– The two arguments are vectorial Result objects. Then, wi = ui × v i .

– The second argument can be replaced by a vector (Array of three real elements).
Then, one calculates wi = ui × v.
– The first argument can be replaced by a vector (Array of three real elements) or a
complex vector (Array of three complex elements). Then, wi = u × v i .
• P
“sumVectProduct” calculates the sum of the vectorial product of its arguments: w =
i ui × v i . The two arguments are vectorial Result objects.
• “min” keeps the minimum of the two values. Values must be Real. If the arguments are
not scalar, they must have common tensorial order, and for each key-value pair, the coor-
dinate system ID of the arguments must match. Then, the derivation is done component
per component.
• “max” keeps the maximum of the two values. Values must be Real. If the arguments are
not scalar, they must have common tensorial order, and for each key-value pair, the coor-
dinate system ID of the arguments must match. Then, the derivation is done component
per component.
• “compare” sets the value of new Result to -1, 0 or 1 depending on the relative first and
second values. Values must be scalar and Real. If the arguments are not scalar, they must
have common tensorial order, and for each key-value pair, the coordinate system ID of
the arguments must match. Then, the derivation is done component per component.
• “merge” or “mergeKeepFirst” keeps the value of the first Result if a given key is present
in the two values. Otherwise the pair key-value of the second Result is kept.
• “mergeKeepLast” keeps the value of the second Result if a given key is present in the
two values. Otherwise the pair key-value of the first Result is kept.
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 “merge-
KeepLast” 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.5 Methods modifying the object

One presents here methods that modify the Result object to which they are applied.
I.4.5.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.
• “Name” returns a String containing the name of the Result. The method has no argument.
• “Name=” has one String argument and sets the name of the Result.
• “Format” returns an integer corresponding to the format of the Result (1="Real", 2="Real-
Imaginary", 3="Magnitude-Phase").
• “Format=” has one integer argument and sets the format of the Result object. (Same
possible values as for “Format” attribute “getter”.)
• “TensorOrder” returns an integer corresponding to the tensorial order of the Result.
• “TensorOrder=” has one integer argument and sets the tensorial order of the object.
• “clearData” has no argument and clears the keys and values stored in a Result object.
• “insert” has two Array arguments corresponding to a result::key and a result::values re-
spectively:
– The “Key” argument is an Array of between 1 and 4 elements corresponding to

element, node and layer identifiers respectively. These elements can be of String or
integer types.
I.4.5. METHODS MODIFYING THE OBJECT 81
– The “Values” argument is an Array of elements the number of which depends on

the tensorial order of the Result object that is filled. (This tensorial order must
have been defined already.) The first element of the Array is always the coordinate
system identifier (a String or integer object). The other elements of the Array are
Real values corresponding to the components.
• “insertRklVals” has two arguments corresponding to a ResKeyList or Result object and

a result::values object respectively:
– The “Rkl” is a ResKeyList or Result object containing the list of keys for which
values are inserted. This argument can be replaced by a Result object; then, only
the keys of the Result are used for insertion of data.
– The “Values” is the same argument as in “insert” method described above. Note that
one inserts identical values for the different keys of the “Rkl” ResKeyList object.
• “insertResultValues” has one “Result” argument. The keys and values of the of this
“Result” object are inserted to the Result object on which the method is called.
• “setComponent” has two or three arguments and allows to modify a selected component
of the values stored in the Result object on which the method is called:
– If the method has three arguments:

∗ The first “oComp” argument is an integer corresponding to the index of the
component that shall be modified.
∗ The second “inRes” argument is a Result object from which the new compo-
nent values are read.
∗ The third “iComp” argument is an integer corresponding to the index of the
component that is read from the “inRes” Result object.
The values of the target Result object (on which the method is called) are modified
only for the keys that are found in the “inRes” Result argument. It is the responsibil-
ity of the user to defined correct “oComp” and “iComp” indices. (First component
corresponds to index 0.)
– If the method has two arguments:
∗ The first “oComp” argument is an integer corresponding to the index of the
component that shall be modified.
∗ The second “fValue” argument is a real value corresponding to the new com-
ponent value.
With this version of the method, all the values of the target Result object are mod-
ified. Here again, the user is responsible for the correct definition of “oComp”
argument.
• “removeKeysAndValues” is used to remove keys and values from an existing “Result”

object. If the method has one argument, the arguments is either a “Result” or a “ResKeyList”
object. Then, keys and values are removed for all the keys found in the argument. If two
arguments are provided, they must be a “method” String argument, adn a “Group” argu-
ment, and the method keys are eliminated according to the “getData” method.
• “setIntId” has two arguments: the index of integer ID to be set, and its new value.
• “getIntId” has one argument: the index of integer ID that is to be retrieved.
• “setRealId” has two arguments: the index of real ID to be set, and its new value.
• “getRealId” has one argument: the index of real ID that is to be retrieved.
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.5.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:
• An integer corresponding to the integer ID of the associated coordinate system.
• A String corresponding to the names of peculiar coordinate systems. The possible val-
ues for the String are “NONE”, “userCS”, “projCS”, “elemCS”, “nodeCS”, “matCS”,
“plyCS” and “elemIJK”.
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.
I.4.5.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”.
I.4.5.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”.
I.4.5.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.
I.4.5. METHODS MODIFYING THE OBJECT 83
I.4.5.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.
I.4.5.7 “modifyRefCoordSys”
“modifyRefCoordSys” is used to modify the reference coordinate system wrt which the com-
ponents 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 argu-
ments:
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” coor-
dinate 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 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 ex-
pressed 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 sys-
tems, 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.
I.4.5.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 vec-
torial.
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.5.7.
This method can be used with real Results only.
I.4.5.9 “setToCombili”
“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).
I.4.6. OPERATORS 85
I.4.6 Operators
Five elementary operators on Result objects have been defined. Also, their corresponding as-
signment 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 re-
placed by a constant real value.
One can make a few general remarks:
• When the two arguments are vectorial or tensorial Results, the coordinate system ids
must be the same for each corresponding values.
• The coordinate system associated to the values of the constructed Result z is defined
according the following rules:
1. For a scalar Result z, the cId is always set to -9999 (Result not associated to a
coordinate system).
2. For a vectorial or tensorial Result, the coordinate system for each value is set to the
corresponding coordinate systems of the vectorial or tensorial arguments.
3. When it is not possible to determine the Result coordinate system according to the
preceding rules, the CID is set to 0 for all values. An example of such a case is the
division of an Array by a scalar Result.
• The operators are defined in the Result class. This means that the first operand must be a
Result object. However, to the different operators defined in Result class corresponding
“operator” methods defined the “Post” module. Several of the “Post” methods allows to
replace the first operand by a real object or an Array. (See section I.6.4.)
Note that this rule does not apply to the .NET assembly that allows the first operand of
the different operators to be replaced by constant values.
The support for Complex Result operators depends on the type of dyadic operation. See the
sub-sections below for more information.
I.4.6.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.6.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.6.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 possi-
bilities are summarized in Table I.4.6 with a short explanation of the meaning of the operation
when deemed necessary.
Table I.4.6: Possible arguments of the Result multiplication operator, returned value, and mean-
ing of the operation.
z x y 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.6.4 Division operator

The division operator can be used as follows:
z = x/y .
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. “CALCRESULTINGFM” METHOD 87
I.4.6.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.7 “calcResultingFM” method

“calcResultingFM” method is a class method used to estimate the total force and moment cor-
responding 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 recov-
ery 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:
• If argument 5 is omitted, the method assumes that the recovery point is located on the
origin of the coordinate system.
• I argument 6 is omitted, the nodal coordinates

P are used to estimate the global moment
corresponding to the nodal forces (M = i xi × f i ). Then, the forces used to estimate
the global moment must be associated to nodes.
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.8 Complex Results

Several methods correspond to operations specific to complex Results. These methods are
described below.
I.4.8.1 Rectangular-Polar conversions

Two methods allow to tranform Complex Results expressed in real-imaginary format to magnitude-
phase format, and reversely:
• “set2RI” produces a complex Result in rectangular (real-imaginary) format. 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.
• “set2MP” produces a Complex Result in polar (magnitude-phase) format. The method
has the same characteristics as “set2RI”.
For these two methods, no complex conversion is performed if the Result is already in the
requested format.
I.4.8.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.8. COMPLEX RESULTS 89
I.4.8.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 indiffer-
ently with Complex Results in rectangular or in polar formats. The method may have one or
two arguments:
• If the method has only one argument, it is the angle θ that is added to the phase. The
modified argument is the Result object on which the method is called.
• If the method has two arguments, the first one is a Result object, and the second one is
the rotation angle in degrees. Then the Result object on which the method is applied is
initialized to the rotated argument Result object.
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.8.4 Extractions from Complex Results

Four methods produce Real Results from Complex Results by extracting the appropriate com-
ponents:
• “getR” returns the “Real” components of the Result.
• “getM” returns the “Magnitude” components of the Result.
• “getI” returns the “Imaginary” components of the Result.
• “getP” returns the “Phase” components of the Result.
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.8.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:
• They must be Real Results.
• They must have the same number of key-values pairs, with exact key matches.
• Their values must have the same number of components.
• When one pair of value objects are merged, their Coordinate System IDs must be the
same.
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.9 “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 five, seven
or ten 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.7.
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.
I.4.10. “BLOBS” 91
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.7: Correspondence between the integer in C++ “value” class and the value returned
by Result member method “getData”.
integer in C++ “value” class returned 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.10 “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:
• “toBlob” has no argument and returns the BLOB in a String object.
• “fromBlob” has one String argument corresponding to the BLOB, and initializes the
Result according to Blob content.
I.4.11 Iterators
Three iterators are defined in the class:
• “each” iterates on the data and produces pairs of key and values. Each key is an Array
of four elements, and each “values” and Array of 2 to 7 elements. The iterator may have
between 0 and 5 arguments. The arguments are Strings that specify whether some of the
data are to be returned in String or integer format. The consecutive arguments correspond
to the formatting of element id, node id, layer id, sub-layer id and coordinate system id.
• “each_key” iterates on the data and produces Arrays of three elements corresponding to
keys. The iterator may have between 0 and 4 argument. The arguments are Strings that
specify whether some of the data are to be returned in String or integer format.
• “each_values” iterates on the data and produces Arrays of 2 to 7 elements. The iterator
may have 1 or no String argument specifying the Type of the element corresponding to
the coordinate system identifier.
For the meaning of the arguments, see more information in section I.4.9. One difference be-
tween the “each” iterator and the getData method is that the key and values elements are sepa-
rated 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.12 A few singleton (static) methods

Four singleton methods allow to convert layers and sub-layers string/integer IDs:
• “layerStr2Int” converts a layer name to its corresponding layer integer ID.
• “layerInt2Str” converts a layer integer ID to the corresponding name (String).
• “subLayerStr2Int” converts a sub-layer name to its corresponding layer integer ID.
• “subLayerInt2Str” converts a sub-layer integer ID to the corresponding name (String).
I.4.13 Other methods

One gives here a list of methods that do not fit in any category listed above.
I.4.13. OTHER METHODS 93
I.4.13.1 “new”
“new” method is used to create a new Result object.
I.4.13.2 “initialize”
“initialize” method initializes or clears a Result object.
I.4.13.3 “clone”
“clone” method returns a Copy of the Result object to which it is applied.
I.4.13.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.13.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.13.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.13.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.2 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.

Creation and initialization
new 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
renumberSubLayers I.5.3.2
removeLayers I.5.3.3
removeSubLayers I.5.3.4
Operators
+ I.5.4
95
96 CHAPTER I.5. THE “RESKEYLIST” CLASS

- 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:
• “extractLayers” returns an Array of String and integers corresponding to the layers that
are referenced in the ResKeyList object.
• “extractSubLayers” returns an Array of String and integers corresponding to the sub-

layers that are referenced in the ResKeyList object.
• “extractGroup” returns a Group object containing the elements and nodes that are refer-
enced in the ResKeyList object.
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.4. DYADIC OPERATORS 97
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.
• “+” operator returns the union of two ResKeyLists.
• “-” operator returns the difference of two ResKeyLists.
• “*” operator returns the intersection of two ResKeyLists.
• “/” operator: if x and y are two ResKeyLists, then x/y = (x+y)−(x∗y). (The operation
is equivalent to a logical “exclusive or” operation on the entities.)
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.
98 CHAPTER I.5. THE “RESKEYLIST” CLASS
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 ob-
ject. 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.9).
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:
• Method “Name” attribute getter returns a String containing the name of the ResKeyList.
This method corresponds to “Name” attribute.
• Method “Name=” attribute setter has one String argument and sets the name of the
ResKeyList. This method corresponds to “Name” attribute.
• Method “Size” attribute returns an integer corresponding to the number of keys stored in
the object. This method corresponds to “Size” read-only attribute.
• Method “to_s” is used for printing the ResKeyList object.

Chapter I.6
The “Post” module
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.

Manipulation of FeResPost standard output
openMsgOutputFile I.6.1
closeMsgOutputFile I.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
99
100 CHAPTER I.6. THE “POST” MODULE

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.10 IV.2.4.3 and chapter IV.4
Loading the HDF5 shared library
loadHdf5Library I.6.11
I.6.1 Manipulation of FeResPost standard output

Four methods of “Post” Module allow to manipulate the information, warning and error mes-
sages issue by FeResPost:
• “openMsgOutputFile” opens an output file and redirects the standard output used by
FeResPost to issue its messages. The method has up to two String arguments: the name
of the output file, and the opening mode ("w" for write and "w+" for append). The second
argument is optional. If omitted, "w" is considered by FeResPost.
• “closeMsgOutputFile” closes the output file and restore the standard output for FeRes-
Post messages.
I.6.2. MONADIC FUNCTIONS FOR NEW RESULT CREATION 101
• “writeAboutInformation” writes the FeResPost information message to standard output,

or corresponding output files. (Information contains among other things the version of
FeResPost and its date of compilation.)
• “writeMsgOutputLine” writes a line in the standard output stream. (The stream can of
course be a file.)
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, and does of the ruby
post-processing program.
I.6.2 Monadic functions for new Result creation

In section I.4.3, 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):
• y=Post.exp(x) is equivalent to “y=x.deriveScalToScal("exp")”.
• y=Post.log(x) is equivalent to “y=x.deriveScalToScal("log")”.
• y=Post.exp10(x) is equivalent “to y=x.deriveScalToScal("exp10")”.
• y=Post.log10(x) is equivalent “to y=x.deriveScalToScal("log10")”.
• y=Post.abs(x) is equivalent to “y=x.deriveScalToScal("abs")”,
“y=x.deriveVectorToOneScal("abs")” or “y=x.deriveTensorToOneScal("abs")”.
• y=Post.inv(x) is equivalent to “y=x.deriveScalToScal("inv")”.
• y=Post.sq(x) is equivalent to “y=x.deriveScalToScal("sq")”
or “y=x.deriveVectorToOneScal("sq")”.
• y=Post.sqrt(x) is equivalent to “y=x.deriveScalToScal("sqrt")”.
• y=Post.sgn(x) is equivalent to “y=x.deriveScalToScal("sgn")”.
I.6.3 Dyadic functions for new Result creation

In section I.4.3, 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):
• z=Post.pow(x,y) is generally equivalent to “z=x.deriveDyadic("pow",y)”. But the “pow”
method defined in “Post” module also allows to replace the first “x” operand by a Real
value. However, at least one of the two arguments must be a Result object.
• z=Post.atan2(x,y) is generally equivalent to “z=x.deriveDyadic("atan2",y)”. But the “atan2”
method defined in “Post” module also allows to replace the first “x” operand by a Real
value. However, at least one of the two arguments must be a Result object.
• z=Post.vectProduct(x,y) is generally equivalent to “z=x.deriveDyadic("vectProduct",y)”.

However the first argument can be replaced by a vector (Array of three real elements).
However, at least one of the two arguments must be a Result object.
• z=Post.sumVectProduct(x,y) is equivalent to “z=x.deriveDyadic("sumVectProduct",y)”.
Also other functions that have no correspondence in Result class methods can be used to define
new Results
• z=Post.min(x,y) returns a Result build by selecting the minimum values of x and y. The
method works with scalar, vectorial or tensorial results. Either x or y can be replaced by
a Real value.
• z=Post.max(x,y) returns a Result build by selecting the maximum values of x and y. The
method works with scalar, vectorial or tensorial results. Either x or y can be replaced by
a Real value.
• z=Post.cmp(x,y) returns a Result build by setting the corresponding values to -1 if x<y,

0 if x==y and 1 if x>y. Both results must be scalar. Either of the two Results can be
replaced by a real argument.
• z=Post.mergeKeepFirst(x,y) returns a Result build by merging the two arguments. When

a key is present in the two argument Results, the values extracted from the first Result
are kept.
• z=Post.merge(x,y) is identical to z=Post.mergeKeepFirst(x,y).
• z=Post.mergeKeepLast(x,y) returns a Result build by merging the two arguments. When

a key is present in the two argument Results, the values extracted from the second Result
are kept.
Most of the dyadic functions insert a pair “key-value” in the created Result only if the corre-
sponding 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:
• If first argument is a “Group” object, the second argument must also be a “Group” object.
• If first argument is a “ResKeyList” object, the second argument must also be a “ResKeyList”
object.
I.6.5. READING AND WRITING OF GROUPS 103
• If either first or second argument is a “Result” object, then the possible arguments are
those of the corresponding operators in “Result” class (section I.4.6).
The first argument can be a “Result” object, a real value, a complex value, an Array of
three real values or three complex values, or a 3 × 3 matrix of real elements.
The second argument can be a “Result” object, a real value, a complex value, an Array
of three real values, or a 3 × 3 matrix of real elements.
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:
• “setVerbosityLevel” has one “level” integer argument and is used to set the level of ver-
bosity.
• “getVerbosityLevel” returns an integer corresponding to the verbosity level.
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 read-
ing 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” Mod-
ule:
• “convertIdfierToString” has one CLA identifier argument and returns a String.
• “convertStringToIdfier” performs the reverse operation.

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
I.6.9. RANDOM OR PSD INTEGRATION METHODS 105
is necessary to understand what the method does. Reader is referred to [Sof10] for more infor-
mation.
The purpose of a random calculation is to assess structural response as power spectral den-
sity 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 |2 Sa .
In previous expression:
• Hja is the structure transfert function at location j for an excitation a. This transfert func-
tion depends on the frequency and is supposed to be obtained by computing a frequency
response analysis with Nastran with a unit excitation.
• Sa is the input PSD depending on the kind of excitation and unit system used in the finite
element analysis, its units are g 2 /Hz, (m/s2 )2 /Hz, P a2 /Hz... The input PSD is scalar.
• Sja is the output PSD at location j. Depending on the kind of quantity that is calculated,
the output PSD units may differ: m2 /Hz for displacements, g 2 /Hz for accelerations,
P a2 /Hz for stresses, N 2 /Hz for forces... FeResPost considers that the output PSD can
be scalar, vectorial or tensorial depending on the kind of quantity that is calculated.
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:
sZ
∞
uj = Sja (f )df .
0
Practically, FeResPost calculates the integral on a finite range of frequencies:

sZ
fmax
uj = Sja (f )df .
fmin
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:
Z ∞ N
X −1 Z fi+1
Sja (f )df ≈ Sja (f )df.
0 i=1 fi
Assuming a log-log dependence of Sja (f ) between fi and fi+1 , one has
Sja (fi ) α
Sja (f ) = f with fi < f < fi+1 ,
fiα
in which
log (Sja (fi+1 )/Sja (fi ))
α= .
log (fi+1 /fi )
The integral in range [fi , fi+1 ] is then calculated by:
• If Sja (fi+1 ) = 0 or Sja (fi ) = 0:

Z fi+1
Sja (f )df = 0 .
fi
• If Sja (fi+1 ) 6= 0 and Sja (fi ) 6= 0:


Z fi+1  fi Sja (fi ) log (fi+1 /fi ) if α = −1 ,
Sja (f )df = Sja (fi )
fi+1
α
fi  f i+1 fi
− f i if α 6= −1 .
1+α
If one assumes that function Sja (f ) varies linearly between fi and fi+1 , then the integral in
range [fi , fi+1 ] becomes simply:
fi+1
(Sja (fi ) + Sja (f i + 1)) (fi+1 − fi )
Z
Sja (f )df = .
fi 2
Note that in Nastran, the assumption of log-log or linear interpolation on each frequency inter-
val is managed by the option RMSINT.
“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=calcRandomResponse(bOutputPsd,bOutputIntPsd,bOutputRMS,
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 trans-
fert 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.
I.6.10. PREDEFINED CRITERIA 107
6. “integType” is a String that specifies the interpolation and integration rule on fre-
quency 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 cor-

responding 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 ob-
ject. 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:
• “CritName”, a String argument that specifies which criterion is required.
• “InputValues”, an Array containing the arguments for the calculation. (Each argument
may be a DataBase, a String an integer, a real value, a Boolean Value, a Result object, a
Group object, ...)
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:
• The predefined criteria give a lower level access to the FeResPost object at C++ level.
This allows to perform operations on the objects that could be tricky with higher level
language access, and this allows optimizations of the computations. (A marvelous exam-
ple of optimization is presented in section IV.2.4.3.)
• As the predefined criteria are provided in a compiled shared library, it becomes possible
to hide the immplementation to the final user of FeResPost.
• Once a predefined criterion is programmed and debugged, it is easier to guaranty that the
same calculation is performed with ruby extension, COM component or .NET assembly.
Of course, the adoption of pre-defined criteria has also some disadvantages:
• The programming of a criterion is C++ can be difficult and errors difficult to track.
• The addition of a criterion, or the modification of an existing criterion requires the re-
compilation of FeResPost library.
• Also, if a user has developed is own pre-defined criterion, a recompilation of each new
version of FeResPost is necessary to include his criterion.
So far, only a limited number of predefined criteria have been included in FeResPost. They
are presented in Appendix X.D.
I.6.11 Loading HDF5 library

Method “loadHdf5Library” is used to load the HDF5 shared library. It is simply used as fol-
lows:
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.
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
109
110 CHAPTER I.7. ARGUMENTS COERCION FOR “RESULT” CLASS OPERATORS
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)
return Post.opSub(self,second)
else
return self._FeFesPost_old_opSub(second)
end
end
def *(second)
return Post.opMul(self,second)
else
return self._FeFesPost_old_opMul(second)
end
end
def /(second)
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
111
Chapter II.0
Introduction
Four classes specific to Classical Laminate Analysis calculations have been defined in FeRes-
Post module:
• The “ClaDb” class allows the definition of composite databases used to store the defi-
nition of composite materials, laminates and loadings. This class is presented in Chap-
ter II.2.
• The “ClaMat” class allows the definition and manipulation of materials. This class is
presented in Chapter II.3.
• The “ClaLam” class allows the definition and manipulation of laminates. This class is
presented in Chapter II.4.
• The “ClaLoad” class allows the definition and manipulation of loadings to be applied to
laminates. This class is presented in Chapter II.5.
Throughout the composite manual pages, the concept of identifier is often used. An identifier
can be:
• An Integer,
• A String,
• Or an Array of two elements (an integer and a String).

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 com-
patible 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")
113
114 INTRODUCTION
...
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:
• To produce layered results automatically, using the definition of laminates and, for ex-
ample, Results corresponding to in-plane forces and bending moments in 2D elements,
• To calculate the corresponding failure indices, strength ratios and reserve factors, all
these being instances of the FeResPost::Result class.
• ...
The composite capabilities programming is based on the Classical Laminate Analysis as pre-
sented 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. There-
fore, 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 [Gay97, Pal99]. 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:
• Section II.1.1 presents the conventions used for the numbering of plies, orientations of
plies, laminate axes...
• Section II.1.2 summarizes the calculation rules for the rotation of tensors and vectors.
Some of the notions and notations used in the rest of the Chapter are introduced in the
section.
• The constitutive equations describing ply materials behavior are given in section II.1.3.
One also introduces several notations that are used in the rest of the Chapter and one
presents the calculation rules that must be used to perform material property rotations.
• In section II.1.5, the calculation of laminate in-plane and flexural properties is described.
Note that the influences of temperature and moisture are not considered in the section.
• Section II.1.6 is devoted to the out-of-plane shear behavior of laminates. The explanation
is more detailed than what is given in section II.1.5. Here again, temperature and moisture
effects are not considered.
• Section II.1.7 is devoted to the influence of temperature and moisture. One considers the
influence of these loading contributions on the in-plane, flexural and out-of-plane shear
laminate behavior and load response.
• Section II.1.8 presents the calculation of load response of laminates submitted to a load-
ing. Among other-things, one explains how the ply stresses and strains are calculated.
115
116 CHAPTER II.1. THEORETICAL BACKGROUND
• Section II.1.10 is devoted to the calculation criteria available in FeResPost.

• Section II.1.13 is devoted to a presentation of the units of many of the quantities intro-
duced in this Chapter.
II.1.1 Conventions
Figure II.1.1 represents some of the conventions used for the definition of laminate in FeRes-
Post. 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 = +t/2 and bottom surface
at z0 = −t/2. (The plies are numbered from 1 to N .)
z6 (top)
z0 (bottom)
z
y 6
top 5
4
x 3
2
bottom 1
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.
z=3 2
x +ξ 1
Figure II.1.2: Conventions for the orientation of plies in the laminate.)

II.1.2. ROTATION IN XY PLANE AND ALGEBRAIC NOTATIONS 117
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.
y 2
Figure II.1.3: Rotation of angle θ around the origin in O12 plane.
Rotation of base vectors

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

ex cos θ sin θ e1
= · .
ey − sin θ cos θ 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 c s 0 e1
 ey  =  −s c 0  ·  e2  . (II.1.1)
ez 0 0 1 e3
The inverse relation corresponds to a rotation of angle −θ and is obtained by changing the signs
of the sinuses in the rotation matrix:
     
e1 c −s 0 ex
 e 2  =  s c 0  ·  ey  . (II.1.2)
e3 0 0 1 ez
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:      
Vx c s 0 V1
 Vy  =  −s c 0  ·  V2  . (II.1.3)
Vz 0 0 1 V3
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 c s 0 σ11 σ12 σ31 c −s 0
 σxy σyy σyz  =  −s c 0  ·  σ12 σ22 σ23  ·  s c 0  . (II.1.4)
σzx σyz σzz 0 0 1 σ31 σ23 σ33 0 0 1
Matricial notations
As the Cauchy stress tensor is symmetric, expression (II.1.4) is more conveniently written in a
matricial form as follows:
  2
s2 0 0 0
   
σxx c 2cs σ11
 σyy   s2 c2 0 0 0 −2cs    σ22 
 
  
 σzz   0 0 1 0 0 0  ·  σ33  .
  
 = (II.1.5)
 τyz   0 0 0 c −s 0   τ23 
     
 τzx   0 0 0 s c 0   τ13 
τxy −cs cs 0 0 0 c2 − s2 τ12
The same expression applies to the components of the strain tensor, which is also symmetric:
  2
s2 0 0 0
   
xx c 2cs 11
 yy   s2 c2 0 0 0 −2cs    22 
 
  
 zz   0 0 1 0 0 0   33 
 yz  =  0
·
  23  .
   
   0 0 c −s 0   
 zx   0 0 0 s c 0   13 
xy −cs cs 0 0 0 c2 − s2 12
However, unfortunately, the classical laminate analysis is universally written using angular
shear components for the strain tensor:
γij = 2ij (i 6= j) .
Using the angular components, the matricial expression to be used for the rotation becomes:
c2 s2 0 0 0
     
xx cs 11
 yy   s2 c2 0 0 0 −cs    22 
 
  
 zz   0 0 1 0 0 0  ·  33  .
  
 = (II.1.6)
 γyz   0 0 0 c −s 0   γ23 
     
 γzx   0 0 0 s c 0   γ13 
2 2
γxy −2cs 2cs 0 0 0 c − s γ12
An interesting aspect of the transformations (II.1.5) and (II.1.6) is that one can apply the trans-
formation separately on sub-groups of components:
• For the in-plane components, one uses the following transformations:
  2
s2
   
σxx c 2cs σ11
 σyy  =  s2 c2 −2cs  ·  σ22  , (II.1.7)
τxy −cs cs c2 − s2 τ12
II.1.2. ROTATION IN XY PLANE AND ALGEBRAIC NOTATIONS 119
c2 s2
     
xx cs 11
 yy  =  s2 c2 −cs  ·  22  . (II.1.8)
γxy −2cs 2cs c − s2
2
γ12
• For the out of plane shear, the transformation is:

γzx c s γ13
= · . (II.1.9)
γyz −s c γ23
The relation has been written for the out-of-plane shear components of strain tensor. Note
however, that the relation is the same for the out-of-plane shear components of Cauchy
stress tensor.
• The zz or 33 component is left unchanged.

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;
  2
s2
   
σ11 c −2cs σxx
 σ22  =  s2 c2 2cs  ·  σyy  , (II.1.10)
2 2
τ12 cs −cs c − s τxy
  2
s2
   
11 c −cs xx
 22  =  s2 c2 cs  ·  yy  (II.1.11)
2 2
γ12 2cs −2cs c − s γxy
Introduction of a short notation

In order to simplify the notations, one introduces the following notations:
 2
s2

c −2cs
[T+ ](θ) =  s2 c2 2cs  , (II.1.12)
cs −cs c − s2 2
 2
s2

c 2cs
[T− ](θ) =  s2 c2 −2cs  , (II.1.13)
−cs cs c2 − s2
2 2
 
0 c s cs
T+ (θ) =  s2 c2 −cs  , (II.1.14)
−2cs 2cs c − s2 2
 2 2

0 c s −cs
T− (θ) =  s2 c2 cs  , (II.1.15)
2cs −2cs c − s2 2

c −s
[S− ](θ) = , (II.1.16)
s c

c s
[S+ ](θ) = . (II.1.17)
−s c
These matrices are not independent. For example:
−1
[T− ](θ) = [T+ ](θ) = [T+ ](−θ) ,
−1
[T− ](θ) = [T+ ](θ) = [T+ ](−θ) ,
T
T+0

(θ)
= [T+ ](θ) ,
T −1
[S− ](θ) = [S+ ](θ) = [S+ ](θ) = [S+ ](−θ) .
The transformations of the components of strain tensor (II.1.8) and stress tensor (II.1.10) are
then written:
{}xy = T+0 (θ) · {}12 ,

(II.1.18)
{σ}12 = [T+ ](θ) · {σ}xy , (II.1.19)
{}12 = T−0 (θ) · {}xy ,

(II.1.20)
{σ}xy = [T− ](θ) · {σ}12 . (II.1.21)
Similarly, for the out-of-plane shear stresses and strains one writes the following relations:
{γs }xy = [S+ ](θ) · {γs }12 , (II.1.22)
{τs }xy = [S+ ](θ) · {τs }12 , (II.1.23)
{γs }12 = [S− ](θ) · {γs }xy , (II.1.24)
{τs }12 = [S− ](θ) · {τs }xy . (II.1.25)
II.1.3 Materials and plies

One summarizes in this section a few results that are commonly found in composite literature.
II.1.3. MATERIALS AND PLIES 121
II.1.3.1 Plies
Each ply is defined by:
• One material (constitutive equation),
• One thickness,
• One orientation wrt laminate axes,
• Its allowables.
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 C1111 C1122 C1133 C1123 C1131 C1112 11
 σ22   C2211 C2222 C2233 C2223 C2231 C2212   22 
     
 σ33   C3311 C3322 C3333 C3323 C3331 C3312   33 
 τ23   C2311 C2322 C2333 C2323 C2331 C2312   γ23  .
 = ·  (II.1.26)
     
 τ13   C1311 C1322 C1333 C1323 C1331 C1312   γ31 
τ12 C1211 C1222 C1233 C1223 C1231 C1212 γ12
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 inde-
pendent coefficients. [Cijkl ] is the stiffness matrix of the material.
Equation (II.1.26)can be reversed as follows:
     
11 c1111 c1122 c1133 c1123 c1131 c1112 σ11

 22  
  c2211 c2222 c2233 c2223 c2231 c2212  
  σ22 


 33  
= c3311 c3322 c3333 c3323 c3331 c3312  
· σ33 


 γ23  
  c2311 c2322 c2333 c2323 c2331 c2312  
  τ23 

 γ31   c1311 c1322 c1333 c1323 c1331 c1312   τ13 
γ12 c1211 c1222 c1233 c1223 c1231 c1212 τ12
   
α11 β11

 α22 


 β22 

 α33   β33 
+ ∆T   + ∆H   . (II.1.27)

 α23 


 β23 

 α13   β13 
α12 β12
In expression (II.1.27), one added the thermo-elastic and moisture expansion terms in previous
expression. They are characterized by CTE and CME tensors noted {αkl } and {βkl } respec-
tively. 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 a fabric, 1 corresponds generally to the warp direction, and 2 to the weft direction.
The corresponding tensile/compressive moduli are noted E1 and E2 respectively. E3
denotes the out-of-plane tensile/compressive modulus.
• Correspondingly, one defines shear moduli noted G12 , G23 and G13 .
• In general six Poisson coefficients can be defined: ν12 , ν23 , ν31 , ν21 , ν32 , ν13 . However,
these coefficients are not independent. The relations
ν21 ν12
= ,
E2 E1
ν31 ν13
= ,
E3 E1
ν32 ν23
=
E3 E2
allow to eliminate the coefficients ν21 , ν32 and ν13 so that only the three Poisson coeffi-
cients ν12 , ν23 and ν13 have to be introduced when defining a material.
• The constitutive equation of an orthotropic material is given by

    
11 1/E1 −ν21 /E2 −ν31 /E3 0 0 0 σ11

 22  
  −ν12 /E1 1/E2 −ν32 /E3 0 0 0    σ22 
 

 33  
= −ν13 /E1 −ν23 /E2 1/E3 0 0 0  · σ33 
 

 γ23  
  0 0 0 1/G23 0 0    τ23 
 
 γ13   0 0 0 0 1/G13 0   τ13 
γ12 0 0 0 0 0 1/G12 τ12
   
α11 β11
 α22   β22 
   
 α33   β33 
+ ∆T  α23  + ∆H  β23  . (II.1.28)
  
   
 α13   β13 
α12 β12
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 = ν .
II.1.3. MATERIALS AND PLIES 123
E, G and ν satisfy the following relation:
E − 2G(1 + ν) = 0 .
Finally, one introduces shorter notations that allow to rewrite expressions (II.1.26) and
(II.1.27) respectively as follows:
{} = [c] · {σ} + ∆T {α} + ∆H {β} , (II.1.29)
{σ} = [C] · {} − ∆T [C] · {α} − ∆H [C] · {β} . (II.1.30)

One introduces also the “Mechanical Strain Tensor” estimated as follows:
Mech
= [c] · {σ} . (II.1.31)
This new strain tensor differs from the one defined by (II.1.29) 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 (II.1.28) reduces to:
         
11 c1111 c1122 c1112 σ11 α11 β11
 22  =  c2211 c2222 c2212  ·  σ22  + ∆T  α22  + ∆H  β22  . (II.1.32)
γ12 c1211 c1222 c1212 τ12 α12 β12
The indices in this notation are integers and indicate that the corresponding properties are given
in ply coordinate system. The equation (II.1.32) is written more shortly as follows:
{}ply = [c]ply · {σ}ply + ∆T {α}ply + ∆H {β}ply . (II.1.33)
One introduces in (II.1.33) 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.29). 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.33) is noted:
{σ}ply = [C]ply · {}ply − ∆T [C]ply · {α}ply − ∆H [C]ply · {β}ply . (II.1.34)
In (II.1.34) one introduces the in-plane stiffness matrix [C]ply = [c]−1

ply .
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.33) and (II.1.34) are expressed in the laminate coordinate system as follows:
{}lam = T+0 (−ξ) · [c]ply · [T+ ](−ξ) · {σ}lam + ∆T T+0 (−ξ) · {α}ply + ∆H T+0 (−ξ) · {β}ply ,

{σ}lam = [T− ](−ξ) · [C]ply · T−0 (−ξ) · {}lam

− ∆T [T− ](−ξ) · [C]ply · {α}ply − ∆H [T− ](−ξ) · [C]ply · {β}ply .
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+0 (−ξ) · [c]ply · [T+ ](−ξ) ,

(II.1.35)
{α}lam = T+0 (−ξ) · {α}ply ,

(II.1.36)
{β}lam = T+0 (−ξ) · {β}ply ,

(II.1.37)
[C]lam = [T− ](−ξ) · [C]ply · T−0 (−ξ) ,

(II.1.38)
[C]lam · {α}lam = [T− ](−ξ) · [C]ply · {α}ply , (II.1.39)
[C]lam · {β}lam = [T− ](−ξ) · [C]ply · {β}ply . (II.1.40)
0is transformed as in (II.1.35) or a vector as in (II.1.36), one says that they are
When a matrix
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 con-
stitutive equations are written as follows:
{τs }ply = [g]ply · {γs }ply − ∆T [g]ply · {αs }ply − ∆H [g]ply · {βs }ply , (II.1.41)
{γs }ply = g −1 ply · {τs }ply + ∆T {αs }ply + ∆H {βs }ply .

(II.1.42)
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 ,
II.1.4. THICKNESS AND MASS OF LAMINATE 125
{τ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.41) as follows:
[S+ ](ξ) · {τs }lam = [g]ply · [S+ ](ξ) · {γs }lam

− ∆T [g]ply · [S+ ](ξ) · {αs }lam − ∆H [g]ply · [S+ ](ξ) · {βs }lam ,
{τs }lam = [S+ ](−ξ) · [g]ply · [S+ ](ξ) · {γs }lam

− ∆T [S+ ](−ξ) · [g]ply · [S+ ](ξ) · {αs }lam
− ∆H [S+ ](−ξ) · [g]ply · [S+ ](ξ) · {βs }lam ,
{τ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 = [S+ ](−ξ) · g −1 ply · [S+ ](ξ) .

lam
II.1.4 Thickness and mass of laminate

The total laminate thickness is the sum of the thickness of each of its plies:
N
X
tlam = ek .
k=1
Correspondingly the surfacic mass is given by:
N
X
smlam = ρek .
k=1
And the laminate average density is:
ρlam = smlam /tlam .

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:
• In-plane normal forces tensor:
   
Nxx Z h/2 σxx
{N }lam =  Nyy  =  σyy  dz .
Nxy −h/2 τxy
• Bending moment tensor:

   
Mxx Z h/2 σxx
{M }lam =  Myy  = z  σyy  dz .
Mxy −h/2 τxy
• Average deformation tensor:

0
 0     
xx
Z h/2 xx u ,x
0 1
lam =  0yy  =  yy  dz =  0
v,y  .
0 h −h/2 0 0
γxy γxy u,y + v,x
• Curvature tensor:
     0 
κxx Z h/2 xx w,xx
12 0
{κ}lam =  κyy  = 3 z  yy  dz =  w,yy  . (II.1.43)
h −h/2 0
κxy γxy 2w,xy
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:
II.1.5. IN-PLANE AND FLEXURAL LAMINATE BEHAVIOR 127
• Matrix [A]lam is a 3 × 3 matrix corresponding to the in-plane stiffness of laminate. Its

components are calculated as follows:
Z h/2 N
X
[A]lam = [C]lam (z) dz = [Ck ]lam ek .
−h/2 k=1
• Matrix [D]lam is a 3 × 3 matrix corresponding to the flexural stiffness of laminate. Its

components are calculated as follows:
h/2 N
zk3 − zk−1
3
Z X
2
[D]lam = z [C]lam (z) dz = [Ck ]lam .
−h/2 k=1
3
• Matrix [B]lam is a 3 × 3 matrix corresponding to the coupling between flexural and in-
plane behavior of the laminate. It is calculated as follows:
h/2 N
zk2 − zk−1
2
Z X
[B]lam = z [C]lam (z) dz = [Ck ]lam .
−h/2 k=1
2
All the new matrices and vectors are obtained by summation of the ply contributions. In or-
der to obtain the ply stiffness matrix in laminate axes [C]klam and the ply thermo-elastic CTE
coefficients in thermo-elastic axes {α}klam , one uses the transformations (II.1.36) and (II.1.38)
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:
−1
[a]lam [b]lam [A]lam [B]lam
= , (II.1.44)
[b]T
lam [d]lam
[B]lam [D]lam
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. This is done as follows (we follow the expressions presented in [Pal99]):
• One calculates the normalized in-plane, coupling and flexural stiffness and compliance
matrices:
1
[A∗ ]lam = [A]lam , [a∗ ]lam = h [a]lam ,
h
2 h2
[B ∗ ]lam = 2 [B]lam , [b∗ ]lam = [b] ,
h 2 lam
12 h3
[D∗ ]lam = 3 [D]lam , [d∗ ]lam = [d] .
h 12 lam
• Equivalent in-plane moduli and Poisson ratios are then given by:
1 1 1
Exx = , Eyy = , Gxy = ,
a∗11 a∗22 a∗33
a∗33 a∗33
νxy = − , νyx = − .
a∗11 a∗22
These moduli correspond to a case for which the laminate is free to curve under in-plane
loading. This can be the case when there is coupling of in-plane and flexural laminate
behavior. (Matrix [B]lam is not zero.) The laminate in-plane engineering constants with
suppressed curvature are calculated as follows:
[ã∗ ]lam = [A∗ ]−1

lam ,
κ=0 1 κ=0 1 1
Exx = , Eyy = , Gκ=0
xy = ,
ã∗11 ã∗22 ã∗33
κ=0 ã∗33 κ=0 ã∗33
νxy =− , νyx =− .
ã∗11 ã∗22
• Similarly, equivalent flexural moduli and Poisson ratios can be calculated. One notes the
following relation:
 
1/EI 11 1/EI 12 1/EI 13
([D]lam )−1 =  1/EI 21 1/EI 22 1/EI 23  .
1/EI 31 1/EI 32 1/EI 33
If there is no coupling between laminate flexural and membrane properties

 
1/EI 11 1/EI 12 1/EI 13
([D]lam )−1 = [d]lam =  1/EI 21 1/EI 22 1/EI 23  .
1/EI 31 1/EI 32 1/EI 33
Generally, the “no-coupling” behavior is assumed (see for example section II.1.6). There-
fore, one writes simply:
f 1 f 1 1
Exx = , Eyy = , Gfxy = ,
d∗11 d∗22 d∗33
f d∗33 f d∗33
νxy =− , νyx =− .
d∗11 d∗22
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 calcula-
tion that takes xy and yz components of the out-of-plane shear stress into account at the same
time.
II.1.6. OUT-OF-PLANE SHEAR OF LAMINATE 129
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 ∂σxx
+ =0. (II.1.45)
∂z ∂x
Similarly, the equilibrium of a portion dx of the full laminate is given globally by the expres-
sion:
∂Mxx
Qxz − =0. (II.1.46)
∂x
Qxz Mxx
σxx σxx + dσxx
τxz
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 lami-
nates 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.47)
τxy,x + σyy,y + τyz,z = 0 . (II.1.48)

Correspondingly, a global equilibrium is expressed by the two equations:
Mxx,x + Mxy,y = Qxz , (II.1.49)
Mxy,x + Myy,y = Qyz . (II.1.50)

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. There-
fore, 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.51)
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.47) to (II.1.50), 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.49) and (II.1.50), the out-of-plane shear is related to
the gradient of bending moment. One derives equation (II.1.51) wrt to x and y:
   
 σxx,x (x, y, z)   Mxx,x (x, y) 
σyy,x (x, y, z) = [C]lam (z) · ([b]lam + z [d]lam ) · Myy,x (x, y) ,
τxy,x (x, y, z) lam Mxy,x (x, y) lam
   
   
 σxx,y (x, y, z)   Mxx,y (x, y) 
σyy,y (x, y, z) = [C]lam (z) · ([b]lam + z [d]lam ) · Myy,y (x, y) .
τxy,y (x, y, z) lam 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) 
 0 0 0 
 M xx,x 

σ (z)  [F ] (z) 0 0 0   M
  
yy,x yy,x
   

 
  lam  
 

τxy,x (z) 0 0 0 M
   
xy,x
 
=   Mxx,y  .
· (II.1.52)

 σxx,y (z) 
 0 0 0
   
σyy,y (z)   0 0 0 [F ] (z)   Myy,y 

   

 
 lam 
 

τxy,y (z) lam 0 0 0 Mxy,y lam
   
II.1.6.3 Out-of-plane shear stress partial derivative equations

Note that the global equilibrium equation (II.1.49) and (II.1.50) 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.52).
Actually, one can do better than that. The local equilibrium equations (II.1.47) and (II.1.48)
are rewritten as follows:
 

 σxx,x (z) 
σ (z)
 
yy,x

 

 
τxz,z (z) −1 0 0 0 0 −1 τxy,x (z)
 
= · . (II.1.53)
τyz,z (z) lam 0 0 −1 0 −1 0 
 σxx,y (z) 
σ (z) 
 
 yy,y

 
 
τxy,y (z) lam

Similarly, one writes:

   

 Mxx,x 
 1 0 0 0  
Myy,x 0 0 0 0 Mxx,x

 
   

 
    

Mxy,x 0 1 0 0 Mxy,x
     
= · . (II.1.54)

 Mxx,y 


 0 0 0 0  
  Myy,y 

M 0 0 1 0 Mxy,y
    
 yy,y
  
lam

 

Mxy,y 0 0 0 1

lam
The substitution of (II.1.52) and (II.1.54) in (II.1.53) leads to the following expression:

τxz,z (z) −1 0 0 0 0 −1
= ·
τyz,z (z) lam 0 0 −1 0 −1 0
   
0 0 0 1 0 0 0  
 [F ] (z) 0 0 0   0 0 0 0   Mxx,x 
 lam     
 0 0 0   0 1 0 0   Mxy,x 
·
  0 0 0 0  ·  Myy,y  . (II.1.55)
 
 0 0 0
     
 0 0 0 [F ] (z)   0 0 1 0   Mxy,y 
lam lam
0 0 0 0 0 0 1
One would like to eliminate the four x and y partial derivative of bending moment tensor
components in the previous expression. For this, one uses the global equilibrium equations
(II.1.49) and (II.1.50). This leaves some arbitrary choice in the determination of dependence
wrt out-of-plane shear. For example:
Mxx,x = µx Qxz ,
Mxy,y = (1 − µx )Qxz ,
Myy,y = µy Qyz ,
Mxy,x = (1 − µy )Qyz .
   

 Mxx,x 
 µx 0
Mxy,x 0 (1 − µx )  Qxz
  
=

 · Qyz
 ,

 Myy,y 
 0 µy lam
Mxy,y (1 − µy ) 0
 
lam
   

 Mxx,x 
 1 0 0 0  
Myy,x 0 0 0 0 µx 0

 
  

 
  
Mxy,x 0 1 0 0 0 (1 − µx ) Qxz
     
= · · ,

 Mxx,y 


 0 0 0 0  
 0 µy  Qyz lam
M 0 0 1 0 (1 − µy ) 0
 
 yy,y

 
  
 
Mxy,y 0 0 0 1

lam
 
µx 0

 0 0 

 0 (1 − µx )  · Qxz

= .

 0 0 
 Qyz lam
 0 µy 
(1 − µy ) 0
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:
   
0 0 0 µx 0
 [F ]lam (z)
 0 0 0  
  0 0 

1 0 0 0 0 1  0 0 0   0 (1 − µx ) 
[X]lam (z) = − · · .
0 0 1 0 1 0  0 0 0
 
  0 0 

 0 0 0 [F ]lam (z)   0 µy 
0 0 0 (1 − µy ) 0
The choice µx = µy = 1/2 gives more symmetry to the relation between {τ }lam (z) and
{Q}lam (z). This choice leads to:
   
0 0 0 1 0
 [F ]lam (z)
 0 0 0   0  0 
1

1 0 0 0 0 1  0 0 0  · 0
 1 
[X]lam (z) = − ·  .
2 0 0 1 0 1 0  0 0 0

  0
  0 

 0 0 0 [F ]lam (z)   0 1 
0 0 0 1 0
The choice µx = µy = 1 is the default choice in FeResPost. The same choice seems to
have been done in other software, like ESAComp. In the rest of the document, the following
notations are used:
1 0 0 0 0 1
[P1 ] = , (II.1.56)
0 0 1 0 1 0
 
µx 0

 0 0 

 0 (1 − µx ) 
[P2 (µx , µy )] =   . (II.1.57)

 0 0 

 0 µy 
(1 − µy ) 0
[X]lam (z) is a 2 × 2 matrix that relates the out-of-plane shear stress components partial deriva-
tives wrt z to the out-of-plane shear force components:

τxz,z (z) Qxz
= [X]lam (z) · . (II.1.58)
τyz,z (z) lam
Qyz lam
Note that by replacing the partial derivative of bending moments by out-of-plane shear force
components, one has done an approximation that involves much arbitrariness. Actually, Ex-
pression (II.1.55) shows that out-of-plane shear stresses in the laminate are related to partial
derivative of bending moments, but not directly to out-of-plane shear force components. The
approximations that have been done allow us to define a theory that is more in line with what
is usually presented in the literature.
Its main advantage is that the decoupling between in-plane and flexural load response on
one side and out-of-plane shear response on the other side can be completed. Moreover, esti-
mates of the partial derivatives of bending moments are not always available. For example, no
finite element results corresponding to these unknown are commonly available.
Its main disadvantage is that the laminate out-of-plane shear equations lose their objectivity
wrt rotations around axis z as illustrated by the example described in section IV.5.5. This
example also allows to estimate the effects of the approximation on the precision of results
given by the theory.
The matrix [X]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:
Xk (z) = X0k lam + z X1k lam ,

lam
in which the components of the two matrices X0k lam and X1k lam are constant. Similarly one

can write a polynomial expression for [F ]lam (z) if one splits the definition by plies:
Fk
k
lam
(z) = C lam · ([b]lam + z [d]lam ) ,
= C k lam · [b]lam + C k lam · [d]lam z ,

= F0k lam + F1k lam z .

Of course, one has the two relations:
 
0 0 0
k

 F0
 lam
0 0 0 

0 0 0 
X0k

= − [P1 ] · 
  · [P2 (µx , µy )] ,
 0 0 0
lam 
k 
 0 0 0 F0 
lam
0 0 0
 
0 0 0
k

 F1
 lam
0 0 0  
0 0 0 
X1k

lam
= − [P1 ] · 
 0 0 0
 · [P2 (µx , µy )] .

 k 
 0 0 0 F1 lam 
0 0 0
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.58)
along the thickness. This leads to the following expression:
Z z
τxz (z) Qxz τxz (z0 )
= [X]lam (z) dz · + .
τyz (z) lam z0 Qyz lam τ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:
Z z
τxz (z) Qxz
= [X]lam (z) dz · ,
τyz (z) lam z0 Qyz lam

Qxz
= [Y ]lam (z) · , (II.1.59)
Qyz lam
where a new matrix has been introduced:
Z z
[Y ]lam (z) = [X]lam (z) dz .
z0
An explicit expression of the integrated matrix is calculated ply-by-ply, from bottom layer to
top layer. If zk−1 ≤ z ≤ zk :
[Y ]lam (z) = Y k lam (z) ,

Z z
k
= X lam (z) dz ,
z0
Z z
k k
= Y lam (zk−1 ) + X lam (z) dz ,
zk−1
Z z
k k
X0 lam + z X1k lam dz ,

= Y lam (zk−1 ) +
zk−1
z 2 − zk−1
2
= Y k lam (zk−1 ) + X0k lam (z − zk−1 ) + X1k lam

,
2
= Y0 lam + Y1 lam z + Y2 lam z 2 .
k k k
(II.1.60)
In expression (II.1.60), one introduced new symbols that are calculated as follows:
2
zk−1
Y0k lam k
X0k lam zk−1 X1k lam

= Y (zk−1 ) − − ,
lam 2
Y1k
= X0k lam ,

lam
k
k X1 lam
Y2 lam = .
2
Note that the expression above involve the a priori unknown quantity Y k lam (zk−1 ). To cal-

culate this expression, one uses the continuity of Y k lam (z) across ply interfaces:

k
Y lam (zk−1 ) = Y k−1 lam (zk−1 ) ,

This relation corresponds to the continuity of out-of-plane shear stress at ply interfaces. One
develops the relation as follows.
k zk−1 2
Y0k
k−1 k
lam
= Y lam
(z k−1 ) − X 0 lam z k−1 − X 1 lam ,
2
k−1 k−1 k−1 2
k zk−1
2
k
= Y0 lam
+ Y1 z
lam k−1
+ Y2 z
lam k−1
− X0 lam zk−1 − X1 lam ,
k ! 2
X1 lam 2
= Y0k−1 lam + Y1k−1 lam − X0k lam zk−1 + Y2k−1 lam −

zk−1 .
2
(II.1.61)
The last line of this development allows to calculate recursively the components of Y0k lam

from bottom ply to top ply. For bottom ply, the condition τxz (z0 ) = τyz (z0 ) = 0 leads to the
following expressions:
1
Y lam (z0 ) = Y01 lam + Y11 lam z0 + Y21 lam z02 = 0 .

1
Y0 lam = − Y11 lam z0 − Y21 lam z02 .

Then, it becomes possible to calculate recursively the [Y0i ]lam matrices.

One checks easily that the condition τxz (z0 ) = τyz (z0 ) = 0 ensures also that τxz (zN ) =
τyz (zN ) = 0. Indeed, one has:
Z zN
[Y ]lam (zN ) = [X]lam (z) dz ,
z0
 
0 0 0
Z zN  [F ]lam (z) 0 0 0 
 
 0 0 0 
= − [P1 ] · 
 0 0 0
 dz · [P2 (µx , µy )] ,

z0  
 0 0 0 [F ] (z) 
lam
0 0 0
 
R zN 0 0 0
 z0 [F ]lam (z) dz
 0 0 0 

 0 0 0 
= − [P1 ] · 
  · [P2 (µx , µy )] .
 0 0 0 R zN


 0 0 0 z0
[F ]lam (z) dz 
0 0 0
The last line of previous equation contains twice the integral of [F ]lam (z) along the laminate
thickness. One develops this integral as follows:
Z zN Z zN
[F ]lam (z) dz = [C]lam (z) · ([b]lam + z [d]lam ) dz ,
z0 z0
Z z N Z zN
= [C]lam (z) dz · [b]lam + z [C]lam (z) dz · [d]lam ,
z0 z0
= [A]lam · [b]lam + [B]lam · [d]lam .
On the other hand, equation (II.1.44) allows to write:
[A] · [a] + [B] · [b]T [A] · [b] + [B] · [d]

[A] [B] [a] [b]
· = ,
[B] [D] [b]T [d] [B] · [a] + [D] · [b]T [B] · [b] + [D] · [d]

[I] [0]
= .
[0] [I]
(The “lam” subscript has been omitted for shortness 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:
[Y ]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.59). The out-of-plane shear stresses depend only on out-of-plane
shear forces and ply in-plane material properties. One shows in section II.1.6.5 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 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) −1 τxz (z)
= [g]lam (z) · .
γyz (z) lam τyz (z) lam
To this relation corresponds a relation between the average out-of-plane shear strains and the
out-of-plane shear force:

Γxz −1 Qxz
= [G]lam · .
Γyz lam Qyz lam
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 compo-
nents is done simply by multiplication or division by laminate total thickness t:
Q
τ= .
t
One introduces notations that simplifies the writing of equations:

Γxz
{Γs }* = ,
Γyz *

Qxz
{Qs }* = ,
Qyz *

τ xz
{τs }* = .
τ yz *
In these expressions the ∗ subscripts can be replaced by a symbol specific to the coordinate sys-
tem in which the components of the vector are expressed (for example "load", "ply", "lam"...).
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 surfacic energy using the local expression
of shear strains:
1 zN
Z
local
Wshear = {γs (z)}T lam · {τs (z)}lam dz ,
2 z0
1 zN
Z
= {τs (z)}T −1
lam · [g]lam (z) · {τs (z)}lam dz ,
2 z0
1 zN
Z
= {Qs }T T −1
lam · [Y ]lam (z) · [g]lam (z) · [Y ]lam (z) · {Qs }lam dz ,
2 z0
Z zN
1 T T −1
= {Qs }lam · [Y ]lam (z) · [g]lam (z) · [Y ]lam (z) dz · {Qs }lam . (II.1.62)
2 z0 lam
similarly, the surfacic energy can be estimated from the out-of-plane shear global equation:
1
global
Wshear = {Γs (z)}Tlam · {Qs }lam ,
2
1
= {Qs }T −1
lam · [G]lam · {Qs }lam . (II.1.63)
2
global local
As there is only one surfacic energy, Wshear = Wshear and
Z zN
−1
[G]lam = [Y ]T −1
lam (z) · [g]lam (z) · [Y ]lam (z) dz ,
Zz0zN
= [U ]lam (z) dz .
z0
Here again, the integration can be calculated ply-by-ply. More precisely, one calculates on ply
k:
k T −1
U lam (z) = Y k lam (z) · g k lam · Y k lam (z) ,
= U0k lam + U1k lam z + U2k lam z 2 + U3k lam z 3 + U4k lam z 4 .

where
k T −1
U0 lam = Y0k lam · g k lam · Y0k lam ,
k T −1 T −1
U1 lam = Y0k lam · g k lam · Y1k lam + Y1k lam · g k lam · Y0k lam ,
k T −1 T −1 T −1
U2 lam = Y0k lam · g k lam · Y2k lam + Y1k lam · g k lam · Y1k lam + Y2k lam · g k lam · Y0k lam ,
k T −1 T −1
U3 lam = Y1k lam · g k lam · Y2k lam + Y2k lam · g k lam · Y1k lam ,
k T −1
U4 lam = Y2k lam · g k lam · Y2k lam .
Then the integral above develops as follows:

Z zN
−1
[G]lam = [U ]lam (z) dz ,
z0
N
X Z zk
Uk

= lam
(z) dz ,
k=1 zk−1
N Z zk 4
!
X X
k
zi

= Ui lam
dz ,
k=1 zk−1 i=0
N 4
!
X X Z zk
k
z i dz

= Ui lam
,
k=1 i=0 zk−1
N 4
!
XX k
zki+1 − zk−1
i+1
= Ui lam
. (II.1.64)
k=1 i=0
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:

1
Gxz = ,
t · [G−1 ]11
1
Gyz = ,
t · [G−1 ]22
in which the [G−1 ]lam matrix has first been rotated into the appropriate axes.
II.1.6.6 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]−1

lam to zero.
3. Then for each layer k with 1 ≤ k ≤ N , one performs the following sequence of opera-
tions:
k estimates the 3 × 3 matrix of in-plane stiffness coefficients in laminate axes

(a) One
C 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 sec-

tion II.1.6.3 for more details.) One has:
Fk
k k
lam
(z) = F 0 lam
+ z F1 lam .
(c) Then, one calculates two other 2 × 2 matrices X0k lam and X1k lam . (See sec-

tion II.1.6.3.) One has:
Xk (z) = X0k lam + z X1k lam .

lam
(d) Then one calculates the Yik lam 2 × 2 matrices:

!
X1k lam 2

k k−1 k−1 k k−1

Y0 lam
= Y0 lam
+ Y1 lam
− X0 lam
zk−1 + Y2 lam
− zk−1 ,
2
Y1k
k
lam
= X0 lam ,
k
k X1 lam
Y2 lam = .
2
As the expression of Y0k lam is recursive, one needs another expression for the first

value. The expression is:

1
Y0 lam = − Y11 lam z0 − Y21 lam z02 .

1
= − X01 lam z0 − X11 lam z02 .

2
These matrices allow to calculate the out-of-plane shear stress from the global out-
of-plane shear force:
k
Y lam (z) = Y0k lam + Y1k lam z + Y2k lam z 2 ,

{τ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 ]lam
ply (z) · {Qs }lam .
One stores a 2 × 2 matrix [Y ]lam

ply for each station through laminate thickness where
out-of-plane shear stress might be requested. Actually it is done at top, mid and
lam
bottom surfaces in each ply. This means that 3N 2 × 2 matrices [Y j ]ply are stored
in the ClaLam object.
(e) One calculates the Uik lam 2 × 2 matrix. (See the end of section II.1.6.5 for the

expressions to be used.) Then to [G]−1lam , one adds one term:

4
!
i+1 i+1
X z − z
[G]−1 −1
Uik lam k k−1

lam = [G]lam + .
i=0
i + 1
4. At the end of the loop on layers, the shear stiffness matrix [G]lam is calculated by inversion
of [G]−1
lam .
One also defines an out-of-plane shear compliance matrix calculated as follows:

[g]lam = [G]−1
lam .
This matrix allows to calculate the laminate out-of-plane shear moduli:

1
Gxz = ,
t · g11
1
Gyz = ,
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 =
5G/6 in which G is material shear modulus. (The usual 5/6 factor in shell theory is recovered.)
II.1.7. CTE AND CME CALCULATIONS 141
II.1.7 CTE and CME calculations

One assumes a linear dependence of the temperature on the location through the laminate thick-
ness:
T (z) = T0 + zT,z . (II.1.65)
Similarly, the water uptake depends linearly on z:
H(z) = H0 + zH,z . (II.1.66)
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.34) 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:
Z h/2
{N }lam = {σ}lam dz ,
−h/2
Z h/2
=− [(T0 − Tref ) + zT,z ] [C]lam · {α}lam dz ,
−h/2
Z h/2 ! !
Z h/2
=− [C]lam · {α}lam dz (T0 − Tref ) − z [C]lam · {α}lam dz T,z ,
−h/2 −h/2
= − {αEh}lam (T0 − Tref ) − αEh2 lam T,z .

In the previous expression, two new symbols have been introduced that are calculated as fol-
lows:
Z h/2
{αEh}lam = [C]lam · {α}lam dz ,
−h/2
N
X
= [C]klam · {α}klam (zk − zk−1 ) . (II.1.67)
k=1
Z h/2
2

αEh lam
= z [C]lam · {α}lam dz ,
−h/2
N
zk2 − zk−1
2
X
= [C]klam · {α}klam . (II.1.68)
k=1
2
Similarly the bending moment tensor is obtained by integrating the Cauchy stress tensor mul-
tiplied by z along the thickness:
Z h/2
{M }lam = z {σ}lam dz ,
−h/2
Z h/2
=− z[(T0 − Tref ) + zT,z ] [C]lam · {α}lam dz ,
−h/2
Z h/2 ! !
Z h/2
=− z [C]lam · {α}lam dz (T0 − Tref ) − z 2 [C]lam · {α}lam dz T,z ,
−h/2 −h/2
= − αEh2 lam (T0 − Tref ) − αEh3 lam T,z .

In the previous expression, one new symbol has been introduced:

Z h/2
3
z 2 [C]lam · {α}lam dz ,

αEh lam =
−h/2
N
zk3 − zk−1
3
X
= [C]klam · {α}klam . (II.1.69)
k=1
3
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:
0
{N }lam [A]lam [B]lam { }lam
= ·
{M }lam [B]lam [D]lam {κ}lam
{αEh2 }lam

{αEh}lam
− (T0 − Tref ) − T,z . (II.1.70)
{αEh2 }lam {αEh3 }lam
Using relation (II.1.44), the previous expression is reversed as follows:
0
{ }lam [a]lam [b]lam {N }lam
= ·
{κ}lam [b]T
lam [d]lam
{M }lam

[a]lam [b]lam {αEh}lam
+ · (T0 − Tref )
[b]T
lam [d]lam
{αEh2 }lam
{αEh2 }lam

[a]lam [b]lam
+ · T,z .
[b]T
lam [d]lam
{αEh3 }lam
In the last expression, four new quantities can be identified:
{α0 }lam = [a]lam · {αEh}lam + [b]lam αEh2 lam ,

(II.1.71)
{α1 }lam = [a]lam · αEh2 lam + [b]lam αEh3 lam ,

(II.1.72)
{α0κ }lam = [b]T 2

lam · {αEh}lam + [d] lam αEh lam
, (II.1.73)
{α1κ }lam = [b]T 2 3

lam · αEh lam + [d]lam αEh lam . (II.1.74)
So that finally, the “compliance” equation is:
{0 }lam

[a]lam [b]lam {N }lam
= ·
{κ}lam [b]T
lam [d]lam
{M }lam
{α0 }lam {α1 }lam

+ (T0 − Tref ) + T,z . (II.1.75)
{α0κ }lam {α1κ }lam
II.1.7.2 Out-of-plane shear thermo-elastic behavior

Starting with the out-of-plane shear constitutive equation (II.1.42) and of the expression defin-
ing 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:
Z h/2
{αs Gh}lam = [g]lam · {αs }lam dz ,
−h/2
N
X
= [g]klam · {αs }klam (zk − zk−1 ) . (II.1.76)
k=1
Z h/2
2

αs Gh lam
= z [g]lam · {αs }lam dz ,
−h/2
N
zk2 − zk−1
2
X
= [g]klam · {αs }klam . (II.1.77)
k=1
2
They are used in the expression:
{Q}lam = [G]lam · {Γ}lam − {αs Gh}lam (T0 − Tref ) − αs Gh2 lam T,z .

(II.1.78)
Correspondingly, one estimates the laminate out-of-plane shear CTE vectors:
{α0s }lam = [G]−1

lam · {αGh}lam (II.1.79)
{α1s }lam = [G]−1 2

lam · αGh lam
(II.1.80)
These two expressions allow to write the expression of the inverse of (II.1.78):
[Γ]lam = [G]−1 s s
lam · {Q}lam + {α0 }lam (T0 − Tref ) + {α1 }lam T,z . (II.1.81)
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.
N
X
{βEh}lam = [C]klam · {β}klam (zk − zk−1 ) , (II.1.82)
k=1
N 2
zk2 − zk−1
X
2
[C]klam {β}klam

βEh = · , (II.1.83)
lam
k=1
2
N
zk3 − zk−1
3
X
3
[C]klam {β}klam

βEh lam
= · , (II.1.84)
k=1
3
0
= ·
{βEh2 }lam

{βEh}lam
− (H0 − Href ) − H,z , (II.1.85)
{βEh2 }lam {βEh3 }lam
{β0 }lam = [a]lam · {βEh}lam + [b]lam βEh2 lam ,

(II.1.86)
{β1 }lam = [a]lam · βEh2 lam + [b]lam βEh3 lam ,

(II.1.87)
{β0κ }lam = [b]T 2

lam · {βEh}lam + [d] lam βEh lam
, (II.1.88)
{β1κ }lam = [b]T 2 3

lam · βEh lam + [d]lam βEh lam , (II.1.89)
{0 }lam

= ·
{κ}lam [b]T
lam [d]lam
{M }lam
{β0 }lam {β1 }lam

+ (H0 − Href ) + H,z , (II.1.90)
{β0κ }lam {β1κ }lam
Z h/2
{βs Gh}lam = [g]lam · {βs }lam dz ,
−h/2
N
X
= [g]klam · {βs }klam (zk − zk−1 ) , (II.1.91)
k=1
Z h/2
2

βs Gh lam
= z [g]lam · {βs }lam dz ,
−h/2
N
zk2 − zk−1
2
X
= [g]klam · {βs }klam , (II.1.92)
k=1
2
{Q}lam = [G]lam · {Γ}lam − {βs Gh}lam (H0 − Href ) − βs Gh2 lam H,z ,

(II.1.93)
{β0s }lam = [G]−1

lam · {βGh}lam (II.1.94)
{β1s }lam = [G]−1 2

lam · βGh lam (II.1.95)
[Γ]lam = [G]−1 s s
lam · {Q}lam + {β0 }lam (H0 − Href ) + {β1 }lam H,z . (II.1.96)
II.1.7.4 Full sets of equations

Finally, the full set of constitutive equation written with stiffness matrices looks like:
0
[A]lam [B]lam { }lam {N }lam
· =
[B]lam [D]lam {κ}lam {M }lam
{αEh2 }lam

{αEh}lam
+ (T0 − Tref ) + T,z
{βEh2 }lam

{βEh}lam
+ (H0 − Href ) + H,z , (II.1.97)
[G]lam · {Γ}lam = {Q}lam + {αs Gh}lam (T0 − Tref ) + αs Gh2 lam T,z

+ {βs Gh}lam (H0 − Href ) + βs Gh2 lam H,z . (II.1.98)

The two previous expressions are inversed as follows:

·
[b]T
lam [d]lam
{M }lam
0
{α0 }lam {α1 }lam

{ }lam
= + (T0 − Tref ) + T,z
{κ}lam {α0κ }lam {α1κ }lam
{β0 }lam {β1 }lam

+ (H0 − Href ) + H,z , (II.1.99)
{β0κ }lam {β1κ }lam
[G]−1 s s
lam · {Q}lam = [Γ]lam − {α0 }lam (T0 − Tref ) − {α1 }lam T,z
− {β0s }lam (H0 − Href ) − {β1s }lam H,z . (II.1.100)
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 sec-
tions 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:
• By specifying normal forces {N }load and bending moments {M }load .
• By specifying average strains {0 }load and curvatures {κ}load .
• By specifying average stresses and flexural stresses.
The type of loading is specified component-by-component. This means that a single load-
ing 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 ex-
plains 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 ,

h2 f
{M }load = σ load ,
6
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 cal-
culated in this new coordinate system. (It is more convenient for the elimination of com-
ponents 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−0 (λ) ,

[B]load = [T− ](λ) · [B]lam · T−0 (λ) ,

[D]load = [T− ](λ) · [D]lam · T−0 (λ) ,

{αEh}load = [T− ](λ) · {αEh}lam ,

...
II.1.8. CALCULATION OF LOAD RESPONSE 147
βEh3 = [T− ](λ) · βEh3 lam .

load
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:
0
[A]load [B]load { }load {N }load
· =
[B]load [D]load {κ}load {M }load
{αEh2 }load

{αEh}load
+ (T0 − Tref ) + T,z
{αEh2 }load {αEh3 }load
{βEh2 }load

{βEh}load
+ (H0 − Href ) + H,z .
{βEh2 }load {βEh3 }load
(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
n
X
Kij uj = bi , i = 1...n.
j=1
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 k th equation of the system:
n
X
Kij uj = bi , i = 1...n, i 6= k
j=1
uk = a .
The unknown uk can be easily eliminated from the linear

n
X
Kij uj = bi − Kik a, i = 1...n, i 6= k
j=1,j6=k
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 load T,z − {βEh}load (H0 − Href ) − βEh2 load H,z ,

{M }load = [B]load · 0 load + [D]load · {κ}load − αEh2 load (T0 − Tref )

− αEh3 load T,z − βEh2 load (H0 − Href ) − βEh3 load H,z .

(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 (−λ) · 0 load ,

{κ}lam = T+0 (−λ) · {κ}load .

Similarly, the normal forces and bending moments components are re-expressed in lam-
inate 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 (ξ) · 0 lam ,

{κ}ply = T+0 (ξ) · {κ}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 re-
quired, the strain components are calculated with:
{}ply (z) = 0 ply + z {κ}ply .

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.101)
II.1.8. CALCULATION OF LOAD RESPONSE 149
(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 “Equiv-
alent 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 calcu-
lations stores a few results:
• The average strain and curvature of the laminate in laminate axes {0 }lam and {κ}lam .
• The laminate in-plane membrane forces and bending moments in laminate axes {N }lam
and {M }lam .

• The ply results in ply axes {}ply (zi ), {σ}ply (zi ) and Mech ply (zi ), zi being the different
stations through the thickness for which the ply results have been calculated.
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 + {αs Gh}load (T0 − Tref )

+ αs Gh2 load T,z + {βs Gh}load (H0 − Href ) + βs Gh2 load H,z .

(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 }load T,z − {β0s }load (H0 − Href ) − {β1s }load H,z .
(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. The ply out-of-plane shear stress components are calculated at the different requested
locations by:
j lam
τs (z) ply = Y j (z) ply · {Qs }lam ,

lam
in which the matrix [Y j ]ply 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]−1
ply · {τ s (z)}ply + {α}ply (T0 − Tref + zT,z )

+ {β}ply (H0 − Href + zH,z ) .
(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 Mech
33 are generally not zero. These strain tensor components can be estimated from
(II.1.27):
Mech
33 = c3311 σ11 + c3322 σ22 + c3333 σ33 + c3323 σ23 + c3331 σ31 + c3312 σ12 ,
33 = Mech
33 + α33 ∆T + β33 ∆H .
II.1.9. ACCELERATING THE CALCULATION OF LOAD RESPONSE 151
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 com-
putation 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 load-
ing, 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 .
−1
3. Finally, this matrix is inversed, and on obtained the 6 × 6 matrix Kconstr .
−1
This Kconstr 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 fol-
lowing matricial product:
{0 }load

−1
= Kconstr · bconstr .
{κ}load
3. Then, the shell strains and curvature components can be expressed in laminate axes by
performing the following matricial operation:
" #
0 T+0 (−λ) [0] 0

{ }lam { }load
= 0 · ,
{κ}lam [0] T+ (−λ) {κ}load
" #
T+0 (−λ) [0] −1
= 0 · Kconstr · bconstr . (II.1.102)
[0] T+ (−λ)
Finally, the last expression leads to the definition of a new 6 × 6 matrix

" #
0
−1
T + (−λ) [0] −1
Kconstr, lam =
0 · Kconstr ,
[0] T+ (−λ)
that allows to write

{0 }lam

−1
= Kconstr, lam · bconstr . (II.1.103)
{κ}lam
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:
0−1
1. The construction of a 2 × 2 Kconstr matrix allows to write:
0−1
[Γ]load = Kconstr · b0constr ,
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:
0−1 0−1
Kconstr, lam = [S− ](λ) · Kconstr ,
0−1 0
[Γ]lam = Kconstr, lam · bconstr . (II.1.104)
Finally, now that the laminate strains and curvatures have been estimated in laminate axes,
the corresponding laminate forces and moments are estimated as follows:
0
= ·
{αEh2 }lam

{αEh}lam
− (T0 − Tref ) − T,z
{βEh2 }lam

{βEh}lam
− (H0 − Href ) − H,z , (II.1.105)
[Q]lam = [G]lam · {Γ}lam − {α0s }lam (T0 − Tref )

− {α1s }lam T,z − {β0s }lam (H0 − Href ) − {β1s }lam H,z . (II.1.106)
One can substitute (II.1.103) and (II.1.104) in expressions (II.1.105) and (II.1.106). This leads
to the following expressions:

{N }lam [A]lam [B]lam −1 {αEh}lam
= · Kconstr, lam −
{M }lam [B]lam [D]lam {αEh2 }lam
 

 bconstr  
T − T
 
0 ref
2
2
 
{αEh }lam {βEh}lam {βEh }lam
 
− − − · T,z ,
{αEh3 }lam {βEh2 }lam {βEh3 }lam
H − H
 
 0

 
ref 


H,z

NM FM
= Kconstr, lam · bconstr , (II.1.107)
0−1 s s

[Q]lam = [G]lam · Kconstr, lam − {α0 }lam − {α1 }lam
b0constr 
 

 


 T 0 − T ref



s s

− {β0 }lam − {β1 }lam · T,z ,
H − Href 
 
 0

 
 
H,z

Q n Q o
= Kconstr, lam · bconstr . (II.1.108)
From equations (II.1.103), (II.1.104), (II.1.107) and (II.1.108), one identifies four matrices and
four vectors that allow the calculation of laminate stress/strain state in laminate axes:
−1
• The 6 × 6 matrix Kconstr, lam ,
0−1
NM
Q
• The 6-components vector bconstr ,

• The 2-components vector b0constr ,
• The 10-components vector bFconstr
M
,
n o
• The 6-components vector bQ constr .
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:
• Laminate in-plane average strain and curvature tensors {0 }lam and {κ}lam (in laminate
axes),
• Laminate out-of-plane shear loads {Q}lam (in laminate axes),
• Laminate temperature loading characterized by the two real values (T0 − Tref ) and T,z ,
• Laminate moisture loading characterized by the two real values (H0 − Href ) and H,z .
These quantities correspond to 12 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 12 real
values. All the calculations are linear.
If one defines a vector with 12 components as follows:
 0


 { } lam 

{κ}

 


 lam 

 {Q}lam 

 

{LLd}lam = T0 − Tref ,
T
 
,z

 

 
H − H
 
0

 ref


 
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 ×12 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.
M ech
Similarly one can also define matrices [K ]ply (zi ) and K ply
(zi ) for the calculations
Mech
of {}ply (zi ) and ply
(zi ) respectively. We explain here, how these three matrices can be
constructed.
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 (ξ) · 0 lam ,

{κ}ply = T+0 (ξ) · {κ}lam ,

j lam
τs (z) ply = Y j (z) ply · {Qs }lam .

The four real values corresponding to laminate temperature and moisture loading are not af-
fected by the modification of coordinate system. The three relations above allow us to write the
following equation:
 0
  T 0 [0] [0] 0 0 0 0
 
0

 { }ply  + (ξ)  { } lam 
 [0] 0
T [0] 0 0 0 0
    



 {κ} ply



  + (ξ) 



 {κ} lam




j lam
{Q}
 {τs (z)}ply   [0] j
     
  [0] [Y (z)] ply 0 0 0 0  
 lam


T0 − Tref = · T − T .
 
 [0] [0] [0] 1 0 0 0   0
  ref
T,z T,z
  





  [0] [0] [0] 0 1 0 0 

 

  
H0 − Href  H − H
    




  [0] [0] [0] 0 0 1 0  

 0 ref



H,z H
   
[0] [0] [0] 0 0 0 1 ,z
(II.1.109)
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:
0
 

 { }ply 

      {κ} 

{} ply (z) [δ 3 ] [δ 3 ] z [0] 0 0 0 0 

j
ply 

{τ (z)}

 
 
 

j s
{τs (z)}ply [0] [0] [δ ] 0 0 0 0 ply
   
2
 
=   · T0 − Tref . (II.1.110)
 T (z) − Tref  [0] [0] [0] 1 z 0 0  
T,z
   

H(z) − Href [0] [0] [0] 0 0 1 z
  
 

H − H

 


 0 ref 

H,z
 
([δ3 ] and [δ2 ] are 3 × 3 and 2 × 2 unit matrices respectively.) Then, considering equation
(II.1.101), one writes:
    

 {σ} ply (z) 
 [C]ply [0] − [C]ply · {α}ply − [C]ply · {β}ply   {} ply (z) 

j   {τsj (z)}
{τs (z)}ply [0] [δ2 ] {0} {0}
   
= · ply
 T (z) − Tref   [0] [0] 1 0   T (z) − Tref  .
   
H(z) − Href [0] [0] 0 1 H(z) − Href
   
(II.1.111)
The vector at left hand side of expression (II.1.111) contains all the ply stress components. One
can remove the two lower lines of the equation as follows:
 
  {}ply (z)  
{τsj (z)}ply

{σ}ply (z) [C]ply [0] − [C]ply · {α}ply − [C]ply · {β}ply  
= · .
{τsj (z)}ply [0] [δ2 ] {0} {0} 
 T (z) − Tref  
H(z) − Href
 
(II.1.112)
Then, the components can be reordered as follows:

   
σ11 1 0 0 0 0
 σ22   0 1 0 0 0 
   
 σ33 
 (z) =  0 0 0 0
 0  {σ} ply (z)
{σ}mat (z) =  · . (II.1.113)
 τ23 
 
 0 0 0 0
 1 
 {τsj (z)}ply
 τ13   0 0 0 1 0 
τ12 0 0 1 0 0
One will also use:

   
σ11 1 0 0 0 0 0 0

 σ22 


 0 1 0 0 0 0 0 
  
   σ33   0 0 0 0 0 0 0   {}ply (z)
{σ}mat (z)      

 τ23   0 0 0 0 1 0 0   {τsj (z)} 
 T (z) − Tref  =   (z) =  · ply .
 τ13   0 0 0 1 0 0 0   T (z) − Tref
H(z) − Href      

τ12 0 0 1 0 0 0 0   H(z) − Href
   
   
 T − Tref   0 0 0 0 0 1 0 
H − Href 0 0 0 0 0 0 1
(II.1.114)
One uses (II.1.27) to estimate the strain tensor:
 
11
 22   

 33 

{σ} mat (z)
 γ23  (z) = [cijkl ] {α}mat {β}mat ·
{}mat (z) =    T (z) − Tref  . (II.1.115)

 γ31 
 H(z) − Href
γ12
The vector that appears in right-hand-side of the previous expression The so-called “mechanical
strain tensor” is given by:
 Mech 
11
 Mech 
 22 Mech

Mech
 33 
{}mat (z) = 
 γ23Mech  (z) = [cijkl ] · {σ}mat (z) .
 (II.1.116)
 Mech 
 γ31 
Mech
γ12
All the operations (II.1.109) to (II.1.116) 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.
In the end, one writes:
{σ}mat (z) = [K5 ] · [K4 ] · [K2 ] (z) · [K1 ] (z) · {LLd}lam ,

= [Kσ ] (z) · {LLd}lam . (II.1.117)
II.1.10. FAILURE THEORIES 157
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.109) 12 × 12 Ply angle, material and height z
[K2 ] (II.1.110) 7 × 12 Height z
[K3 ] (II.1.111) 7×7 Ply material
[K5 ] (II.1.113) 6×5 —
[K6 ] (II.1.114) 8×7 —
{}mat (z) = [K7 ] · [K6 ] · [K3 ] · [K2 ] (z) · [K1 ] (z) · {LLd}lam ,
= [K ] (z) · {LLd}lam . (II.1.118)
{}Mech
mat (z) = [K8 ] · {σ}mat (z) ,
= [K8 ] · [Kσ ] (z) · {LLd}lam ,
= KMech (z) · {LLd}lam .

(II.1.119)
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 × 12 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.
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:
r
1 1
σI,II = (σ11 + σ22 ) ± (σ11 + σ22 )2 + τ12
2
. (II.1.120)
2 4
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 deriva-
tion 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 F oS = 1.
6. One specifies whether a reserve factor and/or strength ratio can be calculated with FeR-
esPost:
• 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.
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:
2 2 2 2 2 2
f = F11 σ11 + F22 σ22 + F33 σ33 + F44 σ23 + F55 σ31 + F66 σ12
+ 2F12 σ11 σ22 + 2F23 σ22 σ33 + 2F31 σ33 σ11
+ F1 σ11 + F2 σ22 + F3 σ33 + F4 σ23 + F5 σ31 + F6 σ12 , (II.1.121)
then a test is done on the calculated value:
f ≤1.
Several failure theories discussed below are obtained by expressing the coefficients in the ex-
pressions 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 character-
ized for the material.
Note that the 2D criteria defined in this section often correspond to the failure criteria de-
fined in ESAComp.
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 fabric II.1.10.4 no yes yes
“MaxStress3D” tape or fabric II.1.10.5 no yes yes
“MaxStrain” tape or fabric II.1.10.6 no yes yes
“MaxStrain3D” tape or fabric II.1.10.7 no yes yes
“CombStrain2D” tape or fabric II.1.10.8 no yes yes
“MaxTotalStrain” tape or fabric II.1.10.6 no yes yes
“MaxTotalStrain3D” tape or fabric II.1.10.7 no yes yes
“CombTotalStrain2D” tape or fabric II.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.17 no yes yes
“Puck_c” tape II.1.10.17 no yes yes
“Hashin” tape II.1.10.18 no yes yes
“Hashin_b” tape II.1.10.18 no yes yes
“Hashin_c” tape II.1.10.18 no yes yes
“Hashin3D” tape II.1.10.19 no yes yes
“Hashin3D_b” tape II.1.10.19 no yes yes
“Hashin3D_c” tape II.1.10.19 no yes yes
“YamadaSun” tape II.1.10.20 no yes yes
“YamadaSun_b” fabric II.1.10.21 no yes yes
“Honey3D” honeycomb II.1.10.22 no yes yes
“HoneyShear” honeycomb II.1.10.23 no yes yes
“HoneyShear_b” honeycomb II.1.10.24 yes yes yes
“Ilss” all II.1.10.25 yes yes yes
“Ilss_b” all II.1.10.25 yes yes yes
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.18
II.1.10.1 Tresca criterion (2D)

Using the stress tensor components a scalar equivalent shear stress is given by:

Tresca2D 1 1 1
τeq = max |σI − σII | , |σI | , |σII | . (II.1.122)
2 2 2
This equivalent shear stress allows to define a Tresca failure index as follows:
Tresca2D
2 · τeq
F I Tresca2D = , (II.1.123)
σtall
The reserve factor is given by:
1 σtall
RF Tresca2D = = , (II.1.124)
F oS · F I Tresca2D F oS · 2 · τeq
Tresca2D
and the strength ratio by:

Tresca2D
F oS · 2 · τeq
SRTresca2D = F oS · F I Tresca2D = . (II.1.125)
σtall
This criterion is referred to as “Tresca2D” criterion in FeResPost.
II.1.10.2 Von Mises criterion (2D)

q
VonMises2D 2 2 2
σeq = σ11 + σ22 − σ11 σ22 + 3τ12 . (II.1.126)
The corresponding failure index is:

VonMises2D
σeq
F I VonMises2D = , (II.1.127)
σtall
The reserve factor is given by:
1 σtall
RF VonMises2D = = , (II.1.128)
F oS · F I VonMises2D F oS · σeq
VonMises2D
and the strength ratio by:

VonMises2D
VonMises2D VonMises2D
F oS · σeq
SR = F oS · F I = . (II.1.129)
σtall
This criterion is referred to as “VonMises2D” criterion in FeResPost.
II.1.10.3 Von Mises criterion (3D)

q
VonMises3D 2 2 2 2 2 2
σeq = σ11 + σ22 + σ33 − σ11 σ22 − σ22 σ33 − σ33 σ11 + 3τ12 + 3τ23 + 3τ31 .
(II.1.130)
As for the 2D version, the corresponding failure index is given by II.1.127, the reserve factor
by II.1.128 and the strength ratio by II.1.129. This criterion is referred to as “VonMises3D”
criterion in FeResPost.
II.1.10.4 Maximum stress criterion

The failure index is calculated as follows:

MaxStress
σ11 σ22 τ12
FI = max all , all , all , (II.1.131)
σ11 σ22 τ12
all all
in which the σ11 and σ22 allowables depend on the sign of σ11 and σ22 respectively. (Generally,
tensile and compressive allowables are different for orthotropic materials.) The reserve factor
is calculated as follows:
1
RF MaxStress = , (II.1.132)
F oS · F I MaxStress
and the strength ratio is given by:
SRMaxStress = F oS · F I MaxStress . (II.1.133)
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:

MaxStress3D
σ11 σ22 σ33 τ12 τ23 τ31
FI = max all , all , all , all , all , all , (II.1.134)
σ11 σ22 σ33 τ12 τ23 τ31
all all all

in which the σ11 , σ22 and σ33 allowables depend on the sign of σ11 , σ22 and σ33 respectively.
(Generally, tensile and compressive allowables are different for orthotropic materials.) The
reserve factor is calculated as follows:
1
RF MaxStress3D = , (II.1.135)
F oS · F I MaxStress3D
SRMaxStress3D = F oS · F I MaxStress3D . (II.1.136)
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:
Mech Mech Mech
γ
= max 11all , 22all , 12all ,
MaxStrain

FI (II.1.137)
11 22 γ12
in which the all all Mech

11 and 22 allowables depend on the sign of 11 and Mech
22 respectively. The
1
RF MaxStrain = , (II.1.138)
F oS · F I MaxStrain
SRMaxStrain = F oS · F I MaxStrain . (II.1.139)
This criterion is referred to as “MaxStrain” criterion in FeResPost.

FeResPost proposes a second version ofthe criterion
where the “total” strain tensor {} is
Mech
used instead of the mechanical strain tensor . 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:
Mech Mech Mech Mech Mech Mech
γ γ γ
= max 11all , 22all , 33all , 12all , 23all , 31all .
MaxStrain3D

FI (II.1.140)
11 22 33 γ12 γ23 γ31
in which the all all all

11 , 22 and 33 allowables depend on the sign of the corresponding mechanical
strain tensor component.
The reserve factor is calculated as follows:
1
RF MaxStrain3D = , (II.1.141)
F oS · F I MaxStrain3D
and the strength ratio is given by

SRMaxStrain3D = F oS · F I MaxStrain3D . (II.1.142)
This criterion is referred to as “MaxStrain3D” criterion in FeResPost.
Mech
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:
s 
Mech 2 Mech 2 s Mech 2 Mech 2
11 γ12 22 γ12
F I CombStrain2D = max  all
+ all
, all
+ all
 , (II.1.143)
11 γ12 22 γ12
in which the all all

11 and 22 allowables depend on the sign of 11
Mech
and Mech
22 respectively. (The
criterion is calculated from the mechanical or equivalent strain tensor components.) The reserve
factor is calculated as follows:
1
RF CombStrain2D = , (II.1.144)
F oS · F I CombStrain2D
SRCombStrain2D = F oS · F I CombStrain2D . (II.1.145)
This criterion is referred to as “CombStrain2D” criterion in FeResPost.
Mech
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:
2 2 2
TsaiHill σ11 σ22 τ12 σ11 σ22
FI = + + − . (II.1.146)
all
σ11 all
σ22 all
τ12 all 2
(σ11 )
all all
Here again, the allowables σ11 and σ22 depend on the signs of σ11 and σ22 respectively. The
Tsai-Hill failure index depends quadratically on the different components of the stress tensor.
Therefore, the reserve factor is calculated as follows:
1
RF TsaiHill = √ , (II.1.147)
F oS F I TsaiHill
√
SRTsaiHill = F oS F I TsaiHill . (II.1.148)
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
t,all t,all
only the tensile allowables σ11 and σ22 are considered for the calculations.
The calculation of reserve factor is as for the more classical Tsai-Hill criterion (II.1.147)
and (II.1.148). 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
2 2 2
TsaiHill_c σ11 σ22 τ12 σ11 σ22
FI = all
+ all
+ all
− 2 . (II.1.149)
σ11 σ22 τ12 0all
(σ11 )
0all
The criterion differs from the previous one by the fact that the allowable σ11 is used in the
t,all c,all
calculation. This allowable is set to σ11 or σ11 depending on the sign of σ11 σ22 .
and (II.1.148). 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
2 2 2 2 2 2
TsaiHill3D σ11 σ22 σ33 τ12 τ23 τ31
FI = all
+ all
+ all
+ all
+ all
+ all
σ11 σ22 σ33 τ12 τ23 τ31
! !
1 1 1 1 1 1
− 2 + 2 − 2 σ11 σ22 − 2 + 2 − 2 σ22 σ33
all all all all all all
(σ11 ) (σ22 ) (σ33 ) (σ22 ) (σ33 ) (σ11 )
!
1 1 1
− + − σ33 σ11 . (II.1.150)
all 2 all 2 all 2
(σ33 ) (σ11 ) (σ22 )
all all all

The allowables σ11 , σ22 and σ33 depend on the signs of σ11 , σ22 and σ33 respectively. The Tsai-
Hill failure index depends quadratically on the different components of the stress tensor. The
1
RF TsaiHill3D = √ , (II.1.151)
F oS F I TsaiHill3D

√
SRTsaiHill3D = F oS F I TsaiHill3D . (II.1.152)
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
t,all t,all t,all
only the tensile allowables σ11 , σ22 and σ33 are considered for the calculations.
and (II.1.152). 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
2
σ2 σ2

τ12 1 1
FI TsaiWu
= t,all11c,all + t,all22c,all + all
+ t,all
−
c,all
σ11
σ11 σ11 σ22 σ22 τ12 σ11 σ11

1 1 TW
+ t,all
− c,all σ22 + 2F12 σ11 σ22 . (II.1.153)
σ22 σ22
TW
In this expression, F12 is a material parameter to be obtained by characterization tests. This
parameter must satisfy the following relation:
TW
2 1
F12 < t,all c,all t,all c,all
.
σ11 σ11 σ22 σ22
Its units are, for example, Pa−2 . Sometimes the corresponding dimensionless parameter is

used instead: q
∗ TW t,all c,all t,all c,all
F12 = F12 σ11 σ11 σ22 σ22 .
This dimensionless parameter must satisfy the relation:
∗
−1 ≤ F12 ≤1.
∗
The value F12 = −1/2 corresponds to a generalized Von Mises criterion. The value
TW
−1
F12 = t,all c,all
2σ11 σ11
leads to the Hoffman criterion discussed in section II.1.10.16.

In some of the terms of expression (II.1.153) 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:
2 2
2
σ11 σ22 τ12 TW
a = t,all c,all + t,all c,all + all
+ 2F12 σ11 σ22 ,
σ11 σ11 σ22 σ22 τ12

1 1 1 1
b= t,all
− c,all σ11 + t,all
− c,all σ22 ,
σ11 σ11 σ22 σ22
c = −1 ,
√
TsaiWu −b + b2 − 4ac
RF = , (II.1.154)
2 · F oS · a
1
SRTsaiWu = . (II.1.155)
RF TsaiWu
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:
2 2 2
2 2 2
TsaiWu3D σ11 σ22 σ33 τ12 τ23 τ31
FI = t,all c,all + t,all c,all + t,all c,all + all
+ all
+
σ σ σ22 σ22 σ σ τ τ τ all
11 11 33 33 12 23 31
1 1 1 1 1 1
+ t,all
− c,all
σ 11 + t,all
− c,all
σ 22 + t,all
− c,all
σ33
σ11 σ11 σ22 σ22 σ33 σ33
TW TW TW
+ 2F12 σ11 σ22 + 2F23 σ22 σ33 + 2F31 σ33 σ11 . (II.1.156)
TW TW TW
The values of F23 and F31 are submitted to the same limitations as F12 in section II.1.10.14.
The RF calculation is done as follows:
2 2 2
2 2 2
σ11 σ22 σ33 τ12 τ23 τ31
a = t,all c,all + t,all c,all + t,all c,all + all
+ all
+ all
σ11 σ11 σ22 σ22 σ33 σ33 τ12 τ23 τ31
TW TW TW
+ 2F12 σ11 σ22 + 2F23 σ22 σ33 + 2F31 σ33 σ11 ,

1 1 1 1 1 1
b= t,all
− c,all σ33 ,
σ11 σ11 σ22 σ22 σ33 σ33
c = −1 ,
√
TsaiWu3D −b + b2 − 4ac
RF = , (II.1.157)
2 · F oS · a
1
SRTsaiWu3D = . (II.1.158)
RF TsaiWu3D
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:
2 2
2
Hoffman σ11 σ22 τ12 1 1
FI = t,all c,all + t,all c,all + all
+ t,all
− c,all σ11
σ11 σ11 σ22 σ22 τ12 σ11 σ11

1 1 σ11 σ22
+ t,all
− c,all σ22 − t,all c,all . (II.1.159)
σ22 σ22 σ11 σ11
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:
2 2
2
σ11 σ22 τ12 σ11 σ22
a = t,all c,all + t,all c,all + all
− t,all c,all ,
σ11 σ11 σ22 σ22 τ12 σ11 σ11

1 1 1 1
b= t,all
− c,all σ22 ,
σ11 σ11 σ22 σ22
c = −1 ,
√
Hoffman −b + b2 − 4ac
RF = , (II.1.160)
2 · F oS · a
1
SRHoffman = . (II.1.161)
RF Hoffman
This criterion is referred to as “Hoffman” criterion in FeResPost.
II.1.10.17 Puck criteria

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:
 
v u !2 !2
 σ11 u σ22 τ12 

F I Puck = max  all , t all + all  , (II.1.162)
σ11 σ22 τ12
all all
in which the allowables σ11 and σ22 depend on the signs of σ11 and σ22 respectively. The reserve
factor is simply given by:
1
RF Puck =  v !2 !2  , (II.1.163)
σ u
11 t σ22 τ12
u
F oS · max  all , +

σ11 all all
σ22 τ12

 
v !2 !2
u σ
 σ11 u 22 τ12
SRPuck = F oS · max  all , t all +  . (II.1.164)

σ11 all
σ22 τ12
This criterion is referred to as “Puck” criterion in FeResPost.

A modified version of Puck criterion is defined as follows:

 !2 !
σ 2
11 σ 22 τ 12 1 1
F I Puck_b = max  all , c,all t,all + + σ22 −  . (II.1.165)

σ11 σ22 σ22 all t,all c,all
τ12 σ22 σ22

all
σ11
RFa = ,
F oS · σ11
!2
2
σ22 τ12
a = c,all t,all + all
,
σ22 σ22 τ12

1 1
b = σ22 t,all
− c,all ,
σ22 σ22
c = −1 ,
√
−b + b2 − 4ac
RFb = ,
2 · F oS · a
RF Puck_b = min (RFa , RFb ) . (II.1.166)

The calculation of failure index is based on the calculation of the reserve factor:
1
F I Puck_b = , (II.1.167)
RF Puck_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:
1
SRPuck_b = . (II.1.168)
RF Puck_2
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:
 !2 !2 !
σ 2
11 σ11 σ22 τ12 1 1
F I Puck_c = max  all , t,all
+ c,all t,all + all
+ σ22 t,all
− c,all  .
σ11 2σ11 σ22 σ22 τ12 σ22 σ22
(II.1.169)
The calculation of reserve factor is done as for version “b” of Puck criterion, but one uses a
modified expression for a parameter:
!2 !2
2
σ11 σ22 τ12
a= t,all
+ c,all t,all + all
.
2σ11 σ22 σ22 τ12
This criterion is referred to as “Puck_c” criterion in FeResPost.

II.1.10.18 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:
• If σ11 > 0 a quadratic function is used to estimate fiber reserve factor:
1
RFb = v !2 !2 ,
u
u σ11 τ12
F oS · t t,all
+ all
σ11 τ12
otherwise, a linear expression is used:
c,all
σ11
RFb = .
F oS · |σ11 |
• The calculation of matrix failure is slightly more complicated. If σ22 > 0 one has simply:
1
RFc = v !2 !2 .
u
u σ22 τ12
F oS · t t,all
+ all
σ22 τ12
Otherwise a quadratic equation must be solved:
!2 !2
σ22 τ12
a= all
+ all
,
2τ12 τ12
 
c,all 2
!
σ22 σ
22
b= all
− 1 · c,all
2τ12 σ22
c = −1
√
−b + b2 − 4ac
b=
2 · F oS · a
Finally, the reserve factor is given by:
RF Hashin = min (RFb , RFc ) (II.1.170)
Here again, the calculation of failure index is based on the calculation of the reserve factor:
1
F I Hashin = , (II.1.171)
RF Hashin
in which the safety factor used in the calculation of the RF is 1, and the strength ratio is calcu-
lated as
1
SRHashin = , (II.1.172)
RF Hashin
in which one keeps the value of safety factor.
The criterion presented above is referred to by “Hashin” criterion in FeResPost. Corre-
spondingly, 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.19 Hashin criteria (3D)

A 3D version of the criterion defined in section II.1.10.18 is defined as follows
• If σ11 > 0 a quadratic function is used to estimate fiber reserve factor:
1
RFb = v !2 .
u 2 2
u σ11 τ12+ τ31
F oS · t +
t,all
σ11 all 2
(τ12 )
Otherwise, the following linear expression is used:

c,all
σ11
RFb = .
F oS · |σ11 |
• The calculation of matrix failure is slightly more complicated. If σ22 + σ33 > 0 one has:
1
RFc = v !2 .
u 2 2 2
u τ12 + τ31 τ23 − σ22 σ33 σ22 + σ33
F oS · t 2 + +
all all 2 t,all
σ22
(τ12 ) (τ23 )
Otherwise the failure criterion is:

!2  !2 
2 2 2 c,all
τ12 + τ31 τ23 − σ22 σ33 σ22 + σ33 σ22 + σ33 σ22
+ + +  − 1 ≥ 1 .
all 2 all 2 all
2τ23 c,all
σ22 all
2τ23
(τ12 ) (τ23 )
For that case, one successively calculates:

!2
2 2 2
τ12 + τ31 τ23 − σ22 σ33 σ22 + σ33
a= 2 + 2 + all
,
all
(τ12 ) all
(τ23 ) 2τ23
 !2 
c,all
σ22 + σ33 σ22
b= c,all

all
− 1 ,
σ22 2τ23
c = −1 ,
√
−b + b2 − 4ac
RFc = .
2 · F oS · a
Finally, the reserve factor is given by:
RF Hashin3D = min (RFb , RFc ) (II.1.173)
Here again, the calculation of failure index is based on the calculation of the reserve factor:
1
F I Hashin3D = , (II.1.174)
RF Hashin3D
in which the safety factor used in the calculation of the RF is set to 1, and the strength ratio is
calculated as
1
SRHashin3D = , (II.1.175)
RF Hashin3D
in which one keeps the value of safety factor.

The criterion presented above is referred to by “Hashin3D” criterion in FeResPost. Corre-
spondingly, 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.20 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:
2 2
YamadaSun σ11 τ12
FI = all
+ all
. (II.1.176)
σ11 τ12
all
The allowable σ11 depends on the sign of σ11 . The reserve factor is calculated as follows:
1
RF YamadaSun = √ , (II.1.177)
F oS F I YamadaSun
√
SRYamadaSun = F oS F I YamadaSun . (II.1.178)
This criterion is referred to as “YamadaSun” in FeResPost.
II.1.10.21 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:
" 2 2 2 2 #
σ 11 τ 12 σ 22 τ12
F I YamadaSun_b = max all
+ all
; all
+ all
. (II.1.179)
σ11 τ12 σ22 τ12
all all
The allowables σ11 and σ22 depends on the signs of σ11 and σ22 respectively. The reserve factor
is calculated as follows:
1
RF YamadaSun_b = √ , (II.1.180)
F oS F I YamadaSun_b
√
SRYamadaSun_b = F oS F I YamadaSun_b . (II.1.181)
This criterion is referred to as “YamadaSun_b” in FeResPost.

II.1.10.22 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:
s 2 2 2
Honey3D σ33 τ23 τ31
FI = all
+ all
+ all
. (II.1.182)
σ33 τ23 τ31
all
The allowable σ33 depends on the sign of σ33 (Generally, the compressive allowable is signif-
icantly smaller than the tensile one). The honeycomb material is generally defined in such a
all all
way that the allowable τ31 = τL is in ribbon direction (longitudinal allowable) and τ23 is the
transverse allowable τW .
1
RF Honey3D = , (II.1.183)
F oS · F I Honey3D
SRHoney3D = F oS · F I Honey3D . (II.1.184)
This criterion is referred to as “Honey3D” in FeResPost.
II.1.10.23 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:
s
2 2
HoneyShear τ23 τ31
FI = all
+ all
. (II.1.185)
τ23 τ31

1
RF HoneyShear = , (II.1.186)
F oS · F I HoneyShear
SRHoneyShear = F oS · F I HoneyShear . (II.1.187)
This criterion is referred to as “HoneyShear” in FeResPost.
II.1.10.24 Honeycomb simplified shear criterion

Sometimes, one simplifies the criterion described in section II.1.10.23 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:
q
2 2
τshear = τ13 + τ23 . (II.1.188)
The failure index is then calculated as follows:

τshear
F I HoneyShear_b = all
. (II.1.189)
τ23

1
RF HoneyShear_b = , (II.1.190)
F oS · F I HoneyShear_b
SRHoneyShear_b = F oS · F I HoneyShear_b . (II.1.191)
This criterion is referred to as “HoneyShear_b” in FeResPost.
II.1.10.25 Inter-laminar shear criterion

The inter-laminar shear criterion is based on the comparison of inter-laminar shear stress with
resin shear allowable:
τinter-laminar
F I Ilss = all , (II.1.192)
τinter-laminar
In which the inter-laminar shear stress is a scalar stress calculated as follows:
q
2 + τ2 .
τinter-laminar = τxz yz
The reserve factor is of course:

1
RF Ilss = , (II.1.193)
F oS · F I Ilss
SRIlss = F oS · F I Ilss . (II.1.194)
This criterion is different from the other criteria in this that it does not use ply material allow-
ables. 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:
∂T
ρCp = −∇ · q + r , (II.1.195)
∂t
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 , (II.1.196)
where λT is the tensor of thermal conductivity coefficients.
When thermal conductivity calculations are performed with laminates, two homogenized
quantities must first be calculated:
• The laminate global conductivity tensor,
• The laminate global thermal capacity.
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 tensor may be written as follows:
 T
λ11 λT12 λT13
  
q1
 q2  = −  λT21 λT22 λT23  · ∇T .
q3 λT31 λT32 λT33
The tensor λT is symmetric, so that only 6 components must be defined:
 T
λ11 λT12 λT31
  
q1
 q2  = −  λT12 λT22 λT23  · ∇T . (II.1.197)
q3 λT31 λT23 λT33
For an orthotropic material, the previous equations reduces to:
   T 
q1 λ11 0 0
 q2  = −  0 λT22 0  · ∇T . (II.1.198)
q3 0 0 λT33
Then, only three material parameters define the thermal conductivity. Finally, for an isotropic
material the thermal conductivity is defined by a single parameter λT :
   T 
q1 λ 0 0
 q2  = −  0 λT 0  · ∇T . (II.1.199)
T
q3 0 0 λ
II.1.11. TEMPERATURE DIFFUSION IN LAMINATES 175
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:
q1
{q12 } = ,
q2
and the out-of-plane component q3 .
Correspondingly, the tensor of thermal conductivity coefficients is separated into an in-
plane conductivity tensor: T
λ11 λT12

T
λ 12 = ,
λT12 λT22
and the out-of-plane conductivity λT33 . The “shear” components λT31 and λT23 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 λT33 . The transformation of components for {q} and λT is
noted with the transformation matrices defined in expressions (II.1.12) to (II.1.17):
λT = [S− ](θ) · λT xy · [S+ ](θ) ,

12
(II.1.200)
λT = [S+ ](θ) · λT 12 · [S− ](θ) ,

xy
(II.1.201)
{q}xy = [S+ ](θ) · {q}12 , (II.1.202)
{q}12 = [S− ](θ) · {q}xy . (II.1.203)
II.1.11.4 Integration along the laminate thickness

One considers separately the laminate thermal in-plane conductivity, thermal out-of-plane con-
ductivity and thermal capacity.
In-plane conductivity
To calculate the laminate in-plane thermal conductivity properties, one assumes that tempera-
ture 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 .

(II.1.204)
The laminate in-plane thermal conductivity is calculated as follows:

Z −h/2
{Q}xy = {q}xy (z) dz ,
−h/2
Z −h/2
λT

= xy
(z) · {∇T }xy dz ,
−h/2
!
Z −h/2
λT

= xy
(z) dz · {∇T }xy ,
−h/2
!
Z −h/2
T

= [S+ ](θ) (z) · λ 12
(z) · [S− ](θ) (z) dz · {∇T }xy ,
−h/2
= ΛT xy · {∇T }xy .

In the previous equation, one introduced the laminate in-plane thermal conductivity:
Z −h/2
T
[S+ ](θ) (z) · λT 12 (z) · [S− ](θ) (z) dz ,

Λ xy =
−h/2
N
X
[S+ ](θk ) · λTk 12 · [S− ](θk ) ek ,

= (II.1.205)
k=1
where ek is the thickness of ply k.
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:
qz
. ∇Tz = (II.1.206)
λT33
The integration across the thickness gives the difference of temperature between upper and
lower laminate surfaces:
Z −h/2
Tsup − Tinf = ∇Tz dz ,
−h/2
−h/2
qz
Z
= dz ,
−h/2 λT33
!
−h/2
1
Z
= dz qz ,
−h/2 λT33
T
= R33 qz .
In previous expression, one introduced the out-of-plane thermal resistance:
Z −h/2
T
1
R33 = T
dz ,
−h/2 λ33
N
X 1
= ek . (II.1.207)
k=1
(λT33 )k
II.1.12. MOISTURE DIFFUSION IN LAMINATES 177
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:
Z −h/2
U= ρCp T dz ,
−h/2
!
Z −h/2
= ρCp dz T,
−h/2
= (ρCp h)lam T .
In previous expression, one introduced the surfacic thermal capacity

Z −h/2
(ρCp h)lam = ρCp dz ,
−h/2
N
X
= (ρCp )k ek . (II.1.208)
k=1
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
= −∇ · q M , (II.1.209)
∂t
where M is the moisture content (for example in [kg/m3 ]) and vector q M is the massic flux of
moisture (in [kg/m2 s]). 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 , (II.1.210)
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
= ∇ · λH · ∇H .

(II.1.211)
∂t
here λH is the tensor of moisture conductivity coefficients. This expression is very similar to
the equation of thermal diffusion:
• The components of λH are defined the same way as the components of λT depending on
the type of material (isotropic, orthotropic or anisotropic).
• The calculation of laminate global conductivity properties is done the same way as for
thermal conductivities:
N
X
ΛH [S+ ](θk ) · λH

xy
= k 12 · [S− ](θk ) ek , (II.1.212)
k=1
N
H
X 1
R33 = ek . (II.1.213)
k=1
(λH
33 )k
As one works with moisture percentages, nothing equivalent to the laminate thermal capacity
(ρCp h)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 definition 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:
• Lengths are expressed in meters [m].
• Masses are expressed in kilograms [kg].
• Time is expressed in seconds [s].
• Force is expressed in Newtons [N].
• Energy is expressed in joules [J].
• Temperatures are expressed in Celsius degrees [o C].
• Moisture contents are expressed in percentage of weight [%w]. (Weight of water divided
by the weight of dry material in %.)
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.
II.1.13. UNITS 179
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 FI []
Reserve factors RF []
Table II.1.5: Units of the different quantities related to material properties.

Materials stiffnesses or moduli Cijkl , [C], E or G [F/L2 ]
Materials compliance matrices cijkl , [c], [g] [L2 /F] ]
Poisson coefficients νij [-]
Thermal conductivity λTij [E/(LT)]
Coefficients of thermal expansion α [L/(LT)] or [1/T]
Moisture conductivity λH ij [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 Fi [L2 /F]
Coefficients of quadratic failure criteria Fij [L4 /F2 ]
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.
• Length: “micron”, “mm”, “cm”, “m”, “mil” (milli-inch), “in”, “ft”.
• Mass: “g”, “kg”, “t” (tons), “dat” (deca-tons), “lbm”, “kbm” (kilo-pounds).
• Time: “s”, “min”, “hour”.
• Force: “N”, “daN”, “kN”, “kgf” (kilogram-force), “lbf” (pound-force), “kips” (kilo-
pound-force).
• Energy: “J”, “cal”, “BTU”, “ft.lbf”, “in.lbf”, “kgf.m”.
Table II.1.6: Units of the different quantities related to laminate properties.

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]T [L/F]
In-plane thermal conductivity matrix Λ [E/(tT)]
T
Out-of-plane thermal resistance R33 [L2 Tt/E]
Surfacic heat capacity (ρC
p h) lam [E/L2 /T]
In-plane moisture conductivity matrix ΛH [1/t]
H
Out-of-plane moisture resistance R33 [L2 t]
• Temperature: “o C”, “o F”, “K”.
• Moisture content: “%w”.
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. The “setUnits” method change the units attributed to an object without modify-
ing the values of the different quantities defining the object. (No unit conversion is done.)
The “changeUnits” method performs the units conversion. Both “setUnits” and “changeUnits”
methods has an Hash argument corresponding to the value returned by “getUnits” method.
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.
Table II.2.1: The different methods that have been defined in “ClaDb” class.

new II.2.1 IV.5.1
initialize II.2.1
clone II.2.8
Manipulation of data defining ClaDb object
insertMaterial II.2.3 IV.5.2
eraseMaterial II.2.3
getMaterialsNbr II.2.3
getMaterialCopy II.2.3 IV.5.2
insertLaminate II.2.3 IV.5.2
eraseLaminate II.2.3
getLaminatesNbr II.2.3
getLaminateCopy II.2.3 IV.5.4.2
reInitAllPliesAccelMatrices II.2.3
insertLoad II.2.3
eraseLoad II.2.3
getLoadsNbr II.2.3
getLoadCopy II.2.3 IV.5.4.2
Management of units methods
getDbUnits II.2.4
setDbUnits II.2.4
setUnitsAllEntities II.2.4
Table II.2.1 – continued on next page
181
182 CHAPTER II.2. THE “CLADB” CLASS
Table II.2.1 – continued from previous page

setUnitsAllMaterials II.2.4
setUnitsAllLaminates II.2.4
setUnitsAllLoads II.2.4
changeUnitsAllEntities II.2.4
changeUnitsAllMaterials II.2.4
changeUnitsAllLaminates II.2.4
changeUnitsAllLoads II.2.4
Iterators
each_material II.2.7
each_materialId II.2.7
each_laminate II.2.7 IV.5.4.3
each_laminateId II.2.7
each_load II.2.7
each_loadId II.2.7
Disk IO methods
readEdf II.2.5 IV.5.1
writeNeutral II.2.5 IV.5.1
readNeutral II.2.5 IV.5.1
NDF lines
initWithNeutralLines II.2.6
getNeutralLines II.2.6
Attributes
Id II.2.2
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):
• “Id” attribute setter has one argument and sets the identifier. The argument is an identifier
(an integer, a String or an Array[int,String]).
• “Id” attribute getter has no argument and returns the identifier of the object (same types
as above), or nil if no identifier has been attributed to the object.
II.2.3. MANIPULATING ENTITIES STORED IN A CLADB 183
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:
• “insertMaterial” makes a copy of the ClaMat argument and inserts it into the materials
collection.
• “eraseMaterial” removes the specified material from the stored materials collection. The
argument is an identifier corresponding to the material to be retrieved.
• “‘getMaterialsNbr” returns the number of materials stored in the materials collection.
• “getMaterialCopy” returns a copy of a material stored in the materials collection. The

argument is an identifier corresponding to the material to be retrieved.
• “insertLaminate” makes a copy of the ClaLam argument and inserts it into the laminates
collection.
• “eraseLaminate” removes the specified laminate from the stored laminates collection.
The argument is an identifier corresponding to the laminate to be retrieved.
• “‘getLaminatesNbr” returns the number of laminates stored in the laminates collection.
• “getLaminateCopy” returns a copy of a ClaLam stored in the laminates collection. The

argument is an identifier corresponding to the laminate to be retrieved.
• “reInitAllPliesAccelMatrices” re-initializes the ply acceleration matrices of all the lami-

nates stored in the dataBase. (See sections II.4.8.2 and II.1.9.2 for more information.)
• “insertLoad” makes a copy of the ClaLoad argument and inserts it into the loads collec-
tion.
• “eraseLoad” removes the specified load from the stored loads collection. The argument
is an identifier corresponding to the load to be retrieved.
• “‘getLoadsNbr” returns the number of loads stored in the loads collection.
• “getLoadCopy” returns a copy of a ClaLoad object stored in the loads collection. The
argument is an identifier corresponding to the load to be retrieved.
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 materi-
als, 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 hαEhi 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:
• “getDbUnits” returns a Hash containing the definition of units associated to the database.
• “setDbUnits” has a Hash argument and sets the units associated to the database. The
method does not modify anything else to the CLA entities stored in the database.
• “setUnitsAllEntities” has a Hash argument and sets the units associated to the database
and all the CLA entities stored in the database.
• “setUnitsAllMaterials” has a Hash argument and sets the units associated to all the Cla-
Mat entities stored in the database.
• “setUnitsAllLaminates” has a Hash argument and sets the units associated to all the
ClaLam entities stored in the database.
• “setUnitsAllLoads” has a Hash argument and sets the units associated to all the ClaLoad
entities stored in the database.
• “changeUnitsAllEntities” has a Hash argument and changes the units associated to the
database and all the CLA entities stored in the database.
• “changeUnitsAllMaterials” has a Hash argument and changes the units associated to all
the ClaMat entities stored in the database.
• “changeUnitsAllLaminates” has a Hash argument and changes the units associated to all
the ClaLam entities stored in the database.
• “changeUnitsAllLoads’ has a Hash argument and changes the units associated to all the
ClaLoad entities stored in the database.
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 185
II.2.5 Saving to or retrieving from a disk file

Presently, three interface functions are defined:
• “readEdf” is used to import the data stored in an ESAComp data file. The function has
one argument: a String containing the name of the "edf" file.
When a load is read from an ESAComp file, the reader should keep in mind that the
numbering of plies follows different conventions in FeResPost and ESAComp. When a
thermo-elastic loading is defined, the ESAComp “bottom” temperature corresponds to
FeResPost “Tsup”, and the “top” temperature corresponds to “Tinf”. The same remark
applied to thermo-elastic loading.
• “readNeutral” is used to import the data stored in a neutral data file. The function has
one argument: a String containing the name of the “ndf” file.
• “writeNeutral” is used to export the data stored to a neutral data file. The function has
one argument: a String containing the name of the “ndf” file.
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:
• “initWithNeutralLines” that initializes the ClaDb object from an Array of Strings inter-
preted as the content of an NDF file. The argument is the Array of Strings containing the
lines.
• “getNeutralLines” that returns an Array of Strings corresponding to the lines that would
have been written in the NDF file by “writeNeutral” method. This method has no argu-
ment.
II.2.7 Iterators
The ClaDb class provides 6 iterators:
• “each_material” iterates on the materials storage and produces pairs of identifier and
ClaMat object.
• “each_materialId” iterates on the materials storage and produces the identifiers only.
• “each_laminate” iterates on the laminates storage and produces pairs of identifier and
ClaLam object.
• “each_laminateId” iterates on the laminates storage and produces the identifiers only.
• “each_load” iterates on the loads storage and produces pairs of identifier and ClaLoad
object.
• “each_loadId” iterates on the loads storage and produces the identifiers only.
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:
• An identifier,
• A type which can be "isotropic", "orthotropic" or "anisotropic".
• Its moduli and Poisson’s coefficients,
• Its thermal and moisture expansion coefficients,
• Its allowables.
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.

new II.3.1 IV.5.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.5.2
getDataModuli II.3.3
clearCTEs II.3.3
insertCTEs II.3.3
fillCTEs II.3.3 IV.5.2
getDataCTEs II.3.3
187
188 CHAPTER II.3. THE “CLAMAT” CLASS

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.5.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.5.2
getInPlaneCompliance II.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.5.3
getRho II.3.4 IV.5.3
getCp II.3.4 IV.5.3
getRhoCp II.3.4 IV.5.3
getInPlaneLambdaH II.3.4
getUnits II.3.5
setUnits II.3.5
changeUnits II.3.5
II.3.1. CREATION OF AN OBJECT 189

Attributes
Id II.3.2
Type II.3.2
TypeName II.3.2 (read only)
NDF lines

The singleton method “new” is used to create ClaMat objects. This method has no 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:
• “Type” attribute setter has one String or integer argument corresponding to the type of the
material. Presently, three values are allowed: "isotropic", "orthotropic" or "anisotropic".
The type of the object must be set prior to the attribution of material moduli, thermal
expansion coefficients and allowables. Note that the attribute “getter” returns an integer.
• “TypeName” attribute getter returns a String corresponding to the type (same values as
for the “Type” attribute arguments, or "NONE" if no material type is defined).
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.26) 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 coeffi-

cients. 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 “in-
sertCTEs” 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 coef-

ficients. 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 “in-
sertCMEs” 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 calcu-
late isotropic stress criteria or reserve factors. "F12" "F23" and "F31" correspond to the
TW TW TW
F12 , F23 and F31 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 cri-
terion calculation, the allowable is always extracted from the laminate definition. (More
precisely, the ilss laminate allowable, or the ply allowables are used.)
II.3.3. MANIPULATING DATA 191
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", "lamb-
daT23" 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 argu-
ments as “insertThermalData” but differs by the fact that thermal data are re-initialized
16. “clearMoistureData” has no arguments and erases all the Moisture data stored in a Cla-
Mat object.
17. “insertMoistureData” is used to define the moisture data. For orthotropic and anisotropic
materials, possible keys are "lambdaH1", "lambdaH2", "lambdaH3", "lambdaH12", "lamb-
daH23" 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 argu-
ments as “insertMoistureData” but differs by the fact that moisture data are re-initialized
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.
• “getCompliance” returns an Array of 6 × 6 elements corresponding to the material com-
pliance matrix.
• “getStiffness” returns an Array of 6 × 6 elements corresponding to the material compli-

ance matrix.
• “getInPlaneCompliance” returns an Array of 3×3 elements corresponding to the in-plane

material compliance matrix.
• “getInPlaneStiffness’ returns an Array of 3 × 3 elements corresponding to the in-plane

material compliance matrix.
• “getInPlaneAlfaE” returns an Array of 3 elements corresponding to the in-plane {αE}

vector.
• “getInPlaneBetaE” returns an Array of 3 elements corresponding to the in-plane {βE}

vector.
• “getInPlaneAlfa” returns an Array of 3 elements corresponding to the in-plane {α} vec-

tor.
• “getInPlaneBeta” returns an Array of 3 elements corresponding to the in-plane {β} vec-

tor.
• “getOOPSCompliance” returns an Array of 2 × 2 elements corresponding to the out-of-

plane shear material compliance matrix.
• “getOOPSStiffness” returns an Array of 2×2 elements corresponding to the out-of-plane

shear material compliance matrix.
• “getOOPSAlfaG” returns an Array of 2 elements corresponding to the out-of-plane {αs G}

vector.
• “getOOPSBetaG” returns an Array of 2 elements corresponding to the out-of-plane {βs G}

vector.
• “getOOPSAlfa” returns an Array of 2 elements corresponding to the out-of-plane {αs }

vector.
• “getOOPSBeta” returns an Array of 2 elements corresponding to the out-of-plane {βs }

vector.
• “getInPlaneLambdaT” returns an Array of 2 × 2 elements corresponding to the in-plane

T
thermal conductivity matrix λk .
• “getInPlaneLambdaH” returns an Array of 2 × 2 elements corresponding to the in-plane

moisture conductivity matrix λH
k .
II.3.5. MANAGEMENT OF UNITS 193
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 argu-
ment:
• “getRho” returns a real value corresponding to the material density ρ.
• “getCp” returns a real value corresponding to the material specific heat capacity Cp .
• “getRhoCp” returns a real value corresponding to the material volumic heat capacity ρCp .
The different calculated results from the ClaMat object are expressed in the units system asso-
ciated with the object.

The “ClaMat” class defines three methods for the management of units:
• “getUnits” returns a Hash containing the definition of units associated to the material.
• “setUnits” has a Hash argument and sets the units associated to the material.
• “changeUnits” has a Hash argument and changes the units associated to the material.

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.

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

new II.4.2 IV.5.2
initialize II.4.2
clone II.4.13
Class single methods
setMuxMuy II.4.1
getMuxMuy II.4.1
Manipulations of the laminate plies
clearPlies II.4.4
addPly II.4.4 IV.5.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.5.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
195
196 CHAPTER II.4. THE “CLALAM” CLASS

setLaminateIlss II.4.5 IV.5.4.3
setAllPliesIlss II.4.5 IV.5.4.3
Laminate properties
calcLaminateProperties II.4.6 IV.5.3
get_thickness II.4.6
get_surfacicMass II.4.6
get_averageDensity II.4.6
get_ABBD II.4.6 IV.5.2
get_G II.4.6 IV.5.5
get_alfaEh1 II.4.6 IV.5.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.5.4.1
get_LambdaT II.4.6 IV.5.3
get_R33T II.4.6 IV.5.3
get_RhoCpH II.4.6 IV.5.3
get_LambdaH II.4.6
get_R33H II.4.6
Laminate load response
197

calcResponse II.4.7.1 IV.5.4.2
isThermalLoadingDefined II.4.7.2
getDeltaT II.4.7.2 IV.5.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.2 IV.5.4.1
getMoments II.4.7.2 IV.5.4.1
getShearForces II.4.7.2 IV.5.4.1
getNormalStrains II.4.7.2 IV.5.4.1
getCurvatures II.4.7.2 IV.5.4.1
getShearStrains II.4.7.2 IV.5.4.1
getAverageInPlaneStresses II.4.7.2 IV.5.4.1
getFlexuralStresses II.4.7.2 IV.5.4.1
getAverageShearStresses II.4.7.2 IV.5.4.1
getAverageInPlaneStrains II.4.7.2 IV.5.4.1
getFlexuralStrains II.4.7.2 IV.5.4.1
getAverageShearStrains II.4.7.2 IV.5.4.1
getPliesStrains II.4.7.3 IV.5.4.1
getPliesStresses II.4.7.3 IV.5.4.1
getPliesMechanicalStrains II.4.7.3 IV.5.4.1
getPliesStrainsWrtLamAxes II.4.7.3
getPliesStressesWrtLamAxes II.4.7.3
getPliesMechanicalStrainsWrtLamAxes II.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.5 IV.5.4.1
getMaxDerived II.4.7.5
getMinDerived II.4.7.5
getFailureIndices II.4.7.5 IV.5.4.1
getMaxFailureIndices II.4.7.5
getMinFailureIndices II.4.7.5
getReserveFactors II.4.7.5 IV.5.4.1

getMaxReserveFactors II.4.7.5
getMinReserveFactors II.4.7.5
getStrengthRatios II.4.7.5 IV.5.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.5.6
getUnits II.4.10
setUnits II.4.10
changeUnits II.4.10
Iterators
each_ply II.4.12 IV.5.5
NDF lines
Attributes
Id II.4.3
II.4.1 Two 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. The default values of these parameters are µx = µy = 1.
Two Class Methods allow the manipulation of these parameters:
• “setMuxMuy” has two Real parameters and is used to set the values of µx and µy respec-
tively.
• “getMuxMuy” returns an Array of two Real objects corresponding to µx and µy respec-

tively.
As these methods are Class methods, the modification of µx or µy affects all the laminates
defined in all the CLA databases.

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 199
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.
• “PlyId” is the global identifier of the ply. This identifier can be an integer, a String or a
pair "integer-String" stored in an Array. If one decides not to specify a global ID for the
ply, the argument can be omitted (optional argument).
• “MatId” is the material id of the ply. This identifier must correspond to an existing
material stored in a ClaDb object. The identifier is used internally by the ClaLam class
to retrieve material properties and calculate laminate properties.
• “Thickness” is a Real argument corresponding to the thickness of the ply. The units must
be consistent with those of other data. For example, the thickness may have to be given
in meters.
• “Angle” is a Real argument corresponding to the orientation of the ply in the laminate.
This angle is specified in degrees.
• “IlssInf” is the inter-laminar shear stress allowable between the ply being added and the
previous ply (lower ply in the layup).
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 argu-
ments are nearly the same as those of the “addPly” method:
• “Index” is the position in laminate of the ply for which data are defined. It is an integer
such that 0 ≤ i < N where N is the number of plies defined in the Laminate.
• “PlyId” (see “addPly” method). This argument is optional.
• “MatId” (see “addPly” method).

• “Thickness” (see “addPly” method).
• “Angle” (see “addPly” method).
• “IlssInf” (see “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 pre-
viously 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:
• “getNbrPlies” has no argument and returns the number of plies.
• “getPlyData” returns the data for one specific ply. The method has one argument: the
local index of the ply in the laminate (its position in the lay-up). if the laminate has N
plies, then the index must be 0 ≤ i ≤ N − 1. (The first ply has index 0.)
The method returns an Array containing 5 elements corresponding to the arguments of
the “addPly” method.
Obviously, the different data inserted in, or retrieved from the ClaLam object should be
II.4.5 Other data

The reference temperature of a laminate is accessed with the two following methods:
• “clearAllowables” has no arguments and erases all the allowables stored in a ClaLam.
• “insertAllowables” is used to add material allowables. This method must be used if the
calculation of failure indices or reserve factor is done using laminate allowables instead
of ply materials allowables. (See section II.3.3 for more explanation on the use of this
method.)
• “getDataAllowables” has no arguments and returns a Hash containing the data defining
allowables. (See the corresponding method in ClaMat class section II.3.3.)
• “setRefT” has one Real argument and sets the reference temperature of the laminate.
• “getRefT” returns the reference temperature (a Real object).
• “setRefH” has one Real argument and sets the reference moisture of the laminate.
• “getRefH” returns the reference moisture (a Real object).
• “setLaminateIlss” has one Real argument and sets the value of laminate inter-laminar
shear strength allowable at laminate level.
II.4.6. LAMINATE PROPERTIES 201
• “setAllPliesIlss” has one Real argument and sets the value of laminate inter-laminar shear
strength allowable for all the plies defined in the ClaLam.
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 lami-
nate “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
II.4.6 Laminate properties

The method “calcLaminateProperties” calculates the laminate properties of the ClaLam ob-
ject. 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 (other-
wise, 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:
• “get_ABBD” returns the 6×6 ABBD stiffness matrix. More precisely, the object returned
by this method is an Array of 6 elements. Each element corresponds to one line of the
matrix and is an Array of 6 Real objects.
• “get_G” returns the 2 × 2 out-of-plane shear stiffness matrix. More precisely, the object
returned by this method is an Array of 2 elements. Each element corresponds to one line
of the matrix and is an Array of 2 Real objects.
• “get_alfaEh1”, “get_alfaEh2” and‘ ‘get_alfaEh3” return 3-components vectors {αEh},

{αEh2 } and {αEh3 } as defined by equations (II.1.67), (II.1.68) and (II.1.69) respec-
tively.
• “get_alfaGh1” and “get_alfaGh2” return 2-components vectors {αGh} and {αGh2 } as

defined by equations (II.1.76) and (II.1.77) respectively.
• “get_betaEh1”, “get_betaEh2” and “get_betaEh3” return 3-components vectors {βEh},

{βEh2 } and {βEh3 } as defined by equations (II.1.82), (II.1.83) and (II.1.84) respec-
tively.
• “get_betaGh1” and “get_betaGh2” return 2-components vectors {βGh} and {βGh2 } as

defined by equations (II.1.91) and (II.1.92) respectively.
• “get_abbd_complMat” returns the 6 × 6 abbd compliance matrix. (Format similar as

“get_ABBD”.)
• “get_g_complMat” returns the 2 × 2 out-of-plane shear compliance matrix. More pre-

cisely, the object returned by this method is an Array of 2 elements. Each element corre-
sponds to one line of the matrix and is an Array of 2 Real objects.
• “get_alfae0”, “get_alfae1”, “get_alfak0” and “get_alfak1” return 3-components Array

containing the components of laminate CTE vectors {α0 }, {α1 }, {α0κ } and {α1κ } as de-
fined by expressions (II.1.71), (II.1.72), (II.1.73) and (II.1.74).
• “get_alfas0” and “get_alfas1” return 2-components Arrays containing the components of

laminate CTE vectors {α0s } and {α1s } defined by expressions (II.1.79) and (II.1.80).
• “get_betae0”, “get_betae1”, “get_betak0” and “get_betak1” return 3-components Array

containing the components of laminate CTE vectors {β0 }, {β1 }, {β0κ } and {β1κ } as de-
fined by expressions (II.1.86), (II.1.87), (II.1.88) and (II.1.89).
• “get_betas0” and “get_betas1” return 2-components Arrays containing the components

of laminate CTE vectors {β0s } and {β1s } defined by expressions (II.1.94) and (II.1.95).
• “get_engineering” returns a Hash containing equivalent engineering constants of the lam-

inate. More precisely in-plane moduli and Poisson coefficients are returned for in-plane
loading, in-plane with curvature constrained to zero, and pure flexion of the laminate.
Each element of the Hash is a pair String-Real. The different values of the Strings
are: "E_xx", "E_yy", "G_xy", "nu_xy", "nu_yx", "E_k0_xx", "E_k0_yy", "G_k0_xy",
"nu_k0_xy", "nu_k0_yx", "E_f_xx", "E_f_yy", "G_f_xy", "nu_f_xy", "nu_f_yx", "G_xz",
"G_yz".
• “get_LambdaT” returns the 2 × 2 in-plane thermal conductance matrix ΛT .

• “get_LambdaH” returns the 2 × 2 in-plane moisture conductance matrix ΛH .

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:
• “get_thickness” returns the total thickness of the laminate tlam .
• “get_surfacicMass” returns the surfacic mass of the laminate smlam .
• “get_averageDensity” returns the average density of the laminate ρlam .

T
• “get_R33T” returns the out-of-plane thermal conductance of the laminate R33 .
• “get_RhoCpH” returns the thermal surfacic capacity of the laminate (ρCp h)lam .
H
• “get_R33H” returns the out-of-plane moisture conductance of the laminate R33 .
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 203
II.4.7 Laminate load response

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, tem-
perature 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 calcula-
tion 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 with the object.
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:
• A ClaDb object. This object is necessary, because information about the material prop-
erties of the different plies may be necessary to perform the calculation.
• A real value corresponding to the orientation of loading wrt laminate axes. The angle is
given in degrees.
• A ClaLoad object containing the loading definition. (See Chapter II.5 for the description
of loads.)
• A logical parameter specifying whether the stresses and strains are to be calculated at the
bottom of each laminate ply.
• A logical parameter specifying whether the stresses and strains are to be calculated at
mid thickness of each laminate ply.
• A logical parameter specifying whether the stresses and strains are to be calculated at the
top of each laminate ply.
The three last parameters are optional and default to false (no calculation of the correspond-
ing layered results).
II.4.7.2 Laminate internal loads and strains

Several methods allow to recover results calculated at laminate level. All these results corre-
spond to the laminate results for the last call to method “calcResponse”:
• “isThermalLoadingDefined” returns a logical that specifies whether the last load response
calculation has been calculated with a thermo-elastic contribution.
• “getDeltaT” returns a Real values corresponding to the difference between the load aver-
age temperature and the reference temperature of the laminate.
• “getT0” returns a Real values corresponding to the average temperature used in the last
load response.
• “getGradT” returns a Real values corresponding to the temperature out-of-plane gradient

used in the last load response.
• “isMoistureLoadingDefined” returns a logical that specifies whether the last load re-
sponse calculation has been calculated with a hygro-elastic contribution.
• “getDeltaH” returns a Real values corresponding to the difference between the load av-
erage moisture and the reference moisture of the laminate.
• “getH0” returns a Real values corresponding to the average moisture used in the last load
response.
• “getGradH” returns a Real values corresponding to the moisture out-of-plane gradient

used in the last load response.
• “isMechanicaLoadingDefined” returns a logical that specifies whether the laminate con-

tain a load response. (When a laminate load response is calculated, a mechanical contri-
bution to the loading is mandatory.)
• “getNormalForces” returns the in-plane normal forces in an Array of three Real values.
This method has one optional argument corresponding to a rotation wrt laminate axes.
• “getMoments” returns the bending moments in an Array of three Real values. This
method has one optional argument corresponding to a rotation wrt laminate axes.
• “getShearForces” returns the out-of-plane shear forces in an Array of two Real values.
• “getNormalStrains” returns the in-plane average strains in an Array of three Real values.
• “getCurvatures” returns the curvature tensor in an Array of three Real values. This
• “getShearStrains” returns the average out-of-plane shear strains in an Array of two Real
values. This method has one optional argument corresponding to a rotation wrt laminate
axes.
• “getAverageInPlaneStresses” returns the average in-plane stress tensor components in an

Array of three Real values. This method has one optional argument corresponding to a
rotation wrt laminate axes.
• “getFlexuralStresses” returns the top surface stress tensor components corresponding to
bending moment assuming homogenous material. The components are returned in an
• “getAverageShearStresses” returns the average out-of-plane shear stress tensor compo-
nents in an Array of two Real values. This method has one optional argument corre-
sponding to a rotation wrt laminate axes.
• “getAverageInPlaneStrains” returns the in-plane average strain tensor components in an
• “getFlexuralStrains” returns the top surface strain tensor components corresponding to
bending moment. The components are returned in an Array of three Real values. This
• “getAverageShearStrains” returns the out-of-plane shear components of average strain
tensor in an Array of three Real values. This method has one optional argument corre-
sponding to a rotation wrt laminate axes.
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:
• “getPliesStrains” returns the components of the strain tensor stored in the layered results
of the laminate.
• “getPliesStresses” returns the components of the stress tensor stored in the layered results
of the laminate.
• “getPliesMechanicalStrains” returns the components of the Mechanical Strain Tensor
stored in the layered results of the laminate according to (II.1.31). This tensor corre-
sponds to the “Mechanical Strain Tensor” presented in Tables X.C.3 and III.2.4.
These three methods:
• Have an arbitrary number of arguments. Each argument corresponds to an identifier of the
layer and location at which the layered components are recovered. The identifier is given
as an Array of two elements: the ply local integer index and an String that can have "Inf",
"Mid" or "Sup" value. Among these layers, only those for which layered components
have been previously calculated and stored are returned by the method. If the call is done
without argument, all the layered results stored in the laminate are returned.
• They return components expressed in the ply coordinate system.

• The components are calculated assuming that σ33 = 0.
• The components are returned by the method only if their calculation and storage has been
required in the last call to “calcResponse”. (See section II.4.7.1.)
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:
• The two first elements identify the layer: they correspond to the integer index of the ply
between 0 and N − 1, and the String location in the ply ("Inf", "Mid" or "Sup"). (Note
that this does not correspond to the ply identifier. The integer index corresponds to the
position of the ply in laminate lay-up.)
• The next 6 real elements contain the components of the result in the following order: 11,
22, 33, 23, 13, 12.
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:
• “getPliesStrainsWrtLamAxes”,
• “getPliesStressesWrtLamAxes”,
• “getPliesMechanicalStrainsWrtLamAxes”.
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:
• “getPliesT” returns the temperature in plies.
• “getPliesDeltaT” returns the variation of temperature in plies.
• “getPliesH” returns the moisture in plies.
• “getPliesDeltaH” returns the variation of moisture in plies.
The arguments are the same as those of the method described in section II.4.7.3: they corre-
spond 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:
• The two first elements identify the layer: they correspond to the integer index of the ply
between 0 and N − 1, and the String location in the ply ("Inf", "Mid" or "Sup").
• The third element is a Real value containing the corresponding returned value.
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” returns an equivalent stress or strain corresponding to the components

stored in the laminate. For example, a Tresca or Von Mises equivalent stress.
• “getFailureIndices” is devoted to the calculation of failure indices like the Tsai-Hill or

Tsai-Wu. This method differs from the previous one by the fact that failure indices are
calculated from the stored results and corresponding allowables.
• “getReserveFactors” calculates reserve factors.
• “getStrengthRatios” calculates strength ratios.
“getDerived” and “getFailureIndices” have the same parameters:
• A ClaDb object that provides the definition of materials used in the laminate, and of the
corresponding allowables. If this first parameter is omitted, then the allowables stored in
ClaLam object are used instead of material allowables.
• An Array of Strings containing a list of criteria for the calculations.
• Then follows an arbitrary number of arguments. Each argument corresponds to an iden-

tifier of the layer and location at which the layered components are recovered. (Same
principle as methods returning plies strains and strains in section II.4.7.3.) If none of
these arguments identifier is provided, the calculation is done for all layers.
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 re-
turned 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 param-
eters 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 Ar-
ray, 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 re-
sponse. 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 defi-
nition 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.)
II.4.8. LAMINATE FINITE ELEMENT LOAD RESPONSE 209
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 re-
ferred 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 Fac-
tors, 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 calcu-
lation 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:
• FeResPost first calculates a list of all the entities (elements, or elements and their corner
nodes) for which mechanical, thermo-elastic or hygro-elastic loading components are
defined in the ClaLoad object. FeResPost calculates a load response and corresponding
finite element Results for all these finite element entities.
• When mechanical loading components are defined as finite element Results, it is the
responsibility of the user to first transform the components in such a way that their use by
FeResPost makes sense. This means that the Results must be expressed in the appropriate
coordinate system. (See also section II.5.6.)
• When mechanical loading components are defined as finite element Results, and when
for some components, and if some of the finite element entities (elements or nodes) are
not present in all the corresponding finite element Result stored in the ClaLoad object,
FeResPost assumes the corresponding components to be zero for the loading of the entity.
• When thermo-elastic or hygro-elastic components are defined as finite element Results:
– Values on upper and lower faces correspond to the finite element temperatures found
at layers Z1 and Z2 respectively.
– If values at Z1 and/or Z2 are not found, and a value is found at layer Z0 or NONE,
this value is used instead. Note that when both Z0 and NONE layers are found in
the layers, Z0 layer value supersedes the NONE layer value.
– If either of the two values at Z1 or Z2 is not found by either of the two methods
listed above, then the thermo-elastic or hygro-elastic contribution is not considered
for laminate response analysis of the current FEM entity.
• Non-layered vectorial or tensorial Results are calculated in laminate axes. Layered vec-
torial and tensorial Results are calculated in ply axes. Scalar Results are not associated
to a coordinate system.
• The “Ilss” and “Ilss_b” scalar results are always calculated at bottom layer of each ply,
even if no explicit request of output to bottom sub-layer has been done.
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”
Note that the same method with exactly the same arguments has been defined in the DataBase
class. (See section I.1.5.)
II.4.9. CALCULATION OF CRITERIA FROM FE STRESSES OR STRAINS 211
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”
Units
The different calculated results from the ClaLam object are expressed in the units system asso-
ciated 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 signifi-
cantly 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:
• “ClaDB” a ClaDb object from which ply allowables and needed for the calculations are
retrieved.
• “InRes” a tensorial Result object corresponding to “Stress Tensor”, “Strain Tensor” or
“Mechanical Strain Tensor” the components of which are used to estimate the criteria.
It is the responsibility of the user to provide the tensor corresponding to the requested
criteria.
• “FoS” a Real object corresponding to the factor of safety.
• “FiRfResReq” the requested criteria outputs. (See the description of method “calcFiniteElementRespons
for a detailed description of the argument.)
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.

The “ClaLam” class defines three methods for the management of units:
• “getUnits” returns a Hash containing the definition of units associated to the laminate.
• “setUnits” has a Hash argument and sets the units associated to the laminate.
• “changeUnits” has a Hash argument and changes the units associated to the laminate.
The ‘ash arguments or return values mentioned above have String keys and values as explained

Two methods allow to save or read ClaLam objects from an Array of Strings in neutral format.
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.

“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:
• The thermo-elastic loading of the laminate defined by a specified temperature.
• The membrane part of mechanical loading. Three such components lxx , lyy and lxy are
given.
• The flexural part of mechanical loading. Three such components lxx , lyy and lxy are
given.
• The out-of-plane shear part of mechanical loading. Two such components lxz and lyz are
given.
• The types of solicitation for each component of the mechanical loading. This type is
specified separately for each component of the mechanical loading. This means that
three components are specified for the membrane part, three components for the flexural
part and two components for the out-of-plane shear part. For each component, the type
of solicitation can be:
– “FM” means that a normal force are specified for a membrane component (ex-
pressed for example in N/m), a bending moments for a flexural component (in
Nm/m) and again a force per unit of length for out-of-plane shear (in N/m). “femFM”
has the same meaning as “FM” but specifies that the load components shall be ex-
tracted from the finite element results stored in the ClaLoad object when calculating
laminate load response (“Shell Forces” or “Shell Moments”).
– “SC” Means that strains are specified for membrane components (in m/m), curva-
ture for flexural components (in 1/m), and again average shear strain for the out-
of-plane shear components. Note that the shear components are given as angular
components γij . Also the xy component of curvature tensor is a kind of angular
component as defined by equation. “femSC” has the same meaning as “SC” but
specifies that the load components shall be extracted from the finite element re-
sults stored in the ClaLoad object when calculating laminate load response (“Shell
Strains” or “Shell Curvatures”, see equation II.1.43).
213
214 CHAPTER II.5. THE “CLALOAD” CLASS
– “NS” means that normalized stress is specified for the component whatever the part
of the loading is concerned.
The default values of loading are of the type “FM” with zero components. This means
zero normal forces, zero bending moments, and zero out-of-plane shear forces. When
the laminate load response is calculated, moisture and temperature load contributions are
taken into account only if they have been initialized in the ClaLoad object.
For thermo-elastic and hygrometric parts of loading, it is also possible to specify a load-
ing with finite element results. The type of loading is determined by the value of String
first argument of “setT” and “setH” methods which can be “fem” or “noFem”.
A list of the methods defined in “ClaLoad” class is given in Table II.5.1.
Table II.5.1: The different methods that have been defined in “ClaLoad” class.

new II.5.1 IV.5.4.4
initialize II.5.1
clone II.5.9
Manipulation of data defining ClaLoad object
setT II.5.3 IV.5.4.4
getTinf II.5.3
getTsup II.5.3
isTdefined II.5.3
unsetT II.5.3
setH II.5.3
getHinf II.5.3
getHsup II.5.3
isHdefined II.5.3
unsetH II.5.3
setMembrane II.5.4 IV.5.4.4
setFlexural II.5.4 IV.5.4.4
setOutOfPlane II.5.4
getMembrane II.5.4
getFlexural II.5.4
getOutOfPlane II.5.4
setToCombili II.5.5
setShellForces II.5.6 IV.5.6
getShellForcesCopy II.5.6
clearShellForces II.5.6
setShellMoments II.5.6 IV.5.6
II.5.1. CREATION OF AN OBJECT 215

getShellMomentsCopy II.5.6
clearShellMoments II.5.6
setShellStrains II.5.6 IV.5.6
getShellStrainsCopy II.5.6
clearShellStrains II.5.6
setShellCurvatures II.5.6 IV.5.6
getShellCurvaturesCopy II.5.6
clearShellCurvatures II.5.6
setShellTemperatures II.5.6
getShellTemperaturesCopy II.5.6
clearShellTemperatures II.5.6
setShellMoistures II.5.6
getShellMoisturesCopy II.5.6
clearShellMoistures II.5.6
getUnits II.5.7
setUnits II.5.7
changeUnits II.5.7
NDF lines
Attributes
Id II.5.2

The singleton method “new” is used to create ClaLoad objects. This method has no 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 char-
acteristics are the thermo-elastic and hygro-elastic contributions to loading.) The methods are:
• “setT” is used to set thermo-elastic part of loading. The method has two or three argu-
ments:
1. The first argument is a String specifying whether the laminate load response shall
use the finite element Result temperatures to calculate load response, or the two
constant values provided as arguments 2 and/or 3. (This argument is “fem” or
“noFem”.)
2. The second and/or third argument(s) are the laminate bottom and top temperatures.
These arguments are Real values. If only one temperature is provided, the bottom
and top laminate temperatures are initialized to the same value.
• “getTinf” returns a Real value corresponding to the bottom temperature.
• “getTsup” returns a Real value corresponding to the top temperature.
• “isTdefined” returns true if a temperature contribution has been defined in the ClaLoad,
and returns false otherwise.
• “unsetT” erases the temperature contribution defined in the ClaLoad object.
• “setH” is used to set hygro-elastic part of loading. The method has two or three argu-
ments:
1. The first argument is a String specifying whether the laminate load response shall
use the finite element Result moistures to calculate load response, or the two con-
stant values provided as arguments 2 and/or 3. (This argument is “fem” or “noFem”.)
2. The second and/or third argument(s) are the laminate bottom and top moistures.
These arguments are Real values. If only one moisture is provided, the bottom and
top laminate moistures are initialized to the same value.
• “getHinf” This function returns a Real value corresponding to the bottom moisture.
• “getHsup” This function returns a Real value corresponding to the top moisture.
• “isHdefined” returns true if a moisture contribution has been defined in the ClaLoad, and
returns false otherwise.
• “unsetH” erases the moisture contribution defined in the ClaLoad object.
Obviously, the different data inserted in, or retrieved from the ClaLoad object should be
II.5.4. SETTING AND GETTING MECHANICAL PARTS 217
II.5.4 Setting and getting mechanical parts

Three methods are used to set the mechanical part of loading stored in the ClaLoad object:
• “setMembrane” sets the membrane part of the loading. The method has from 1 up to
4 arguments. The first argument is an Array of three Real values corresponding to the
components of loading lxx , lyy and lxy given in loading axes. The five following optional
arguments are Strings giving the type of solicitation of the corresponding components.
The possible values of these types of solicitations are "FM", "femFM", "SC", "femSC",
and "NS". (See an explanation page 213.) If optional arguments are omitted, the default
value "FM" is assumed.
The “fem” versions of component loading types specify that when laminate load response
shall be calculated, the corresponding component shall be retrieved from the finite ele-
ment results stored in the ClaLoad object.
• “setFlexural” sets the flexural part of the loading. The method has the same argument
types as method “setMembrane”.
• “setOutOfPlane” sets the out-of-plane shear part of the loading. The method has from
1 up to 3 arguments. The first argument is an Array of two Real values corresponding
to the components of out-of-plane shear: lxz and lyz . The two optional arguments are
Strings corresponding to the type of solicitation of the components.
Each of the three “set” methods described above has a corresponding “get” method:
• “getMembrane” returns the membrane part of loading.
• “getFlexural” returns the flexural part of loading.
• “getOutOfPlane” returns the out-of-plane shear part of loading.

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
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:
N
X
Ttot = Tref + fi · (Ti − Tref ) .
i=1
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 ele-
ment 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 Temper-
atures” 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:
• “setShellMoments”, “getShellMomentsCopy” and “clearShellMoments” for the manip-
ulation of “Shell Moments”.
• “setShellStrains”, “getShellStrainsCopy” and “clearShellStrains” for the manipulation of
“Shell Strains”.
• “setShellCurvatures”, “getShellCurvaturesCopy” and “clearShellCurvatures” for the ma-
nipulation of “Shell Curvatures”.
• “setShellTemperatures”, “getShellTemperaturesCopy” and “clearShellTemperatures” for
the manipulation of “Shell Temperatures”.
• “setShellMoistures”, “getShellMoisturesCopy” and “clearShellMoistures” for the ma-
nipulation of “Shell Moistures”.
Obviously, the different data inserted in, or retrieved from the ClaMat object should be consis-
tent 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 219

The “ClaLoad” class defines three methods for the management of units:
• “getUnits” returns a Hash containing the definition of units associated to the load.
• “setUnits” has a Hash argument and sets the units associated to the loads.
• “changeUnits” has a Hash argument and changes the units associated to the loads.

Two methods allow to save or read ClaLoad objects from an Array of Strings in neutral format.
correspond to a single ClaLoad object definition.

“clone” method has no argument and returns a copy of the ClaLoad object.
Part III
Solver Preferences
221
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 special-
izing 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.
DataBase
NastranDb SamcefDb
Figure 1: Finite element DataBase classes hierarchy.
223
224 INTRODUCTION
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).

(See also methods in generic DataBase class.)
new 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.7 IV.2.4.1
getXdbLcNames III.1.1.8
getXdbScNames III.1.1.8
getXdbResNames III.1.1.8
getXdbLcScNames III.1.1.8
getXdbLcScResNames III.1.1.8 IV.2.4.6
getXdbLcInfos III.1.1.8 IV.2.4.6
printXdbDictionnary III.1.1.8
readXdb III.1.1.8 IV.2.4.6
XDB attachments
attachXdb III.1.1.9
detachXdb III.1.1.9
removeAllAttachments III.1.1.9
getNbrAttachments III.1.1.9
getAttachmentNames III.1.1.9
checkAttachmentExists III.1.1.9
Table III.1.1 – continued on next page
225
226 CHAPTER III.1. NASTRAN PREFERENCES
Table III.1.1 – continued from previous page

getAttachmentLcInfos III.1.1.9
getAttachmentNbrLoadCases III.1.1.9
getAttachmentLcNames III.1.1.9
getAttachmentLcScNames III.1.1.9
getAttachmentLcScResNames III.1.1.9
getAttachmentNbrSubCases III.1.1.9
getAttachmentScNames III.1.1.9
getAttachmentNbrResults III.1.1.9
getAttachmentResIds III.1.1.9
getAttachmentResNames III.1.1.9
getAttachmentResults III.1.1.9
importAttachmentResults III.1.1.9
getAttachmentResultsCombili III.1.1.9
getAttachmentDesVarHistory III.1.1.9 IV.2.7
getAttachmentConstrDefinitions III.1.1.9 IV.2.7
getAttachmentConstrHistory III.1.1.9 IV.2.7
getAttachmentObjectiveHistory III.1.1.9 IV.2.7
getAttachmentDesRespHistory III.1.1.9
setStorageBufferMaxCapacity III.1.1.9
getStorageBufferMaxCapacity III.1.1.9
getAttachmentElementExtId III.1.1.9
getAttachmentNodeInfo III.1.1.9
getAttachmentDictKeys III.1.1.9
getAttachmentDictionnary III.1.1.9
each_xdbRaw III.1.1.9
HDF attachments. (See also section I.6.11.)
attachHdf III.1.1.10 IV.2.9
detachHdf III.1.1.10
removeAllHdfAttachments III.1.1.10
getNbrHdfAttachments III.1.1.10
getHdfAttachmentNames III.1.1.10
checkHdfAttachmentExists III.1.1.10
getHdfAttachmentLcInfos III.1.1.10 IV.2.9
getHdfAttachmentNbrLoadCases III.1.1.10
getHdfAttachmentLcNames III.1.1.10 IV.2.9
getHdfAttachmentLcScNames III.1.1.10
getHdfAttachmentLcScResNames III.1.1.10
getHdfAttachmentNbrSubCases III.1.1.10
getHdfAttachmentScNames III.1.1.10 IV.2.9
227

getHdfAttachmentNbrResults III.1.1.10
getHdfAttachmentResIds III.1.1.10
getHdfAttachmentResNames III.1.1.10 IV.2.9
getHdfAttachmentResults III.1.1.10
readHdfAttachmentResults III.1.1.10 IV.2.9
Enabling/Disabling bulk cards or Results
enableBulkCards III.1.1.7
disableBulkCards III.1.1.7
getBulkCardsEnableInfos III.1.1.7
enableOp2ResElems III.1.1.7
disableOp2ResElems III.1.1.7
getOp2ResElemsEnableInfos III.1.1.7
enableXdbTables III.1.1.8
disableXdbTables III.1.1.8
getXdbTablesEnableInfos III.1.1.8
Coordinate system methods
getCoordSysCopy III.1.1.5
addCoordSys III.1.1.5
makeAllCoordSysWrt0 III.1.1.5
Group manipulation methods
getNodesAssociatedToElements III.1.1.6 IV.2.5.3
getNodesAssociatedToRbes III.1.1.6
getElementsAssociatedToNodes III.1.1.6 IV.2.5.3
getRbesAssociatedToNodes III.1.1.6
getElementsAssociatedToMaterials III.1.1.6
getElementsAssociatedToPlies III.1.1.6
getElementsAssociatedToProperties III.1.1.6
Iterators
each_coordSysId III.1.1.12
each_elemId III.1.1.12 IV.2.3
each_nodeId III.1.1.12
each_rbeId III.1.1.12
each_materialId III.1.1.12
each_propertyId III.1.1.12
each_nodeOfElement III.1.1.12 IV.2.3
each_cornerNodeOfElement III.1.1.12
Write methods
writeBdfLines III.1.1.3
writeNastranCard III.1.1.3 IV.2.5.1

writeNastranCards III.1.1.3 IV.2.5.1
writeNastranCardToVectStr III.1.1.3
writeNastranCardsToVectStr III.1.1.3 IV.2.2
Other methods (access to FEM definition and FEM modification)
getNbrRbes III.1.1.13
getMpcNodes III.1.1.13
getMpcDependentNodes III.1.1.13
getMpcIndependentNodes III.1.1.13
getElementPropertyId III.1.1.13
getNodeRcId III.1.1.13
getNodeAcId III.1.1.13
getNodeCoords III.1.1.13
fillCard III.1.1.4 IV.2.2, IV.2.3 and IX.1.3
insertCard III.1.1.4
insertCards III.1.1.4 IV.2.2
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 state-
ments. Its default value is a void String. (This argument corresponds to the jidtype in
Nastran.)
III.1.1. “NASTRANDB” CLASS 229
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:
• Generally, only the lines between “BEGIN BULK” and “ENDDATA” are interpreted.
(These words can also be lowercase.) In that case, all the lines before “BEGIN BULK”
statement are ignored, and if no “BEGIN BULK” statement appears in the file, no line is
interpreted.
• If the “BulkOnly” Logical parameter is set to “true”, the lines in the file are assumed
to correspond to lines if the Bulk Data Section of Nastran input. Then, lines “BEGIN
BULK” and “ENDDATA” are ignored.
• Generally, the “readBdf” method is called only once after the NastranDb object creation
to initialize the finite element model. However, additional files might help to add FEM
entities to the model. (For example, additional nodes used for the post-processing.)
• When a FEM entity that is supposed to be defined only once in a model, is read several
times, or already is defined in the DataBase before the call to “readBdf” method, only
the last entity is kept.
• One advises to limit the number of calls to the “readBdf” method because the method can
be time consuming. Indeed, at the end of each call, FeResPost updates a large number
of data structures in the “NastranDb” class, in this can take some time. (These data
structures correspond, for example, to containers associating elements and p roperties,
elements and materials, nodes and elements...) Therefore, a good way to work would
be to read all the BDF files by a single call to “readBdf”, the file being read including
different sub-files.
• The method accepts the reading of cards in short format fields, large format fields, and
free format fields. But for free format field, the separator must be a comma (“,”), and the
card must be written on one single line.
• Recognized Nastran cards are:
– The “GRID” card.

– The following element cards: “CBAR”, “CBEAM”, “CBEND”, “CBUSH”, “CBUSH1D”,
“CDAMP1”, “CDAMP2”, “CDAMP3”, “CDAMP4”, “CDAMP5”, “CELAS1”, “CELAS2”,
“CELAS3”, “CELAS4”, “CFAST”, “CGAP”, “CHEXA”, “CMASS1”, “CMASS2”,
“CMASS3”, “CMASS4”, “CONM2”, “CONROD”, “CPENTA”, “CQUAD”, “CQUAD4”,
“CQUAD8”, “CQUADR”, “CROD”, “CSHEAR”, “CTETRA”, “CTRIA3”, “CTRIA6”,
“CTRIAR”, “CTUBE”, “CVISC”, “PLOTEL” and “SPOINT”.
– The following multi point constraints cards: “RBE1”, ‘RBE2”, “RBE3”,“RROD”,
“RBAR”, “MPC” and “MPCADD”.
– The following coordinate system cards: “CORD1C”, “CORD1R”, “CORD1S”,
“CORD2C”, “CORD2R”, “CORD2S” and “CORD3G”.
Note however that the support for “CORD3G” coordinate system is limited. In
particular, Transformation from/to this type of coordinate system are not possible.
Actually, the support is limited to the reading of the “CORD3G” card from Nastran
BDF file (no reading from OP2), and the correct identification of the CS type in
such a way that an exception can be thrown if not supported CS transformation is
attempt.
– The following property cards: “PBAR”, “PBARL”, “PBEAM”, “PBEAML”, “PBUSH”,
“PCOMP”, “PCOMPG”, “PDAMP”, “PDAMP5”, “PDAMPT”, “PELAS”, “PELAST”,
“PFAST”, “PGAP”, “PMASS”, “PROD”, “PSHEAR”, “PSHELL”, “PSOLID”, “PTUBE”
and “PVISC” are totally supported. The cards“PBEND”, “PBUSH1D”, “PBUSHT”,
“PLPLANE” and “PLSOLID” are only partially supported1 .
– Four material cards are totally supported: “MAT1”, “MAT2”, “MAT8” and “MAT9”.
Some other material cards are only partially supported1 : “CREEP”, “MATS1”,
“MATT1”, “MATT2”, “MATT8”, “MAT3”, “MATT3”, “MAT4”, “MAT5”, “MATT4”,
“MATT5”, “MATT9”, “MAT10”, “MAT11” and “MATHP”.
• The “include”, “rfinclude” or “rfalter” statement lines are taken into account, but with
some limitations:
– The include statements must obviously comply with Nastran “include” syntax. Note
however that the rule that one first attempt an include of a file starting from the
Nastran working directory is not implemented. (How could one determine in which
directory the Nastran command has been run?) instead, the first include directory
that is tested is the current working directory of FeResPost.
1
“Partially supported” means mainly that not all input and output capabilities have been programmed. For
example, the conversion of all fields read from a bdf file is not systematically done. Also the writing of the card
in a bdf file will lead to very approximate results. But the support that has been programmed should be sufficient
for most post-processing applications.
– The user should use single slash character as directory level separator, and not back-
slash. (In other words, use “/” and not “
”.)
– when strings are quoted, use single quotes, and not double ones. (Use “ ’ ”, and not
“ " t’t’.)
– When variations of base file names are tested, the “UNIX” rules are followed. (See
MSC.Nastran manual.)
– The logical symbols in path names are interpreted. However no extensive tests have
been done to check that the programming is correct.
– Comments in file names may lead to problems.
– Quoted strings that span on several lines may lead to problems.
– The blank character is not completely supported so that its use should be avoided in
the definition of include file names.
The examples given in “RUBY/EX01” directory should help the reader to identify the
kinds of include statements that are accepted by FeResPost. (See section IV.2.2.1.)
In case of problems, we suggest:
– To be “defensive” and “reasonable” when using “include” statements in its bulk

Data Files.
– To check that the “include” statements comply with Nastran rules and the recom-
mendations given above.
– To set the “verbosity” argument to true to debug FeResPost (or the Nastran model).
– To report any problem with a small example, so that we can debug FeResPost if
necessary.
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.7 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.7 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.7 for the use of the corresponding singleton
methods. Note that the disabling of Nastran cards also influences the “readBdf” method.
III.1.1.3 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 correspond-
ing 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
4. A second format String argument specifying whether the fields in the card output are
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 ARGU-
MENT 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 ar-
guments), 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:
• If the number of arguments of the method is 5, the first element of each “card” Array
must be a String corresponding to the Nastran card name.
• If the number of arguments is 6, then the output card name argument is given and com-
mon to all the Nastran output cards. Then, the card name must not be included as first
element of the different Nastran card Arrays.
Remark that when “writeNastranCards” is called with 5 arguments, it is possible, with a sin-
gle 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 for-
matted 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
2. A second format String argument specifying whether the fields in the card output are
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 ar-
guments), 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” single-

ton 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.4 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”, “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:
• The first element of the Array (corresponding to index 0), is a String containing the name
of the Nastran card.
• Elements 1 to 8 correspond to the first line in the card definition (small field format).
• Elements 9 to 16 correspond to the second line in card definition (small field format).
• For each line, the fields 1 and 10 are neglected, except for the first line in which field 1
contains the name of the Nastran card.
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:
• We strongly advise to use “insertCards” method instead of “insertCard” to limit the num-
ber of calls to the method. Indeed, at the end of each insertion, FeResPost updates a
large number of data structures in the “NastranDb” class, in this can take some time.
(These data structures correspond, for example, to containers associating elements and
properties, elements and materials, nodes and elements...) Therefore, a good way to work
would be to collect all the cards to be inserted in the model in abig Array, and perform
the insertion operation only once.
• If one inserts a FEM entity that already exists in the database, the pre-existing entity is
replaced by the new one. If an entity is defined twice in the argument cards, only the last
card will remain inserted in the database at the end.
III.1.1.5 “CoordSys” methods

The “CoordSys” class allows the manipulation of coordinate systems for post-processing pur-
pose. This class is presented in Chapter I.2. One presents below the methods of NastranDb
class devoted to the manipulation of coordinate systems.
“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.
“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.
“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.6 Construction of Groups by associations

The list of “NastranDb” methods returning Groups defined by association follows:
• “getElementsAssociatedToNodes” returns a Group containing the list of elements asso-

ciated to the nodes of the Group argument.
• “getElementsAssociatedToMaterials” returns a Group containing the list of elements as-

sociated to the material(s) given as argument(s). The argument is an integer or an Array
of integers corresponding to the material IDs of the elements inserted in the list.
• “getElementsAssociatedToProperties” returns a Group containing the list of elements

associated to the property (properties) given as argument(s). The argument is an integer
or an Array of integers corresponding to the property IDs of the elements inserted in the
list.
• “getElementsAssociatedToPlies” returns a Group containing the list of elements associ-

ated to the ply (plies) given as argument(s). The argument is an integer or an Array of
integers corresponding to the ply IDs of the elements inserted in the list. The ply Ids are
the global ply identifiers referenced by PCOMPG Nastran data cards (Nastran model).
• “getNodesAssociatedToElements” returns a Group containing the list of nodes associated

to the elements of the Group argument.
• “getNodesAssociatedToRbes” returns a Group containing the list of nodes associated to

the MPCs of the Group argument.
• “getRbesAssociatedToNodes” returns a Group containing the list of MPCs associated to

the nodes of the Group argument.
III.1.1.7 “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
• “readOp2” method is used to read FEM entities or Results into the DataBase from an
“op2” file generated by Nastran. This method is also discussed in section III.1.1.2 for
the reading of finite element model. Here, one discusses more precisely the reading of
Results.
The method has 6 arguments:
1. A String that corresponds to the file from which model or Results are read.
2. A String that corresponds to the entities that are being read. Possible values of the
second argument are "Model/Results", "Model" and "Results". Generally, only the
third possible argument is used.
3. A “LcNames” argument that corresponds to the list of load cases for which the
Results are read. The argument may be:
(a) A Single String corresponding to the name of one load case.
(b) An Array of Strings corresponding to the list of load cases for which Results
are read.
If this argument is omitted, or if the Array argument contains no elements, the
Results of ALL load cases are read.
4. A “ScNames” argument that corresponds to the list of subcases for which the Re-
sults are read. The argument may be:
(a) A Single String corresponding to the name of one subcase.
(b) An Array of Strings corresponding to the list of subcases for which Results are
read.
If this argument is omitted, or if the Array argument contains no elements, the
Results of ALL subcases are read.
5. A “ResNames” argument that corresponds to the list of Results identifiers for which
the Results are read. The argument may be:
(a) A Single String corresponding to the Result ID.
(b) An Array of Strings corresponding to the list of Result IDs for which Results
are read.
If this argument is omitted, or if the Array argument contains no elements, ALL
Results are read.
6. A “PostParam” integer argument corresponding to the parameter “POST” in Nas-
tran Bulk Data File. Possible values of the parameter:
– “-1” (for Patran output),
– “-2” (for EDS I-DEAS output),
– “-6” (EDS Unigraphics output).
The default value of this argument is “-1” (op2 created for Patran). Note that
readOp2 will not work with the values “-4’ and “-5” which are valid POST pa-
rameters for Nastran.
The third, fourth, fifth and sixth arguments can be omitted. Note that Ruby identifies the
type of arguments by their order of appearance in the list. So, if “LcNames” argument
is omitted, but “ScNames” or “ResNames” argument is used, the “LcNames” must be a
void Array (“[]”). Examples of possible calls to “readOp2” method follow:
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results")
...
db.readOp2("../../EXEC/orbit_unit_xyz.op2","Results",\
"GRAV_X")
...
["GRAV_X"])
...
["GRAV_X", "GRAV_Y"])
...
[],[],"Stress Tensor")
...
[],[],["Stress Tensor", "Shell Forces", Shell Moments"])
...
["GRAV_X", "GRAV_Y"],"Statics",\
["Stress Tensor", "Shell Forces", Shell Moments"])
...
[],[],[],-2)
...
• Six singleton methods allow to disable or (re-)enable some entities when importing
model or result entities from Nastran op2 or bdf files, or to check the status of the bdf
cards or Results:
1. “enableBulkCards” is used to re-enable some Nastran card when reading model

entities from a Nastran bdf or op2 file.
2. “disableBulkCards” is used to disable some Nastran card when reading model enti-
ties from a Nastran bdf or op2 file.
3. “getBulkCardsEnableInfos” returns a Hash with String keys and Boolean values
that associates the enabled/disabled status to the different BDF card names.
4. “enableOp2ResElems” is used to re-enable “result element types” when reading
Results from an op2 file.
5. “disableOp2ResElems” is used to disable “result element types” when reading Re-
sults from an op2 file.
6. “getOp2ResElemsEnableInfos” returns a Hash with String keys and Boolean val-
ues that associates the enabled/disabled status to the different BDF card names for
results reading from op2 files.
The four 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” methods have no argument.
Other methods devoted to enable or disable composite layered Results are defined in the
generic “DataBase” class. These methods are presented in section I.1.3.2.
These enable/disable methods can be set to filter the results importation in order to reduce
the computation time, or the memory usage. The methods can also be used to prevent
FeResPost in the hopefully rare case when a bug occurs in the program for the reading of
a particular element, or the reading of the corresponding Results from an op2 file.
Presently, only some of the result data blocks of the file can be read:
• The “OUG” block corresponds to displacements, velocities, accelerations, temperatures...
• The “OGPFB1” block corresponds to Grid Point Forces.
• The “OES” blocks correspond to strains or stresses. The names of blocks that can be
read are: “OSTR1”, “OSTR1C”, “OES1C” and “OES1X”.
• The “OPG1” block corresponds to applied loads at nodes.
• The “OEF” blocks correspond to results in composite parts of the structure, or to forces
in surfacic or 1D elements. The names of blocks that can be read are: “OEFIT” and
“OEF1C”.
• The “OQG” blocks correspond to MPC or SPC forces.

The correspondence between the Nastran output requests and the DMAP data blocks written
in the “op2” file is given in Tables III.1.3 to III.1.10. 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:
• SOL 101: linear static or thermal analysis,
• SOL 103: linear eigen-values analysis,
• SOL 105: buckling analysis,
• SOL 106: non-linear static analysis,
• SOL 129: non-linear transient analysis,
• SOL 159: transient thermal analysis,
• SOL 400: non-linear static or transient analysis (corresponds to the SOL106 and SOL129
analyses).
III.1.1.8 “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 at-
tached to a database. (The corresponding methods with XDB attachments are described in
section III.1.1.9.)
“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.
“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:
XDB file.
“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:
XDB file.
“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:
XDB file.
“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:
XDB file.
“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:
XDB file.

The method returns an Array of Arrays. Each element of the Array contains the information
for one load case and sub-case identification:
• A String corresponding to the name of the load case.
• A String corresponding to the name of the sub-case. (As defined for modal analyses,
non-linear analyses...).
• A third String argument (unused so far).
• The first integer ID of the corresponding Results (usually, the load case ID).
• The second integer ID of the corresponding Results (usually, a mode ID, or a step ID...).
• The first real associated value (frequency, real eigen-value, real part of a complex eigen
value or continuation parameter...).
• The second real associated value (imaginary part of a complex eigen-value).

“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.
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.
“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 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 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.
XDB file.
All parameters, except the first one, can be omitted. Then the method assumes that a void Array
has been passed as argument.
Presently the support of “xdb” Results reading is more limited than the corresponding sup-
port for “op2” reading. Results that can be read are:
• Nodal displacements (translations and rotations),
• Nodal temperatures,
• SPC forces and moments,
• MPC forces and moments,

• Grid Point Forces,
• Element forces and moments,
• Element stresses,
• Element strains,
• Element Strain and kinetic energies, and energy loss.
• Composite ply stresses and strains.
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:
• 0D elements: CONM1 and CONM2 (for kinetic energy),
• 1D elements: CBAR, CBEAM, CGAP, CELAS1, CELAS2, CELAS3, CELAS4, CROD,

CBUSH and CFAST.
• 2D elements: CTRIA3, CQUAD4, CTRIA6, CQUAD8, CQUADR and CTRIAR.
• 3D elements: CHEXA, CPENTA and CTETRA.
The different characteristics of imported Results correspond to the characteristics of corre-

sponding 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.
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 ex-
ample, 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 en-
dianness. 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:
• FeResPost reads five of the first words in the XDB file. (Words 5, 8, 11, 12 and 15, index
0 corresponding to the first word at beginning in the file.)
• Each of these words is supposed to correspond to a positive integer value smaller than
65536. Hence, only the two less significant bytes of the words should be different than
zero.
• The test is done on the five integers and for each one, one attempts to guess if the endi-
anness is “big” or “little”. The result for word 15 determines which kind of endianness
is adopted. This word seems to correspond to “DATA BASE OPEN MODE FLAG” and
has been selected because one assumes that it always has a very small value.
• if the five words do not lead to the same conclusion, a warning message is issued. (This
might help the user to identify the source of the problem.)
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:
• The type of Result (stresses, forces, displacements,...),
• The type of element (CBAR, CQUAD4...),
• The format (real, complex,...).
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.9 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 XDB file is attached to the DataBase.
• Its content (lists of load cases, sub-cases and Results) is identified.
• The Results that are needed are then read from the file.
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.8.
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 endian-
ness 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 244 for more information.)
Several other methods are used to manage the Xdb attachments to a DataBase:
• “detachXdb” is used to delete an XDB attachment. The method has one String argument
corresponding to the name of the XDB file.
• “removeAllAttachments” removes all the XDB file attachments to a DataBase. This

• “getNbrAttachments” has no argument and returns the number of XDB files attached to
the DataBase.
• “getAttachmentNames” has no argument and returns an Array of Strings containing the

list of XDB files attached to the DataBase.
• “checkAttachmentExists” has one String argument containing the XDB file name, and
returns “True” if the XDB file is Attached to the DataBase, and “False” otherwise.
Extracting information of XDB file attachments

The following methods extract information related to the Results stored in an XDB file attached
to the DataBase:
• “getAttachmentLcInfos” returns information on load cases and sub-cases of Results found

in the attached XDB file. The information is returned in an Array. (More information
about the content of this Array is given in the description of method “getXdbLcInfos”.
page 242.)
• “getAttachmentNbrLoadCases” returns the number of load cases found in an XDB file.

• “getAttachmentLcNames” returns an Array of Strings corresponding to the load case

names found in the XDB file.
• “getAttachmentLcScNames” returns an Array containing two elements. The first element

is an Array of String containing the load case names found in the XDB file. The second
element is an Array of String containing the sub-case names found in the XDB file.
• “getAttachmentLcScResNames” returns an Array of three elements. Each element is an

Array of Strings. The first element is the list of load case names. The second element is
the list of sub-case names. The last element is the list of Result names.
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:
• “getAttachmentNbrSubCases” returns the number of sub-cases found in an XDB file.
• “getAttachmentScNames” returns an Array of Strings corresponding to the sub-case

names found in the XDB file.
• “getAttachmentNbrResults” returns the number of Result names identified in the XDB

attached file.
• “getAttachmentResIds” returns an Array of Integers corresponding to the identifiers of

the Results found in the XDB file.
• “getAttachmentResNames” returns an Array of Strings corresponding to the names of

the Results found in the XDB file.
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.
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 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.2. For example:
• The fifth argument can be a ResKeyList object. Then the Results are extracted on the
keys of the ResKeyList object.
• The fifth argument can be a Result object. Then the Results are extracted on the keys of
the Result object.
• Extractions can be performed on Groups. Then one specifies the target by a “Method”
String argument and a “GrpTarget” Group argument. The possible values of the “Method”
argument are listed in section I.4.2.1. (Description of “extractResultOnEntities” method
in the Result class.) When Results are extracted on Groups, one can also specify a list of
layers for which values are extracted. This argument is optional. (See below.)
• One can also specify a list of layers by providing a parameter which is an Array of String
or Integer values. Note however that the filtering on layers is done only when Results
for which several layers can be read. For example, this parameter does not influence the
reading of MPC Forces, Shell Forces...
• One can also specify a list of sub-layers by providing a parameter which is an Array
of String or Integer values. Note that this last parameter influences only the reading of
laminate stresses or strains. The reading of solid or shell element stresses and strains is
not affected by this parameter.
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]])
resTarget)
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:
• For element Results like element stresses or element forces the “Elements”, “ElemCen-
ters”, “ElemCorners” and “ElemNodes” extraction methods allow the use of a random
access algorithm. On the other hand, the “Nodes” and “NodesOnly” methods are asso-
ciated to an algorithm that sweeps sequentially the entire corresponding Result tables of
XDB file.
• For nodal Results, the efficient extraction methods are “Nodes”, “ElemNodes” and “Nodes-
Only”. They allow the use of a random access algorithm for the extraction of values from
each suitable table.
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:
• The Hash keys are Array of three Strings corresponding to the name of the load case, the
name of the sub-case, and the Result type name respectively.
• The Hash values are the Results.

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 ele-

mentary 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 ex-
tracted 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
XDB file(s).
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.
are read.
are read.
Results are read. Actually, the reading operation from an XDB combines the reading and some
of the extraction operations described in section I.4.2. For example:
the Result object.
in the Result class.) When Results are extracted on Groups, one can also specify a list of
layers for which values are extracted. This argument is optional. (See below.)
or Integer values.
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,
scNames,resNames,
resTarget)
scNames,resNames,
rklTarget)
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.
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)
Getting optimization data from XDB

It is possible to obtain some of the Nastran optimization (SOL200) results from an XDB at-
tachment. Four methods have been defined in NastranDb class:
1. “getAttachmentDesVarHistory” returns the history of design variables and has three pa-
rameters:
• “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 argu-

ments:

• “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:
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 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 parame-
ters:
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 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 equa-
tion (corresponding to the previous internal response).
5. “getAttachmentDesRespHistory” returns the history of design responses and has three
parameters:
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 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.
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:
• “setStorageBufferMaxCapacity” sets the capacity of storage. The method has one argu-
ments: a real value containing the size in Megabytes of the buffer.
• “getStorageBufferMaxCapacity” returns the storage buffer current total capacity. The

returned value is a real that corresponds to the capacity in Megabytes of the buffer. The
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.
“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 infor-
mation 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 cor-
respond 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 ele-
ment, Nastran generates a sequential XDB numbering starting at 1. The “EQEX-
INE” 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.
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 al-
lows 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:
• “getAttachmentElementExtId” that allows to retrieve an element external ID if one knows

its “XDB type” and its “XDB internal ID”. The method has three arguments:
1. A String containing the name of the attachment file,

2. An integer corresponding to the XDB element type,
3. An integer corresponding to the XDB internal ID of the element.
The method returns the integer Nastran external ID.
• “getAttachmentNodeInfo” has two arguments corresponding to the attachment file name

and the node XDB internal ID. It returns an Array of three integers corresponding to the
external ID, type and ACID.
• “getAttachmentDictKeys” has one String argument corresponding the XDB file name. It
returns an Array of two element Arrays. Each of these two element Arrays corresponds
to a dictionnary key identified by a String and an integer ID. (See the explanation above.)
• “getAttachmentDictionnary” has one String argument corresponding the XDB file name.
It returns a “Hash” object that associates dictionnary keys (Arrays of two elements, String
and integer) to Arrays of 22 integer elements containing information on the correspond-
ing table.
• “each_xdbRaw” is the iterator that allows to retrieve the information from an XDB table.
Iterator “each_xdbRaw” has three arguments:
1. A String containing the name of XDB file attachment.

2. An Array of two elements (String and integer) corresponding to the dictionnary key
ID, and identifying the table on which one iterates.
3. A String that specifies the translation of the words that are read for each field. Each
character of the String corresponds to translation of one word. The correspondence
is as follows:
– “i” or “l” means that the word is converted to a single precision integer.
– “u” means that the word is converted to a single precision unsigned integer.
– “I” or “L” means that 8 bytes (one or two words) are converted to a long long
(8 bytes integer).
– “U” means that 8 bytes (one or two words) are converted to a unsigned long
long (8 bytes unsigned integer).
– “f” or “d” means that the word is converted to a float (single precision real
value).
– “F” or “D” means that 8 bytes (one or two words) are converted to a double
(double precision real value).
– “s” means that the word is converted to a String.
– “S” means that 8 bytes (one or two words) are converted to String.
An example of call to the iterator follows:
db.each_xdbRaw(xdbFileName,["SUBCASES",0],"iiiiiiii") do |tab|
puts tab
end
The reader must read the examples to better understand the use of this iterator. The
examples are discussed in section IV.2.8.
III.1.1.10 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 reading of HDF files is possible only after the HDF5 shared library is loaded into
FeResPost. This is done by calling method “Post.loadHdf5Library” described in sec-
tion I.6.11.
• The HDF file is attached to the DataBase and its content (lists of load cases, sub-cases
and Results) is identified. Several methods give access to this information.
• The Results that are needed are then read from the file (into a Nastran Database, or
returned into a Hash).
sections.
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:
• “detachHdf” is used to delete an HDF attachment. The method has one String argument
corresponding to the name of the HDF file. (Same argument as the one used to attach the
file.)
• “removeAllHdfAttachments” removes all the HDF file attachments to a DataBase. This

• “getNbrHdfAttachments” has no argument and returns the number of HDF files attached
to the DataBase.
• “getHdfAttachmentNames” has no argument and returns an Array of Strings containing

the list of HDF files attached to the DataBase.
• “checkHdfAttachmentExists” has one String argument containing the HDF file name,
and returns “True” if the HDF file is Attached to the DataBase, and “False” otherwise.
Extracting information from HDF file attachments

The following methods extract information related to the Results stored in an HDF file attached
to the DataBase:
• “getHdfAttachmentLcInfos” returns information on load cases and sub-cases of Results

found in the attached Hdf file. The information is returned in an Array. (More informa-
tion about the content of this Array is given in the description of method “getXdbLcInfos”.
• “getHdfAttachmentNbrLoadCases” returns the number of load cases found in an HDF

file.
• “getHdfAttachmentLcNames” returns an Array of Strings corresponding to the load case

names found in the HDF file.
• “getHdfAttachmentLcScNames” returns an Array containing two elements. The first

element is an Array of String containing the load case names found in the HDF file. The
second element is an Array of String containing the sub-case names found in the HDF
file.
• “getHdfAttachmentLcScResNames” returns an Array of three elements. Each element is

an Array of Strings. The first element is the list of load case names. The second element
is the list of sub-case names. The last element is the list of Result names.
All these methods have a single String argument containing the name of the HDF file that must
• “getHdfAttachmentNbrSubCases” returns the number of sub-cases found in an HDF file.
• “getHdfAttachmentScNames” returns an Array of Strings corresponding to the sub-case

names found in the HDF file.
• “getAttachmentNbrResults” returns the number of Result names identified in the HDF

attached file.
• “getHdfAttachmentResIds” returns an Array of Integers corresponding to the identifiers

of the Results found in the HDF file.
• “getHdfAttachmentResNames” returns an Array of Strings corresponding to the names

of the Results found in the HDF file.
The first argument is the name of the HDF file that must have been previously attached to the
in the attached HDF file. If the argument is not provided, all the load cases are investigated
does not exist in HDF attachment an error message is issued.
Extracting Results From HDF file attachments

Two methods are used to extract results from Nastran HDF files:
• Method “readHdfAttachmentResults” is used to read Results from the HDF file. Results
are returned in a Hash object.
• Method “getHdfAttachmentResults” is used to read Results from the HDF file. Results
are returned in a Hash object.
The two methods have up to four arguments:
1. A String corresponding to the name of HDF file attachment from which Results are read.
2. A String or an Array of Strings corresponding to the names of load cases for which
Results are read.
are read.
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:
h=db.readHdfAttachmentResults(hdfName,lcNames,scNames,resNames)
h=db.readHdfAttachmentResults(hdfName,lcNames,scNames)
h=db.readHdfAttachmentResults(hdfName,lcNames)
h=db.readHdfAttachmentResults(hdfName)
When one of the “lcNames”, “scNames” or “resNames” is missing, nil or an empty Array, all
the load cases, sib-cases or result types are read.
III.1.1.11 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.12 Iterators
A first group of iterators iterate on finite element entities of the finite element model stored in
the DataBase.
• “each_coordSysId” iterates on the integer identifiers of coordinate systems.
• “each_elemId” iterates on the integer identifiers of elements.
• “each_nodeId” iterates on the integer identifiers of nodes.
• “each_rbeId” iterates on the integer identifiers of rigid body elements.
• “each_propertyId” iterates on the integer identifiers of properties.
• “each_materialId” iterates on the integer identifiers of materials.
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:
• “each_nodeOfElement”,
• “each_cornerNodeOfElement”.
These two iterators have one integer argument corresponding to the index of the element. They
iterate on the integer indices of nodes.
III.1.1.13 Other methods

Several other methods allow to obtain model information.
• “getNbrRbes” returns the number of rigid body elements in stored finite element model.
This method has no argument.
• “getMpcNodes” returns the number of dependent and independent nodes defining an
MPC. The argument of the method is the MPC integer ID.
• “getMpcDependentNodes” returns the number of dependent nodes of an MPC. The ar-
gument of the method is the MPC integer ID.
• “getMpcIndependentNodes” returns the number of independent nodes of an MPC. The
argument of the method is the MPC integer ID.
• “getElementPropertyId” has an integer argument corresponding to the element ID and
returns the corresponding property ID.
• “getNodeRcId” has an integer argument corresponding to the node ID and returns the
corresponding reference coordinate system ID.
• “getNodeAcId” has an integer argument corresponding to the node ID and returns the
corresponding analysis coordinate system ID.
• “getNodeCoords” returns the coordinates of a node. This method has one or two argu-
ments:
– The first argument is an integer corresponding to the node ID.

– The second argument is an integer or a string that corresponds to the coordinate
system in which the coordinates are expressed. The argument is an integer, or the
“AsIs” string. Note that if the argument is missing, the “AsIs” coordinate system is
considered.
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:
• For SOL 101: IntId[0] corresponds to the sub-case identifier, and IntId[1] is the load set
number.
• For SOL 103: IntId[0] corresponds to the sub-case identifier, and IntId[1] is the mode
number.
√ RealId[0] is the real eigenvalue. The corresponding eigen-frequency is given by
f = RealId[0]/2π. (Note however that this eigen-frequency is left undefined for the
Grid Point Forces.)
• For SOL 105: IntId[0] corresponds to the sub-case identifier, and IntId[1] is the mode
number. RealId[0] is the real eigenvalue, corresponding to the critical load. (Note how-
ever that this critical load is left undefined for the Grid Point Forces.)
• For SOL 106: IntId[0] corresponds to the sub-case identifier, and IntId[1] corresponds to
the step index in the sub-case. RealId[0] is the value of the continuation parameter for
which the Results have been saved in the “op2” file.
The “load case name” identifier associated to read or accessed results correspond to the “SUB-
TITLE” 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
Finally, the results found in the op2 file are presented by blocks corresponding to the dif-
ferent “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].)
III.1.2. NASTRAN RESULT CHARACTERISTICS 261
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 sum-
marized in Table III.1.2. (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.2: 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
"CbeamSt1" -101
"CbeamSt2" -102
"CbeamSt3" -103
"CbeamSt4" -104
"CbeamSt5" -105
"CbeamSt6" -106
"CbeamSt7" -107
"CbeamSt8" -108
"CbeamSt9" -109
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.3 to III.1.12. 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.3: Correspondence between the Nastran output cards and the “op2” result data
blocks. (Displacements read from OUG data blocks.)
Nastran “op2” Generated
Statement Data Block Result
“Displacements, Translational”
DISPL OUG “Displacements, Rotational”
“Displacements, Scalar”
“Velocities, Translational”
VELO OUG “Velocities, Rotational”
“Velocities, Scalar”
“Accelerations, Translational”
ACCEL OUG “Accelerations, Rotational”
“Accelerations, Scalar”
blocks. (Applied loads read from OPG data blocks.)
“Applied Loads, Forces”
OLOAD (3) OPG
“Applied Loads, Moments”
One can make a few remarks about the information given in Tables III.1.3 to III.1.12:
1. “Reaction Forces” Results are obtained by merging the contributions of MPC and SPC
forces. This result has been added to harmonize Nastran and Samcef importation of
Results.
2. The Nastran “CELASi” and “CDAMPi” elements produce scalar forces or moments that
are stored in “Beam Scalar Forces” Results.
3. “Applied Loads” are available both with the “OLOAD” and “GPFORCE” Nastran state-
ments. The first one provides forces and moments on nodes. The second one produces
the same Results at element corners.
A similar remark can be done for “MPC Forces” and “SPC Forces”.
4. The shear components of strain tensor output by Nastran are the angular deformations:
γij = 2ij . When these results are imported in a NastranDb, the corresponding com-
ponents are divided by two in such a way that a “physical” tensor is stored into the
blocks. (MPC and SPC forces read from OQG data blocks.)
“MPC Forces, Forces”
MPCFORCES (3) OPG “MPC Forces, Moments”
“MPC Forces, Scalar”
“SPC Forces, Forces”
SPCFORCES (3) OPG “SPC Forces, Moments”
“SPC Forces, Scalar”
“Reaction Forces, Forces” (1)
MPCFORCES
OPG “Reaction Forces, Moments” (1)
SPCFORCES
“Reaction Forces, Scalar” (1)
blocks. (Grid point forces read from OGF data blocks.)
“Grid Point Forces, Internal Forces”
“Grid Point Forces, Internal Moments”
“Grid Point Forces, MPC Forces” (3)
“Grid Point Forces, MPC Moments” (3)
“Grid Point Forces, SPC Forces” (3)
“Grid Point Forces, SPC Moments” (3)
GPFORCES (3) OGF
“Grid Point Forces, Reaction Forces” (1)
“Grid Point Forces, Reaction Moments” (1)
“Grid Point Forces, Applied Forces” (3)
“Grid Point Forces, Applied Moments” (3)
“Grid Point Forces, Total Forces”
“Grid Point Forces, Total Moments”
blocks. (Strains read from OES data blocks and corresponding to “STRAIN” output requests..)

“Strain Tensor” (4, 2))
“Beam Axial Strain for Axial Loads”
“Beam Axial Strain for Bending Loads”
“Beam Axial Strain for Total Loads” (8)
“Beam Shear Strain for Torsion Loads”
“Beam Deformations” (14)
“Beam Velocities” (14)
“Gap Forces” (15)
STRAIN OES “Gap Deformations” (15)
“Gap Slips” (15)
“Spring Scalar Strain”
“Bush Forces Strain Tensor” (12 and 13)
“Bush Moments Strain Tensor” (12 and 13)
“Bush Plastic Strain” (12 and 13)
“Curvature Tensor” (4, 7)
“Shear Panel Strain, Max”
“Shear Panel Strain, Average”
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.
5. 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.
6. 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 values of the corresponding strain tensor
component on the upper face of the shell.
7. 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.
8. “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
blocks. (Stresses read from OES data blocks and corresponding to “STRESS” output requests.)

“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” (8)
“Beam Shear Stress for Torsion Loads”
“Beam Forces” (12 and 13)
“Beam Moments” (12 and 13)
“Beam Deformations” (14)
“Beam Velocities” (14)
STRESS OES
“Gap Deformations” (15)
“Spring Scalar Stress”
“Bush Forces Stress Tensor” (12 and 13)
“Bush Moments Stress Tensor” (12 and 13)
“Bush Stress, Axial” (14)
“Bush Strain, Axial” (14)
“Bush Plastic Strain” (14)
“Shear Panel Stress, Max”
“Shear Panel Stress, Average”
blocks. (Nonlinear stresses read from OES data blocks and corresponding to “NLSTRESS”
output requests.)
“Nonlinear Stress Tensor” (5)
“Nonlinear Strain Tensor” (5)
“Nonlinear Effective Plastic Strain” (5)
“Nonlinear Effective Creep Strain” (5)
“Nonlinear Spring Scalar Strain”
“Nonlinear Spring Scalar Stress”
NLSTRESS OES “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”
blocks. (Element forces read from OEF data blocks or other “FORCE” output.)
“Shell Forces”
“Shell Moments” (6)
“Beam Forces” (9, 10,11)

“Beam Moments” (9, 10,11)
“Beam Warping Torque”
FORCE (2, 14) OEF “Beam Deformations”
“Beam Velocities”
“Gap Deformations” (15)
“Spring Scalar Forces”
“Bush Plastic Strain”
blocks. (Element forces read from OEE data blocks or “ESE”, “EKE” and “EDE” output.)
“Element Strain Energy”
ESE OEE “Element Strain Energy (Density)”
“Element Strain Energy (Percent of Total)”
“Element Kinetic Energy”
EKE OEE “Element Kinetic Energy (Density)”
“Element Kinetic Energy (Percent of Total)”
“Element Energy Loss”
EDE OEE “Element Energy Loss (Density)”
“Element Energy Loss (Percent of Total)”
Table III.1.12: Nastran Results for thermal calculations.

TEMPERATURE OUG “Temperature”
FLUX OEF “Temperature Gradient”
FLUX OEF “Conductive Heat Flux”
with CBEAM Results. For CBEAM Results, Stresses or Strains are recovered on the
extremities only.
9. Nastran “BEAM” type elements (CBAR, CBEAM, CBEND,...) do not output vectorial
or tensorial forces or moments. Instead, the different components are expressed in dif-
ferent coordinate systems (axial, plane 1 and plane 2). When importing these Results, a
conversion into tensorial format is done as follows:
   
Fxx Fxy Fxz Faxial V1 V2
F =  Fxy 0 0  =  V1 0 0  ,
Fxz 0 0 V2 0 0
   
Mxx Mxy Mxz Mtorsion −M2 M1
M =  Mxy 0 0  =  −M2 0 0  .
Mxz 0 0 M1 0 0
10. Nastran CBUSH elements produce forces and moments corresponding to the loads ap-
plied 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:
   
Fxx Fxy Fxz Fx Fy Fz
F =  Fxy 0 0  =  Fy 0 0  ,
Fxz 0 0 Fz 0 0
   
Mxx Mxy Mxz M x M y Mz
M =  Mxy 0 0  =  My 0 0  .
Mxz 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 coordiante 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:
     
Fxx Fxy Fxz 1 Fxx
f =  Fxy 0 0  ·  0  =  Fxy  ,
Fxz 0 0 0 Fxz
     
Mxx Mxy Mxz 1 Mxx
m =  Mxy 0 0  ·  0  =  Mxy  .
Mxz 0 0 0 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.
(a)
(b)
Figure III.1.1: CBUSH element axes definition. (Pictures extracted from [Sof04b].)
11. For CBAR elements, “Beam Forces” are always produced at the center of elements, and
“Beam Moments” at the two end nodes.
12. 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 re-
sults 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.
13. 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.
14. 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:  
Fxx 0 0
F = 0 0 0  .
0 0 0
No bending moments are produced by “CBUSH1D” elements.
15. 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”.
16. Various Nastran elements refer scalar points instead of grids. Nevertheless, Nastran con-
siders 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 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!
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.13. 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.
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.13 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.13: Correspondence between the Nastran output cards and composite stresses and
strains
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.14.
Table III.1.14: 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.25
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).

new III.2.1 III.2.1
initialize III.2.1
Reading model or Results
readSamcefDat III.2.1.1
readDesFac III.2.1.4
desFacResetFlags III.2.1.4
desFacSetFlag III.2.1.4
desFacUnsetFlag III.2.1.4
desFacGetFlag III.2.1.4
enableSamcefResCodes III.2.1.4
disableSamcefResCodes 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
271
272 CHAPTER III.2. SAMCEF PREFERENCES

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 III.2.1.5
getStorageBufferMaxCapacity 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
getElementsAssociatedToLaminates III.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
III.2.1. “SAMCEFDB” CLASS 273

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
getNbrRbes III.2.1.9
getNodeRcId III.2.1.9
getNodeAcId III.2.1.9
getNodeCoords III.2.1.9
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:
• A String object containing the name of the “banque” file from which the model is read.
This file must have been obtained by a “.sauve banque” command in Bacon. However,
it may have been split into several files.
• The second argument is a logical value (true or false) specifying whether the Groups
defined in the banque file are to be imported too. However, it may be useful not to import
the Groups from the banque file if one prefers to import them from a Patran session file
(see section I.1.2.1). This argument is optional and its default value is “true”.
• A Logical argument specifying the verbosity of the reading operations. 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.
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:
• The statement begins with keyword “input” or “INPUT”.
• It may be followed by a label (“input.label”).
• No abbreviations are accepted in the statement.
• The statement cannot contain comments.
• ...
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 abbre-
viations 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.
III.2.1.2 “CoordSys” methods

The “CoordSys” class allows the manipulation of coordinate systems for post-processing pur-
pose. This class is presented in Chapter I.2. One presents below the methods of SamcefDb
class devoted to the manipulation of coordinate systems.
“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.
“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.
“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.2.1.3 Construction of Groups by association operations

The list of “SamcefDb” methods returning Groups defined by association is given below:
• “getElementsAssociatedToNodes”. (See description in “NastranDb” class.)
• “getElementsAssociatedToMaterials” returns a Group containing the list of elements as-
sociated to the material(s) given as argument(s). The argument is an integer or an Array
of integers corresponding to the material IDs of the elements inserted in the list. Each
integer argument can be replaced by a String corresponding to the name of the material
defined in the DataBase.
• “getElementsAssociatedToPlies” returns a Group containing the list of elements associ-
ated to the ply (plies) given as argument(s). The argument is an integer or an Array of
integers corresponding to the property IDs of the elements inserted in the list. The ply
Ids are either the ply identifiers defined with the “.PLI” command (Samcef model),.
• “getNodesAssociatedToElements”. (See description in “NastranDb” class.)
• “getNodesAssociatedToRbes”. (See description in “NastranDb” class.)
• “getRbesAssociatedToNodes”. (See description in “NastranDb” class.)
• “getElementsAssociatedToLaminates” returns a Group containing the list of elements
associated to the laminate(s) given as argument(s). The argument is an integer or an
Array of integers corresponding to the property IDs of the elements inserted in the list.
• “getElementsAssociatedToAttr1s” returns a Group containing the list of elements of
which the first attribute is included in the arguments. The argument is an integer or
an Array of integers corresponding to the first attributes of the elements inserted in the
list.
• “getElementsAssociatedToAttr2s” returns a Group containing the list of elements of
which the second attribute is included in the arguments. The argument is an integer
or an Array of integers corresponding to the second attributes of the elements inserted in
the list.
III.2.1.4 Methods related to Results importation

“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:
• Asef. The first integer ID associated to the created Results is the number of the load
case. The first Real ID associated to the create Results is the deformation energy. The
default case ID of the created Result objects is “Load Case x” where “x” is replaced by
the integer ID of the case. The subcase ID associated to the load case is always “Statics”.
• Mecano. The first integer ID associated to the created Results is the time step ID. The
first Real ID associated to the create Results is the time (continuation parameter would
be a more appropriate name). The default case ID of the created Result objects is “Non-
Linear Load Case”. The subcase ID associated to the load case is always “Step x” where
“x” is replaced by the time step index.
• Dynam. The first integer ID associated to the created Results is the mode index. The
first Real ID associated to the create Results is the frequency. The default case ID of
the created Result objects is “Dynam Load Case”. The subcase ID associated to the load
case is always “Mode x” where “x” is replaced by the mode index.
• Stabi. The first integer ID associated to the created Results is the mode index. The first
Real ID associated to the create Results is the critical load. The default case ID of the
created Result objects is “Stabi Load Case”. The subcase ID associated to the load case
is always “Mode x” where “x” is replaced by the mode index.
Flags for reading of Results

Flags influencing the behavior of “readDesFac” method can be defined. The following single-
ton 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 consid-
ered flag. Among the above methods, only the last one returns a value.
Two such flags have been defined:
• The flag “ANGULAR_STRAIN_BUG” is used to correct a Samcef bug when importing
“Strain Tensor” Results . (See section III.2.2 for more information on the effect of this
flag.)
• The flag “DES_FAC_DEBUG” force SamcefDb methods related to the access to samcef
Des/Fac files to issue debugging messages that might help to identify problems when
trouble strike.
Similarly, two singleton methods allow to enable or disable Samcef Result codes:
• “enableSamcefResCodes” is used to enable or re-enable “result codes” when reading
Results from a pair of “des” and “fac” files.
• “disableSamcefResCodes” is used to disable “result codes” when reading Results from a
pair of “des” and “fac” files.
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 DES/FAC file is attached to the DataBase.
• Its content (lists of load cases, sub-cases, Results...) is identified.
• The Results that are needed are then read from the file.
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.
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:
• “detachDesFac” is used to delete an attachment. The method has one String argument
corresponding to the name of the FAC file.
• “removeAllAttachments” removes all the attachments to a DataBase. This method has

no argument.
• “getNbrAttachments” has no argument and returns the number of DES/FAC files attached
to the DataBase.
• “getAttachmentNames” has no argument and returns an Array of Strings containing the

list of FAC files attached to the DataBase.
• “checkAttachmentExists” has one String argument containing the FAC file name, and
returns “True” if the FAC file is Attached to the DataBase, and “False” otherwise.
Extracting information from DES/FAC attachments

The following methods extract information related to the Results stored in DES/FAC files at-
tached to the DataBase:
• “getAttachmentLcInfos” returns information on load cases and sub-cases of Results found

in the DataBase. The information is returned in an Array. (Format of returned Array is
described in chapter III.1.)
• “getAttachmentNbrLoadCases” returns the number of load cases found in an attachment.
• “getAttachmentLcNames” returns an Array of Strings corresponding to the load case

names found in an attachment.
• “getAttachmentLcScNames” returns an Array containing two elements. The first element

is an Array of String containing the load case names found in the FAC file. The second
element is an Array of String containing the sub-case names found in the FAC file.
• “getAttachmentLcScResNames” returns an Array of three elements. Each element is an

Array of Strings. The first element is the list of load case names. The second element is
the list of sub-case names. The last element is the list of Result names.
• “getAttachmentNbrLayers” returns the number of layers identified in an attachment.
• “getAttachmentLayerIds” returns an Array of Integers corresponding to the identifiers of

the layers found in an attachment.
• “getAttachmentLayerNames” returns an Array of Strings corresponding to the names of

the layers found in an attachment.
• “getAttachmentNbrSubLayers” returns the number of sub-layers identified in an attach-

ment.
• “getAttachmentSubLayerIds” returns an Array of Integers corresponding to the identi-

fiers of the sub-layers found in an attachment.
• “getAttachmentSubLayerNames” returns an Array of Strings corresponding to the names

of the sub-layers found in an attachment.
All these methods have a single String argument containing the name of the FAC file that must
• “getAttachmentNbrSubCases” returns the number of sub-cases found in an attachment.

• “getAttachmentScNames” returns an Array of Strings corresponding to the sub-case

names found in an attachment.
• “getAttachmentNbrResults” returns the number of Result names identified in an attach-

ment.
• “getAttachmentResIds” returns an Array of Integers corresponding to the identifiers of

the Results found in an attachment.
• “getAttachmentResNames” returns an Array of Strings corresponding to the names of

the Results found in an attachment.
The first argument is the name of the FAC file that must have been previously attached to the
in the attached FAC file. If the argument is not provided, all the load cases are investigated
does not exist in FAC attachment an error message is issued.
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.
1. A String corresponding to the name of FAC file attachment from which Results are read.
are read.
are read.
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.2. For example:
the Result object.
in the Result class.) When Results are extracted on Groups, one can also specify list of
layers and sub-layers for which values are extracted. This argument is optional. (See
below.)
or Integer values. Note however that the filtering on layers is done only when Results
for which several layers can be read. For example, this parameter does not influence the
reading of MPC Forces, Shell Forces...
• One can also specify a list of sub-layers by providing a parameter which is an Array
of String or Integer values. Note that this last parameter influences only the reading of
laminate stresses or strains. The reading of solid or shell element stresses and strains is
not affected by this parameter.
One can extract Results without specifying the ResKeyList, Result or Group argument. How-
ever, 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” argu-
ment 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,
resTarget)
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:
• The Hash keys are Array of three Strings corresponding to the name of the load case, the
name of the sub-case, and the Result type name respectively.
• The Hash values are the Results.

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
#~ Util::printRes(STDOUT,"brol",res)
end
The method “getAttachmentResultsCombili” is used to extract linear combinations of ele-

mentary 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 ex-
tracted 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).
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.
are read.
are read.
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.2. For example:
the Result object.
in the Result class.)
or Integer values.
• One can also specify a list of sub-layers by providing a parameter which is an Array of
String or Integer values.
One can extract Results without specifying the ResKeyList, Result or Group argument. How-
ever, 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” argu-
ment 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)
method,grpTarget)
resTarget)
rklTarget)
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.
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:
• “setStorageBufferMaxCapacity” sets the capacity of storage. The method has one argu-
ments: a real value containing the size in Megabytes of the buffer.
• “getStorageBufferMaxCapacity” returns the storage buffer current total capacity. The

returned value is a real that corresponds to the capacity in Megabytes of the buffer. The
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 cor-
responding 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.
• “each_coordSysId” iterates on the integer identifiers of coordinate systems.
• “each_elemId” iterates on the integer identifiers of elements.
• “each_nodeId” iterates on the integer identifiers of nodes.
• “each_materialId” iterates on the integer identifiers of materials.
• “each_samcefPlyId” iterates on the integer identifiers of samcef plies.
• “each_samcefLaminateId” iterates on the integer identifiers of samcef laminates.
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:
• “each_samcefMatIdName” produces pairs of integer and String elements.
• “each_samcefMatNameId” produces pairs of String and integer elements.
Two iterators loop on the nodes defining an element:
• “each_nodeOfElement”,
• “each_cornerNodeOfElement”.
These two iterators have one integer argument corresponding to the index of the element. The
return the integer indices of nodes.
III.2.2. SAMCEF RESULTS CHARACTERISTICS 285
III.2.1.9 Other methods

Several other methods allow to obtain model information.
• “getNbrRbes” returns the number of rigid body elements in stored finite element model.
This method has no argument.
• “getNodeRcId” has an integer argument corresponding to the node ID and returns the
corresponding reference coordinate system ID.
• “getNodeAcId” has an integer argument corresponding to the node ID and returns the
corresponding analysis coordinate system ID.
• “getNodeCoords” returns the coordinates of a node. This method has one or two argu-
ments:
– The first argument is an integer corresponding to the node ID.

– The second argument is an integer or a string that corresponds to the coordinate
system in which the coordinates are expressed. The argument is an integer, or the
“AsIs” string. Note that if the argument is missing, the “AsIs” coordinate system is
considered.
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 = γij /2). 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 modi-
fication 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:
   
Fxx Fxy Fxz N T1 T2
F =  Fxy 0 0  =  T1 0 0  ,
Fxz 0 0 T2 0 0
   
Mxx Mxy Mxz M −F2 F1
M =  Mxy 0 0  =  −F2 0 0  .
Mxz 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:
   
0 0 Fxz 0 0 F1
F = 0 0 Fyz  =  0 0 F2  ,
Fxz Fyz Fzz F1 F2 F3
   
0 0 Mxz 0 0 M1
M = 0 0 Myz  =  0 0 M2  .
Mxz Myz Mzz M1 M2 M 3
Table III.2.2: Correspondence between Samcef Result Codes and Scalar Results generated in
FeResPost.
Samcef Result Code Generated Result
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”
III.2.2. SAMCEF RESULTS CHARACTERISTICS 287
Table III.2.3: Correspondence between Samcef Result Codes and Vectorial Results generated
in FeResPost.
153 “Coordinates”
163 “Displacements, Translational”
191 “Displacements, Rotational”
“Reaction Forces, Forces”,
221
“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.)
*1411, *1413, 1431, 1435,
1436, *3411, *3413, 3431, “Stress Tensor”
3435, 3436,
*1421, 1445, 1446, *3421,
“Strain Tensor” (1)
3445, 3446
*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.
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 elemen-
tary 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 compo-
nents 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.
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 identifi-
cation of the appropriate CLA criterion.
Important remarks must be done about the coordinate system associated to each value in
the Result objects:
• The “ElemCS” coordinate system is obtained from the element topology. This means that
it can be reconstructed using the nodes defining the element. So the element coordinate
system looks more like a Nastran element coordinate system. This remark is necessary
because Samcef documentation uses often the words “element coordinate system” to
qualify what is rather a material coordinate system.
• The “ElemIJK” coordinate system is the same as “ElemCS”.
• The “MatCS” coordinate system corresponds to what is often called “element coordinate
system” in Samcef documentation. This modification of terminology has been done to
have a meaning closer to the one of Nastran Results.
III.2.3 Methods defined in “Post” module

The method “readGroupsFromSamcefDat” reads Groups from a Samcef Bacon data file and re-
turns 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:
III.2.3. METHODS DEFINED IN “POST” MODULE 289
Table III.2.6: Correspondence between Samcef Result Codes for Scalar failure indices gener-
ated in FeResPost (4). (Stars “*” can be replaced by 1, 2 or nothing and are related to the
sub-layer IDs.)
*1621, *3621 “Composite Failure Index, Tsai-Hill Version 1”
*1624, *3624 “Composite Failure Index, Tsai-Wu”
*1625, *3625 “Composite Failure Index, Hashin Version 1”
*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”
*7624 “Composite Critical Ply Failure Index, Tsai-Wu”
*7625 “Composite Critical Ply Failure Index, Hashin Version 1”
*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).
8621 “Composite Critical Ply, Tsai-Hill Version 1”
8624 “Composite Critical Ply, Tsai-Wu”
8625 “Composite Critical Ply, Hashin Version 1”
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 gen-
erated in FeResPost (3).
1628, 3628 “Composite Failure Index, Maximum Strain”
1629, 3629 “Composite Failure Index, Maximum Stress”
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.19
“Composite Failure Index, Hashin Version 2” “Hashin3D_b” II.1.10.19
“Composite Failure Index, Hashin Version 3” “Hashin3D_c” II.1.10.19
“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.25
III.2.3. METHODS DEFINED IN “POST” MODULE 291
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
293
Chapter IV.0
Introduction
This Part of the document is devoted to the presentation of examples illustrating various as-
pects 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:
• The finite element model of the structure is described in Chapter IV.1. In that Chapter,
one also gives information that will help the reader to use the finite element in the various
examples.
• In Chapter IV.2, one presents small examples of ruby programs using the FeResPost
library and finite element model and results of the “testSat” satellite. These results illus-
trate the use of various classes and methods of the FeResPost library.
• In Chapter IV.3, one presents an example of object-oriented post-processing program

written with ruby and using FeResPost library. The program uses the model and results
of “testSat” satellite to calculate margins of safety in honeycomb, skins and connections
• Chapter IV.5 presents a few examples that illustrate the use of composite classes.
• Finally, Chapter VII.1 shows how FeResPost COM component can be sued for CLA
analyses. (On Windows only.)
All the examples are delivered in “TESTSAT” directory. This directory contains four subdirec-
tories:
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. “RUBY” contains the small examples described in Chapter IV.2. The sub-directories in
“RUBY” are:
• The different “EX??” directories containing the small examples.

• “PROJECTa” is the main directory of the modular program described in Chap-
ter IV.3. Each
• “PROJECTb” is the main directory of the object oriented program described in
Chapter IV.4.
295
296 INTRODUCTION
3. 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.
4. 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 pro-
duce 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 that are used
to launch the example scripts, and the following variables are generally initialized:
set LIB=
set INCLUDE=
set RUBYLIB=D:/SHARED/FERESPOST/SRC/OUTPUTS/RUBY/RUBY_18
set PATH=C:/NewProgs/MINGW/bin;C:/NewProgs/RUBY/Ruby187/bin
Note that we add the directory containing GNU compiler executables in “PATH” environment
variable. This is necessary because some of the libraries delivered with GNU compiler are
needed to run the ruby extension.
(Of course the different paths you will initialize will have to be adapted to you peculiar
installation, and to the version of Ruby you are using.)
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:
• In section IV.1.1, one presents the satellite’s structure and its finite element model.
• The materials and element properties are described in section IV.1.2.
• The conventions used for the numbering of nodes, elements and MPCs, and the groups
that have been defined are given in section IV.1.3.
• In section IV.1.4, the loads and boundary conditions used in the examples of Chapter IV.2
are presented.
• Finally, one briefly describes in section IV.1.6 the way the FE model has been split into
several bulk data files, and the organization of these files into several directories.
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.
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.
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.
297
298 CHAPTER IV.1. A SMALL SATELLITE
Z
Y
X
Figure IV.1.1: Overall view of the satellite’s finite element model.
Z
Y
X
Figure IV.1.2: Metallic frame of the satellite lower box.

IV.1.1. PRESENTATION OF THE STRUCTURE AND ITS MODELING 299
Z
Y
X
Figure IV.1.3: Volumic modeling of sandwich panels.
Z
Y
X
Figure IV.1.4: Traversing elements for inserts’ modeling.

(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.
Z
Y
X
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 MID E (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
All CBAR elements receive PBARL properties:

IV.1.2. SATELLITE FEM MATERIALS AND PROPERTIES 301
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
G11 (MPa) 0.670 0.760
G22 (MPa) 0.670 0.760
G33 (MPa) 669.0 1276.0
G44 (MPa) 0.207 0.310
G55 (MPa) 138.0 193.0
G66 (MPa) 310.0 483.0
3
ρ (kg/m ) 50 72
−1
α (K ) 23.6 10−6 23.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
E1 (MPa) 0.500 290000
E2 (MPa) 0.500 5600
ν12 0.3 0.33
G12 (MPa) 0.500 3000
G1Z (MPa) 310.0 1100
G2Z (MPa) 138.0 1100
ρ (kg/m3 ) 50 1670
−6
α1 (K−1 ) 23.6 10 −1 10−6
α2 (K−1 ) 23.6 10−6 31 10−6
S1t (MPa) 0.050 1600
S1c (MPa) 0.050 500
S2t (MPa) 0.050 25
S2c (MPa) 0.050 140
Ss (MPa) 0.050 55
• For the traversing elements representing the inserts in sandwich panels, one assumes a
cylinder of 16 mm diameter. The material is Al 7010 T7451.
• The bars of metallic frame receive Al 7010 T7351 material and have a tubular cross-
section with 26 mm and 30 mm internal and external diameters respectively.
• The bars of struts receive Al 7010 T7351 material and have a tubular cross-section with
46 mm and 50 mm internal and external diameters respectively.
• Finally, when RBE2 elements are replaced by very stiff CBAR elements for thermo-
elastic calculations, one attributes the fake material 5001 to the CBAR elements. This
material is equivalent to Al 7010 T7351 but has no density. The bar cross-section is
assumed to be a rod of 30 mm diameter.
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”.
Other groups are defined in the session file:
IV.1.4. LOADS AND BOUNDARY CONDITIONS 303
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
• Groups corresponding to the various bars of the metallic frame. They are named
“bar_MXMY”, “bar_MXPY”,... There are 12 such groups that contain the CBAR tube
elements, the RBE2 connecting the sandwich panels to the metallic frame (or the cor-
responding stiff CBAR elements for thermo-elastic calculations), and the nodes of the
sandwich panels connected to the bar.
• Groups corresponding to the corner nodes of the metallic frame. Each groups contains
one CONM2, one RBE2 (or corresponding CBAR elements), and the corresponding
nodes. Those groups are named “corner_MXMYMZ”, “corner_MXMYPZ”,...
• Groups corresponding to the struts’ fittings. These groups are defined with conven-
tions similar to the groups of corner nodes. Those groups are named “fitting_MX”,
“fitting_PX”,...
• Six groups corresponding to individual struts. These groups are named “strut_A”, “strut_B”,
“strut_C”,...
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 satel-
lite 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:
• In file “force1_PAN_PZ.bdf”, one defines a force field corresponding to a unit acceler-

ation one the panel +Z and on the instrument. The force field corresponds to load id
616001. Similarly, one defines force fields in directions Y and Z with ids 616002 and
616003 respectively.
• Similarly on defines unit acceleration fields on the upper part of the structure in files
“force*_UPPER.bdf” (the upper panel, the struts and the fittings). These force fields
correspond to load IDs 617001, 617002 and 617003 respectively.
One also defines temperature fields for thermo-elastic load cases calculations:
• In files “temp_M100_PAN_PZ.bdf” and “temp_M100_PAN_PZ.bdf” one defines tem-

perature fields on the +Z panel. The two files correspond to a temperature of -100 ◦ C and
+120 ◦ C respectively. The corresponding load ids are 621001 and 621002.
• In files “temp_M100_PAN_PANLAT.bdf” and “temp_M100_PAN_PANLAT.bdf” one

defines temperature fields on lateral panels. The two files correspond to a temperature of
-100 ◦ C and +120 ◦ C respectively. The corresponding load ids are 622001 and 622002.
• In files “temp_GRAD_X.bdf”, ‘temp_GRAD_Y.bdf” and ‘temp_GRAD_Z.bdf”, on de-

fines three temperature gradients of 100 ◦ C/m on the entire structure in directions X, Y
and Z respectively. The corresponding load ids are 623001, 623002 and 623003.
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:
• The fixations stored in file “launch.bdf” correspond to the clamping of the four lower
corner nodes of the satellite. Practically, this is done by defining an RBE2 corresponding
to the launcher interface. The six degrees of freedom of the master node are fixed by an
SPC. This fixation can be selected by its number identifier: 701001.
• The fixations stored in file “orbit.bdf” correspond to a fixation of the six rigid modes.
This is done by defining the appropriate RBE3 element, with CELAS and SPC. This
fixation is particularly adapted to the calculation of thermo-elastic load cases in orbit and
is selected by its identifier 702001.
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. MAIN DATA FILES 305
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:
• “LAUNCH_ONE_MS2_X” for a unit acceleration in direction X.
• “LAUNCH_ONE_MS2_Y” for a unit acceleration in direction Y.
• “LAUNCH_ONE_MS2_Z” for a unit acceleration in direction Z.
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”:
• “ORBIT_ONE_MS2_X” for a unit acceleration in direction X.
• “ORBIT_ONE_MS2_Y” for a unit acceleration in direction Y.
• “ORBIT_ONE_MS2_Z” for a unit acceleration in direction Z.
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:
• “PANPZ_ONE_MS2_X” for a unit acceleration in direction X on panel +Z.
• “PANPZ_ONE_MS2_Y” for a unit acceleration in direction Y on panel +Z.
• “PANPZ_ONE_MS2_Z” for a unit acceleration in direction Z on panel +Z.
• “UPPER_ONE_MS2_X” for a unit acceleration in direction X on upper part of the struc-

ture.
• “UPPER_ONE_MS2_Y” for a unit acceleration in direction Y on upper part of the struc-

ture.
• “UPPER_ONE_MS2_Z” for a unit acceleration in direction Z on upper part of the struc-

ture.
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 temper-
ature fields are applied to the structure. The four load cases are defined as follows:
• “TEMP_PZ_COLD” corresponds to a temperature of -100 ◦ C on panel +Z and -50 ◦ C on

the rest of the structure.
• “TEMP_PZ_HOT” corresponds to a temperature of 120 ◦ C on panel +Z and 70 ◦ C on

the rest of the structure.
• “TEMP_PANLAT_COLD” corresponds to a temperature of -100 ◦ C on lateral panels

and -50 ◦ C on the rest of the structure.
• “TEMP_PANLAT_HOT” corresponds to a temperature of 120 ◦ C on lateral panels and

70 ◦ C on the rest of the structure.
The file “temp_grad.bdf” defines three load cases corresponding to gradients of 100 ◦ C/m ap-
plied on the entire satellite:
• “TEMP_GRAD_X” corresponds to a gradient in direction X.
• “TEMP_GRAD_Y” corresponds to a gradient in direction Y.
• “TEMP_GRAD_Z” corresponds to a gradient in direction Z.
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:
• “sol103.bdf” presents an example of Real modal analysis (SOL103).
• “sol105.bdf” presents an example of buckling analysis (SOL105).
• “sol106.bdf” presents an example of non-linear analysis (SOL106).
• “sol111_mp_xyz.bdf” presents an example of dynamic response analysis with a SOL111

solution sequence and with Complex Results output in magnitude-phase format.
• “sol111_ri_xyz.bdf” presents an example of dynamic response analysis with a SOL111

solution sequence and with Complex Results output in real-imaginary format.
• “sol200_a.bdf” corresponds to an optimization with design variables.
• “sol200_b.bdf” corresponds to a topometric optimization.
• “sol400.bdf” for a non-linear analysis with “SOL 400” solution sequence.
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:
• The directory “MAINS” contains the main data files that are used for Nastran calcula-
tions. The “main” files define various execution parameters, the load cases,... They also
include model files located in other directories. The main files have a “.bdf” extension.
IV.1.6. ORGANIZATION OF FEM IN FILES AND DIRECTORIES 307
• All files defining materials (“MAT*” cards) are located in “MATS” directory. All these
files have a “.bdf” extension.
• All files defining property cards are defined in “PROPS” directory. All these files have a
“.bdf” extension.
• In directory “FIXAS”, one places the files that define fixations of the structure. All these
files have a “.bdf” extension.
• In directory “LOADS” are the files that define loads applied to the structure. These
loads may include local forces, quasi-static loads, temperature fields for thermo-elastic
calculations,...
• In directory “MESH” are located all the elements defining the structure, its internal con-
nections, its GRIDS, its coordinate systems,... This is normally the largest directory. Note
that one makes the distinction between the internal connections modeled with RBE2 el-
ements, and their CBAR version for thermo-elastic calculations.
• In directory “EXEC_OP2”, the main bdf files should be copied. (Actually, they already
have been copied in the directory.) This is the directory in which the Nastran runs should
be done. Otherwise, it is also possible to make the calculations elsewhere. But then, the
examples should be modified, or symbolic links will have to be created.
• In directory “EXEC_XDB”, one finds the same bdf files as in “EXEC_OP2” directory
except that in each file the line “PARAM POST -1” as been replace by “PARAM POST
0”. This ensures that an xdb Result file shall be produced instead of an op2. The remarks
done for directory “EXEC_OP2” apply to directory “EXEC_XDB”.
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 defi-
nition 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:
• Section IV.2.1 presents the “Util” Module that is used in several of the examples.
• Section IV.2.2 shows how the model is read from a Bulk Data File and how Groups can
be manipulated. No Results are considered in those examples.
• Section IV.2.3 shows how some iterators are used.
• Section IV.2.4 is more specifically devoted to the manipulation of Results.
• In section IV.2.5, one presents two useful tools that can be used to generate loads for
subsequent Nastran calculations.
IV.2.1 Utilities Module

In file "RUBY/UTIL/util.rb", one defines the “Util” Module that contains several useful meth-
ods:
• “printRes” outputs a formatted listing of one Result object. The three argument of the
method are an output stream, a title name for the listing and the Result object to be
printed.
• “printGrp” outputs a summary of information on a Group. The three argument of the

method are an output stream, a title name for the listing and the Group object.
• “printDbResList” outputs a listing with the characteristics of all the Results stored in a
DataBase object. The two arguments are an output stream and a DataBase object.
• “printDbGrpList” outputs a listing with the characteristics of all the Groups stored in a
DataBase object. The two arguments are an output stream and a DataBase object.
309
310 CHAPTER IV.2. A FEW SMALL EXAMPLES
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
printf ("**********************************************************************\n\
raise x
end
The revised version reads main file “unit_xyz_V1.bdf” that illustrates several possible inter-
pretation of the “include” statements in Nastran Bulk Data Files. The user must uncom-
ment 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:
IV.2.2. EXAMPLES WITHOUT RESULTS 311
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 ma-
nipulation 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
IV.2.2.2 Group examples

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:
db=NastranDb.new()
db.Name="tmpDB"
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".
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:
• One initializes the DataBase “as usual”.
• One loops on the list of Group names stored in the DataBase, and for each groupName:
1. One gets a copy of the Group stored in the DataBase.

2. For the four types of entities one recovers the entities. Actually, one only stores the
respective sizes of the Arrays returned by the call to “getEntitiesByType”.
3. Finally, one prints the result (formatted print).
The program looks like this:
db=NastranDb.new()
db.Name="tmpDB"
# Prints Groups’ data :
printf("%20s%10s%10s%10s%10s\n","groupName","Nodes",\
"Elements","MPCs","CoordSys")
db.each_groupName do |groupName|
grp = db.getGroupCopy(groupName)
nodesNbr = grp.NbrElements
elementsNbr = grp.NbrNodes
mpcsNbr = grp.NbrMpcs
coordNbr = grp.NbrCoordsys
printf("%20s%10d%10d%10d%10d\n",groupName,nodesNbr,\
elementsNbr,mpcsNbr,coordNbr)
end
The example is given in file "RUBY/EX02/printGroups.rb".
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 opera-
tion).
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 “getElementsAssociat-
edToMaterialId” 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:
• The integer identifiers of the various materials are described in section IV.1.2.
• For the honeycomb 50 kg/m3 , the Group is created in two steps because two correspond-
ing materials have been defined: one MAT8 and one MAT9. The MAT8 corresponds to
the -Z panel which is modeled with surface elements. There is no corresponding dupli-
cation for Aluminum 2024 material which is isotropic (MAT1).
• After being created, the material Groups are stored in an Array called “matGroups”. This
storage simplifies the creation of the Groups by intersection at step 3.
• The three Groups are stored in the DataBase. This operation has no peculiar utility in
this example and could be cancelled.
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:
• “panelGroupNames”, an Array containing the names of the Groups corresponding to the

different sandwich panels is constructed explicitly.
• A “for” loop is nested into another “for” loop. The external one is the loop on the panel
Group names, and the internal one is the loop on the material Groups.
• In the external loop, one asks to the DataBase a copy of The Group with the appropriate
name.
• In the internal loop, on performs the intersection operations. Each Group is stored in
variable newGroup. It is named with a String obtained by concatenation of the names of
intersected Groups. Then it is inserted in the DataBase only if it contains entities.
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.4 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:
IV.2.4. EXAMPLES WITH RESULTS 317
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 call to method “readOp2” loads Results into the DataBase.
• One also generate coordinate Results.
• Then one builds three lists containing the load cases, sub cases and type names of all
the Results contained in the DataBase. Those are three Array of String objects. Their
respective contents are printed.
• One uses several iterators that read the lists of load cases, subcases and Result identifiers
and prints the output.
• Using the iterator “each_resultKey” one obtains copy of the Results stored in the DataBase,
prints the corresponding key identifiers, and the corresponding size.
The example is provided in file "RUBY/EX04/printResLists.rb".
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],\
Basically, the process can be divided into three parts:
1. Actual calculation of Von Mises stress. One recovers the Cauchy stress tensor corre-
sponding to the selected load case and selected Group. Then one derives a scalar equiva-
lent 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")
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):
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)
puts
puts "Maximum bar stress in strut A :"
puts
printf(" Sxx = %.2f\n",maxStressData[5])
puts
puts
Note that the way maximum stress is recovered from FE Results is different because Nas-
tran 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 cri-
terion 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:
• First the Cauchy Stress Tensor Result is extracted fro a Group of elements:
stress = db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Stress Tensor",
"ElemCorners",targetGrp,[])
• Then an Array of parameters is prepared:
criterionData=[]
criterionData << db
criterionData << 1.5625
criterionData << 2.41e6
criterionData << 1.41e6
criterionData << "XZ"
criterionData << "YZ"
criterionData << stress
(The reader will easily check that these parameters correspond to those liste in sec-
tion X.D.1.2.
• The criterion is calculated by a call to “Post.calcPredefinedCriterion” method:
output=Post.calcPredefinedCriterion("HoneycombAirbusSR",criterionData)
• Finally, the “output” Array returned by the method is exploited:
puts
puts "Worst results in panel +Z honeycomb :"
puts
STDOUT.printf(" on element %d\n",output[0])
STDOUT.printf(" on node %d\n",output[1])
STDOUT.printf(" on layer %d\n",output[2])
STDOUT.printf(" on sub-layer %d\n",output[3])
STDOUT.printf(" SL = %g\n",output[4])
STDOUT.printf(" SW = %g\n",output[5])
STDOUT.printf(" SR max = %g\n",output[6])
puts
Util.printRes(STDOUT,"Honey SR",output[7])
In this case, the “exploitation” consists simply in prints to standard output.

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.
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 corre-
sponding to STRAIN statement are multiplied by two by Nastran. So, when imported into a
DataBase, one divides the corresponding components by two (see remark 4 page 264 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:
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:
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 compo-
nents 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 proper-
ties. Then the components are printed after several transformations:
• Native results as stored in the “op2” file. These results are given in the ply local coordi-
nate system.
• Results in the element IJK coordinate system (Patran element coordinate system).
• Results given in DataBase defined Cartesian coordinate system number 7.
• Results given in material coordinate system.
• Results given in projected coordinate system 0.X.
• Results given in projected coordinate system 0.Y.

• Results given in element local (Nastran) coordinate system.

The transformations are performed with the following instructions:
...
stress.modifyRefCoordSys(db,0)
...
stress.modifyRefCoordSys(db,"elemIJK")
...
...
stress.modifyRefCoordSys(db,"matCS")
...
stress.modifyRefCoordSys(db,0,[1.0, 0.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 ex-
ample 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 co-
ordinate systems can further be modified without resulting in error messages. The successive
transformation of coordinate systems become:
...
...
stress.modifyRefCoordSys(db,"elemIJK")
...
...
stress.modifyRefCoordSys(db,"matCS")
...
...
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".
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.
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.
Extracting xdb Results information

The part of interest looks as follows:
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".
Manipulation of Complex Results

The results of "printXdbLcInfos.rb" are used to select load cases and sub-cases for which Re-
sults 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:
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 assem-
bled 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 argu-
ments. 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)
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:
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
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.
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:
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
Extracting Results from XDB attached file

The example “attachedXdbResults.rb” shows how Results can be extracted from an XDB at-
tachment. 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 correspond-
ing 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 “attachedXd-
bExtract.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]
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 ex-
ample, 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.
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:
• Function “psdFunction” calculates the PSD excitation as a function of the frequency.

In this case, as the excitation corresponds to a unit acceleration, the units for PSD are
(m/s2 )2 /Hz. Function “psdFunction” is called by “computeRms” function.
• “computeRms” function calculates and returns the RMS value of a result extracted from
PSD. The function has 8 arguments:
1. “db”: a NastranDb object containing the model and XDB attachment from which
results are read.
2. “xdbFileName” is the name of XDB attachment.
3. “lcName” is the name of the load case for which the results are extracted.
4. “resName” is the name of the Result to extract from the XDB file.
5. “maxNbrFreqsPerSlice” is an integer corresponding to the maximum number of Re-
sults to be manipulated simultaneously. (One cuts the integration in several “slices”
to avoid memory exhaustion when extracting the results.)
6. “integType” is a String corresponding to the same parameter in “calcRandomResponse”
method. Possible values are “LogLog” or “LinLin”.
7. “method”is a String corresponding to XDB extraction method on Group. This pa-
rameter corresponds to the “method” argument of the “getAttachmentNbrResults”
method in “NastranDb” class.
8. “grp” is the Group on which the Results are extracted. This parameter corresponds
to the “grp” argument of the “getAttachmentNbrResults” method in “NastranDb””
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 accel-
erations of 1 m/s2 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 perform-
ing 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
IV.2.5. A FEW USEFUL TOOLS 333
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:
• First, one opens the output file for writing.
• One recovers the data stored in the Result argument.
• Then, for each vector, one saves it into the “cards” array, but only if the norm of the
vector is larger than a specified value (not equal to zero).
• At the end, the printing is done by a call to “writeNastranCards” method.
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)
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 “card-
Name” argument is omitted.) On the other hand, each “values” Array has one additional ele-
ment. 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",\
forces3=db.getResultCopy("LAUNCH_ONE_MS2_Z","Statics",\
Grav.writeForce("force1_"+extName+".bdf",baseLID+1,csId,forces1)
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 dif-
ferent 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
• The function recovers the data stored in the current element (name of the Group, exten-
sion to be added to the output file name, and base of the load identifier).
• The coordinate system on which the force components are expressed are always 1001.
(This means that the function is not general and depends on the existence of a corre-
sponding coordinates system in the DataBase.)
• One recovers a Copy of the Group from the DataBase and stores it into “target”.
• One recovers from the DataBase the forces corresponding to the three load cases
“LAUNCH_ONE_MS2_X”, “LAUNCH_ONE_MS2_Y” and “LAUNCH_ONE_MS2_Z”.
Here again, this is done assuming that the corresponding Results have been loaded into
the DataBase before. Moreover, these load cases are assumed to correspond to unit accel-
erations in direction X, Y and Z respectively. The Results are stored in variables “force1”,
“force2” and “force3” respectively.
• For each force field, one modifies the reference coordinate system and sets it to 1001.
• Then the corresponding Results are printed by calling function “Grav.writeForce”.

Finally The “main” function looks like this:
def Grav.main()
# Creation of the dataBase :
db=NastranDb.new()
db.Name="tmpDB"
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:
• First the DataBase is initialized by reading the model and the Groups.
• A new Group, produced by union of several Groups is added to the DataBase.
• Results are read into the DataBase by calling “readOp2” method.
• The data are produced by filling the “data” Array.

• Finally, one calls function “Grav.genAllGravFields” with the appropriate arguments.

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/makeGravForc
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)
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)
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]
index+=1
end
else
values = []
values << lcId
for i in 0...(size-index)
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")
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:
• The Group of nodes “tmpGrp” is build by defining a range of nodes. After this operation,
the Groups contains the list of nodes numbered 1 to 99999. Most of these nodes do
not exist in the finite element model. To Ensure that they exist, one matches the Group
against the DataBase.
• temperature fields are build from coordinate field. This means that the coordinate Results
are created in the DataBase by a call to “generateCoordResults”. Then they are extracted
on the nodes of the Group.
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 re-
trieved.
3. “scName”, a String containing the name of the sub-case for which the results are re-
trieved.
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
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",\
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
IV.2.6. SAVING AND RETRIEVING RESULTS FROM AN SQL DATABASE 343
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:
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)" )
"Applied Loads, Forces (RI)" )
"Applied Loads, Moments (RI)" )
"Accelerations, Rotational (RI)" )
"Velocities, Rotational (RI)" )
"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"
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:
• “sol200_a.bdf” for an optimization with design variables.
• “sol200_b.bdf” for a topometric optimization.
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
IV.2.8. “RAW” ACCESS TO XDB FILE CONTENT 345
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 vari-
able 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:
• “printDictKeys” prints the list of dictionnary keys.

• “printDictionnary” prints the dictionnary. (This can be useful if one does not know the
field size for a given table.)
(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 ex-
ample 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[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.
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 cor-
responding 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:

• The first call to iterator is done to access the first “void” field. This allows to identify
an integer “modulo” that is used later to calculate the element internal ID for each field.
There is a “break” statements that forces an exit from iterator loop once the modulo has
been identified.
• Then, one calls the iterator a second time to perform the “real” reading of element results.
Note that the string “translation” argument is not the same.
• The definition of the translation string has been done by trials and errors. The reading
of Nastran documentation may help (for example the structure of OP2 data blocks in
Nastran DMAP manual [Rey04]) to understand the output, but there is no detailed de-
scription of XDB file content in MSC.Access documentation. This is true for results
tables, as well as for FEM description tables.
• For the “real” reading, one skips the “modulo” part.
• The element access type is set to 12 as one extracts forces on CBAR elements.
• The element internal ID is obtained by dividing key by the modulo.

• Method “getAttachmentElementExtId” is used to obtain the element external ID (Nastran

element ID).
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:
• The XDB file contains in this case 50 “PSHELL” tables because one outputs the results
of all optimization steps. One reads only the last “PSHELL” table. (Its index is 49 as the
numbering starts with 0.)
• Here again, the identification of “real” and “integer” values has been done by trials and
errors. (If you print the translated values in an output file, you see easily if you have
made an error.)
• A similar reading is done in for the CQUAD4 elements.
• Also, if you print the PSHELL cards, you will discover the for a topometric optimization,
Nastran generates a very large number of PSHELL cards. (One card per element in the
group of topometric optimization.) In our example, the numbering of the newly generated
cards starts with 1000000.
• The CQUAD4 elements that are read refer to the new generated property IDs.
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”:
• Initializes all the nodes to a default temperature for each load case:
grpNodes=db.getGroupAllNodes()
tempFields={}
hTD.each do |tempId,temp|
tempRes=Result.new
tempRes.Name="temperature"
tempRes.Format=1
tempRes.TensorOrder=0
grpNodes.each_node do |nodeId|
tempRes.insert(["NONE",nodeId],["NONE",temp])
end
tempFields[tempId]=tempRes
end
(The “TEMPD” cards are not saved in XDB file, and the default temperature for each
load case must be provided by the user. In function “getXdbTemperature” the default
temperatures are provided in a Hash that associates the load case integer IDs to real
temperatures.)
• The “SUBCASES” and “SUBCTITL” tables are also read from the XDB file. These
tables allo to associate temperature fields to subcase names. Note that in the method, one
uses the ‘TEMP(LOAD)” but not the “TEMP(INIT)”.
• The method returns a hash object that associates temperature IDs to corresponding scalar
results.
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 HDF file

Example “RUBY/EX23/testHDF.rb” illustrates the reading of Nastran HDF file results. First,
the library has to be loaded:
Then, the different methods described in section III.1.1.10 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[
end
db.readHdfAttachmentResults(hdfName,lcName,scName,resNames)
Chapter IV.3
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:
• In section IV.3.1, one presents the general architecture of the post-processing program.
• In section IV.3.2, two post-processing modules of the program are described in detail.
• A few last comments are done in section IV.3.4.
IV.3.1 Global structure of the program

Different modules corresponding to the different concepts used in the post-processing.
IV.3.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:
• “getResDirName” returns a String corresponding to a directory in which result files are

stored.
• “getModelDirName” returns a String corresponding to a directory in which model files

are stored.
• “createGroups” performs the definition of Groups in a DataBase. The method has two
arguments. The first argument is the DataBase object on which Groups are added. The
second argument is a String corresponding to the version of the DataBase.
In the example, the method reads Groups from a Patran session files. Then, other Groups
are defined by topological operations. The “version” argument is not used because all
351
352 CHAPTER IV.3. A MODULAR POST-PROCESSING
the DataBases contain the same Group definition. (Generally, Groups defined in different
DataBases are not the same.)
The “createGroups” method is used when a new DataBase is defined.
• “getDb” method returns the DataBase corresponding to a specified version. The version
is given as a String argument. The method first checks if the requested DataBase already
exists, i.e. if it is stored in @@dbList member data. If it already exists, the DataBase is
returned. If it does not exists, a new DataBase is created. It is read from a BDF file, and
groups are defined by a call to “createGroups” methods. The created DataBase is stored
in @@dbList and returned.
• Finally, the main method is the iterator “each”. This method has one argument cor-
responding to the version of the loop on load cases. The method defines two “proc1 ”
objects:
1. “postList” loads Results from an op2 file and loops on the corresponding list of load
cases. The list is given in the “lcList” Hash. The Results must be read from a single
op2 file. The method “yields” and Array containing the DataBase, the name of the
load case, and the name of the subcase for which Results are post-processed. After
yielding, the Results corresponding to the load case are destroyed.
Note that the programming of this “proc” has been done in such a way that it can
easily be switched to read Samcef result. This is the reason which the list of load
cases to be processed is given in a Hash argument.
2. “postCombili” builds Results by linear combination, yields the corresponding Re-
sults to a block, then destroys the Results. The created Results are defined by the
name of the loadcase, by an Array containing the factors of the linear combination,
by the list of elementary load case names.
When the two “proc” objects have been defined, they can be used by the definition of
operations to load, yield and destroy Results. This is done in a case statement. One
comments below several examples of uses:
– A first set of load cases corresponds to the three load cases at constant temperature.
They are defined as follows:
case version
when "thermo_const" then
db=getDb("ORBIT")
dirName=getResDirName()
op2Name="temp_disc.op2"
lcList={}
lcList[1]="TEMP_PZ_COLD"
lcList[2]="TEMP_PZ_HOT"
lcList[3]="TEMP_PANLAT_COLD"
lcList[4]="TEMP_PANLAT_HOT"
postList.call
1
For those who are not familiar with ruby language, “proc” objects can be considered as functions that can be
manipulated as objects.
IV.3.1. GLOBAL STRUCTURE OF THE PROGRAM 353
“thermo_const” is the “version” argument of the iterator. One first retrieves the
DataBase corresponding to orbital (thermo-elastic) load cases by calling “getDb”
method. Then, one specifies which op2 file is to be read. Finally, the list of load
cases to be read and post-processed is build. Finally, the proc is called.
– One gives below a second example with load cases defined by linear combinations
of elementary load cases. The piece of code looks as follows:
when "qs_launch" then

db=getDb("LAUNCH")
dirName=getResDirName()
op2Name="unit_xyz.op2"
elemNames=["LAUNCH_ONE_MS2_X","LAUNCH_ONE_MS2_Y",\
"LAUNCH_ONE_MS2_Z"]
db.readOp2(getResDirName()+"/"+op2Name,"Results",elemNames)
postCombili.call("GLOB_COMPRESSION",[0.0,0.0,-200.0],elemNames)
postCombili.call("GLOB_TENSION",[0.0,-15.0,180.0],elemNames)
postCombili.call("GLOB_LATERAL_1",[30.0,0.0,-50.0],elemNames)
postCombili.call("GLOB_LATERAL_4",[-21.21,21.21,-50.0],elemNames)
postCombili.call("GLOB_LATERAL_5",[-30.0,0.0,-50.0],elemNames)
postCombili.call("GLOB_LATERAL_6",[-21.21,-21.21,-50.0],elemNames)
postCombili.call("GLOB_LATERAL_7",[0.0,-30.0,-50.0],elemNames)
postCombili.call("GLOB_LATERAL_8",[21.21,-21.21,-50.0],elemNames)
elemNames.each do |name|
db.removeResults("CaseId",name)
end
elemNames=nil
GC.start
First, the DataBase is prepared and elementary load cases are read from “unit_xyz.op2”.
Then the “postCombili” proc objects is called with the appropriate arguments to
generate the linear combination of Results. At the end of the calculations, the ele-
mentary results are removed from the DataBase.
A peculiar case of iterator is defined by calling each iterator and yielding the returned
parameters given in the block:
when "All" then

LoadCases::each("qs_launch") do |db,lcName,scName|
yield([db,lcName,scName])
end
LoadCases::each("thermo_grad") do |db,lcName,scName|
end
LoadCases::each("thermo_const") do |db,lcName,scName|
end
IV.3.2 Two post-processing modules

One defines two-post-processing modules. The first module, described in section IV.3.2.1 uses
the Grid Point Forces and Moments to calculate connection margins of safety. The second
module, presented in section IV.3.2.3 uses the Cauchy stress tensor to calculate margins of
safety.
IV.3.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.
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 “cal-
cOneInterface”.
“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:

IV.3.2. TWO POST-PROCESSING MODULES 355
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 compo-
nents:
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 appro-
priate 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.

Sliding criterion
This criterion, defined by “crit_Sliding” method is used to calculate sliding margins of safety
with the following expression:
Cf ∗ Pmin
MoS = −1,
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.
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.
Gapping criterion
This criterion, defined by “crit_Gapping” method is used to calculate gapping margins of safety
Pmin
MoS = −1,
FoS ∗ (max(Faxial , 0) + Mbending /R)
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)
Insert criterion
This criterion, defined by “crit_Insert” method is used to calculate inserts margins of safety
1
MoS = v !2 − 1 ,
u ! 2
u Faxial Fshear
FoS t +
PSS QSS
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)
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”.
Definition of parameters
Some parameters depend on the interfaces. For example, the direction of connections, allow-
ables... 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.
IV.3.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 param-
eters 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 IV.3.2.3 a different modular design that allows not to repeat the writ-
ing of calculation methods, and at the same time to split the module into separate smaller en-
tities. 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.
IV.3.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 “Air-
bus” criterion for the calculation of honeycomb, a “MaxShear” criterion for the calculation of
honeycomb, and a “VonMises” criterion for the calculation of metallic parts.
Member data
The class has three member data:
• “groupName” is a String corresponding to the name of the Group of elements for which
the post-processing is done.
• “layerNames” is an Array of Strings which contains the list of layers for which the Re-
sults are retrieved. This variable is initialized by the first call to “getParameters” method.
• “stressTensor” contains a Result object with values corresponding to the Cauchy stress
tensor for a particular Group and on selected layers. This member data is filled by method
“calcOneGroup” is called
“calcOneGroup” method
This method has one more argument than the corresponding method in “Post_Connect” mod-
ule:
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 fol-
lows:
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.
Airbus criterion
This criterion, defined by “crit_HoneyAirbus” method is used to calculate margins of safety in
the honeycomb with the following expression:
1
MoS = v !2 !2 − 1 ,
u
u τL τW
FoSt +
σL σW
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.
MaxShear criterion
This criterion, defined by “crit_HoneyMaxShear” method is used to calculate margins of safety
in the honeycomb with the following expression:
σW
MoS = −1,
FoS ∗ τ
in which τ is the maximum shear stress and σW the transverse shear allowable.
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:
Ft
MoS = −1,
FoS ∗ σV M
in which σV M is the Von Mises equivalent stress and Ft the material tensile allowable.
“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” mod-
ule. This method is similar to the corresponding method in “Post_Connect” module.
IV.3.3. MAIN FUNCTION 361
“Post_skins” specialization module

This module is very similar to ‘Post_honeycomb” module.
IV.3.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.
IV.3.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 IV.4 an example of object-oriented post-processing.
Chapter IV.4
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 IV.3. 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 differ-
ence 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.
IV.4.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 cor-
responds 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".
IV.4.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 IV.3. 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:
363
364 CHAPTER IV.4. AN OBJECT-ORIENTED POST-PROCESSING
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".
IV.4.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
IV.4.2. TRANSFORMATION OF MODULES INTO CLASSES 365
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 "@minMosRe-
sults". 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 crite-
rion 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".
IV.4.2.2 A composite post-processing

The Class “PostComposite” calculates composite failure indices and reserve factors for a spec-
ified 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",
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”.
IV.4.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.
IV.4.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 compo-
nent, 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:

• The usual “db”, “lcName” and “scName” arguments.
• “refName”: is used to reference the extracted Results in “extracts” member data.
• “grpContent” the description of entities for which Results are extracted. This argument
contains a String that must correspond to exactly one extracted value. For example:
“Element 10”, “Node 17”.
IV.4.3. A NEW POST-PROCESSING FOR DYNAMIC RESULTS 367
• “resName”: a String containing the name of the Result stored in the DataBase “db” and
from which one value shall be extracted.
• “extractMethod”: a String corresponding to the extraction method of “getResultCopy”
DataBase method.
• “csId” the identifier of the coordinate system in which the Result shall be expressed. This
argument can be an integer or a String.
• “component” The name of the component one shall extract. This is a String with 0, 1
or 2 characters. For example: "", "Y", "ZZ", "ZY"... (The void String is used if no
extraction operation is necessary. This is the case when the Result obtained from the
DataBase is already scalar.
Then the following sequence of operations:
• One builds a Group “grp” that shall be used for the extraction of a Result from the
DataBase “db”:
grp=Group.new
grp.Name=refName
grp.setEntities(grpContent)
• The Result is extracted:
res=db.getResultCopy(lcName,scName,resName,extractMethod,grp,[])
• If the Result is vectorial or tensorial, the transformation of coordinate system is done:
if (res.TensorOrder>0) then
res.modifyRefCoordSys(db,csId)
end
• One builds a new Result “compRes” by extraction of a component. Of course, if the

Result is already scalar, one just performs an assignation operation:
if (component.size==0) then
compRes=res
elsif (component.size==1) then
compRes=res.deriveVectorToOneScal("Component "+component)
elsif (component.size==2) then
compRes=res.deriveTensorToOneScal("Component "+component)
end
• Then, one retrieves an Array “grpHashRes” from “extracts” member data. If the Array
is not found in the Hash by key “refName”, this means that this key appears for the first
time. then, one initializes a new Array and inserts it in “extracts”.
if @extracts.has_key?(refName) then
grpHashRes=@extracts[refName]
else
grpHashRes=[]
@extracts[refName]=grpHashRes
end
• Finally, one inserts extracted values in “grpHashRes”. The four values inserted are the
output index, the frequency, the magnitude and the phase:
compRes.set2MP
data=compRes.getData
mag=data[0][5]
phase=data[0][6]
grpHashRes << [compRes.getIntId(1),compRes.getRealId(0),mag,phase]
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
IV.4.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 defini-
tion 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")
forces=db.getResultCopy(lcName,scName,"Shell Forces (RI)",

forces.modifyRefCoordSys(db,"lamCS")
moments=db.getResultCopy(lcName,scName,"Shell Moments (RI)",

IV.4.4. MAIN FUNCTION 369
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)
res=moments.getR(theta)
...
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 num-
ber of rotation angles to be tested in the post-processing.
IV.4.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|
if current.respond_to?("calcAll") then
current.calcAll(db,lcName,scName)
end
end
GC.start
end
db=LoadCases.getDb("LAUNCH")
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.
IV.4.5 Definition of data

IV.4.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
• A String object containing the full name of the Nastran xdb file in which the dynamic
Results will be read.
• The Name of the Load Case for which Results shall be improved. This is also a String
argument.
• An integer argument corresponding to maximum number of dynamic sub-cases that can
be stored in the DataBase. This parameter allows to prevent the DataBase memory to
increase too much because it contains an excessive number of Results.
The first operation performed by “makeDynamLoop” is to build a list of sub-cases in sorted in
order of increasing frequencies:
IV.4.5. DEFINITION OF DATA 371
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.
IV.4.5.2 Data of post-processing

One presents the example of data for honeycomb calculation. Also examples of data for dy-
namic post-processing with “PostExtract” class are presented.
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 calcula-
tion 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
IV.4.5. DEFINITION OF DATA 373
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)
...
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",

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 repre-
sented in Figure IV.4.1 and IV.4.2.
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.
1800
"Force_launcher.txt" using 2:3
1600
1400
1200
1000
800
600
400
200
0
40 60 80 100 120 140 160
Figure IV.4.1: Magnitude of launcher interface loads in direction Z for axial unit acceleration
case.
180
"Force_launcher.txt" using 2:4
160
140
120
100
80
60
40
20
0
40 60 80 100 120 140 160
Figure IV.4.2: Phase of launcher interface loads in direction Z for axial unit acceleration case.
IV.4.6. ACCELERATION WITH PREDEFINED CRITERION 375
IV.4.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” meth-
ods of the class.
The data for the calculations of these versions of the criterion are defined in files “ DATA/data_Post_honeyco
and “DATA/data_Post_skins2.rb”. The activation/deactivation of these calculations can be ob-
tained 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"
IV.4.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:
• The excitation on the large mass below the satellite corresponds to a sinusoidal acceler-
ation of amplitude 1 m/s−2 . This is not a realistic case. Actually, a realistic excitation
should be a data of the post-processing. For this, the post-processing should be modified.
• One should try to program with Ruby and FeResPost a tool similar to the Patran tool
MSC.Random to calculate the response of structures to random excitations.
• ...
Chapter IV.5
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.5.1 Importing and exporting data

The first examples are presented in directory “TESTSAT/RUBY/EX12” and illustrate the im-
portation 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.)
377
378 CHAPTER IV.5. USING THE COMPOSITE CLASSES
IV.5.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
IV.5.3. COMPOSITE THERMAL PROPERTIES 379
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 (45ř):\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.5.3 Composite thermal properties

The example illustrates the calculation of laminate thermal properties. The example is pre-
sented 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})
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})
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.5.4 Extending composite classes

In the example of section IV.5.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.5.4.1 Extension “extendedCLA.rb”

Presently, only “ClaMat” and “ClaLam” classes have been modified in “extendedCLA.rb”.
Modification of “ClaLam” class

One adds methods devoted to the printing of stiffness and compliance matrices, laminate engi-
neering constants... The list of these functions include:
• “write_ABBD” for the writing of laminate ABBD stiffness matrix.
• “write_abbd_complMat” for the writing of laminate ABBD compliance matrix.
• “write_G” for the writing of laminate out-of-plane shear stiffness matrix.
• “write_g_complMat” for the writing of laminate out-of-plane shear compliance matrix.
• “write_alfaEGh123”, “write_alfaEh2” and “write_alfaEh3”, for the writing of laminate

CTE related quantities {αEh}, {αEh2 }, {αEh3 }, {αGh} and {αGh2 }.
IV.5.4. EXTENDING COMPOSITE CLASSES 381
• “write_alfa” for the writing of laminate CTE related vectors {α0 }, {α1 }, {α0κ }, {α1κ },
{α0s } and {α1s } respectively.
• “write_alfaEGh123”, “write_alfaEh2” and “write_alfaEh3”, for the writing of laminate

CTE related quantities {βEh}, {βEh2 }, {βEh3 }, {βGh} and {βGh2 }.
• “write_alfa” for the writing of laminate CTE related vectors {β0 }, {β1 }, {β0κ }, {β1κ },
{β0s } and {β1s } respectively.
• “write_engineering” for the printing of laminate equivalent engineering constants.

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 re-
sults):
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)
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_PliesInPlaneStra
Correspondingly, the ply failure indices and reserve factors can be calculated and written:
def write_crit(os,db,criteria,fos=1.0)
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 ar-
gument 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.
Modification of “ClaMat” class
Similarly, in “ClaMat” class, several printing methods have been defined. A list of these meth-
ods follows:
• “write_Compliance”,
• “write_InPlaneAlfaE”,
• “write_InPlaneAlfa”,
• “write_InPlaneBetaE”,
• “write_InPlaneBeta”,
• “write_InPlaneCompliance”,
• “write_InPlaneStiffness”,
• “write_OOPSAlfaG”,
• “write_OOPSAlfa”,
• “write_OOPSBetaG”,
• “write_OOPSBeta”,
• “write_OOPSCompliance”,
• “write_OOPSStiffness”,
• “write_Stiffness”.
Each of these methods has two arguments: an output stream object, and an optional angle θ.
(Its default value is 0.)
IV.5.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"
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.5.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.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.5.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"
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")
IV.5.5. OUT-OF-PLANE LAMINATE SHEAR RESPONSE 387
This example has been used for mainly debugging composite classes. It illustrates the calcula-
tion 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.5.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.5.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 composite ClaDb in which the materials and laminates definition is stored.
• A ClaLam object for which the stiffness matrix components are stored.
• A Real object containing the angle θ by which the laminate is rotated.
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 lam-
inate 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 “getNor-
malG”:
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.
IV.5.5. OUT-OF-PLANE LAMINATE SHEAR RESPONSE 389
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 ,
Qyz = Myy,y ,
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 de-
fined 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” calcu-
lation 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 el-
ement 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.5.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 Re-
sult 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")
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Shell Forces",
"ElemCenters",bottom,[])
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Shell Moments",
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Strain Tensor",
"ElemCenters",bottom,["NONE"])
ld.setShellStrains(res)
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Curvature Tensor",
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”.
IV.5.6. PRODUCING COMPOSITE FINITE ELEMENT RESULTS 391
os=File.open("Reference.txt","w")
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Shell Forces",
Util::printRes(os,"Shell Forces",res)
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Shell Moments",
Util::printRes(os,"Shell Moments",res)
Util::printRes(os,"Strain Tensor",res)
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Curvature Tensor",
Util::printRes(os,"Curvature Tensor",res)
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics","Stress Tensor",
Util::printRes(os,"Stress Tensor",res)
Util::printRes(os,"Strain Tensor",res)
res=db.getResultCopy("ORBIT_ONE_MS2_Z","Statics",
"Composite Failure Index, Tsai-Hill",
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["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],
["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],
["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:
• The example is done with a Group of 4 elements only. This has been done to allow an
easy comparison of Results. One could do the example with a Group corresponding to
the entire bottom panel to test the efficiency of the method. Also, composite Results can
be calculated at corner of elements. (You will discover that the algorithms involved are
very efficient, if you do not print the Results.)
• The out-of-plane shear stress/strain components retrieved from Nastran OP2 file do not
match exactly the values obtained with CLA classes. This is due to limitations of the
CLA out-of-plane shear theory that have been highlighted in section II.1.6 of the present
IV.5.7. MODIFYING UNITS 393
document. Results are similar though. Note also that the limitations of the out-of-plane
shear theory is general and concerns Nastran as well as FeResPost so that none of the
two results is really better than the other one.
• In the example, one tries to compare Results calculated directly with Nastran with those
produced by FeResPost. This is one possible use of the “calcFiniteElementResponse”
method, but not the only one. For example:
– One can produce Results corresponding to deteriorated allowables due to manufac-

turing problems, or ageing...
– Some calculation methods require modification of the loadings. sometimes, for
example, curvature is neglected, or only partially taken into account for the calcu-
lations.
– Also, with Nastran, composite Results can be produced, even when no laminate
(PCOMP) properties have been modeled. This is the case when equivalent shell
properties are modeled.
– ...
The examples given above are far from being exhaustive. The stress engineers expe-
rienced in composite calculations will very soon discover the advantages of the new
method. This is particularly true when Nastran is used because its composite capabil-
ities are poor. (Even though Patran compensates partially Nastran deficiencies with its
optional “Laminate Modeler” tool.)
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.5.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:
• A DataBase is read from neutral file “”.
• Then engineering constants of all the laminates in the DataBase are saved into file “oldUnits.txt”.
• The units of all materials in the DataBase are modified using method “changeUnitsAll-
Materials”.
• The modified DataBase is saved into file “testUnits.ndf”.
• Then engineering constants of all the laminates in the modified DataBase are saved into
file “newUnits.txt”.
The two files “oldUnits.txt” and “newUnits.txt” may be compared. They should contain equiv-
alent 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"]="řF"
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.)
Part V
FeResPost Python bindings
395
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=D:/SHARED/FERESPOST/SRC/OUTPUTS/PYTHON/PYTHON_27
set PATH=C:/NewProgs/PYTHON/PYTHON_27;C:/NewProgs/MINGW/bin
Note that we add the directory containing GNU compiler executables in “PATH” environment
variable. This is necessary because some of the libraries delivered with GNU compiler are
needed to run the python extension.
(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.)
V.0.2 Python versus ruby

Most of the differences of FeResPost Python and ruby libraries are directly related to the dif-
ferences 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.
397
398 CHAPTER V.0. INTRODUCTION
V.0.2.1 Creating class instances

New instances of the FeResPost classes are obtained by calling the corresponding class con-
structor:
...
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 sec-
tion V.1.2.)
V.0.2.3 Iterators
It is not possible to define several iterators in a given class in Python. Therefore, several spe-
cial “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_”, corre-
spondingly, 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 obvi-
ous: “each_ply” becomes “iter_ply”, “each_material” becomes “iter_material”,...
V.0.2. PYTHON VERSUS RUBY 399
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.
400 CHAPTER V.0. INTRODUCTION
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
mpcsNbr = grp.NbrMpcs
coordNbr = grp.NbrCoordSys
print("%20s%10d%10d%10d%10d"%(groupName,nodesNbr,elementsNbr,
mpcsNbr,coordNbr))
Note:
• The parentheses at the end of “iter_groupName” method call. (This is specific to the
Python language.)
• The “:” that defines the beginning of the instructionqs bloc in Python. This is also specific
to Python language, as is the fact that the indentation of the code defines the limits of
instruction blocs.
• And of course, the fact that ruby “each_groupName” iteration method is replaced by a
call to the Python “iter_groupName” function that returns an iterable object.
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 ac-
cess looks as follows:
401
402 CHAPTER V.1. PYTHON EXAMPLES
...
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),tm
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 corre-
sponding 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
V.1.4. OBJECT-ORIENTED POST-PROCESSING 403
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 IV.4.
Significant differences in the programming of the two projects deserve to be noted:
• It seems Python does not allow to define object methods. Therefore, for each object in
the ruby project that defines its own methods, one must define an additional class in the
Python project.
For example, the ruby project defines an instance of the “PostCauchy” class called “post_honeycomb”,
and the “post_honeycomb” object defines post-processing data in the instance methods.
With Python, one first defines a “PostHoneycomb” class that defines the methods used to
fill post-processing data. this means that one msut define an additional class.
• In ruby “LoadCases” module, several “proc” objects have been defined. In Python corre-
sponding module, one defines methods corresponding to the “procs”, because the equiv-
alent of ruby proc does not seem to exist in Python. (Python “lambdas” only allow the
definition of simple expressions.)
404 CHAPTER V.1. PYTHON EXAMPLES
Part VI
FeResPost as COM component
405
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.
these methods and attributes are the same as those available in the FeResPost ruby exten-
sion. 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:
• Chapter VI.2 presents the COM characteristics of the FeResPost generic classes de-
scribed in Part I.
• Chapter VI.1 presents the COM characteristics of the FeResPost CLA classes described
in Part II.
• Chapter VI.3 presents the COM characteristics of the FeResPost generic classes de-
scribed in Part III. (Solver classes.)
• In Chapter VII.1, one gives a few examples illustrating the use of FeResPost COM com-
ponent.
The present Chapter discusses the following points:
• The different ways to access the COM component depending on the language and/or on
the programming environment (section VI.0.1).
• In section VI.0.2, one describes conventions that have been adopted when translating the
ruby extension into a COM component. Information is given each time the ruby methods
are modified to be implemented into the COM component. For example, this is done for
407
408 CHAPTER VI.0. INTRODUCTION
iterators, operators, “clone” method... Also one explains how objects are created with the
component.
The installation (registration) of the COM component is described in section X.A.3.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 FeR-
esPost 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. ACCESSING THE COM COMPONENT 409
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 lan-
guage. 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:
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.)
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.
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:
...
...
db=frpApp.newObject("ClaDb")
...
mat=frpApp.newObject("ClaMat")
...
The corresponding VBscript lines of code follow:
...
...
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
VI.0.2. COM COMPONENT VERSUS RUBY EXTENSION 411
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:
• The first index range for this array corresponds to the number of key-value pairs of the
corresponding Hash argument.
• The second index ranges from 0 to 1 (two values). The value 0 corresponds to the key
and the value 1 corresponds to the value of the pair.
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 differ-
ent 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.
...
...
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 FeRes-
Post 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_”, cor-
respondingly, the COM component methods returning an Iterator object have a name that
starts with “iter_”. The correspondence between ruby extension methods and COM com-
ponent 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 not supported in COM. Therefore, the operators that are defined by ruby classes
are replaced by methods in COM component:
• Method “opAdd” corresponds to operator “+”,
• Method “opSub” corresponds to operator “-”,
• Method “opMul” corresponds to operator “*”,
• Method “opDiv” corresponds to operator “/”,
• Method “opPow” corresponds to operator “**” (power).

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. COM COMPONENT VERSUS RUBY EXTENSION 413
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 not supported by
COM classes.
Therefore, all the singleton methods defined in ruby extension are defined as instance meth-
ods in COM component. This means that before using such a method, an instance of the corre-
sponding 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 ex-
ists 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).
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 dis-
cussed 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 sec-
tion 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 other-
wise, 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:
• Iterator “each_material” in ruby extension becomes “iter_material”.
• Iterator “each_materialId” in ruby extension becomes “iter_materialId”.
• Iterator “each_laminate” in ruby extension becomes “iter_laminate”.
• Iterator “each_laminateId” in ruby extension becomes “iter_laminteId”.
• Iterator “each_load” in ruby extension becomes “iter_load”.
• Iterator “each_loadId” in ruby extension becomes “iter_loadId”.
The “makeCopy” method that returns a copy of the object.
VI.1.2 “ClaMat” class

This class corresponds to “IClaMat” interface.
415
416 CHAPTER VI.1. CLA CLASSES
Methods returning a 2D matrix, return a an Array with 2 dimensions. These methods are
“getCompliance”, “getStiffness”, “getInPlaneCompliance”, “getInPlaneStiffness”, “getOOP-
SCompliance”, “getOOPSStiffness”, “getInPlaneLambdaT”, “getInPlaneLambdaH”. (In ruby
extension, these methods return an array of arrays.)
VI.1.3 “ClaLam” class

This class corresponds to “IClaLam” interface.
“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”.
VI.1.4 “ClaLoad” class

This class corresponds to “IClaLoad” interface. No peculiar remark is to be done. The “make-
Copy” 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 com-
ponent. 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.
417
418 CHAPTER VI.2. GENERIC FERESPOST CLASSES
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 “Appli-
cation” class for the COM component. Presently, these methods are
• The methods “openMsgOutputFile”, “closeMsgOutputFile” and “writeAboutInforma-

tion”.
• The methods “readGroupsFromPatranSession” and “writeGroupsToPatranSession” to read

lists of Groups in Arrays.
• Several methods for the manipulation of Results like “cmp”, “max”, “sin”, “sq”, “exp”,...
• Dyadic “operators” on Results like “opAdd”, “opMul”,...
• The “convertBlob” method deals with Array of Bytes (unsigned char) instead of Strings
in the ruby extension.
• ...
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:
• “setCurrentDirectory” has one string argument and sets the server current, or working
directory.
• “getCurrentDirectory” has no argument and returns a string corresponding to the server

current working directory.
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”, “disableLayeredResultsRead-
ing”, “enableSubLayersReading” and “disableSubLayersReading” in the ruby extension generic
VI.2.3. GROUP CLASS 419
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 “getStorageBufferMax-
Capacity”.
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:
• The iterators are now “iter_element”, “iter_mpc”, “iter_node” and “iter_coordsys” in-
stead of “each_element”, “each_mpc”, “each_node” and “each_coordsys”.
• The four operators “+”, “-”, “*” and “/” are replaced by the methods “opAdd”, “opSub”,
“opMul” and “opDiv” respectively.
• The “toBlob” and “fromBlob” methods deal with Array of Bytes (unsigned char) instead
of Strings in the ruby extension.
• The “makeCopy” method that returns a copy of the object.
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:
• The iterators are now “iter”, “iter_key” and “iter_values”.
• The five operators “+”, “-”, “*”, “/” and “**” are replaced by the methods “opAdd”,
“opSub”, “opMul”, “opDiv” and “opPow” respectively.
• The “getData” method returns a 2D Array, instead of an array of arrays in the ruby
extension.
• The “makeCopy” method that returns a copy of the object.

420 CHAPTER VI.2. GENERIC FERESPOST CLASSES
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:
• The property “each_key” is here named “iter_key”.
• The “getData” method returns a 2D Array, instead of an array of arrays as in the ruby
extension.
• The “makeCopy” method returns a copy of the object.

Chapter VI.3
Supported Solvers
The two classes that correspond to the two supported solvers (Nastran and Samcef) are com-
plete.
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 “makeCopy” method that returns a copy of the dataBase.
• Several iterator methods with or without argument: “iter_coordSysId”, “iter_elemId”,

“iter_nodeId”, “iter_rbeId”, “iter_materialId”, “iter_propertyId”, “iter_nodeOfElement”,
“iter_cornerNodeOfElement”. When these iterators have arguments, they are imple-
mented with methods and not with properties.
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 “makeCopy” method that returns a copy of the dataBase.

“iter_nodeId”, “iter_materialId”, “iter_samcefPlyId”, “iter_samcefLaminateId”,
“iter_samcefMatIdName”, “iter_samcefMatNameId”, “iter_nodeOfElement”,
421
422 CHAPTER VI.3. SUPPORTED SOLVERS
Part VII
FeResPost Examples with COM

Component
423
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.3.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:
• The most detailed example is given in section VII.1.1.1 where a python program calcu-
lates and prints laminate properties and load responses. (In the other examples, one only
presents the aspects of programming peculiar to the language.)
• In section VII.1.1.2, the ruby version of the program is given.
• The VBscript version is given in section VII.1.1.3. (Even though you will see that there
is a problem in this example.)
• In section VII.1.1.4, one programs the example in C++. This requires a compilation of
the example.
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:
425
426 CHAPTER VII.1. COM EXAMPLES WITH VARIOUS LANGUAGES
import sys
import win32con
from win32com.client import Dispatch, constants
Then the program defines several methods that are used in the main program:
• The method “id2str” converts an idfier returned by one CLA method into a string that
can be used when results are printed. Remember that a CLA idfier is either an integer, a
String or an Array containing one integer and one String. The method “id2str” tests the
type of the “id” argument and performs the necessary operations to convert it to a String.
• The method “printLamProperties” writes a laminate definition and several of its proper-
ties (ABBD matrix, G matrix, CTE vectors...). The method has three arguments:
– “db”: a ClaDb object (composite dataBase). The laminate shall be retrieved from
this dataBase.
– “os”: the output stream in which results are written.
– “lamID”: an idfier corresponding to the ClaLam object for which properties are
written.
The lamID argument is used to obtain a copy of the laminate from the dataBase. Then, the
definition and the properties are written in the output stream. The programming lines that
perform these operations are easy to understand and require no additional explanation.
• The method “printLoadResponse” calculates the laminate load response for a selected
loading. The method has six arguments:
– “db”: a ClaDb object (composite dataBase). The laminate and the load used in
calculations shall be retrieved from this dataBase.
– “os”: the output stream in which results are written.
– “lamID”: an idfier corresponding to the ClaLam object for which load response is
calculated.
– “loadID”: an idfier corresponding to the ClaLoad object for which load response is
calculated.
– “theta”: a real argument corresponding to the angles of load applied to laminate wrt
laminate axes.
– “criteria”: an Array of Strings corresponding to the list of criteria for which reserve
factors are calculated.
At the beginning of the method, the ClaLam and ClaLoad objects are retrieved from the
dataBase and the laminate load response is calculated as follows:
lam=db.getLaminateCopy(lamID)
load=db.getLoadCopy(loadID)
lam.calcResponse(db,theta,load,True,True,True)
VII.1.1. USING COM COMPONENT WITH SEVERAL LANGUAGES 427
(Note that the ply result calculation is requested at bottom, mid and upper layers of each
ply.) Then several results are extracted from the ClaLam object and printed in output
stream:
– The laminate normal forces, bending moments, normal strains and curvatures, in
laminate axes.
– The ply stresses in ply axes.
– The ply strains in ply axes.
– The reserve factors for the selected criteria. These reserve factors are calculated
with a unit safety factor.
Note that other results could be calculated as failure indices. This is left as an exercise.
Note also that the interpretation of ply results requires some understanding of the struc-
ture of results returned by methods like “getPliesStresses”, “getPliesStrains”, “getRe-
serveFactors”... The information provided in Part II of this manual and in Chapter VI.0
should be sufficient, even though it requires to spend some time on the analysis of the
example.
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.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 num-
ber 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 exam-
ple.)
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:
• At the beginning, one needs to load several standard packages:
require ’Win32API’
require ’win32ole’
“Win32API” is necessary to create message box windows. “win32ole” is necessary for

the OLE automation.
• the program defines the same three methods as python program in section VII.1.1.1:
“id2str”, “printLamProperties” and “printLoadResponse”. These methods are nearly the
exact equivalent as the same methods in the python version of the program.
• In the main program, the access to the COM component, and the creation of the ClaDb
dataBase are done as follows:
db.readNeutral("test.ndf")
(Here again, you may have to change the version number of FeResPost to match the
version installed on your computer.) The loop on laminate and load IDs looks as follows:
db.iter_laminateId.each do |lamId|
printLamProperties(db,os,lamId)
db.iter_loadId.each do |loadId|
printLoadResponse(db,os,lamId,loadId,0.0,criteria)
end
end
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 db=frpApp.newObject("ClaDb")
db.readNeutral "test.ndf"
VII.1.1. USING COM COMPONENT WITH SEVERAL LANGUAGES 429
VII.1.1.4 Using component with C++

The example is provided in the following files:
• “COMEX/EX01/testClaCom.cpp” is the principal file containing calculation functions

and the main program.
• “COMEX/EX01/util.cpp” contains the definition of utility functions. (Mainly conversion

functions.)
• “COMEX/EX01/util.h” contains the declarations of the same functions.

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 com-
ponent with compiled languages than with interpreted languages that support COM automation.
This is related to several factors:
• The scanning of results returned by FeResPost methods is generally more complex than
with an interpreted language because all the conversion operations must be done “manu-
ally” by the programmer.
The development of a set of functions performing the conversions may reduce slightly
the burden of programming these operations. However, it shall always be significantly
more tedious in C++ than in python or ruby.
• Similarly, when methods have a variable number of arguments, these are passed by a
SafeArray that has to be prepared before calling the method.
• All the conversions to or from VARIANT variables must be managed by the programmer,
while interpreted languages manage most of this job.
• The programmer cannot forget to call the “Release” method when appropriate to avoid
memory leakage.
• ...
Just to illustrate the points above, one gives below an example of the programming lines nec-
essary 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)) {
VII.1.2. TESTING THE “NASTRANDB” AND “GROUP” CLASSES 431
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.
• “testIterators” reads a Nastran BDF and a Patran session file into a NastranDb dataBase.
Then the different iterators are tested and the “iterated” entities returned by the iterators
are printed in an output file.
• “testElemConnectivity” prints the elements connectivity for all the elements.
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 “testElem-
Connectivity” 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:
• “testGroupFunction1” reads a Nastran BDF and a Patran session file into a NastranDb
dataBase. Then a loop on the Groups is done and the number of each type of entity
present in each Group is printed.
dataBase. Then the different operators are tested.
• “testGroupFunction3” reads a list of Groups from a Patran session file without inserting
them into a DataBase. Then, a loop is done on the Array containing the Groups and the
Group names and objects are printed.
dataBase. Then, Groups are build by association to materials.
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.)
VII.1.3. TRANSLATING A FEW SMALL “RUBY” RESULT EXAMPLES 433
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|
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]
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 exam-
ple “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 ex-
ample “RUBY/EX06/makeGravForces.rb” described in section IV.2.5.1. As a Module is de-
fined 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 ex-
ample “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 dif-
ference 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 state-
ment:
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 cor-
respond to the examples of directory “RUBY/EX09” described in section IV.2.4.5. The exam-
ple “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.4. USING COMPONENT FOR CLA ANALYSES 435
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.
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.
Manipulation of complex Results

This example is stored in file “COMEX/EX04/manipComplex.rb”. It corresponds to the ex-
ample “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:
multRI=resRI.clone
multRI*=Z
become the following statements when the COM component is used:

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.5.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.5.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:
allowables={}
...
lam.insertAllowables(allowables.to_a)
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:
allowables={}
...
lam.insertAllowables(allowables.items())
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.5.6. No remark is to be done about this
example.
VII.1.5. OBJECT-ORIENTED POST-PROCESSING 437
VII.1.5 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 de-
scribed in Chapter IV.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.6 XDB attachment Results access with RUBY and COM

In directory “COMEX/EX08”, one presents the source files of examples illustrating the ac-
cess 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.7 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:
• In Chapter VII.2 one shows how a small tool devoted to the automation of Classical
Laminate Analysis can be developed in Excel.
• The extraction of Results in Excel from a Nastran XDB file is illustrated in Chapter VII.3.
• One shows in Chapter VII.4 how an entire post-processing project can be developed in
excel. This project allows to define the data in excel while the actual calculations are
managed by the programmed VBA modules that call FeResPost objects and methods.
• A very small example illustrating the use of BLOB and SQL with VBA in section VII.1.8.
VII.1.8 An Excel workbook illustrating the use of SQL databases

This example is presented in excel workbook “blob_test.xls” 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 correspond-
ing 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 op-
erations 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 lan-
guage. (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.5.
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.xls”.
The presentation of the example is organized as follows:
• One explains in section VII.2.1 how the excel workbook must be prepared to make the
example work.
• The different spreadsheets defined in the workbook are presented in section VII.2.3.
• Some explanations on the different modules defined in the workbook are given in sec-
tion VII.2.4
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:
• The COM component must have been properly installed as explained in section X.A.3.5.
• Then, open the excel workbook.
• Open in the VBA editor: “Tools –> macros –> VisualBasic Editor”, or more simply key
in "Alt+F11".
439
440 CHAPTER VII.2. CLA ANALYSES IN EXCEL
• In VBA editor, you must reference the library. Go in “Tools –> References”, and select
the appropriate version of FeResPost COM server. In the list, the name of the COM
server should look like “FeResPost 4.5.1 COM server”.
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_0_0.Application"
VII.2.2 Workbook events

Two events are defined in the workbook:
• The “BeforeClose” proposes to save the current ClaDb database into an NDF file, and
into the “NeutralLines” spreadsheet before quitting the workbook. Note that if you save
the database into the “NeutralLlines” spreadsheet, you also must save the excel workbook
if you want to retrieve you data the next time you open it.
• The “Open” event starts the FeResPost application and retrieves the ClaDb dataBase
stored in the “NeutralLines” spreadsheet when the workbook is opened.
VII.2.3 Spreadsheets
One presents below the different spreadsheets defined in the workbook. Most of these spread-
sheets 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 spread-
sheet 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 spread-
sheet 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. SPREADSHEETS 441
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:
• An integer ID,
• A String ID,
• an excel ID.
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:
• The ComboBox button allows to select the type of file from which a DataBase shall
be read or DataBase entities shall be imported. This file format must be correctly de-
fined for the file read/import operations to work properly. Four file formats are possible:
“ESAComp" EDF file, FeResPost neutral data file (NDF), Nastran BDF bulk data file,
and Samcef DAT banque file.
• The “Read Data File” button is used to read a new ClaDb database. All the entities stored
in the current dataBase are first deleted. Note that the ComboBox button must have been
properly set before reading entities.
• The “Import Data File” button performs the same operation, but the entities that have
been read are added to the current dataBase. (They also replace the old entities that have
the same ID.)
• Three command buttons perform the same operation as “Import Data File” button except
that each time, only one type of entities is read: “Import Laminates”, “Import Materials”
and “Import Loads” buttons.
• The button “Save FeResPost NDF file” is used to save the composite DataBase in a
neutral data file. (Only neutral Data files can be saved by FeResPost.)
• The button “Show/Hide FeResPost” is used to show or hide the FeResPost server win-
dow. Note that the FeResPost server continues to run, even when it is hidden.
• The button “Close FeResPost” really closes the FeResPost server. When this is done, the
composite dataBase is closed too, but its content is not saved! (so be careful with this
button.)
• The button “Delete Selected Entities” is used to remove entities from the composite
dataBase. To use this button you must first select a range in the entities that appear
below, then press the button. To select a range, at least the three columns corresponding
to the entities you want to remove must be selected.
• The two buttons “SaveDbToNeutralLines” and "RetrieveDbFromNeutralLines” are used

to store the current DataBase into the hidden “NeutralLines” spreadsheet. This allows
you to recover the db you wore working with the last time you used the workbook without
reading an NDF file. (Of course you have to save the excel workbook before quitting.)
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 nec-
essary, 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:
• Seven ComboBox buttons allow to select the units for length, mass, force...
• The “SetDbUnits” button sets the units system associated to the composite database but
does not change anything to entities stored in the DB.
• The “SetUnitsAllEntities” button sets the system of units of the CLA database and of all
its entities (materials, laminates and loads).
• The “SetUnitsAllMaterials” button sets the units of all material entities stored in the
database.
• The “SetUnitsAllLaminates” button sets the units of all laminate entities stored in the
database.
• The “SetUnitsAllLoads” button sets the units of all load entities stored in the database.
• The “ChangeUnitsAllEntities” button changes the system of units of the CLA database
and of all its entities (materials, laminates and loads).
VII.2.3. SPREADSHEETS 443
• The “ChangeUnitsAllMaterials” button changes the units of all material entities stored in
the database.
• The “ChangeUnitsAllLaminates” button changes the units of all laminate entities stored
in the database.
• The “ChangeUnitsAllLoads” button changes the units of all load entities stored in the
database.
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 “Se-
tUnits*” 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 indi-
vidually. 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 ComboBox button allows to retrieve the definition of a material defined in the current
DataBase in ClaDbIds spreadsheet. The excel ID is used to retrieve the material.
• The “Insert in DataBase” button is used to insert the defined material in the DataBase.
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 ComboBox button allows to retrieve the definition of a laminate defined in the current
DataBase in ClaDbIds spreadsheet. The excel ID is used to retrieve the laminate.
• The “Insert in DataBase” button is used to insert the defined laminate in the DataBase.
• The “Existing Material Search” ComboBox button is only used to retrieve the exact in-
teger and String IDs of a material that exists in the DataBase and make the definition of
additional plies easier.
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 ComboBox button allows to retrieve the definition of a load defined in the current
DataBase in ClaDbIds spreadsheet. The excel ID is used to retrieve the load.
• The “Insert in DataBase” button is used to insert the defined load in the DataBase.
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 mod-
ule.
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 mod-
ule.
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 “cal-
cLamProperties” 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 com-
posite dataBase, and a loading also defined in the current dataBase. The buttons allow to select:
• An existing laminate (in the active dataBase),
• An existing load (in the active dataBase),
• The orientation wrt which laminate properties are calculated,
• Whether plies result outputs are requested at bottom, mid or upper surface of each layer,
VII.2.4. VBA MODULES 445
• Whether the ply stresses and strains are restituted in coordinate system related to laminate
axes or in ply axes,
• The last button gives the rotation angle wrt laminate axes of the restitution coordinate
system. (This button is used only if the previous button is set to “YES”.
The spreadsheet makes use of several functions defined in “calcLamLoadResponse” VBA mod-
ule. 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 mate-
rial 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, se-
lect 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 “MatProp-
erties”.
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 “Lam-
Properties” 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:
• If the range corresponds to one single cell, this cell is assumed to contain the excel ID of
a ClaLoad object stored in the current DataBase.
• If the selection corresponds to a range of 2 line and 9 columns, the elements are inter-
preted as a load defined explicitly.
Chapter VII.3
Extraction and manipulation of Results

with excel
In directory “COMEX/EX09”, one gives an excel workbook “PostXdbRandom.xls” 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:
• A Hidden spreadsheet called “FemHiddenData” contains some persistent data for menus
or selections.
• Spreadsheet “FemDbIds” is devoted to the access to finite element model and Results.
This spreadsheet is discussed in section VII.3.2.
• Spreadsheet “GroupEdit” that allows to manipulate groups stored in the current database.
This spreadsheet is discussed in section VII.3.3.
• Spreadsheet “ResExtract” performs simple extractions of Results on specified Groups. A
description is given in section VII.3.4.
• Spreadsheet “ResCombiliExtract” performs extractions of linear combination of Results
on specified Groups. A description is given in section VII.3.5.
• In “WorstResExtract” spreadsheet, presented in section VII.3.6, one shows that the spread-
sheets may be used to select a certain number of values based on a specified criterion.
• Spreadsheet “DynamResExtract” is devoted to the extraction of complex Results corre-
sponding to dynamic response analysis. The spreadsheet is discussed in section VII.3.7.
• Possible improvements of the excel spreadsheet are discussed in section VII.3.8.
The excel workbook makes use of the FeResPost COM component. This means that the com-
ponent 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 “Post-
DesFacRandom.xls”). Its functionalities and principles are very similar to those of Nastran
version.
447
448CHAPTER VII.3. EXTRACTION AND MANIPULATION OF RESULTS WITH EXCEL

done as follows:
in "Alt+F11".
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 Re-
sults. Several buttons can be used:
• The two buttons “Show/Hide FeResPost” and “Close FeResPost” work exactly as in
“LaminateAnalysis.xls” workbook. (See section VII.2.3.)
• Button “Select Bdf File” is used to select the BDF file from which the finite element
model shall be read.
• Button “Select Ses File” is used to select the Patran Session file from which the definition
of Groups shall be read.
• Button “ReadModel” performs several operations:
1. If necessary the COM component is loaded and the FeResPost application is loaded.
2. A “NastranDb” object is created.
3. The BDF file previously selected is imported as model into the DataBase.
4. The Groups are initialized by reading the Patran Session File previously selected.
VII.3.3. ACCESSING THE FEM AND RESULTS 449
5. After the importation of model and Groups, the list of Groups and coordinate sys-
tems present in the DataBase are saved in the two first columns in the spreadsheet.
• Button “Select Xdb File” is used to select the Nastran XDB Result file that shall be read.
• Button “ScanXdb” scans the content of the previously selected XDB Result file and up-
dates the lists of load cases, sub-cases and Result types in columns C, D and E.
• Button “exportGroups” can be used to export Groups from the current DataBase in a
Patran session file. This is useful only if the Groups have been manipulated in the “Grou-
pEdit” worksheet. (Section VII.3.3.)
Note that the reading of a model and Results must be performed before using the other spread-
sheets.
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:
• The name of the Group being manipulated is stored in cell “C3”. This name can be set
manually, or selected in the menu just below if it already exists in the DataBase.
• The entities to be set, removed or added are defined in columns “A” to “E” and lines 11
to ... Column “A” corresponds to entity types. Column “B” is used when a single entity
is to be added to the Group. Columns “C” to “E” defines ranges by looping on the entity
IDs. Some of the cells may be left void.
• Button “Add Group to current Db” builds the Group defined by its name and entities
and stores it in the DataBase. If a Group with the same name is already defined in the
DataBase, it is replaced by the new Group.
• Button “Add Entities to Existing Group” adds the defined entities to the entities of a
Group already existing in the DataBase.
• Button “Remove Entities from Existing Group” performs the reverse operation.
Four buttons allow to build new Groups by topological operations on existing Groups. The op-
erations 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:
• Selection of the name of the Group on which the Results shall be extracted.
• Selection of the load case name.
• Selection of the sub-case name.
• Selection of the Result type name.
• Selection of the “location” parameter. For example “Nodes”, “Elements” “ElemCen-

ters”... This parameter, together with the name of the Group determines on which ele-
ment and node entities the Results are extracted.
• The coordinate system in which the Result components shall be extracted. This is the
only parameter corresponding to a post-processing calculation done on the Result.
• A checkBox allows to specify whether the data are recovered in a projected coordinate
system (when applicable). Then, three real values specify the components of the coordi-
nate systems given in the selected coordinate system.
• It is possible to select the layers on which results will be extracted (when applicable).
The choice is between “all layers” (no layers selection) or a range address. The range
corresponds to a selection of cells in which the layers are given.
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 spread-
sheet.
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” spread-
sheet.)
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.

VII.3.5. EXTRACTION OF LINEAR COMBINATIONS RESULTS 451
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:
• Combinations of 3 elementary load cases Results.
• Moreover, the elementary Results must be read from a single XDB file.
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 ap-
propriate. A “tmpRes” Result is created.
3. One extracts the nbrVals largest values of this “tmpRes” Result by calling “extractRe-
sultForNbrVals” method.
4. Correspondingly, one also extracts the critical values of “res” Result using “extractRe-
sultOnResultKeys” 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 spread-
sheet.
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”.
VII.3.8. CURRENT LIMITATIONS 453
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:
• Allow the management of several DataBases, Patran session files or XDB attachments.
• Allow the definition of linear combinations of Results with more that 3 elementary Re-
sults or with Results extracted from different XDB attachments.
• ...
(See also the Samcef version of the workbook is also given in directory “COMEX/EX09” and
file “PostDesFacRandom.xls”.)
Chapter VII.4
An Excel workbook devoted to

post-processing
In directory “COMEX/EX10”, one gives an excel workbook “PostProject.xls” 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 IV.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 (sec-
tion VII.4.2) and VBA modules (section VII.4.3).

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 multipli-
cation of elapsed computing time by a factor 2 approximately.
VII.4.1.2 Referencing FeResPost in VBA

done as follows:
455
456 CHAPTER VII.4. AN EXCEL WORKBOOK DEVOTED TO POST-PROCESSING
in "Alt+F11".
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 “TEST-
SAT/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:
• Worksheets that contain the definition of databases and load cases. (More precisely, they
contain the information needed to build databases and Results.) The characteristics of
these worksheets are given in section VII.4.2.2.
• Worksheets that allow to select load cases, and associate parameters to each load case.
Section VII.4.2.3 presents these worksheets.
• The “LcSelector” worksheet that automates several operations. Only one such worksheet
can be defined in the workbook. It is presented in section VII.4.2.1.
• The post-processing worksheets that define the data and sequence of operations to per-
form post-processing calculations, and archive Results. More information about these
worksheets is given in section VII.4.2.4
• One worksheet called “envelopeGMSH” and devoted to the manual production of GMSH
envelope of Results.
• Several worksheets have been added to test the post-processing of Samcef results:
VII.4.2. WORKSHEETS 457
– Worksheet “SamcefDefDbLc” defines a database and several load cases.

– Worksheet “SamcefSel” defines the corresponding selection with associated param-
eters.
– Worksheet “post_samcef” tests the post-processing of samcef results by extracting
results and calculating a few margins of safety.
Note that the finite element model and results corresponding to these samcef post-processing
are not provided, so that you cannot work the samcef example.
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 name of the worksheet in which the definition of databases and load cases is pro-
vided.
• The name of a worksheet containing a selection of load cases and defining the associated
parameters.
The worksheet also defines several automation buttons:
• “ReadDbAndLoadCases” is used to read the definition of databases and load cases, and
the selection of load cases and parameters. The names of the two corresponding work-
sheets must first be defined in the appropriate cells below the “ReadDbAndLoadCases”
button. This button is the first to use after opening the workbook. Indeed, this button
initializes lists of load cases and databases in the “LcSelector” worksheet and several
variables in “DbAndLoadCases” module.
• The ComboBox allows to manually select and calculate a load case.
• The “ArchiveResults” button can be used to manually archive the calculated Results in a
separate workbook.
• The “ReinitArchiveResults” button reinitializes all the VBA variables related to the archiv-
ing of calculated Results.
• The “WriteGmshFiles” button performs the writing of Results in GMSH files.
• The “ReinitGmshFilesList” clears all the variables related to the archiving of Results into
GMSH files.
• The “LoopOnLoadCases” button performs the calculations for all the selected load cases
and archives the Results in a separate workbook.
• “Reinit FeResPost Objects” button re-inits all the variables defined in the VBA project,
which restarts from scratch.
• “Debug Current Load Case” button prints in the standard output file debugging informa-
tion about the current load case.
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:
• The ten first lines are never taken into account.
• Otherwise each line defines a peculiar entity:
– An elementary load case if the first column contains “LC_ELEM” keyword.

– A load case combining linearly elementary load cases if the first column contains
“LC_COMBILI” keyword.
– A NastranDb database if the first column contains “NASTRANDB” keyword.
– A SamcefDb database if the first column contains “SAMCEFDB” keyword.
All the lines of which the first element does not contain one of these keywords are ig-
nored.
• For valid lines (un-ignored ones), the second column corresponds to an identifier of the
entity that is defined.
• The other columns contain information defining the object:
– For NastranDb databases, several keywords allow to define the operations that are
performed when a database is created:
∗ The first keyword in the first column is “NASTRANDB" and is followed im-
mediately by an identifier allowing to retrieve the entities and information as-
sociated to the database.
∗ The keyword “GMSH” specifies that the value in the following column con-
tains the name of a GMSH file in which the Nastran model is saved in GMSH
format.
∗ The “BDF” keyword specifies that the following column contains the name of
a file from which the Nastran finite element model is read.
∗ The “SESSION” keyword specifies that the columns that follow contain names
of Patran Group session files containing the definition of Groups.
∗ The “CLADB” keyword specifies that the columns that follow contain the
sources in which information is read to build the ClaDB object in which com-
poiste entities are defined. Sources correspond to the names of NDF files in
which composite databases are stored. If a cell contains the name of the Nas-
tranDb currently being defined, the composite entities defined in the corre-
sponding finite element model are imported into the database. If the keyword
is omitted, then the ClaDb is produced by extraction of the NastranDb database
that is build.
– For SamcefDb databases, several keywords allow to define the operations that are
performed when a database is created:
∗ The first keyword in the first column is “SAMCEFDB" and is followed imme-
diately by an identifier allowing to retrieve the entities and information associ-
ated to the database.
∗ The keyword “GMSH” specifies that the value in the following column con-
tains the name of a GMSH file in which the Nastran model is saved in GMSH
format.
∗ The “DAT” keyword specifies that the following column contains the name of
a Samcef Bacon “banque” file from which the Samcef finite element model is
read.
∗ The “SESSION” keyword specifies that the columns that follow contain names
of Patran Group session files containing the definition of Groups.
∗ The “GROUPDAT” keyword specifies that the columns that follow contain
names of a Samcef Bacon “banque” files from which the definition of Groups
shall be read.
∗ The “CLADB” keyword specifies that the column that follows contains the
name of the NDF file from which a ClaDb composite database is read. If the
keyword is omitted, then the ClaDb is produced by extraction of the SamcefDb
database that is build.
The “SESSION” and “GROUPDAT” keywords are the only ones that may be fol-
lowed by several columns.
– For elementary load cases, one provides:
∗ In the first column, the keyword “LC_ELEM” followed in the second column
by the name of the load case. This is the name by which the load case shall be
referred to in the rest of the worksheet.
∗ In the third column, one gives the name of the database associated to the load
case. This corresponds to the database that shall be used for all the post-
processing operations of this load case Results. The choice of the associated
database can be superseded by defining parameter “FEMDB” at load cases
selection level. (See section VII.4.2.3.)
∗ The fourth column contains a keyword corresponding to the type of Result file
that shall be accessed. Presently, Only two values are allowed:
· Columns 4 may contain the keyword “XDB”. Then, an XDB attachment
to a NastranDb database is defined and...
· In column 5, one provides the access path to the XDB file.
· In column 6, one provides the name of the load case in the XDB file. This
name does not necessarily correspond to the “FeResPost” name specified
on the second column.
· Finally, the identification of the subcase is provided in column 7.

· Columns 4 may contain the keyword “DESFAC”. Then, a DESFAC attach-
ment to a SamcefDb database is defined and...
· In column 5, one provides the access path to the DES file.
· In column 6, one provides the access path to the FAC file.
· In column 7, one provides the name of the load case in the DES/FAC file.
(Default name generated by FeResPost when the file is attached.) This
name does not necessarily correspond to the “FeResPost” name specified
on the second column.
· Finally, the identification of the subcase is provided in column 8.
Note that XDB files must be attached to NastranDb databases, and DESFAC
files to SamcefDb databases.
– For combined load cases, one provides:
∗ In the first column, the keyword “LC_COMBILI’ followed in the second col-
umn by the name of the load case. This is the name by which the load case
shall be referred to in the rest of the project.
∗ In the third column, the number of elementary load cases used in the linear
combination.
∗ The following columns define pairs of real and string values corresponding to
the factors and names of elementary load cases used for the linear combination
of Results. These load cases must have been defined on “LC_ELEM” lines.
VII.4.2.3 Worksheet for Selection of load cases and associated parame-

ters
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:
• In the first column, one defines the name of the load case.
• The other columns define parameter values.
One notes that one load case can be defined in different “selection” worksheets with identi-
cal 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 Nas-
tran 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”, "ResultsExtrac-
tion", 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:
• The number of worksheets could be increased if necessary without problem. So far, one
created three post-processing worksheets, each being devoted to a peculiar type of post-
processing (connections, stresses or extraction). However, other types of separations are
possible: type of margin, part of the structure...
• One also uses the “getParameter” function of “DbAndLoadCases” VBA module to obtain
the appropriate safety factors.
• The functions must depend directly or indirectly on the current load case name if one
wants them to be re-calculated each time the selected load case is modified. This means
that all the functions refer directly or indirectly to the corresponding cell in “LcSelector”
worksheet.
• One separates the calls to the post-processing function from the formatting of Results for
archiving. This formatting is used to:
– Select the values that shall be archived,
– Modify units (MPa instead of Pa, mm instead of m...),
– Perform additional calculations (calculation of margins of safety),
– ...
• Calls to “saveToArchive” function are done to allow to archive calculated Results. (This
is particularly useful when one performs loops on a selection of load cases.)
VII.4.2.5 “envelopeGMSH” worksheet

This worksheet is used to generate “manually” the GMSH files containing the envelopes of Re-
sults. 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 corre-
sponding subroutine are stored in two cells:
• Cell C6 contains the name of the spreadsheet in which the selection of load cases shall
be read. This spreadsheet can be the sheet “envelopeGMSH” itself, or another worksheet
defining the selection. The first column of the worksheet is read and a list of load cases
is generated.
• Cell C7 contains the access path to the main BDF files used to generate the database that
shall be used for the generation of GMSH files.
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 re-
covery of information needed to create the databases, and to generate and read the Results cor-
responding 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:
• “appName” allows to retrieve the appropriate version of FeResPost. When you change
the version of FeResPost COM server, you have to modify the variable.
• “storageMaxCapacity” is a “Double” variable that corresponds to the size in Megabytes
of the buffer that stores information read from XDB attachments.
• “maxNbrDataBases” contains the maximum number of databases that can be managed
simultaneously by the excel project. Keeping the value low will reduce the use of mem-
ory by excel.
• “maxNbrAttachments” corresponds to the maximum total number of attachments al-
lowed in the project. Here again, the tuning of that value allows to reduce the amount of
memory used by excel.
Also this module provides functions that allow to retrieve Results or load case information.
Several such functions deserve more explanation:
• “getCurrentDb” returns the currently active database corresponding to the currently se-
lected load case name.
• “getResults” is used to extract Results, or build them by calculating linear combinations.
• “getParameter” is used to retrieve a parameter associated to the currently selected load
case. (Arguments are the name of the currently selected load case, and the name of the
parameter.)
These methods are mentioned here because they are used in “ExtractCriteria” module to pro-
gram 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 func-
tions that can be called from post-processing worksheets, a separate section is specifically de-
voted to this module. (See section VII.4.4.)
VII.4.3. VBA MODULES 463
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:
• One string corresponding to the name of worksheet in which the Results are saved.
• One excel range of cells corresponding to the title inserted in the worksheet when it is
created, i.e. when the worksheet is first accessed.
• One excel range of cells corresponding to the values to be saved. (The number of columns
in this range should preferably match the number of columns in the “title” selection.)
• On excel range of cells corresponding to a test allowing to determine whether a selected

line in the “values” range is to be archived. The check is done on a line-by-line basis.
The number of lines in this range must match the number of lines in “values” range. The
number of columns must be 1. (This argument has been added to avoid archiving some
parts of the Results when necessary.)
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 “LcSe-
lector” worksheet for example). Also, the calculation of worksheets must be redone after push-
ing “ReinitArchiveResults” button in “LcSelector” worksheet. Indeed, the “ReinitArchiveRe-
sults” 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:
• “sqliteLibDirName” contains the path to the directory containing the “SQLite3” shared
libraries. This variable must be adapted to match your installation.
• “globOutputList” contains the envelopes of Results calculated for the current selection
of load cases.
• “locOutputList” contains the envelopes of Results for the current load case.
• “sqlDbName” contains the name of the SQLite3 database in which Results are stored for
each load case.
• “sqlDbHandle” is a handle (pointer) to the current SQLite3 database.

VII.4.4. “EXTRACTIONCRITERIA” VBA MODULE 465
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.8 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 gen-
erates 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:
• “SheetExists” allows to check the presence of a worksheet in an excel workbook.
• “checkItemExistsInCollection” allows to verify if a specified item exists in a collection.
• “copyRangeFormat” copies several format characteristics of an excel range of cells to

another range of cells. The sizes of the two ranges must match.
• “setArrayAllValues” initializes all the values of an Array to the same specified value.
• “clearAllModuleVariables” re-initializes the variables of several modules in the work-

book.
• “layersFromRange” returns an Array corresponding to a selection of Result layers. The

argument of the function is an excel range (selection of cells).
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:
• These functions are called directly from the post-processing worksheets. These functions
take a specified set of arguments and return an array of values (matricial functions). More
precisely, so far, each extraction function returns a one line array of values. In order to
know the number of columns, you should examine the examples or the sources of VBA
module.
• The functions return FALSE values in case of problem.

• The definition of post-processing functions could be split in different post-processing

VBA modules. This might be handy when many such functions are defined.
• For all the post-processing criteria, the two last arguments of the associated functions
are optional. These are string arguments corresponding to the name of a GMSH file in
which an envelope of Results is stored, and the name of the Result that is saved in this
GMSH output file. A majority of methods defined in “ExtractionCriteria” call methods
in “ResultsGmsh” module to build the envelopes of Results.
(Generally, the envelopes that are calculated are the maximum of the inverse of reserve
factors, but this is not an absolute rule.)
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

“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 exam-
ple: “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.
“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.
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.
“getHoneycombCoreAirbusRF” function
Function “getHoneycombCoreAirbusRF” in “ExtractionCriteria” VBA module calculates the
minimum honeycomb reserve factor on a Group of elements using the so-called “Airbus” cri-
terion:
1
RF = v !2 !2 ,
u
u τL τW
FoSt +
σL σW
in which τL and τL are the honeycomb longitudinal and transverse shear components of Cauchy
1. A String corresponding to the name of the load case for which Cauchy stress tensor is
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 .
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.
“getHoneycombCoreMaxShearRF” function
Function “getHoneycombCoreMaxShearRF” in “ExtractionCriteria” VBA module calculates
the minimum honeycomb reserve factor on a Group of elements using a maximum shear crite-
rion:
σW
MoS = −1,
FoS ∗ τ
in which τ is the maximum shear stress and σW the transverse shear allowable.
1. A String corresponding to the name of the load case for which Cauchy stress tensor is
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.)
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,
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 esti-
mate 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 asso-
ciated reserve factor.
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 exam-
ple, 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 argu-
ment above are the following:
• “GPFINT” if loads are obtained using Grid Point Forces, Internal Forces and Moments.
• “GPFMPC” if loads are obtained using Grid Point Forces, MPC Forces and Moments.
• “GPFSPC” if loads are obtained using Grid Point Forces, SPC Forces and Moments.
• “MPCFRC” if loads are obtained from MPC Forces and Moments.
• “SPCFRC” if loads are obtained from SPC Forces and Moments.
• “BMFRC” is loads are obtained from Beam Forces and Moments. (This may correspond
to forces of several elements like CBAR, CBEAM, CBUSH or CFAST.)
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:
• When MPC or SPC forces and moments are post-processed. The choice of grp1 and grp2
is indifferent as loads are extracted on the intersection nodes only.
• When one processes Grid Point Forces internal forces and moments, the definition of
grp1 and grp2 may matter. Consider the example represented in Figure VII.4.1 in which
Part 2 is a sandwich panel modeled with shell elements. Then,
– If one calculates inserts margins of safety, loads should be extracted on elements
of sandwich panel at connection nodes because the inserts of sandwich panels are
loaded by connections of Groups “ConnectGrp2” and “ConnectGrp3”. This means
the grp1 should correspond to Part 2 and grp2 to either “ConnectGrp2” and “Con-
nectGrp3”.
– On the other hand, if one calculates sliding between Part 1 and Part 2, only the
loads transmitted by elements of Group “ConnectGrp2” must be recovered. Then
grp1 should correspond to Group “ConnectGrp2” and grp2 to Part2. Of course, this
will work only if the connections are modeled with elements ( CBUSH, CBAR,...)
and not MPCs.
In many cases, grp1 and grp2 can be switched without consequences on the results. Then
it is generally less expensive to select grp1 corresponding to the Group containing the
connections.
Note however that when grp1 and grp2 are switched, the vector defining axial direction
should be reversed too!
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.
“getSlidingRF” function
This function calculates reserve factors for the sliding criterion with the following expression:
Cf ∗ Pmin
RF = ,
FoS ∗ (Cf ∗ max(Faxial , 0) + Fshear )
ConnectGrp1
Part 1
ConnectGrp2
Part 2
ConnectGrp3
Part 3
ConnectGrp4
Figure VII.4.1: Example of assembly of different layers with a single connection.
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 factor of safety “FoS”. (Parameter 7 of the function.)
• The minimum estimated pretension of a connection “Pmin”. (Parameter 8 of the func-
tion.)
• The friction coefficient “Cf”. (Parameter 9 of the function.)
• Two optional parameters containing the name of the GMSH file in which the envelope of
inverse reserve factors is saved, and the name of the Result by which it is referred to in
the GMSH file.
The function returns an Array of one line and four columns containing:
• The ID of the finite element entity to which minimum reserve factor corresponds. This
is the ID of an element for “BMFRC” extraction and a node ID otherwise.
• The corresponding axial force.
• The corresponding shear force.
• The minimum reserve factor.
“getGappingRF” function
This function calculates reserve factors for the gapping criterion with the following expression:
Pmin
RF = ,
FoS ∗ (max(Faxial , 0) + Mbending /R)
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 minimum estimated pretension of a connection “Pmin”. (Parameter 8 of the func-
tion.)
• The friction coefficient “Radius”. (Parameter 9 of the function.)
the GMSH file.
• The corresponding bending moment.
“getInsertRF” function
This function calculates reserve factors for the insert criterion with the following expression:
1
RF = v !2 ,
u ! 2
u Faxial Fshear
FoSt +
PSS QSS
In which “PSS” is the axial allowable of the insert and “QSS” is its shear allowable. Parameters
specific to this function are:
• The insert axial allowable “PSS”. (Parameter 8 of the function.)
• The insert shear allowable “QSS”. (Parameter 9 of the function.)
the GMSH file.
“getShearBearingRF” function
This function calculates reserve factors for the shear-bearing failure mode with the following
expression:
ShrAll
RF = ,
FoS ∗ Fshear
in which ShrAll is the shear bearing allowable. Parameters specific to this function are:
• The shear-bearing allowable “ShrAll”. (Parameter 8 of the function.)
the GMSH file.
The function returns an Array of one line and three columns containing:
“getPullThroughRF” function
This function calculates reserve factors for the pull-through failure mode with the following
expression:
PullAll
RF = ,
FoS ∗ max (Faxial , PullAll ∗ 10−9 )
in which PullAll is the pull-through tensile allowable. Parameters specific to this function are:
• The pull-through allowable “PullAll”. (Parameter 8 of the function.)
the GMSH file.
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 re-
covered 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.
The use of “getCompositeRF” function is illustrated in “post_composite” worksheet.

“getCompositeRF2” function defined in “UserCriteria” Module is a variant of “getCom-
positeRF” with two additional arguments:
• “bCurvature” is a boolean that specifies that one loads the laminates with “Curvature
Tensor” instead of “Shell Moments Tensor” to calculate laminate load response. item
“tempFieldId” corresponds to an integer that allows to retrieve a temperature field from
“sqliteResults.db3” database to load the laminate. This contribution is taken into account
if the database is located in excel working directory, and if the specified temperature field
is found in the database. In the example, the “TempLoad” parameter is used to associate
the temperature fields to post-processing load case.
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 “getCompos-
iteRF” 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 func-
tions calculating laminate criteria. The arguments of this function are the same as those of
“getCompositeRF” function.
Part VIII
FeResPost as .NET assembly
477
Chapter VIII.0
Introduction
On Windows OS, FeResPost is distributed at the same time as a ruby extension, a COM com-
ponent and as a .NET assembly. One describes in this Part several characteristics of FeResPost
as a .NET assembly.
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. There-
fore, 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:
• Chapter VIII.2 presents the .NET characteristics of the FeResPost generic classes de-
scribed in Part I.
• Chapter VIII.1 presents the .NET characteristics of the FeResPost CLA classes described
in Part II.
• Chapter VIII.3 presents the .NET characteristics of the FeResPost generic classes de-
scribed in Part III. (Solver classes.)
• In Chapter IX.1, one gives a few examples illustrating the use of FeResPost .NET assem-
bly.
The installation of the .NET assembly is described in section X.A.3.6.

In section VIII.0.1, 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.
479
480 CHAPTER VIII.0. INTRODUCTION
VIII.0.1 .NET assembly versus ruby extension

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.1 Accessing the .NET assembly

If FeResPost assembly is installed into global assembly cache, no peculiar operation is neces-
sary 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 in-
dependently 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.1.2 Accessing FeResPost namespace

All classes of the FeResPost .NET assembly are defined in “FeResPost” namespace. To sim-
plify 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.1. .NET ASSEMBLY VERSUS RUBY EXTENSION 481
VIII.0.1.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.1.4 Basic types as arguments and returned values

In FeResPost .NET assembly, the following default types are used for parameters:
• Real are single precision real values corresponding to “float” C++/CLI type or “Single”
CLR type. Note however, that “double” arguments are sometimes accepted.
• Integer values are 32 bits integers corresponding to “int” C++/CLI type or “Int32” CLR
type.
• Logical values correspond to “bool” C++/CLI type or “Boolean” CLR type.
• Strings of characters are passed as “Stringˆ” C++/CLR/CLI objects.
• ...
The different classes defined in FeResPost assembly are reference managed classes. The ex-
amples given in Part IX should clarify the use of arguments.
VIII.0.1.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.1.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:
• The “Iterator” class that implements “IEnumerable” interface.
• The “IterX” class that implements “IEnumerator” interface.
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.
...
...
end
...
With FeResPost .NET assembly and IronRuby, an Iterator must first be produced before iterat-
ing 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 FeRes-
Post .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.
VIII.0.1. .NET ASSEMBLY VERSUS RUBY EXTENSION 483
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.1.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.1.8 Singleton methods

Ruby “singleton” methods of FeResPost classes are defined as static functions of FeResPost
managed classes.
VIII.0.1.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 de-
riving 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.1.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.1.11 Complex arguments

Complex arguments are input as 1D Arrays of two float or double values.
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.1.6, and of the “clone” methods that have been replaced by “make-
Copy” 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 sec-
tion VIII.0.1.5 for the “Hash” arguments or returned values.
In the rest of this Chapter, one makes a few remarks about the different classes. But other-
wise, 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:
• Iterator “each_material” in ruby extension becomes “iter_material”.
• Iterator “each_materialId” in ruby extension becomes “iter_materialId”.
• Iterator “each_laminate” in ruby extension becomes “iter_laminate”.
• Iterator “each_laminateId” in ruby extension becomes “iter_laminteId”.
• Iterator “each_load” in ruby extension becomes “iter_load”.
• Iterator “each_loadId” in ruby extension becomes “iter_loadId”.
The “Clone” method that returns a copy of the object.
VIII.1.2 “ClaMat” class

“getCompliance”, “getStiffness”, “getInPlaneCompliance”, “getInPlaneStiffness”, “getOOP-
SCompliance”, “getOOPSStiffness”, “getInPlaneLambdaT”, “getInPlaneLambdaH”. (In ruby
extension, these methods return an array of arrays.)
485
486 CHAPTER VIII.1. CLA CLASSES
VIII.1.3 “ClaLam” class

Iterator “each_ply” in ruby extension becomes “iter_ply”.
“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.
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
• The methods “openMsgOutputFile”, “closeMsgOutputFile” and “writeAboutInforma-

tion”.
• The methods “readGroupsFromPatranSession” and “writeGroupsToPatranSession” to read

lists of Groups in Arrays.
• Several methods for the manipulation of Results like “cmp”, “max”, “sin”, “sq”, “exp”,...
• The “convertBlob” method deals with Array of Bytes (unsigned char) instead of Strings
in the ruby extension.
• ...
Note that no dyadic “operator” “op*” is defined in “Post” class, as was done in COM compo-
nent 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”,
487
488 CHAPTER VIII.2. GENERIC FERESPOST CLASSES
“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”, “disableLayeredResultsRead-
ing”, “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:
• The iterators are now “iter_element”, “iter_mpc”, “iter_node” and “iter_coordsys” in-
stead of “each_element”, “each_mpc”, “each_node” and “each_coordsys”.
• The “Clone” method that returns a copy of the object.
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:
• The iterators are now “iter”, “iter_key” and “iter_values”.
extension.
• Several operators defined as “static” in Result class allow to have a float first argument
for corresponding dyadic operations.
• The “Clone” method that returns a copy of the object.

VIII.2.6. RESKEYLIST CLASS 489
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:
• The property “each_key” is here named “iter_key”.
extension.
• The “Clone” method returns a copy of the object.

490 CHAPTER VIII.2. GENERIC FERESPOST CLASSES
Chapter VIII.3
Supported Solvers
The two classes that correspond to the two supported solvers (Nastran and Samcef) are com-
plete.
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 “makeCopy” method that returns a copy of the database.

“iter_nodeId”, “iter_rbeId”, “iter_materialId”, “iter_propertyId”, “iter_nodeOfElement”,
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 “makeCopy” method that returns a copy of the database.

“iter_nodeId”, “iter_materialId”, “iter_samcefPlyId”, “iter_samcefLaminateId”,
“iter_samcefMatIdName”, “iter_samcefMatNameId”, “iter_nodeOfElement”,
491
492 CHAPTER VIII.3. SUPPORTED SOLVERS
Part IX
FeResPost Examples with .NET Assembly
493
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 cor-
respond 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#
The first C# example is very simple and illustrates the use of .NET assembly with C# program-
ming 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 ex-
tended 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 ;
495
496 CHAPTER IX.1. EXAMPLES OF USE FOR .NET ASSEMBLY
These directives allow to reduce the length of type names used in the program. For exam-
ple, the “using FeResPost” directive allows to use “NastranDb” keyword instead of “FeRes-
Post.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"
IX.1.2. “PRINTSTRESSMAX” EXAMPLE 497
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"),s
...
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 :
...
...
printf(" Sxx = %.2f, Syy = %.2f, Szz = %.2f,\n",maxStressData[5],\
printf(" Sxy = %.2f, Syz = %.2f, Szx = %.2f\n",maxStressData[8],\
...
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.4
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 ver-
sion 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));
}
...
IX.1.5. SAVING AND RETRIEVING RESULTS FROM AN SQL DATABASE 499
Note that the first argument is “this ClaMat m”, which indicates the class that is being ex-
tended. In file “NETEX/EX13/extendedCla.cs”, the extension methods are defined in “exten-
sion” 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();
Part X
Appendices
501
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.
Note that the C++ shared libraries are still distributed in “OUTPUTS/lib” directory to main-
tain compatibility with what was done with previous versions. The use of these binaries is
however not recommended because:
• The methods of the shared library throw C++ exceptions. This may lead to problems at
the interfaces of shared objects.
• The compatibility of shared objects built from C++ code depends on the compiler used
to produce them (or on its version). You might be unable to use the distributed libraries.
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.
X.A.1.1 Linux binaries (32 bits)

In archive “FeResPost_4.5.1_LINUX_32.7z” the binaries contain ruby wrappers and C++ li-
brary:
• “OUTPUTS/lib” directory contains the file “libFeResPost_4.5.1.so” that corresponds to

the FeResPost C++ library without any wrapper. If you intend to work with the C++
shared library, this file should be located in a library standard directory, or in a library
pointed to by environment variable “LD_LIBRARY_PATH”.
503
504 APPENDIX X.A. INSTALLING FERESPOST LIBRARY
• “OUTPUTS/include” directory and its subdirectories contain FeResPost C++ headers.

You have no use of these files unless you wish to develop your own wrapper for FeRe-
sPost (for use with Python, Perl, Java...), or use FeResPost C++ library in one of your
C++ applications. So most of you can forget this directory.
• “OUTPUTS/RUBY/” directory contains RUBY extensions for ruby versions between 1.8
and 2.4 (in corresponding sub-directories).
• “OUTPUTS/PYTHON/” directory contains Python extensions for Python versions be-

tween 2.6 and 3.7 (in corresponding sub-directories).
The ruby and python libraries must be used with the appropriate 64 bits distribution of ruby or
python.
X.A.1.2 Linux binaries (64 bits)

In archive “FeResPost_4.5.1_LINUX_64.7z” the binaries contain ruby wrappers and C++ li-
brary:
• “OUTPUTS/lib” directory contains the file “libFeResPost_4.5.1.so” that corresponds to

the FeResPost C++ library without any wrapper. If you intend to work with the C++
shared library, this file should be located in a library standard directory, or in a library
pointed to by environment variable “LD_LIBRARY_PATH”.


python.
X.A.1.3 Windows binaries (32 bits)

In archive “FeResPost_win32_4.5.1.7z” the binaries contain ruby wrappers, COM component
and C++ library:
• “OUTPUTS/lib” directory contains the file “libFeResPost_4.5.1.dll” that corresponds to

the FeResPost C++ library without any wrapper. If you intend to work with this shared
library, this file should be located in a directory that appears in the “Path” environment
variable. (The FeResPost extension shared libraries are linked to this C++ library so that
it must be accessible.)
X.A.1. BINARIES 505


• “OUTPUTS/COM” contains the directories and files for the COM component (dll and
tlb files). Information on the installation of the COM component on Windows is given in
section X.A.3.5.
python.
X.A.1.4 Windows binaries (64 bits)

In archive “FeResPost_win64_4.5.1.7z” the binaries contain ruby wrappers, COM component
and C++ library:
• “OUTPUTS/lib” directory contains the file “libFeResPost_4.5.1.dll” that corresponds to

the FeResPost C++ library without any wrapper. If you intend to work with this shared
library, this file should be located in a directory that appears in the “Path” environment
variable. (The FeResPost extension shared libraries are linked to this C++ library so that
it must be accessible.)


• “OUTPUTS/COM” contains the directories and files for the COM component (dll and
tlb files). Information on the installation of the COM component on Windows is given in
section X.A.3.5.
python.
X.A.1.5 Windows .NET assemblies

In archive “FeResPost_NET_4.5.1.7z” the assemblies are distributed in directory “OUTPUTS/NET”.
Three versions of FeResPost .NET assembly are build:
• In directory “OUTPUTS/NET/X86_CLR2”, one distributes 32 bits managed assembly

that targets CLR version 2.0. It should work with programs compiled under .NET Frame-
works versions 2.0, 3.0 and 3.5.

that targets CLR version 4. It should work with programs compiled under .NET Frame-
works versions 4, 4.5 (4.5.1 and 4.5.2) and 4.6 (4.6.1).

that targets CLR version 4. It should work with programs compiled under .NET Frame-
works versions 4, 4.5 (4.5.1 and 4.5.2) and 4.6 (4.6.1).
X.A.1.6 HDF shared libraries

As explained in section III.1.1.10, 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:
• The makefiles must be used with the GNU “make” command. This means that on Win-
dows OS, you should install the corresponding binaries. We use “MSYS” for several
UNIX commands, and have tested different versions of the GNU C/C++ compilers down-
loaded with different versions of “MINGW”. The compilation has also been tested with
different versions of Microsoft Visual C++ compiler.
• The “BASH” and “BAT” scripts are located in the “SRC” main directory. “BAT” scripts
are used for the compilation on Windows OS, and “BASH” scripts on LINUX. These
scripts define part of the compilation environment, and you may have to modify them if
you want to recompile the sources.
• The main Makefiles are located in “SRC/MAKEFILES” directory. They include sub-
makefiles located in the “SRC/MAKEFILES” directory and in the sources sub-directories.
The Makefiles in “SRC/MAKEFILES” directory also define part of the compilation en-
vironment and will have to be adapted in order to re-compile the sources. These adapta-
tions consist mainly in modifying paths to match installation on your computer. (Ruby
installation directory, for example.)
X.A.2. BUILDING FROM SOURCES 507
• The makefiles in source directories are built automatically. You just have to ask for the
building of “dependences” target. For example,you type the command “build_mingw32.bat
dependences”. (You do not need to do this if you do not modify the sources.)
• The association of script commands, makefiles and targets is summarized in Table X.A.1.
Besides, one also defines several targets that do not depend on the platform:
– “clean” cleans all the objects, libraries and other files produced by the compiler
command.
– “dependences” produces or updates the makefiles in the source directories.
– “ruby” to build all the ruby extensions available in the Makefile.
– “python” to build all the python extensions available in the Makefile.
– “com” to build the COM component.
– “archives” creates a 7Zip archive of the “OUTPUTS” directory.
– “outputs” produces all the libraries in other outputs in “OUTPUTS” directory, and
then builds the “archive”
• Some targets are specific to the .NET assembly compilation:
– “signkey” for the update of the assembly signature.

– “install” to install the assembly in the Global Assembly Cache (GAC).
• On Windows OS, the compilation of python extension is possible with the MSVC compil-
ers (“build_python_msvc32.bat” and “build_python_msvc64.bat” scripts) or with GNU
compiler (“build_mingw32.bat” and “build_mingw64.bat” scripts). We advise to use the
GNU compilers as it allows to build all the 32-bits python extensions with a single ver-
sion of the compiler.
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
ruby_24, ruby_23, ruby_22,
ruby_18, python_26, python_27,
build_linux32.bash Makefile.LINUX_586
python_30, python_31, python_32,
python_36, python_37, develop
ruby_19, ruby_18, python_26,
build_linux64.bash Makefile.LINUX_I64 python_27, python_30, python_31,
develop
com, ruby_25, ruby_24, ruby_25,
ruby_19, ruby_18, vbaruby, de-
build_mingw32.bat Makefile.WIN.32 velop, python_26, python_27,
python_36, python_37
com, ruby_25, ruby_24, ruby_23,
build_mingw64.bat Makefile.WIN.64
ruby_19, ruby_18, develop,
python_35, python_36, python_37
build_net.bat Makefile.NET net
build_msvc_x86.bat Makefile.MSVC_X86 com, ruby_18, vbaruby, develop
build_msvc_x64.bat Makefile.MSVC_X64 com, ruby_19, develop
build_python_win32.bat Makefile.PYTHON python_31, python_32, python_33,
python_34, develop
build_python_win64.bat Makefile.PYTHON
develop
X.A.3. INSTALLATION AND CONFIGURATION OF BINARIES 509
X.A.3 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:
• For ruby and python extensions:
– Make sure that you are using the FeResPost extension library that matches your
ruby version.
– Chose the right version among LINUX and Windows binaries.
– Chose the appropriate version among 32 bits and 64 bits libraries (for ruby wrapper
library as well as FeResPost C++ library).
• For COM component (on Windows), chose the Windows 32 or 64 bits C++ libraries for
Windows.
• There is no significant risk of mistake for the .NET assembly, but you have to chose
between CLR2 and CLR4, and between 32 bits and 64 bits versions (for CLR4). Actually,
CLR2 is rather old, so that CLR4 should work on most computers.
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 exten-
sion (section X.A.3.3)
Use FeResPost as COM component Install and register the COM component (sec-
(Windows only) tion X.A.3.5)
Use the .NET assembly Install the assembly in GAC (global assembly cache)
as explained in section X.A.3.6. An installation of the
redistributable Microsoft Visual C++ libraries may
also be necessary.
Develop you own wrapper around Install the C++ library and corresponding header files
FeResPost C++ library, or write a (section X.A.3.2)
program that directly uses the C++
library
Modify and/or recompile the Copy the sources and try to find inspiration in the in-
sources formation provided in section X.A.2
X.A.3.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 compo-
nent. (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:
• The simplest way to access the redistributable libraries is to add the complete directory
name to your PATH environment variable.
• You can also copy the redistributable dll files in a directory already point to by your
PATH environment variable.
• Possibly, the libraries are already installed on your computer and properly referenced by
your PATH variable. It might be the case if you have an installation of the appropriate
version of GNU compiler, or of a program that has been compiled with this compiler.
On Windows OS, your PATH environment variable can be modified in “Control Panel” –>
“System and Security” –> “System” –> “Advanced system settings” –> “Environment vari-
ables”.
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.xls
endlocal
(This is just an example, you have to adapt the PATH variable to your installation.)
X.A.3.2 FeResPost C++ developer’s library and headers

One distinguishes the UNIX/LINUX OS and Windows OS:
• On UNIX/LINUS OS, the file “libFeResPost_4.5.1.so” should be located in a library
standard directory, or in a library pointed to by environment variable “LD_LIBRARY_PATH”.
(If necessary, this variable can be modified to contain the path to directory in which you
copy the library.)
• On Windows OS, the library “libFeResPost_4.5.1.dll” should be located in a directory

that appears in the “Path” environment variable. (If necessary, this variable can be modi-
fied to include the path to the directory in which you copy the library.)
(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.3.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.3.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.3.5 COM component

The servers must be registered before use. For that purpose, a program called “modifyReg-
istry.exe” is distributed with FeResPost library. This program is used to add keys to the Win-
dows register. Follows some information:
• 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.
• The registration program allows the user to select the part that shall be installed among:
– The in-proc library “FeResPost.dll”,

– The type library “FeResPost.tlb”,
– The out-of-proc “FeResPost.exe” (no longer built or provided in libraries),
– The Proxy/Stub “Proxy.dll” (no longer built or provided in libraries).
The out-of-proc (EXE) server, and the corresponding Proxy/Stub library are not dis-
tributed with the binaries, and the Makefiles provided with the sources no longer build
these elements. So you cannot register these two elements at the moment, unless you
manage to compile them.
The registration of type library (TLB) is not necessary if the COM component is used
from compiled language. But the user must register the type library to use the component
from interpreted languages VBA, ruby, python...
The standard and recommended configuration involves the registration of the in-proc
library “FeResPost.dll’, and of the type library “FeResPost.tlb”.
• Among the keys and values that are written to the Windows registry, the full paths to
the dll, exe and tlb appear several times. This means that ones the component has been
registered, these files should not be moved. So, a proper location for the FeResPost
library should be selected prior to its registration.
• Several versions of FeResPost COM component can be installed at the same time on the
same computer.
The examples presented in Part VII require only the registration of in-proc library and type
library (recommended configuration).
You may register either 32 bits version of the component, or 64 bits version of the compo-
nent, or both 32 bits and 64 bits versions of the component:
• The 64 bits version of the component works on 64 bits Windows only. On the other hand,
the 32 bits version works on 32 bits as well as 64 bits versions of Windows. This means
that the registration of both 32 and 64 bits versions of the COM component is possible
only on 64 bits Windows OS.
• Windows manages the writing of kes in the appropriate directories of the register. For
example, when 32 bits component is registered in 64 bits Windows OS, CLASSES keys
are defined in “HKLM/Software/Wow6432Node/Classes/CLSID” directory.
• The registration is done with “modifyRegistry.exe” executable. The 64 bits “modifyReg-
istry.exe” must be used to register the 64 bits library, and the 32 bits “modifyRegistry.exe”
must be used to register the 32 bits library.
• The “dll” library name is the same for 32 bits and 64 bits versio of the component.
Therefore, the two dll files must be located in separate and preferably clearly identified
directories.
• The “tlb” file must be registered only once. For example, a possible scenario is to register
the 32 bits “dll” library and the “tlb” file 32 bits version of “modifyRegistry.exe”, then
use the 64 bits version of “modifyRegistry.exe” to register 64 bits “dll” library.
Figure X.A.1: Registration of FeResPost COM component.

• It is not always easy to determine whether the 32 bits or the 64 bits version of COM
component is to be used. For example, 64 bits versions of ruby or python seem to require
the 32 bits components that are accessed through “win32ole” or “win32con” extesnions.
Therefore, it may be a good idea to register the two versions.
• When one gets rid of an older version of FeResPost, the 32 bits and 64 bits versions of
the components must be un-registered separately.
X.A.3.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 As-
sembly 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:
• You may need Administrator’ privileges to perform the operation.
• You have to choose the right version of the .NET assembly. (See above.)
• You can also use an assembly without registration. Then, the assembly must be located
in the same directory as the one containing the executable.
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 coor-
dinate 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 orthogo-
nal vectors e1 , e2 and e3 . Then the vector f corresponds to:
3
X
f= f i ei .
i=1
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 = fi e i .
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 ) .
515
516 APPENDIX X.B. COORDINATE SYSTEM TRANSFORMATIONS
The nine quantities (ei ⊗ej ) can be considered as the basic tensors from which all the other ten-
sors 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 coor-
dinate 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. Convention-
ally, 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 g i are obtained by deriving the position p wrt coordinates:
∂p
g1 = gr = ,
∂r
∂p
g2 = gθ = ,
∂θ
∂p
g3 = gz = .
∂z
Finally, the three tangent vectors are normalized as follows:

gi
ei =
kg i k
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 character-
istic 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 transfor-
mations 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. TRANSFORMATION OF COMPONENTS 517
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 e0i respectively. So one has:
v = vi ei = vi0 e0i .
In the last expression we introduce the notations vi and vi0 for the components of vector v in ei
and e0i respectively.
It is possible to decompose the vectors e0i as a linear combination of vectors ej :
e0i = Aij ej .
The coefficients Aij are easily calculated. Indeed, the scalar multiplication of the previous
equality by ek gives successively:
e0i · ek = (Aij ej · ek ) ,
e0i · ek = (Aij δjk ) ,
e0i · ek = Aik ,
or finally:
Aij = e0i · ej .
By a similar calculation, it is possible to identify the relations between the components of

vector v expressed in the two coordinate systems:
e0k · v = e0k · (vi ei ) = e0k · (vi0 e0i ) ,

vi (e0k · ei ) = vi0 (e0k · e0i ) ,
vi Aki = vi0 δki ,
Aki vi = vk0 ,
Finally, one sees that the relation between base vectors and vector components are the same:
e0i = Aij ej ,
vi0 = Aij vj .
That’s the reason why the transformation is called a covariant transformation. One also says
that vi or vi0 are covariant components of vector v in coordinate systems ei and e0i respectively.
In the last vector component transformation one recognizes a classical algebraic result:
V0 =A·V .
The matrix Aij is orthogonal: (Aij )−1 = Aji and the reverse relation for vector components
is:
vj = Aji vi0 .
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 ) = Tij0 (e0i ⊗ e0j ) .
Using the same definition of transformation matrix Aij as in section X.B.2.1, one writes:
ek = Aik e0i ,
el = Ajl e0j .
Then, the substitution of the two expressions in the equations defining components gives:
T = Tkl (ek ⊗ el ) = Tij0 (e0i ⊗ e0j ) ,
Tkl (Aik e0i ⊗ Ajl e0j ) = Tij0 (e0i ⊗ e0j ) ,
Aik Tkl Ajl (e0i ⊗ e0j ) = Tij0 (e0i ⊗ e0j ) .
The last expression allows us to extract a relation involving only the components of tensors,
and not the base vectors:
Tij0 = Aik Tkl Ajl .
Here again, one recognizes a classical matricial expression:
T 0 = A · T · At .
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:
e0i = cos θei + (1 − cos θ)(v · ei )v + sin θ(v × ei ) . (X.B.1)
In particular, if v corresponds to e3 , the three
e01 = cos θe1 + (1 − cos θ)(e3 · e1 )e3 + sin θ(e3 × e1 ) ,
= cos θe1 + sin θ(e2 ) ,
= cos θe1 + sin θe2 .

= cos θe2 + sin θ(−e1 ) ,
= cos θe2 − sin θe1 .

= cos θe3 + (1 − cos θ)(1)e3 ,
= e3 .
X.B.4. MODIFICATION OF COORDINATE SYSTEMS 519
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 pro-
jected 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. Usu-
ally, it is defined with the three first definition nodes of the element. Direction X corre-
sponds 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 ap-
propriate 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 coordi-
nate 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 corre-
sponds 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 cor-
responds 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 coordi-
nate 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:

1 1
x1 = + ξ xA + − ξ xC ,
2 2

1 1
x2 = + η xB + − η xD .
2 2
So, one has to find the parameters ξ and η that minimize kx1 − x2 k. The vector x1 − x2 can
be developed as follows:
x1 − x2 = (xA − xB + xC − xD ) + (xA − xC ) ξ + (xD − xB ) η ,
= v3 + v1ξ + v2η ,
where
v 1 = xA − xC ,
v 2 = xD − xB ,
v 3 = xA − xB + xC − xD .
The square of the norm defined above (x1 − x2 )2 depends on parameters ξ and η and is
given by:
f (ξ, η) = v 23 + 2v 3 · v 1 ξ + 2v 3 · v 2 η + v 21 ξ 2 + v 22 η 2 + 2v 1 · v 2 ξη .
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 η:
v 3 · v 1 + v 21 ξ + v 1 · v 2 η = 0 ,
v 3 · v 2 + v 1 · v 2 ξ + v 22 η = 0 .
These two equations may be rewritten as follows:
v 1 · (v 3 + v 1 ξ + v 2 η) = 0 ,
v 2 · (v 3 + v 1 ξ + v 2 η) = 0 ,
Or simply
v 1 · (x1 − x2 ) = 0 ,
v 2 · (x1 − x2 ) = 0 .
This equation simply means that the vector connecting the two optimum points is perpendic-
ular 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:
x1 + x2
x0 = ,
2
xA + xB + xC + xD xA − xC xB − xD
= + ξ+ η.
4 2 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 pro-
vides 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 Carte-
sian 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: r 1 = R, r 2 = S, r 3 = T . So the element coordinate
system is {O, ei } and the three vectors R, S and T are denoted r i . Then one defines with matrix
A corresponding to the description of vectors r i on the base ei . One has:
r i = Aij ej ,
Aij = r i · 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:
r i · ej = r j · 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 r i provided as data, one must find the three
components of the vector w = θv such that the new base vector e0i obtained with equation
(X.B.1) satisfy the relation
r i · e0j − r j · e0i = 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:
e0j ≈ ej + ∆ej ,
∆ej ≈ ∆w × ej .
Substituting the two previous expressions in (X.B.2), one obtains successively:
r i · (ej + ∆ej ) − r j · (ei + ∆ei ) = 0 ,
r i · (ej + ∆w × ej ) − r j · (ei + ∆w × ei ) = 0 ,
r i · (∆w × ej ) − r j · (∆w × ei ) = r j · ei − r i · ej ,
(ej × r i − ei × r j ) · ∆w = r j · ei − r i · 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:
θ = k∆wk ,
∆w
v= .
k∆wk
(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 mod-
ification 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:
• The entities (Result keys) to which values are attached are noted:
– “E” if Result values are attached to element centers,

– “N” if Result values are attached to nodes,
– “EL” if Result values are attached to element centers and are layered,
– “EN” if Result values are attached to element corners,
– “ENL” if Result values are attached to element corners and are layered.
Some Results allow several possibilities for the attachment of values.
• The tensoriality of Results is noted as follows:
– “S” means that the Result has scalar values,

– “V” means that the Result has vectorial values,
– “T” means that the Result has tensorial values.
The Results have been defined in such a way that each type of Result has only one
possible tensoriality.
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.
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.
525
526 APPENDIX X.C. RESULTS CHARACTERISTICS
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
X.C.1. REAL RESULTS 527
Table X.C.2: Grid Points Forces.

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.

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.

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.

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.

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.

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

Name Entities Type
“Composite Failure Index, Tsai-Hill Version 1” 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, Maximum Strain” EL, ENL T (11)
“Composite Failure Index, Maximum Strain, CompMax” EL, ENL S (11)
“Composite Failure Index, Maximum Stress” EL, ENL T (11)
“Composite Failure Index, Maximum Stress, CompMax” EL, ENL S (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).

Name Entities Type
“Composite Critical Ply Failure Index, Tsai-Hill Version 1” 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, 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).

Name Entities Type
“Composite Critical Ply, Tsai-Hill Version 1” 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, 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.

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
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 sys-
tematically nil. The non-zero components are:
   
Fxx Fxy Fxz Mxx Mxy Mxz
F =  Fxy 0 0  , M =  Mxy 0 0  .
Fxz 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 compo-
nents as follows:    
Fxx Z σxx
{F } =  Fxy  =  τxy  dΩ .
Fxz Ω τxz
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:
   
Mxx Z (y − yC ) τxz − (z − zC ) τxy
{M } =  Mxy  =  (z − z0 ) σxx  dΩ .
Mxz Ω − (y − y0 ) σxx
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
   
Fxx Mxx
{F } =  Fxy  and {M } =  Mxy 
Fxz 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 displace-

ments 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 respec-
tively. These Results contain all the force and moment tensors produced by 2D elements.
The non-zero components are:
   
Fxx Fxy Qxz Mxx Mxy 0
F =  Fxy Fyy Qyz  , M =  Mxy Myy 0  .
Qxz Qyz 0 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:
Z h/2
Fxx = σxx dz ,
−h/2
Z h/2
Fxy = σxy dz ,
−h/2
...
Similarly, one assumes that the bending moments tensor is calculated using the distribu-
tion through the thickness of the Cauchy stress tensor components as follows:
Z h/2
Mxx = zσxx dz ,
−h/2
Z h/2
Mxy = zσxy dz ,
−h/2
...
This is a usual convention for shell elements. For example, this is generally the conven-
tion 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 = γij /2.
6. The shell curvature tensor is defined as follows:

     0 
κxx Z h/2 xx w,xx
12 0
{κ} =  κyy  = 3 z  yy  dz =  w,yy  .
h −h/2 0
κxy xy w,xy
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.
X.C.2. COMPLEX RESULTS 533
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 re-
mark 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 (displace-
ments). 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.

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.

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
X.C.2. COMPLEX RESULTS 535
Table X.C.14: Beam element Complex Results.

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

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/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:
1
MoS = v !2 !2 − 1 ,
u
u τL τW
FoSt +
σL σW
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:
• The four first elements correspond to the Result key on which the minimum margin of
safety is calculated.
• Then, the two components of the out-of-plane shear stress at critical location is given.
• Then, one gives the critical (minimum) margin of safety.
537
538 APPENDIX X.D. PREDEFINED CRITERIA
• The last element of the Array is a Result object that contains the margins of safety
element-per-element, node-per-node...
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 SubLayerId Integer 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:
1
MoS = v !2 !2 − 1 ,
u
u τL τW
FoSt +
σL σW
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:
1 1
SR = = .
RF M oS + 1
X.D.1. LIST OF THE PREDEFINED CRITERIA 539
This leads to the following expression for the strength ratio:

v
u τL 2
u ! !2
τ W
SR = FoSt + ,
σL σW
(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 “HoneycombAir-
busMoS” 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:
• Then, the two components of the out-of-plane shear stress at critical location is given.
• Then, one gives the critical (maximum) strength ratio.
• The last element of the Array is a Result object that contains the strength ratio element-
per-element, node-per-node...
Table X.D.3: Arguments of the “HoneycombAirbusSR” predefined criterion

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
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:
σall
MoS = −1,
FoSσV M
s
(σxx − σyy )2 + (σyy − σzz )2 + (σzz − σxx )2 2 + 3σ 2 + 3σ 2 .
σV M = + 3σxy xz yz
2
Table X.D.4: Outputs of the “HoneycombAirbusSR” predefined criterion

. 4 SubLayerId Integer 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
• Then, Von Mises equivalent stress at critical location.
Table X.D.5: Arguments of the “VonMisesMoS” predefined criterion

. 2 fos Real factor of safety NO
3 sigAll Real allowable stress NO
Table X.D.6: Outputs of the “VonMisesMoS” predefined criterion

.
4 SubLayerId Integer 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:
1 1
SR = = .
RF M oS + 1
This leads to the following expression for the strength ratio:
FoSσV M
SR = ,
σall
in which
s
(σxx − σyy )2 + (σyy − σzz )2 + (σzz − σxx )2 2 + 3σ 2 + 3σ 2 .
σV M = + 3σxy xz yz
2
• Then, Von Mises equivalent stress at critical location.
Table X.D.7: Arguments of the “VonMisesSR” predefined criterion

. 2 fos Real factor of safety NO
3 sigAll Real allowable stress NO
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:
1 1
SR = = .
RF M oS + 1
In this case, three strength ratios are calculated:
Table X.D.8: Outputs of the “VonMisesSR” predefined criterion

.
4 SubLayerId Integer 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
• For the sliding strength ratio, one calculates:
FoSsliding · (Cf · max(Faxial , 0) + Fshear )

SRsliding = ,
Cf · Pmin
in which Cf is the friction coefficient between assembled elements and Pmin is an estimate
of the minimum possible pretension of the bolt.
• The gapping strength ratio is given by:
FoSgapping · (max(Faxial , 0) + Mbending /R)

SRgapping = ,
Pmin
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.
• The insert criterion is calculated as follows:

v
u Faxial 2
u ! !2
Fshear
SRinsert = FoSinsert · t + ,
PSS QSS
In which “PSS” is the axial allowable of the insert and “QSS” is its shear allowable.
In these expressions, various scalar values related to the connection force and moment vectors
are calculated:
Faxial = F · d ,
q
2
Fshear = F · F − Faxial ,
Mtorsion = M · d ,
q
2
Mbending = M · M − Mtorsion .
The arguments of the criterion are given in Table X.D.9:
• First argument is a DataBase.

• The second argument is a String that corresponds to extraction method. If this argument
is “BSHFRC” or “BMFRC”, the forces and moments are assumed to be associated to
elements. Otherwise they are associated to nodes. (This parameter influences the critical
entity ID returned for each failure criterion.)
• Arguments 3 and 4 are Result objects that correspond to the connection forces and mo-
ments. Note that these Result objects can be modifed if the predefined criterion is cal-
cualted. It is the case, for example, if the coordinate system wrt which force and moment
components are expressed is changed.
• Arguments 5 to 8 define the direction vector that allows to convert vectorial forces and
moments to the corresponding scalar derived components.
• Arguments 9 to 11 correspond to the safety factors of the different criteria. A negative

safety factor means that the corresponding criterion must not be calculated. Then the
corresponding output values are initalized to Boolean “FALSE”.
• Arguments 12 to 16 are clearly presented in Table X.D.9
The method returns an Array of 15 elements (5 elements for each criterion):
• Elements 1 to 5 correspond to the sliding criterion and are:
– The maximum strength ratio;

– The corresponding entity ID (element or node ID),
– The corresponding connection axial force.
– The corresponding connection shear force.
– A Result object containing all the strength ratios.
If the sliding safety factor is negative, the criterion is not calculated, and 5 “FALSE”
Booleans are returned.
• Elements 6 to 10 correspond to the gapping criterion and are:

– The corresponding connection bending moment.
If the gapping safety factor is negative, the criterion is not calculated, and 5 “FALSE”
• Elements 11 to 15 correspond to the insert criterion and are:


– The corresponding connection shear force.
If the gapping safety factor is negative, the criterion is not calculated, and 5 “FALSE”
Table X.D.9: Arguments of the “SGI_SR” predefined criterion

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
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:
• One must first define the itneger ID that is associated to the criterion. This is done by
inserting the appropriate “#define” statement at the beginning. For example:
#define UD_criterion_1 20001

// ...
in which one assumes that all the user criteria are prefixed with “UD_” string. (It is
advised to prefix the criteria following this kind of convention to reduce the risk of clash
with someone else’s criterion.)
X.D.2. USER PREDEFINED CRITERIA 545
Table X.D.10: Outputs of the “SGI_SR” predefined criterion

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)
• Then, at the beginning of the “result::calcPredefinedCriterion” method, the mapping be-

tween criteria names and integer IDs must be build (“critNameIds” variable). This is
currently done by the following C++ lines:
if (bFirstHere) {
critNameIds.insert(make_pair("HoneycombAirbusMoS",HoneycombAirbusMoS));
critNameIds.insert(make_pair("HoneycombAirbusSR",HoneycombAirbusSR));
critNameIds.insert(make_pair("VonMisesMoS",VonMisesMoS));
critNameIds.insert(make_pair("VonMisesSR",VonMisesSR));
critNameIds.insert(make_pair("SGI_SR",SGI_SR));
critNameIds.insert(make_pair("UD_criterion_1",UD_criterion_1));
// ...
}
(Here again, the User is allowed to change the criteria name and associated integer vari-
able names.)
• Finally, the new criterion “case” must be defined in the “switch(critId)” case. The case
integer ID corrtrsponds to the integer value defined with “#define” statement. The otugh
part fo the job is to write the appropriate C++ source code. We hope that the criteria
already defined will be a source of inspiration for the developers.
Appendix X.E
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.E.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.E.1:
• Excel and its objects (workbooks, worksheets, ranges, automation buttons...) are repre-
sented in blue.
• The green part corresponds to the small bits of VBA code that is necessary to call the
ruby runtime environment through the bridge.
• The parts specific to the bridging are represented in red. In the excel process, they cor-
respond to the two loaded dynamic libraries (the bridging and the ruby runtime environ-
ment, and their different interactions. Outside excel process, the external environment
corresponds to ruby programs, loaded extensions, input and output files...
In order to explain how the bridging works, one gives in section X.E.1.1 information about
the programming of the bridge. In section X.E.2.1 one explains what is done in excel VBA
modules to use the bridge and ruby programs.
X.E.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:
547
548 APPENDIX X.E. FERESPOST RUBY EXTENSION IN EXCEL
Excel
Excel objects
VBA BRIDGE RUBY
RUBY external environment

(programs, extensions, IO files...)
Figure X.E.1: Schematic representation of the connections existing between excel objects, VBA,
VBA-ruby bridge, ruby and the external world inside excel memory.
• Files “conversion.h” and “conversion.cpp” are devoted to type conversion between VBA
and ruby. More precisely, the corresponding “convert” C++ methods perform conver-
sions between VBA “Variant” and ruby “VALUE” types. Note that conversion are done
from Variant to VALUE, or in the other direction. Some “convert” methods from Variant
to other C++ types are also defined for internal use only.
• “win32ole.h” and “win32ole.cpp” define methods that are called from “conversion.cpp”
functions. They contain specifics to the conversion of COM automation types. The
reason why these methods have been kept separate from the conversion ones, is that the
bits of code in our “win32ole” files have been extracted from the corresponding sources
of ruby “win32ole” extension.
• Files “marshal.h” and “marshal.cpp” contain the definition of methods that dispatch the
calls from VBA to ruby. In particular, four methods that are meant to be exported in the
dll library are defined here.
• File “marshal.def” exports the methods that will be used in excel: “RubyInit”, “RubyFin-
ish”, “RubyRequire”, “RubyLoad” and “RubyCallMethod”. The “RubyInit” method has
no argument and simply initializes the ruby runtime. The “RubyFinish” method is used to
quit ruby interpreter and unload the bridge library. Methods “RubyRequire” and “Ruby-
Load” can be used to load the ruby programs that shall later be called from VBA. Each
of these two methods has one argument corresponding to the name of the ruby file to
be imported. Finally, method “RubyCallMethod” is the one that really performs the dis-
patch between VBA and ruby. The method has four arguments that correspond to the
methods receiver (module or class name), the name of the method, an Array containing
the arguments, and the Variant in which the value returned by the method shall be stored.
The four methods listed above return an integer containing the error code.
Note that the four arguments of the method “RubyCallMethod” are pointers to VARIANT
objects:
X.E.1. A VBA-RUBY BRIDGE 549
extern "C" int __stdcall RubyCallMethod(const VARIANT *objName,

const VARIANT *methodName,const VARIANT *args,
VARIANT *ret) {
...
}
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
-c conversion.cpp
-c win32ole.cpp
gcc -O2 -LC:/NewProgs/RUBY/Ruby187/bin \
-fPIC -shared -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.E.1.2 Requirements
One summarizes here the requirements to use the VBA-ruby bridge:
• The bridge works on Windows platforms only.
• It must be used from VBA environment. Typically, it shall be used in excel.
• the “win32ole” ruby extension must be available.
• The dll library is linked to a peculiar version of ruby runtime machine. This means that
this version of the runtime must be available, and the corresponding “bin” directory must
be in the “PATH” environment variable. If someone wants to use another version of the
ruby runtime machine, then the bridge must be recompiled.
• Some of the practical details for using the bridge are explained in the example in sec-
tion X.E.2.
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.E.2 An example
One presents in directory “TESTSAT/VBARUBYEX” an example that corresponds to the
“PostProject.xls” example illustrating FeResPost COM component. (See section VII.4.) The
programming of ruby modules is discussed in section X.E.2.1. Two VBA modules are defined
in the excel workbook: “RubyMarshal” and “RubyFunctions”. These modules are discussed
in section X.E.2.2 and section X.E.2.3 respectively. A few other points are discussed in sec-
tion X.E.2.4.
X.E.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:
• The first lines update the list of directories from which ruby files and extensions shall
be loaded. You must change these lines according to the local configuration of your
computer. Note that the first directory added to the list is defined relative to the current
working directory. The rest of the programming assumes that the working directory is the
one in which “PostProject.xls” is located. A special VBA command in “PostProject.xls”
has been added to ensure it is the case.
• The following lines redirect standard outputs to “main.log” file. This can be handy when
you have a bug and you want to retrieve ruby error messages.
• Finally, the lines that follow perform “require” statements that load the programmed
modules. The “postProject” require corresponds to most of the post-processing program-
ming.
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.E.2. AN EXAMPLE 551
X.E.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 constant “vbaRubyLib” contains the full path to bridge dynamic library. You will
probably have to change this line to match the configuration of your computer.
• Two methods from “kernel32” system library are declared. These methods are used to
load and free libraries.
• Five methods from the “vbaruby” bridge dll library are declared. Those are the methods
that perform the marshaling between VBA and ruby. Note that all the parameters are long
integers; these correspond to pointers towards the corresponding VARIANT objects.
• Variable “testLibrary” contains a pointer to the bridge library.

The VBA procedure “libInit” performs the loading of the bridge library and the require state-
ment 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 pref-
erences.
The VBA function “CallMethod” calls the bridge method “RubyCallMethod”. Its three ar-
guments 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 ar-
gument 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 ar-
guments 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.E.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 func-
tion “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( _
X.E.2. AN EXAMPLE 553
"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.E.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 correspond-
ing 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 rel-
ative to the directory containing “PostProject.xls” is used in the “RubyMarshal” VBA module.
(Sees section X.E.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.xls”. (See section X.E.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.E.2.5 Things to do to match a particular configuration

In order to adapt the example to your configuration you must:
• Change the “vbaRubyLib” constant in “RubyMarshall” Module of the excel spreadsheet.
• Change the “PATH” environment variable so that it points to the “bin” directory of the
particular version you intend to use.
• In “RUBY/main.rb” file, change the include directory definition:
$: << "D:/SHARED/FERESPOST/SRC/OUTPUTS/RUBY_191"
Appendix X.F
Copying FeResPost
X.F.1 Copyright
Copyright 2005-2015 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 WAR-
RANTY; 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.F.2 GNU GENERAL PUBLIC LICENSE
GNU 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.
555
556 APPENDIX X.F. COPYING FERESPOST
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 war-
ranty 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
X.F.2. GNU GENERAL PUBLIC LICENSE 557
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.
T ERMS AND C ONDITIONS
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 li-
censee is addressed as “you”. “Licensees” and “recipients” may be individuals or orga-
nizations.
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 modifi-
cations 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 pro-
gramming 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 mod-
ify 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 automat-
ically 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 condi-
tions 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 mea-
sures.
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 require-
ment 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 Ap-
propriate 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 prod-
uct 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 Li-
cense, 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 facili-
ties, 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 of-
fered to the general public at no charge under subsection 6d.
A separable portion of the object code, whose source code is excluded from the Corre-
sponding 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 per-
sonal 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 sub-
stantial 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, autho-
rization 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 mod-
ified 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 addi-
tional 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 mod-
ified 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, trade-
marks, 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 restric-
tion, 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 ma-
terial 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 Pro-
gram. 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 sub-
stantially 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 trans-
action 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 Pro-
gram 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 com-
mitment, 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 Correspond-
ing 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 acces-
sible 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 ex-
tend 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 Gen-
eral 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 IM-
PLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE EN-
TIRE 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, IN-

CIDENTAL 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.
E ND OF T ERMS AND C ONDITIONS
X.F.3 GNU LESSER ENERAL 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 condi-
tions of version 3 of the GNU General Public License, supplemented by the additional permis-
sions 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 Applica-
tion 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".
X.F.3. GNU LESSER ENERAL PUBLIC LICENSE 567
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 applica-
ble 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 docu-
ment.
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 pro-
vide 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 Com-
bined 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
X.F.3. GNU LESSER ENERAL PUBLIC LICENSE 569
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.G
Summary of changes
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:
• Correction for the reading of strain tensor, and curvature tensor in “op2” Nastran results
file.
• Correction of small bugs in the reading of element forces.
Addition of new capabilities:
• Addition of the new functions “min”, “max” and “cmp” in the “Post” Module.
• New methods have been added to the ResKeyList class.
• The reading of strain/stress tensors, and of element forces is supported for additional
element types.
The modifications of the manual correspond to the modifications of the library and of the ex-
amples:
• Modifications corresponding to the reading of strain tensor from “op2” Nastran results
file. Also, a few comments about the strain tensor have been added. Correspondingly, an
example has been added (section IV.2.4.4).
• Presentation of the new functions “min”, “max” and “cmp” in the “Post” module in
section I.6.3.
• Modification of the presentation of post-processing data definition for the calculation of
margins of safety with the Cauchy stress tensor.
• Modifications corresponding to the new methods introduced in the ResKeyList class
(Chapter I.5).
571
572 SUMMARY OF CHANGES
Version 1.0.2
The new version of the library is issued 2005/09/11.
• The four elementary operators “+”, “-”, “*” and “/” allow now Float or Array left operands.
The FeResPost library also modifies the corresponding classes.
• Correction of a few small bugs.
The modifications of the manual correspond to the modifications of the library and of the ex-
amples:
• The four elementary operators “+”, “-”, “*” and “/” allow now Float or Array left operands.
The post-processing example as been modified accordingly.
• The post-processing example has been modified in such a way that the methods defined
in “Post” module are included in “Main” name space.
Version 1.0.3
• Correction of a bug in result extraction.
• A new element coordinate system “elemIJK” is introduced.
• Several modifications have been brought to the modifications of reference coordinate

systems. (Possibility of projecting coordinate systems, for example).
The modifications of the manual correspond to some of the modifications of the library, and a
little more:
• Addition of Appendix X.B devoted to the thoeretical background of transformation of

coordinates.
• Addition of an example illustrating the capabilities of coordinate system transformations

(section IV.2.4.5).
Version 1.0.4
• The definition of local element (Nastran) coordinate systems has been modified.
• The “CTETRA” element is now supported.
• The reading of “op2” files is now more reliable. Previously tests were made with Nastran
version 70.5 only. Now Nastran 2005 has been tested and a few bugs have been corrected.
SUMMARY OF CHANGES 573
• Also, the reading functions check the “endiannes” of “op2” files and the performs the
needed corrections when reading the content. This improves the portability of the result
files from one platform to another.
little more:
• Modification of the example illustrating the capabilities of coordinate system transfor-
mations (section IV.2.4.5). One more transformation is proposed. Moreover, one also
gives an example with results on 3D elements.
Version 1.0.5
• Correction of few bugs.
• Modification of the C++ programming of op2 reading. The reliability should be im-
proved.
• The third argument of function “modifyRefCoordSys” is now optional.
• It is now possible to manipulate CoordSys objects and store them into a DataBase.
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
• More results types can be read from op2 files, and also results for other solution se-
quences can be read. (SOL 101, 103, 105 and 106 are now supported.)
• Additional Nastran cards can be read from bdf or op2 file.
• Some readings of entities in Nastran results or models can be desactivated.
• A new function allows to calculate the total force and moment corresponding to a distri-
bution of forces and moments. (see function “calcResultingFM” in section I.4.7.
• Modification of “generateCoordResults” method in DataBase class. The method can now

have three String arguments that correspond to the key to which the generated Result
object is associated in the DataBase.
little more:
• Modification of the example presented in section IV.2.4.1 to illustrate the modification of

function “generateCoordResults” in DataBase class.
• Addition of a new example in section IV.2.5.3 to illustrate the calculation of global force
and moment transmitted by an interface.
Version 1.0.7
• Addition of method “writeBdfLines” to the “DataBase” class.
• Addition of methods “renameResults” and “copyResults” to the “DataBase” class.
The modifications of the manual correspond to some of the modifications of the library.
Version 1.0.8
Version 2.0.0
• Modification of a few Nastran Result names.
• Addition of a Samcef interface.
• PCOMPG Nastran card is now supported.
• New options for “deriveByRemapping” method in “Result” class. The new options are
“mergeLayers” and “mergeLayersKeepId”.
• Addition of methods “initWithOV2V1”, “initWithOV3V2” and “initWithOV1V3” to the

“CoordSys” class.
• Addition of method “setRefCoordSys” to the “Result” class.
• Addition of method “extractResultOnLayers” to the “Result” class.
• In nearly all functions dealing with layers, the layer may be identified either with String
or integer objects. The correspondence between the two identification methods is sum-
marized in Table I.4.4.
• Addition of “extractLayers” and “extractGroup” methods to “Result” and “ResKeyList”

classes.
Version 2.1.0
• Reading of Dynam and Stabi Samcef Results.
• Addition of “getSize” method to “Result” class.
• Modification of “getResultCopy” method in “DataBase” class.
• Modification of Result names to harmonize Samcef and Nastran Results access:
– “Shell Forces” and “Shell Moments” for forces in 2D reduction elements.

– “Beam Forces” and “Beam Moments” for forces in 1D reduction elements.
– Beam Results in general.
– Composite Results.
– ...
Some of the examples have been modified accordingly.
• Correction of a few bugs.
Version 2.2.0
• In the DataBase class, addition of several methods:
– “readXdb” to import Result from a Nastran “xdb” file.

– “removeAllResults” to clean the Results stored in a DataBase.
– “eraseAllGroups” to erase all the Groups stored in a DataBase.
– “getElementsAssociatedToMaterials”,
– “getElementsAssociatedToProperties”,
– “getElementsAssociatedToPlies”,
– “getElementsAssociatedToLaminates”,
– “getElementsAssociatedToAttr1s”,
– “getElementsAssociatedToAttr2s”.
Also, two functions are now marked “to be deprecated soon”:
– “getElementsAssociatedToMaterialId”,
– “getElementsAssociatedToPropertyId”.
• Addition of a few methods in the “Group” class:
– “getNbrEntitiesByType”,
– “getNbrEntities”.
• Two methods added to “Post” module allow the activation and deactivation of Samcef
Result codes:
– “activateSamcefResCodes”,
– “desactivateSamcefResCodes”.
• A few modifications of Results corresponding to Bush and Gap elements.
• Correction of a few bugs in the reading of Samcef composite Results.

Version 2.3.0
• Correction to the beam element type forces and moments imported from Nastran Result
files.
• Improvement of the support for Samcef coordinate systems. However limitations for
results given in element axes still exist!
• Modification of the arguments of methods used to import Results. It is now possible

to filter the Results being imported. (Modified methods are “readOp2”, “readXdb” and
“readDesFac”.
Version 2.4.0
• Redefinition of keys for force and stress Results on Nastran CBEAM and CSHEAR ele-
ments.
• Redefinition of “getData” method and addition of “getStrData” method to the Result

class.
• Deletion of “getStrData” method from the Result class.

• “getData” method from the Result class has now optional arguments that allow to tune
the type of values returned in the Array. The values corresponding to the element, the
node, the layer and the coordinate system may now be of integer or string type.
• The "feresPost.so" library build by the Makefile is now output in the "FeResPost.so"
file. Also, the classes "CoordSys", "ResKeyList", "DataBase", "Group", "Result" and the
module "Post" are defined under the new module "FeResPost". The ruby programs using
the previous versions of FeResPost must be modified. More precisely, the line
require "feresPost"
in the previous versions must be replaced by the two following lines:
require "FeResPost"
include FeResPost
and the rest of the program may be left unchanged.
• Addition of the “lamCS” coordinate system identifier in the “result::values” class. Also,
the use of “lamCS”, “matCS” and “plyCS” parameters in the “modifyRefCoordSys”
method of “Result” class has been modified.
• Correction of a bug in the reading of stresses on Nastran solid elements. (The reference
coordinate system was wrong.) Similar corrections for the reading of layered results.
• Correction of bugs when reading Samcef beam forces and moments.
• Addition of several methods allowing the manipulation of flags influencing the behaviour
of “readDesFac” method in “DataBase” class. This has been done to correct a bug in
Samcef. Actually, only the “ANGULAR_STRAIN_BUG” flag can be set to correct er-
rors in the shear components of strain tensor.
• Addition of the “generateElemAxesResults” method to “DataBase” class.
• Addition of the “sgn” derivation method for scalar Results.
• Addition of the “deriveVectorToVector” method for vectorial Results.

Version 2.5.0
• Addition of functions for the manipulation of abbreviations read from Samcef finite ele-
ment models in the DataBase class. (Section I.1.7.)
• Addition of a method allowing the renumbering of layers in a Result object. (Section

I.4.5.3.)
• Addition of a “writeGmsh” method to the DataBase class. (See section I.1.7.)

• Addition of iterators to different classes (Group, Result, ResKeyList and DataBase classes).
• A few modification of rules for coordinate system definitions and transformations on

Results associated to elements with laminated properties. (See section I.4.5.7 and section
X.B.5.)
The modifications of the manual correspond to some of the modifications of the library. Let us
mention however:
• Addition of an example illustrating the use of the new “writeGmsh” method of the
DataBase class. This example is presented in section IV.2.5.4.
• Modification of examples to illustrate the use of iterators. See for example, sections
IV.2.2.2, IV.2.4.1, IV.2.4.4 and IV.2.4.5.
• A few modification of rules for coordinate system definitions and transformations on

Results associated to elements with laminated properties. (See section I.4.5.7 and section
X.B.5.)
Version 2.6.0
• Correction of a bug in reading the OQG block of the Nastran op2 file.
• A bug in the “writeGmsh” method of the “DataBase” class has been corrected.
• Addition of “eachLcScId” iterator to DataBase class.
• Modification of sub-case identifier of Results read in Samcef Results (asef module). One
now names them with “Statics” instead of “Static SubCase”.
• Addition of methods to the “Group” class: “clearEntitiesByType”, “importEntitiesBy-

Type”.
• Suppression of the definition of assignment operators “+=”, “-=”, “*=”, “/=” in “Group”,
“Result” and “ResKeyList” classes. However, these operators can still be used as ruby
generates them automatically from the corresponding dyadic operators.
• Addition of the “insert” method to the “ResKeyList” class that allows the user to fill its
own ResKeyList objects.
• Addition of the “insert”, “setTensorOrder” and “getTensorOrder”method to the “Result”

class that allow the user to fill its own Result objects.
mention however:
• Modification of the example "EX04" presented in section IV.2.4.1.

Version 2.7.0
• When reading Nastran laminate ILSS failure indices, the "-1" values are no longer in-
serted in the Result.
• Correction of a bug in the reading of stresses and strains from an xdb file.
• Correction of a bug in reading Samcef results.
mention however:
• Modification of the post-processing program example. One now presents a simple mod-
ular example, and a more sophisticated object-oriented example.
Version 2.8.0
• Correction of a bug in the re-definition of “+”, “-” and “*” operators of the Array class.
• Addition of sub-layer id field to the Result keys. Several classes and methods are affected
by this modification:
– Several methods of the “Result” class are modified: “getData”, “extractResultO-
nEntities”, “insert”, “each”, “each_key”.
– One also added methods “extractResultOnSubLayers”, “extractSubLayers”.
– Several methods of the ResKeyList class: “insert”, “each”. One also added “ex-
tractSubLayers” method.
When possible, one tried to modify the methods in such a way that previous versions of
ruby programs using FeResPost were not to be deeply modified. Most modified methods
do not require a corresponding modification of the ruby programs. However, for “get-
Data” and “each” methods of Result class, more care is necessary. To ease the migration
of post-processings, the previous version of “getData” still exists but has been renamed
“oldGetData”.
• It is now possible to read Samcef result codes 1???? and 2????. (Composite results on
top and bottom surfaces of plies.) This is related to the addition of a sub-Layer ID in
Result keys.
• Addition of methods “activateSamcefSubLayerResCodes” and “desactivateSamcefSub-
LayerResCodes” to the “Post” module to desactivate the reading of sub-layer result codes
from Samcef finite element Results.
• Modifications in the importation of Nastran shell bending and curvature Results.
Version 2.9.0
• Correction of a serious bug that affected all dyadic operations on Results. This bug
resulted in segmentation faults when FeResPost was run on windows, in version 2.8.0.
• Modification of the “writeGmsh” method in “DataBase” class. It is now possible to

output Results at "ElemCenterPoints". Void Results are no longer output in the file.
• Correction of a bug in the reading of Samcef banque file. No the reading should work for
all types of line splitting.
• Correction of a few other minor bugs.
• Addition of CLA module for Classical Laminate Analysis calculations. The module is
still under development.
Version 2.9.1
• Correction of a few bugs in CLA module and its Classes:
– Correction of a problem of material orientation in the calculation of laminate shear

properties.
– Correction of the “each_ply” iterator in Laminate Class.
• Addition of an example illustrating the out-of-plane shear calculations with CLA mod-
ules.
• It is now possible to define temperature loadings with different upper skin and lower skin
temperatures.
• Addition of moisture contribution to the loading. (Based on the same principles as the
temperature loading.)
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 calcu-
lations). The theoretical Chapter has been deeply transformed.
Version 2.9.2
• Correction of a bug in some string manipulation instructions. (The problem appeared

only for some computer architecture.)
• Modification of the methods used to manipulation temperature and moisture contribu-

tions in Load class of CLA module.
• Better support of anisotropic materials.
• Better distinction of material types when mechanical, CTE and CME characteristics are
defined.
Version 2.9.3
• Correction of a bug is Result methods "extractOnLayers" and “extractOnSubLayers”.
• Correction of a bug in “getResultCopy” method of DataBase class. (The bug occurred

when the one extracted result for a selection of entities AND on a list of layers or sub-
layers.)
• Addition of the reading of composite strength ratios in Nastran “op2” files.
• Improvement of the reading of ESAComp edf files: now laminates with repetition of
layers or symmetry are supported.
Version 2.9.4
• The “Cla::DataBase” class has been renamed “CLA::CompDb”. (This to avoid confu-
sions between the “FeResPost::DataBase” and “FeResPost::CLA::DataBase” classes.)
• Addition of CLA methods to the “DataBase” class. The methods are devoted to the
manipulation of “CompDb” class that stores materials and laminates corresponding to
finite element model stored in the DataBase object.
• Correction of a bug in the reading of ESAComp "edf" files.
• Correction of a bug in the definition of anisotropic materials in CLA module.
Version 2.9.5
• Suppression of the concept of “active” CLA::CompDb object. The corresponding meth-

ods of the CLA::CompDb class have been cancelled.
• It is now possible to insert Result objects into CLA::Load objects (“Shell Forces”, “Shell
Moments”, “Shell Strains”, “Shell Curvatures”, “Shell Temperatures”, “Shell Moistures”)..
• In relation to this modification, the methods “setT” and “setH” of the Load object have
one additional parameter specifying the type of component to consider for laminate load
response. Also the type of mechanical components “femFM” and “femSC” have been
introduced. Also, eighteen methods for finite element Results insertions have been intro-
duced in “Load” class (section II.5.6).
• Addition of two iterators in the “DataBase” class: “each_nodeOfElement” and “each_cornerNodeOfElem

An example illustrating the use of these iterators has been added.
• Addition of the “Mid” sub-layer ID. Also the correspondence between sub-layer names
and sub-layer IDs has been changed.
• Addition of the method “calcFiniteElementResponse” to the “Laminate” class. The same

method has been added to “CompDb” class too.
The modifications of the manual correspond to some of the modifications of the library. More-
over:
• In the “testSat” example, the bottom panel is modeled with surface elements and lami-
nates properties corresponding to a sandwich panel with laminated skins.
• Examples “EX15” and “EX16” have been added to the “RUBY” examples. (Example
“EX15” illustrates the production of composites Results from other finite element Re-
sults.)
Version 2.9.6
• Correction of a bug in the reading of continuation cards in Nastran Bulk Data Files.
• Support for “include” statements in Nastran Bulk Data Files. Now the Bulk Data Files
can be split in several files.
• Support for “input” statements in Samcef banque files. Here again, this allows to split
the model in several files.
over:
• Restructuration of the presentation of the ‘testSat” model, with one version with xdb
outputs, and one version with op2 outputs.
• The examples have been updated to take the modifications of “readBdf” in “DataBase”
class into account. (“include” statements.
Version 2.9.7
• Correction of a bug in the reading 1D element forces from Nastran “op2” result files.
• Correction of a bug in the reading of SPOINT elements from Nastran Bulk Data File.
• Addition of the method “getdXdbLcInfos” to the “DataBase” class.
• Addition of the methods “setFormat” and “getFormat” to the “Result” class.
• The previously deprecated method “oldGetData” has been completely deleted.
• It is now possible to read Complex Results from a Nastran xdb file. Nastran SOL107,
SOL108 and SOL111 are supported.
• Methods devoted to the manipulation of Complex Results have been defined in the “Re-
sult” class. (See section I.4.8.)
• Correction of several bugs in reading Nastran Bulk Data Files. Among other things, the
reading of free format cards has been improved.
• Results from CELASi elements can now be read from an xdb Nastran Result file.
over:
• Addition of an example illustrating the manipulation of Complex Results.
• The discussion of examples has been modified according to these different modifications.
Version 2.9.8
• Correction of a bug in the reading of binary xdb files.
• Correction of a bug in the reading of continuation fields when bulk data files are read.
• When Nastran Results are read, different load case names are attributed to Results with
no load case titles.
• The “Complex” class is no longer automatically required when FeresPost is loaded.

• Modification of classes and methods specific to the composite calculations:
– The classes “CLA::CompDb”, “CLA::Laminate”, “CLA::Material” and “CLA::Load”

have been renamed “ClaDb”, “ClaLam”, “ClaMat” and “ClaLoad” respectively.
– These new classes are defined directly in “FeResPost” module. The “FeResPost::CLA”
module has been erased.
– Several “Composite” Methods of the “DataBase” class have been renamed: “build-
ClaDb”, “getClaDbCopy”, “setClaDb” and “clearClaDb”.
Version 2.9.9
• “DataBase” class is now virtual and two specialized classes have defined: “NastranDb”
and “SamcefDb” classes. The “DataBase” class no longer can be instantiated. This is a
modification of the extension that mirrors deep restructuration of the C++ programming
of FeResPost.
• In “DataBase” class, methods “buildClaDb”, “getClaDbCopy”, “setClaDb” and “clearClaDb”

have been suppressed. Instead, a method “getClaDb” has been inserted.
• The DataBase methods “getElementsAssociatedToMaterialId” and “getElementsAssoci-

atedToPropertyId” have been deprecated.
• Addition of method “getResultSize” to the generic DataBase class.
• Correction of a bug in the reading of Des and Fac Samcef Result files.
• Reading of new Samcef Codes: 1413, 3413, *423.
• Addition of a seventh optional parameter to the “readDesFac” method in SamcefDb class.
• Four singleton methods for activating and deactivating Samcef Result Codes have been
displaced from “Post” module to “SamcefDb” class.
• Similarly, five singleton methods of the “Post” module have been displaced in “Nas-
tranDb” class as singleton methods.
• Modification of the Makefiles organization for compiling the code. The “build.bat” to be
used for compiling in Windows environment is suppressed. Now the compilation is to be
done with “make” command on windows too. (Installation on MSYS on windows might
be necessary.)
Version 2.9.10
• In “readBdf” method of “NastranDb” class, a few bugs have been corrected. (Among
other things problems around void lines, or splitting of bulk Data Files.)
• Correction of a bug in the reading of strain tensor per plies from an xdb file.
• In CLA classes and methods, the “Equivalent Strain Tensor” is renamed “Mechanical
Strain Tensor”. Correspondingly, the method “getPliesEquivStrains” is renamed “get-
PliesMechanicalStrains”.
• Addition of “calcFiniteElementCriteria” to DataBase and ClaLam classes.
Version 2.9.11
• Modification of ClaLam methods devoted to the manipulation of allowables.
• Modification of ClaMat methods devoted to the manipulation of allowables, moduli,
CTEs and CMEs.
• Addition to the ClaMat class of methods allowing to recover characteristics in specified
direction. Some of the already existing methods have been renamed.
• Possibility to retrieve absolute and relative ply temperature and moisture when laminate
load response is calculated.
• Modification of the calculation of 33 in plies with CLA module.
• Modification of “max” and “min” methods in “Post” module.
• Addition of “insertRklVals” method to the “Result” class.
• Addition of a sixth parameter in “writeGmsh” method of DataBase class. The logical
parameter is used to trigger binary or ASCII output.
• Modification of the identification of sub-cases when Samcef Results are read from “des”
and “fac” files. The new denomination is now closer to the Nastran one. Also the integer
and real values associated to Results have been modified.
• Addition several of Mecano Thermal elements support in Samcef preferences.
• Several Mecano Thermal Results can now be read.
• A few bugs have been corrected.
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
• Addition of methods “getGroupAllElements”, “getGroupAllNodes”, “getGroupAllRbes”,
‘getGroupAllCoordSys”, “getGroupAllFEM” to the DataBase class.
• Addition of method “renumberSubLayers” to the Result class.
• Modification of the reading for Shell Laminate Stresses from Nastran Results. Now the
inter-laminar stresses are better taken into account.
• Addition of method “calcFemLamProperties” to DataBase class (I.1.5).
over:
• The examples in “TESTSAT/RUBY/EX15” has been modified. A modification of coor-
dinate system of the shell Results is done to obtain them in laminate axes.
Version 3.0.0
• Addition of methods “readGroupsFromPatranSession” and “readGroupsFromSamcef-
Dat”to the “Post” module.
• Correction of a few minor bugs.
• Addition of composite failure criteria in CLA classes, or renaming of some of the existing
criteria.
• Some failure criteria imported from Samcef or Nastran finite element Results have been
renamed.
• Critical ply Results are no longer produced when Nastran layered failure indices are read
from a Nastran op2 file.
• Corrections brought to the calculation of Tsai-Wu criterion.
• Addition of several derivation methods for the “deriveDyadic” method of Result class.
Corresponding methods have been added to the “Post” Module.
• Addition of the “writeGmshMesh” method to the generic “DataBase” Class. Modifica-
tion of the corresponding example in section IV.2.5.4.
• Finalization of the separation of solvers (Nastran and Samcef).
over:
• The manual is completely restructured in such a way that the preferences for the different
supported solvers are discussed in a separate Part of the manual.
• Addition of the example “TESTSAT/RUBY/EX02/writeGroupEntities.rb” that illustrates
the reading of Groups into a Hash object.
• Addition of examples illustrating the calculation of composite failure indices from shell
forces and moments. The examples are defined for static load cases as well as dynamic
ones.
Version 3.0.1
• Correction of a bug in the reading of ILSS from ESAComp EDF files.
• Addition of new capabilities to the method “modifyRefCoordSys” in “Result” Class.
over:
• Addition of an example illustrating the “Beam Forces” and “Beam Moments” recovered
from Nastran CBAR element Results.
• Addition of an example illustrating the new capabilities of “modifyRefCoordSys” method
in DataBase Class.
• New explanation for the coordinate systems in NastranDb and SamcefDb Classes.
• More information about the peculiarities of “writeGmsh” methods in NastranDb and
SamcefDb Classes.
• Minor modification of example “EX01/readBdf”. An error message is issued if the sec-
ond “readBdf” fails.
Version 3.0.2
• Addition of methods for the activation/deactivation of reading of composite layered Re-
sults. These methods are defined in generic DataBase class (section I.1.3.2).
• Correspondingly the two methods “activateSamcefSubLayerResCodes” and “desactivate-
SamcefSubLayerResCodes” previously defined in SamcefDb class have been erased.
• Correction of a small bug in the reading of ILS failure indices from Nastran op2 Result
files.
over:
• Modification of the example in section IV.2.4.1 to illustrate the deactivation of composite
element layered results reading.
Version 3.0.3
• Correction of a bug in the reading of Nastran PBEAM properties.
• Reading of the nodal temperature results from Nastran “op2” and “xdb” result files.
• The name of sub-cases no longer include the units of time or frequencies (when applica-
ble). For example “Mode 1 (f = 2.2526 Hz)” becomes “Mode 1 (f = 2.2526)”
and “Step 12 (t = 8.6591 s)” becomes “Step 12 (t = 8.6591)”.
• Correction of a small bug in the modification of coordinate systems for Nastran Results.
over:
• Correction of an error in the description of methods in Group class “clearAllEntitiesBy-
Type” method).
• Small modification of the example devoted to the manipulation of complex Results in
sectionIV.2.4.6.
Version 3.0.4
• Removing a few “write” statements that has been added for debugging of the PBEAM
property reading.
• “readBdf” method of NastranDb class has now up to five arguments. The additional
argument corresponds to symbols that can be substituted in the file names in include
statements.
over:
• The example illustrating the reading of Nastran Bulk Data Files has been modified to
illustrate the use of symbols in include statements and the related modifications in Nas-
tranDb “readBdf” method.
Version 3.0.5
• Addition of a parameter to “readOp2” method of “NastranDb” class to allow the reading
of op2 Result files for post-processors other than Patran.
• Reading of the “BOPHIG” and "BOUGV1" result tables from op2 files.
• Reading of Nastran element energies from op2 files as well as xdb files.
he modifications of the manual correspond to some of the modifications of the library.
Version 3.0.6
• Correction of a bug in the extraction of CoordSys objects from Nastran or Samcef DataBases.
• Correction of several bugs in the manipulation of user-defined CoordSys objects.
• Modification of the method “initWith3Points” defined in “CoordSys” class. A DataBase
object must be added to the list of arguments.
• A few modification of reading of des and fac files into “SamcefDb” DataBases.
he modifications of the manual correspond to some of the modifications of the library. More-
over:
• The post-processing examples have been modified. Addition of criteria to the PostCon-
nect class and correction of one bug in the calculation of the norm of direction defining
the axis of a connection.
Version 3.0.7
• Correction of a bug in “extractResultOnLayers” method in Result class.
• A few other minor modifications.
Version 3.1.0
• Modification of CLA classes for the calculation of thermal and moisture diffusion quan-
tities.
• Addition of methods “removeLayers” and “removeSubLayers” to the “Result” class.
• Addition of methods “removeLayers” and “removeSubLayers” to the “ResKeyList” class.
• Reading of “conductive Heat Flux” and “Temperature Gradient” Results from Nastran
op2 and xdb Result files.
• Correction of a bug in the reading of Samcef Results.
• A few other minor modifications.
over:
• Addition of an example illustrating the calculation of Laminate thermal properties.
• Correction of a few minor errors in the manual.
Version 3.1.1
• Modification in the reading of beam bending moments from Samcef Results.
over:
• Addition of more explanation about sign conventions for beam force and moments ten-
sors.
• Addition of lists of methods defined in the different classes of FeResPost.
• Correction of a few minor errors in the manual.
Version 3.1.2
• Correction of a bug int the reading and manipulation of Nastran “PCOMP” property cards
with “SYM” option.
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
• Addition of method “generateShellOffsetsResult” to the SamcefDb class.
• Addition of method “extractResultOnResultKeys” to the Result class.
• Modification of method “getResultcopy” in generic DataBase class.
Version 3.1.4
• Correction of a bug in the reading of Grid Point Forces from Nastran xdb file. Class
NastranDb is modified.
• Addition of the methods “writeGroupsToPatranSession” in generic DataBase class and

Post module.
• The lists of entities to be stored in Groups can now be defined in ranges with steps: for
example “ ... firstId:lastId:step ...”.
few errors in the manual have been corrected. Moreover:
• Addition of an example illustrating the manipulation of entities stored in a Group and the
use of method “Post::writeGroupsToPatranSession” (section IV.2.2.3).
• Modification of Appendix X.A describing the installation and compilation of FeResPost.
• Modification of the introduction of the manual.
Version 3.1.5
• Correction of a few minor bugs related to error messages.
Version 3.1.6
• Addition of “getData” and “getSize” methods to “ResKeyList” class.
• Addition of attributes setters and getters to several classes.
• Modification in the, reading of BDF files. Now the reading should be more reliable for
“special cases”, even though the reverse is also possible. (If you have problems, do not
hesitate to send examples of data leading to bugs.)
Version 3.2.0
• All the attributes have been renamed. Their name starts now with an uppercase letter.
• The two methods “get_abbd” and “get_g” have been renamed “get_abbd_complMat”
and “get_g_complMat”.
• Addition of methods “eraseMaterial”, “getMaterialsNbr”,“eraseLaminate”, “getLami-

natesNbr”,“eraseLoad” and “getLoadsNbr” to the “ClaDb” class.
• Correction of several bugs in the reading of Nastran Bdf and Samcef Dat files.
• FeResPost is no longer open source.
Version 3.2.1
• The FeResPost library is now distributed as a COM component (on windows).
Version 3.2.2
• Correction of a bug in Result filtering when Nastran xdb stress Results are read.
• Correction of a bug in COM conversion of boolean arguments.
• Correction of two bugs in methods of ClaMat class returning CME properties.
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
• Correction of a bug in the division of tensorial results by real values.
• Addition of the exponentiation “**” operator to the “Result” class.
• Addition of methods “getPliesStrainsWrtLamAxes”, “getPliesStressesWrtLamAxes” and

and “getPliesMechanicalStrainsWrtLamAxes” to ClaLam class (Section II.4.7.3).
• Addition of “clearData” method to Result class.
• Modification of “insertRklVals” method in Result class. Now, the first argument can also
be a Result object.
Version 3.2.4
• The “each” iterator of ResKeyList class in ruby extension is renamed “each_key”.
• Modification of the arguments for singleton method “writeNastran” of NastranDb class
in ruby extension. The method has been renamed “writeNastranCard”. One also defines
the new method “writeNastranCards”.
• The “writeBdfLines” of NastranDb class is ruby extension has also been modified.
• Correction of bugs in some iterators on FE entities ID of the NastranDb and SamcefDb
classes. (When specified, the lower ID was not well taken into account.)
• In “SamcefDb” class, method “each_samcefMaterialId” has been renamed “each_samcefPlyId”.
This new name corresponds to what the method does.
• In COM component, the classes “Group”, “CoordSys” and “ResKeyList” are more or
less terminated. The “NastranDb” and “SamcefDb” classes are in progress.
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
• Correction of a bug in SamcefDb class of COM component: the two “readSamcefDat”
and “readDesFac” methods were permuted.
• Addition of several methods in generic DataBase class.
• Addition of several methods in “Application” class.
Version 3.2.6
• Addition of methods “getNeutralLines” and “initWithNeutralLines” in the four CLA
classes.
• Addition of several methods in Result class.
• Addition of several methods in “Application” class.
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
• Correction of a bug in the reading of Samcef BUSH element results.
• Correction of a bug in method “writeGroupsToPatranSession”. (Void Groups resulted in

erroneous session lines.)
Version 3.3.0
• Addition of methods “opAdd”, “opSub”, “opMul” and “opdiv” in the “Post” Module.
• The modification of “Float” and “Array” classes is done in a separate ruby source file and
no-longer in the compiled shared library.
• Correction of a bug in methods returning laminate stresses and strain (“ClaLam” class of
FeResPost ruby extension). The structure of Results was not as stated in the manual. The
examples have been updated according to the modification.
• The different classes in the COM component are now completely programmed, and sev-
eral bugs have been fixed.
• Addition of different methods for XDB files content investigation to the “NastranDb”
class.
• A small correction in the calculation of Tsai-Hill reserve factors: when the failure index
is negative, the RF is 1e+20.
• Addition of several methods to FE DataBase classes to investigate the content of the

model (number of elements, nodes, groups,...).
• A small modification in the parameters of the “getResultCopy” in generic DataBase class.
• The “none” keyword for merging method of “deriveByRemapping” in Result class is

replaced by “NONE”.
• Several examples using the COM component have been added. These examples have
also been used to fix several bugs.
Version 3.3.1
• Correction of a bug in the reading of XDB Results. No Results were previously read for
SOL101 analyses when the loading was purely thermo-elastic.
• Addition of units management to the different CLA classes.
• The CFAST element is now supported.
• Correction of the “sol106.bdf” data file.
• Addition of examples illustrating the manipulation of CLA classes units systems.
Version 3.3.2
• Correction of a bug in the construction of a Composite DataBase from Nastran or Samcef

Databases: now the density of materials is correctly initialized.
• Addition of several mass units in CLA ("t", "dat" and "kbm").
• Correction of a bug in method “matchWithDbEntities” of Group COM class. (There was

one “Release” too much.)
Version 3.3.3
• “Bizarre” points are skipped with a warning message when “OUG” or “OQG” blocs are
read by a “readOp2” statement.
• Modifications that should increase the robustness of reading of groups from Patran ses-
sion files.
• Addition of a “SwapEndiannes” optional argument to methods devoted to XDB files

access. This argument allows to force the swap of endiannes when reading the binary
file.
Version 3.4.0
• Addition of new layers corresponding to groups of layers in Results keys. (For extraction
operations.) Similarly, one adds one new sub-layer for extractions.
• A few modification of interpretation of element properties when elements are read into a
SamcefDb object. The modified method for reading Samcef banque files should be more
reliable.
• Correction of bugs in the conversion of Boolean variables in COM component.
• Addition of methods for XDB random access in NastranDb class.
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 illus-
trating the use of random access have been added.
Version 3.4.1
• Addition of a memory buffer to XDB attachments.
• Addition of method “writeMsgOutputLine” to “Post” Module.
• Huge memory leak problems in the COM component have been solved.
• Correction of several problems related to String conversions in COM component.
Version 3.4.2
• Correction of several bugs in the filtering on elements/nodes when Results are read on a
given Group from a Nastran XDB file.
• A few bug corrections in the conversions of arguments in COM component.
• The reading of Nastran composite layered stress Results has been modified. Values are
no longer produced in top and bottom skins of each ply.
Moreover, a post-processing project in excel using COM component is presented. (See
Chapter VII.4.)
Version 3.4.3
• Correction of a bug in the random access to XDB files. (When nodal values were read
on a Group, the first node was skipped.)
The excel post-processing project has been improved.
Version 3.4.4
• Correction of several bugs in the conversion of matrices in COM component.
• Correction of a bug in the conversion of Arrays of Boolean in COM component.
• Correction of a bug in the calculation of laminate finite element load response. (The bug
resulted in several criteria not being calculated.)
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.
Version 3.5.0
• Random access to Samcef “des” and “fac” Result files.
• Addition of one “UNDEF” layer for Result keys.
• Most methods of “NastranDb” class devoted to the manipulation of XDB attachments

have been renamed. (The “Xdb” in method name has been removed.)
• Addition of method “getAttachmentNbrSubCases” to “NastranDb” class.
• Correction of a bug in the conversion of “SamcefDb” arguments in COM component.
• Correction of several bugs related to the modification of coordinate systems for beam
Results.
Moreover:
• Correction of Samcef Contact Result names in the manual.
• Suppression of the example illustrating sequential access to Nastran XDB Results with
excel.
• Addition of an example illustrating random access to Samcef DES/FAC Results with

excel.
• Modification of the excel post-processing example to allow the post-processing of Sam-

cef Results as well as Nastran Results.
Version 3.5.1
• Correction of a bug in the writing of Nastran cards in wide format.
• Correction of a bug in the reading of Groups from Patran session files. (Now several
“ga_group_entity_add” statements can be interpreted for a single Group, or a Group can
be build by reading several session files.)
• Correction of a bug in method “deriveByRemapping” method of Result class. The

“MergeLayersKeepId” option did not keep the layer as it should.
• Correction of a bug in the writing of GMSH meshes for Nastran models.
Version 3.5.2
• Correction of several bugs in the CLA calculations (ClaLam class).
• Correction of a bug in the creation of COM component. (The creation of component was
not possible with several languages.)
Version 3.5.3
• Modification of method “getAttachmentNbrSubCases” in “NastranDb” class.

• Addition/modification of several DES/FAC “attachment” methods to the “SamcefDb”

class. (The purpose of these modifications is to defined the same methods in “NastranDb”
and “SamcefDb” class.
• Addition of several checks when results are read from Nastran XDB files (insertion of
pairs key-values for composite results in particular).
• Addition of methods “isThermalLoadingDefined”, “isMoistureLoadingDefined” and “is-
MechanicalLoadingDefined” to the “ClaLam” class.
• Correction of a bug in the management of units for Classical Laminate Analysis.
• Modification of the management of storage buffers for methods and classes provid-
ing random access to binary Result files. (Presently, Nastran XDB files and Samcef
DES/FAC files.) After the modification the, management of buffers is common to the dif-
ferent result attachments. The maximum capacity for storage buffers is managed by sin-
gleton methods “setStorageBufferMaxCapacity” and “getStorageBufferMaxCapacity” of
the generic “DataBase” Class. The corresponding methods of “NastranDb” and “Sam-
cefDb” classes have been deleted.
• Correction of a bug in the reading of Nastran SOL107 Results from XDB files.
• Correction of a bug in the simplification of include paths when Nastran BDF files are read
with “readBdf” method of “NastranDb” class. The same correction has been done for the
reading of Samcef Bacon files with “readSamcefDat” method of “SamcefDb” class.
Moreover:
• In examples “RUBY/EX13”, modification of the source file “extendedCLA.rb” to illus-
trate the use of new “ClaLam” class methods. The manual is modified accordingly.
Version 3.5.4
• Correction of a bug in the storage buffer for Result reading. (Previously, the actual size
of buffer was 16 times the size specified by the call of “setStorageBufferMaxCapacity”.)
• Correction of a bug in the reading of Samcef contact result codes 1305, 1306 and 1307
from FAC result files.
• Correction of a bug in the reading of abbreviations from Samcef "dat" files.
he modifications of the manual correspond to some of the modifications of the library and a
Moreover:
• In examples “RUBY/EX13”, modification of the source file “extendedCLA.rb” to illus-
trate the use of new “ClaLam” class methods. The manual is modified accordingly.
Version 3.5.5
• Correction of small bugs in the random access to Nastran XDB result files.
• Improvement of the reading of ESAComp files. Now version 4 files are supported as well
as those of version 3.4.
Moreover:
• Addition of installation instructions to the distributed ruby extensions and COM compo-
nents.
• Modification and documentation of the COM excel examples.
Version 3.5.6
• Correction of a bug in the extraction of Result eigen-values. Previously, the extraction
algorithm sometimes failed when two eigen-values were very close to each other.
• Correction of a bug in the reading of Nastran BDF files. The rules for including sub-files
have changed.
• More explanation is given about the rules applied by FeResPost to include sub-files when
Nastran BDF files are imported into a DataBase.
• Some tidying up of the manual (among other things in the list of versions and changes).
• Addition of the example “RUBY/EX01/readBdf_V3.rb” to test new versions of file in-
cludes statement in BDF read with “readBdf” of “NastranDb” class.
Version 3.5.7
• Correction of a bug in the reading of result code 221 (reaction forces and moments) from
Samcef Mecano des/fac files.
• Additional information on the Hash object returned by “getAttachmentResults” and “getAt-
tachmentResultsCombili” in NastranDb and SamcefDb classes.
• New example “RUBY/EX19/attachedXdbExtract.rb” illustrating the extraction of Re-
sults from XDB attachments.
Version 3.5.8
• Correction of several bugs here and there. Most of these bugs are related to segmentation
faults that appear when using the Microsoft Visual C++ compiler.
• Correction of several bugs in the reading of Nastran CBEAM element forces, stresses
and strains from XDB result files.
• Correction of a bug in Nastran XDB files reading. Now, results produced with SORT2
Nastran output can be read as well as those produced with SORT1 option.
• Addition of flag “DES_FAC_DEBUG” to SamcefDb class to allow the debugging of

Des/Fac Result files access.
• Modification in the reading of Samcef Des files: lines containing NULL characters are
now accepted by FeResPost. (Note that we consider this as a bug in Samcef, as it is very
nasty to add NULL characters in a file that is supposed to be formatted.)
• Additional information on the reading of composite stresses from Nastran op2 or xdb
result files. (In particular about the out-of-plane shear stress components.)
• The example described in section VII.2 (Classical Laminate Analysis with Excel) is
slightly modified: for spreadsheets calculating laminate load response in which load-
ing is directly defined in the spreadsheet, loading units are now the same as the laminate
ones. (Loading is no longer defined with default units.)
In “calcLamLoadResponse” module, methods “calcLamOopShearForces” and “calcLam-
OopShearStrains” have been added. Spreadhseets “LamLoadResponse_A” and “Lam-
LoadResponse_B” have been modified to use the new methods.
Version 3.5.9
• Correction of several bugs in COM conversions, and iterators.
• Addition of a second version of Yamada-Sun criterion (more adapted to the justification

of fabrics).
• The Laminate Analysis example with Excel has been updated. (Several bugs were fixed
in thee excel VBA.)
Version 4.0.0
• FeResPost is now also distributed as a .NET assembly.
• In CLA classes, the “Id” attribute is no longer accessible by methods “setId” and “getId”.
Instead, the corresponding attributes (ruby) or properties (COM and .NET) have to be
used.
• In all classes, the “Name” attribute is no longer accessible by methods “setName” and
“getName”. Instead, the corresponding attributes (ruby) or properties (COM and .NET)
have to be used.
• In class ClaMat, the material type can no longer be accessed by “setType”, “getType”
and “getTypeName” methods. Instead, the corresponding attributes (ruby) or properties
(COM and .NET) have to be used.
• In “Result” class, several “set” or “get” methods have become attributes. These methods
correspond to “Name”, “TensorOrder”, “Format” and “Size” attributes. (Note that the
“size” attribute or property has been renamed “Size”.)
• Similarly, The “Size” and “Name” attributes of “ResKeyList” class have been modified.
Note that the “size” attribute or property has been renamed “Size”.)
• in “ClaLam” class, the methods returning load results by ply have been modified: the
returned values have a different format.
• In “ClaLam” class of COM component, the methods “getMaxDerived”, “getMinDerived”,
“getMaxFailureIndices”, “getMinFailureIndices”, “getMaxReserveFactors” and “getMin-
ReserveFactors” returns 2 dimensional Arrays of sizes N*3.
• Parts VIII and IX corresponding to the .NET assembly have been added.
• ...
Version 4.0.1
• Methods “setVerbosityLevel” and “getVerbosityLevel” have been added to “Post” Mod-
ule.
• Methods “convertIdfierToString” and “convertStringToIdfier” have been added to “Post”
Module.
• Correction of several small bugs in the .NET assembly, and in the reading of Nastran
BDF cards in free format.
• Correction in the “PostProject.xls” COM example: there was a problem in the extraction
of connection loads.
• The COM examples with Excel have been modified to allow debugging by setting the
value of a “verbosityLevel” variable.
• ...
Version 4.0.2
• Correction in method “convertStringToIdfier” of “Post” Module.
• Correction of method “getOOPSStiffness” in “ClaMat” Class.
• Correction of a small bug in the reading of RBE3 MPC elements from Nastran BDF files.
• Several memory leaks have been quenched.
• Minor corrections in the manual and in the examples.
• ...
Version 4.0.3
• Several minor bugs have been fixed (memory leaks).
• A few modifications in the construction of Groups to avoid a too large use of RAM.
• Several corrections in the “PostProject.xls” example to reduce the use of computer mem-
ory.
• ...
Version 4.0.4
• Correction of a several memory leaks that occurred when exceptions were thrown. (Clean-
ing of temporary variables when exceptions were thrown.)
• Addition of methods in “Group” and “Result” classes that allow the conversions between
these objects and SQL BLOBs.
• In .NET assembly, the assignment operators (operator=) of the FeResPost classes, have
been removed.
• In .NET assembly, definition of “finalizer” methods in FeResPost classes. (Huge memory

leaks!)
• in COM component: correction of an error in vector<result*> conversion.
• ...
• Addition of examples illustrating the manipulation of FeResPost BLOBs with SQLite.
• FeResPost is again distributed under the terms of the general public license.
Version 4.0.5
• Correction of a bug in blob conversion of Results. (Conversion failed when “void” Re-
sults were considered.)
• A few modifications in the output of Results in GMSH files. Now the Results should be
output without problem even when some of the keys do not match finite element entities
(nodes or elements) defined database.
• Modification of the post-processing with excel project. It is now possible to save an

SQLite3 database that can be used a posteriori to build envelopes of Results to be saved
in GMSH files.
Version 4.0.6
• Correction of a bug in “addResult” of generic DataBase class. (A huge memory leak.)
• Correction of a bug in the random access to XDB results. (Previously latest key-value
pairs in data blocks were sometimes “forgotten”.)
• Correction of bug in “attachDesFac” method of “SamcefDb” class. (In some cases, the
method failed and FeResPost crashed.)
Modification of the manual and examples:
• Modification of the post-processing with excel project. The method “getCurrentDb”

of “DbAndLoadCases” Module has been modified to ensure that the last DataBase is
returned.
• Also in post-processing with excel example, the Module “ResultsGmsh” has been mod-
ified in such a way that the post-processing also works when SQLite is not available, or
installed in a different location.
• Addition of a spreadsheet for manipulation of Groups in examples “PostXdbRandom.xls”

and “PostDesFacRandom” examples.
Version 4.0.7
• Correction of a bug in XDB files random access. Now the access to files alarger than 1
Tb should work. (Previously the limit was approximately 2 Gb.)
• Correction of a bug in Nastran FAC files random access. Now the access to files alarger
than 1 Tb should work. (Previously the limit was approximately 2 Gb.)
• The “activate” and “desactivate” methods have been renamed “enable” and “disable”.
• Examples have been modified to correspond to the new “enable” and “disable” methods
Version 4.0.8
• The COM component is now also distributed as an out-of-proc (EXE) server.

Version 4.0.9
• Correction of a bug in the reading of CSHEAR element stresses from op2 files. (The
“elemId” field of result keys was not initialized.)
• Reading of CONROD and CSHEAR results from xdb files.
• COM component is provided with a Proxy/stub dll.
Version 4.0.10
• Attribution of a default load case name when Results are read from Nastran OP2 or
XDB files and no SUBTITLE has been defined in the corresponding Nastran SUBCASE
definition.
• Special care has been taken to correctly identify the version of .NET assembly.
• Update of the manual according to the modifications of the library.
• Update of information on the component registration.
Version 4.0.11
• Addition of the “FromTo” parameters “MergeSubLayers” and “MergeSubLayersKeepId”

for the method “deriveByRemapping” of “Result” class.
• Modification of “getData” methods of “Result” and “ResKeyList” classes in such a way

that they return coherent default “string” or “int” values. (Coherence between the two
classes, but also between the ruby extension, COM component and .NET assembly.)
• Addition of the methods “getElementType”, “getElementTypeName”, “getElementDim”,

“getElementNbrNodes”, “getElementNbrCornerNodes” to the generic DataBase class.
• Addition of the method “getElementPropertyId” to the NastranDb class.
• Distribution of a “vbaruby” bridge for the embedding of ruby in MS-Office programs,

and the dispatch of VBA calls to ruby interpreter. (See X.E.)
• A few improvements in the “writeBdfLines” method of “NastranDb” class.

• Modification of the example “RUBY/EX16/elemConnectivity.rb”.
• Elimination of “ResultsEnveloper” module from “COMEX/EX10/PostProject.xls” ex-

ample.
• Addition of an example illustrating the use of vbaruby bridge to call ruby post-processing
programs from excel. (See Appendix X.E.)
Version 4.0.12
• Addition of methods allowing to access the characteristics of nodes in NastranDb and

SamcefDb classes. (Access to coordinates, ACID or RCID.)
• Addition of methods “checkAbbreviationExists”, “checkCoordSysExists”, “checkEle-

mentExists”, “checkNodeExists” and “checkRbeExists” in the generic “DataBase” class.
• In the “CoordSys” class, addition of methods allowing the transformation of point coor-
dinates, or vectors and tensors components.
• Description of the new methods have been added in the user manual.
• Addition of an example illustrating the transformation of point coordinates and vector or

tensor components in the “CoordSys” class. (See section IV.2.4.5.)
Version 4.1.0
• A few very minor modifications of the source code.
• For the ruby extensions and COM component, the ruby and COM “wrappers” are now
separated from the FeResPost C++ “core” library.
• The information about installation, configuration and compilation of FeResPost and as-
sociated libraries has been gathered in Appendix X.A. A careful reading of this Appendix
is recommended because the modifications of binaries organization influences the way
they must be installed.
Version 4.1.1
• A few very minor modifications of the source code.
• Correction of a bug in the .NET iterators. (The first element of each collection was
missing.)
• Four attributes (properties) added to the “Group” class: “NbrElement”, “NbrNodes”,

“NbrMpcs” and “NbrCoordsys”.
• Modification of examples to illustrate the use of the new Group attributes.
• Modification of the “VBARUBY” bridge and corresponding example. The new version
should work better with the 1.9.* versions of ruby.
Version 4.1.2
• Correction of a bug in “getNodeRcId”, “getNodeAcId” and “getNodeCoords” methods

of the “NastranDb” class. (The return values always corresponded to the first call to the
method.)
Version 4.1.3
• Addition of several error messages, and more tests for error detection.
• Correction of a few minor bugs.
• Addition of methods “getElementNodes” and “getElementCornerNodes” to the generic

“DataBase” class.
• The new ruby extensions and COM component are now statically linked to the FeResPost
object. The use of a shared library containing all FeResPost C++ classes is no longer
necessary. Static linking is recommended for your own programs/extensions.
Version 4.1.4

• Better separation of the different Nastran and Samcef specific classes from the “common”
classes. (This is internal stuff related to the programming of coordSys classes, but should
be of no consequence for the library users.)
• The COM and .NET iterators have also been re-organized. (Here again, the modifications
should be of no consequence for the library user.)
Version 4.1.5
• Correction of a bug in the reading of Nastran BDF files.
• Correction of a bug in the reading of Nastran XDB files.
• Addition of four methods for the reading of Nastran SOL200 results (experimental). The
four methods are “getAttachmentDesVarHistory”, “getAttachmentConstrDefinitions”, “getAt-
tachmentConstrHistory” and “getAttachmentObjectiveHistory”.
Version 4.1.6
• Small correction in Samcef and Nastran dataBase headers that prevented the compilation
with GCC versions 4.6.*.
• Correction of a bug in the reading of the history of constraints from Nastran SOL200
XDB results.
• Addition of method “getAttachmentDesRespHistory” to NastranDb class.
• Correction of a bug in the reading of Nastran BDF files, or Samcef DAT files. (too long
lines stalled the program before correction.)
Version 4.1.7
• Correction of a bug in the calculation of mechanical strain tensor in laminates: previously
(until version 4.1.6), the “total” or “actual” strain tensor were returned at bottom layer of
the plies.
• Distinction between strain tensor criteria calculated with mechanical and total strain ten-
sor components respectively. The default strain criteria are now using the mechanical
strain tensor. (Previously, only the total strain tensor was used. It is still possible to use
it with the “Total” version of each strain criterion.)
• Correction of many typographical errors in FeResPost User Manual.

Version 4.1.8
• Correction of bugs in the reading of Nastran PBEAM properties.
• Some cleaning of the code.
• A few modifications in user manual.
Version 4.1.9
• Correction of a bug in the reading of the CBAR element stresses and strains.
• Correction of several bugs in the reading of Nastran BDF files (reading of CORD1R,
CORD1C, CORD1S, RBE1 and PSHELL cards).
Version 4.2.0
• Correction of a bug in the reading of the PBEAM properties from BDF files.
• Correction of a bug in the PCOMP properties with symmetric laminates.
• Addition of the support for 64bits XDB result files.
• The “PostPproject.xls” example has been optimized. (Post-processing with COM com-
ponent and excel.)
• A few modifications in User Manual.
Version 4.2.1
• Correction of a several bugs in the XDB access:
– Problems related to the identification of load cases.

– Problems related to the reading of very large XDB files (size>2Gb).
Version 4.2.2
• Addition of four singleton methods to the Result class for the conversion of layer and
sub-layer string and integer IDs.
• Correction of a bug in the reading of BDF files: some real values were not recognized.
• Modification of the acceptable COM arguments for conversion to “vector3”. Now, one
accepts two-dimensional arrays 1*3 or 3*1. (Previously, only one-dimensional arrays
were accepted.)
• Modification of the “PostXdbRandom.xls” and “PostDesFacRandom.xls” workbooks that

now allow to extract Results expressed in projected coordinate systems, and/or to select
the layers for which values are extracted.
Version 4.2.3
• For Nastran Results, one now makes the difference between (linear) Stress and Strain
tensors, and the “Nonlinear” corresponding results. Nonlinear stress and strain Results
are read for CHEXA, CPENTA, CTETRA, CQUAD4 and CTRIA3 elements.
• Modification of the Results for Nastran CGAP elements.
• Correction of a bug in the reading of design variables history for Nastran SOL 200 output.
• Correction of a bug in the “writeGmsh” method in generic “DataBase” class:
– Previously only one value was printed per element/node was printed when several
were present in the output Results. This may have been a problem when multi-
layered Results were output.
– Now an error message is issued when this kind of problem is detected and FeRes-
Post throws an exception. (This error message is influenced by verbosity level.)
The responsibility of producing mono-layered Results for GMSH output is the user’s
responsibility.
• Correction of a bug in the reading of surface element forces, strain or stresses from XDB
files. (Results at element corners were sometimes wrong.)
• Correction of a bug in the reading of shell element complex strain and curvature Results
from Nastran XDB files. (Generally, the curvatures were not correctly interpreted.)
• CQUADR and CTRIAR element Results can now be read from XDB files.
• Correction of a bug in “scanBdf” method of NastranDb class: comments in BDF lines

are better taken into account.
• Addition of “MergeAll” accepted value for “FromTo” parameter of “deriveByRemap-

ping” in Result class.
• Singleton methods “enableNasResElems” and “disableNasResElems” have been renamed

“enableOp2ResElems” and “disableOp2ResElems” respectively.
• Addition of singleton methods “enableXdbTables” and “disableXdbTables” to the Nas-

tranDb class to allow a better filtering of XDB tables reading.
• Addition of the three “getBulkCardsEnableInfos”, “getOp2ResElemsEnableInfos” and

“getXdbTablesEnableInfos” singleton methods in NastranDb class.
• The description of Results read from Nastran OP2 and XDB result files has been updated
(in particular, the reading of non-linear analysis Results from SOL 106, 129 and 400
analyses.
• “printXdbDictionnary” method has been added to NastranDb class.
• Modification of nil argument conversions in Strings or Arrays, Hashes: the conversion

results in a void String, or Array or Hash.
Version 4.2.4
The new version of the library is issued 2014/01/04:
• The reading of Nastran 32 bits and 64 bits OP2 files is now possible.
The examples are also modified:
• The post-processing project in excel has been updated. A button has been added to the
“LcSelector” spreadsheet to help the debugging of data.
Version 4.2.5
• Correction of several memory segmentation bugs related to the replacement of several

“strncpy” by “memcpy” in issue 4.2.4 of the library.
• Addition of “initToZero” method to the “Result” class.
Version 4.2.6
• Correction of two bugs in the “checkGroupExists” and “checkAbbreviationExists” meth-

ods of the generic DataBase class in ruby extension.
• For the reading of Nastran BDF files, the “rfinclude” and “rfalter” include statements are
now taken into account. Note however than in FeResPost, these statements are considered
to be strictly equivalent to the usual “include” statement.
• Correction of a bug in the identification of included files in the “include” statements of

“readBdf” method.
• Modification of “min” and “max” derivations in “deriveDyadic” method of the Result

class. Now, the dyadic derivation can be done for vectorial or tensorial Results. (See
section I.4.4.)
• Correction of a bug in the modification of coordinate systems wrt which the components
of tensors or vectors are expressed. (The THETA parameter used in the definition of
material orientation was not always taken into account.)
• Addition of BBBT accessor to XDB files. Previously, only the HK access was supported.
Note However that the reading of Grid Point Forces fails and throws an exception if
several sub-cases are defined in a load case (SOL103, sol105, SOL106...).
Version 4.2.7
• Correction of a bug in the reading of Nastran BDF files: the “include” statements on
several lines before “BEGIN BULK” statement are now processed correctly (hopefully
without bug).
• Correction of several bugs in the conversion of COM Arrays. (Segmentation faults pos-
sible when exceptions were thrown.)
• Addition of “writeNastranCardToVectStr” method to “NastranDb” class.
• Addition of methods “getMpcNodes”, “getMpcDependentNodes” and “getMpcIndepen-

dentNodes” to “NastranDb” class.
• Correction of a bug in “writeGmsh” method of “DataBase” class. Problems occurred

when void Strings were associated to Result, Mesh or Skeleton outputs.
• Correction of a small bug in “scanBdf” method of “NastranDb” class. (Management of

the include directories.)
• Correction of the Python examples with COM component.
A few corrections in the User Manual.

Version 4.2.8
• Correction of a major bug in the reading of Nastran BDF files: the “include” statements
should work better now. (The “corrections” in version 4.2.7 were actually catastrophic.)
Version 4.2.9
• Correction of a bug in the Nastran CoordSys class. (The building of CORD1R, CORD1C
or CORD1S wrt 0 failed when the nodes defining the object were defined wrt 0.)
• Correction of a bug in the reading of stresses or strains from XDB files at corners of solid
elements.
• Addition of method “fillcard” to the NastranDb class. (See section III.1.1.4.)
Version 4.3.0
• Correction of a bug in the conversion of Nastran MAT8 material to ClaMat object. (The
“STRN” parameter was not taken into account.)
• the “LaminateAnalysis.xls” example using COM component has been slightly improved.
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.F for more information.)
Version 4.3.1
• Addition of an example with ruby extension illustrating the access to optimization results
(RUBY/EX21). The manual is modified accordingly (section IV.2.7).
• In “NastranDb” class, the “writeNastranCard”, “writeNastranCards” and “writeNastran-
CardToVectStr” have been modified. The “cardName” String argument has become op-
tional. The User Manual and corresponding examples have been adapted.
• Addition of several “raw XDB access” methods to the “NastranDb” class. The methods
are described in section III.1.1.9 and illustrated by examples in section IV.2.8.
Version 4.3.2
• Correction in the reading of shell element stresses at mid-thickness. The stresses are
associated to “NONE” layer, and no longer to “Z0”. (This has been done to ensure
coherence with other shell results reading. User manual is updated accordingly.
• The reading of Nastran XDB result files produced with option “DBCFACT=4” has been
nearly completely re-programmed. It seems that all the results that can be read with
“DBCFACT=0” can also be read with “DBCFACT=4”.
• Correction of a major bug in the “modifyRefCoordSys” method of “Result” class. (The
modifications from spherical, or to spherical coordinate systems were completely erro-
neous before version 4.3.2.)
Version 4.3.3
• Correction of a few minor bugs:
– FIXED: in GMSH output, no output was produced when one or several Result keys
failed.
– FIXED: program crashed when operands were of wrong type.
– FIXED: wrong error message in Result extract operation.
– Small optimization of XDB files indexed with hash keys.
• Addition of a “BulkOnly” Logical parameter to the “readBdf” method in “NastranDb”
class.
• Addition of method “writeNastranCardsToVectStr” to the “NastranDb” class.
• Addition of methods “insertCard” and “insertCards” to the “NastranDb” class. (These
methods allow to modify the model defined in the “NastranDb” object.)
• Addition of “atan2” dyadic function in the “Post” Module.
• The “Post.pow” method now also allows a Float as first argument.
• The “Post.vectProduct” method allows vectors (Arrays of three Float) as first or second
argument. Note also that the “vectProduct” operation in ”deriveDyadic” method of “Re-
sult” class has also been modified and also allows an Array of three real values as second
argument.
• Addition of the “setComponent” method to the ‘Result” class.
• Some of the “xdb” methods in NastranDb class have been transformed in ruby singleton
method, or in .NET static methods. (It does not change the bahaviour of COM compo-
nent.)
• Addition of the special node IDs “CbarGrdA” et “CbarGrdB” to allow the reading of
moments and stresses in CBAR elements that are not defined in the dataBase. (See
Table III.1.2.)
A few corrections in the examples, and in the user manual.
Version 4.3.4
• Correction of a bug in “getNodeCoords” in “NastranDb” class. Now the coordinates wrt
coordinate system 0 can be obtained.
• Correction of a bug in “Post.cmp” method.
• Correction of a bug in the writing of GMSH “mesh” files.
• Addition of support for the unisgned int and unsigned long int in NastranDb raw accessor
to XDB tables (“u” and “U” conversions).
Some modifications on the manual and the distributed binaries:
• Modifications that correspond to the modifications of FeResPost libraries.
• The procedure for building the binaries from sources have been cleaned somewhat, and
should be easier to adapt and use for anyone.
• The number of available binaries has been increased. (More versions of Ruby are now
supported, in 32bits or 64bits. The .NET CLR versions 2 and 4 are supported.)
Version 4.3.5
• Correction of bugs in the XDB raw iterator. (The unsigned int conversion was missing in
COM component and .NET assembly.)
• Correction of a bug in the “writeGroupsToPatranSessionFile” in the COM Application
object. (Sometimes, the “Groups” argument was not well converted.)
• Correction of a bug in the calculation of CLA finite element load response. (The thermo-
elastic and hygro-elastic contributions were not correct.)
• Relaxation for the syntactic rules in BDF files read with “readBdf” method of NastranDb
class. Integers are now accepted as real values when no ambiguity is possible.
• A few corrections in the manuals.
• Binaries for the versions 2.3.* of ruby are also distributed.
• Addition of examples showing how the temperature distributions applied for thermo-
elastic loading of Nastran models can be retrieved and used for the calculation of laminate
load response. (See sections IV.2.8.5 and VII.4.4.3.)
Version 4.3.6
• Correction of several methods with variable number of arguments:
– Method “setComponent” in “Result” class.
– Methods “getAttachmentNbrSubCases” and “getNodeCoords” in “NastranDb” class.
– Methods “getAttachmentNbrSubCases”, “generateShellOffsetsResult” and “getN-
odeCoords” in “SamcefDb” class.
• Correction of a bug in the “insert” method of “Result” class. (The “NONE” element ID
of key was not accepted.)
• Correction of arguments in methods “removeLayers” and “removeSubLayers” of “Re-
sult” class in .NET assembly.
• Correction of arguments in methods “removeLayers”, “removeSubLayers” and “extrac-
tResultOnEntities” of “Result” class in COM component.
• In COM component: correction of a bug in the “writeBdfLines” singleton method of
“NastranDb” class.
• Correction of a bug in the extraction of corner nodes in Nastran scalar elements “CMASS1”,
“CMASS2”, “CDAMP1”, “CDAMP2”, “CELAS1” and “CELAS2”. (This bug affected
several other methods as “writeGmshMesh”.
• The limit on lines length when Nastran BDF or Samcef DAT files are read has been
elmininated.
• Correction of a bug in the “Result” class modification of reference coordinate systems.
(Previously, transformation was erroneous when curvilinear coordinate systems were
used in the orientation of material properties in shell elements.)
• Introduction of the “Ilss_b” version of the composite inter-laminar shear stress failure
criterion in CLA classes. (See section II.1.10.25.)
• Addition of method “containsEntity” to the “Group” class.
• In the description of generic “DataBase” class in User Manual, methods “getNbrCo-
ordSys”, “getNbrElements”, “getNbrNodes”, “getNbrAbbreviations” and‘getNbrGroups”
are now presented as they are: as attributes “NbrCoordSys”, “NbrElements”, “NbrN-
odes”, “NbrAbbreviations” and “NbrGroups”.
• A few “cosmetic improvement of the manuals (addition of internal links).
• COM component installation program “registrySetup.exe” has been renamed “modi-
fyRegister.exe”. (This has been done to “dodge” Windows 10 User Access Control that
does not like executables containing the word “setup”.)
• Elimination of dirty spurious “QueryInterface” error messages from the COM compo-
nent.
Version 4.3.7
• Correction of a bug in “setComponent” methods of “Result” class when two parameters

are passed to the method. (One bug for all extensions, and another bug for the COM
component only.)
• Correction of a bug in the XDB reading/attachment, when anonymous load cases are
present in the XDB file (SUBCASES with no SUBTITLE).
• In Ruby extension, correction of a bug in “modifyRefCoordSys” method of “Result”

class. (The method returned “Self” instead of nil.)
• Correction of a bug in the XDB access with BBBT index (option DBCFACT=4). (It
seems that no index is produced when the table is stored in a single page.)
• Improvement of the test for big/little endianness of XDB files. A warning message is
issued in case of “doubt”. The manual is modified accordingly (section III.1.1.8).
• Correction of a bug in the extraction of nodes in Nastran scalar elements “CMASS1”,

“CMASS2”, “CDAMP1”, “CDAMP2”, “CELAS1” and “CELAS2”. (This bug affected
several other methods as “writeGmsh”.
• Addition of method “calcRandomResponse” in the “Post” module.
• Addition of method “deriveScalPerComponent” in the “Result” class.
• Addition of “VonMises2D” derivation method for the “deriveTensorToOneScal” method.
• Addition of method “deriveVectorToTensor” to the “Result” class.
• A sixth optional argument has been added to the “calcResultingFM” class method in
“Result” class. This argument allows to provide the list of coordinates used for the calcu-
lation of global moment. This can be handy when the forces are not associated to nodes.
(Element forces extracted from CBUSH elements, for example.)
Version 4.3.8
• Correction of a bug in “deriveVectorToTensor” method of “Result” class.
• Correction of a small error in User Manual (description of the “calcRandomResponse”

method in “Post” module.)
• Addition of information in Appendix X.A devoted on installation instructions. (Discus-

sion of execution environment, of installations of both 32 bits and 64 bits versions of the
COM component, on GNU C++ re-distributable libraries.)
• Correction of a bug in the Result modification of reference coordinate system when one
of the system is curvilinear and the result values are associated to element center. (Error
was related to the fact that the location of element center is obtained by averaging the
nodal coordinates in a curvilinear CS instead of a cartesian one.) Errors with previous
versions were very small in most cases.
• Correction of a bug in method “calcResultingFM” of the Result class. In some cases,
results were erroneous when curvilinear coordinate systems were used in the calculations.
• Improvement of the “modifyRefCoordSys” in Result class. New version should be faster
when several modifications are done on results related to the same FEM entities. In some
cases, the time saving can be very significant.
• Improvement of the different operators in the “Result” class. Among other things, a
better support for calculations with complex numbers is provided.
• The “Post.vectProduct” method also supports calculations with complex numbers.
Version 4.3.9
• Correction of a bug in the reading of Nastran “PBEAML” property cards. (Method
“readBdf”in “NastranDb” class.)
• Correction of a bug in the reading of Nastran BDF files. Comment lines inside Nastran
Cards were causing problems. (Method “readBdf” in “NastranDb” class.)
• Minimum support for the “CORD3G” Nastran card.
• Correction of a bug in a few dyadic operators in Result class. (Bad initialization of cId
in some cases.)
• Modification of the “operator” methods in ruby “Post” module (COM component “Ap-
plication” class). Now, the new methods cover the corresponding operators and dyadic
functions in “Result”, “Group” and “ResKeyList” classes. (See section I.6.4 for more
information)
• Improvement of “generateCoordResults” method in DataBase class. Now, error mes-
sages are printed when missing nodes are detected, but no exception is thrown.
• A few optimizations of the code. In particular, the composite Result calculations have
been significantly accelerated. (See section II.1.9 for a detailed explanation.)
• Method “reInitAllPliesAccelMatrices” added to the “ClaLam” and “ClaDb” classes. (This
modification is related to the acceleration of composite calculations.)
• Correction of a few bugs in the conversion of array arguments of COM component.
• Addition of a ninth parameter to “calcFiniteElementResponse” and “calcFiniteElementResponse”
methods.
Version 4.3.10
• Modification of “calcFiniteElementResponse” method. ILSS criteria are always calcu-
lated at bottom ply if requested, even if no output request at bottom sub-layers.
• Introduction of the concept of “Strength Ratio” in classical laminate analysis (sections II.1.10
and II.4.7.5).
• A few corrections in “calcRandomResponse” method of “Post” Module. The User Man-
ual has been corrected too.
• Addition of method “calcPredefinedCriterion” in “Post” Module in order to accelerate
computations (optimization of post-processing operations).
Version 4.4.0
• Correction of a bug in the Result class “multi iterator”. This correction should fix the
problem in “SGI_SR” predefined criterion.
• In COM component: correction of a bug in the conversion of complex vector to variant.
• Correction for the reading from XDB files of complex stresses in CBEAM elements (MP
format).
• In “DataBase” class of the component, the “NbrAbbreviations”, “NbrGroups”, “NbrCo-
ordSys”, “NbrElements”, “NbrNodes”“get*” methods are replaced by property “getters”.
• Several bug fixes.
• The most significant innovation is that FeResPost is also distributed as a Python library.
Version 4.4.1
• Modification of the “WriteGmsh” method in “DataBase” class. A check of the Result
values is done and infinite of NaN values are substituted with MAXFLOAT and MIN-
FLOAT respectively.
• Correction of string conversion in PYTHON version > 3. C/C++ strings are now con-
verted to Unicode strings, and no longer to bytes.
• The problems related to the different operators in the Python extension “Result” class
have been fixed. It is now possible to use the “+”, “*”, “*”, “/” and “**” operators.
The corresponding “opAdd”, “opSub”, “opMul”, “opDiv”, “opPow” methods have been
removed. (This means you will have to modify your Python scripts if you have used these
methods.)
• Correction of the “extractLayers” and “extractSubLayers” methods in “Result” class.

The methods return the “NONE” layers or cub-layers, and corrections are done in COM
component and .NET assembly.
Version 4.4.2
• In ruby extension, addition of a “coerce” method in the “Result” class for the manage-
ment of operators with “Result” object as second argument. (See section I.7.) The stan-
dard classes are no longer modified by “modifStdClasses.rb”.
• Addition of “opPow” method in “Post” Module.
• In the .NET assembly, for compatibility with other FeResPost libraries, one has defined
the “opAdd”, “opSub”, “opMul”, “opDiv” and “opPow” methods in the “Post” Module.
• Correction of a bug in the reading of Results from XDB files produced with option “DBC-
FACT=4” (BBBT accessor). The reading failed when the table fitted a single page (output
of a small amount of data).
• Correction of a bug in method “deriveTensorToThreeScals” of “Result” class.
• Addition of method “eigenQR” to “Result” class.
• In Windows binaries, python extensions are now compiled with GNU compiler.
Version 4.4.3
• Correction of a bug in the “insertLaminate” of the “ClaDb” class. The method no longer
returns an exception when laminate properties calculation fails.
• Correction of a bug in the reading of text files on UNIX and LINUX systems. The DOS
“end-of-line characters” were not well supported. This bug fix concerns the reading of
Nastran BDF files, Samcef DAT files, composite databases from EDF or NDF files and
groups from Patran session files.
• correction of a bug in the generation of GMSH “skeletons”. (Segmentation fault occured

if one node used in element definition was missing.)
• Modification of “LaminateAnalysis.xls” example. Now the material and laminate ther-

mal and moisture properties are also calculated in the corresponding spreadsheets. Also,
one improved the calculation of minimum or maximum composite criteria.
• A few corrections in the User Manual. For example, some remarks have been added to
the description of CBUSH element forces and moments read from Nastran results.
• Addition of a few checks on “NULL” arguments for “claDb” and "ClaLoad" arguments.
• Correction of a major bug in Python complement. (The bug prevented numerical opera-
tions of Result class objects with other type’s arguments.) This bug concerns the version
2.* of Python.
• Several other bugs have been fixed in the Python complement.
• Addition of an object oriented post-processing in the Python examples (section V.1.4).
• Several errors have been correction in the Python examples.
Version 4.4.4
• Correction of a bug in reading of CBUSH element complex stresses from XDB file.
• Addition of method “importAttachmentResults” in “NastranDb” class.
• Renaming the complex nodal Results read from XDB. The (RI) or (MP) is now at the
end of Result name, and no longer at the beginning. Examples and manual are updated
accordingly.
• Correction of a bug in the “deriveScalToScal” method in “Result” class. (The method

was completely wrong when applied to complex results.)
• Correction of a bug in “deriveVectorToScal” method in “Result” class. The format of

Result object is always set to Real for “abs” and “sq” derivation, even if the argument is
a Complex vectorial Result.
• Correction of a bug in the “max” and “min” dyadic derivation methods of “Result” class.
Results were not correction when keys belonged to only one of the Results, and when the
Results were tensorial or vectorial.
• Modification of the “compare” method behaviour for “deriveDyadic” in “Result” class.

Now the method can also be used with vectorial or tensorial Results. Then, the compari-
son is done on a component-per-component basis.
• Modification of the “writeGmsh” method in generic “DataBase” class. The method now
also accepts the “Elements” as output location for the Results.
• Correction of a bug in the “writeGmsh” method in generic “DataBase” class. The func-
tion should no longer crash when one attempts to output empty or nil Results in GMSH
files.
• Correction of a bug in the reading of composite stresses/strains from Nastran XDB and
OP2 files. When inter-laminar results are read, a rotation of the shear components is
now done to obtain results in ply axes. (Nastran produces inter-laminar shear results in
laminate axes.)
• Correction of a bug in the reading of Nastran XDB result files produced with option
“DBCFACT=4”. Results directly written in the indexation data pages, isntead of in sepa-
rate data blocks are now read correctly. This is the case, for example, for the spring scalar
forces. (We suspects Nastran does not create separate data pages when corresponding
data are small and can be stored in a number of words <=2.)
• A few other improvements of the XDB access with option “DBCFACT=4”.
• The laminate interlaminar shear criteria are no longer calculated at bottom layer of lami-
nates bottom ply.
• Addition of a test on the number of components of values inserted into “Result” objects.
• Correction of a bug in the reading of nonlinear stresses and strains from Nastran XDB
files.
• Addition of several methods in the “Result” class: “cloneNoValues”, “insertResultValues”

and “removeKeysAndValues”.
• Production of compiled extensions for ruby version 2.5.* and Python version 3.7.*.
(However, I have problems to run the FeResPost extension with versions 2.4.* and 2.5.*
of ruby on windows OS.)
• A few corrections in User Manual.
Version 4.5.0
• Correction at several places in the sources codes of errors related to the check of “nbr-
Values” for insertion in Results.
• Correction of two bugs for the conversion of blob objects:
– In ruby extension, on makes a check on nil values.

– In Python library, one corrects a bug in the method of “Post” module that converts
blobs.
• COM component and ruby or python extensions are now statically linked to GNU com-
piler libraries “libm.a” and “libstdc++.a”. This should facilitate the installation of FeRe-
sPost as the GNU C++ redistributable libraries are then no longer needed to use FeRes-
Post.
• Correction of two bugs in the reading of XDB results produced with option DBCFACT=4
for Nastran SOL 106.
• Correction of bug in the calculation of reaction forces and moments. They are now
calculated as the summation of SPC forces or moments. The Reaction forces are now
also available when results are read from XDB files.
• Correction of several bugs in the reading of complex results in magnitude-phase format

from XDB files. The errors concern the reading of “Beam Forces”, “Shell Moments”,
“Shell Curvatures’, “Strain Tensor” and “Stress Tensor”. (The errors were related to
some components wrong sign corrections of the phase part of results.)
• Correction of the reading of strain tensor shear components on CSHEAR, CROD, CON-
ROD, CTUBE and CBEND elements. (Division by two in order to have “real” tensor
component instead of angular shear strains.)
• Correction of the reading of strains, stresses, forces and moments from XDB on CTRIA6
and CQUAD8 elements.
• Void Results read from XDB files are now erased from the list of Results read from the
file.
• Addition of support for the reading of Nastran Results from HDF files. Programming of
this part is under way and support is only partial:
– em The HDF support is not available yet in .NET assembly!

– No support for the reading of optimization results.
– No support for the reading of thermal results.
– Only partial support for the reading of nonlinear analyses results. (Result tables
specific to nonlinear analyses are not read.)
– ...
We are working on these limitations and expect progress soon. See sections III.1.1.10
and I.6.11 for more information.
Version 4.5.1
• Reading of Nastran HDF5 Result files is now possible in .NET assemblies CLR version
4. It does not compile with CLR version 2 however.
• Minor bug fixes (wrong error messages).
• Extension of support for Nastran CWELD element.
• Addition of method “getHdfAttachmentLcInfos” to NastranDb class.

Part XI
References
625
Bibliography
[Gay97] Daniel Gay. Matériaux Composites. Hermès, 1997. 114, 115
[Nas05] MSC.Access User’s Manual. MSC.Software Corporation, 2005. 254
[Pal99] Markku Palanterä, editor. Theoretical Background of ESAComp Analyses, Version

1.5. april 1999. 115, 127
[Rey04] Michael Reymond. MSC.Nastran 2005, DMAP Programmer’s Guide, volume 1.

MSC.Software Corporation, 2004. 231, 232, 260, 347
[Sof04a] MSC Software, editor. MSC.Nastran 2004, Reference Manual. MSC.Software Cor-
poration, 2004. 115, 128, 129
[Sof04b] MSC Software, editor. MSC.Nastran 2005, Quick Reference Guide. MSC.Software
Corporation, 2004. 48, 229, 268, 522
[Sof10] MSC Software, editor. MD/MSC. Nastran 2010, Dynamic Analysis User’s Guide.
MSC.Software Corporation, 2010. 104, 105
627

FeResPost Manual

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

FeResPost Manual

Hochgeladen von

Copyright:

Verfügbare Formate

FeResPost

FeResPost User Manual

THIS PAGE IS INTENTIONALLY LEFT BLANK

In this document, one presents the manual of FeResPost.

• Sometimes, the calculation methods are imposed by a client or a methodology depart-

1. With object-oriented languages, it allows to write interpreted and object-oriented auto-

• As a Python copiled library on Windows and Linux.

How to learn FeResPost?

Structure of the document

2. Addition of specialized post-processing modules programmed at C++ level to provide

• A module devoted to fatigue and damage tolerance analysis.

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

I FeResPost Reference Manual 27

I.1 Generic “DataBase” class 31

I.2 The “CoordSys” class 47

I.2.3.2 “changeCoords02B” method . . . . . . . . . . . . . . . . . . . 50

I.3 The “Group” class 55

I.4 The “Result” class 61

I.4.2.19 “extractSubLayers” method . . . . . . . . . . . . . . . . . . . 72

I.4.13.6 “Size” attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 93

I.5 The “ResKeyList” class 95

I.6 The “Post” module 99

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

II Composite Reference Manual 111

II.1 Theoretical background 115

II.1.6 Out-of-plane shear of laminate . . . . . . . . . . . . . . . . . . . . . . . 128

II.1.11.1 Material thermal parameters . . . . . . . . . . . . . . . . . . . 174

II.2 The “ClaDb” class 181

II.3 The “ClaMat” class 187

II.4 The “ClaLam” class 195

II.4.13 Other methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

II.5 The “ClaLoad” class 213

III Solver Preferences 221

III.1 Nastran Preferences 225

III.2 Samcef Preferences 271

III.2.1.8 Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

IV FeResPost Examples with RUBY Extension 293

IV.1 A small satellite 297

IV.2 A few small examples 309

IV.2.5.3 Calculation of a total force and moment . . . . . . . . . . . . . 339

IV.3 A modular post-processing 351

IV.4 An object-oriented post-processing 363

IV.5 Using the composite classes 377

IV.5.4.3 Properties of the laminates defined in an ESAComp file . . . . . 385

V FeResPost Python bindings 395

V.1 Python examples 401

VI FeResPost as COM component 405

VI.1 CLA classes 415

VI.2 Generic FeResPost classes 417

VI.3 Supported Solvers 421

VII FeResPost Examples with COM Component 423

VII.1.4 Using component for CLA analyses . . . . . . . . . . . . . . . . . . . . . 435

VII.2 CLA analyses in excel 439

VII.3 Extraction and manipulation of Results with excel 447

VII.4 An Excel workbook devoted to post-processing 455

VII.4.1.3 Installing “SQLite for Excel” . . . . . . . . . . . . . . . . . . . 456

VIII FeResPost as .NET assembly 477

VIII.1CLA classes 485

VIII.2Generic FeResPost classes 487

VIII.2.3Group class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488

VIII.3Supported Solvers 491

IX FeResPost Examples with .NET Assembly 493

X.B Coordinate system transformations 515

X.B.2.1 Transformation of vector components . . . . . . . . . . . . . . 517