Some advice is given here to people starting to use FeResPost. The order in which knowledge is acquired matters. One of the worst ways 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, the following sequence of knowledge acquisition is suggested:
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 who try to learn ruby and FeResPost simultaneously will likely struggle with both.
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 acquiring a basic knowledge of ruby.
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.
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. However, it is also less complete and less elegant from a programming point of view.
The reason why the advice above is given is that many users send emails with questions or complaints because they fail to understand something about FeResPost that is clearly illustrated in the examples. Sometimes, the problems faced by users are simply related to a lack of understanding of the ruby programming language.