6. Model Enumerators

In a MemCom database, many different kinds of models, meshes, and coordinate sets may be present simultaneously. If this is not the case, this section and the following section can be skipped.

Having multiple models present in a database creates the problem of identifying of and distinguishing between them. This is dealt with the concept of enumerators. There is a fixed number of enumerators, each serving a specific purpose. Enumerators can take different values. The models are identified according to the set of enumerator values.

To make the understanding of the following easier, here is a short definition of what comprises a Model:

  • A set of coordinates. In baspl++, these are nodal coordinates.

  • A set of element connectivities and element properties. Together with the set of coordinates, this defines a "mesh".

  • A description of the solution fields. For instance, this may define that "TEMPERATURE" is a solution field which is defined at the nodes, while "HEATFLUX" is a solution field defined at sampling points inside the element. This description depends on the computational discipline (CFD, CSM, CHT, etc.) and on the solver. For instance, a CFD solver making use of turbulence model may define additional solution fields.

In the following, all supported Model enumerators are described. Depending on the database in question, not all of the enumerators described here may be displayed.

  • GENERATION: For databases containing results of a genetic optimization run, this enumerator identifies the generation (or optimization iteration). It is assumed that the mesh may be altered for each generation (geometry, element properties, etc.).

  • VARIANT: When using a genetic optimization algorithm, there may be several variants per-generation present in the database. This enumerator identifies the variant. It is assumed that the mesh may be altered for each variant (geometry, element properties, etc.).

  • DISCIPLINE: A goal function used in an optimization strategy might take into account the results from several computational disciplines. For instance, an aero-elastic optimization would make use of a CFD and a CSM analysis. In this case, the values for the DISCIPLINE enumerator would be "CFD" and "CSM". The disciplines may have different meshes, element properties, and solution fields. For instance, a "PRESSURE" field could have a different meaning and type for the "CFD" discipline than for the "CSM" discipline.

  • MESHCYCLE: For nonlinear analyses making use of mesh adaptation (CFD analysis where shock phenomena are of importance, for instance), this enumerator identifies the mesh (coordinates, element connectivities, and possibly the element properties). It then replaces the CYCLE iterator of the Field object. In contrast to the GENERATION, VARIANT, and DISCIPLINE enumerators, the meaning of the solution fields does not change with the MESHCYCLE enumerator.

  • COORCYCLE: For nonlinear analyses where the coordinates are changed but neither the element connectivities, the element properties, nor the meaning of the solution fields, this enumerator identifies the coordinates set. A typical example is that of an aero-elastic analysis where the CFD coordinates are updated at each aero-elastic iteration. The COORCYCLE enumerator would then indicate the aero-elastic iteration.

Enumerators may take the values that are present on the database; if an enumerator is defined but not used, it takes the value "None". In Python, this corresponds to the special value None.

There are also enumerators for solution fields, see Section 3. The values of these Field enumerators always depend on the values of the Model enumerators; thus the Model enumerators are higher in the hierarchy than the Field enumerators.

In addition, there are enumerators internally used by baspl++ to distinguish between different branches, element types, materials, etc. They are not visible in the graphical user interface, nor are they accessible from the Python environment.