Chapter IV.4
Object-oriented post-processing

We present in this chapter an example of object-oriented post-processing programmed in ruby language. The structure of the post-processing presented here is very similar to the structure of post-processings we are currently using on actual “real” projects, and results from a long evolution driven by years of practice. Earlier versions of the post-processing project are presented and discussed in Appendixes X.E and X.F and in Chapter VII.4.

We summarize below the history of post-processings that are described in FeResPost User Manual:

• The first post-processing project that has been written in ruby if the modular post-processing presented in Appendix X.E. The project is written in ruby language, but is not object-oriented, which is a shame.
• 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 Appendix X.F. 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 corresponds actually to a limitation of the object-orientation of post-processing objects.
• An excel post-processing is presented in Chapter VII.4. 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. One discovered however several limitations of this excel 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.
  • In my company, we have access to 32 bits versions of Office only. 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 Appendix X.F and Chapter VII.4. 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. One also describes the main classes and modules that define the programming of the post-processing.
• 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 VII.4. Current project also uses Microsoft Office tools:

• To produce the CSV files that define the post-processing data. Indeed, excel is an handy 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 informations about the final part of 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.