Using Multi-Model optimization with reflective symmetry in OptiStruct


In OptiStruct, Multi-Model Optimization (MMO) is a technique that can be used to optimize models that have different configurations for a similar design space.  Examples for this would be models with shared common structure, but in different states such as open and closed doors, as well as models with separate modules that have common designable regions.

 

To define reflective symmetry within an MMO topology optimization model, pattern repetition should be used.  This is because pattern grouping, where one-plane symmetry is usually defined in an OptiStruct topology optimization, is not supported with MMO.

 

Across the optimization models, the design space IDs need to match to be mapped in the MMO.  For topology optimization, this means that the DTPL card IDs should match for the linked design variables.

 

In both models, the MAIN and SECOND lines for the DTPL cards need to be defined.  These can be set in HyperMesh through the pattern repetition option for the design space. 

 

To define reflective symmetry in each model, the coordinate systems for the mapping should be defined with the COORD continuation line.  Importantly, to map reflective symmetry across a plane with the COORD line, nodes should be created which define a left-handed and right-handed system for the symmetry.

 

Here are example DTPL cards for two optimization models used in MMO containing a constraint for reflective symmetry.

 

Model 1:

 

DTPL    1       PSOLID  1      

+       MEMBSIZ 10.0   

+       MAIN   

+       COORD          0    9876                    9880               

+                           9877                    9879                

DTPL    2       PSOLID  2      

+       SECOND         1

+       COORD          0    9876                    9880               

+                           9878                    9879               

+       SCALE        1.0     1.0     1.0

 

Model 2:

 

DTPL    1       PSOLID  1      

+       MEMBSIZ 10.0   

+       MAIN   

+       COORD          0    9876                    9880               

+                           9877                    9879               

DTPL    3       PSOLID  2      

+       SECOND         1

+       COORD          0    9876                    9880               

+                           9878                    9879               

+       SCALE        1.0     1.0     1.0

 

The IDs for the main design variables for pattern grouping match, which ensure that the optimization results will be the same for those IDs.  The secondary IDs do not match, so they are not mapped directly with MMO.  However, the COORD line defines the coordinate systems for the mapping inside each model, and the SCALE on the SECOND entries scales the secondary result for the DTPL by 1.0 in X, Y, and Z.

 

For the coordinate systems, four grid points are defined to build the system.  An example for one of the models is shown below, with the locations of the grid points for reference.  Grid points are used because they allow the creation of inverted left and right-handed coordinate systems, which are necessary for symmetry with pattern grouping.

 

The DTPL cards reference the coordinate system defined by the same anchor point, first grid, and third grids.  The second grid is different because it defines the positive direction of the y-axis for the system.

 

 

Between the .fem models, the position or IDs of the grids for the system should be updated to account for the orientation and position of the design variables.

 

Here is an example that demonstrates the process to set up MMO for topology optimization with reflective symmetry within the models.  Attached are two model files containing a basic compliance-based topology optimization definition with the DTPL cards above and a main file that calls them for the MMO.  The setup for one model is shown here, with grids for the coordinate systems for reflective symmetry shown.  The design spaces are in blue and yellow.

 

 

 

The other model is translated and rotated relative to the other with a different applied loading direction.  A comparison of the difference between the models is shown here.

 

 

 

To submit the MMO, the OptiStruct run options -mmo -np 3 are used, and the main.fem file that links to the individual optimization model files is selected.  This file contains the ASSIGN card to link the other models together in the optimization.

 

At least 3 MPI processes are required to run this MMO, since there should be a separate process for each optimization model as well as a main MPI process calling them.  The result of the optimization is shown here.

 

 

The optimization results are mapped between the models as well as across the defined reflected systems for symmetry.

 

Next Steps:

More information about running MMO with OptiStruct is available here:

https://help.altair.com/hwsolvers/os/topics/solvers/os/multi_model_optimization_intro_r.htm#multi_model_optimization_intro_r