next up previous contents index
Next: Contents Up: FeResPost User Manual Previous: FeResPost User Manual   Contents   Index

Subsections

I.0 Introduction

In this document, one presents the manual of FeResPost.

FeResPost

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

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

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

FeResPost is 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:

  1. 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.
  2. The FeResPost library is mainly written in C++, which is also an object-oriented language. Then a Ruby wrapping is provided around the C++ code.
During the development of FeResPost, the developer has been trying to maintain as much as possible the simplicity and clarity of the language in which post-processing programs are written. 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.

How to learn FeResPost?

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

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

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

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

  2. Then, the user may test FeResPost by running the small examples. These are provided in the sub-directories in ``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.

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

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

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

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

Structure of the document

This document is organized as follows:

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


Table 1: Classes defined by FeResPost, and links to the corresponding lists of methods.
Class Chapter Table Page
``Common'' Classes
userManual.DataBase.methods.tabDataBase I.1 I.1.1 [*]
userManual.CoordSys.methods.tabCoordSys I.2 I.2.1 [*]
userManual.Group.methods.tabGroup I.3 I.3.1 [*]
userManual.Result.methods.tabResult I.4 I.4.1 [*]
userManual.ResKeyList.methods.tabResKeyList I.5 I.5.1 [*]
userManual.Post.methods.tabPost (module) I.6 I.6.1 [*]
Classical Laminate Analysis
CLA.ClaDb.methods.tabClaDb II.2 II.2.1 [*]
CLA.ClaMat.methods.tabClaMat II.3 II.3.1 [*]
CLA.ClaLam.methods.tabClaLam II.4 II.4.1 [*]
CLA.ClaLoad.methods.tabClaLoad II.5 II.5.1 [*]
Solver Preferences
userManual.Nastran.DB.methods.tabNastranDb III.1 III.1.1 [*]
userManual.Samcef.DB.methods.tabSamcefDb III.2 III.2.1 [*]

Future developments

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

  1. Correction of bugs...
  2. Addition of specialized post-processing modules programmed at C++ level to provide efficiency. For examples:
  3. Extension of FeResPost by providing interfaces towards other FE software like Abaqus,...
  4. Development of extensions for other interpreted languages like python or perl.
  5. Development of a UNO component.
  6. ...
Of course, we are open to constructive remarks and comments about the ruby library in order to improve it.


next up previous contents index
Next: Contents Up: FeResPost User Manual Previous: FeResPost User Manual   Contents   Index
FeResPost 2017-05-28