Ansys optiSLang is one of the newer pieces of software in the Ansys toolkit that was recently acquired along with the company Dynardo. Functionally, optiSLang provides a flexible top-level platform for all kinds of optimization. It is solver agnostic, in that as long as you can run a solver through batch files and produce text readable result files, you can use said solver with optiSLang. There are also some very convenient integrations with many of the Ansys toolkit solvers in addition to other popular programs. This includes AEDT, Workbench, LS-DYNA, Python, MATLAB, and Excel, among many others.
While the ultimate objective is often to simply minimize or maximize a system output according to a set of inputs, the complexity of the problem can increase dramatically by introducing constraints and multiple optimization goals. And of course, the more complicated the relationships between variables are, the harder it gets to adequately describe them for optimization purposes.
Much of what optiSLang can do is a result of fitting the input data to a Metamodel of Optimal Prognosis (MOP) which is a categorical description for the specific metamodels that optiSLang uses. A user can choose one of the included models (Polynomial, Moving Least Squares, and Ordinary Kriging), define their own model, and/or allow optiSLang to compare the resulting Coefficients of Prognosis (COP) from each model to choose the most appropriate approach.
The COP is calculated in a similar manner as the more common COD or R2 values, except that it is calculated through a cross-validation process where the data is partitioned into subsets that are each used only for the MOP calculation or the COP calculation, not both. For this reason, it is preferred as a measure for how effective the model is at predicting unknown data points, which is particularly valuable in this kind of MOP application.
This whole process really shows where optiSLang’s functionality shines: workflow automation. Not only does optiSLang intelligently select the metamodel based on its applicability to the data, but it can also apply an adaptive method for the improvement of the MOP. It will suggest an automatic sampling method based on the number of problem variables involved, which can then be applied towards refining either the global COP or the minimum local COP. The automation of this process means that once the user has linked optiSLang to a solver with appropriate inputs/outputs and defined the necessary run methodology for optimization, all that is left is to click a button and wait.
As an example of this, we will run through a test case that utilizes the ability to interface with Ansys EDT Icepak.
Figure 1: The EDT Icepak project model.
For our setup, we have a simple board mounted with bodies representative of 3 x 2 watt RAM modules, and 2 x 10 watt CPUs with attached heatsinks. The entire board is contained within an air enclosure, where boundary conditions are defined as walls with two parametrically positioned circular inlets/outlets. The inlet is a fixed mass flow rate surface and the outlet is a zero-pressure boundary. In our design, we permit the y and z coordinates for the inlet and outlet to vary, and we will be searching for the configuration that minimizes the resulting CPU and RAM temperatures.
The optiSLang process generally follows a series of drag-and-drop wizards. We start with the Solver Wizard which guides us through the options for which kind of solver is being used: text-based, direct integrations, or interfaces. In this case, the Icepak project is part of the AEDT interface, so optiSLang will identify any of the parameters defined within EDT as well as the resulting report definitions. The Parametric Solver System created through the solver wizard then provides the interfacing required to adjust inputs while reading outputs as designs are tested and an MOP is generated.
Figure 2: Resulting block from the Solver wizard with parameters read in from EDT.
Once the parametric solver is defined, we drag and drop in a sensitivity wizard, which starts the AMOP study. We will start with a total of 100 samples; 40 will be initial designs, and 60 will be across 3 stages of COP refinement with all parameter sets sampled according to the Advanced Latin Hypercube Sampling method.
Figure 3: Resulting block from the Sensitivity wizard with Advanced Latin Hypercube Sampling.
The results of individual runs are tabulated and viewable as the study is conducted, and at the conclusion, a description of the AMOP is provided with response surfaces, residual plots, and variable sensitivities. For instance, we can see that by using these first 100 samples, a decent metamodel with a COP of 90% is generated for the CPU temperature near the inlet. We also note that optiSLang has determined that none of the responses are sensitive to the ‘y’ position of the outlet, so this variable is automatically freed from further analysis.
Figure 4: MOP surface for the temperature of Chip1, resulting from the first round of sampling.
If we decide that this CoP, or that from any of our other outputs, is not good enough for our purposes, optiSLang makes it very easy to add on to our study. All that is required is dragging and dropping a new sensitivity wizard onto our previous study, which will automatically load the previous results in as starting values. This makes a copy of and visually connects an output from the previous solver block to a new sensitivity analysis on the diagram, which we can then be adjusted independently.
For simplicity and demonstration’s sake, we will add on two more global refinement iterations of 50 samples each. By doing this and then excluding 8 of our 200 total samples that appear as outliers, our “Chip1” CoP can be improved to 97%.
Figure 5: A refined MOP generated by including a new Sensitivity wizard.
Now that we have an MOP of suitable predictive power for our outputs of interest, we can perform some fast optimization. By initially building an MOP based on the overall system behavior, we are now afforded some flexibility in our optimization criteria. As in the previous steps, all that is needed at this point is to drag and drop an optimization wizard onto our “AMOP Addition” system, and optiSLang will guide us through the options with recommendations based on the number of criteria and initial conditions.
In this case, we will define three optimization criteria for thoroughness: a sum of both chip temperatures, a sum of all RAM temperatures, and an average temperature rise from ambient for all components with double weighting applied to the chips. Following the default optimization settings, we end up with an evolutionary algorithm that iterates through 9300 samples in about 14 minutes – far and away faster than directly optimizing the Icepak project. What’s more, if we decide to adjust the optimization criteria, we’ll only need to rerun this ~14 minute evolutionary algorithm.
What we are most interested in for this example are the resulting Pareto fronts which give us a clear view of the tradeoffs between each of our optimization criteria. Each of the designs on this front can easily be selected through the interface, and their corresponding input parameters can be accessed.
Figure 6: Pareto front of the “Chipsum” and “TotalAve” optimization criteria.
Scanning through some of these designs also provides a very convenient way to identify which of our parameters are limiting the design criteria. Two distinct regions can be identified here: the left region is limited by how close we are allowing the inlet fan to be to the board, and the right region is limited by how close to the +xz corner of our domain the outlet vent can be placed. In a situation where these parameters were not physically constrained by geometry, this would be a good opportunity to consider relaxing parameter constraints to further improve our optimization criteria.
As it is, we can now choose a design based on this Pareto front to verify with the full solver. After choosing a point in the middle of the “Limited by outlet ‘z’” zone, we find that our actual “ChipSum” is 73.33 vs. the predicted 72.78 and the actual “TotalAve” is 17.82 vs. the predicted 17.42. For this demonstration, we consider this small error as satisfactory, and a snapshot of the corresponding Icepak solution is shown below.
Figure 7: The Icepak solution of the final design. The inlet vent is aligned with the outlet side’s heatsink, and the outlet vent is in the corner nearest the heatsink. Primary flow through the far heatsink is maximized, while a strong recirculating flow is produced around the front heatsink.
The accuracy of these results is of course dependent not only on how thoroughly we constructed the MOP, but also the accuracy of the 3D solution; creating mesh definitions that remain consistently accurate through parameterized geometry changes can be particularly tricky. Though, with all of this considered, optiSLang provides a great environment for not only managing optimization studies, but displaying the results in such a way that you can gain an improved understanding of the interaction between input/output variables and their optimization criteria.
