Solving an optiSLang Setup

To analyze an optiSLang setup within Electronics Desktop:

• From the Project Manager, right-click a setup and select Analyze.

  

Considerations for Using the Analyze All Command

The Analysis > Analyze All command solves all projects in a design, including Optimetrics setups. For more information, see Running More Than One Simulation.

Before using the Analyze All command, remove any unnecessary analysis setups from the project.

Some reasons for doing so:

• During regular DSO run mode, optiSLang creates Optimetics DSO design tables. By leaving just one setup for analysis, there is no ambiguity about which analysis setup is associated with any new table.
• Numerical convergence settings steer the performance trade-off between speed and accuracy. If a small number of designs take exceptionally long to converge, it can make a substantial performance difference whether designs are solved independently or in groups (DSO jobs). In group jobs, one slowly converging simulation can delay the entire group. This increases the importance of upper bounds on iterations for mesh refining, interpolation point addition, and so on.
• The unintended presence of Optimetrics setups (including optiSLang setups) can lead to long execution times. When used intentionally, however, Optimetrics setups can be used to define parametric sweeps. These sweeps are easy to set up and represent the sweep per design as a nested system in optiSLang. Note that reports must be adjusted accordingly, so that data is drawn from the entire sweep and not a single point, in order to reach the optiSLang database.
• Analysis setups contain settings that drastically impact the resulting file and folder sizes (for example, the Save Fields check box). If saved fields consume disk space in the range of gigabytes for a single project, then the creation of hundreds of design folders with solution data by optiSLang can quickly fill a hard drive.

Considerations for Distributed Analysis

There are additional considerations for using Distributed Analysis and Large-Scale DSO to analyze optiSLang setups.

• Using the AEDT node's run mode "regular DSO" is not the only way to create DSO jobs. Also in run mode "single simulation" DSO jobs can be spawned. For example, due to the Analyze All command, a user-created pre-existing Optimetrics setup could be solved for every one of optiSLang's design evaluations.
• The integration node's Designs Per Execution setting can work with HPC and DSO settings for AEDT solvers in many different ways. If set to 4, optiSLang can send four designs per AEDT call when AEDT is geared at solving four design variations simultaneously. If Designs Per Execution is set to 9999, however, each optiSLang algorithm will always send all designs waiting in the pipeline at once (a robustness sampling of 1000 designs can be cast into one single DSO job). Using HPC settings, AEDT can still be made to break it down with ntasks=ncores=4. The drawback is that the success/failure info becomes visible in optiSLang only at the very end of the job. A large value for Designs Per Execution can make sense for optimization algorithms demanding design sets of fluctuating size.
• With population-based optimizers, it can be useful to match the population size with compute resources to avoid job load fluctuations.
• Several optiSLang nodes offer the feature to list files to be copied from the reference location into each design folder. However, this may not work for directories. A simple solution is to use a Python node and the shutil.copytree command.
• Avoid redundant solve actions. It may be helpful to copy not only the bare *.aedt file but also the *.aedtresults directory into each design folder. When the AEDT node issues the Analyze All command on the project level, pre-existing solution data can reduce the scope of analysis setups that are triggered to be solved. Compare the time for copying the data of solved projects against the time gain due to less computation. Avoid disc space concerns by activating design directory purging rules to be applied to every design folder after finished evaluation.
• AEDT offers a special type of postprocessing variables. When they are varied while other parameters stay constant, a new design variation can be evaluated with very little computational burden as compared to solving from scratch. The AEDT integration node provides copy functionalities for *.aedtresults folders allowing to benefit from AEDT features around postprocessing variables in certain use cases.

See: Example optiSLang Setups.