How to learn FeResPost?

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

1.

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

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

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

2.

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

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

3.

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

4.

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

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

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