An example of object-oriented post-processing programmed in ruby language is presented in this chapter. The structure of the post-processing presented here is very similar to the structure of post-processings currently used on actual “real” projects, and results from a long evolution driven by years of practice. (An earlier excel version of the post-processing project is presented and discussed in Appendix X.D.2.)
The history of post-processings described in the FeResPost User Manual is summarized below:
The first post-processing project that has been written in ruby if the modular post-processing presented earlier versions of the manual (up to version 5.1.3). The project is written in ruby language, but is not object-oriented, which is a drawback.
Therefore, a second version of the post-processing, also with ruby language, has been programmed. This post-processing is more object-oriented, and is described in earlier version of the user manual. It suffers however several limitations. One of these limitations, is that one single post-processing object can be related to the calculation of several parts of interfaces. This is in fact a limitation of the object-orientation of the post-processing objects.
An excel post-processing is presented in Appendix X.D.2. The programming is then done with VBA language, and FeResPost COM component is used. This post-processing is a nice example of excel automation with FeResPost COM component. However, several limitations of this Excel approach were discovered when using it on large projects:
Important limitations are related to the programming with VBA language which is a little too old fashioned to produce an efficient code. In particular, VBA language is only slightly object-oriented. This results in difficulties to produce efficient code. The modifications of existing code is also more difficult with VBA language than with other languages.
There is no clear separation of programming and data, as the triggering of post-processing is done via the calculation of functions in excel spreadsheets. In particular, the fact that each failure criterion is calculated via the calculation of an excel function, limits the possibility to optimize the project by reducing the number of Results extractions from Nastran Result files.
Only 32-bit versions of Office may be available. This limits the size of XDB files that can be used to approximately 2Gb. Also, excel is run on computers with limited power and RAM. This is sometimes a big problem as the computer is also used for other purposes when the post-processing is run.
Finally, a new post-processing has been programmed in ruby. This post-processing inherits most of the best characteristics of the previous versions presented in earlier versions the manual. This post-processing is described in the rest of current Chapter.
The rest of this Chapter is organized as follows:
Section IV.4.1 is devoted to the general structure of the project. The main classes and modules that define the programming of the post-processing are also described.
Section IV.4.2 describes how the data have been defined for the example.
Several tools for the final post-processing steps are described in section IV.4.3.
Note that the purpose of current chapter is to describe the main structure of the post-processing in a way that allows the reader to better understand source code. However, the understanding of the project will be achieved only by diving into the source code, which is described in section IV.4.1.
“DbAndLoadCases” module also acts as a server of Results for the post-processing objects discussed in section IV.4.1. Method “DbAndLoadCases.getResult” is programmed in such a way that the post-processing classes remain “unaware” of the solver or solution sequence that have produced the Results being post-processed:
Post-processing objects do not know whether they post-process Nastran or Samcef Results.
When Nastran Results are post-processed, they do not know whether these Results have been extract from OP2, HDF or XDB files.
When accessing Results stored in current FEM database, they require Results using the “real” Result names, without “ (MP)” or “ (RI)”. Manipulations specific to Result format is done inside post-processing objects however.
We made reference above to the excel post-processing described in Chapter X.D.2. Current project also uses Microsoft Office tools:
To produce the CSV files that define the post-processing data. Indeed, Excel is a useful tool to present and manipulate tables.
To extract results from the “xl_*” tables in SQLite database and save them in separate excel Workbooks.
To copy and paste automatically tables from excel to word. Writing of parts of the reports can then be automated.
More information about the final part of the post-processing is provided in section IV.4.4. Note that the use of Microsoft Office tools, excel in particular has been reduced as much as possible in order to allow the running of most post-processing on Linux instead of Windows. This is why excel is used only for the preparation of CSV files, and for the extraction of results to be inserted into Word reports.