A library that allows
you to read Nastran and Samcef finite element models and results, and to
automate postprocessing operations.
Purpose
of FeResPost
FeResPost
is a
library that allows the rapid development of small programs to be
used to automate the post-processing of structural analysis finite
element results.
Structural
analysis
The
structure analysis of complex structures often leads to repetitive
tasks. This is related to :
The nature of the structure
that is being analysed. Identical or similar components are often
present several times, and sometimes many times, in the same structure
(beams, panels, interfaces, connections...). These different parts or
components are generally justified exactly the same way, and the
corresponding calculation is often automated (with a programming
language, excel...).
A structure is rarely sized
for a single event, or checked again a single requirement. Generally,
for static analysis, numerous load case are defined to ensure that the
structure's strength is sufficient to sustain severel events in its
life. This means that for each component, or each type of failure mode,
the calculations is often done as many times as the number of defined
load cases.
During the development of
the structure, the design will be updated several times. Sometimes,
several versions of a structure may be justified simultaneously, or
consecutively. (Think, for example, at the different versions of the
B737 Boeing or A320 Airbus planes that are flying nowadays.)
This also contribute to the repititiveness of structural analysis
calculations.
This
explains why engineers involved in structural analysis are often also
programmers. The need for automation leads them to use spreadsheets,
use third party programs to accelerate the justification, or write its
own post-processing programs.FeResPost
can help in the development of these small programs!
How we can help?
The
main
purpose of the program is to download and manipulate Result entities
in order to calculate margins of safety. Possible operations that can
be performed on ``Result'' objects are, for example :
Extraction of the Results
corresponding to a group of elements or nodes.
Modification
of the reference coordinate system,
Calculation
of total force and moment corresponding to a distribution of loads,
Derivation
of criteria like Von Mises for a stress tensor, the norm of a
vectors, the eigen-values and corresponding eigen-vectors for tensorial
results...
Operations
combining several results (sum, difference, product, merging of
Results...),
Derivation
of new Results (for example, laminated Results),
Extraction of maximum or
minimum values, and corresponding finite element entities (elements,
nodes...),
...
So
far, these results can be read from Nastran XDB or OP2 files, or from
Samcef DES/FAC files. The corresponding finite element models can also
be important from Nastran Bulk BDF files, or Samcef Bacon DAT files.
The
groups of elements and nodes can be read from Samcef DAT or Patran
session files. Manipulation of these Groups, by addition, substraction,
intersection, associations are possible.
FeResPost
allows the
simultaneous manipulation of several models by defining several
NastranDb and SamcefDb objects, and different Nastran and
Samcef models can be manipulated simultaneously.
FeResPost
also allows the calculation of composite structure by providing
severeal classes for the Classical
Laminate Analysis (CLA).
Among other things, the CLA classes of FeResPost allow to :
Evaluate Laminate properties
(equivalent moduli, stiffness and compliance matrices, coefficient of
thermal expansion).
Calculate laminate analysis
response corresponding to a specified loading (laminate loads and
deformation, ply stresses and strains,...)
Evaluate laminate strength
by calculating different failure criteria.
...
The
CLA classes can be used separately from the finite element results, but
also
used together with finite element results.
This allows for example to:
Calculate,
at post-processing level, with a single command, the laminate response
using shell forces, moments, temperatures on a large set of elements.
Do this calculation with the
finite element model laminates, or with different laminates,
Estimate failure criteria
that are no proposed by the finite element solver being used
...
Classes
and Modules
The
library provides an access to
7 classes
and 2 module allowing the manipulation of FE entities and
results. The 7 classes are :
The
``DataBase'' class that is used to store
a FE model and other entities
(Groups, Results,...). This class is a generic class that can not be
instanciated. Two classes inherit the DataBase class:
The
``NastranDb'' class that is used for the manipulation of Nastran models
and Results.
The
``SamcefDb'' class that is used for the manipulation of Samcef models
and Results.
The
``Result'' class that allows the manipulation of Results, thier
transformation,...
The
``ResKeyList'' class, very useful to manipulate Result entities.
The
``Group'' class that allows the definition of Groups, thier
manipulation, the extraction of Results on small parts of the
structure.
The
``CoordSys'' class for the manipulation of coordinate systems (still to
be done)
The
``Post'' module gives access
to several additional functions.
Four
classes used to perform
Classical Laminate Analysis calculations are also provided:
The
``ClaDb'' class that stores composite entities,
The
``ClaMat'' class used to mainpulate materials,
The
``ClaLam'' class to store laminates and perform CLA calculations
The
``ClaLoad'' class used to manipulate loadings applied to Laminates.
The
CLA classes are interfaced
with the rest of FeResPost and allow to post-process very efficiently
composite finite element Results.
The
program
is mainly written in C++, and the ruby extension is build as a
wrapping around a C++ library. This solution ensures that the program
is easy to manage and that the program remains efficient because
costly operations are done at C++ level (compiled language
efficiency).
License
FeResPost
is distributed as a
LGPL resource. This means that it is
free, and that you can modify and re-distribute it gratis as long as
you comply with ther therms of the LGPL license. (These are given in an
Appendix of the User Manual. See below.)
System
requirements
Solvers
So
far, Results of Nastran and Samcef solvers can be post-processed.
Nastran
Finite element models can be read either from a BDF (bulk data file),
or an op2 file. Groups can be build by reading Patran sessions files
obtained with the utilities of Patran.
Results
can be read from OP2 or XDB files. The most commonly used
types of elements are supported. For XDB files, it is also possible to
extract results by random access (XDB attachment).
Samcef
Finite element models can be read from a dat file obtained by a
".sauve banque" Bacon command.
Results
can be read or accessed randomly from DES/FAC files.
Operating
systems and programming languages
The
library is distributed as a ruby extension
(LINUX and Windows), as a COM component (Windows only) and as a .NET
assembly (Windows only). In order to use FeResPost you need to
install first one of the corresponding programming languages :
Ruby if you wish to use the ruby extension. (Binaries are
distributed for Linux and Windows operating systems, but a
recompilation of the sources allow the installation of FeResPost on
other OSs.)
The COM component can be used with many languages, but on Windows
OS only. Testst have been done with Ruby, Python, C++, VBA (in excel).
Other languages like C, Java should also be capable of using the COM
component.
All the .NET languages should be able to use the .NET assembly.
This includes VB.NET, IronRuby, Java.NET, C#. Tests have been done with
C# language only. (See the examples.)
The
programming language in
which all those operations are programmed is object oriented and
allows the development of very sophisticated and large
post-processing programs, or very small tools, according to the
wishes of the programmer.
Other
resources
Besides
the installation of the programming language you wish to use, a few
other programs may help you to develop scripts using FeResPost. The
examples distributed on this web site and discussed in the User Manual
sometimes assume that thos programs have been installed on your
computer. For example:
FeResPost allows to save Nastran and Samcef DataBases or
intermediate results in GMSH files for later
visualisation. You do not needs in GMSH files to run the
example. the program is necessary if you want to visualize what you
have saved, so you better install it on your computer. It is free, very
easy to install, and distributed under the LGPL license.
The Result class has a member function for conversion from/to
BLOB (Binary Large Objects) for interaction with SQL databases. Several
examples illustrate the use of these conversion methods. These examples
make use of the SQLite database
system. The corresponding library is free, open source, but needs to be
installed if you want to run the corresponding examples.
Some examples that use the COM component are written in the VBA
code of excel spreadsheets. Of course, you need excel if you want to
run these examples.
Downloads
Latest
version is version
4.3.0!
Manuals
An
online HTML manual is available, but we advise to download the PDF
version :
The
manual presents the different classes defined in FeResPost library,
with the associated properties and methods. It also illustrates the use
of different FeResPost objects with examples. (See below.)
Examples
One
distributes two archives containing the examples. (The content of these
two files are the same.)
The
examples contain a small satellite Nastran finite element model, and
numerous post-processing examples :
Manipulation of Groups and
Results with FeResPost Ruby extension,
Use of the COM component
with several programming languages (Ruby, Python, VBA, C++),
Use of the .NET assembly
with C# examples.
...
Some
of these examples are very small and illustrate simple extraction of
results from XDB or OP2 files, with a very limited number of
manipulations. But one also proposes examples corresponding to entire
post-processing projects that could be used readily in a real project.
(These examples are provided as Ruby programs, or in excel workbooks.)
One suggest however, that the user reads the examples in the order in
which they are defined, starting with the ruby examples, as this is the
only way to really understand the use of FeResPost objects.
Sources
As
FeResPost is distributed under the LGPL license, the sources are also
distributed for re-compilation or modification and re-distribution :
Binaries
are distributed for several versions of FeResPost and include ruby
extensions for Linux and Windows, COM component for Windows, and a .NET
assembly. The FeResPost C++ library is also distributed for latest
versions, but one recommends to use static linking for your own
programs and to recompile yourself the FeResPost classes.
Sources
of FeResPost are distributed for the different published versions of
the library. These include the C/C++ sources, the examples, and
possibly the PDF manual.
Third party contributions
One
also distributes a third-party contribution, but without any support :
You
can visit
or subscribe to FeResPost Google group :
If
you have a question to ask, a bug to report, we would appreciate that
you do it via FeResPost google group, so that others can benefit of
your remarks as well.
You
can also subscribe to the freshmeat
FeResPost mailing list if
you want to be automatically warned
about new major revisions of FeResPost. Similar mailing lists are also
available on other websites as Softpedia (for Linux or Windows).
FeResPost allows to automate the following operations :
FeResPost allows to export/import results and groups into/from BLOB objects (Binary Large OBjects) for insertion in
in an SQL database. Several of the examples presented use the SQLite database, but the capability should also work
with other SQL database systems as MySQL, PostgresSQL,...
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 department in the company, and these methods may also be modified,
or be defined concurrently 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 an extension of ruby 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:
Ruby being object-oriented, it allows to write interpreted and
object-oriented automated post-processing. An example of such an
object-oriented post-processing program is given in
Chapter IV.3. Ruby has been chosen because the
language is clean, nice and very, and can easily be extended with compiled
classes and modules.
The FeResPost library is mainly written in C++, which is also an
object-oriented language. Then a Ruby wrapping is provided around the C++
code.
During the development of FeResPost, the developer has been trying to maintain
as much as possible the simplicity and clarity of the language in which
post-processing programs are written. He hopes that this will make the
task of the structural analysis engineers using the program, as much as possible
an enjoyable task, and not one job that makes him want to throw his
computer by the window, to kick his boss or to hang himself.
One gives here some advice to people starting to use FeResPost. The order in
which the knowledge is acquired matters. One of the worst way to try to
learn FeResPost is to read the manual while writing bits of code meant to solve
the particular problem the user has in mind. Instead, one suggests the
following sequence of knowledge acquisition:
FeResPost is an extension of ruby programming language. This means that
the examples provided in the document are small ruby programs. Therefore
a basic knowledge of ruby is necessary. People trying to learn ruby
and FeResPost at the same time will probably fail in both tasks.
Very good books on ruby language are available in libraries. Internet
resources are also a source of information (newsgroups, tutorials with
examples...).
Note that people already familiar with one or several object-oriented
programming languages will have no difficulty to acquire a basic knowledge of
ruby.
Then, the user may test FeResPost by running the small examples. These
are provided in the sub-directories in ``SMALLEX'' 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.
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.
The two examples ``PROJECTa'' and ``PROJECTb'' illustrate the
programming of more complex post-processing of Results involving loops
on load-cases, on several types of post-processing calculations... These
two projects should be studied at the very end.
``PROJECTa'' is meant to be studied before ``PROJECTb''. Indeed, ``PROJECTa''
is easier to understand than ``PROJECTb'', because it is less
object-oriented. but it is also less complete and less nice from
a programming point of view.
The reason why the advices above is given is that many users send mails of
questions or complaints because they fail to understand something about
FeResPost which is clearly illustrated in the examples. Sometimes, the problems
faced by the users are simply related to a lack of understanding of the ruby
programming language.
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 supported by FeResPost.
In Part IV, several examples of
post-processing written with the ruby library are presented.
Part V 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 VI.
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:
Correction of bugs...
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.
...
Extension of FeResPost by providing interfaces towards other FE
software like Abaqus,...
Development of extensions for other interpreted languages like python
or perl.
Development of a UNO component.
...
Of course, we are open to constructive remarks and comments about the
ruby library in order to improve it.
FeResPost is a ruby extension 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
Chapter 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''.
Finally, the loading of FeResPost library also modifies some methods of Float
and Array classes, as explained in
section I.4.6.
I.1 Generic ``DataBase'' class
Basically, a ``DataBase'' class is a container used to store a finite element
model, Groups, Results, and other less important
entities. The DataBase class also allow to retrieve, manipulate or modify these
objects. The DataBase class is a generic class that cannot be instantiated. The
specialized classes that inherit the generic DataBase class are described in
Part III. Other solvers might be supported in the
future. The class hierarchy is schematically represented in
Figure I.1.1.
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.
Section I.1.3 is devoted to the
DataBase's methods devoted to the manipulation of Results.
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.
userManual.DataBase.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
No generic ``DataBase'' object can be created because ``DataBase'' class
cannot be instantiated. This means that a statement like:
db=DataBase.new()
leads to an error message. All the methods described in this
section are defined in the specialized versions of the DataBase class.
So no ``new'', ``initialize'' or ``clone'' method.
One defines three methods that allow to retrieve the number of entities
of certain types stored in DataBase FE model:
``getNbrCoordSys'' returns the number of coordinate systems
stored in the DataBase.
``getNbrElements'' returns the number of elements
stored in the DataBase.
``getNbrNodes'' 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 otherwise.
``checkElementExists'' returns true if the specified element
exists, false otherwise.
``checkNodeExists'' returns true if the specified node
exists, false otherwise.
``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 manipulation of Group objects. In the
DataBase, the Group objects are stored in a mapping associating their names
to the Group. This association allows to retrieve the Group when needed.
One makes the distinction between the simple manipulation of Groups described
in section I.1.2.1 and the more
complicated operation where new Groups are created by association operations
(section I.1.2.2). The methods
related to these associative operations are often defined in the specialized
versions of the Database class.
I.1.2.1 Simple manipulation of Groups
One describes here methods that allow the manipulation of Groups stored in a
generic DataBase object. All the methods described in this section are
defined in generic DataBase class. These methods are described below:
``readGroupsFromPatranSession'' reads one or several Groups from a
Patran session file obtained using the utility
``Patran->utilities->groups->exportToSessionFile''. The argument 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 corresponding 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.
``getNbrGroups'' has no argument and returns the number of Groups
stored in the DataBase.
``getAllGroupNames'' has no argument and returns an Array of String
objects corresponding to the names of all the Groups contained in the
DataBase on which the method is called.
``checkGroupExists'' allows to check whether a Group exists in the
DataBase. The argument 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 corresponding 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 argument.
``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 stored in the DataBase.
``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 define the model stored in the DataBase.
``getGroupAllFEM'' returns a Group containing all the elements,
nodes, rbes and coordinate 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 association is checked by inspection of the finite
element model stored in the DataBase. Therefore, these methods are defined
in the specialized version of the ``DataBase'' class. Therefore, these methods
are systematically defined in specialized versions of the ``DataBase'' class.
For each supported solver, a description of these methods is given. (See
Part III.)
I.1.3 ``Result'' methods
As explained in the introduction of this Chapter, the DataBase can be used
to store Results. Internally, a mapping between keys and Results allows to
associate Result objects to an identifier. Each key^{I.11} is
characterized by three String objects corresponding respectively to the load
case name, to the subcase name and to the Result type name.
I.1.3.1 Manipulation of Results
The class ``Result'' is described in Chapter I.4.
In this section, one describes the methods of the generic ``DataBase'' class
that deal with ``Result'' objects. The ``Result'' methods are:
``getResultLoadCaseNames'' is a method without argument that returns
an Array containing 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 containing 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:
``Axis 1'' corresponding to the first element axis.
``Axis 2'' corresponding to the second element axis.
``Axis 3'' corresponding to the third element axis.
``Normals'' corresponding to the normals to 2D elements.
``Axis'' corresponding to the first element axis of 1D elements.
``Coordinates'' corresponding to the coordinate Results generated
by ``generateCoordResults'' method.
By default, components are expressed in element axes, except for the
``Coordinates'' Result which follow the conventions of
``generateCoordResults'' method. The third argument 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 optional.
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 containing 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:
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.
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 duplicated, 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 argument.
``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 possibilities):
A String argument corresponding to the load case name.
A String argument corresponding to the subcase name.
A String argument corresponding to the Result type name.
A String argument corresponding to the method of selection.
Possible values of this argument are: ``Elements'', ``ElemCenters'',
``ElemCorners'', ``Nodes'', ``NodesOnly'', ``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.)
A Group argument corresponding to the Target (selection of
elements or nodes on which the Results are recovered).
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:
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.
Four singleton methods allow to enable or disable partially or totally
the reading of composite layered Results from finite element result files.
These methods influence the behavior of methods defined in the
``specialized'' versions of the ``DataBase'' class. (See
Part III.) The four methods are:
``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 (inverse of the previous method). Again, the
method has no argument.
``enableSubLayersReading'' enables some sub-layers for the
reading of composite layered 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 layered 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:
``clearAbbreviations'' has no argument and clears all the
abbreviations stored into the DataBase.
``addAbbreviation'' adds one abbreviation to the DataBase. The
method has two String arguments: the key and the value.
``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.
``getNbrAbbreviations'' has no argument and returns the number of abbreviations stored
in the DataBase.
``getAbbreviation'' returns the String value of one abbreviation.
The method has one String argument: the key of the abbreviation.
``checkAbbreviationExists'' returns ``true'' if the abbreviation exists.
The method has one String argument: the key of the abbreviation.
``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.3. If the finite element model is
defined in another unit system, it is the responsibility of the user to define
correctly the units of the ClaDb database and of all its entities using the
method ``setUnitsAllEntities'' of ClaDb class. (See
section II.2.4.)
Another method corresponding to the calculation of Results related to
laminate load response has been added. This method called
``calcFiniteElementResponse'' has the same arguments as the corresponding
method defined in the ``ClaLam'' class. The method and the meaning of its
arguments are described in section II.4.8. The
method defined in ``DataBase'' class differs from the one defined in
``ClaLam'' class by the fact that the algorithm tries to retrieve the
Laminate corresponding to the element to which Result values are attached.
The information is found in the DataBase object. More precisely, The
algorithm performs as follows:
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 ClaLaminate 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:
A ClaDb object which is used for the calculations of the different
laminate properties.
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.)
A Hash with String keys and values corresponding to the requests.
The key corresponds to the name by which the returned Result shall be
referred. The value corresponds to the laminate engineering property that
is requested. Presently, possible values of this parameter are:
``E_f_xx'', ``E_f_yy'', ``E_k0_xx'', ``E_k0_yy'', ``E_xx'',
``E_yy'', ``G_f_xy'', ``G_k0_xy'', ``G_xy'', ``nu_f_xy'',
``nu_f_yx'', ``nu_k0_xy'', ``nu_k0_yx'', ``nu_xy'', ``nu_yx'',
``thickness'', ``surfacicMass'', ``averageDensity''.
The method returns a Hash with String keys and Result values.
An example of use of this method follows:
...
compDb=db.getClaDb
res=db.getResultCopy("COORD","coord","coordinates")
rkl=res.extractRkl
requests={}
requests["res1"]="thickness"
requests["res2"]="E_xx"
requests["res3"]="E_yy"
resList=db.calcFemLamProperties(compDb,rkl,requests)
resList.each do |id,res|
Util.printRes(STDOUT,id,res)
end
...
For the different ``finite element'' methods listed above, the units considered for the
returned ``Result'' objects are the units of the ``ClaDb'' object argument. This
characteristic differs from the behavior of the corresponding methods in
``ClaLam'' class.
I.1.6 Iterators
One describes here the iterators of the generic DataBase class only. The
iterators of the specialized versions of the class are described in
Part III.
``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 Results 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:
A string containing the name of the file in which the model and
Results will be output.
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.
An Array containing the Results to be stored in Gmsh file. Each
element of the Array is An Array of three elements:
A Result object.
A String corresponding to the name with which the Result shall be
referenced in Gmsh.
A String that can have four values: ``ElemCenters'',
``ElemCorners'', ``Nodes'' and ``ElemCenterPoints''. It corresponds to
the location of values that are extracted from the Result object to be
printed in the Gmsh file. ``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.
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.
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.
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.
The ``writeGmshMesh'' method defined in generic ``dataBase'' class saves a
Gmsh mesh file. The method has up to four arguments (last argument is
optional):
A String containing the name of the file in which the mesh is
output.
An integer argument corresponding to the coordinate system in which
the nodes are expressed.
A Group corresponding to the entities to be saved in the mesh file.
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)
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.
userManual.CoordSys.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
A CoordSys object corresponds to a coordinate system. CoordSys objects are
generally created in a DataBase when a model is imported.
Besides the data corresponding to the definition of the coordinate system,
the CoordSys object also contains a definition of the coordinate system wrt
the most basic coordinate system ``0''. The corresponding member data are
used by functions like the Result methods of modification of reference
coordinate systems to perform the transformations of components (sections
I.4.5.7 and
I.4.5.8). Practically those functions work in
two steps:
The components of the Result object are expressed wrt the basic
coordinate system ``0''.
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''
This function 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 coordinate system.
An integer argument corresponding to the reference coordinate
system (coordinate system 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 argument.
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 coordinate 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 coordinate 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 functions ``initWithOViVj''
The three functions are ``initWithOV1V2'', ``initWithOV2V3'',
``initWithOV3V1'', ``initWithOV2V1'', ``initWithOV3V2'' and
``initWithOV1V3''. They produce CoordSys objects defined by their origin
and two direction vectors corresponding to vector
and to the
orientation of vector
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 system 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
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
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
is not necessarily
orthogonal to
. If the vectors are not orthogonal, then
is a unit vector parallel to
, and vector
is
the unit vector perpendicular to
closest to
. The last
vector
of the coordinate system is a unit vector perpendicular to
both
and
.
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 Function ``updateDefWrt0''
This function updates the definition of a CoordSys object wrt to ``0''
(most basic coordinate system). This function has one argument: the
DataBase in which the information needed to build the definition wrt 0 is
found.
Note that if one works with several DataBases, the responsibility of
managing the correspondence of coordinate systems and DataBases lies on
the user.
I.2.3 Transformation of point coordinates
The ``CoordSys'' class defines three methods devoted to the transformation
of a point coordinates from one coordinate system to another.
I.2.3.1 Method ``changeCoordsA20''
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 Method ``changeCoords02B''
Method ``changeCoords02B'' is used to calculate the coordinates of a point
wrt a given coordinate system ``B'':
The coordinate system on which the method is called is the
coordinate system in which 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 coordinate of the same point, but expressed wrt
coordinate system ``B''.
The method is called as follows:
coordsB=csB.changeCoords02B(coords0)
I.2.3.3 Method ``changeCoordsA2B''
Method ``changeCoordsA2B'' is used to calculate the coordinates of a point
wrt a given coordinate system ``B''. The initial coordinate system is
a given ``A'' coordinate system:
The 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 coordinate of the point expressed wrt
coordinate system ``B''.
The method is called as follows:
coordsB=csA.changeCoordsA2B(coordsA,csB)
I.2.4 Transformation of vector and tensor components
The ``CoordSys'' class defines three methods devoted to the transformation
of a vector or tensor components from one coordinate system to another.
These methods are similar to the methods used to transform point
coordinates in section I.2.3 but with
the following differences:
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 Method ``changeCompsA20''
Method ``changeCompsA20'' is used to calculate the components of a vector
or tensor wrt basic or ``0'' coordinate system:
The coordinate system on which the method is called is the
coordinate system in which the initial components are
defined. (Coordinate system ``A''.)
The first ``CoordA'' argument is an Array of
three real values corresponding to the coordinates 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 coordinate system ``0''. (An Array of three
real values, or an Array of Arrays of three real values.)
The method is called as follows:
vm0=csA.changeCompsA20(coordsA,vmA)
I.2.4.2 Method ``changeComps02B''
Method ``changeComps02B'' is used to calculate the components of a vector
or tensor wrt basic or ``B'' coordinate system:
The coordinate system on which the method is called is the
coordinate system in which one wants to express the components.
(Coordinate system ``B''.)
The first ``Coord0'' argument is an Array of
three real values corresponding to the coordinates 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.)
The method returns the components of a vector or tensor,
but expressed wrt basic coordinate system ``B''. (An Array of three
real values, or an Array of Arrays of three real values.)
The method is called as follows:
vmB=csB.changeCoords02B(coords0,vm0)
I.2.4.3 Method ``changeCompsA2B''
Method ``changeCompsA2B'' is used to calculate the components of a vector
or tensor wrt basic or ``B'' coordinate system:
The coordinate system on which the method is called is the
coordinate system in which the initial components are
defined. (Coordinate system ``A''.)
The first ``CoordA'' argument is an Array of
three real values corresponding to the coordinates 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.
The method returns the components of a vector or tensor,
but expressed wrt basic coordinate system ``B''. (An Array of three
real values, or an Array of Arrays of three real values.)
The method is called as follows:
vmB=csA.changeCoordsA2B(coordsA,vmA,csB)
I.2.5 Other functions
One gives here a list of functions that do not fit in any category listed
above.
This function is used for printing the Result object.
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.
userManual.Group.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
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
corresponding to the identifiers of the entities.
Part of the operations dealing with Groups are done by methods defined in
DataBase class. The methods of DataBase specially devoted to operations
mainly related to Groups are described in
section I.1.2.
I.3.2 Creation of a Group object
The singleton method ``new'' is used to create Group objects.
I.3.3 Manipulation of entities stored in a Group
The class ``Group'' provides a large choice of methods devoted to the
manipulation of the list of entities in its storage. One makes the
distinction between operations that modify the content of a Group, and the
operations that allow the inspection of this content.
The modification of the Group's content can be done by calls to the
following methods:
``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:
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.
The second argument may also be an Array of integers. Then the
integers correspond 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 inserted.
``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, only three 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 entity 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: ``CoordSys'', ``Element'',
``Node'' and ``MPC''.
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
and
are two Groups, then
. (The operation is equivalent to a logical
``exclusive or'' operation on the entities.)
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.
I.4 The ``Result'' class
The ``Result'' class is devoted to the manipulation of finite element Results.
Examples of Results are stress tensor on volumic or surfacic elements,
displacements, grid point forces,... The ruby class ``Result'' is a
wrapping around the C++ class ``Result''.
Results can be read from various solver binary files. See
Part III for more information.
The ``Result'' class allows the storage and manipulation of Real as well as
Complex values. Note however that several of the methods of Result class do not
allow the manipulation of Complex Results. Therefore, indications are inserted
here and there in this Chapter to provide information about the ``Complex
capabilities'' of the different methods.
An important comment must be done: Even though the results can be imported
into a DataBase, this does not mean that the manipulation of the results is
correct. Indeed, all manipulation that involve transformation of coordinate
systems can be incorrect because geometric non-linearities are not taken into
account. Methods that can be affected by this limitation are for example:
``modifyRefCoordSys'', ``modifyPositionRefCoordSys'' and ``calcResultingFM''.
A list of the methods defined in ``Result'' class is given in
Table I.4.1.
Table I.4.1:The different methods that have been defined in ``Result'' class.
userManual.Result.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
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,
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 corresponds 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 ``Z0'', ``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 ..."
...
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
"PointA"
-201
"PointB"
-202
"PointC"
-203
"PointD"
-204
"PointE"
-205
"PointF"
-206
For 2D elements
"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
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:
-9999 means that the results are not attached to a coordinate
system. Their value corresponds 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 coordinate 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 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 conscerned.
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 number,... 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 calculation, to continuation parameters,
eigen-values,... These member data can set or retrieved 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
This method is used to extract a sub-set of keys and values from an
existing Result object. The method returns the newly created Result
object. The method has up to four arguments:
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.
``ElemCenters'': all the values associated to the elements of
Group ``Target'' but not associated to any node are inserted in
the values of the returned Result object. This means that the
extraction returns only values at center of the elements.
``ElemCorners'': all the values associated to the elements of
Group ``Target'' and associated to any node are inserted in
the values of the returned Result object. The extraction returns
only values at corner of the elements. Note that the list of nodes
of the ``Target'' Group is irrelevant for this extraction operation.
``Nodes'': all the values associated to the nodes of
Group ``Target'' are inserted in the values of the returned Result
object.
``NodesOnly'': all the values associated to the nodes of
Group ``Target'' but associated to no elements are inserted in
the values of the returned Result object.
``ElemNodes'': all the values associated to the elements of
Group ``Target'' AND to the nodes of the same Group are inserted
in the values of the returned Result object. This means that the
new Result contains only values at corners of elements.
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.
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
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
This method is used to extract a sub-set of keys and values from an
existing Result object. The method returns the newly created Result
object. The method has one ``LayersList'' argument: it is an Array
containing the list of layers on which the pairs of key and value must be
extracted. The elements of the Array argument are integers or String
values.
This method works for Real as well as for Complex Results.
I.4.2.3 ``extractResultOnSubLayers'' method
This method is used to extract a sub-set of keys and values from an
existing Result object. The method returns the newly created Result
object. The method has one ``SubLayersList'' argument: it is an Array
containing the list of sub-layers on which the pairs of key and value
must be extracted. The elements of the Array argument are integers or
String values.
This method works for Real as well as for Complex Results.
I.4.2.4 ``extractResultOnRkl'' method
This method returns a Result object build by extraction of the values
corresponding to the keys contained in the ResKeyList
``Target'' argument.
This method works for Real as well as for Complex Results.
I.4.2.5 ``extractResultOnResultKeys'' method
This method returns a Result object build by extraction of the values
corresponding to the keys contained in the Result
``Target'' argument. (This method is very similar to ``extractResultOnRkl''
method, except that the target is given by a Result argument.)
This method works for Real as well as for Complex Results.
I.4.2.6 ``extractResultOnRange'' method
This method returns a Result object build by extraction of the values
selected by specifying a range. This method can be applied to
scalar Result objects only as the range is specified by one
or two Real values. The arguments of the method are:
The ``Method'' String argument specifies the extraction
algorithm that is used. Four values are possible:
``below'': extraction of the values below the ``LowerBound''
Real argument value.
``above'': extraction of the values above the ``UpperBound''
Real argument value.
``between'': extraction of the values between the
``LowerBound'' and ``UpperBound'' Real argument value.
``outside'': extraction of the values not between the
``LowerBound'' and ``UpperBound'' Real argument value.
The ``LowerBound'' argument is a real value specifying the lower
bound of the range. For some algorithms, this value may be unused and
irrelevant.
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
This method returns a Result object build by extraction of maximum
``NbrVals'' values. This method can be applied to scalar
Result objects only and has two arguments:
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.
``NbrVals'' is an integer argument corresponding to the number of
values to be kept.
This method works for Real Results only.
I.4.2.8 ``extractResultMin'' method
This method returns a Result object build by extraction of the minimum
value and corresponding key. This method can be applied to
scalar Result objects only.
This method works for Real Results only.
I.4.2.9 ``extractResultMax'' method
This method returns a Result object build by extraction of the maximum
value and corresponding key. This method can be applied to
scalar Result objects only.
This method works for Real Results only.
I.4.2.10 ``extractRklOnRange'' method
This 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.
This method works for Real Results only.
I.4.2.11 ``extractRklForNbrVals'' method
This 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.
This method works for Real Results only.
I.4.2.12 ``extractRklMin'' method
This method returns a ResKeyList object build by extraction of
the key corresponding to the minimum value. This method can be applied
to scalar Result objects only.
This method works for Real Results only.
I.4.2.13 ``extractRklMax'' method
This method returns a ResKeyList object build by extraction of
the key corresponding to the maximum value. This method can be applied
to scalar Result objects only.
This method works for Real Results only.
I.4.2.14 ``extractRkl'' method
This method returns a ResKeyList object build by extraction of all
the keys of the Result object to which the method is applied.
This method works for Real as well as for Complex Results.
I.4.2.15 ``extractGroupOnRange'' method
This 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.
This method works for Real Results only.
I.4.2.16 ``extractGroupForNbrVals'' method
This method works exactly as method ``extractResultForNbrVals''
described 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.
This method works for Real Results only.
I.4.2.17 ``extractGroup'' method
This method returns a Group object containing the elements and nodes that
are referenced in the Result object. This method has no argument.
This method works for Real as well as for Complex Results.
I.4.2.18 ``extractLayers'' method
This method returns an Array of String and integers corresponding
to the layers that are referenced in the Result object. This method has no
argument.
This method works for Real as well as for Complex Results.
I.4.2.19 ``extractSubLayers'' method
This method returns an Array of String and integers corresponding
to the sub-layers that are referenced in the Result object. This method
has no argument.
This method works for Real as well as for Complex Results.
I.4.3 Derivation monadic methods
All the methods presented in this section are devoted to the production of
new results by performing operations on the values of the Result object to
which they are applied. Each method produces Results with as many pairs
``key-values'' as in the Result object to which it is applied, but the number
of components associated to each key may be different than the original
number of components. Indeed, the original Result and derived Result have not
necessarily a same tensor order.
Most of the methods presented below have only one argument: a Method
String object corresponding to the algorithm of derivation. The use of the
methods defined below leads sometimes to very heavy notations for simple or
very often used operations. Therefore, short-cuts to some methods have been
defined in the ``Post'' module
(ChapterI.6).
I.4.3.1 ``deriveScalToScal'' method
This 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
(angle in radians).
``cos'': returns
(angle in radians).
``tan'': returns
(angle in radians).
``asin'': returns
(angle in radians).
``acos'': returns
(angle in radians).
``atan'': returns
(angle in radians).
``exp'': returns
.
``log'': returns
.
``exp10'': return
.
``log10'': returns
.
``abs'': returns
.
``inv'': returns
.
``sinh'': returns
.
``cosh'': returns
.
``tanh'': returns
.
``sq'': returns
.
``sqrt'':
.
``sgn'': +1, 0 or -1 depending on the value of argument
(arg>0, arg==0 or arg<0 respectively).
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.
I.4.3.2 ``deriveVectorToOneScal'' method
This 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
.
``sq'': returns
.
This method works for Real Results as well as for Complex Results.
When applied to a Complex 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.3 ``deriveVectorToVector'' method
This 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.4 ``deriveTensorToOneScal'' method
This 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
).
``2DMaxPrincipal'': returns the maximum principal value
assuming that the tensor is a 2D tensor (all components
).
``2DMinPrincipal'': returns the minimum principal value
assuming that the tensor is a 2D tensor (all components
).
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.5 ``deriveTensorToTwoScals'' method
This method returns an Array of two Result objects derived from the
tensorial Result object on which the method is
applied. The returned Results are scalar. Possible values of
the ``Method'' String argument are:
``Principals2D'': returns the principal values of a
tensorial Result assuming that the tensor is
a 2D tensor (all components
). 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 tensorial Result. The first Result
contains minimum principal values, and the second Result contains
maximum principal Values.
This method works for Real Results only.
I.4.3.6 ``deriveTensorToThreeScals'' method
This method returns an Array of three Result objects derived from the
tensorial Result object on which the method is
applied. The returned Results are scalar. Possible values
of the ``Method'' String argument are:
``Principals'': returns the principal values of a
tensorial Result sorted by order of increasing
values. (First Result contains minimum principal values, second Result
corresponds to second principal value, and third Result contains the
maximum principal values.)
This method works for Real Results only.
I.4.3.7 ``deriveByRemapping'' method
This 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:
``FromTo'': a String object specifying the correspondence
between the keys of the old Result object and the keys of the new
Result object. Six 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 Element, Node and SubLayer only one Layer is kept. The
layerId of each key of the produced Result object is the one of
the selected key-value of the original Result. For this option only
``min'' and ``max'' selection methods are accepted.
``MergeSubLayers'': one produces a Result object in which
for each pair of Element, Node and Layer only one SubLayer is kept. The
subLayerId of each key of the produced Result object is kept
uninitialized (i.e. set to 0).
``MergeSubLayersKeepId'': one produces a Result object in which
for each pair of Element, Node and Layer only one SubLayer is kept. The
subLayerId of each key of the produced Result object is the one of
the selected key-value of the original Result. For this option only
``min'' and ``max'' selection methods are accepted.
``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.
``DB'': a DataBase object used by the method to recover the
association of node and elements. This association is often needed
to perform the remapping.
The ``deriveByRemapping'' method can be used with Real as well as
Complex Results. Only, for Complex Results, there are some restriction
about the type of ``Method'' argument for merging values: the ``min''
and ``max'' values are not accepted for Complex Results.
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
(
). 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
``pow'' performs the ``pow'' operation on its argument
(
). 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
for each
.
``vectProduct'' calculates the vectorial product of its
arguments:
. The two arguments
are vectorial Result objects.
``sumVectProduct'' calculates the sum of the vectorial product
of its arguments:
. The two arguments
are vectorial Result objects.
``min'' keeps the minimum of the two values. Values must be scalar
and Real.
``max'' keeps the maximum of the two values. Values must be scalar
and Real.
``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.
``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 ``mergeKeepLast'' can be used. Of course,
if the ''Second'' argument is a Real object, the ``deriveDyadic'' method
cannot be invoked on a Complex Result object.
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 respectively.
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.
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 element are Real values
corresponding to the components.
``insertRklVals'' has two arguments corresponding to a
ResKeyList object and a result::values object respectively.
The ``Rkl'' is a ResKeyList 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.
``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 values 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''.
This method can be used with Real Results as well as with Complex Results.
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''.
This method can be used with Real Results as well as with Complex Results.
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.
This method can be used with Real Results as well as with Complex Results.
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.
This method can be used with Real Results as well as with Complex Results.
I.4.5.7 ``modifyRefCoordSys''
``modifyRefCoordSys'' is used to modify the reference coordinate
system wrt which the components of a vectorial or a
tensorial Result are applied. If the Result is
vectorial it can represent any vectorial quantities except the
coordinates. For coordinate vectorial Result, the
method ``modifyPositionRefCoordSys'' must be used. This method has
no effect on scalar Results.
The methods returns nil (no new Result object is created) and takes
two, three or five arguments:
A DataBase object.
An object corresponding to the definition of the coordinate
system to which one switches. This object may have different types:
A String object with one of the following values: ``elemCS'',
``nodeCS'', ``matCS'', ``plyCS'', ``elemIJK'', ``lamCS''. All
those coordinate systems are local to an element or to a node.
More information about the peculiarities of ``matCS'', ``plyCS'' and
``lamCS'' coordinate system transformations is given in section
IX.B.5.
The argument may by a CoordSys object. Then it must be defined
wrt a coordinate system defined in the DataBase argument.
The argument may also be an integer larger than or equal to 0.
Then the coordinate system must be defined in the DataBase.
The third argument is the direction vector used to build the
projected coordinate system on surfacic elements. The vector is given
by an Array of three real objects, and is expressed wrt to the
coordinate system given in second argument. If one does not wish to
transform into a projected coordinate system, then the third argument
must be omitted or nil. (However if arguments 4 and 5 are provided,
the third argument cannot be omitted.)
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.
The last argument is a direction vector used to build the
projected coordinate system on surfacic elements. The vector is given
by an Array of three real objects, and is expressed wrt to the
coordinate system given in second argument. If one does not wish to
transform into a projected coordinate system, then the third argument
must be nil.
The reason why a DataBase object is given as argument is
that for curvilinear coordinate systems, much information about the
location of Result value is necessary to perform a correct transformation
of the components. Also, all coordinate systems are stored in the
DataBase object. Therefore, it is very important that the
programmer keeps in mind that all Results are related to a
DataBase.
Note that some transformation vectorial or tensorial coordinate systems
cannot be reversed. For example, once a Result is expressed in a projected
coordinate system. Also, if a conversion has been done in a coordinate
system that is not defined in the DataBase, the conversion is impossible.
After transformation, the coordinate system referenced in Result values is
altered (section I.4.1.2).
If arguments 4 and 5 are provided, the method assumes that the values
are expressed in that coordinate system definition. This means that the
CsId found in each pair ``key-values'' pair of the Result object is totally
disregarded. The use of arguments 4 and 5 may allow the modification of
Results expressed in a user or projected coordinate system.
More information on the transformation of coordinate systems is given in
section IX.B.4.
This method can be used with Real Results as well as with Complex Results.
I.4.5.8 ``modifyPositionRefCoordSys''
``modifyPositionRefCoordSys'' is used to modify the reference coordinate
system wrt which vectorial Results corresponding to
coordinates are expressed. The Results must be vectorial.
The method returns nil (no new Result object is created) and takes
two arguments:
A DataBase object.
An integer object corresponding to the index of the coordinate
system to which one switches. This index must be >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''
The 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:
An Array of Real values containing the factors of the linear
combination.
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
Five elementary operators on Result objects have been defined. Also,
their corresponding assignment method have been defined. Unless otherwise
specified, in the examples given below,
,
and
are Result objects.
However the second operand
of the addition, substraction and
multiplication operators can be replaced by:
A real value. Then the operation on all the data values of the
``Result'' operand is performed with the real operand.
An Array of three real value. Then the operation is performed for
all the data values of the ``Result'' operand with the corresponding
constant vector operand.
An Array of three Arrays of three real value each. Then the
operation is performed for all the data values of the ``Result'' operand
with the constant matrix operand. Note that the matrix is symmetrized
prior to performing the operation.
For the division operation,
can be replaced by a real argument, but not
by a vector or a matrix. For the exponentiation operator, the two Results must
be scalar.
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
is defined according the following rules:
For a scalar Result
, the cId is always set to -9999 (Result
not associated to a coordinate system).
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.
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 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:
In the previous expression, the Results
and
must have the same
tensorial order. Of course, the returned
object is also of the same
tensor order as
and
.
This operator works with Complex Result operators as well as with Real
Result operators. However, if one operator is a Complex Result, the
other operator cannot be a Real Object, or a Vector (Array of Real
objects), or a Matrix (Array of Arrays of Real objects).
I.4.6.2 Substraction operator
The substraction operator can be used as follows:
In the previous expression, the Results
and
must have the same
tensorial order. Of course, the returned
object is also of the same
tensor order as
and
.
This operator works with Complex Result operators as well as with Real
Result operators. However, if one operator is a Complex Result, the
other operator cannot be a Real Object, or a Vector (Array of Real
objects), or a Matrix (Array of Arrays of Real objects).
I.4.6.3 Multiplication operator
The multiplication operator can be used as follows:
The meaning of this operation depends on the tensorial orders of
and
. The various possibilities 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 meaning of the operation.
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
Complex Results are partially supported by the multiplication operator.
We list below several characteristics of the operator:
When the two operands are Result objects, both the operands must
be in Real format.
The first operand can be a Real object or a Result object (with
Real or Complex values). However, this first operand can never be
a Complex object.
Only the second operand can be a Complex object.
I.4.6.4 Division operator
The division operator can be used as follows:
In the last expression
can have any tensorial order. The tensorial order of the returned
Result
is identical to the tensorial order of
. The argument
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.6.5 Exponent operator
The exponentiation operator can be used as follows:
In the last expression
must be a scalar Result. The tensorial order of the returned
Result
is identical to the tensorial order of
. The argument
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 two following expressions are equivalent:
z=x**y
z=Post.pow(x,y)
I.4.7 ``calcResultingFM'' method
This is a class method used to estimate the total force and
moment corresponding to a distribution of forces and moments on several
points. The method has five arguments:
A DataBase object containing the model used to calculate the total
forces and moments.
A first Result object corresponding to the vectorial forces.
A second Result object corresponding to the vectorial moments.
An object corresponding to the coordinate system in which
results and position of recovery point are expressed. If the argument
is an integer, it must correspond to the index of a CoordSys object
defined in the dataBase. The argument can also be a CoordSys object,
but its definition must refer a coordinate system defined in the
dataBase.
The last argument is 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.)
Note that the last argument is optional. If it is omitted, the method
assumes that the recovery point is located on the origin of the coordinate
system.
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 (
). 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.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 indifferrently 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.
I.4.8.4 Extractions from Complex Results
Four methods produce Real Results from Complex Results by extracting the
appropriate components:
``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 do 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 correspond to a rotation applied to the Result before extracting the
Real or Imaginary component Result. 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:
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).
A first Result object that will correspond to the real or
magnitude components of the assembled Result.
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:
The 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:
The first element corresponds to the elemId.
The second element corresponds to the nodeId of the key.
The third element corresponds to the layerId of the key.
The fourth element corresponds to the subLayerId of the key.
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.
The other elements are real values corresponding to the components
(1, 3 or 6 values for a scalar, vectorial
or tensorial Result respectively). For the precise
meaning of the returned value corresponding to coordinate system, see also
section I.4.1.2.
The method may have 5, 4, 3, 2, 1 or no argument. The arguments correspond
to the type of the Array elements corresponding to elemId, nodeId, layerId,
subLayerId or coordSysId. In the returned Array, these elements may be of
String or Integer types. Correspondingly the arguments are Strings the value
of which can be "int", "string" or any other String. If any other String is
used as argument (for example a void string), the default Integer or String
type elements are returned.
For element, node and layer ids, the negative values correspond to
``special'' values. (See
Tables I.4.2 to
I.4.4.)
Table I.4.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 between the ``each''
iterator and the getData method is that the key and values elements are
separated into two Arrays in the block. So the iterator is to be used
as follows:
strain.each("int","int","int") do |key,values|
...
end
...
strain.each("int","int","string","string") do |key,values|
...
end
Note that, as the ``each_key'' and ``each_values'' iterators
return Arrays, one can indifferently recover an Array argument, or its
elements in the arguments of the block that follows the iterator.
For example, in the following lines:
stress.each_key do |stressKey|
...
end
``stressKey'' is an Array of three elements. However in the
following lines:
stress.each_key("int","int","int") do |elemId,nodeId,layerId|
...
end
the arguments correspond to the different identifiers of
the Result key.
I.4.12 Other methods
One gives here a list of methods that do not fit in any category listed
above.
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.
This method is used for printing the Result object.
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.
userManual.ResKeyList.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
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 3 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
Result ResKeyList.
``extractGroup'' returns a Group object containing the elements and
nodes that are referenced 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.3.1 ``renumberLayers''
``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
and
are two ResKeyLists, then
. (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.
Actually, the ``each_key'' iterator of ResKeyList class is identical to the
``each_key'' iterator of Result class.
I.5.6 ``getData''
The method returns an Array of Arrays containing the data stored in a
ResKeyList object. The returned Array may actually be considered as a
two-dimensional Array with as many lines as there are pairs of keys in the
ResKeyList object. Each line of the Array contains four elements:
The first element corresponds to the elemId.
The second element corresponds to the nodeId of the key.
The third element corresponds to the layerId of the key.
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.
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.
userManual.Post.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
Four methods of ``Post'' Module allow to manipulate the information,
warning and error messages issue by FeResPost:
``openMsgOutputFile'' opens a 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 FeResPost messages.
``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 equivalent to ``z=x.deriveDyadic("pow",y)''.
z=Post.vectProduct(x,y) is equivalent to
``z=x.deriveDyadic("vectProduct",y)''.
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. Both Results must be scalar. 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. Both Results must be scalar. 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 corresponding key is found in the two Result arguments.
``Post.min'', ``Post.max'' and the `Post.merge'' methods are an exception:
if a given key is found in only one of the two argument it is inserted in
the new Result.
I.6.4 ``Operator'' methods
Four ``operator'' methods are defined in the ``Post'' module:
``opAdd'', ``opSub'', ``opMul'' and ``opDiv''. These four methods
correspond to the four operators ``+'', ``-'', ``*'' and ``/''. These four
methods have the following characteristics:
They have two arguments, the two operands.
The second argument must be a Result object.
The first argument can be a Result, a Float or and Array.
If the first argument is an Array, it must correspond to an Array
of 3 Float objects, or be an Array containing 3 Arrays of 3 Float
objects (
matrix).
These four methods have been defined to allow the use of FeResPost
ruby extension without modifying standard classes like ``Float'' and
``Array''.
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:
A String corresponding to the name of the session file.
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:
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:
The first argument of the method is a String containing the name of
the output session file.
The second argument if the list of Groups. This can be a Hash
similar to the one produced by method ``Post::readGroupsFromPatranSession'',
of 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.
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 verbosity.
``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 reading finite element models, and accessing Results in disk files.
I.6.7 Conversion of CLA idfiers
Two methods are defined to convert CLA identifiers to Strings, or Strings to CLA
identifiers. (See chapter II.0 for the notion of identifier.) The
two methods are defined in the ``Post'' Module:
``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.7 Modification of Standard classes
Two standard classes may also be
modified in FeResPost: the ``Float'' class and the ``Array'' class; the
operators are modified in such a way that the second operand may be a
``Result'' object. If the second operand is not a Result object, the default
version of the operator is called.
Table I.7.1 summarizes
the modifications in these classes.
Practically, the modification of standard classes is done in ruby file
``modifStdClasses.rb''. Until version 3.2.7 of FeResPost, the modification was
done in the compiled library. Now the fact that the modification of standard
classes is done with ruby statements allows the user to cancel these modifications,
for example by erasing the corresponding lines in the ``FeResPost.rb'' file of the
distribution. The file would then look as follows:
if (RUBY_PLATFORM.include?("win")) then
require "FeResPost.dll"
else
require "FeResPost.so"
end
#require "modifStdClasses"
STDOUT.printf("End \"FeResPost\" module initialization.\n")
STDOUT.printf("\n\n")
STDOUT.flush
The reason why the modification of standard classes is displaced
into a ruby source file rather than in the compiled part of the extension is that
one tries to maintain the compiled library in line with the COM component. Moreover,
it is not very good practice to modify standard classes in a programming language.
I.7.1 Operators in modified standard classes
The two classes that are modified are ``Float'' and ``Array'' classes. In each case,
when an operator is called, the corresponding ``Operator'' method in ``Post'' Module
is called. for example, the two following statements are equivalent:
z=x+y
z=Post.opAdd(x,y)
Actually, this is true only if
is an object of the class ``Float'' or ``Array''.
Practically, the modification of standard classes is done in two steps:
An alias is created for the old version of the operator.
A new operator is created. In the definition of the operator,
one tests the second operand to call the appropriate version of the
operator, which may be the old one.
The following lines illustrate the modification for the addition operator
of the ``Float'' class.
class Float
alias _FeFesPost_old_opAdd +
...
def +(second)
if second.class==Result then
return Post.opAdd(self,second)
else
return self._FeFesPost_old_opAdd(second)
end
end
...
end # Float
II. Composite Reference Manual
II.0 Introduction
Four classes specific to Classical Laminate Analysis calculations have been
defined in FeResPost module:
The ``ClaDb'' class allows the definition of composite
databases used to store the definition of composite materials, laminates and
loadings. This class is presented in Chapter 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 compatible with several software
(ESAComp or finite element solvers...). As entities manipulated
by these software are sometimes identified by integers, sometimes by strings and
sometimes by both an integer and a String, this peculiar way to identify the
entities in a ClaDb object had to be developed. For example, if a ClaLam object
has been stored in a ClaDb, it can be retrieved with:
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 example, 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 presented widely in literature. The programmer based its
developments on [Gay97]. For the in-plane and flexural
parts of laminate response, the approximations done in the development of
equations are common to what has been found in the rest of literature. On the
other hand, few references have been found about the out-of-plane shear
behavior of laminates. In [Gay97], this aspect of laminate
analysis is presented with a few assumptions. For example, Gay assumes a
mirror symmetry of the laminate. This is obviously not a characteristic of all
laminates. Therefore, the out-of-plane shear responses calculated by composite
classes should be used with care.
More information about the conventions used for FeResPost composite
calculations are given in Chapter II.1.
II.0.1 Remarks and limitations
One presents below a list of limitations, which should not be considered as
exhaustive:
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.
As the composite classes are under development, modifications of
ruby functions related to the composite classes are still possible (and
likely).
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 loading. Among other-things,
one explains how the ply stresses and strains are calculated.
Section II.1.9 is devoted to the calculation
criteria available in FeResPost.
Section II.1.12 is devoted to a presentation of
the units of many of the quantities introduced in this Chapter.
II.1.1 Conventions
Figure II.1.1 represents some of the conventions
used for the definition of laminate in FeResPost. The laminate coordinate
system is defined in such a way that the
axis is perpendicular to
laminate surface and points from bottom to top surface.
and
vectors
are parallel to the laminate plies. Plies are numbered from the bottom to
the top surface. If
is the index of a ply, one considers that it is
limited by
coordinates
and
. The origin of the
coordinate system is located at mid laminate thickness so that if
is
the laminate total thickness and the laminate has
plies, top surface of
the laminate is located at
and bottom surface at
.
(The plies are numbered from 1 to
.)
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.
,
and
are
the ply axes;
,
and
are the laminate axes. Of course, because only
2D laminates are considered here, one has always
. 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
to axis
. If the angle is
, the first ply axis 1 is
parallel to the first laminate axis
.
Figure II.1.2:Conventions for the orientation of plies in the
laminate.)
II.1.2 Rotation in XY plane and algebraic notations
One common operation in classical laminate analysis is to rotate vectors,
tensors and matrices. One summarizes here the operations one uses in the
rest of this Chapter and in FeResPost. This rotation is represented in
Figure II.1.3.
Figure:Rotation of angle
around the origin in
plane.
As the Cauchy stress tensor is symmetric, expression
(II.1.4) is more conveniently written
in a matricial form as follows:
(II.15)
The same expression applies to the components of the strain tensor, which
is also symmetric:
However, unfortunately, the classical laminate analysis is universally
written using angular shear components for the strain tensor:
Using the angular components, the matricial expression to be used for
the rotation becomes:
(II.16)
An interesting aspect of the transformations (II.1.5)
and (II.1.6) is that one can apply the transformation
separately on sub-groups of components:
For the in-plane components, one uses the following
transformations:
(II.17)
(II.18)
For the out of plane shear, the transformation is:
(II.19)
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
or
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:
.
The inverse of relation (II.1.7) is obviously;
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
matrix contains all the elastic
coefficients defining the material:
(II.126)
One shows that, because the peculiar choice of angular strain tensor
components, the matrix
containing the
elastic coefficients is symmetric. Therefore, the matrix has only
21 independent coefficients.
is the stiffness
matrix of the material.
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
and
respectively.
Note that shear components of these two tensors are angular components.
Practically, it does not matter much as most materials have zero shear
components for CTE or CME tensors.
is the
compliance matrix of the material. Obviously
. 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
and
respectively.
denotes the
out-of-plane tensile/compressive modulus.
Correspondingly, one defines shear moduli noted
,
and
.
In general six Poisson coefficients can be defined:
,
,
,
,
,
. However,
these coefficients are not independent. The relations
allow to eliminate the coefficients
,
and
so that only the three Poisson coefficients
,
and
have to be introduced when defining a
material.
The constitutive equation of an orthotropic material is given by
For an isotropic material, the definition of
and either
or
is sufficient to characterize the material. Then one has:
,
and
satisfy the following relation:
Finally, one introduces shorter notations that allow to rewrite
expressions (II.1.26) and
(II.1.27) respectively as follows:
(II.127)
(II.128)
One introduces also the ``Mechanical Strain Tensor'' estimated as
follows:
(II.129)
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''.
One considers the properties of the ply in a plane parallel to the
laminate. Then the constitutive equation (II.1.28)
reduces to:
(II.130)
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:
(II.131)
One introduces in (II.1.33) the material
in-plane compliance matrix
. In order to
avoid too complicated notations, one uses the same notations as for the
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 (
,
,
,
,
,...
In (II.1.34) one introduces
the in-plane stiffness matrix
.
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:
This leads to the new expression in laminate axes:
where one introduces new notations for in-plane ply properties rotated by
an angle
(in laminate axes):
(II.133)
(II.134)
(II.135)
(II.136)
(II.137)
(II.138)
When a matrix is transformed as in
(II.1.35) or a vector as in
(II.1.36), one says that they are rotated
with
rotation matrix.
One makes developments similar to those in the previous section. The
out-of-plane shear constitutive equations are written as follows:
(II.139)
(II.140)
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:
Then, one makes consecutive transformations of relations
(II.1.41) as follows:
where one introduced:
One says that tensor
is rotated by matrix
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:
II.1.4 Thickness and mass of laminate
The total laminate thickness is the sum of the thickness of each of its
plies:
Correspondingly the surfacic mass is given by:
And the laminate average density is:
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 developements that lead to these results are needed. In
this section, the different equations are written in laminate axes and the
corresponding indices are noted
and
.
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:
Bending moment tensor:
Average deformation tensor:
Curvature tensor:
(II.141)
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:
One defines below the different matrices and vectors introduced in
these equations:
Matrix
is a
matrix
corresponding to the in-plane stiffness of laminate. Its components
are calculated as follows:
Matrix
is a
matrix
corresponding to the flexural stiffness of laminate. Its components
are calculated as follows:
Matrix
is a
matrix
corresponding to the coupling between flexural and in-plane behavior
of the laminate. It is calculated as follows:
All the new matrices and vectors are obtained by summation of the
ply contributions. In order to obtain the ply stiffness matrix in
laminate axes
and the ply thermo-elastic CTE
coefficients in thermo-elastic axes
,
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
,
and
are obtained by inversion of the
matrix:
(II.142)
Then the average laminate strain and its curvature tensor can be
calculated as follows:
One often calculates equivalent moduli corresponding to the calculated
stiffness matrices
and
. 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:
Equivalent in-plane moduli and Poisson ratios are then given by:
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
is not zero.)
The laminate in-plane engineering constants with
suppressed curvature are calculated as follows:
Similarly, equivalent flexural moduli and Poisson ratios
can be calculated. One notes the following relation:
If there is no coupling between laminate flexural and membrane properties
Generally, the ``no-coupling'' behavior is assumed (see for example
section II.1.6). Therefore, one writes simply:
II.1.6 Out-of-plane shear of laminate
One presents one version of the out-of-plane shear theory for laminates based on
information found in Chapter 13 of [Sof04a]. Only, one presents
here a more general version of the calculation that takes
and
components
of the out-of-plane shear stress into account at the same time.
In Chapter 13 of [Sof04a] one considers the equilibrium in
direction
of a small portion of the material (Figure
II.1.4) of lengths
and
respectively:
(II.143)
Similarly, the equilibrium of a portion
of the full laminate is given
globally by the expression:
(II.144)
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
and
. All the
developments are based on the local
equilibrium relation.
In this document, a more general presentation of the out-of-plane shear
behavior of laminates is done. The
and
components of in-plane local
equilibrium are written as follows:
(II.145)
(II.146)
Correspondingly, a global equilibrium is expressed by the two equations:
(II.147)
(II.148)
Those equations shall be developed and will ultimately allow the calculation
of
and
from the global shear
and
.
In most expressions below, the components of tensors are expressed in
laminate axes. Therefore, the ``lam'' underscore is often added to the
different quantities used in the equations.
First, one calculates the components of Cauchy stress tensor. However, a few
simplifying assumptions shall be done. The strain tensor components
are calculated from the laminate average strain tensor and curvature as
follows:
(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:
One then writes a simple expression of the in-plane laminate deformation
tensor:
Then, the components of Cauchy stress tensor are given by:
(II.149)
In this last expression, the
matrix
corresponds to the plies in-plane moduli
expressed in laminate axes. It depends on
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
and
:
At this point, one no longer needs to assume a dependence of the gradient
of bending moments wrt
and
. The same is true for the gradient of
Cauchy stress tensor. One also introduces a new notation:
Then, the components of Cauchy stress tensor gradient are obtained from
the components of bending moments gradient with the following expression:
Note that the global equilibrium equation
(II.1.49) and
(II.1.50) do not contain the components
and
of the bending moments tensor. Similarly, the
local equilibrium equations do not contain the components
and
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:
(II.151)
Similarly, one writes:
(II.152)
The substitution of (II.1.52) and
(II.1.54) in (II.1.53)
leads to the following expression:
One would like to eliminate the four
and
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:
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:
The choice
gives more symmetry to the relation between
and
.
This choice leads to:
The choice
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:
(II.153)
(II.154)
is a
matrix that relates the
out-of-plane shear stress components partial derivatives wrt
to the out-of-plane shear force components:
(II.155)
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, Expression
(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, estimates 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
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
depends on
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
, one has:
in which the components of the two matrices
and
are constant. Similarly one can write a polynomial expression for
if one splits the definition by plies:
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:
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
and
. This assumption leads to the
following expression:
In expression (II.1.60), one introduced
new symbols that are calculated as follows:
Note that the expression above involve the a priori unknown quantity
. To calculate this expression,
one uses the continuity of
across
ply interfaces:
This relation corresponds to the continuity of out-of-plane shear stress
at ply interfaces. One develops the relation as follows.
(II.158)
The last line of this development allows to calculate recursively the
components of
from bottom ply to top
ply. For bottom ply, the condition
leads to the following expressions:
Then, it becomes possible to calculate recursively the
matrices.
One checks easily that the condition
ensures also that
. Indeed, one has:
The last line of previous equation contains twice the integral of
along the laminate thickness. One develops
this integral as follows:
On the other hand, equation (II.1.44) allows to write:
(The ``lam'' subscript has been omitted for shortness sake.) The
identification of the right upper corner of the last expression with the
integration of
along the laminate thickness
shows that this integral must be zero. Consequently, one also has:
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:
To this relation corresponds a relation between the average out-of-plane
shear strains and the out-of-plane shear force:
In the definition of loadings, the out-of-plane components of shear force
can be replaced by average out-of-plane shear stress
. Then
the conversion between these two types of components is done simply by
multiplication or division by laminate total thickness
:
One introduces notations that simplifies the writing of equations:
In these expressions the
subscripts can be replaced by a symbol specific
to the coordinate system in which the components of the vector are expressed
(for example "load", "ply", "lam"...).
The components of matrix
are easily
obtained from the orientation and material of plies. The components of
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:
(II.159)
similarly, the surfacic energy can be estimated from the out-of-plane shear
global equation:
(II.160)
As there is only one surfacic energy,
and
Here again, the integration can be calculated ply-by-ply. More precisely,
one calculates on ply
:
One notes the stiffness matrix
and the
compliance matrix
. 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:
in which the
matrix has first been rotated into
the appropriate axes.
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.
Calculate laminate in-plane and flexural properties. This is
necessary because one needs the matrices
and
to calculate out-of-plane shear properties.
One initializes the
matrix
to zero.
Then for each layer
with
, one
performs the following sequence of operations:
One estimates the
matrix of in-plane stiffness
coefficients in laminate axes
. For other
calculations, one also need properties like the laminate thickness
and the positions
of different layer interfaces.
This matrix is used to calculate the two matrices
and
. (See
section II.1.6.3 for more details.)
One has:
Then, one calculates two other
matrices
and
. (See
section II.1.6.3.) One has:
Then one calculates the
matrices:
As the expression of
is recursive, one needs
another expression for the first value. The expression is:
These matrices allow to calculate the out-of-plane shear stress from the
global out-of-plane shear force:
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:
Then, one has simply:
One stores a
matrix
for each station through
laminate thickness where out-of-plane shear stress might be requested.
Actually it is done at top, mid and bottom surfaces in each ply. This
means that
matrices
are stored in the
ClaLam object.
One calculates the
matrix. (See the end of section II.1.6.5
for the expressions to be used.) Then to
, one adds one term:
At the end of the loop on layers, the shear stiffness matrix
is calculated by inversion of
.
II.1.7 CTE and CME calculations
One assumes a linear dependence of the temperature on the location through
the laminate thickness:
(II.162)
Similarly, the water uptake depends linearly on
:
(II.163)
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:
In laminate axes, the equation is rewritten:
One substitutes in the equation the assumed temperature profile:
The corresponding laminate in-plane force tensor is obtained by integrating
the Cauchy stress tensor along the thickness:
In the previous expression, two new symbols have been introduced that
are calculated as follows:
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:
Using relation (II.1.44), the previous expression
is reversed as follows:
In the last expression, four new quantities can be identified:
Starting with the out-of-plane shear constitutive equation
(II.1.42) and of the expression defining
the out-of-plane shear force vectors
one makes developments similar to those of
section II.1.7.1 and defines the following
quantities:
Finally, the full set of constitutive equation written with
stiffness matrices looks like:
The two previous expressions are inversed as follows:
II.1.8 Calculation of load response
One always considered a decoupling of in-plane and flexural of laminates
on one side, and the out-of-plane shear of laminates on the other side.
These two aspects are discussed in
sections II.1.8.1
and II.1.8.2 respectively.
II.1.8.1 In-plane and flexural response
Beside thermo-elastic or hygro-elastic loading, the composite classes of
FeResPost allows the definition different types of mechanical loads:
By specifying normal forces
and bending moments
.
By specifying average strains
and curvatures
.
By specifying average stresses and flexural stresses.
The type of loading is specified component-by-component. This
means that a single loading may have some components imposed as normal
forces and bending moments, with other components imposed as average
strains, and other components as average stresses or flexural stresses.
The mechanical part of loading is also characterized by a direction
wrt laminate axes. The subscript ``load'' indicates that the
components are given in loading axes. One explains below how the laminate
response is calculated.
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:
in which
is the laminate thickness.
The mechanical part of loading is characterized by a direction
wrt laminate axes. This direction is given by an angle
.
In order to have laminate properties and loading given in the same
coordinate system, the laminate stiffness matrices and CTE vectors
are calculated in this new coordinate system. (It is more convenient
for the elimination of components imposed as average strains or
curvatures.) More precisely, the stiffness matrices and CTE vector
are rotated with the following expressions:
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:
(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
Now, one considers a case in which one component of vector
is constrained to be a certain value. For example
.
This equation replaces the
equation of the system:
The unknown
can be easily eliminated from the linear
The first line above corresponds to a new linear system of
equations with
unknowns. The set of two lines define the algebraic
operations that are performed in FeResPost when one imposes an average
strain or curvature component.
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
and
are known in loading axes.
The normal forces and bending moments are then calculated
in loading axes with the following equations:
(The CTE and CME related terms are optional.)
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:
and
.
Similarly, the normal forces and bending moments components are
re-expressed in laminate axes:
For each ply, one calculates (if required) the stresses and
strains as follows:
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
:
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.
At the different stations through the thickness at
which strains and stresses are required, the strain
components are calculated with:
In FeResPost
may have the values
,
,
. Then the stress components are
given by:
(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:
This version of the strain tensor is called the ``Mechanical Strain
Tensor'' or ``Equivalent Strain Tensor''.
This is the version of the strain tensors that is used for the strain failure criteria.
Note however that a ``Total Strain'' version of the criteria is proposed as well.
At the end of the calculations, the laminate object which has been
used to perform those calculations stores a few results:
The average strain and curvature of the laminate in laminate
axes
and
.
The laminate in-plane membrane forces and bending moments
in laminate axes
and
.
The ply results in ply axes
,
and
,
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:
The first step of the calculation is to resolve the loading in
out-of-plane shear forces in loading axes
(or
). 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:
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. One distinguishes three cases:
If out-of-plane shear forces are specified, no operation is
needed to obtain them.
If out-of-plane average shear strains are specified, they are
converted into out-of-plane shear forces with the following relation:
(The CTE and CME related terms are optional.)
If an hybrid loading is defined, like
One first calculates the matrix
by inversion of
. Then one solves
the linear system of equations:
in which the appropriate constraints have first been applied for the
components specified as forces. (Here again, the CTE and CME related
terms are optional.)
At this stage, whatever the type of loading applied to the laminate,
is known. Then, if necessary,
is then simply calculated with
expression (II.1.100) written
in loading axes:
(The CTE and CME related terms are optional.) Once
and
are known, the corresponding
loading in laminate axes is obtained with:
The ply out-of-plane shear stress components are calculated at
the different requested locations by:
in which the matrix
is
relative to the station at which the stress is requested.
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:
(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
.
Consequently,
and
are generally
not zero. These strain tensor components can be estimated from
(II.1.27):
II.1.9 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:
(II.190)
In the rest of this section all the allowables used in failure
criteria have positive values. Even the compressive allowables are
.
Table II.1.1 summarizes the criteria available
in FeResPost. For each criterion, the Table provides:
A String corresponding to the argument that identifies the selected
criterion when derivation is asked.
A description of the type of material (metallic or isotropic,
unidirectional tape, fabric,...).
A reference to the section in which the criterion is presented
and discussed.
Specification whether an equivalent stress for this criterion can
be derived in FeResPost or not.
One specifies whether a failure index can be derived with FeResPost.
One specifies whether a reserve factor can be calculated with
FeResPost.
Table II.1.1:Summary of failure criteria available in FeResPost and information
on what can be calculated.
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:
then a test is done on the calculated value:
Several failure theories discussed below are obtained by expressing the
coefficients in the expressions above by expressions depending on the
material allowables. Also for the Tsai-Wu criteria discussed in
section II.1.9.14 and
II.1.9.15, the parameters
are directly
characterized for the material.
Note that the 2D criteria defined in this section often correspond to the
failure criteria defined in ESAComp.
Table II.1.2:Correspondence between the ESAComp failure criteria and the
failure criteria defined in CLA module.
Using the stress tensor components a scalar equivalent shear
stress is given by:
(II.191)
This equivalent shear stress allows to define a Tresca failure index
as follows:
(II.192)
and the reserve factor is given by:
(II.193)
This criterion is referred to as ``Tresca2D'' criterion in FeResPost.
II.1.9.2 Von Mises criterion (2D)
Using the stress tensor components a scalar equivalent shear
stress is given by:
(II.194)
The corresponding failure index is:
(II.195)
and the reserve factor is given by:
(II.196)
This criterion is referred to as ``VonMises2D'' criterion in FeResPost.
II.1.9.3 Von Mises criterion (3D)
Using the stress tensor components a scalar equivalent shear
stress is given by:
(II.197)
As for the 2D version, the corresponding failure index is given by
II.1.107 and the reserve factor by
II.1.108.
This criterion is referred to as ``VonMises3D'' criterion in FeResPost.
II.1.9.4 Maximum stress criterion
The failure index is calculated as follows:
(II.198)
in which the
and
allowables depend on the sign of
and
respectively. (Generally, tensile and compressive allowables
are different for orthotropic materials.)
The reserve factor is calculated as follows:
(II.199)
This criterion is referred to as ``MaxStress'' criterion in FeResPost.
II.1.9.5 Maximum stress criterion (3D)
The failure index is calculated as follows:
(II.1100)
in which the
,
and
allowables depend on the sign of
,
and
respectively. (Generally,
tensile and compressive allowables are different for orthotropic
materials.) The reserve factor is calculated as follows:
(II.1101)
This criterion is referred to as ``MaxStress3D'' criterion in FeResPost.
II.1.9.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:
(II.1102)
in which the
and
allowables depend on the sign of
and
respectively.
The reserve factor is calculated as follows:
(II.1103)
This criterion is referred to as ``MaxStrain'' criterion in FeResPost.
FeResPost proposes a second version of the criterion where the ``total'' strain tensor
is used instead of the mechanical strain tensor
. This version of the
criterion is referred to as ``MaxTotalStrain'' criterion in FeResPost.
II.1.9.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:
(II.1104)
in which the
,
and
allowables depend on the sign of the corresponding
mechanical strain tensor component.
The reserve factor is calculated as follows:
(II.1105)
This criterion is referred to as ``MaxStrain3D'' criterion in FeResPost.
FeResPost proposes a second version of the criterion where the ``total'' strain tensor
is used instead of the mechanical strain tensor
. This version of the
criterion is referred to as ``MaxTotalStrain3D'' criterion in FeResPost.
II.1.9.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:
(II.1106)
in which the
and
allowables depend on the sign of
and
respectively.
(The criterion is calculated from the mechanical
or equivalent strain tensor components.)
The reserve factor is calculated as follows:
(II.1107)
This criterion is referred to as ``CombStrain2D'' criterion in FeResPost.
FeResPost proposes a second version of the criterion where the ``total'' strain tensor
is used instead of the mechanical strain tensor
. This version of the
criterion is referred to as ``CombTotalStrain2D'' criterion in FeResPost.
II.1.9.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:
(II.1108)
Here again, the allowables
and
depend on the signs of
and
respectively. The Tsai-Hill failure
index depends quadratically on the different components of the
stress tensor. Therefore, the reserve factor is calculated as
follows:
(II.1109)
This criterion is referred to as ``TsaiHill'' criterion in FeResPost.
II.1.9.10 Tsai-Hill criterion (version b)
This criterion is very similar to the one described in
section II.1.9.10. It differs by the fact that
only the tensile allowables
and
are considered for the calculations.
The calculation of reserve factor is as for the more classical Tsai-Hill
criterion (II.1.121). This criterion is
referred to as ``TsaiHill_b'' criterion in FeResPost.
II.1.9.11 Tsai-Hill criterion (version c)
This criterion is very similar to the one described in
section II.1.9.9. The criterion has a failure
index calculated as follows:
(II.1110)
The criterion differs from the previous one by the fact that the allowable
is used in the calculation. This
allowable is set to
or
depending on the sign of
.
The calculation of reserve factor is as for the more classical Tsai-Hill
criterion (II.1.121). This criterion is
referred to as ``TsaiHill_c'' criterion in FeResPost.
II.1.9.12 Tsai-Hill criterion (3D)
The Tsai-Hill criterion is a quadratic criterion. The 3D version of this
criterion has a failure index calculated as follows:
The allowables
,
and
depend on the signs of
,
and
respectively. The Tsai-Hill failure index
depends quadratically on the different components of the stress tensor.
The reserve factor is calculated as follows:
(II.1111)
This criterion is referred to as ``TsaiHill3D'' criterion in FeResPost.
II.1.9.13 Tsai-Hill criterion (3D version b)
This criterion is very similar to the one described in
section II.1.9.13. It differs by the fact that
only the tensile allowables
,
and
are
considered for the calculations.
The calculation of reserve factor is as for the more classical Tsai-Hill
criterion (II.1.124). This criterion is
referred to as ``TsaiHill3D_b'' criterion in FeResPost.
II.1.9.14 Tsai-Wu criterion
The Tsai-Wu criterion is a quadratic criterion. The 2D version
of this criterion has a failure index calculated as follows:
In this expression,
is a material parameter to be obtained
by characterization tests. This parameter must satisfy the following
relation:
Its units are, for example,
. Sometimes the
corresponding dimensionless parameter is used instead:
This dimensionless parameter must satisfy the relation:
The value
corresponds to a generalized
Von Mises criterion. The value
leads to the Hoffman criterion discussed in
section II.1.9.16.
In some of the terms of expression (II.1.125)
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:
(II.1112)
This criterion is referred to as ``TsaiWu'' criterion in FeResPost.
II.1.9.15 Tsai-Wu criterion (3D)
The 3D version of Tsai-Wu failure criterion leads to the following
expression of the failure index:
The values of
and
are
submitted to the same limitations as
in
section II.1.9.14. The RF calculation is done as
follows:
(II.1113)
This criterion is referred to as ``TsaiWu3D'' criterion in FeResPost.
II.1.9.16 Hoffman criterion
The Hoffman criterion is very similar to the Tsai-Wu criterion.
Only the last term of failure index is different:
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:
(II.1114)
This criterion is referred to as ``Hoffman'' criterion in FeResPost.
II.1.9.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:
(II.1115)
in which the allowables
and
depend on the signs of
and
respectively.
The reserve factor is simply given by:
(II.1116)
This criterion is referred to as ``Puck'' criterion in FeResPost.
A modified version of Puck criterion is defined as
follows:
(II.1117)
The reserve factor is calculated as follows:
(II.1118)
The calculation of failure index is based on the calculation of the
reserve factor:
(II.1119)
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.
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:
(II.1120)
The calculation of reserve factor is done as for version ``b'' of Puck
criterion, but one uses a modified expression for
parameter:
This criterion is referred to as ``Puck_c'' criterion in FeResPost.
II.1.9.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
a quadratic function is used to estimate
fiber reserve factor:
Otherwise, a linear expression is used:
The calculation of matrix failure is slightly more complicated.
If
one has simply:
Otherwise a quadratic equation must be solved:
Finally, the reserve factor is given by:
(II.1121)
Here again, the calculation of failure index is based on the calculation
of the reserve factor:
(II.1122)
in which the safety factor used in the calculation of the RF
is 1.
The criterion presented above is referred to by ``Hashin'' criterion in FeResPost.
Correspondingly, one defines version ``Hashin_b'' in which only the
fiber failure is checked and ``Hashin_c'' in which only the matrix
failure is checked. (These correspond to the values
and
calculated above.)
II.1.9.19 Hashin criteria (3D)
A 3D version of the criterion defined in
section II.1.9.18 is defined as follows
If
a quadratic function is used to estimate
fiber reserve factor:
Otherwise, the following linear expression is used:
The calculation of matrix failure is slightly more complicated.
If
one has:
Otherwise the failure criterion is:
For that case, one successively calculates:
Finally, the reserve factor is given by:
(II.1123)
Here again, the calculation of failure index is based on the calculation
of the reserve factor:
(II.1124)
in which the safety factor used in the calculation of the RF
is 1.
The criterion presented above is referred to by ``Hashin3D'' criterion in FeResPost.
Correspondingly, one defines version ``Hashin3D_b'' in which only the
fiber failure is checked and ``Hashin3D_c'' in which only the matrix
failure is checked. (These correspond to the values
and
calculated above.)
II.1.9.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:
(II.1125)
The allowable
depends on the sign of
. The reserve factor is calculated as follows:
(II.1126)
This criterion is referred to as ``YamadaSun'' in FeResPost.
II.1.9.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:
(II.1127)
The allowables
and
depends on the signs of
and
respectively. The reserve factor is calculated as follows:
(II.1128)
This criterion is referred to as ``YamadaSun_b'' in FeResPost.
II.1.9.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:
(II.1129)
The allowable
depends on the sign of
(Generally, the compressive allowable is significantly
smaller than the tensile one). The honeycomb material is generally defined
in such a way that the allowable
is in
ribbon direction (longitudinal allowable) and
is the transverse allowable
.
The reserve factor is calculated as follows:
(II.1130)
This criterion is referred to as ``Honey3D'' in FeResPost.
II.1.9.23 Honeycomb shear criterion
Depending of the modeling, the component
of Cauchy
stress tensor is sometimes zero. Then a simplified ``shear'' criterion
is often used:
(II.1131)
The reserve factor is calculated as follows:
(II.1132)
This criterion is referred to as ``HoneyShear'' in FeResPost.
II.1.9.24 Honeycomb simplified shear criterion
Sometimes, one simplifies the criterion described in
section II.1.9.23 by using the smallest shear
allowable
. This new criterion is referred to as ``HoneyShear_b''.
As a single allowable is used, an equivalent shear stress can be defined:
(II.1133)
The failure index is then calculated as follows:
(II.1134)
The reserve factor is calculated as follows:
(II.1135)
This criterion is referred to as ``HoneyShear_b'' in FeResPost.
II.1.9.25 Inter-laminar shear criterion
The inter-laminar shear criterion is based on the comparison of inter-laminar
shear stress with resin shear allowable:
(II.1136)
In which the inter-laminar shear stress is a scalar stress calculated as
follows:
The reserve factor is of course:
(II.1137)
This criterion is different from the other criteria in this that it
does not use ply material allowables. Instead, the ply ilss allowable
or the laminate ilss allowable is used.
Note also that FeResPost calculates the inter-laminar shear criterion on
the lower face of plies only.
This criterion is referred to as ``Ilss'' in FeResPost.
The thermal conservation equation in a solid material is written as follows:
(II.1138)
where
is the temperature,
is the heat capacity of the material and
vector
is the heat flux. Note that
and
are used for
transient thermal calculations only. Generally, the heat flux is related to the
gradient of temperature by Fourrier's law:
(II.1139)
where
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.
Two scalar parameters influence the transient thermal behavior of laminates:
the density
and the heat capacity (per unit of mass)
. 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
is a
order tensor. Generally, for an anisotropic material, the
tensor may be written as follows:
The tensor
is symmetric, so that only 6 components must be
defined:
(II.1140)
For an orthotropic material, the previous equations reduces to:
(II.1141)
Then, only three material parameters define the thermal conductivity.
Finally, for an isotropic material the thermal conductivity is defined by a
single parameter
:
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:
and the out-of-plane component
.
Correspondingly, the tensor of thermal conductivity coefficients is separated
into an in-plane conductivity tensor:
and the out-of-plane conductivity
. The ``shear'' components
and
are neglected in the homogenization theory.
(This means that out-of-plane and in-plane conductivities are decoupled.)
The material scalar properties are left unmodified by in-plane rotations.
The same is true for the out-of-plane quantities
and
.
The transformation of components for
and
is noted with the transformation matrices
defined in expressions (II.1.12) to
(II.1.17):
To calculate the laminate in-plane thermal conductivity properties, one
assumes that temperature is constant along the laminate thickness.
Consequently, the temperature gradient does not depend on
. The thermal
flux
however depends on
because the thermal
conductivity does:
(II.1147)
The laminate in-plane thermal conductivity is calculated as follows:
d
d
In the previous equation, one introduced the laminate in-plane
thermal conductivity:
One assumes that out-of-plane thermal flux is constant across laminate
thickness. Then, as thermal conductivity depends on
, so will the
out-of-plane gradient of temperature:
(II.1149)
The integration across the thickness gives the difference of temperature
between upper and lower laminate surfaces:
d
d
In previous expression, one introduced the out-of-plane thermal
resistance:
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:
d
In previous expression, one introduced the surfacic thermal capacity
d
(II.1151)
Note that in Nastran, when a thermal material MAT4 or MAT5
is defined, the density
and the heat capacity per unit of mass
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.)
The moisture conservation equation in a solid material is written as follows:
(II.1152)
where
is the moisture content (for example in [kg/m
]) and vector
is the massic flux of moisture (in [kg/m
s]). When several
materials are present in a structure, as often in laminates, it is more
practical to work with moisture percentage
(in [%w]). The moisture
percentage is related to moisture content by the following expression:
(II.1153)
where
is the moisture coefficient in [kg/(m
%w)].
Generally, the moisture flux is related to the gradient of moisture by
Fick's law, and the moisture diffusion equation can be written:
(II.1154)
here
is the tensor of moisture conductivity coefficients. This
expression is very similar to the equation of thermal diffusion:
The components of
are defined the same way as the
components of
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:
(II.1155)
(II.1156)
As one works with moisture percentages, nothing equivalent to the
laminate thermal capacity
is defined
for moisture.
II.1.12 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
quantitities 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 [
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.
All the other units of FeResPost are obtained by combining these
base units. The most important ones are summarized in Tables
II.1.3, II.1.4 and
II.1.5.
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
as well as the units of coefficients of moisture expansion
.
Table II.1.3:Units of the different quantities related to loading, stresses or load responses.
Quantities
Symbols
Units
Strains
,
or
[L/L] or [-]
Stresses
or
[F/L
]
Curvatures
[1/L]
Forces
or
[F/L]
Moments
[FL/L] or [F]
Temperatures
[T]
Moistures
[W] (always [%w])
Failure indices
[]
Reserve factors
[]
Table II.1.4:Units of the different quantities related to material properties.
Quantities
Symbols
Units
Materials stiffnesses or moduli
,
,
or
[F/L
]
Materials compliance matrices
,
,
[L
/F] ]
Poisson coefficients
[-]
Thermal conductivity
[E/(LT)]
Coefficients of thermal expansion
[L/(LT)] or [1/T]
Moisture conductivity
[1/(Lt)]
Coefficients of moisture expansion
[L/(LW)] or [1/W]
Density
[M/L
]
Heat specific capacity
[E/(MT)]
Coefficients of quadratic failure criteria
[L
/F]
Coefficients of quadratic failure criteria
[L
/F
]
Table II.1.5:Units of the different quantities related to laminate properties.
Quantities
Symbols
Units
Thicknesses
[L]
Membrane stiffness matrix
[F/L]
Membrane-bending coupling stiffness matrix
[F]
Bending stiffness matrix
[FL]
Out-of-plane shear stiffness matrix
[F/L]
Membrane compliance matrix
[L/F]
Membrane-bending coupling compliance matrix
[1/F]
Bending compliance matrix
[1/(FL)]
Out-of-plane shear compliance matrix
[L/F]
In-plane thermal conductivity matrix
[E/(tT)]
Out-of-plane thermal resistance
[L
Tt/E]
Surfacic heat capacity
[E/L
/T]
In-plane moisture conductivity matrix
[1/t]
Out-of-plane moisture resistance
[L
t]
Other units systems can be used with the CLA classes. Each CLA object has an attribute
corresponding to the units system in which all its characteristics are defined.
The units of CLA object can be obtained with ``getUnits'' method that returns a Hash containing
pairs of Strings. The first String describes the kind of dimension: ``L'' for length, ``M'' for mass,
``t'' for time, ``T'' for temperature, ``E'' for energy, ``W'' for moisture and ``F'' for force. The second
String corresponds to one of the unit listed above for the selected quantity.
The units of a CLA object can also be modified by calling ``setUnits'' or ``changeUnits'' methods.
The ``setUnits'' method change the units attributed to an object without modifying 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.
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.
CLA.ClaDb.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
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
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.
``insertLoad'' makes a copy of the ClaLoad argument and
inserts it into the loads collection.
``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 materials, laminates or loads respectively. When an
object is stored into the ClaDb, the key which allows to retrieve the
object is the identifier one attributed to it with the ``Id''
attributes. (See Chapters II.3 to II.5.)
Note that the identifier used to retrieve an object from the ClaDb
must match exactly the key to which the object is associated. For
example, if the identifier of a load is [17,"QS_and_bending"],
then 17 or "QS_and_bending" will not allow to retrieve
a copy of the object. [17,"QS_and_bending"] must be used as
argument of the `getMaterialCopy'' method.
When a ClaLam object is stored into the ClaDb, its properties are
calculated automatically. (Stiffness matrix and
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 ClaMat 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.12. The difference
between the ``setUnits'' and ``changeUnits'' methods is also explained in the
same section.
II.2.5 Saving to or retrieving from a disk file
Presently, three interface functions are defined:
``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 interpreted 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 argument.
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.
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.
CLA.ClaMat.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
The singleton method ``new'' is used to create ClaMat objects. This
method has no argument. (Nor has the ``initialize'' method an argument.)
II.3.2 Identifier and type
Two attributes are defined for the ``ClaMat'' object: ``Id'' and ``Type''.
Five methods allow the manipulation of the identifier of material and
of its type:
``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.
``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.
``clearModuli'' has no arguments and erases all the moduli stored in
a ClaMat object.
``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
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.)
``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.
``clearCTEs'' has no arguments and erases all the CTEs stored in
a ClaMat object.
``insertCTEs'' is used to define different components of the thermal
expansion coefficients. For orthotropic and anisotropic materials,
possible keys are "alfa1", "alfa2", "alfa3", "alfa12", "alfa23" and
"alfa31". For isotropic materials, key "alfa" only can be used.
``fillCTEs'' is used to set material CTEs. This method has the same
arguments as ``insertCTEs'' but differs by the fact that CTEs are
re-initialized before insertion of values.
``clearCMEs'' has no arguments and erases all the CMEs stored in
a ClaMat object.
``insertCMEs'' is used to define different components of the
moisture expansion coefficients. For orthotropic and anisotropic
materials, possible keys are "beta1", "beta2", "beta3", "beta12", "beta23"
and "beta31". For isotropic materials, key "beta" only can be used.
``fillCMEs'' is used to set material CMEs. This method has the same
arguments as ``insertCMEs'' but differs by the fact that CMEs are
re-initialized before insertion of values.
``clearAllowables'' has no arguments and erases all the allowables
stored in a ClaMat object.
``insertAllowables'' is used to add material allowables. The
possible keys are "sc", "st", "ss", "ec", "et", "gs", "s1c", "s1t", "s2c",
"s2t", "s12", "s23", "s31", "e1c", "e1t", "e2c", "e2t", "e3c", "e3t", "g12", "g23",
"g31", "F12", "F23" and "F31". "st" is used to calculate isotropic
stress criteria or reserve factors. "F12" "F23" and "F31" correspond to
the
,
and
of
the Tsai-Wu failure criteria (sections II.1.9.14
and II.1.9.15). Note that the "ilss" allowable
defined at material level has no effect because for Ilss criterion calculation,
the allowable is always extracted from the laminate definition. (More
precisely, the ilss laminate allowable, or the ply allowables are used.)
``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.
``clearThermalData'' has no arguments and erases all the thermal
data stored in a ClaMat object.
``insertThermalData'' is used to define the thermal data. For
orthotropic and anisotropic materials, possible keys are "lambdaT1",
"lambdaT2", "lambdaT3", "lambdaT12", "lambdaT23" and "lambdaT31". For
isotropic materials, key "lambdaT" only can be used. For all types of
materials "rho" and "Cp" keys can be used.
``fillThermalData'' is used to set material thermal data. This
method has the same arguments as ``insertThermalData'' but differs by the
fact that thermal data are re-initialized before insertion of values.
``clearMoistureData'' has no arguments and erases all the Moisture
data stored in a ClaMat object.
``insertMoistureData'' is used to define the moisture data. For
orthotropic and anisotropic materials, possible keys are "lambdaH1",
"lambdaH2", "lambdaH3", "lambdaH12", "lambdaH23" and "lambdaH31". For
isotropic materials, key "lambdaH" only can be used.
``fillMoistureData'' is used to set material Moisture data. This
method has the same arguments as ``insertMoistureData'' but differs by
the fact that moisture data are re-initialized before insertion of values.
The type of ClaMat object must have been set prior to the use of
any of the three previous methods. (See ``Type'' attribute described in
section II.3.2.) Several methods allow to retrieve
the data that define a material:
``getDataModuli'' returns the moduli that define the ClaMat object.
``getDataCTEs'' returns the CTEs that define the ClaMat object.
``getDataCMEs'' returns the CMEs that define the ClaMat object.
``getDataAllowables'' returns the allowables that characterize the
ClaMat object.
``getThermalData'' returns the thermal data that define the ClaMat
object.
``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
elements
corresponding to the material compliance matrix.
``getStiffness'' returns an Array of
elements
corresponding to the material compliance matrix.
``getInPlaneCompliance'' returns an Array of
elements corresponding to the in-plane material compliance matrix.
``getInPlaneStiffness' returns an Array of
elements
corresponding to the in-plane material compliance matrix.
``getInPlaneAlfaE'' returns an Array of 3 elements corresponding to
the in-plane
vector.
``getInPlaneBetaE'' returns an Array of 3 elements corresponding to
the in-plane
vector.
``getInPlaneAlfa'' returns an Array of 3 elements corresponding to
the in-plane
vector.
``getInPlaneBeta'' returns an Array of 3 elements corresponding to
the in-plane
vector.
``getOOPSCompliance'' returns an Array of
elements
corresponding to the out-of-plane shear material compliance matrix.
``getOOPSStiffness'' returns an Array of
elements
corresponding to the out-of-plane shear material compliance matrix.
``getOOPSAlfaG'' returns an Array of 2 elements corresponding to
the out-of-plane
vector.
``getOOPSBetaG'' returns an Array of 2 elements corresponding to
the out-of-plane
vector.
``getOOPSAlfa'' returns an Array of 2 elements corresponding to
the out-of-plane
vector.
``getOOPSBeta'' returns an Array of 2 elements corresponding to
the out-of-plane
vector.
``getInPlaneLambdaT'' returns an Array of
elements
corresponding to the in-plane thermal conductivity matrix
.
``getInPlaneLambdaH'' returns an Array of
elements
corresponding to the in-plane moisture conductivity matrix
.
All these methods have one optional argument: an angle
corresponding to the direction of observation wrt material axes, and in which
the components of the matrix are expressed.
On the other hand, three methods return material scalar characteristics
and have no argument:
``getRho'' returns a real value corresponding to the material
density
.
``getCp'' returns a real value corresponding to the material
specific heat capacity
.
``getRhoCp'' returns a real value corresponding to the material
volumic heat capacity
.
The different calculated results from the ClaMat object are expressed
in the units system associated with the object.
II.3.5 Management of Units
The ``ClaMat'' class defines three methods for the management of units:
``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.
The ``Hash'' arguments or return values mentioned above have String
keys and values as explained in section II.1.12. The difference
between the ``setUnits'' and ``changeUnits'' methods is also explained in the
same section.
II.3.6 Saving or initializing with NDF lines
Two methods allow to save or read ClaMat objects from an Array of Strings
in neutral format. These two methods are ``initWithNeutralLines''
and ``getNeutralLines'' that work in a similar way as the corresponding
methods in ``ClaDb'' class (section II.2.6).
However, the lines transmitted to ``initWithNeutralLines'' or returned
by ``getNeutralLines'' correspond to a single ClaMat object definition.
II.3.7 Other methods
``clone'' method has no argument and returns a copy of the ClaMat object.
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.
CLA.ClaLam.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
Method Name
Description
Example
Creation and initialization methods
table.ClaLam.methods
One shows in section II.1.6 that two arbitrary
parameters
and
define the relations between
and
partial derivatives of laminate bending moment components and out-of-plane
shear forces. The default values of these parameters are
.
Two Class Methods allow the manipulation of these parameters:
``setMuxMuy'' has two Real parameters and is used to set the values
of
and
respectively.
``getMuxMuy'' returns an Array of two Real objects corresponding
to
and
respectively.
As these methods are Class methods, the modification of
or
affects all the laminates defined in all the CLA databases.
II.4.2 Creation of an object
The singleton method ``new'' is used to create ClaLam objects. This
method has no argument.
II.4.3 Identifying a laminate
Two methods allow the manipulation of the identifier of ClaLam 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.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 arguments 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
where
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 previously existing one. Of course,
an entirely new laminate can also have its ply data initialized with
``setPly'' method, but then the number of plies must first be set...
``setNbrPlies'' method has one argument and sets the number of plies. Note
that the ply definition data previously stored in the laminate may have
random values after using this method.
Two methods allow to access and examine the plies stored in a ClaLam
object:
``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
plies, then the
index must be
. (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 consistent with the set of units attributed to the same object.
This set of units can be attributed to the object after initialization of the data.
II.4.5 Other data
The reference temperature of a laminate is accessed with the two
following methods:
``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.
``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 laminate ``ilss'' allowable is used; when a ClaDb argument
is provided, the ply ``ilss'' allowables are used. This means that the
``ilss'' allowable provided in ClaMat materials is never used.
Obviously, the different data inserted in, or retrieved from the ClaLam object
should be consistent with the set of units attributed to the same object.
This set of units can be attributed to the object after initalization of the data.
II.4.6 Laminate properties
The method ``calcLaminateProperties'' calculates the laminate properties
of the ClaLam object. This means that the stiffness and compliance
matrices, the thermal-expansion vectors are estimated and stored into
the laminate object. This method can be called only after all the
plies of the laminate have been inserted into the object. The method
has one argument: a ClaDb object in which all the materials used
in the lay-up definition have to be stored (otherwise, an exception
is raised). Note that when a ClaLam object is inserted into a
ClaDb, the ``calcLaminateProperties'' method is called
automatically, with this ClaDb object as argument.
Six methods allow to retrieve the properties of a laminate:
``get_ABBD'' returns the
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
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
,
and
as defined by equations (II.1.67),
(II.1.68) and
(II.1.69) respectively.
``get_alfaGh1'' and ``get_alfaGh2'' return 2-components vectors
and
as defined by equations (II.1.76) and
(II.1.77) respectively.
``get_betaEh1'', ``get_betaEh2'' and ``get_betaEh3'' return
3-components vectors
,
and
as defined by equations (II.1.82),
(II.1.83) and
(II.1.84) respectively.
``get_betaGh1'' and ``get_betaGh2'' return 2-components vectors
and
as defined by equations (II.1.91) and
(II.1.92) respectively.
``get_abbd_complMat'' returns the
abbd compliance matrix.
(Format similar as ``get_ABBD''.)
``get_g_complMat'' returns the
out-of-plane shear compliance
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_alfae0'', ``get_alfae1'', ``get_alfak0'' and
``get_alfak1'' return 3-components Array containing the components of
laminate CTE vectors
,
,
and
as defined 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
and
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
,
,
and
as defined 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
and
defined by
expressions (II.1.94)
and (II.1.95).
``get_engineering'' returns a Hash containing equivalent
engineering constants of the laminate. 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
in-plane thermal
conductance matrix
.
``get_LambdaH'' returns the
in-plane moisture
conductance matrix
.
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
.
Four methods return Real scalar values:
``get_thickness'' returns the total thickness of the laminate
.
``get_surfacicMass'' returns the surfacic mass of the laminate
.
``get_averageDensity'' returns the average density of the laminate
.
``get_R33T'' returns the out-of-plane thermal conductance of the
laminate
.
``get_RhoCpH'' returns the out-of-plane thermal surfacic capacity
of the laminate
.
``get_R33H'' returns the out-of-plane moisture conductance of the
laminate
.
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
The calculation of the laminate response to a specified loading
is always done in two steps:
The laminate load response is calculated for a specific
loading. This calculation is used to estimate laminate in-plane
forces, bending moments, average strains, curvature,
temperature variations... Also layered results are calculated if
required. (See description of method ``calcResponse'' in
section II.4.7.1.)
All these results are stored in the ClaLam object and remembered
until the next calculation is performed.
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 properties 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 corresponding layered results).
II.4.7.2 Laminate internal loads and strains
Several methods allow to recover results calculated at laminate level.
All these results correspond to the laminate results for the last
call to method ``calcResponse'':
``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 average 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 response calculation has been calculated with
a hygro-elastic contribution.
``getDeltaH'' returns a Real values corresponding to the
difference between the load average 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 contain a load response. (When a laminate load
response is calculated, a mechanical contribution 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. This method has one optional argument
corresponding to a rotation wrt laminate axes.
``getNormalStrains'' returns the in-plane average strains in an
Array of three Real values. This method has one optional argument
corresponding to a rotation wrt laminate axes.
``getCurvatures'' returns the curvature tensor in an Array
of three Real values. This method has one optional argument
corresponding to a rotation wrt laminate axes.
``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 Array of three Real
values. This method has one optional argument corresponding to a
rotation wrt laminate axes.
``getAverageShearStresses'' returns the average out-of-plane
shear stress tensor components in an Array of two Real values. This
method has one optional argument corresponding to a rotation wrt
laminate axes.
``getAverageInPlaneStrains'' returns the in-plane average strain
tensor components in an Array of three Real values. This method has
one optional argument corresponding to a rotation wrt laminate axes.
``getFlexuralStrains'' returns the top surface strain tensor
components corresponding to bending moment. The components are
returned in an Array of three Real values. This method has one optional
argument corresponding to a rotation wrt laminate axes.
``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 corresponding 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
corresponds to the ``Mechanical Strain Tensor'' presented in
Tables IX.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
.
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
, 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 correspond to the
identifiers of layers at which ply results are recovered. The methods
return an Array of which each element corresponds to a layered Result.
More precisely, each element is an Array of 3 elements containing:
The two first elements identify the layer: they correspond to the integer
index of the ply between 0 and
, 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.
``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 identifier 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:
Note that several criteria can be calculated by a single
call. The method ``getReserveFactors'' has 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
Each of the three methods described above returns an
Array containing two elements:
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.
The second element contains the new layered results. Each
element of this Array contains 2+X elements:
The two first elements of the sub-array
identify the layer to which the calculated results correspond.
The X elements 3 to 2+X of the sub-array contain the Real calculated values.
These X elements correspond to the X Strings referred to above in the
list of criteria returned by the method.
The three methods ``getDerived'', ``getFailureIndices'' and
``getReserveFactors'' have ``Min'' and ``Max'' variants. This
makes six additional methods: ``getMinDerived'',
``getMinFailureIndices'', ``getMinReserveFactors'', ``getMaxDerived'',
``getMaxFailureIndices'' and ``getMaxReserveFactors''. These methods
have the same parameters as their basic corresponding methods and
are used to return values associated to the most critical ply. (The ply
leading to maximum or minimum calculated criterion.) The returned
Array, however, is different. The returned value is an Array
of which each element is an Array of four elements:
The calculated criterion (String).
Two elements identifying the critical layer (an integer and string value).
A Real object corresponding to the critical value.
The criteria presently available are summarized in Table
II.1.1.
II.4.8 Laminate finite element load response
The ``calcFiniteElementResponse'' method allows the calculation of
finite element load response. More precisely the method calculates several
Result objects containing finite laminate finite element results, from
loading of which some components are finite element results.
The method has up to eight arguments:
The first argument is a ``ClaDb'' object in which the
materials used in the laminate definition are stored.
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.
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.
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.)
The fifth parameter is an Array of Strings specifying the
non-layered laminate results that will be returned by the method.
The sixth parameter is an Array of Strings specifying the
layered laminate results that will be returned by the method. (Results
at ply level.)
The seventh parameter is a Real object. This parameter is used
by the method only for the calculation of reserve factors.
(See the following argument.)
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 String corresponding to the key by which the corresponding
result shall be referred in the Hash returned by
``calcFiniteElementResponse'' method.
A String corresponding to the name of the criterion. This name
must one of the names defined in Table II.1.1.
A string defining the type of Result that shall be defined. Values
can be ``FI'', ``RF'', ``EQ''. They correspond to the calculation
of failure indices, reserve factors or Scalar Derived values
respectively. If a reserve factor is required, the factor of safety
parameter is used for the calculation.
A logical value specifying whether the laminate allowables are
used for the calculation of Result values. If this value is false,
then the ply material allowables are used in the calculations.
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.
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, if the two values at Z1 and Z2 are not found for
the finite element entity on which FeResPost tries to calculate a load
response, the corresponding thermo-elastic or hygro-elastic component of
loading is ignored for the entity load response calculation.
Non-layered vectorial or tensorial Results are calculated in
laminate axes. Layered vectorial and tensorial Results are calculated
in ply axes. Scalar Results are not associated to a coordinate system.
The requirements for laminate non-layered and layered Results are
summarized in Table II.4.2 and
Table II.4.3 respectively.
Note that the same method with exactly the same arguments has been defined
in the DataBase class. (See
section I.1.5.)
The different calculated results from the ClaLam object are expressed
in the units system associated with the object.
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 ``calcFiniteElementResponse'' 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.
II.4.10 Management of Units
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 ``Hash'' arguments or return values mentioned above have String
keys and values as explained in section II.1.12. The difference
between the ``setUnits'' and ``changeUnits'' methods is also explained in the
same section.
II.4.11 Saving or initializing with NDF lines
Two methods allow to save or read ClaLam objects from an Array of Strings
in neutral format. These two methods are ``initWithNeutralLines''
and ``getNeutralLines'' that work in a similar way as the corresponding
methods in ``ClaDb'' class (section II.2.6).
However, the lines transmitted to ``initWithNeutralLines'' or returned
by ``getNeutralLines'' correspond to a single ClaLam object definition.
II.4.12 One iterator
The ClaLam class provides the iterator ``each_ply'' that iterates
on the plies. This iterator returns pairs of elements corresponding
to the ply index, and the ply definition. The ply definition is an
Array of 5 elements identical to the one returned by ``getPlyData''
method.
II.4.13 Other methods
``clone'' method has no argument and returns a copy of the ClaLam object.
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
,
and
are given.
The flexural part of mechanical loading. Three
such components
,
and
are given.
The out-of-plane shear part of mechanical
loading. Two such components
and
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 (expressed 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 extracted 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), curvature 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
. Also the
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 results stored
in the ClaLoad object when calculating laminate load response (``Shell
Strains'' or ``Shell Curvatures'',
see equation II.1.43).
``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 loading 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.
CLA.ClaLoad.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
The singleton method ``new'' is used to create ClaLoad objects. This
method has no argument. (Nor has the ``initialize'' method an argument.)
II.5.2 Identifying a ClaLoad
Two methods allow the manipulation of the identifier of ClaLoad objects (``Id'' attribute):
``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.5.3 Thermo-elastic and hygro-elastic contributions
Ten methods allow the manipulation of scalar characteristics of the
loadings. (The scalar characteristics are the thermo-elastic and
hygro-elastic contributions to loading.) The methods are:
``setT'' is used to set thermo-elastic part of loading.
The method has two or three arguments:
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''.)
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 arguments:
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 constant values provided as
arguments 2 and/or 3. (This argument is ``fem'' or ``noFem''.)
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 consistent with the set of units attributed to the same object.
This set of units can be attributed to the object after initialization of the data.
II.5.4 Setting and getting mechanical parts
Three methods are used to set the mechanical part of loading stored
in the ClaLoad object:
``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
,
and
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
.) 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 element 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:
and
. The two optional arguments are
Strings corresponding to the type of solications 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 consistent with the set of units attributed to the same object.
This set of units can be attributed to the object after initialization of the data.
II.5.5 Linear combinations of loads
``setToCombili'' method allows to define a ClaLoad as a linear
combination of pre-defined ClaLoads. This method has four arguments:
A reference temperature. This Real parameter is necessary
because the top and bottom temperatures of the combined ClaLoad are
calculated as follows:
A reference moisture. (Same remarks as for the reference
temperature.)
An Array of Reals corresponding to the coefficients
of the linear combination.
An Array of ClaLoad objects.
The sizes of the two Array arguments must match. Also
the types of the different components of mechanical part of the
loadings must be the same.
II.5.6 Finite element Results
Eighteen methods are devoted to the manipulation of loading components
defined as finite element Results. Six member data correspond to these
methods: ``Shell Forces'', ``Shell Moments'', ``Shell Strains'',
``Shell Curvatures'', ``Shell Temperatures'' and ``Shell Moistures''.
The mechanical components of loading correspond to non-layered Results.
``Shell Temperatures'' and ``Shell Moistures'' are defined at Shell
lower and upper surfaces (layers ``Z1'' and ``Z2'' respectively). When
calculating laminate load response, FeResPost does not check or
considers the coordinate system to which mechanical loading components
are associated. This means that all the components are assumed to be
given in loading axes. It is the responsibility of the user to first
transform the components in such a way that their use by FeResPost makes
sense.
Three methods allow the manipulation of Shell Forces stored in the
ClaLoad object:
``setShellForces'' inserts a copy of the Result argument inside
the ClaLoad object.
``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.
``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 manipulation of ``Shell Moments''.
``setShellStrains'', ``getShellStrainsCopy'' and
``clearShellStrains'' for the manipulation of ``Shell Strains''.
``setShellCurvatures'', ``getShellCurvaturesCopy'' and
``clearShellCurvatures'' for the manipulation of ``Shell Curvatures''.
``setShellTemperatures'', ``getShellTemperaturesCopy'' and
``clearShellTemperatures'' for the manipulation of
``Shell Temperatures''.
``setShellMoistures'', ``getShellMoisturesCopy'' and
``clearShellMoistures'' for the manipulation of ``Shell Moistures''.
Obviously, the different data inserted in, or retrieved from the ClaMat object
should be consistent with the set of units attributed to the same object.
This set of units can be attributed to the object after initialization of the data.
II.5.7 Management of Units
The ``ClaLoad'' class defines three methods for the management of units:
``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.
The ``Hash'' arguments or return values mentioned above have String
keys and values as explained in section II.1.12. The difference
between the ``setUnits'' and ``changeUnits'' methods is also explained in the
same section.
II.5.8 Saving or initializing with NDF lines
Two methods allow to save or read ClaLoad objects from an Array of Strings
in neutral format. These two methods are ``initWithNeutralLines''
and ``getNeutralLines'' that work in a similar way as the corresponding
methods in ``ClaDb'' class (section II.2.6).
However, the lines transmitted to ``initWithNeutralLines'' or returned
by ``getNeutralLines'' correspond to a single ClaLoad object definition.
II.5.9 Other methods
``clone'' method has no argument and returns a copy of the ClaLoad object.
In this Part of the document, one describes the preferences for the different
solvers supported by FeResPost. Most preferences are defined as methods and
member data of the classes specializing the ``DataBase'' class defined
Chapter I.1. Presently two solvers are supported:
Nastran and Samcef. The corresponding classes specializing ``DataBase'' class
are ``NastranDb'' and ``SamcefDb'' classes. The corresponding preferences are
described in Chapters III.1 and III.2
respectively. The diagram of Figure I.1.1
representing the ``DataBase'' hierarchy can be more precisely represented as in
Figure 1.
Figure 1:Finite element DataBase classes hierarchy.
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).
userManual.Nastran.DB.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
(See also methods in userManual.DataBase.methods.tabgeneric DataBase class.)
A ``NastranDb'' object can be created by a statement 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 five arguments.
A String containing the name of the main Nastran Bulk Data File.
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.
The name of an extension that may be added to the file names
specified in include statements. Its default value is a void String. (This
argument corresponds to the jidtype in Nastran.)
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.
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.
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:
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:
Only the lines between ``BEGIN BULK'' and ``ENDDATA'' are read.
(These words can also be lowercase.)
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.
The following multi point constraints cards: ``RBE1'',
`RBE2'', ``RBE3'',``RROD'', ``RBAR'', ``MPC'' and ``MPCADD''.
The following coordinate system cards: ``CORD1C'',
``CORD1R'', ``CORD1S'', ``CORD2C'', ``CORD2R'' and ``CORD2S''.
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 supported^{III.11}.
Four material cards are totally supported: ``MAT1'',
``MAT2'', ``MAT8'' and ``MAT9''. Some other material cards are
only partially
supported
1
: ``CREEP'',
``MATS1'', ``MATT1'', ``MATT2'', ``MATT8'', ``MAT3'', ``MATT3'',
``MAT4'', ``MAT5'', ``MATT4'', ``MATT5'', ``MATT9'', ``MAT10'',
``MAT11'' and ``MATHP''.
The ``include'' 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.
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 will lead to problems.
Quoted strings that span on several lines lead to problems.
In all cases, we suggest the user to be ``defensive'' and ``reasonable''
when using ``include'' statements in its bulk Data Files. In case of problem, the ``verbosity''
argument should help to debug FeResPost (or the Nastran model).
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 likely to occur 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.6 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.6 the reading of Results.
Note that only the reading of 32bits ``op2'' files is possible. There is no
support for 64bits output files.
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.
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.6 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 :
A string containing the name of the file to which the Nastran cards
are printed.
A string corresponding to the opening mode for the file. Valid
values are ``w'' and ``w+'' (for append mode).
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''.
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''.
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''.
The last argument is optional and corresponds to the Group for
which cards are to be printed. It can be a String or a Group argument.
If its type is String, then the corresponding Group defined in the
DataBase is considered. Note that ``Properties'' and ``Materials'' are
not printed if the Group argument is provided.
The ``writeBdfLines'' method must be used for debugging purposes only.
The user must keep in mind that some entities are not totally supported
and their output may be problematic.
One 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 six arguments:
A String containing the name of the file to which the Nastran card
is printed.
A String corresponding to the opening mode for the output file. Valid
values are ``w'' and ``w+'' (for append mode).
A first format String argument specifying whether the fields in
the card output are left or right aligned. This argument may have three
values: ``left'', ``right'' or a void String. If the String is void,
the format defaults to ``left''.
A second format String argument specifying whether the fields in
the card output are narrow or wide. This argument may have three
values: ``short'', ``wide'' or a void String. If the String is void,
the format defaults to ``short''.
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.
An Array containing the fields to be printed. Possible types for
the elements of this Array are Real, Integer and String.
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.
III.1.1.4 ``CoordSys'' methods
The ``CoordSys'' class allows the manipulation of coordinate systems for
post-processing purpose. This class is presented in
Chapter I.2. One presents below the methods of
NastranDb class devoted to the manipulation of coordinate systems.
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.
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.
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.5 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 associated to the nodes of the Group argument.
``getElementsAssociatedToMaterials'' returns a Group containing the
list of elements associated 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 associated 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.6 ``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.
Note that only the reading of 32bits ``op2'' files is possible. There is no
support for 64bits output files.
``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:
A String that corresponds to the file from which model or Results
are read.
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.
A ``LcNames'' argument that corresponds to the list of load cases
for which the Results are read. The argument may be:
A Single String corresponding to the name of one load case.
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.
A ``ScNames'' argument that corresponds to the list of subcases
for which the Results are read. The argument may be:
A Single String corresponding to the name of one subcase.
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.
A ``ResNames'' argument that corresponds to the list of
Results identifiers for which the Results are read.
The argument may be:
A Single String corresponding to the Result ID.
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.
A ``PostParam'' integer argument corresponding to the parameter
``POST'' in Nastran 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 parameters 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:
Four singleton methods allow to disable or (re-)enable some
entities when importing model or result entities from Nastran op2 or bdf
files:
``enableBulkCards'' is used to re-enable some Nastran card
when reading model entities from a Nastran bdf or op2 file.
``disableBulkCards'' is used to disable some Nastran
card when reading model entities from a Nastran bdf or op2 file.
``enableNastResElems'' is used to re-enable ``result element
types'' when reading Results from an op2 file.
``disableNastResElems'' is used to disable ``result
element types'' when reading Results from an op2 file.
These four 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.
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.
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.9. 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 159: transient thermal analysis.
III.1.1.7 ``XDB'' methods for reading Results into DataBase
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. (Actually, it probably slows down the XDB access.)
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:
A String argument that corresponds to the name of the file from
which Results are read.
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.
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.
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.
A Boolean value specifying whether one forces the swap of endianness when
reading the XDB file.
All parameters, except the first one, can be omitted. Then the
method assumes that a void Array has been passed as argument.
Presently the support of ``xdb'' Results reading is more limited than the
corresponding support 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),
The different characteristics of imported Results correspond to the
characteristics of corresponding Results read from ``op2'' files.
Note however, that Complex Results can also be read from xdb files. Generally,
the complex Results are the same as the real Results. More information can be found
in section IX.C.2.
Four methods devoted to the enabling or disabling composite
layered Results are defined in the generic ``DataBase'' class. These
methods are presented in
section I.1.3.2.
III.1.1.7.8 A note on ``endianness''
The different methods devoted to XDB files access allow to specify a force on
swap endianness. When the corresponding parameter is set to ``TRUE'', FeResPost
considers that the endianness of binary XDB file does not correspond to the
endianness of the machine on which FeResPost executes. Then, a swap of endianness
is performed when the binary file is read.
If the ``SwapEndianness'' parameter is set to false, no modification of endianness is
done when the file is read.
If the ``SwapEndianness'' parameter is not given, FeResPost checks the endiannes of the file
and, if needed, does corrections to the binary data that are read. The test is the following:
FeResPost reads the first word of the XDB binary file. This word is the size of the blocks in the
XDB file. (1024 by default, but this size can be modified by the RECL parameter in ASSIGN
Nastran statement and set to a maximum value of 65536.) A check on the value allows to
determine whether the endiannes of the file corresponds to the endianness of the machine
on which FeResPost is run. The check works if the size is smaller than 65536. If the size
of blocks is 65536, the check fails and the ``SwapEndianness'' parameter must be specified
in the calls to methods accessing XDB files.
III.1.1.8 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.7.
The method ``attachXdb'' is used to attach an XDB file to the Nastran DataBase. This
method has up to two arguments:
The first argument is a String containing the name of the XDB file. (Full path name
must be provided.)
The second argument is an optional Boolean parameter specifying whether the
endianness must be swapped when XDB file content is read. If the parameter is not
given, the endianness of the file is automatically detected. Note however that this check
might fail. (See also page 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 method has no argument.
``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.
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 ``getdXdbLcInfos''
page III.1.1.7.)
``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.
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:
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.)
A String corresponding to the name of the load case for which Results
are read.
A String or an Array of Strings corresponding to the names of sub-cases
for which Results are read.
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 howveer 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'':
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'', ``ElemCenters'',
``ElemCorners'' and ``ElemNodes'' extraction methods allow the use of a random access algorithm. On
the other hand, the ``Nodes'' and ``NodesOnly'' methods are associated 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 ``NodesOnly''.
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
elementary Results found in one or several XDB files. As for method ``getAttachmentResults''
the Results are directly returned by the method to the caller. They are not inserted
in the DataBase from which the method is called. This method is more or
less a combination of the methods ``getAttachmentResults'' and ``buildLoadCasesCombili''
of the generic DataBase class.
Practically, the main difference between ``getAttachmentResults'' and
``getAttachmentResultsCombili'' is that the first argument is no longer an Xdb file
name. This argument is removed. Instead, one provides a ``Combili'' argument that
describes the linear combination corresponding to extracted Results. This ``Combili'' argument
is the second argument. The first argument is the ``LcName'' argument corresponding
to the load case name attributed to the generated Results. This load case name is not supposed
to correspond to any load case name found in the attached XDB file(s).
The method has minimum four arguments:
A String corresponding to the name of the load case for which Results
are read.
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.
A String or an Array of Strings corresponding to the names of sub-cases
for which Results are read.
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.
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'':
It is possible to obtain some of the Nastran optimization (SOL200) results from an XDB attachment.
Four methods have been defined in NastranDb class:
``getAttachmentDesVarHistory'' returns the history of design variables and has three parameters:
``xdbFileName'', a String corresponding to the name of the attached XDB file.
``iSteps'', an Array of integers corresponding to the list of steps for which one wishes to obtain results.
``iDesVarIds'', an array of integers corresponding to the list of design variable IDs for which one wishes to obtained the results.
Parameters 2 and 3 are optional and can be omitted or replaced by a ``nil'' argument. If they are not defined, all the steps or
design variables are returned in the results.
The method returns a N X 3 array. For each line, the three colunns 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.
``getAttachmentConstrDefinitions'' returns the definition of constraints and has two arguments:
``xdbFileName'', a String corresponding to the name of the attached XDB file.
``iConstrIds'', an array of integers corresponding to the list of constrain IDs.
Parameters 2 is optional and can be omitted or replaced by a ``nil'' argument.
The method returns a N X 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.
``getAttachmentConstrHistory'' returns the history of constrains and has three parameters:
``xdbFileName'', a String corresponding to the name of the attached XDB file.
``iSteps'', an Array of integers corresponding to the list of steps for which one wishes to obtain results.
``iIRIds'', an array of integers corresponding to the list of internal response IDs for which one wishes to obtained the results.
Parameters 2 and 3 are optional and can be omitted or replaced by a ``nil'' argument. If they are not defined, all the steps or
design responses are returned in the results.
The method returns a N X 3 array. For each line, the three columns correspond to:
The first element is an integer corresponding to the optimization step ID.
The second element is an integer corresponding to identifier of the design response.
The third element is a float containing the design response value.
``getAttachmentObjectiveHistory'' returns the history of constrains and has two parameters:
``xdbFileName'', a String corresponding to the name of the attached XDB file.
``iSteps'', an Array of integers corresponding to the list of steps for which one wishes to obtain results.
Parameter 2 is optional and can be omitted or replaced by a ``nil'' argument. If it is not defined, all the steps
are returned in the results.
The method returns a N X 3 array. For each line, the three columns correspond to:
The first element is an integer corresponding to the optimization step ID.
The second element is a float corresponding to the value of objective.
The third element is an integer containing the identified of an internal response.
The fourth element is a float containing the value of the maximum constraint equation (corresponding to the previous internal response).
``getAttachmentDesRespHistory'' returns the history of design responses and has three parameters:
``xdbFileName'', a String corresponding to the name of the attached XDB file.
``iSteps'', an Array of integers corresponding to the list of steps for which one wishes to obtain results.
``iDesRespIds'', an array of integers corresponding to the list of design responses IDs for which one wishes to obtained the results.
Parameters 2 and 3 are optional and can be omitted or replaced by a ``nil'' argument. If they are not defined, all the steps or
design variables are returned in the results.
The method returns a N X 3 array. For each line, the three columns correspond to:
The first element is an integer corresponding to the optimization step ID.
The second element is an integer corresponding to identifier of the design response.
The third element is a float containing the design response value.
So far, the reading of optimization results is experimental and might be changed in future version.
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 arguments: 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 method has no argument.
Note that all buffers are now common to all the methods that provide random access to XDB
result files. In particular, the method is used in management of the binary file access for XDB
attachment or reading. This means that if one Result file attached to one DataBase
is more used, the storage will contain a majority of buffers for this Result file and progressively
delete the other buffers.
The default capacity for storage buffer is 0Mb. Note that the two methods described above
can be called from any class derived from the generic ``DataBase'' class.
III.1.1.9 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.10 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. The return the integer indices of nodes.
III.1.1.11 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.
``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 arguments:
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
. (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 however 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 ``SUBTITLE'' associated to the SUBCASE defined in Nastran data file. If this
SUBTITLE is not define, the SUBCASE ID is used to generate a default load case
identifier as follows:
lcName="Load Case "+ID
Finally, the results found in the op2 file are presented by blocks
corresponding to the different ``result element types''. Unfortunately, those
element types do not correspond exactly to the element bdf cards presented
in section III.1.1.1. The supported
result element types are: ``ROD'', ``BEAM'', ``TUBE'', ``SHEAR'',
``CONROD'', ``ELAS1'', ``ELAS2'', ``ELAS3'', ``ELAS4'', ``DAMP1'',
``DAMP2'', ``DAMP3'', ``DAMP4'', ``VISC'', ``MASS1'', ``MASS2'', ``MASS3'',
``MASS4'', ``CONM1'', ``CONM2'', ``PLOTEL'', ``QUAD4'', ``BAR'', ``GAP'',
``TETRA'', ``BUSH1D'', ``QUAD8'', ``HEXA'', ``PENTA'', ``BEND'', ``TRIAR'',
``TRIA3'', ``TRIA6'', ``QUADR'', ``TETRANL'', ``GAPNL'', ``TUBENL'',
``TRIA3NL'', ``RODNL'', ``QUAD4NL'', ``PENTANL'', ``CONRODNL'', ``HEXANL'',
``BEAMNL'', ``QUAD4LC'', ``QUAD8LC'', ``TRIA3LC'', ``TRIA6LC'', ``BUSH'', ``FAST'',
``QUAD144'', ``QUADRNL'', ``TRIARNL'', ``ELAS1NL'', ``ELAS3NL'', ``BUSHNL'',
``QUADRLC'' and ``TRIARLC''. (More information on the result element types
can be found in [Rey04].)
Here again, some of the element result types can be disabled or
enabled (section III.1.1.1). The
arguments given to the enabling or disabling methods correspond to a
String object, or an Array of Strings, the values of Strings corresponding to
some of the Result element types given just above.
The negative node values corresponding to Results on specific Nastran
elements are summarized in Table III.1.2.
(This Table is a complement to
Table I.4.2.)
Table III.1.2:
Correspondence between special nodes for element Results and
their integer ids (peculiar to Nastran solver).
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.11. 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
DISPL
OUG
``Displacements, Translational''
``Displacements, Rotational''
``Displacements, Scalar''
VELO
OUG
``Velocities, Translational''
``Velocities, Rotational''
``Velocities, Scalar''
ACCEL
OUG
``Accelerations, Translational''
``Accelerations, Rotational''
``Accelerations, Scalar''
Table III.1.4:Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Applied loads read from OPG data blocks.)
Table III.1.7:Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Strains read from OES data blocks and
corresponding to ``STRAIN'' output requests..)
Table III.1.8:Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Stresses read from OES data blocks and
corresponding to ``STRESS'' output requests.)
Table III.1.9:Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Element forces
read from OEF data blocks or other ``FORCE'' output.)
Table III.1.10:Correspondence between the Nastran output cards and the
``op2'' result data blocks. (Element forces read from OEE data blocks or
``ESE'', ``EKE'' and ``EDE'' output.)
Nastran
``op2''
Generated
Statement
Data Block
Result
ESE
OEE
``Element Strain Energy''
``Element Strain Energy (Density)''
``Element Strain Energy (Percent of Total)''
EKE
OEE
``Element Kinetic Energy''
``Element Kinetic Energy (Density)''
``Element Kinetic Energy (Percent of Total)''
EDE
OEE
``Element Energy Loss''
``Element Energy Loss (Density)''
``Element Energy Loss (Percent of Total)''
Table III.1.11:Nastran Results for thermal calculations.
Nastran
``op2''
Generated
Statement
Data Block
Result
TEMPERATURE
OUG
``Temperature''
FLUX
OEF
``Temperature Gradient''
FLUX
OEF
``Conductive Heat Flux''
One can make a few remarks about the information given in
Tables III.1.3 to
III.1.11:
``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.
The Nastran ``CELASi'' and ``CDAMPi'' elements produce scalar
forces or moments that are stored in ``Beam Scalar Forces'' Results.
``Applied Loads'' are available both with the ``OLOAD'' and
``GPFORCE'' Nastran statements. 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''.
The shear components of strain tensor output by Nastran are the
angular deformations:
. When these results are
imported in a NastranDb, the corresponding components are divided by two
in such a way that a ``physical'' tensor is stored into the NastranDb.
The same remark applies for the non-diagonal components of the curvature
tensor (shell elements).
The ``STRAIN'' Nastran output statement with ``FIBER'' option outputs
the strain tensor at Z1 and Z2, but do not produce the curvature tensor.
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.
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.
``Axial Strain'' or ``Axial Stress'' for ``Total Loads'' and CBAR
elements are produced by combined axial loads to bending loads. This has
been done to harmonize CBAR Results with CBEAM Results. For CBEAM
Results, Stresses or Strains are recovered on the extremities only.
Plastic deformation results are produced for non-linear results
only.
Nastran ``beam'' type elements (CBAR, CBEAM, CBEND, CBUSH,...) do not
output vectorial or tensorial forces or moments. Instead, the different
components are expressed in different coordinate systems (axial, plane 1 and
plane 2). When importing these Results, a conversion into tensorial format
is done as follows:
For CBAR elements, ``Beam Forces'' are always produced at the center
of elements, and ``Beam Moments'' at the two end nodes.
Bush result types for OEF and OES outputs depend on the kind
of BUSH elements to which they correspond:
Nastran ``CBUSH'' elements for linear analyses produce
vectorial or tensorial results in OEF and OES blocks.
Nastran ``CBUSH'' elements for non-linear analyses produce
vectorial or tensorial results in OES blocks. No results are
produced in OEF blocks.
The element forces and moments are stored in ``Beam Forces''
and ``Beam Moments'' tensorial Results.
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.
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:
No bending moments are produced by ``CBUSH1D'' elements.
Nastran ``CGAP'' elements produces various results. Results
are tensorial and:
Gap forces results are stored in ``Beam Forces'' tensorial
Result. The value of the axial component is multiplied by ``-1.0'',
because it is a compression component. Note that the ``OES'' block
also contains gap forces which are also stored in ``Beam Forces''
Result.
``Gap Slips'' is identical to ``Beam Deformations'' except
that the axial component is set to ``0.0''.
Various Nastran elements refer scalar points instead of grids.
Nevertheless, Nastran considers the scalar point as a kind of element
rather than as a kind of grid. This is, in our opinion, an unfortunate
choice! FeResPost considers SPOINT 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.12.
One can make a few remarks about the information given in those Tables:
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.)
Note also that, as out-of-plane shear stresses represent interlaminar
stresses, the components are expressed in laminate axes rather than in one of
the plies coordinate system. This means that, even though stress tensor
values are assumed to be given in ply axes, the out-of-plane shear stresses
are given in laminate axes. This is an additional reason to be careful when using
these components.
When Nastran composite strains are read, values are produced for Mid
thickness of each ply only.
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.
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.12
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.12:Correspondence between the Nastran output cards and
composite stresses and strains
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.)
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).
userManual.Samcef.DB.methods.tab
(FeResPost list of classes is given in
Table 1
page .)
(See also methods in userManual.DataBase.methods.tabgeneric DataBase class.)