2. Purpose of the Model Object

The Model object is characterized as follows:

• It constitutes an access point to a MemCom database containing meshes and solution fields.

• It contains a mesh (nodes and elements) in-memory which is used for instance by the NPart object(s) for mesh extraction, extraction of cuts, of iso-surfaces, etc. A MemCom database may contain many meshes simultaneously, stemming from different computational disciplines, or from different iterations of an optimization. In such cases, the Model object permits to select the mesh to be loaded.

The Model object does not perform any post-processing itself. In particular:

• It is not a container for solution field data. This task is deferred to the Field object.

• It is not responsible for processing and preparing for OpenGL-display of any mesh and solution field data. This task is deferred to the NPart object.

The reasons for this restriction of the Model object are the following:

• Efficient OpenGL-display of 3D data requires the use of dedicated data structures which may occupy a large amount of memory. Specifically for CFD post-processing, only a small subset of the mesh and of the solution field data will be actually displayed in most cases; for instance the wall, the symmetry plane, or a cutting plane, but not the whole volume. Thus, in baspl++, the task of OpenGL-display is deferred to the object which performs the actual extraction and post-processing, the NPart object.

• MemCom databases may contain a very large number of meshes and solution fields, much larger than what would fit in main memory. Thus, it is important to load into memory only the portions of data that are actually needed for post-processing. Solution data is handled by the Field objects which make use of the Model object to access the MemCom database.

The relationships between the different objects are displayed in the following figure: