ANSYS ACT Developers Guide

ANSYS ACT Developer's Guide
ANSYS, Inc.
Southpointe
2600 ANSYS Drive
Canonsburg, PA 15317
ansysinfo@ansys.com
http://www.ansys.com
(T) 724-746-3304
(F) 724-514-9494
Release 16.2
July 2015
ANSYS Customization Suite
ANSYS, Inc. is
certified to ISO
9001:2008.
Copyright and Trademark Information

2015 SAS IP, Inc. All rights reserved. Unauthorized use, distribution or duplication is prohibited.
ANSYS, ANSYS Workbench, Ansoft, AUTODYN, EKM, Engineering Knowledge Manager, CFX, FLUENT, HFSS, AIM
and any and all ANSYS, Inc. brand, product, service and feature names, logos and slogans are registered trademarks
or trademarks of ANSYS, Inc. or its subsidiaries in the United States or other countries. ICEM CFD is a trademark
used by ANSYS, Inc. under license. CFX is a trademark of Sony Corporation in Japan. All other brand, product,
service and feature names or trademarks are the property of their respective owners.
Disclaimer Notice
THIS ANSYS SOFTWARE PRODUCT AND PROGRAM DOCUMENTATION INCLUDE TRADE SECRETS AND ARE CONFIDENTIAL AND PROPRIETARY PRODUCTS OF ANSYS, INC., ITS SUBSIDIARIES, OR LICENSORS. The software products
and documentation are furnished by ANSYS, Inc., its subsidiaries, or affiliates under a software license agreement
that contains provisions concerning non-disclosure, copying, length and nature of use, compliance with exporting
laws, warranties, disclaimers, limitations of liability, and remedies, and other provisions. The software products
and documentation may be used, disclosed, transferred, or copied only in accordance with the terms and conditions
of that software license agreement.
ANSYS, Inc. is certified to ISO 9001:2008.
U.S. Government Rights

For U.S. Government users, except as specifically granted by the ANSYS, Inc. software license agreement, the use,
duplication, or disclosure by the United States Government is subject to restrictions stated in the ANSYS, Inc.
software license agreement and FAR 12.212 (for non-DOD licenses).
Third-Party Software
See the legal information in the product help files for the complete Legal Notice for ANSYS proprietary software
and third-party software. If you are unable to access the Legal Notice, please contact ANSYS, Inc.
Published in the U.S.A.
Table of Contents
Introduction ............................................................................................................................................... 1
Add-Ins and Customization ..................................................................................................................... 1
Defining the Extension Concept .............................................................................................................. 1
Project and Extensions ............................................................................................................................ 2
Defining an Extension ................................................................................................................................ 3
Basic Extension Definition ....................................................................................................................... 3
XML Extension Definition ........................................................................................................................ 6
Python Callbacks for Extensions .............................................................................................................. 6
Customizing an Application .................................................................................................................... 7
Extensions and Libraries ......................................................................................................................... 8
Using Extensions ...................................................................................................................................... 11
Extension Types .................................................................................................................................... 11
Loading and Unloading Extensions ....................................................................................................... 11
Installing and Uninstalling an Extension ................................................................................................ 13
Compiling an Extension ........................................................................................................................ 15
Generation Options for Extensions Handling ......................................................................................... 17
Licensing ................................................................................................................................................... 21
Extension Capabilities .............................................................................................................................. 23
Common Capabilities ........................................................................................................................... 23
Defining Toolbars and Toolbar Buttons ............................................................................................ 23
Binding Toolbar Buttons with ACT Objects ...................................................................................... 26
Defining Pop-up Dialogs ................................................................................................................. 27
Storing Data in Your Extension ........................................................................................................ 28
ACT-Based Properties ........................................................................................................................... 29
Creating Property Groups ............................................................................................................... 29
Using PropertyGroup and PropertyTable ................................................................................... 29
Using Templates to Create Property Groups ............................................................................... 33
Parameterizing Properties ............................................................................................................... 34
Common Property Parameterization Processes .......................................................................... 34
Parameterization in ANSYS Mechanical ..................................................................................... 35
Defining Input Parameters in ANSYS Mechanical ................................................................. 35
Defining Output Parameters in ANSYS Mechanical .............................................................. 36
Parameterization in ANSYS DesignModeler ............................................................................... 37
Parameterization in a Third-Party Solver .................................................................................... 39
Defining Parameters under a Load in a Third-Party Solver .................................................... 39
Defining Parameters in Analysis Settings in a Third-Party Solver ........................................... 39
Defining Parameters under Results in a Third-Party Solver .................................................... 40
Defining DesignXplorer Properties .................................................................................................. 40
Properties in the DX Interface ................................................................................................... 40
Additional Attributes for DX Extensions ..................................................................................... 42
Advanced Usage Examples ....................................................................................................... 42
Managing Dependencies between Properties ..................................................................... 42
Controlling Property Visibility with a Callback ...................................................................... 42
DOE Example ................................................................................................................ 43
Optimization Example .................................................................................................. 43
Modifying an Attribute with a Callback ................................................................................ 43
DOE Example ................................................................................................................ 44
Optimization Example .................................................................................................. 44
Capabilities for ANSYS Mechanical ........................................................................................................ 44
Adding a Pre-Processing Feature in ANSYS Mechanical .................................................................... 44
Release 16.2 - SAS IP, Inc. All rights reserved. - Contains proprietary and confidential information
of ANSYS, Inc. and its subsidiaries and affiliates.
iii

Adding a Post-Processing Feature in ANSYS Mechanical .................................................................. 50
Creating Results with Imaginary Parts ............................................................................................. 56
Obsolete OnStartEval and GetValue Callbacks ............................................................................. 56
Connecting to a Third-Party Solver .................................................................................................. 57
Third-Party Solver Connection Extension ................................................................................... 57
Post Processing ........................................................................................................................ 61
Load and Save Data .................................................................................................................. 62
Capabilities for ANSYS DesignModeler .................................................................................................. 65
Geometry Definition in the XML File ................................................................................................ 65
Geometry Definition in the Python File ........................................................................................... 67
Functions Associated with the <ongenerate> Callback .............................................................. 68
Functions Associated with the <onaftergenereate> Callback ..................................................... 70
Capabilities for ANSYS DesignXplorer ................................................................................................... 71
The Design Exploration Process ....................................................................................................... 72
The DX Component .................................................................................................................. 73
The DOE Component .......................................................................................................... 74
The Optimization Component ............................................................................................. 74
The DX Extension ..................................................................................................................... 75
Implementing a DX Extension ......................................................................................................... 75
Implementation Requirements ................................................................................................. 75
DX Extension Definition and Configuration ............................................................................... 75
DX Extension Capabilities ......................................................................................................... 78
Main Capabilities ................................................................................................................ 78
Optional Capabilities .......................................................................................................... 79
Notes on Method Class Implementation .......................................................................................... 80
Notes on Monitoring ................................................................................................................ 80
Notes on Results ....................................................................................................................... 81
Capabilities for Custom ACT Workflows in Workbench ........................................................................... 82
The Custom Workflow Creation Process ........................................................................................... 83
Creating the Extension Definition XML File ...................................................................................... 84
Defining a Task ......................................................................................................................... 86
Defining a Taskgroup ................................................................................................................ 89
Creating the IronPython Script ........................................................................................................ 89
Upstream Data Consumption (Input) ......................................................................................... 89
Data Generation (Output) ......................................................................................................... 89
Convenience APIs ..................................................................................................................... 90
Capabilities for ANSYS AIM .................................................................................................................... 90
Adding a Pre-Processing Feature in ANSYS AIM Structural ................................................................ 90
Custom Load Definition in the XML File .................................................................................... 91
Custom Load Definition in the Python File ................................................................................ 91
Creating a Custom Object to Merge Existing AFD Features (Process Compression) ........................... 94
Fluidic System Definition in the XML File ................................................................................... 94
Fluidic System Definition in the IronPython File ......................................................................... 95
Custom Guided Processes ........................................................................................................................ 99
Types of Guided Processes .................................................................................................................... 99
Creating Guided Processes .................................................................................................................. 100
Parts of a Guided Process .............................................................................................................. 100
The XML Extension Definition File ................................................................................................. 100
Example: XML Extension File for a Project Wizard ..................................................................... 101
The IronPython Script ................................................................................................................... 105
Example: IronPython Script for a Project Wizard ....................................................................... 105
The Custom Help Files ................................................................................................................... 107
iv

Wizard Help ........................................................................................................................... 107
Custom Template Help ........................................................................................................... 108
Installing and Loading Guided Processes ............................................................................................. 108
Using Guided Processes ...................................................................................................................... 109
Using a Workbench or Target Application Wizard ........................................................................... 109
Launching a Wizard ................................................................................................................ 109
The Wizard Interface ............................................................................................................... 110
Entering Data in a Wizard ........................................................................................................ 111
Exiting a Wizard or Project ....................................................................................................... 112
Using an AIM Custom Template ..................................................................................................... 112
Entering Data in a Custom Template ........................................................................................ 113
Accessing Custom Help ........................................................................................................... 115
Viewing the Guided Process Log File ............................................................................................. 115
APIs Description ..................................................................................................................................... 117
APIs for ANSYS Mechanical .................................................................................................................. 117
Directly Accessing an Object ......................................................................................................... 118
Handling Property Types ............................................................................................................... 118
API Examples: Model Object .......................................................................................................... 118
Geometry: Point Mass ............................................................................................................. 119
Mesh: Mesh Control ................................................................................................................ 119
Connections: Frictionless Contact and Beam ............................................................................ 120
Analysis: Load Magnitude ........................................................................................................ 120
Result: Total Deformation Maximum ........................................................................................ 122
API Examples: TraverseExtension ................................................................................................... 123
Traversing the Geometry ......................................................................................................... 123
Traversing the Mesh ................................................................................................................ 125
Traversing Results ................................................................................................................... 126
User Interface and Toolbars ........................................................................................................... 128
APIs for ANSYS Design Modeler ........................................................................................................... 128
Using the Selection Manager in DesignModeler ............................................................................ 128
Working with the Current Selection ........................................................................................ 129
Creating a New Selection and Adding Entities ......................................................................... 129
Creating Primitives ........................................................................................................................ 129
Creating a Sheet Body ............................................................................................................. 130
Creating a Wire Body .............................................................................................................. 131
Creating a Solid Body .............................................................................................................. 132
Applying Operations ..................................................................................................................... 133
Applying the Extrude Operation .............................................................................................. 134
Applying the Transform Edges to Wire Tool .............................................................................. 135
APIs for ANSYS DesignXplorer ............................................................................................................. 136
DOE APIs ...................................................................................................................................... 136
DOE Architecture .................................................................................................................... 136
The Sampling Process ............................................................................................................. 137
Optimization APIs ......................................................................................................................... 138
Optimization Architecture ....................................................................................................... 138
The Optimization Process ........................................................................................................ 139
Associated Libraries ................................................................................................................................ 141
Query to Material Properties ............................................................................................................... 141
Units Conversion ................................................................................................................................ 142
MAPDL Helpers ................................................................................................................................... 144
Journaling Helper ............................................................................................................................... 145
XML Extension Definition ....................................................................................................................... 147

<extension> Element .......................................................................................................................... 147
<GUID> Element .......................................................................................................................... 148
<script> Element .......................................................................................................................... 148
<interface> Element ..................................................................................................................... 148
<images> Element ................................................................................................................. 149
<callbacks> Element ............................................................................................................... 149
<toolbar> Element ................................................................................................................. 152
Child Elements .................................................................................................................. 153
<workflow> Element .................................................................................................................... 154
<tasks> Element ..................................................................................................................... 154
<task> Element ................................................................................................................ 154
<callbacks> Element ................................................................................................... 155
<contextsmenus> Element ......................................................................................... 156
<propertygroup> Element .......................................................................................... 156
<property> Element ................................................................................................... 157
<parameters> Element ............................................................................................... 158
<inputs> Element ....................................................................................................... 159
<outputs> Element .................................................................................................... 159
<taskgroups> Element ............................................................................................................ 159
<taskgroup> Element ....................................................................................................... 160
<simdata> Element ...................................................................................................................... 161
<load> Element ...................................................................................................................... 161
<callbacks> Element ......................................................................................................... 162
<property> Element ......................................................................................................... 167
<callbacks> Element ................................................................................................... 169
<propertygroup> Element ................................................................................................ 171
<propertytable> Element ................................................................................................. 172
<result Element> .................................................................................................................... 172
<solver> Element ................................................................................................................... 177
<sampling> Element .............................................................................................................. 181
<OnCreate> and <OnRelease> Callbacks .......................................................................... 183
<canRun> and <QuickHelp> Callbacks .............................................................................. 184
<optimizer> Element .............................................................................................................. 185
<OnCreate> and <OnRelease> Callbacks .................................................................... 188
<canRun> and <QuickHelp> Callbacks ........................................................................ 188
<Description>, <Configuration>, and <Status> Callbacks ............................................. 190
XML File Definition ............................................................................................................................. 191
Development and Debugging Tips ......................................................................................................... 199
Prerequisites ....................................................................................................................................... 199
Debug Mode ...................................................................................................................................... 199
ACT Console Extension ....................................................................................................................... 202
Debugging an Extension ..................................................................................................................... 203
vi

Debugging with Microsoft Visual Studio ...................................................................................... 204
Using Python Tools for Visual Studio ............................................................................................ 204
Advanced Programming in C# ................................................................................................................ 207
Initialize the C# Project ........................................................................................................................ 207
C# Implementation for a Load ............................................................................................................. 207
C# Implementation for a Result ........................................................................................................... 208
Limitations .............................................................................................................................................. 211
Examples ................................................................................................................................................. 213
ANSYS Mechanical Extension Examples ............................................................................................... 213
Von-Mises Stress as a Custom Result .............................................................................................. 213
An Edge-Node Coupling Tool ........................................................................................................ 217
DesignXplorer Extension Examples ..................................................................................................... 222
DOE Extension Examples .............................................................................................................. 222
Optimization Extension Examples ................................................................................................. 222
Custom ACT Workflows in Workbench Examples .................................................................................. 223
Custom User-Specified GUI Operation ........................................................................................... 223
XML Extension Defintion File ................................................................................................... 223
IronPython Script .................................................................................................................... 224
Custom, Lightweight, External Application Integration with Parameter Definition ........................... 224
XML Extension Definiton File ................................................................................................... 225
Custom, Lightweight, External Application Integration with Custom Data ....................................... 228
XML Extension Definiton File ................................................................................................... 228
Material Transfer ........................................................................................................................... 231
XML Extension Definition File .................................................................................................. 232
Material File ............................................................................................................................ 233
Mesh Transfer ............................................................................................................................... 234
Custom Transfer ............................................................................................................................ 236
Parametric .................................................................................................................................... 239
Custom Guided Process Examples ....................................................................................................... 240
Workbench Project Wizard ............................................................................................................ 240
Target Application Wizard (DesignModeler) ................................................................................... 246
Target Application Wizard (Mechanical) ......................................................................................... 250
Mixed Wizard ................................................................................................................................ 254
AIM Custom Template ................................................................................................................... 260
vii

Defining Custom Help ................................................................................................................... 263
A. ANSYS Workbench Task Inputs and Outputs ........................................................................................... 265
B. Data Transfer Types ................................................................................................................................ 317
viii
Introduction
Add-Ins and Customization
ANSYS Workbench is built on a modular architecture that allows you to extend the functionality of the
framework using add-in development.
The ANSYS Workbench Framework Software Developer's Kit (SDK) is designed to manage data and
workflow, allowing you to integrate ANSYS tools with third-party applications at the framework level.
In contrast, the Application Customization Toolkit (ACT) is designed to allow customizations at the application level. These customizations are done with the goal of inserting specific needs within one
general process. Using ACT in the ANSYS Mechanical application, the customizations include specialized
loads and post processing. You can also use ACT to customize ANSYS DesignModeler, ANSYS
DesignXplorer, and ANSYS AIM. Both ACT and the SDK are part of the ANSYS Customization Suite.
ACT provides internal mechanisms that allow you to customize an ANSYS Workbench application without
needing to compile external code or link with existing ANSYS libraries.
ACT manages the interfaces between the standard application and the additional customization so that
they will interact accurately.
This document describes the steps for creating a custom application, or extension, with ACT. The examples
use ANSYS Mechanical, ANSYS DesignModeler, ANSYS DesignXplorer, and ANSYS AIM as the target applications.
The examples shown are basic ones and intended as a primer. Note that the development of extensions
requires some knowledge of IronPython and XML. For extensions that customize the ANSYS solver,
knowledge of APDL is also required.
The examples included were written and tested on all Windows platforms.
Defining the Extension Concept

ACT provides the ability to create extensions that integrate a set of customized features with the
standard application. This Developer's Guide is primarily intended for those developing the extensions
that provide additional capabilities to ANSYS tools. However, this guide also includes information for
the end user who will be managing the extensions.
ACT can manage an entire set of extensions. When desired, the ANSYS Mechanical, DesignModeler,
DesignXplorer, and AIM applications can be customized by loading a set of extensions. In that case,
each extension provides its own customization level, and the end user can define a personal configuration based on the extensions previously loaded in ANSYS Workbench. Consequently, the level of customization is directly dependent on the choices that the end user made before opening the customized
application.
For more detailed information on defining extensions, see Defining an Extension (p. 3).
Introduction
Project and Extensions

Once the ANSYS Workbench project has been created and saved using extensions developed using
ACT, any further use of the project must integrate any previously used extensions. If these extensions
are available, then ANSYS Workbench loads the extensions automatically when the project is opened.
In the case where an expected extension has not been detected, then an error message occurs. The
availability of extensions is discussed in more detail in Defining an Extension (p. 3).
Defining an Extension
ACT has two basic components:
XML is used to define and configure the content of the extension.
Python script functions are used to respond to user/GUI interactions and implement the behavior of the
extensions. Typically, the Python functions are invoked through the different events or callbacks managed
by the extension.
An extension can potentially be created using additional components such as external Python libraries
or even C# code. However, the two components described above represent the basic definition for an
extension.
Basic Extension Definition

This section refers to a simple extension ExtSample that customizes the ANSYS Mechanical application.
Depending on the application to be customized, the content of the extension differs but the main organization of an ACT extension remains consistent with the one presented in this section whatever the
targeted application.
This extension adds a toolbar with one button to the user interface of ANSYS Mechanical. When this
button is clicked, a dialog box appears and displays the message "High five! ExtSample1 is a success!".
Figure 1: Extension Configuration File Hierarchy (p. 4) illustrates the ExtSample1 configuration. Note
that the XML file ExtSample1.xml a nd the ExtSample1 folder lie at the same level in a given folder.
A common name has to be used for both the XML file and the folder of the extension.
Figure 1: Extension Configuration File Hierarchy
The next figure shows the contents of the ExtSample1 folder. The file sample1.py contains the Python
script needed to fulfill the behavior of the example extension and the images folder holds the icon file
used by the GUI of the extension.
Basic Extension Definition

Figure 2: Extension Folder Content
Figure 3: Images Folder Content (p. 5) shows the contents of the images folder. The icon file hand.bmp
is used by the example extension to expose the specific button from the toolbar. The BMP image format
is the only format supported by the ACT.
Figure 3: Images Folder Content
XML Extension Definition

The XML file used to configure the ExtSample1 extension is named ExtSample1.xml. The contents
of this file are listed below.
<extension version="1" name="ExtSample1">
<guid>e0e0f6c2-b50f-425e-a778-5b3e527f65c1</guid>
<script src="sample1.py" />
<interface context="Mechanical">
<images>images</images>
<callbacks>
<oninit>init</oninit>
</callbacks>
<toolbar name="ExtSample1" caption="ExtSample1">
<entry name="HighFive" icon="hand">
<callbacks>
<onclick>HighFiveOut</onclick>
</callbacks>
</entry>
</toolbar>
</interface>
</extension>
Key elements of the XML file include:

The extension name in line 1
The GUID of the extension in line 2
The Python script file name in line 3
The interface context in line 4
The oninit callback method name in line 7
The toolbar and toolbar button definition in lines 9 through 15
The <entry> tags define the HighFive toolbar button, which uses the icon image from the file
hand.bmp. The <onclick> tags define the name of the callback function to invoke when the button
is selected. The next section addresses the Python script definition of the function HighFiveOut.
The XML extension definition is discussed in more detail in Using Extensions (p. 11).
For more information on the GUID, see Installing and Uninstalling an Extension (p. 13), Compiling an
Extension (p. 15), and <extension> Element (p. 147).
Python Callbacks for Extensions

Python script functions are used to respond to user/GUI interactions and implement the extensions
behavior. As previously discussed, the Python script for ExtSample1 is located inside the file
sample1.py.Here are the script file contents.
clr.AddReference("Ans.UI.Toolkit")
clr.AddReference("Ans.UI.Toolkit.Base")
from Ansys.UI.Toolkit import *
def init(context):
ExtAPI.Log.WriteMessage("Init ExtSample1...")
def HighFiveOut(analysis_obj):
MessageBox.Show("High five! ExtSample1 is a success!")
The script contains two functions:
Customizing an Application
The function init() is called when the application (for example, Mechanical) is opened. The argument
context contains the name of the application (Mechanical).
The function HighFiveOut() is called when the user clicks the toolbar button HighFive. As with all
<onclick> callback functions, the application passes an instance of the active Analysis object as an
argument.
For any function, the global variable ExtAPI represents the main entry point for all the services provided
by ACT. As an example, the init() function uses the ILog interface of the ACT to write one message
in the log file. For more information on the available interfaces, see the Application Customization Toolkit
Reference Guide.
Customizing an Application
In the following figure, the ExtSample1 extension toolbar and HighFive button are now part of the
ANSYS Mechanical user interface. The context of this extension has been set to Mechanical. Consequently, this extension was loaded with the Mechanical application. You can refer to Using Extensions (p. 11) for more information about the load of extensions.
Figure 4: ExtSample1 Toolbar
The next figure shows an open extension log that demonstrates that ExtSample1 was initialized for
the Mechanical application context.
Figure 5: ExtSample1 Extension Log
Extensions and Libraries

As you develop extensions to integrate customizations in the application, you can use additional libraries
to share Python functions between extensions. Some libraries are installed by default with ACT to help
developers customize the application.
Supported libraries related to the Mechanical application are located in the following folder:
%ANSYSversion_DIR%\..\Addins\AdvancedAddinPackage\libraries\Mechanical
Supported libraries related to the AIM application are located in the following folder:
%ANSYSversion_DIR%\..\Addins\AdvancedAddinPackage\libraries\Study
The libraries included with ACT are described below:
ansys.py
Provides helpers to generate an APDL command block.
chart.py
Provides helpers to generate charts, such as curves and histograms.
materials.py
Provides a set of generic functions to convert data from one unit system to another.
wbjn.py
Provides a tool to communicate data to and from the Workbench project page.
Extensions and Libraries

For more information on these libraries, refer to Associated Libraries (p. 141).
10
Using Extensions
From the main menu in Workbench, ACT provides a set of capabilities to handle the extensions. This
section describes these capabilities in detail. Using these capabilities, you have the ability to work with
the extensions as needed during the development and use phases.
Extension Types
ACT handles two different types of extensions. The following sections describe the scripted extensions
comprised of XML and IronPython functions. Another type is binary, resulting from the build of a
scripted extension. In essence, the development phase uses scripted extensions. Once those extensions
are complete, the binary extensions are shared by the developer with other users. The way these extensions can be used is explained more in detail in Licensing (p. 21).
Loading and Unloading Extensions

Extensions are loaded with an application if they are pre-selected in the Workbench Extension Manager
tool. Note that this pre-selection is done automatically for extensions that were loaded and saved with
the project. In that case, the extensions to be automatically loaded must be available to the Extension
Manager. If an extension is not found, an error message is written in the Messages window of the main
Workbench project page and the AIM Messages tab. An example message is shown in Figure 6: Error
Message Generated by ACT (p. 11). The message is repeated each time an extension is found.
Figure 6: Error Message Generated by ACT
The Extension Manager tool is available from the Manage Extensions menu, shown below.
Figure 7: Manage Extensions Menu
11
Using Extensions
Figure 8: Extension Manager (p. 12) shows the Extension Manager, which lists the available extensions.
Both binary and scripted extensions are listed in this menu. In addition to the name of the extension,
the type and version specified in the XML file are also displayed.
Figure 8: Extension Manager
To load an extension, check the Loaded check box for the extension. For binary extensions, it is also
possible to selected the Load option from the context menu by right-clicking a binary extension, shown
in Figure 9: Binary Extension Loading (p. 12).
Figure 9: Binary Extension Loading
To unload an extension, uncheck the Loaded check box or select the Unload option from the rightclick context menu.
You can select a set of extensions to be loaded by default in the Extension Manager. These extensions
are automatically loaded when ANSYS Workbench is launched. The selection of default extensions is
done by selecting Load as Default from the right-click context menu. Both scripted and binary extensions
are available for this selection. There is no limit to the number of extensions which can be loaded by
default. Figure 10: Default Extensions (p. 13) shows two extensions configured to be loaded by default.
For these two extensions, the (Default) label is added to the extension name and the Loaded check
box is automatically checked.
12
Installing and Uninstalling an Extension

Figure 10: Default Extensions
To remove an extension from the list of extensions to be automatically loaded, select the extension
and select Do Not Load as Default from the right-click context menu, as illustrated in Figure 11: Removing a Default Extension (p. 13).
Figure 11: Removing a Default Extension
The Extension Manager identifies the available extensions based on the directories defined in the ACT
options. For information on how to add directories to this list, see Generation Options for Extensions
Handling (p. 17).
The default directories used by the Extension Manager are:
%ANSYSversion_DIR%\..\Addins\AdvancedAddinPackage\extensions
%APPDATA%\Ansys\v162\AdvancedAddinPackage\extensions
Installing and Uninstalling an Extension

From the Install Extension menu, you can select a binary extension, a WBEX file, for installation.
To install a binary extension:
1. In the Project Schematic window, select Extensions > Install Extension.
13
Using Extensions
2. A file selection dialog opens and shows files that end in .wbex.
3. Select the WBEX file for the extension you want to install and select Open.
Extensions installed this way are located in the current users Application Data folder and are available
for loading through the Extension Manager.
Note
When a binary extension is installed, a new folder is created in addition to the WBEX file.
Both the folder and the WBEX file are necessary for compatibility with ACT. If you need to
move this new extension to a different folder, make sure that both the folder and the WBEX
file are copied at the same time to the same folder.
Figure 12: Install Extension menu
To uninstall an extension, select the extension in the Extension Manager and select the Uninstall option
in the right-click context menu, as shown in Figure 13: Uninstalling an Extension (p. 14).
Figure 13: Uninstalling an Extension
The process for uninstalling extensions is only available for binary extensions. To uninstall scripted extensions, delete the associated files and directories related to the extension. If you remove a scripted
extension while the Extension Manager is running, it will not appear the next time the Extension Manager
is launched.
14
Compiling an Extension
Compiling an Extension
Compiling an extension means encapsulating a scripted extension into a binary format. This process
does not require you to use a specific compiler. ACT provides its own process for migrating the extension
to a binary format unreadable by any other user. The encapsulation of the scripted extension, also called
the build of the binary extension, generates a unique WBEX file. This file contains all the files or directories necessary for the extension. Once the extension is built, it must be installed before it can be used.
Installing and Uninstalling an Extension (p. 13) explains how to install a binary extension. The Binary
Extension Builder is available from Extensions > Build Binary Extension, as shown below.
Figure 14: Build Binary Extension Menu
The Binary Extension Builder allows you to define all the required input parameters for building an extension. Figure 15: Binary Extension Builder Interface (p. 15) illustrates the dedicated window that appears
when the user selects the Build Binary Extension option. When all expected input parameters are
defined, the Build button is activated.
Figure 15: Binary Extension Builder Interface
The Scripted Extension to Build option is populated with a list of scripted extensions from directories
defined in the ACT options. Both the name and the version are displayed in the list to avoid any confusion
when multiple versions of one extension are present. Generation Options for Extensions Handling (p. 17)
exposes this process in more detail.
15
Using Extensions
Figure 16: Contextual List of Scripted Extensions
Once the scripted extension is defined, you must identify a directory where the binary extension will
be stored. The final required parameter defines a security level. This security level defines if the extension
can be saved within an ANSYS Workbench project, and thus, when that project is shared, if the extensions
can be loaded with the shared project. This security level enables the developer of the extension to
control how the extension can be shared along their use with various projects. With the option Can
copy extension to project, each time a user asks to save this extension with a project, the extension
itself is copied into the project and consequently is available each time this project is opened. This extension can also be used with other projects. However, if you select Can copy extension to project
but locked to this one, the extension can be saved within a project, as with the previous option, but
the use of the extension is limited to the current project. If a user opens a new project, this extension
is not available. If you select Can't copy extension to project, the extension is not saved with the
project and is not shared with other users with the project. Note that the extension can be sent in addition to the project. The process for saving extensions within a project is described in Generation Options
for Extensions Handling (p. 17). Note that these security options only apply if the user wants to save
the extension with the project, and are otherwise not applicable.
When all parameters are defined, the Build button is available, and you can launch the creation of the
binary extension. The bottom part of the window displays build information as illustrated below.
16
Generation Options for Extensions Handling

Figure 17: Binary Extension Generation

From the main Tools > Options menu, you can define a set of dedicated options for ACT. When you
select Extensions in the left pane of the main Options window, you can define the three properties
used to configure ACT.
Figure 18: Options Menu
17
Using Extensions
Figure 19: Extensions Options
The first option, Additional Extension Folders, provides the ability to define additional folders in which
ACT will search for extensions in order to expose them in the Extension Manager. You can define several folder names, separated by a semi-colon (;). These folders are in addition to the two folders used
by default. These two default folders are the default installation folder for extensions:
%ANSYSversion_DIR%\..\Addins\AdvancedAddinPackage\extensions
and the user's Application Data folder:
%APPDATA%\Ansys\version\AdvancedAddinPackage\extensions
Because these folders are searched for extensions by default, the Extension Manager contains any extensions located in them.
During the scan of the available extensions, the folders are analyzed in following order:
1. The application data folder.
2. The installation folder.
3. Additional folders defined in the Additional Extension Folders option.
During this process, warning messages are returned for any conflicts; these messages are also logged
in the ACT log file.
The second property in the Extensions Options specifies if the extensions should be saved when the
project is saved. Figure 20: Save Extensions Option (p. 19) shows the available options for this property.
18

Figure 20: Save Extensions Option
If you choose Never, the current loaded extensions are not saved within the project.
If you choose Copied but locked to the project, the extensions are saved within the project but are
limited to that project.
If you choose Always, the extensions are saved within the project and no restriction exists as to their
use in other projects. This option represents what most users expect when the project is saved. However,
note that this behavior is dependent on the security options of the extension defined by the developer,
as described in Compiling an Extension (p. 15). In particular, the following scenarios can occur:
The extension was built with the security option set to Cant copy extension to project and the user set
the save option to Always or Copied but locked to the project. In that case, the security option has the
priority and the user will not have the extension saved in the project.
The extension was built with the security option set to Can copy extension to project but locked to this
one and the user set the save option to Always. Although the save option does not impose any restriction
for the extension, the security level will limit the use of the extension for the current given project.
The third property allows you to activate Debug mode. When activated, this mode allows the developer
to debug the scripted extension. In addition, the Debug mode exposes one additional feature in the
toolbar of the main project page that enables to reload the extension once a modification has been
done in a script. This feature is similar to the feature 1 described below. When the ANSYS Mechanical
application is used, the Debug mode exposes two additional features in Mechanical that will help you
debug the extension under development. These two features are available from a new toolbar in
Mechanical.
19
Using Extensions
For more information on debugging capabilities, see Debug Mode (p. 199).
20
Licensing
ACT development is licensed, but binary extension usage is not. In other words, developers creating
new extensions must have a license. However, once the extension is built, a license is not required to
run it.
The ACT license enables two main capabilities, which are:
The ability to build an extension in the Binary Extension Builder. The ACT license is checked out when the
build is launched and is released once the build has been completed.
The ability to load a scripted extension. As a consequence, only the binary extensions can be loaded when
no ACT license is available. No matter the number of scripted extensions that are loaded, only one ACT license
is checked out. This license is released once all the scripted extensions have been unloaded from the Extension
Manager.
Note
If an ACT license is already checked out by a loaded scripted extension, the build operation
will not require a second ACT license to run.
21
22
Extension Capabilities
In the introductory chapter, the sample extension ExtSample1 was used to describe the fundamental
elements of an extension. The ExtSample1 extension demonstrated how to create a toolbar which
contains a button that responds by calling a Python scripted function. This chapter expands on this
description and introduces the main capabilities an extension can address.
This chapter divides extension capabilities in to the following categories:
Common Capabilities
ACT-Based Properties
Capabilities for ANSYS Mechanical
Capabilities for ANSYS DesignModeler
Capabilities for ANSYS DesignXplorer
Capabilities for Custom ACT Workflows in Workbench
Capabilities for ANSYS AIM
Common Capabilities
ACT provides customization capabilities that are common to all target applications: ANSYS Mechanical,
ANSYS DesignModeler, ANSYS DesignXplorer, and ANSYS AIM.
This section discusses the following common capabilities:
Defining Toolbars and Toolbar Buttons
Binding Toolbar Buttons with ACT Objects
Defining Pop-up Dialogs
Storing Data in Your Extension
Defining Toolbars and Toolbar Buttons

This section is focused on applications that expose their own toolbars and toolbar buttons that can be
customized using the methodology explained below. The ANSYS Mechanical application is used for
demonstration purposes.
A toolbar serves as a parent container for one or more toolbar buttons. Conceptually the toolbar should
address a specific feature wherein each toolbar button's focus is on a function that supports the feature.
This relationship is reflected in the structure of the XML that defines a toolbar and its buttons. Below
is the XML from the ExtToolbarSample extension.
The ExtToolbarSample extension adds two toolbars, Toolbar1 and Toolbar2. Each toolbar has
three distinct buttons.
<extension version="1" minorversion="0" name="ExtToolbarSample">
<script src="toolbarsample.py" />
<callbacks>
</callbacks>
<toolbar name="ToolBar1" caption="ToolBar1">
<entry name="TB1Button1" icon="button1Red">
23
<callbacks>
<onclick>OnClickTB1Button1</onclick>
</callbacks>
</entry>
<callbacks>
</callbacks>
</entry>
<callbacks>
</callbacks>
</entry>
</toolbar>
<toolbar name="Toolbar2" caption="Toolbar2">
<entry name="TB2Button1" icon="button1Blue">
<callbacks>
</callbacks>
</entry>
<callbacks>
</callbacks>
</entry>
<callbacks>
</callbacks>
</entry>
</toolbar>
</interface>
</extension>
The ExtToolbarSample extension adds two toolbars, Toolbar1 and Toolbar2. Each toolbar has
three buttons, as shown in Figure 21: User-Defined Toolbars in Mechanical (p. 24).
Figure 21: User-Defined Toolbars in Mechanical
24
Common Capabilities
The XML example defines two toolbar elements. Each element starts with a begin tag <toolbar
name="..." caption="..."> and ends with a terminal tag </toolbar>. The toolbar element
has two attributes, name and caption. The name attribute is required and is used for internal references.
The caption attribute is the text displayed in the application.
The button entry elements define the buttons in the toolbar. Each button entry element starts with
a begin tag <entry name="..." icon="..."> and ends with a terminal tag </entry>. The
entry element has two attributes: name and icon. The name attribute is required and is used for
internal references. The name is also displayed as a tooltip. The icon attribute is the name of the icon
file mapped on to the button.
The entry element for each button is parent to a callbacks element. The <callbacks> element
encapsulates element(s), which are named on the basis of an event. For instance, the name specified
by the onclick element, <onclick>name</onclick>, provides the name of the Python function
to be called when the button is selected.
Referring again to the XML in the above code, the second line:
<script src="toolbarsample.py" />
defines the name of the Python script file for the ExtToolbarSample extension, toolbarsample.py,
the contents of which are shown below. By default, ACT will look for the Python script file in the directory
of the extension. If the Python script file is located in a different directory, an explicit path to the file
must be inserted into the extension XML file.
import os
import datetime
def init(context):
ExtAPI.Log.WriteMessage("Init ExtToolbarSample ...")
def OnClickTB1Button1(analysis):
LogButtonClicked(1, 1, analysis)
def LogButtonClicked(toolbarId, buttonId, analysis):
now = datetime.datetime.now()
outFile = SetUserOutput("ExtToolbarSample.log", analysis)
f = open(outFile,'a')
f.write("*.*.*.*.*.*.*.*\n")
f.write(str(now)+"\n")
f.write("Toolbar "+toolbarId.ToString()+" - Button "+buttonId.ToString()+" Clicked. \n")
f.write("*.*.*.*.*.*.*.*\n")
f.close()
MessageBox.Show("Toolbar "+toolbarId.ToString()+" - Button "+buttonId.ToString()+" Clicked.")
def SetUserOutput(filename, analysis):
25
solverDir = analysis.WorkingDir
return os.path.join(solverDir,filename)
Each button in ExtToolbarSample has a unique callback function. Each callback function passes the
toolbar ID and the ID of the button pressed to the function LogButtonClicked, which stores them
in the variables toolbarId and buttonId. These variables are referenced within the function where
their string values are written. The functions LogButtonClicked and SetUserOutput demonstrate
how to reduce redundant code in callbacks using utility functions. The Analysis object is passed to
each <entry> callback and then used in the SetUserOutput function to query for the working
directory of the analysis. The script in toolbarsample.py makes use of the datetime namespace
from the .NET framework. The datetime namespace exposes a class also called datetime. LogButtonClicked invokes datetime to query the current date and time and stores the result in the variable
name now. The str() utility is used to extract the string definition of the variable now to write out
the date and time.
Binding Toolbar Buttons with ACT Objects

ACT provides the ability to bind a button from the ACT toolbar with an ACT object created in the tree
of the application. This capability allows you to control the contextual availability of the buttons depending on the object selected in the tree. This method is similar to the control used for standard objects
in Mechanical. The connection between the ACT object and the ACT button is made using the userobject tag in the entry element of the interface definition in the XML file. The following code
demonstrates this type of connection for a result object:
<toolbar name="My_Toolbar" caption="My_Toolbar">
<entry name="Button_For_My_Result icon="result" userobject="My_Result">
</entry>
</toolbar>
</interface>
<simdata context="Mechanical">
<result name="My_Result" version="1" caption="My_Result" icon="result" location="elemnode"
type="scalar">
</result>
</simdata>
As an example, if the ACT button is bound with an ACT load in Mechanical, then this button is activated
only if the object is selected in the Mechanical environment; otherwise it is inactive.
In the same way, if the ACT button is bound with an ACT result in Mechnical, this button is active only
if the object is selected in the solution; otherwise it is inactive.
For any ACT object bound to a button, the <onclick> callback is not used.
Based on the above example, Figure 22: Selecting an Environment Object (p. 27) and Figure 23: Selecting
a Solution Object (p. 27) illustrate the GUI behavior based on selection of an object in the tree.
26
Common Capabilities
Figure 22: Selecting an Environment Object
Figure 23: Selecting a Solution Object
In addition to the control provided by the connection between the ACT button and the ACT object,
the <canadd> callback can be implemented to add new criteria to be considered for the activation
and deactivation of the button. If the <canadd> callback of the object returns false, the associated
button is deactivated. A typically example consists of filtering a particular analysis type to activate a
specific load.
Defining Pop-up Dialogs

This section discusses pop-up dialogs using the ExtDialogSample extension as an example.
ExtDialogSample defines a new menu labeled DialogSample with one menu item labeled GetFilename. ExtDialogSample demonstrates how to open a file dialog and display a message window in
the user interface.
The XML for the ExtDialogSample extension, shown below, is similar to the XML used for the
ExtToolbarSample extension.
<extension version="1" minorversion="0" name="ExtDialogSample">
<script src="dialogsample.py" />
<callbacks>
</callbacks>
<toolbar name="DialogSample" caption="DialogSample">
27
<entry name="DialogSample1" caption="GetFilename">
<callbacks>
<onclick>GUIToolbarOpenFile</onclick>
</callbacks>
</entry>
</toolbar>
</interface>
</extension>
The callback function specified in the XML for the GetFilename menu button is GUIToolbarOpenFile.
Here is the Python script from the file dialogsample.py.
def init(context):
ExtAPI.Log.WriteMessage("Init ExtDialogSample ...")
def GUIToolbarOpenFile(analysis):
filters = "txt files (*.txt)|*.txt|All files (*.*)|*.*"
dir = "c:\\"
res = FileDialog.ShowOpenDialog(ExtAPI.UserInterface.MainWindow, dir, filters, 2,
"ExtDialogSample","")
if res[0]==DialogResult.OK:
message = str("OPEN selected -> Filename is "+res[1])
else:
message = "CANCEL selected -> No file"
MessageBox.Show(message)
When GUIToolbarOpenFile is invoked, an instance of a modal file-selection dialog is created by

calling FileDialog.ShowOpenDialog. The class FileDialog is provided by the UI Toolkit. The
user inputs the necessary information in this dialog. When the user clicks the Open or Cancel buttons,
the file-selection dialog closes and this information is returned to GUIToolbarOpenFile. The returned
information is then used to create a message-box dialog. The message displayed in the message-box
dialog validates the result returned from the file-selection dialog.
Storing Data in Your Extension

Two mechanisms are available to store data in your extension. These mechanisms are based on the
<onload>/<onsave> callbacks or on attributes. These mechanisms are available for any application
using ACT.
The <onsave> callback is called each time the target application saves the project. Consequently, this
callback allows the creation of dedicated files to store data, in addition to the standard ANSYS Workbench
project.
The <onload> callback is called each time the application loads the project. The process here is similar
to the previous <onsave> callback, but is now devoted to reading in additional data.
Attributes represent a very interesting way to store data, as this method does not require the creation
of new external files.
Attributes are defined by name and content. The content can be simply defined by a single value such
as an integer, or a double, or with more complex data. The content must be serializable. To accomplish
this, implement the serialization interface provided by .Net. Types such as integer, double, list,
and dictionary are serializable by default.
Attributes are automatically saved and resumed with the project. Attributes can be associated with an
extension, an ACT load or result, and a property.
28
Attributes are created or edited with the method:
Attributes["attribute_name"] = attribute_value
and the content can be retrieved with the method:

attribute value = Attributes["attribute_name"]
Below is an example of an attribute associated with a property:

prop.Attributes["MyData"] = 2
val = prop.Attributes["MyData"]
Below is a similar example for an attribute associated with a load:

load.Attributes["MyData"] = 2
val = load.Attributes["MyData"]
Below is a similar example for an attribute associated with an extension:

ExtAPI.ExtensionMgr.CurrentExtension.Attributes["MyData"] = 2
v = ExtAPI.ExtensionMgr.CurrentExtension.Attributes["MyData"]
Note that an attribute associated with an extension can be shared between applications using the same
extension. For example, two Mechanical sessions can share data.
The command to store the attribute in a shared repository is as follows:
ExtAPI.ExtensionMgr.CurrentExtension.SetAttributeValueWithSync("MyData", 2.)
In the same way, the command to retrieve the content stored in a shared repository is:
ExtAPI.ExtensionMgr.CurrentExtension.UpdateAttributes()
v = ExtAPI.ExtensionMgr.CurrentExtension.Attributes["MyData"]
ACT has the ability to create customized objects that encapsulate ACT-based properties. This section
discusses how to use ACT to create properties.
The following topics are discussed:
Creating Property Groups
Parameterizing Properties
Defining DesignXplorer Properties
Creating Property Groups

This section focuses on the process of creating groups of properties.
The following methods are available:
Using PropertyGroup and PropertyTable
Using Templates to Create Property Groups
Using PropertyGroup and PropertyTable

This section focuses on the process of creating groups of properties via PropertyGroup and PropertyTable.
PropertyGroup and PropertyTable are special types of properties that can be used to create
groups of properties with a given caption. In this way, it is possible to manage dependencies between
29
properties and to create worksheet views from a property.The PropertyGroup type encapsulates a
list of child properties under one group.
The PropertyTable type encapsulates a list of child properties under one table. Each child property
creates a new column in the table and the user is able to control the line number of this table.
These functionalities are demonstrated into the AdvancedProperties extension.
The first example shows how to create a group of properties with a caption. The group can be collapsed
or expanded by the user. The Simple group with caption group is shown below.
Figure 24: Details Pane with Group Definition
This group is created with the following XML code:

<propertygroup name="Group1" caption="Simple group with
<property name="Prop1" caption="Prop1" control="text"
</propertygroup>
caption" display="caption">
/>
/>
/>
The property group has a special attribute, display. In this case, this attribute is set to caption,
which means all the children properties are displayed under the caption. If the caption attribute is
omitted, then the display attribute is set to hidden and the property group is hidden.
The second example illustrates how to show or hide properties according to the value of another selected
property.
As shown in Figure 25: Contextual Content for Groups (p. 31), the visibility of the properties is dependent
on the value of the Group Select property as defined above.
30
Figure 25: Contextual Content for Groups
This group is created with the following XML code, which creates dependencies between properties:
<propertygroup name="Group2" caption="Another group" display="caption">
<propertygroup name="Group3" caption="Group Select" display="property" control="select"
default="Option 1">
<attributes options="Option 1,Option 2,Option 3" />
<property name="Prop1" caption="Prop For Option 1" visibleon="Option 1" control="text" />
<property name="Prop2" caption="Prop For Option 1 and Option 2"
visibleon="Option 1|Option 2" control="text" />
</propertygroup>
</propertygroup>
In this case, the attribute display is set to property. The PropertyGroup Group3 defines a
standard ACT property which provides additional capabilities for all the children properties.
Each child property can specify an attribute visibleonwhich can take a value or a set of values. If
the current value of the parent property fits with the visibleon attribute, then the property is displayed; otherwise, the property is hidden.
The example below demonstrates how to create properties that open a worksheet each time the user
needs access to the content of the properties. The PropertyTable type is used for such an application.
This type of property is of particular interest as it allows you to create a worksheet that exposes a set
of properties for your customization.
31
In order to facilitate the development, ACT already provides some predefined worksheets. Two different
types of worksheets are currently available:
Time-dependent worksheet: The row number of this worksheet is initialized with the number of steps
defined in the AnalysisSettings object. If the user of the extension adds or removes time steps
in the AnalysisSettings object, the worksheet is automatically updated. Consequently, this type
of worksheet represents an efficient way to manage time-dependent data within an extension.
Figure 26: Time-Dependent Worksheet
This worksheet is created with the following XML code:

<propertytable name="TimeDep" caption="TimeDependent" display="worksheet" control="applycancel"
class="Worksheet.TimeFreqTabularData.TFTabularData">
<property name="Step" caption="Step" control="integer" readonly="true" />
<property name="Time" caption="Time" control="float" readonly="true" />
<property name="Temperature" caption="Temperature" unit="Temperature" control="float"></property>
<property name="Pressure" caption="Pressure" unit="Pressure" control="float"></property>
</propertytable>
In this example, the display attribute is set to worksheet. In addition, the class attribute is used
to specify the name of the IronPython class that is used to manage the worksheet. For this given application, the TFTabularData class is used. This class is defined in the file TimeFreqTabularData.py
located into the libraries/Mechanical/Worksheet folder, which is part of the standard ACT
installation.
The properties Step and Time integrate a specific treatment, as they are automatically populated with
the information specified in the AnalysisSettings object. These two properties are optional.
Non-fixed row dimension worksheet: For the second type of worksheet, the array is empty by default.
The user can add a new line by clicking on the top left button as illustrated below.
Figure 27: Non-Fixed Row Dimension Worksheet
This worksheet is created with the following XML code:
32
<propertytable name="Worksheet" caption="Non-Fixed row count" display="worksheet" control="applycancel"
class="Worksheet.PropertyGroupEditor.PGEditor">
<propertygroup name="TempOrPres" caption="TempOrPres" display="property" control="select"
default="Temperature">
<attributes options="Temperature,Pressure" />
<property name="Temperature" caption="Temperature" unit="Temperature" control="float"
visibleon="Temperature"></property>
<property name="Pressure" caption="Pressure" unit="Pressure" control="float"
visibleon="Pressure"></property>
</propertygroup>
<property name="Scoping" caption="Scoping" control="scoping">
<attributes selection_filter="face|edge" />
</property>
<property name="FileName" caption="FileName" control="fileopen">
<attributes filters="Command files (*.bat)|*.bat|All files (*.*)|*.*" />
</property>
</propertytable>
In this example the PGEditor class is used. The PGEditor class is defined in the file PropertyGroupEditor.py, available in the /libraries/Mechanical/Worksheet folder.
You can access the content of the worksheet in the same manner as you do any other standard ACT
property.
Using Templates to Create Property Groups

This section focuses on the process of creating groups of properties via templates.
A template represents a generic method for defining a group of properties with the associated callbacks
code. Basically, you can create a template to provide services that can be integrated into any extension.
For example, you can build a template to generate a property that displays all the available coordinate
systems for the current model.
This template is defined in the file controltemplates.xml located in the templates folder. The
content of this file is presented below.

<controltemplate name="coordinatesystem_selection" version="1">
<property control="select" class="templates.select.SelectCoordinateSystem"></property>
</controltemplate>
First, a name is given to the template. The class SelectCoordinateSystem associated with this
template is defined in the file select.py, located in the /libraries/Mechanical/templates
folder. A template has to be made of one single property. If several properties need to be defined, then
they have to be integrated in a group. The template scoping illustrates a template definition with
different properties.
In order to link this template to a property, the user just needs to fill the control attribute of the
property with the name of the template.
Other examples are available in the file /templates/Mechanical/controltemplates.xml.
To be sure, the advanced user will find benefit in using the templates. The templates currently integrated
in ACT can be enriched so that the customized environment will enable always more complex customization in a very efficient way.
33
Parameterizing Properties
When defining ACT properties in ANSYS Mechanical and ANSYS DesignModeler, it is also possible to
define the property value as either an input or an output parameter (all ACT parameters are inputs,
unless you specify otherwise in the definition). Once parameterized, the property is sent to ANSYS
Workbench for inclusion in the Parameter Set, where it behaves and is treated as any other parameter.
You can incorporate parameters in a variety of places in your analysis.
In ANSYS Mechanical, parameters can be defined for any ACT object, regardless of its location in the tree.
In ANSYS DesignModeler, parameters can be incorporated into a number of custom ACT-based features,
such as renaming selected bodies, specifying geometry generation details like as material, dimensions, etc
.
In a third-party solver implemented by ACT, parameters can be incorporated into the load, analysis settings,
and result.
All combinations of ACT-based and standard parameters are supported:
ACT input(s) and standard output(s)
ACT input(s) and ACT output(s)
Standard input(s) and ACT output(s)
Common Property Parameterization Processes

To define a property as a parameter, you must add the tag isparameter to the XML file and set it
to true. By default, it will be created as an input parameter. To further specify that the property will
be an output parameter, you must also add the tag readonly and set it to true. The following sections
will use sample code segments to illustrate the creation of input and output parameters.
When you define a property as a parameter, keep in mind that it is not selected for parameterization
(i.e. it is not be parameterized) by default. Defining a property as a parameter only makes parameterization possible by adding a check box to the user interface. In order to actually parameterize the property,
the user must select the check box provided by the ACT tag.
Once a property has been selected for parameterization, it will automatically be sent to the Parameter
Set (accessed on the ANSYS Workbench Project Schematic), where it will be displayed in both the
Outline of All Parameters and the Table of Design Points. Output parameters are read-only, but these
two Parameter Set tables provide the same level of control over the definition of ACT input parameters
as is available for standard, non-ACT inputs. For example:
The user can change the unit of the parameterized input property; the unit proposed will respect the type
of unit specified in the XML file.
The user can add a design point for the input parameter by clicking in the bottom row of the Table of
Design Points.
The user can modify the value of a design point by selecting an input parameter and entering a new value.
However, the type of value must respect the one specified in the XML file. As such, design point values in
the previous value must be floats, and cannot be strings.
34
When the user has finished setting up the system and has finished working with parameters and design
point values (there should be at least one input and one output parameter), he can solve the problem
by updating the design points from the Parameter Set.
Parameterization in ANSYS Mechanical

The following sections provide examples and methods for integrating ACT parameters into your ANSYS
Mechanical model.
In ANSYS Mechanical, it is possible to define ACT-based property values as either input parameters or
output parameters. This section addresses how to implement a parameter on an ACT object in the
ANSYS Mechanical applicationspecifically, how to parameterize loads, results, and userobjects. ACT
objects in any of these categories will behave and interact with parameters in exactly the same way.
The following sections provide examples and methods for integrating ACT parameters into your ANSYS
Mechanical model.
Defining Input Parameters in ANSYS Mechanical
Defining Output Parameters in ANSYS Mechanical
Defining Input Parameters in ANSYS Mechanical

To define a property as a parameter, add the tag isparameter to the XML file and set it to true.
For example, the following code segment creates a property named float_unit. The property will
be a pressure and its value will be a float.
<property name="float_unit" caption="float_unit" control="float" unit="Pressure" isparameter="true"/>
Note
Other tags such as default, isload, etc. could be added, as well.
The isparameter tag adds a check box to the user interface, making it possible for the user to select
the property for parameterization.
Once the property has been selected for parameterization, it will automatically be displayed in both
Outline of All Parameters and the Table of Design Points in the Parameter Set.
35
The code sample below is extracted from the XML file of the extension used in the previous example.
You can see how the property definition of our float_unit property is incorporated into the file.
<load name="CustomPressure" version="1" caption="CustomPressure" icon="tload" support="false"
isload="true" color="#0000FF">
<callbacks>
<getsolvecommands order="1">writeNodeId</getsolvecommands>
</callbacks>
<property name="Geometry" caption="Geometry" control="scoping">
<attributes selection_filter="face"/>
</property>
<property name="float_unit" caption="float_unit" control="float" unit="Pressure" isparameter="true"/>
</load>
Defining Output Parameters in ANSYS Mechanical

It is also possible to define an ACT property as an output parameter.
The process for making a property available as a parameter is the same as for any input parameter (by
adding the isparameter tag and setting it to true); a check box allowing parameterization of the
property will become available. To specify that the property will be an output parameter, you must also
add the readonly tag to the XML file and set it to true.
For example, the following code segment creates a property named MyOutPutProperty. As in the
previous example, the property will be a pressure and its value will be a float. Because it includes the
readonly tag set to true, however, this property can be parameterized only as an output parameter.
<property name="MyOutPutProperty" caption="MyOutPutProperty" control="float" unit="Pressure"
readonly=true isparameter="true"/>
Note
Other tags such as default, isload, etc. could be added, as well.
36
Again, the user must select the check box provided by the ACT tag to actually parameterize the property.
Once the property has been selected for parameterization, the corresponding output will automatically
be generated in the Outline of All Parameters table in the Parameter Set.
In addition, by default the minimum and maximum values of an ACT result object are available to become
output parameters. This capability is not managed by the ACT extension, but takes advantage of the
Mechanical environment.
Parameterization in ANSYS DesignModeler

In ANSYS DesignModeler, it is possible to define ACT-based property values only as input parameters.
This section addresses how to implement an input parameter on an ACT object in the ANSYS DesignModeler application.
As with any other input parameter, to add an input to ANSYS DesignModeler you must added the isparameter tag to the XML file and set it to true. (You will not be able to add output parameters;
the readonly tag is not available for ANSYS DesignModeler).
For example, in an ACT feature that generates a cylinder, you can add length as a parameter. The following XML code segment defines this Length parameter.
<geometry name="MyFeatureWithParameters" caption="MyFeatureWithParameters"
icon="Construction" version="1">
<callbacks>
<ongenerate>generateMyFeature</ongenerate>
</callbacks>
<property name="Length" caption="Length" control="float" isparameter="true"></property>
</geometry>
The resulting check box next to the Length property allows the user to parameterize Length as an input
parameter.
37
You could add a static structural analysis based on the previous Geometry template by adding an
output parameter in the Static Structural analysis. This results in the schematic workflow shown below:
The input parameter defined in ANSYS DesignModeler will be managed in exactly the same way as
other any other input parameter. In the Outline of All Parameters table in Parameter Set, the geometry
input parameter will be placed under the Geometry system.
38
Parameterization in a Third-Party Solver

When you have used ACT to deploy a third-party solver, it is possible to define ACT-based properties
as either input parameters or output parameters. This section addresses how to implement a parameter
on an ACT object in an external third-party solverspecifically, under a load, in the analysis settings,
and under results.
The definition of parameters for a third-party solver is no different than the process described in earlier
sections: To parameterize a property, in the property definition you must introduce the isparameter
tag and set it to true; by default, it will be an input parameter. To define it as an output parameter,
you must add the readonly tag and set it to true.
Defining Parameters under a Load in a Third-Party Solver

The process of defining parameters under a load in ANSYS DesignModeler is identical to the process
described in Defining Input Parameters in ANSYS Mechanical (p. 35).
Defining Parameters in Analysis Settings in a Third-Party Solver

It is possible to parameterize the Analysis Settings in a third-party external solver; the settings options
available depend on the definition of the third-party solver.
For example, you can opt to parameterize the maximum number of iterations under Analysis Settings:
The following code segment, placed under the solver section of the XML definition file, defines the
Max. Iterations parameter.
<solver
<property name="MaxIter" caption="Max. Iterations" control="integer" isparameter="true" default="10"/>
</solver>
39
Defining Parameters under Results in a Third-Party Solver

The process of defining parameters under Results in ANSYS Mechanical is identical to the process described in Parameterization in ANSYS Mechanical (p. 35). Results parameters can be either inputs or
outputs, depending on whether the readonly tag is set to true or false.
Defining DesignXplorer Properties

An external sampling or optimization method can expose settings to allow the user to control algorithm
options and view outputs.
For instance:
A DOE can expose the editable setting Number of Levels to allow the user to define this limit. The sampling
will be responsible for handling this setting as needed. The DOE can also expose the read-only setting Actual Number of Points to inform the user, after the sampling is completed, of the number of points generated.
An optimizer can expose the editable setting Maximum Number of Iterations to allow the user to define
this limit. The optimizer will be responsible for handling this setting as needed. The optimizer can also expose
the read-only setting Actual Number of Iterations to inform the user, after the optimization is completed,
of the number of iterations actually performed.
ACT provides support for the general definition of properties with attributes and callbacks. Each setting
to be exposed to the DX user must be declared and defined in the XML file as a <property> element
under the <sampling> or <optimizer> element, as shown in Figure 28: Example of a DX Property
Definition (p. 40).
Figure 28: Example of a DX Property Definition
<property name="[property internal name (string)]"
caption="[property display name (string)]"
readonly="[true | false(default)]"
default="[default value]"
control="[text(default) | select | float | integer | ...]"
visible="[true(default) | false]"
visibleon="[values(separator '|')]"
...
<attributes>mldr</attributes>
<callbacks
</property>
Optionally, settings can be placed together in groups. Each group must be declared and defined in the
XML file as a <propertygroup> element under <sampling> or <optimizer> element.
For a description of common attributes and callbacks, see property under the XML Tags section of
the ACT Reference Guide for DesignXplorer. For more information on settings groups, see propertygroup
under the XML Tags section of the ACT Reference Guide for DesignXplorer.
Properties in the DX Interface

When an external method is selected in the DX (via the Design of Experiments Type menu in the DOE
workspace or the Method Name menu in the Optimization workspace), its properties are shown in the
Properties view.
For example, in Figure 29: DesignXplorer Properties View for External DOE (p. 41) below, we can see
the Properties view when the external sampling named Full Factorial is selected.
40
Figure 29: DesignXplorer Properties View for External DOE
In Figure 30: DesignXplorer Properties View for External Optimizer (p. 41) below, we can see the Properties view when the external optimizer named Python Optimizer is selected.
Figure 30: DesignXplorer Properties View for External Optimizer
By default, properties are shown under the General category. If a propertygroup is specified, the
corresponding category is created in the property view. The properties under the General and the respective Status categories are specific to the external method and are defined in the XML file.
41
Note that if the sampling supports the LogFile capability, the Log File property is automatically
defined under the Status category of the Properties view. Once the sampling is generated optimization
has been run, the user can view the log file in a dialog box by clicking on the available link.
Additional Attributes for DX Extensions

In the context of sampling and optimization extensions, DX also recognizes the additional attributes
min, max, and advanced for each property. The min and max attributes are used to specify a minimum
and/or maximum value for a double or integer property.
In the following sampling example, the minimum value is 1 and the maximum value is 100.
<property name="NumberOfLevels" caption="Number of Levels" control="integer" default="3">
<attributes min="1" max="100"/>
</property>
In the following optimization example, the minimum value is 2 and the maximum value is 200.
<property name="MyNumberOfSamples" caption="My Number of Samples" control="integer" default="50">
<attributes min="2" max="200"/>
</property>
The advanced attribute is used to classify the property as an advanced option. Advanced options are
visible for the user only if activated (in the Workbench user interface, open Tools > Options > Design
Exploration and select the Show Advanced Options check box). The following example is applicable
to either type of DX extension.
<property name="MyRandomNumber" caption="My Random Number provider" control="select"
default="Python">
<attributes options="Python,CLibrary" advanced="true"/>
</property>
Advanced Usage Examples

The following advanced examples illustrate the use of properties in DX extensions.
Managing Dependencies between Properties

The following example demonstrates how to manage the dependency between properties:
Prop1 is visible when Group3 value is equal to Option 1
Prop2 is visible when Group3 value is equal to Option 1 or Option 2
Prop3 is visible when Group3 value is equal to Option 3
<propertygroup name="Group3" caption="Group Select" display="property" control="select"
default="Option 1">
<property name="Prop2" caption="Prop For Option 1 and Option 2" visibleon="Option 1|Option 2"
control="text" />

</propertygroup>
Controlling Property Visibility with a Callback

The attributes, such as the visibility attribute, can be modified dynamically by using a callback.
42
DOE Example
The following example shows how to control the visibility of the PropForSingleInput property
with a callback coded in IronPython:
<property name="PropForSingleInput" caption="My Property for single input parameter"
control="text">
<callbacks>
<isvisible>isVisibleForSingInput</isvisible>
</callbacks>
</property>
Where isVisibleForSingInput is defined by the following IronPython code:

def isVisibleForSingInput(entity,property):
if entity.NumberOfObjectivesDefined <= 1:
return True
return False
The isVisibleForSinglnputfunction takes two arguments:

The first argument-named entity, is of type DXUserSampling.
The second argument-named property is of type SimProperty.
This method returns True when only one input parameter is defined.
Optimization Example
The following example shows how to control the visibility of the PropForSingleObjective property
with a callback coded in IronPython:
<property name="PropForSingleObjective" caption="My Property for single-objective optimization"
control="text">
<callbacks>
<isvisible>isVisibleForSOO</isvisible>
</callbacks>
</property>
Where isVisibleForSOO is defined by the following IronPython code:

def isVisibleForSOO(entity,property):
if property.Name != PropForSingleObjective
return True
if entity.NumberOfObjectivesDefined <= 1:
return True
return False
The isVisibleForSOO function takes two arguments:

The first argument-named entity, is of type DXUserOptimizer.
The second argument-named property is of type SimProperty.
This method returns True when only one objective is defined.
Modifying an Attribute with a Callback

The following examples show how you can modify the values property attributes when input parameters
are edited by the user.
43
DOE Example
This example shows how you can modify the values of the max attribute of the property NumberOfLevels when input parameters are edited by the user.
Given the partial sampling definition:
<sampling >
<callbacks>
<InputParametersEdited>InputParametersEdited</InputParametersEdited>
</callbacks>
<property name="NumberOfLevels" caption="Number of Levels" control="integer" default="3"/>
<attributes min="1">
</property>
</sampling>
The InputParametersEdited function is defined by the following IronPython code:

def InputParametersEdited(entity):
entity.Properties["NumberOfLevels"].Attributes["max"]=3*entity.NumberOfInputParametersDefined
The InputParametersEdited function is called when input parameters are edited by the user. It
calculates the new minimum allowed value for the NumberOfLevels property from the current
number of input parameters and then sets this value to the max attribute.
This example shows how you can modify the values of the min attribute of the property MyNumberOfSamples when input parameters are edited by the user.
Given the partial optimizer definition:
<optimizer >
<callbacks>
<InputParametersEdited>InputParametersEdited</InputParametersEdited>
</callbacks>
<property name="MyNumberOfSamples" caption="My Number of Samples" control="integer" default="50" />
</optimizer>
The InputParametersEdited function is defined by the following IronPython code:

def InputParametersEdited(entity):
entity.Properties["MyNumberOfSamples"].Attributes["min"]=10*entity.NumberOfInputParametersDefined
The InputParametersEdited function is called when input parameters are edited by the user. It
calculates the new minimum allowed value for the MyNumberOfSamples property from the current
number of input parameters and then sets this value to the min attribute.

Adding a Pre-Processing Feature in ANSYS Mechanical
This section discusses customization for the ANSYS Mechanical application only as the targeted application needs to expose pre-processing features natively.
Thus far the discussion has been focused on extending the user interface by adding toolbars. This section
discusses how to use toolbars to perform meaningful operations such as adding a pre-processing feature
to ANSYS Mechanical. The example used in the discussion is defined in the DemoLoad extension. The
DemoLoad extension was written to create a generic load. This example is for demonstration purposes
only.
44

Below are the contents of the DemoLoad.xml file, which adds a load to a project.
As in previous examples, the XML first defines the extension using a version and name attribute. The
path to the Python script file main.py is specified by the <script> tag. The definition of the toolbar
and the buttons is done in the <interface> tag. The callback function named CreateDemoLoad
is used to create and add the load to the simulation environment.
<extension version="1" minorversion="0" name="DemoLoad">
<script src="main.py" />
<toolbar name="Loads" caption="Loads">
<entry name="DemoLoad" icon="tload">
<callbacks>
<onclick>CreateDemoLoad</onclick>
</callbacks>
</entry>
</toolbar>
</interface>
<load name="DemoLoad" version="1" caption="DemoLoad" icon="tload" color="#00FFFF">
<callbacks>
<getnodalvaluesfordisplay>GetNodalValuesForDisplay_DL</getnodalvaluesfordisplay>
<getprecommands>GetPreCommands_DL</getprecommands>
<getsolvecommands order="1">GetSolveCommands_DL</getsolvecommands>
</callbacks>
<attributes selection_filter="edge" />
</property>
<property name="Text" caption="Text" control="text"></property>
<property name="SelectStatic" caption="Select (static)" control="select">
</property>
<property name="SelectDynamic" caption="Select (dynamic)" control="select">
<callbacks>
<onactivate>StringOptions_DL</onactivate>
</callbacks>
</property>
<property name="Double" caption="Double" unit="Length" control="float"
default="1 [m]"></property>
</load>
</simdata>
</extension>
The definition of the load is encapsulated by the <simdata> begin and end tags. The attributes in
the <load> begin tag provide the name, version, caption, icon, and color that apply to this load. The
color attribute is defined in a hexadecimal format. This color is used to contrast the load when it is
displayed on the model. The load <callbacks> tag encapsulates two callbacks <getsolvecommands> and <getnodalvaluesfordisplay>.
The tag <getnodalvaluesfordisplay> specifies the name of the Python function that is called
when the load is displayed in the application.
The tag <getsolvecommands> specifies the name of the Python function that is called when the
solver input file is generated by the application. Consequently, the related Python function is responsible
for generating the APDL commands that describe the load within the ANSYS input file. When get-
45
solvecommands is used, the solver commands are inserted into the solver input file just before the
SOLVE command.
ACT provides two additional tags to better control where the specific solver commands are inserted in
the solver input file.
The tag <getprecommands> inserts the solver commands before the standard loads and boundary conditions defined in the application. For the ANSYS solver, the new commands are inserted in the context of
the /PREP7 preprocessor after the mesh has been written.
The tag <getpostcommands> inserts the solver commands so they are executed after the solution has
been resolved. For the ANSYS solver, the new commands will be inserted in the context of the /POST1
postprocessor after the /POST1 command.
Below the callbacks definition, you can define the properties that will be applied to the actual definition
of the load. These properties are displayed in the Details pane of ANSYS Mechanical, where the user
provides the necessary values to complete the load definition. In the Python script we will see how the
load's properties can be retrieved and / or modified.
The following figure shows that each property defined above appears in the Details pane with the
corresponding names and types of interface control.
Figure 31: Properties in the Details Pane
Note that the two properties, Select (static) and Select (dynamic), use a select control type. The
first property populates the list of options from the XML, while the second one defines an <onactivate> callback. This callback, which is called when the control is activated, populates the available options
for the property. This second approach allows a full control on the options to be exposed in the dropdown menu and makes the list of options dependent on the current status of the project. Many different
situations that can impact the content of the list of options can be addressed, as long as they are implemented in the <onactivate> callback.
46

The next property, Double, does not require the definition of one specific callback. Instead, the XML
definition introduces a physical quantity dependency with the unit option; this option specifies that
this property is consistent with a length. In addition, default value of 1 [m] is introduced with the default option. This default value is exposed in the Details pane each time a new load is created.
Here is the Python script file main.py used for the DemoLoad extension.
import os
def init(context):
ExtAPI.Log.WriteMessage("Init DemoLoads...")
def CreateDemoLoad(analysis):
analysis.CreateLoadObject("DemoLoad")
def StringOptions_DL(load,prop):
prop.ClearOptions()
prop.AddOption("X")
prop.AddOption("Y")
prop.AddOption("Z")
def GetPreCommands_DL(load, stream):
stream.Write("/COM, **************************************************" + "\n")
stream.Write("/COM, Load properties from DemoLoad getprecommands event" + "\n")
stream.Write("/COM, Text Property = " + load.Properties["Text"].ValueString + "\n")
stream.Write("/COM, SelectDynamic Property = " + load.Properties["SelectDynamic"].ValueString + "\n")
stream.Write("/COM, SelectStatic Property = " + load.Properties["SelectStatic"].ValueString + "\n")
stream.Write("/COM, Double Property = " + load.Properties["Double"].ValueString + "\n")
def GetSolveCommands_DL(load, stream):
stream.Write("/COM, Load properties from DemoLoad getsolvecommands event" + "\n")
stream.Write("/COM, Text Property = " + load.Properties["Text"].ValueString + "\n")
stream.Write("/COM, SelectDynamic Property = " + load.Properties["SelectDynamic"].ValueString + "\n")
stream.Write("/COM, SelectStatic Property = " + load.Properties["SelectStatic"].ValueString + "\n")
stream.Write("/COM, Double Property = " + load.Properties["Double"].ValueString + "\n")
def GetNodalValuesForDisplay_DL(load, nodeIds):
dval = load.Properties["Double"].Value
coordselect = load.Properties["SelectDynamic"].ValueString
mesh = load.Analysis.MeshData
values = []
for id in nodeIds:
node = mesh.NodeById(id)
dispval = float(0.0)
if coordselect == "X":
dispval = node.X * float(dval)
elif coordselect == "Y":
dispval = node.Y * float(dval)
elif coordselect == "Z":
dispval = node.Z * float(dval)
else:
dispval = float(0.0)
values.Add(dispval)
return values
The functions GetNodalValuesForDisplay_DL and GetSolveCommands_DL are critical to the

behavior and application of the load. GetNodalValuesForDisplay_DL is called each time the
graphics is refreshed. The required input arguments are load and nodeIds, where load is the load
object for this load, and nodeIds is a list of node identifiers.
In our example, load.Properties["Double"].Value queries for the "Double" property value. nodeIds
contains a list of node numbers on which one value has to be returned by the function. For every node
of the list, the value of the Double property is assigned in the values array representing the output of
the function. This output is subsequently treated by the graphics engine of the application so that the
visualization on the FE model is available.
47
GetSolveCommands is intentionally simplified for this example. The prototype of this function is made
of two input arguments, the load object and the filename in which the new specific solver commands
are written. It is important to note that this output file is only a temporary file, as the content is rewritten
in the final solver input file to ensure that the specific commands related to the customized load are
merged with all the other commands already defined by the standard features of the application.
You can also create a specific set of context menu options. These options use the property Action.
Actions are defined inside the <callbacks> section of the load.
<callbacks>
<ongenerate>generate</ongenerate>
<oncleardata>clearData</oncleardata>
<action name="a1" caption="Action 1" icon="update">action1 </action>
</callbacks>
The <action> tag takes three attributes:

A name to identify your action.
A caption that will be displayed in the context menu.
A name that refers to the picture that will be displayed for the icon. The image must be stored in the directory
specified in the XML file.
The content of the tag defines the name of the Python function that is called when the user clicks on
the associated context menu option.
Figure 32: Customized Context Menu Options (p. 49) below shows the result of the declaration. There
are now two additional context menu items, Action 1 and Action 2.
48

Figure 32: Customized Context Menu Options
As illustrated above, you can also add a Generate context menu option. This option derives from the
standard Generate action provided by Mechanical. For that reason, the declaration of this particular
option differs from the declaration of the options Action1 and Action2. This option is always associated
with the Clear Generated Data option.
These options allow you to create a load that can mimic a standard Imported Load. The callback associated with the Generate option replaces the standard function integrated in Mechanical.
The feature is activated when you define the callback <ongenerate> for the load.
The <ongenerate> callback will be called each time the user clicks on the Generate context menu
item, as well as when the user solves, if the state of the load is set to "not solved."
As for the standard Imported Load object, the <ongenerate> callback will be called only if the mesh
is already generated.
<callbacks>
<ongenerate>generate</ongenerate>
<oncleardata>clearData</oncleardata>
</callbacks>
The associated Python code looks like:

def generate(load, fct):
pct = 0
fct(pct,"Generating data...")
propEx = load.PropertyByName("Expression")
exp = propEx.Value
if exp=="":
49
return False
try:
vexp = compile(exp,'','eval')
except:
return False
values = SerializableDictionary[int,float]()
nodeIds = []
propGeo = load.PropertyByName("Geometry")
refIds = propGeo.Value
mesh = ExtAPI.DataModel.MeshDataByName("Global")
for refId in refIds:
meshRegion = mesh.MeshRegionById(refId)
nodeIds += meshRegion.NodeIds
nodeIds = list(set(nodeIds))
for i in range(0,nodeIds.Count):
id = nodeIds[i]
x = node.X
y = node.Y
z = node.Z
v = 0.
try:
v = eval(vexp)
finally:
values.Add(id,v)
new_pct = (int)((i*100.)/nodeIds.Count)
if new_pct!=pct:
pct = new_pct
stopped = fct(pct,"Generating data...")
if stopped:
return False
propEx.SetAttributeValue("Values",values)
fct(100,"Generating data...")
return True
def clearData(load):
ExtAPI.Log.WriteMessage("ClearData: "+load.Caption)
propEx = load.PropertyByName("Expression")
propEx.SetAttributeValue("Values",None)
The <ongenerate> callback takes two arguments: the load object and a function to manage a progress
bar. This function takes also two arguments: the message to display and the value (between 0 and 100)
of the progress bar.
During the process, the generated data is stored using an attribute on the property Expression. More
details on how to store data are given in section 5.8.
The <oncleardata> callback takes one argument: the load object. This callback is called each time
the mesh is cleaned or when the user selects on the Clean Generated Data context menu option.
Adding a Post-Processing Feature in ANSYS Mechanical

This section discusses customization for the ANSYS Mechanical application only as the targeted application needs to expose post-processing features natively.
This section discusses how to add a post-processing feature to ANSYS Mechanical. The example used
in the discussion is defined in the DemoResult extension, which creates a customized result that
computes the worst value of the principal stresses for the scoped geometry entities. This example is
for demonstration purposes only.
50

Following are the contents of the DemoResult.xml file, which adds a result to a project. As in previous
examples, the XML begins by defining the extension with a version and name attribute. The path to
the Python script file demoresult.py is specified by the <script></script> tag. The <interface> tag defines the toolbar and buttons. The callback function named Create_WPS_Result is
used to create and add the result to the simulation environment.
<extension version="1" minorversion="0" name="DemoResult">
<script src="demoresult.py" />
<callbacks>
</callbacks>
<toolbar name="Stress Results" caption="Extension: Worst Principal Stress">
<entry name="Worst Principal Stress" icon="result">
<callbacks>
<onclick>Create_WPS_Result</onclick>
</callbacks>
</entry>
</toolbar>
</interface>
<result name="Worst Principal Stress" version="1" caption="Worst Principal Stress" unit="Stress"
icon="result" location="elemnode" type="scalar">
<callbacks>
<evaluate>WPS_Eval</evaluate>
</callbacks>
<property name="Geometry" caption="Geometry" control="scoping"></property>
</result>
</simdata>
</extension>
The definition of the result is encapsulated by the <simdata> begin and end tags. The attributes in
the <result> begin tag provide the name, version, caption, icon, and unit that apply to this result.
The result <callbacks> tag encapsulates the single callback <evaluate> used for the evaluation.
The tag <evaluate> gives the name of the Python function that will be called to compute the result
when the application (i.e. presently ANSYS Mechanical) requests an evaluation. The output of this
function is sent directly to Mechanical to display the result.
Below the callbacks definition, you can define the properties that are applied to the actual result
definition. These properties are displayed in the Details pane of ANSYS Mechanical when the user has
selected the result in the Outline pane.
Figure 33: Properties in the Details Pane (p. 52) shows that each property appears in the Details pane
of ANSYS Mechanical with the corresponding names and result values.
51
Figure 33: Properties in the Details Pane
Below are the contents of the Python script file demoresult.py, the script file used for the DemoResult extension. The functions Create_WPS_Result and WPS_Eval are critical to the behavior and
application of the result.
The Create_WPS_Result function creates and adds the result to the simulation environment.
The WPS_Eval function is called during solution or when the results need to be re-evaluated.
The callback function Create_WPS_Result is used to create the result and add it to the simulation
environment. This function uses Python dot notation, which allows you to chain objects with methods
that return objects to each other. In the expression analysis.CreateResultObject("Absolute
Principal Stress"), the IAnalysis object analysis is given in argument of the callback. This IAnalysis
object calls the CreateResultObject method. From CreateResultObject, the XML is interpreted
and the internal mechanisms are set into motion to add the details and register the callbacks that define
the results framework. For more comprehensive descriptions of the API objects, methods and properties,
see the Application Customization Toolkit Reference Guide.
The WPS_Eval function is called when the result needs to be evaluated or re-evaluated, depending
on the state of the simulation environment. The function definition requires the input arguments result
and step and the output argument collector. Result is the result object for this result and stepInfo
is an IStepInfo object that gives information on the step currently prescribed in the details.
WPS_Eval queries for the component stresses at each node of elements. The stress tensor is used the
compute the three principal stresses (eigenvalues), and then the signed maximum value over these
three is stored as the final result for each node of element. WPS_Eval also deals with the conversion
of units. DemoResults uses a utility library called units, which is imported at the beginning of the
demoresults.py file. With this library, WPS_Eval can derive a conversion factor for the stress units
that is consistent with the units used during solution. Note that the result to be returned by the evalu-
52

ation function must be consistent with the international system of unit. Then the potential useful conversion to the current unit system in the application is done internally by ANSYS Workbench. Whenever
the result values for Worst Principal Stress are needed for display purposes, ANSYS Mechanical uses
directly the output of the function WPS_Eval. The two callbacks and their registration to the event
infrastructure of ANSYS Mechanical make possible the full cycle of result definition, creation, evaluation,
and display.
import units
wps_stress = {}
eigenvalues = {}
def init(context):
ExtAPI.Log.WriteMessage("Init Demoresult Extension...")
def Create_WPS_Result(analysis):
ExtAPI.Log.WriteMessage("Launch Create_WPS_Result...")
analysis.CreateResultObject("Worst Principal Stress")
# This function evaluates the specific result (i.e. the Absolute principal stress) on each element
required by the geometry selection
# The input data "step" represents the step on which we have to evaluate the result
def WPS_Eval(result,stepInfo,collector):
global wps_stress
analysis = result.Analysis
ExtAPI.Log.WriteMessage("Launch evaluation of the WPS result: ")
# Reader initialization
reader = analysis.GetResultsData()
reader.CurrentResultSet = stepInfo.set
# Get the stress result from the reader
stress = reader.GetResult("S")
# Unit sytem management:
# First get the unit system that was used during the resolution
# Second compute the coefficient to be used so that the final result will be returned in the
SI unit system
unit_stress = stress.GetComponentInfo('X').Unit
conv_stress = units.ConvertUnit(1.,unit_stress,"Pa","Stress")
# Get the selected geometry
propGeo = result.Properties["Geometry"]
refIds = propGeo.Value.Ids
# Get the mesh of the model
mesh = analysis.MeshData
#Loop on the list of the selected geometrical entities
# Get mesh information for each geometrical entity
elementIds = meshRegion.ElementIds
# Loop on the elements related to the current geometrical entity
for elementId in elementIds:
# Get the stress tensor related to the current element
tensor = stress.ElementValue(elementId,"X;Y;Z;XY;XZ;YZ")
# Get element information
element = mesh.ElementById(elementId)
nodeIds = element.CornerNodeIds
values = []
# Loop on the nodes of the current element to compute the Von-Mises stress on the element nodes
local_wps = WPS(tensor[6*i:6*(i+1)])
# Final stress result has to be returned in theSI unit system
local_wps = local_wps * conv_stress
values.Add(local_wps)
collector.SetValues(elementId, values)
# This function computes the absolute principal stress from the stress tensor
# The Von-Mises stess is computed based on the three eigenvalues of the stress tensor
def WPS(tensor):
53
# Computation of the eigenvalues
eigenvalues = EigenValues(tensor)
# Extraction of the worst principal stress
wplocal_stress = eigenvalues[0]
if abs(eigenvalues[1])>abs(wplocal_stress):
# Return the worst value of the three principal stresses S1, S2, S3
return wplocal_stress
# This function computes the three eigenvalues of one [3*3] symetric tensor
EPSILON = 1e-4
def EigenValues(tensor):
global eigenvalues
eigenvalues = []
a
b
c
d
e
f
=
=
=
=
=
=
tensor[0]
tensor[1]
tensor[2]
tensor[3]
tensor[4]
tensor[5]
if ((abs(d)>EPSILON) or (abs(e)>EPSILON) or (abs(f)>EPSILON)):

# Polynomial reduction
A = -(a+b+c)
B = a*b+a*c+b*c-d*d-e*e-f*f
C = d*d*c+f*f*a+e*e*b-2*d*e*f-a*b*c
p = B-A*A/3
q = C-A*B/3+2*A*A*A/27
if (q<0):
R = -sqrt(fabs(p)/3)
else:
R = sqrt(fabs(p)/3)
phi = acos(q/(2*R*R*R))
S1=-2*R*cos(phi/3)-A/3
S2=-2*R*cos(phi/3+2*3.1415927/3)-A/3
S3=-2*R*cos(phi/3+4*3.1415927/3)-A/3
else:
S1 = a
S2 = b
S3 = c
eigenvalues.Add(S1)
eigenvalues.Add(S2)
eigenvalues.Add(S3)
return eigenvalues
ACT introduces a new method to facilitate the development of Python functions to evaluate simulation
results. The third output argument collector is internally initialized based on the content of the scoping
property. When defined, this property contains the list of FE entities on which results are evaluated.
This information can be used directly in Python functions without looping over mesh regions. The following demonstrates the use of this method in the function WPS_Eval.
import units
wps_stress = {}
eigenvalues = {}
def init(context):
ExtAPI.Log.WriteMessage("Init Demoresult Extension...")
54
def Create_WPS_Result(analysis):
ExtAPI.Log.WriteMessage("Launch Create_WPS_Result...")
analysis.CreateResultObject("Worst Principal Stress")
# This function evaluates the specific result (i.e. the Absolute principal stress) on each element
required by the geometry selection
def WPS_Eval(result,stepInfo,collector):
global wps_stress
analysis = result.Analysis
ExtAPI.Log.WriteMessage("Launch evaluation of the WPS result: ")
reader.CurrentResultSet = stepInfo.Set
# Unit sytem management:
# First get the unit system that was used during the resolution
# Second compute the coefficient to be used so that the final result will be returned in the
SI unit system
unit_stress = stress.GetComponentInfo('X').Unit
# Loop on the elements related to the collector.Ids list
for elementId in collector.Ids:
tensor = stress.ElementValue(elementId,"X;Y;Z;XY;XZ;YZ")
# Get element information
element = mesh.ElementById(elementId)
nodeIds = element.CornerNodeIds
values = []
# Loop on the nodes of the current element to compute the Von-Mises stress on the element nodes
local_wps = WPS(tensor[6*i:6*(i+1)])
# Final stress result has to be returned in theSI unit system
local_wps = local_wps * conv_stress
values.Add(local_wps)
collector.SetValues(elementId, values)
# This function computes the absolute principal stress from the stress tensor
def WPS(tensor):
eigenvalues = EigenValues(tensor)
# Extraction of the worst principal stress
# Return the worst value of the three principal stresses S1, S2, S3
return wplocal_stress
EPSILON = 1e-4
def EigenValues(tensor):
global eigenvalues
eigenvalues = []
a
b
c
d
=
=
=
=
tensor[0]
tensor[1]
tensor[2]
tensor[3]
55
e = tensor[4]
f = tensor[5]
A = -(a+b+c)
p = B-A*A/3
q = C-A*B/3+2*A*A*A/27
if (q<0):
R = -sqrt(fabs(p)/3)
else:
R = sqrt(fabs(p)/3)
phi = acos(q/(2*R*R*R))
S1=-2*R*cos(phi/3)-A/3
S2=-2*R*cos(phi/3+2*3.1415927/3)-A/3
S3=-2*R*cos(phi/3+4*3.1415927/3)-A/3
else:
S1 = a
S2 = b
S3 = c
eigenvalues.Add(S1)
eigenvalues.Add(S2)
eigenvalues.Add(S3)
return eigenvalues
This extension takes advantage of the fact that the collector.Ids property is initialized with the element
numbers related to the selected geometrical entities. This list can be used to evaluate results for each
element. The collector.Ids property contains nodes or element numbers depending on the type
of result defined in the XML file of the extension. For results with the location set to node, collector.Ids
contains a list of node numbers. For results with the location set to elem or elemnode, collector.Ids
contains a list of element numbers.
Creating Results with Imaginary Parts

Creating results for analyses which have complex results requires managing both real and imaginary
values. The SetValues() method is used to set values to the real part of the result. A second method
named SetImaginaryValues() is also available to set values to the imaginary part of the result.
An example of the creation of a complex result is shown below:
def Evaluate(result,stepInfo,collector):
for id in collectors.Ids:
real_value = 1.
# Set the real part of the result
collector.SetValues(id, real_value)
imaginary_value = 2.
# Set the imaginary part of the result
collector.SetImaginaryValues(id, imaginary_value)
Obsolete OnStartEval and GetValue Callbacks

Both callbacks <onstarteval> and <getvalue> have been replaced by the single callback
<evaluate>. The <evaluate> callback simplifies the implementation of an ACT result, which now
requires only a single Python function. The callbacks <onstarteval> and <getvalue> are still
56

supported for extensions developed in previous versions of ACT, but the use of the <evaluate>
callback is recommended for new extension development.
Connecting to a Third-Party Solver

This section discusses how to add a connection to a third-party solver, or the ability to launch an external process from the Mechanical system instead of launching the ANSYS solver. The example used
in this section is defined in the ExtSolver1 extension, which was written to demonstrate the ability
to plug a very simple solver. This solver distributes the values assigned at boundaries inside the structure.
This example is for demonstration purposes only.
Third-Party Solver Connection Extension

We will begin by looking at the XML required to add a third-party solver in a project, as defined in the
ExtSolver1.xml file.
<simdata context="Project|Mechanical">
<solver name="Solver1" version="1" caption="Solver1" icon="result" analysis="Static" physics="Structural">
<callbacks>
<onsolve>Solve</onsolve>
<getsteps>GetSteps</getsteps>
<getreader>GetReader</getreader>
</callbacks>
<property name="MaxIter" caption="Max. Iterations" control="integer" default="10" />
</solver>
</simdata>
<load name="Values" version="1" caption="Values" icon="tload" issupport="false" isload="true"
color="#0000FF">
<callbacks>
<getsolvecommands>WriteInitialValues</getsolvecommands>
<getnodalvaluesfordisplay>NodeValues</getnodalvaluesfordisplay>
</callbacks>
<property name="Geometry" control="scoping" />
<property name="Expression" caption="Expression" control="text" />
</load>
</simdata>
As with the loads and results features, the solver definition must be encapsulated within a <simdata>
tag. In this example the context attribute is "Project|Mechanical." When "Project" is specified as a
context attribute, the solver appears as a component in the Workbench Project Schematic (see Figure 34: Project Schematic with External Solver System (p. 58)).
The solver definition begins with the tag <solver>. This tag takes some mandatory attributes:
name: internal name of the solver
version: version of the solver
caption: display name of the solver
57
analysis: analysis type addressed by the third-party solver. For compatibility reasons, this attribute must
be set to Static, but this does not prevent you from integrating any type of third-party solver.
physics: physics type addressed by the third-party solver. Today, this attribute must be set to Structural.
This tag as no real impact on what the solver computes.
You must define the callback <onsolve>. This callback is called when the application launches the
solver and thus takes in argument the sol ver object.
You can define a set of properties, which appear in the details view of the analysis. In the example, a
simple property is created to define the maximum number of iterations to be performed by the solver.
By default the value is set to 10.
Figure 34: Project Schematic with External Solver System (p. 58) shows the new system in the toolbox.
Each third-party solver is added into a new category, identified by the caption of the extension; the
system is named by the caption of the solver.
The system related to the third-party solver is equivalent to one standard system that can be created
with the ANSYS solver. The components that build this new system remain the same. Then the user
can add in the schematic a new system related to the solver just as he does for any other systems.
Figure 34: Project Schematic with External Solver System
Following is the code for the extension (file main.py). The solver code is located in a separate file,
solver.py, which is placed in the same folder as main.py. The third line of the main.py script is
"import solver." This Python technique is using separate code for reuse and maintainability. The script
in solver.py defines the SolverEngine class.
import os
import solver
def CreateValuesLoad(analysis):
analysis.CreateLoadObject("Values")
58

initValues = {}
sol = None
solbystep = {}
values = {}
steps = []
res = [0.]
dScal = [0.]
dVec = [0., 0., 0.]
def WriteInitialValues(load,filename):
global initValues
propEx = load.Properties["Expression"]
exp = propEx.Value
if exp=="":
return None
values = []
propGeo = load.Properties["Geometry"]
refIds = propGeo.Value.Ids
nodeIds = meshRegion.NodeIds
for nodeId in nodeIds:
node = mesh.NodeById(nodeId)
x = node.X
y = node.Y
z = node.Z
v = 0.
try:
v = eval(vexp)
v = float(v)
finally:
initValues.Add(nodeId,v)
def NodeValues(load,nodeIds):
propEx = load.Properties["Expression"]
exp = propEx.Value
if exp=="":
return None
try:
except:
return None
values = []
for id in nodeIds:
x = node.X
y = node.Y
z = node.Z
v = 0.
try:
v = eval(vexp)
v = float(v)
finally:
values.Add(v)
return values
def Solve(s, fct):
global steps
global initValues
global sol
global solbystep
global values
solbystep = {}
solbystepTmp = {}
f = open("solve.out","w")
f.write("SolverEngine version 1.0\n\n\n")
try:
59
maxIter = int(s.Properties["MaxIter"].Value)
f.write("Max. iteration : %d\n" % (maxIter))
mesh = s.Analysis.MeshData
numEdges = 0
geo = ExtAPI.DataModel.GeoData
nodeIds = []
for asm in geo.Assemblies:
for part in asm.Parts:
for body in part.Bodies:
for edge in body.Edges:
numEdges = numEdges + 1
ids = mesh.MeshRegionById(edge.Id).NodeIds
nodeIds.extend(ids)
steps = []
stepsTmp = []
f.write("Num. edges : %d\n" % (numEdges))
sol = solver.SolverEngine(mesh,initValues,nodeIds)
initValues = sol.Run(maxIter,f,stepsTmp,solbystepTmp)
nodeIds = mesh.NodeIds
sol = solver.SolverEngine(mesh,initValues,nodeIds)
values = sol.Run(maxIter,f,steps,solbystep)
initValues = {}
except StandardError, e:
f.write("Error:\n");
f.write(e.message+"\n");
f.close()
return False
f.close()
return True
def GetSteps(solver):
global steps
return steps
def Save(folder):
global solbystep
fm = System.Runtime.Serialization.Formatters.Binary.BinaryFormatter()
try:
stream = System.IO.StreamWriter(os.path.join(folder,"sol.res"),False)
except:
return
try:
fm.Serialize(stream.BaseStream,solbystep)
finally:
stream.Close()
def Load(folder):
global solbystep
if folder==None:
return
fm = System.Runtime.Serialization.Formatters.Binary.BinaryFormatter()
try:
stream = System.IO.StreamReader(os.path.join(folder,"sol.res"))
except:
return
try:
solbystep = fm.Deserialize(stream.BaseStream)
finally:
stream.Close()
class ExtSolver1Reader(ICustomResultHeader):
def __init__(self,infos):
self.infos = infos
self.step = 1
60
def GetCurrentStep(self):
return self.step
def SetCurrentStep(self,stepInfo):
self.step = stepInfo
def GetStepValues(self):
global steps
return steps
def GetResultNames(self):
return ["VALUES"]
def GetResultLocation(self,resultName):
return ResultLocationEnum.Node
def GetResultType(self,resultName):
return ResultTypeEnum.Scalar
def GetComponentNames(self,resultName):
return [""]
def GetComponentUnit(self,resultName,componentName):
return "Temperature"
def GetValues(self,resultName,collector):
global solbystep
if self.step.Set in solbystep:
values = solbystep[self.step.Set]
for id in collector.Ids:
if id in values:
collector.SetValues(id, [values[id]])
def GetReader(solver):
return ["ExtSolver1Reader"]
The function associated to the <onsolve> callback is Solve. This function creates a file solve.out,
which is read interactively by the application and stored in the solution information.
By default, the application launches the resolution directly into the working directory, so it is not necessary to set the folder in which the solve.out file must be created.
The callback function must return True or False to specify if the solve has succeeded or failed.
Note that it is not possible to return progress information with the current version.
Post Processing
You can create a result reader to expose results.
To do that, you create a class that implements the ICustomResultReader interface. The following
methods need to be implemented. For each method, the expected results that must be returned are
described.
GetCurrentStep(self)
This method must return the current step number.
SetCurrentStep(self,stepInfo)
This method is called each time the current step number is changed.
GetStepValues(self)
This method must return a lost of double values that represents the time steps or frequencies.
61
GetResultNames(self)
This method must return a list of strings that represents the result names available for the reader.
GetResultLocation(self,resultName)
This method must return the location type of the result identified by the name resultName. The possible
values are node, element, and elemnode.
GetResultType(self,resultName)
This method must return the type of the result identified by the name resultName. The possible values
are scalar, vector, and tensor.
GetComponentNames(self,resultName)
This method must return a list of strings that represents the list of available components available for the
result identified by the name resultName.
GetComponentUnit(self,resultName,componentName)
This method must return the unit name related to the results component identified by the result name
resultName and the component name componentName.
GetValues(self,resultName,collector)
This method must return a list of double values for each component associated to the result identified by
the name resultName.
To specify a dedicated reader, add a <getreader> callback in the solver definition. This callback returns
a list of string, where the first is the name of the reader class and the remainder represents parameters
given to the constructor of the class when the reader is instanced by ACT. Any result exposed in the
method ResultNames() will be available in Mechanical's Results worksheet.
If the name of the result matches a standard result name (like "U"), Workbench applies the same treatment
for this result than for a standard one. So, if the result is named "U", Workbench uses this result to draw
the deformed model.
In the Extsolver1 example, the reader declares one single scalar nodal result VALUES. No deformation is considered.
Load and Save Data

It is possible to use the callbacks <onload> and <onsave> under the <interface> tag to load
and save data associated with the third-party solver. As previously discussed, the proposed extension
uses the <onload> and <onsave> callbacks to save and load the computed results. With the current
extension, the results are still available if the user closes and reopens the Solver1 system.
The <onload> and <onsave> callbacks take in argument the name of the working directory.
Figure 35: Analysis Settings Object Associated to External Solver (p. 63) and Figure 36: Boundary Condition
Object Associated to External Solver (p. 63) show the specific objects that must be integrated in the
definition tree in order to set up an analysis based on the external solver.
62

Figure 35: Analysis Settings Object Associated to External Solver
Figure 36: Boundary Condition Object Associated to External Solver
63
Figure 37: Solution Information Associated to External Solver (p. 64)a nd Figure 38: Post-processing Associated to External Solver (p. 65) show the two types of output derived from the resolution. Note that
the solution information is interactively displayed during the resolution.
Figure 37: Solution Information Associated to External Solver
64

Figure 38: Post-processing Associated to External Solver

This section discusses customization of the ANSYS DesignModeler application. Whereas in the ANSYS
Mechanical application ACT is used to work with loads and results, in DesignModeler it is instead used
to work with geometries. Once you have used ACT to add custom toolbars and menus to the DesignModeler user interface, you can use those entities to generate geometries by creating and using a
primitive generator, defining properties, and applying various operations to the resulting geometry.
This example extension, GeometryFeature, shows how to add a geometry to DesignModeler. This
example is for demonstration purposes only.
The GeometryFeature extension was written to create a geometry based on an existing part. As
part of this process, we will draw a circle, define a disc based on the circle, and extrude the disc into a
cylinder.
We will address the extensions XML file and Python file separately.
Geometry Definition in the XML File

The XML file for our example is called GeometryFeature.xml and is shown below.
<extension version="1" name="GeometryFeature">
<interface context="DesignModeler">
<toolbar name="ACTtoolbar" caption="ACTtoolbar">
<entry name="MyFeature" icon="construction">
<callbacks>
<onclick>createMyFeature</onclick>
65
</callbacks>
</entry>
</toolbar>
</interface>
<simdata context="DesignModeler">
<geometry name="MyFeature" caption="MyFeature" icon="construction" version="1">
<callbacks>
<ongenerate>generateMyFeature</ongenerate>
<onaftergenerate>afterGenerateMyFeature</onaftergenerate>
</callbacks>
<property name="Face" caption="Face" control="scoping">
<attibutes selection_filter="face"/>
</property>
<property name="Length" caption="Length" control="float" unit="Length" default="1.2 [m]"></property>
<property name="Minimum Volume" caption="Minimum Volume" control="float" unit="Volume" >
<attributes readonlyaftergenerate="true" />
</property>
</geometry>
</simdata>
</extension>
As in previous examples, the XML first defines the extension using a version and name attribute. The
path to the Python script file main.py is specified by the <script> tag. The ACT toolbar is defined
in the <interface> tag, which has a context of DesignModeler. The callback function named createMyFeature is used to create and add the geometry to the DesignModeler environment.
The definition of the geometry is encapsulated by the <simdata> begin and end tags. The attributes
in the <geometry> begin tag provide the name, caption, icon, and version that apply to this geometry.
The geometry <callbacks> tag encapsulates two callbacks <ongenerate> and <onaftergenerate>.
The tag <ongenerate> specifies the name of the Python function that is called when the geometry is
generated by the application. The application provides the geometry type (type IDesignModelerGeoFeature) as the callback argument.
This callback must return a Boolean value to indicate whether the generation has been successful; it
returns true if the generation has succeeded and false if it has failed.
The tag <onaftergenerate> specifies the name of the Python function that is called after the geometry
is generated by the application. The application provides the geometry type (type IDesignModelerGeoFeature) as the callback argument.
To specify additional details about the geometry, you can include additional tags, such as <canadd>,
<onadd>, <oninit>, or <onmigragte> between the <callbacks> begin and end tags.
of the geometry (in this example, Face and Length). These properties are displayed in the Details View
pane of ANSYS DesignModeler, where the user provides the necessary values to complete the geometry
definition. When we review the Python script in a subsequent section, we will see how the geometry
properties can be retrieved and/or modified.
The following figure shows that each property defined above appears in the Details View pane with
the corresponding names and types of interface control.
66

Figure 39: Feature and Corresponding Properties in the Details View Pane
Note that the two geometry properties, Face and Length, use different control types.
The Face property uses a scoping control type with the attribute of selection_filter set to face.
This specifies that the value for this property will be one or more faces. The faces will be defined in the
main.py file and then used to generate our geometry.
The Length property uses a float control type, and does not require the definition of one specific callback.
Instead, the XML definition introduces a physical quantity dependency with the unit attribute, which
specifies that this property is consistent with a length. The default attribute specifies a default value
of 1.2[m]; this default value is exposed in the Details View pane each time a new load is created.
Geometry Definition in the Python File

The Python file for our example is called main.py and is shown below. We will discuss the Python
functions associated with the <ongenerate> and <onaftergenerate> callbacks.
import units
import math
def createMyFeature(feature):
ExtAPI.CreateFeature("MyFeature")
def vectorProduct(v1, v2):
return [v1[1]*v2[2]-v1[2]*v2[1], -v1[0]*v2[2]+v1[2]*v2[0], v1[0]*v2[1]-v1[1]*v2[0]]
def scalarProduct(v1, v2):
return v1[0]*v2[0]+v1[1]*v2[1]+v1[2]*v2[2]
def norm(v):
return math.sqrt(scalarProduct(v,v))
def generateMyFeature(feature,function):
length = feature.Properties["Length"].Value
length = units.ConvertUnit(length, ExtAPI.DataModel.CurrentUnitFromQuantityName("Length"), "m")
faces = feature.Properties["Face"].Value.Entities
bodies = []
builder = ExtAPI.DataModel.GeometryBuilder
67
for face in faces:
centroid = face.Centroid
uv = face.ParamAtPoint(centroid)
normal = face.NormalAtParam(uv[0], uv[1])
radius = math.sqrt(face.Area/(math.pi*2))
xdir = [1., 0., 0.]
vector = vectorProduct(xdir, normal)
if norm(vector)<1.e-12:
xdir = [0., 1., 1.]
s = scalarProduct(xdir, normal)
xdir = [xdir[0]-s*normal[0],xdir[1]-s*normal[1],xdir[2]-s*normal[2]]
n = norm(xdir)
xdir[0] /= n
xdir[1] /= n
xdir[2] /= n
arc_generator = builder.Primitives.Wire.CreateArc(radius, centroid, xdir, normal)
arc_generated = arc_generator.Generate()
disc_generator = builder.Operations.Tools.WireToSheetBody(arc_generated)
normal[0] *= -1
normal[1] *= -1
normal[2] *= -1
extrude = builder.Operations.CreateExtrudeOperation(normal,length)
cylinder_generator = extrude.ApplyTo(disc_generator)[0]
bodies.Add(cylinder_generator)
feature.Bodies = bodies
feature.MaterialType = MaterialTypeEnum.Add
return True
def afterGenerateMyFeature(feature):
edges = []
minimum_volume = System.Double.MaxValue
for body in feature.Bodies:
body_volume = 0
if str(body.BodyType) == "GeoBodySolid":
body_volume = body.Volume
if body_volume <= minimum_volume:
minimum_volume = body_volume
edges.Add(edge)
else:
ExtAPI.Log.WriteMessage("Part: "+body.Name)
feature.Properties["Minimum Volume"].Value = minimum_volume
ExtAPI.SelectionManager.NewSelection(edges)
named_selection = ExtAPI.DataModel.FeatureManager.CreateNamedSelection()
ExtAPI.SelectionManager.ClearSelection()
Functions Associated with the <ongenerate> Callback

Below, we will describe the Python functions associated with the <ongenerate> callback.
The function createMyFeature(feature) creates the geometry in the DesignModeler tree. It will
be displayed as My Feature in the Tree Outline.
The mathematical functions vectorProduct and scalarProduct will be used later in the generateMyFeature function.
The first several functions configure details that will be used later in the creation of the geometry.
68

In our example, the function generateMyFeature is referenced in the GeometryFeature.xml
file by the <ongenerate> callback. When called, it generates the geometry feature. Within this function,
the following details about the geometry are defined:
The length property, which will be used later to create the primitive. The conversion of the length unit
ensures that we are working with the expected metric unit.
The scoped face property, which in this example is three faces.
The bodies list, where we will add all the geometric features to be created.
The builder, which serves as the ACT gateway in DesignModeler. We will access all features and operations
from here.
The faces variable, which will be used as the argument to create our circle. Under faces:
Define the centroid of the scoped face.
Evaluate the normal to this face.
Evaluate the radius that will be used for our arc wire.
Calculate the xdir, which is the principle direction of the arc wire defined below and is required to draw
our arc.
The vectorProduct and scalarProduct objects are used to specify the location of the geometrys
primitives and operations.
The next several objects generate an arc wire.
With the arc_generator object, we use the primitive generator builder.Primitives.Wire.CreateArc. The CreateArc() method uses arguments from faces to draw the circle. This generator can
be used one or more times to build the primitive body.
With the arc_generated object, we use the Generate() method to generate the primitive body.
With the disc_generator object, we use the operations generator builder.Operations.Tools.WireToSheetBody to define a disc based on the circle.
The next several lines extrude the disc into a cylinder.
With the extrude object, we use the operations generator builder.Operations.CreateExtrudeOperation. The CreateExtrudeOperation specifies that the resulting extrusion will be equal to
the value of the Length property.
With cylinder_generator object, we use the ApplyTo method to define the geometry to which
the extrude operation will be applied. The ApplyTo() method returns a list of bodies to which the operation will be applied.
Bodies added to the feature.Bodies list will be added to DesignModeler after the generation. All other
bodies used in the generation process will be lost.
The feature.Bodies list can contain both bodies and parts. We can create a part with the command
builder.Operations.Tools.CreatePart(list_of_bodies).
69
The material.Type allows us to enter different properties such as Freeze, Cut, and Add. The image
below illustrates the resulting geometry given selection of the different properties.
Figure 40: Effect of different material type properties on the geometry
Functions Associated with the <onaftergenereate> Callback

Below, we will describe the Python function associated with the <onaftergenerate> callback, which
specifies the name of the IronPython function called when the <ongenerate> callback is complete.
The <onaftergenerate> callback:
Allows you to access and work with the part or bodies created previously by the <ongenerate>
callback.
For example, you can use it rename a part or body, suppress it, create a named selection, create
a new selection via the Selection Manager, or access one or more of the geometric features of
a body as its area.
Unlike the <ongenerate> callback, which expects a return value of True or False, does not expect
a return value.
Allows you to define properties for the feature to be created.
In our example, the function afterGenerateMyFeature is referenced in the GeometryFeature.xml file by the <ongenerate> callback. It accepts only the feature itself as an argument. When
called, it specifies the properties and attributes of the feature and selects edges of the bodies created,
as described below:
The edges list, where we will add all the edges of the bodies to be created for the feature.
The Minimum Volume property, which in this example will be the volume of the body with the smallest
volume of all the bodies created for the feature. It uses a float control type and uses the unit attribute
to specify a value consistent with a volume. Because this property has the special attribute
readonlyaftergenerate set to true, the value becomes non-editable after generation of the
feature.
The edge variable, which will be used to find the edges of all the bodies created for the feature.
70

The feature.Properties[Minimum Volume].Value entry sets the Minimum Volume
property in DesignModeler to the minimum_volume value.
The ExtAPI.SelectionManager.NewSelection(edges) command creates a new selection
including all the edges previously selected.
The named_selection = ExtAPI.DataModel.FeatureManager.CreateNamedSelection() command creates a named selection which will be defined by the current selection containing
all the edges previously selected.
Figure 41: Feature, Named Selection, and Properties in DesignModeler

This section discusses how to define functionality for ANSYS DesignXplorer. The ANSYS DesignXplorer
application is the ANSYS Workbench add-in that offers design exploration and optimization features.
You can create an ACT extension to integrate external functionality with the standard ANSYS
DesignXplorer (DX) application. A DOE Extension integrates one or more external sampling methods,
while an Optimization Extension integrates one or more external optimization methods.
From a user-interface point of view, the sampling or optimization method, along with specific properties
to control its behavior, is hosted and exposed in DX as an additional method. Through its API, DX
provides the services required the calculation of points, report progress, and return results. The enduser experience is the same for both built-in and external methods of optimization or sampling.
From a development point of view, a sampling or optimizer is defined as a standard ACT extension that
includes one or more specific elements for the DesignXplorer context. A required callback, which allows
for the instantiation of the external method, is a class generally coded in C#, C/C++ or Fortran by the
extension developer. The callback class must implement the method interface (ISamplingMethod
or IOptimizationMethod) in order for the sampling or optimizer to be recognized as valid and interact with DX.
71
DX takes advantage of the ANSYS Workbench platform to allow parametric studies in a generic way for
any simulation project. Regardless of the number of solvers and physics or the complexity of the
workflow involved to execute the simulation, DX sees the same simplified representation of the project
and interacts with it only in terms of parameters, design points, and the associated services.
Figure 42: DesignXplorer DOEs in an ANSYS Workbench Project
This generic architecture makes it possible to implement a variety of algorithms without needing to
worry about the communication with solvers. Since the external methods are hosted by DX, they also
take advantage of the ANSYS Workbench platform architecture to work with any kind of simulation
project defined in ANSYS Workbench, with no additional implementation effort.
The Design Exploration Process

The external functionality defined by the extension is responsible for carrying out relevant analysis tasks
as defined by the DX user; the external optimizer is responsible for solving the optimization study, and
the external sampling is responsible for generating the DOE. Note that the external functionality is not
required to support all the features available in DX. On the other hand, since the sampling or optimizer
is hosted in the DX environment, it is subject to the environments limitations; as such, some of the
external features may not be available in DX.
The DOE and optimization study are defined as follows:
Design of Experiments
Optimization Study
Variables
Variables
DOE domain
Optimization domain
Parameter relationships
Objectives
Constraints
72

The Variables are the parameters of the Workbench project. As there are input and output parameters,
there are input and output variables for the sampling or optimization. Note that, since the user can
disable input parameters, the number of input variables transferred to the external functionality is
smaller than or equal to the number of input parameters defined in the Workbench project.
The Domain is the multidimensional space that the sampling or optimizer can explore in order to
generate the DOE or solve the optimization problem. It is defined by the input variables and their range
of variation or as a list of possible values. There are different types of input variables:
Double Variable:
Continuous variable defined by a range of variation, from its lower to its upper bound, where the bounds
are real values
Exposed to the user as a Continuous Input Parameter
Double List Variable:
Defined by a list of sorted real values
Exposed to the user as a Continuous Input Parameter with Manufacturable Values
Integer List Variable:
Defined by a list of integer values
Exposed to the user as a Discrete Input Parameter
The optimization Parameter Relationships define relationships between input variables such as
P1+2*P2 <= 12.5[mm]. They allow the user to restrict the definition of the optimization domain.
The optimization Objectives are defined on variables (e.g., Minimize P3). The following objective types
are supported:
Minimize a variable
Maximize a variable
Seek Target for a variable, where the target is a user-specified constant value
The optimization Constraints are defined on variables, as well (e.g., P3 <= 80). Both an objective and
a constraint can be defined for the same variable. The following constraint types are supported:
Less Than, where the user defines the lower bound (constant value)
Greater Than, where the user defines the upper bound (constant value)
Equal To, where the user defines the target value (constant value)
Inside Bounds, where the user defines the targeted interval (constant values)
The DX Component
DX exposes several types of systems in Workbench, with each system type corresponding to one of its
parametric features such as Parameters Correlation, Response Surface, Six Sigma Analysis, etc. DX
components can be found in the Design Exploration toolbox.
73
The DOE Component

The DOE component appears in two different kinds of DOE systems, the Response Surface system and
the Response Surface Optimization system. It provides a selection of built-in sampling methods. Each
sampling method comes with its own specific standard and advanced properties, capabilities, and limitations.
Figure 43: DesignXplorer Systems Containing DOEs in the Design Exploration Toolbox
The Optimization Component

The Optimization component appears in two different kinds of optimization systems, the Direct Optimization system and the Response Surface Optimization system. It provides a selection of built-in
optimization methods. Each method comes with its own specific standard and advanced properties,
capabilities, and limitations.
Figure 44: DesignXplorer Optimization Systems in the Design Exploration Toolbox
Direct Optimization system:

The system is composed only of an Optimization component.
Each point requested by the optimizer is calculated by updating a design point (real solve).
With this approach:
The optimizer manipulates accurate output parameter values (directly returned by the solver).
The number of input parameters is not limited. However, the cost is proportional to the number of
points.
Response Surface Optimization system:
The system is composed of three components (Design of Experiments, Response Surface, and Optimization).
Each point requested by the optimizer is calculated by evaluating the response surface.
With this approach:
74

The optimizer manipulates approximated output parameter values.
The number of input parameters is limited by the ability to generate the response surface. However,
the cost is extremely low because the resources needed to evaluate the response surface are negligible.
The optimization is performed as a post-processing operation based on the response surface, so several
alternative optimization studies can be performed very quickly on the same surface.
The DX Extension
External DOEs and optimizers can be packaged and installed as Workbench extensions. When the extension is installed and loaded, DX detects the external DOEs or optimizers and exposes them as additional options in the DesignXplorer component. If the user selects one of these custom methods, DX
delegates to the selected external option; it delegates sampling resolution to the external sampling
and optimization resolution to the external optimizer. Note that when an external option is used, the
Workbench session is journaled and can be replayed as usual.
The extension is a container for one or more DOEs or optimizers. The DOEs and optimizers themselves
are generally provided as compiled libraries included in the .wbex extension file.
Implementing a DX Extension
A DX extension is comprised of three main parts:
XML file that declares, defines and configures the extension
Python scripts that implement callbacks
ISamplingMethod or IOptimizationMethod implementation, which is the adapter to your existing
implementation. This is typically achieved in C# or IronPython.
This section describes each of these pieces and includes references to several examples of functional
DX extensions.
Implementation Requirements
The implementation of a DX extension requires:
ANSYS Workbench installation
ANSYS Customization Suite license
IronPython, which is provided as part of ANSYS Workbench in the directory <installdir>\commonfiles\IronPython
Microsoft Visual Studio 2010 SP1 for C# implementation
Microsoft Visual Studio 2010 SP1 or equivalent for C/C++ implementation
DX Extension Definition and Configuration

As with any other type of extension, a DX extension is defined and configured by an XML file that
identifies the extension (version, name, author, description) and provides the following main entry
points:
75
Filename of the main Python script (as specified by the <script> element)
Name of the Python function to invoke when initializing the extension (as specified by the OnInit callback)
In a DX extension, the OnInit callback is the correct place to load the DLL containing the external
sampling. Another callback named OnTerminate is invoked when the extension is unloaded and is
the correct place to perform cleanup operations and unload the DLL.
The specificity of a DX extension is to define external sampling or optimization methods to be used by
DX. The definitions are encapsulated in a <simdata> element, where the context attribute is set to
DesignXplorer. The main elements used to declare and define the DOEs are shown in Figure 45: Declaration and Definition of an External DOE (p. 76). The main elements used to declare and define the
optimizers are shown in Figure 46: Declaration and Definition of an External Optimizer (p. 77).
Figure 45: Declaration and Definition of an External DOE
In Figure 45: Declaration and Definition of an External DOE (p. 76), the DOE defined is called FullFactorial.
The two attributes framed in red are examples of capabilities being defined for this DOE. Here we can
see that for FullFactorial:
The LogFile attribute is set to true, so the sampling has the capability to use the DX API to generate a
log file in the Workbench project.
The CustomTable attribute is set to false, so the DOE does not have the capability to handle the custom
table available in DX.
All other capabilities are configured per the default values. For a listing of capabilities, see DX Extension
Capabilities (p. 78).
The callbacks to hook up with DX are framed in blue. Note that the OnCreate callback, which is invoked
to obtain an ISamplingMethod instance, is mandatory. All other callbacks are optional.
Finally, all of the properties declared for the DOE in Figure 45: Declaration and Definition of an External
DOE (p. 76) are framed in orange. These properties allow the user to control specific settings of the
76

algorithm, access relevant output information (e.g. number of levels or status), or whatever else the
DOE needs to expose as a result of the sampling run.
Figure 46: Declaration and Definition of an External Optimizer
In Figure 46: Declaration and Definition of an External Optimizer (p. 77), the extension is named MyOptimizer and defines two different external optimizers. The declaration for each optimizer is marked with
a green bracket. Each optimizer will be managed by DX as an independent optimization method.
In Figure 46: Declaration and Definition of an External Optimizer (p. 77), the first optimizer defined is
called MyOptimizer. The two attributes framed in red are examples of capabilities being defined for
this optimizer. Here we can see that for MyOptimizer:
The SeekObjective attribute is set to false, so the optimizer does not have the capability to handle
the Seek Target objective available in DX.
The LogFile attribute is set to true, so the optimizer has the capability to use the DX API to generate a
log file in the Workbench project.
All other capabilities are configured per the default values. For a listing of capabilities, see Optimization
Example (p. 78).
77
The callbacks to hook up with DX are framed in blue. Note that the OnCreate callback, which is invoked
to obtain an IOptimizationMethod instance, is mandatory. All other callbacks are optional.
Finally, all of the properties declared for the optimizer in Figure 46: Declaration and Definition of an
External Optimizer (p. 77) are framed in orange. These properties allow the user to control specific
settings of the algorithm, access relevant output information (e.g. number of iterations, final convergence
metrics, status), or whatever else the optimizer needs to expose as a result of the optimization run.
DX Extension Capabilities
A DX extension is designed to solve a specific range of problems, and its implementation is characterized
by complementary features and limitations. To allow DX to determine when a given sampling or optimization method is applicable, depending on the current DOE or optimizer definition, it is necessary to
declare the main capabilities of each external method. There are also optional capabilities used by DX
to adjust the user interface according to what complementary features are supported by the external
method.
For external DOEs, the capabilities are specified in the XML file as attributes of the <sampling> element.
For external optimizers, the capabilities are specified in the XML file as attributes of the <optimizer>
element.
Main Capabilities
The main capabilities are used to determine if the external sampling or optimization method can be
applied to the problem as it is currently defined. If the external method has the required capabilities,
it is available as a menu option in the DX Properties view (applicable external samplings are available
in the Design of Experiments Type menu, and applicable optimizers are available in the Method Name
menu). If an external method is not applicable, it is not listed as a menu option. Each modification to
the DOE or optimization study (e.g. modifying an existing input parameter, enabling or disabling an
input parameter, etc.) triggers an evaluation of the relevant capabilities to reassess whether the external
method is applicable and will be made available to the user.
DOE Example
The external sampling FullFactorial, defined previously in Figure 45: Declaration and Definition of an External DOE (p. 76), has MaximumNumberOfInputParameters capability equal to 10. As a consequence,
as soon as the user defines more than 10 input parameters, FullFactorial is removed from the list of
available sampling methods. If the user then changes the DOE study so that the number of input parameters
is less than or equal to 10, FullFactorial is immediately restored as an available option.
Note that if the user selects FullFactorial first and defines more than 10 input parameters afterward,
the sampling method is retained. Given the incompatibility of the sampling method and the number
of input parameters, however, the state of the DOE will turn to Edit Required and a Quick Help
message will be provided to explain why the sampling cannot be launched as currently configured.
The external optimizer MyFirstOptimizer, defined previously in Figure 46: Declaration and Definition of
an External Optimizer (p. 77), does not have the SeekObjective capability. As a consequence, as soon
as the user defines a Seek Target objective, MyFirstOptimizer is removed from the list of available optimization methods. If the user then changes the optimization study so that the Seek Target objective is no
longer defined, MyFirstOptimizer is immediately restored as an available option.
Note that if the user selects MyFirstOptimizer first and defines the unsupported Seek Target objective afterward, the optimization method is retained. Given the incompatibility of the optimization
method and the objective, however, the state of the Optimization will turn to Edit Required and
78

a Quick Help message will be provided to explain why the optimization cannot be launched as
currently configured.
The table below notes the main capabilities controlling the availability of external methods.
DOE
Optimizer
MaximumNumberOfInputParameters
MaximumNumberOfDoubleParameters
MaximumNumberOfDoubleListParameters
MaximumNumberOfIntegerListParameters
ParameterRelationship
ObjectiveOnInputParameter
ConstraintOnInputParameter
MinimizeObjective
MaximizeObjective
SeekObjective
LessThanConstraint
GreaterThanConstraint
EqualToConstraint
InsideBoundsConstraint
MinimumNumberOfObjectives
MaximumNumberOfObjectives
MinimumNumberOfConstraints
MaximumNumberOfConstraints
BasedOnResponseSurfaceOnly
BasedOnDirectOptimizationOnly
For a comprehensive list of capabilities, see the "Sampling" and Optimizer sections in the ACT Reference
Guide for DesignXplorer.
Optional Capabilities
The optional capabilities are used to enable or disable specific options or features of DX according to
the level of support provided by the selected external method. After the main capabilities have estabRelease 16.2 - SAS IP, Inc. All rights reserved. - Contains proprietary and confidential information
79
lished that a method is applicable to a given DOE or optimization study, the optional capabilities determine which features will be exposed for that method in the DX user interface.
For example, the LogFile capability is declared for the sampling defined in Figure 45: Declaration and
Definition of an External DOE (p. 76), FullFactorial, and also for the optimizer defined in Figure 46: Declaration and Definition of an External Optimizer (p. 77), MyFirstOptimizer. As a result, the corresponding
features to manage and expose the log file are enabled in DX and exposed in the user interface. If this
capability was not declared or was set to false, DX would adjust its user interface to hide the access
to the log file because it is not supported by this external method.
As additional examples:
If the selected sampling does not support the Custom Table capability, the Custom Table is not available
in the user interface.
If the selected optimizer does not support the Maximize objective type, then the objective types available
in the user interface are limited to Minimize and Seek Target.
If the optimizer does not support importance levels on objectives, the Objective Importance property is
not available in the Property view of the optimization criterion.
For a comprehensive list of capabilities, see the "Sampling" and Optimizer sections in the ACT Reference
Notes on Method Class Implementation

An implementation of the main interface method class (ISamplingMethod for DOE and IOptimizationMethod for optimization) is mandatory in order for a DX extension to be valid. This method
class is the core of the extension; it is the object that is delegated the responsibility to generate the
sampling or solve the optimization study.
If you start a completely new implementation of the sampling or optimization algorithm, you might
consider writing a C# class that derives directly from the method class, as provided by the PublicAPIs
assembly.
If you start from an existing code, either in C/C++ or FORTRAN code, you should consider implementing
your method class in IronPython as an adapter to your algorithm implementation, wrapping your existing
classes and/or routines.
Both approaches are illustrated by the extension examples listed in DesignXplorer Extension Examples (p. 222).
For full reference documentation of the API, see the API Description section in the ACT Reference
Notes on Monitoring
Notes on Sampling Monitoring
DX provides user interface elements that allow the user to monitor the progress of a sampling, in addition
to the progress and log messages.
80
Notes on Optimization Monitoring

DX provides user interface elements that allow the user to monitor the progress of an optimization. In
addition to the progress and log messages, the API allows the external optimizer to optionally provide
DX with progress data such as history and convergence values.
The history values are values of the input and output variables and show how the optimizer explores
the parametric space. In the user interface, history values are rendered graphically, as a 2D chart per
objective and/or input parameter, where the X axis represents points or iterations and the Y axis represents the parameter values. For more information, see Using the History Chart in the DesignXplorer
Users Guide.
The X axis can be configured in the XML file to represent points or iterations with the HistoryChartXAxisType attribute of the optimizer element (byPoint or byIteration).
To provide history values during the execution of IOptimizationMethod.Run(), the optimization
method can call IOptimizationServices.PushHistoryPoint(IOptimizationPoint
point) where point contains a value for some or all enabled input and output variables.
The convergence values are independent from the variables. They are the values of one or more convergence metrics, specific to your optimizer and showing its convergence during the process. In the
user interface, convergence values are rendered graphically, as a 2D chart with one or several curves.
For more information, see Using the Convergence Criteria Chart in the DesignXplorer Users Guide.
To provide convergence values during the execution of IOptimizationMethod.Run(), the optimization method can call IOptimizationServices.PushConvergenceData (IConvergenceData data)where data contains the values for one or several convergence criteria.
Notes on Results
Notes on Sampling Results
The DOE post-processing is similar for all DOE methods. It is based on results data rendered graphically
and/or as tables in the user interface.
Once the DOE is generated, DX extracts all results provided by the sampling in order to generate postprocessing tables and charts:
Sample points from the ISamplingMethod.Samples property
Notes on Optimization Results

The optimization post-processing is similar for all optimization methods. It is based on results data
rendered graphically and/or as tables in the user interface.
Once the optimization study is solved, DX checks IOptimizationMethod.PostProcessingTypes
and extracts all results provided by the optimizer in order to generate post-processing tables and charts:
Candidate points from the IOptimizationMethod.Candidates property
Sample points from the IOptimizationMethod.Samples property
Pareto fronts from the IOptimizationMethod.ParetoFrontIndex property
81
In some cases, DX builds missing results if one of these result types is not supported. For example, if
the optimization method provides the sample points without the candidate points, DX applies its own
sorting logic to generate the candidate points based on objectives and constraints definitions. If the
optimizer provides the sample points without the Pareto fronts indices, DX builds missing data based
on objectives and constraints definitions.

With ACT, you can take your custom, lightweight, external applications and processes and integrate
them into the ANSYS Workbench workflow. Features exposed by ACT also enable you to perform
automation and customization activities, such as creating new systems to facilitate interaction with the
Workbench Project Schematic. The ACT API delivers, in an improved and streamlined offering, functionality previously available only through the External Connection add-in. You can use ACT to create custom
taskgroups and custom tasks.
You can use ACT to create custom taskgroups and custom tasks.
Taskgroups contain tasks; in Workbench, task groups are exposed as custom systems.
Tasks are contained in taskgroups; in Workbench, tasks are exposed as custom components.
Once defined and added to the Workbench Toolbox, an ACT-defined taskgroup can be added to the
Project Schematic workflow in the same way as an installed system.
Note
At present, the mixing of ACT-defined and installed tasks and taskgroups is not supported;
ACT-defined tasks cannot be added to installed taskgroups, and installed tasks cannot be
added to ACT-defined taskgroups.
The figure that follows shows a Workbench Mesh Transfer taskgroup that takes an upstream mesh and
passes it to a downstream Fluent taskgroup. For details, see the Mesh Transfer (p. 234) example.
82

Figure 47: End-to-End Mesh Transfer Between Mesh, Mesher, and Fluent Setup
This section discusses how to create the various files required to define custom ACT workflows in
Workbench, exposing custom taskgroups and tasks as systems and components on the Project
Schematic.
The following topics are addressed:
The Custom Workflow Creation Process
Creating the Extension Definition XML File
Creating the IronPython Script
The Custom Workflow Creation Process

As with any other type of extension, creating taskgroups and tasks to be exposed in a Workbench
workflow involves the creation, installation, and loading of the custom workflow extension.
At minimum, you must create the XML extension definition file, the IronPython script, and any support
files (such as taskgroup and task images and custom application executables). Then you must install
the extension by placing these files in one of the specified directories:
%AWP_ROOT162%\Addins\AdvancedAddinPackage\extensions
Any of the include directories defined in the Additional Extension Folders field on the Extensions page
of the Options dialog.
The IronPython script and support files should be placed in the extension directory, which is at the
same level as the XML file.
83
Once youve installed your extension, you can load it into Workbench via the Extensions Manager.
Upon loading your extensions, the custom taskgroup(s) will be exposed as systems in a new Workbench
Toolbar group, as shown below:
Figure 48: Custom Taskgroups in the Workbench Toolbox
These custom taskgroups can be added to the Project Schematic. When you invoke an Update on a
custom task within the taskgroup, the add-in may:
1. Obtain the inputs.
2. Prepare the inputs.
3. Write input file(s).
4. Run the external solver or performs calculations.
5. Read output file(s).
6. Set the parameters or properties to the calculated values.
Creating the Extension Definition XML File

The extension definition XML file contains information to define a workflow within Workbench, including
taskgroups designed for a particular simulation objective. All analyses performed within Workbench
begin by referencing a taskgroup (system). This XML file describes the taskgroups, and declares the
contained tasks.
At the extension level, the XML file must specify, at minimum:
Extension name
Interface context (must be Project)
Interface <images> tag (needed to specify taskgroup or task icons)
Workflow block
At the workflow level, the XML file can specify:
Workflow context (required; must be Project)
84

Tasks (container for individual task definitions)
Taskgroups (container for taskgroup definitions)
At the task level, the XML file can specify:
Task name (required)
Task version (required)
Callbacks
Context menus
Inputs and outputs
Property groups and properties
Parameters
Display text
Image name
At the taskgroup level, XML file can specify:
Taskgroup name (required)
Taskgroup version (required)
Image name
Abbreviation
The following is an example of the basic structure of an XML extension definition file:
<extension version="1" name="">
<guid shortid="">69d0095b-e138-4841-a13a-de12238c83f3</guid>
<script src="" />
<interface context="Project">
</interface>
<workflow context=Project>
<tasks>
<task name="" caption="" icon="" version="1">
<callbacks>
<onupdate></onupdate>
<onrefresh></onrefresh>
<oninitialize></oninitialize>
<onedit></onedit>
<onreset></onreset>
<onstatus></onstatus>
<onreport></onreport>
</callbacks>
<contextmenus>
<entry name= caption= icon= version=1 priority= type=>
<callbacks>
<onclick></onclick>
</callbacks>
</entry>
</contextmenus>
<propertygroup name= caption=>
<property name="" caption="" control="" default="" readonly="" needupdate=
85
visible=""
persistent="" parameterizable="" keytype="" valuetype="" elementtype=""/>
</propertygroup>
<property name="" caption="" control="" default="" readonly="" needupdate= visible=""
<parameters>
<parameter name= caption= usage= control= version=1/>
</parameters>
<inputs>
<input/>
<input type="" format=""/>
</inputs>
<outputs>
<output type="" format=""/>
</outputs>
</task>
</tasks>
<taskgroups>
<taskgroup name="" caption="" icon="" category="" abbreviation="" version="1"
isparametricgroup=False>
<includetask name=/>
<includeGroup name=/>
</taskgroup>
</taskgroups>
</workflow>
</extension>
Defining a Task
One or more tasks can be defined in the <tasks> node. Individual tasks are defined in a <task> child
node.
In each task definition, you must include the name and version attributes. Child nodes are can be
used to specify callbacks, inputs and outputs, properties, parameters, and context menus.
The basic structure of a task definition is shown below:
<tasks>
<callbacks>
<onedit></onedit>
<onreset></onreset>
</callbacks>
<contextmenus>
<callbacks>
<onclick></onclick>
</callbacks>
</entry>
</contextmenus>
</propertygroup>
<parameters>
</parameters>
<inputs>
<input/>
</inputs>
<outputs>
86

</outputs>
</task>
</tasks>
Callbacks
Callbacks to IronPython functions are specified in the <callbacks> node. The following callbacks are
available: <onrefresh>, <oninitialize>, <onupdate>, <onedit>, <onreset>, <onstatus>,
and <onreport>.
Definition of the <onedit> callback automatically creates a default Edit context menu for the task.
Context Menus
If you specify the <onedit> callback in your extension definition file, a default Edit context menu option
is automatically created for the task. However, it is possible to define additional GUI operations for each
task.
Custom GUI operations are specified in the optional <contextmenus> node. At minimum, the
context menu entry definition must include the name and version attributes. When the optional
type attribute is defined, it must be set to ContextMenuEntry.
Each entry in the <contextmenus> node must have an <onclick> callback.
The basic structure of the <contextmenus> node is shown below:
<contextmenus>
<callbacks>
<onclick></onclick>
</callbacks>
</entry>
</contextmenus>
Inputs and Outputs

In a Workbench workflow, the Project Schematic connections serve as visual representations of data flow
between tasks. These connections depend on input and output coordination. Workbench can establish
connections only if an upstream (providing) task exposes outputs whose types also match the inputs for
a downstream (consuming) task.
Inputs and outputs are defined in the <input> and <output> nodes.
At a minimum, a task must always define an empty input (<input>).
You can use the type attribute to specify the data type expected by the connection.
Certain Workbench types require the use of both the type and format attributes. For example,
a Mesh task that consumes a mesh and then passes a mesh to another taskgroup would use these
attributes to specify the mesh type and file format of the input and output files.
This example defines the inputs and outputs for a task within a Fluent meshing workflow. The
meshing-based type values and FluentMesh format values instruct an upstream mesh task to
output the Fluent mesh file format (.msh).
<task name="Mesher" caption="Mesher" icon="GenericMesh_cell" version="1">
<callbacks>
<onupdate>update</onupdate>
<onedit>edit</onedit>
</callbacks>
<inputs>
<input format="FluentMesh" type="MeshingMesh" count="1"/>
87
<input/>
</inputs>
<outputs>
<output format="FluentMesh" type="SimulationGeneratedMesh"/>
</outputs>
</task>
For a list of supported transfer types and their corresponding transfer properties, see Appendix B (p. 317).
Property Groups and Properties
Instead of using parameters to drive your simulation, you can work through the data model, simplifying
data access by defining custom properties.
Properties can be defined in the optional <propertygroup> node. At minimum, each property
group definition must include the name attribute. The caption attribute will be used as the group
category name in the Workbench Property view if the child properties are visible.
Individual properties can be defined in the <property> node, which can be either a child to
<propertygroup> or a stand-alone definition at the same level. At minimum, each property
definition must include the name and control attributes.
The basic structure of a property definition is shown below:
visible=""
</propertygroup>
visible=""
Properties are linked to entity definitions in the referenced IronPython script, which makes use of
the following commands:
GetCustomEntity: Gets the property-containing entity.
GetCustomEntityPropertyValue: Gets the property. This query obtains the entity property value
for a custom property defined on the task.
SetCustomPropertyValue: Sets the property. This command sets the entity property value for a
custom property defined on the task.
Parameters
You can integrate an external application with the Project Schematic by defining parameters that are
created dynamically at initialization.
Parameters are defined in the optional <parameters> node. At minimum, each parameter definition must include the following attributes: name, usage, control, and version.
The basic structure of a parameter definition is shown below:
<parameters>
</parameters>
88
Defining a Taskgroup
The sole purpose of a taskgroup is to collect tasks. One or more taskgroups can be defined in the
<taskgroups> node. Individual taskgroups are defined in a <taskgroup> child node.
At minimum, each taskgroup definition must include the taskgroup name and version attributes. The
<includetask> and <includeGroup> child nodes are to specify one or more tasks or nested
taskgroups to be included.
If you define a caption, it overrides the task-level caption. Otherwise, the taskgroup-level caption is
used.
The basic structure of a taskgroup definition is shown below:
<taskgroups>
<taskgroup name="" caption="" icon="" category="" abbreviation="" version="1" isparametricgroup=False>
<includetask name=/>
<includeGroup name=/>
</taskgroup>
</taskgroups>
Note
At present, the mixing of ACT-defined and installed tasks and taskgroups is not supported;
ACT-defined tasks cannot be added to installed taskgroups, and installed tasks cannot be
added to ACT-defined taskgroups. Also, nested taskgroups within a taskgroup are not recognized by Workbench at 16.2.
Creating the IronPython Script

The IronPython script defines the actions to be executed during a callback invocation. Python scripts
execute within the Workbench Python interpreter; as a result, scripts have full access to the scriptable
Workbench API (Using Journals and Scripts in the Workbench User's Guide).
For example, the script is used to create update instructions for producing and consuming data. If any
task produces or consumes data, you must supply an Update routine that processes input and output
types as declared by the workflow definition. For a table of supported task inputs and outputs, see the
Appendix A (p. 265).
Upstream Data Consumption (Input)

Typically, tasks need to implement complex source handling logic, connection tracking routines, and a
refresh procedure in order to consume data. ACT abstracts these complexities by automatically performing
these actions during refresh. It obtains upstream data and stores it in a dictionary accessible by the
user during the task Update. The task can obtain this data by calling Convenience APIs (p. 90).
Data Generation (Output)

Tasks that produce output data (for example, declare output types in the taskgroup definition file) must
ensure that their custom Update routine assigns output data.
The extension definition XML file prepares empty data objects representing task outputs; the user must
only set the correct transfer properties that downstream consumers will interrogate. Refer to Appendix B (p. 317) to determine which properties you must set.
89
For example, a material transfer to a downstream Engineering Data task must set the DataReference
TransferFile property on a MatML31 data object to the file reference of a registered matmlformatted XML file, all completed during the Update routine.
Convenience APIs
Convenience APIs are IronPython queries that provide simple access to task-stored input and output
data. The available convenience APIs are:
GetInputDataByType
Returns a List<object> containing upstream data for a given type. For example:
upstreamData =
container.GetInputDataByType(InputType="MeshingMesh")
meshFileRef = None
upstreamDataCount = upstreamData.Count
if upstreamDataCount > 0:
meshFileRef = upstreamData[0]
GetOutputData
Returns a Dictionary<string, List<DataReference>> holding the task's output types. For
example:
outputRefs = container.GetOutputData()
meshOutputSet = outputRefs["SimulationGeneratedMesh"]
meshOutput = meshOutputSet[0]
meshOutput.TransferFile = meshFileRef
GetCustomEntity
Obtains the custom data entity from a container based on the entity's name and type. If the name and
type are not specified, the default ACT object is returned. This object contains the properties defined by
the workflow task from the <propertygroup> and <property> blocks.
entity = ACT.GetCustomEntity(container)
GetCustomEntityPropertyValue
This query returns the value of a property defined on a custom data entity.
inputValue = ACT.GetCustomEntityPropertyValue(entity, "Input")
SetCustomEntityPropertyValue
This command handles the setting of a custom entity's property value.
ACT.SetCustomEntityPropertyValue(entity, "Output", outputValue)

This section discusses customization of the ANSYS AIM application. By using ACT in ANSYS AIM, you
can add a custom load for a structural analysis (similar to the functionality available in ANSYS Mechanical) and create a full fluidic system encapsulating all available boundary conditions.
Adding a Pre-Processing Feature in ANSYS AIM Structural

This section discusses customization of the ANSYS AIM application for the native exposure of a preprocessing feature--specifically, how to add a custom load to a structural analysis. The example used
in the discussion is defined in the CustomPressure extension, which was written to create a custom
pressure as a load. This example is for demonstration purposes only.
We will address the extensions's XML and Python file separately.
90
Custom Load Definition in the XML File

Below are the contents of the CustomPressure.xml file, which adds the custom pressure load to
our project.
<extension version="1" name="CustomPressure">
<guid shortid="CustomPressure">314bd00a-2f64-4b62-8196-bab9206c2c6b</guid>
<simdata context="Study">
<load name="CustomPressure" version="1" caption="CustomPressure" icon="tload" issupport="false"
isload="true" color="#0000FF" >
<callbacks>
<getsolvecommands order="1">writeNodeId</getsolvecommands>
</callbacks>
<attributes selection_filter="face" />
</property>
<property name="Expression" caption="Expression" datatype="double" control="float"
unit="Pressure" isparameter="true"></property>
</load>
</simdata>
</extension>
As in previous examples, the XML file first defines the extension using a version and name attribute.
The path to the Python script file main.py is specified by the <script> tag.
The definition of the load is encapsulated by the <simdata> begin and end tags. The context attribute
for <simdata> has been set to Study , which makes the extension compatible with AIM. The attributes
in the <load> begin tag provide the name, version, caption, icon, support status, and color that apply
to this load. The color attribute is defined in a hexadecimal format. This color is used to contrast the
load when it is displayed on the model. The <callbacks> tag encapsulates the callback <getsolvecommands>. This tag specifies the name of the Python function that is called when the solver input
file is generated by the application. Consequently, the related Python function is responsible for generating the commands that describe the load within the ANSYS input file.
of the load. These properties are displayed in the specific ACT object created by the extension, where
the user provides the necessary values to complete the load definition.
Note that neither property requires the definition of a callback.
The first property, Geometry, uses a scoping control type, and has the selection_filter attribute
set to face. This property allows you to select the face of the geometry to which the custom pressure will
be applied.
The second property, Expression, uses a float control type, which provides the property with access
to AIM expressions functionality. Consequently, you can enter an expression into the Expression property
field and expect a float. Setting datatype to double introduces a physical quantity dependency with the
unit option, which is set to Pressure; this combination specifies that this property is consistent with a
pressure. Finally, setting isparameter to true specifies that this expression can be parameterized.
Custom Load Definition in the Python File

Here is the Python script file main.py used for the CustomPressure extension.
91
def writeNodeId(load, stream):
ExtAPI.Log.WriteMessage("writeNodeId...")
stream.WriteLine("/com, GetSolveCommands")
property_expression = load.PropertyByName("Expression")
expression = property_expression.Value
ExtAPI.Log.WriteMessage(expression.ToString())
if expression=="":
return None
property_geometry = load.PropertyByName("Geometry")
refIds = property_geometry.Value.Ids
ExtAPI.Log.WriteMessage(refIds.ToString())
mesh = ExtAPI.DataModel.MeshDataByName("Mesh 1")
ExtAPI.Log.WriteMessage(meshRegion.ToString())
nodeIds = meshRegion.NodeIds
for nodeId in nodeIds:
stream.WriteLine("F,"+nodeId.ToString()+", FX,"+expression.ToString()+"\n")
The main.py Python file defines the writeNodeId function, which writes the value of the Expression
property on the geometry nodes scoped for the load.
The following figure shows that the CustomPressure ACT load weve created is now made available
to be added as a boundary condition in AIM.
92

Figure 49: CustomPressure Load Available as a Boundary Condition in AIM
The following figure shows the status of the load once all the properties are defined.
Figure 50: CustomPressure Load with Properties Defined
93
Creating a Custom Object to Merge Existing AFD Features (Process Compression)

By using ACT extensions in AIM, you have the ability to create a complete fluidic system encapsulating
existing boundary conditions. This section discusses the customization of the ANSYS AIM application
to expose a fluids system with access to all available boundary conditions.
You can have one load per boundary condition, and have access to all fluid boundary conditions (i.e.
inlet, outlet, wall, etc.). The boundary conditions will appear as scoping properties. In some instances,
you can also add an inlet velocity and an outlet pressure to standard boundary conditions.
Fluids extensions developed in AIM are very similar in construction to other extensions developed in
AIM or Workbench. As with other extensions, each AFD extension developed in AIM will have an XML
file and an IronPython script.
The XML file will have both a section containing an element to define buttons and toolbars, and a section
containing callbacks and properties to define the load.
The Python script will define functions invoked by the events and callbacks in the XML file to implement
the behavior of the extension.
As an example, we will use an extension called AFDLoad . This example is for demonstration purposes
only. We will address the extensions's XML and Python file separately.
Fluidic System Definition in the XML File

Below are the contents of the AFDLoad.xml file, which is used to create a fluidic system with full access
to available boundary conditions.
<extension version="1" name="AFDLoad">
<interface context="Study">
</interface>
<simdata context="Study">
<load name="InOut" version="1" caption="InOut" icon="support" issupport="true" color="#0000FF">
<callbacks>
<getsolvecommands>getcmds</getsolvecommands>
</callbacks>
<property name="Inlet" caption="Inlet" control="scoping" />
<property name="Outlet" caption="Outlet" control="scoping" />
<property name="InletVelocity" caption="Inlet Velocity" control="float" unit="Velocity"
default="1 [m s^-1]"/>
<property name="OutletPressure" caption="Outlet Pressure" control="float" unit="Pressure"
default="0 [Pa]"/>
</load>
</simdata>
</extension>
94

The XML file has the standard ACT construction, with the version and name attributes defining the
extension, the <script> tag specifying Python main.py script file, and the interface tag defining
the context as Study.
As in the AIM preprocessing example, the definition of the load is encapsulated by the <simdata>
begin and end tags, the <simdata> context attribute has been set to Study, and the attributes in
the <load> begin tag provide the name, version, caption, icon, support status, and color that apply
to the load that will contain the boundary condition. (In this example, our load name and caption are
both InOut.) As before, the <callbacks> tag encapsulates the callback <getsolvecommands>,
which creates the boundary conditions for the load.
Below the callbacks section, the load properties to be used for the boundary conditions are defined:
Inlet, Outlet, Inlet Velocity, Velocity, Outlet Pressure, and Pressure. The control
type,unit, and default tags function as described in previous examples. These properties are displayed in the specific ACT object created by the where the user provides the necessary values to complete
the load definition.
Fluidic System Definition in the IronPython File

Here is the Python script file main.py used for the AFDLoad extension.
Note
In future releases, the IronPython commands used to define fluid dynamics features
may be modified to ensure consistency with AIM Journaling and Scripting functionality.
For the information on whether a given command has been modified or deprecated,
refer to the ACT Reference Guide.
import clr
clr.AddReference("Ansys.Study.Proxies.Customization")
from Ansys.Study.Proxies.Customization.Analysis import AFDObject
def getcmds(load,stream):
velocity = load.Properties["InletVelocity"]
pressure = load.Properties["OutletPressure"]
faces = []
faces += load.Properties["Inlet"].Value.Ids
faces += load.Properties["Outlet"].Value.Ids
geo = load.Analysis.GeoData
wallFaces = []
for part in geo.Assemblies[0].Parts:
for face in body.Faces:
if not faces.Contains(face.Id) and not wallFaces.Contains(face.Id):
wallFaces.Add(face.Id)
boundary = AFDObject.CreateBoundary()
boundary.SetProperty("BoundaryType","Inlet")
boundary.SetProperty("Location",load.Properties["Inlet"].Value.Ids)
boundary.SetProperty("Flow.Option","Velocity")
boundary.SetProperty("Flow.Velocity.Magnitude",velocity.Value.ToString()+' ['+velocity.UnitString+']')
boundary.Send(stream)
boundary.SetProperty("BoundaryType","Outlet")
boundary.SetProperty("Location",load.Properties["Outlet"].Value.Ids)
boundary.SetProperty("Flow.Option","Pressure")
boundary.SetProperty("Flow.Pressure.GaugeStaticPressure",pressure.Value.ToString()+'
['+pressure.UnitString+']')
95
boundary.SetProperty("BoundaryType","Wall")
boundary.SetProperty("Location",wallFaces)
The function getcmds is defined in the main.py Python file for the AFDLoad extension. This function
writes commands to the solver input file. The required input arguments are load and stream, where
load is the load object and stream refers to the solver input file. In our example, the function
getcmds is referenced in the AFDLoad.xml file by the <getsolvecommands> callback. When
called, it creates the boundaries for the AFD object, defines boundary properties, and specifies the
face(s) to which the boundary will be applied. Within this function:
The CreateBoundary() method is applied to AFDObject to create a boundary. (This AFD object was
imported by the import command at the top of the Python file.)
In the faces section, we can specify:

The faces to be used in the inlet and outlet properties).
The faces belonging to the wall (i.e. all the faces not already used for the inlet and outlet properties).
With boundary.SetProperty, we specify the boundary type (such as inlet, outlet, wall, etc.). It can also
be applied to the boundary object to add a property. As part of the argument, you must specify both the
type of property to be added and the value to be assigned to it.
For example, the code segment below specifies the creation of an inlet boundary.
boundary.SetProperty("BoundaryType","Inlet")
With boundary.SetProperty, we can also specify the location (faces, bodies, etc.) to which the
boundary will be applied. To do so, we can use the scoping properties previously defined in the extension.
The location property expects a list of identifiers.
boundary.SetProperty("Location",load.Properties["Inlet"].Value.Ids)
To the property that just created, we can add an option representing a velocity (for an inlet) or a pressure
(for an outlet).
boundary.SetProperty("Flow.Option","Velocity")
To the option just added, we add a float value. (This float value could come from a property defined in the
XML file.) We also have the ability to specify a unit.
boundary.SetProperty("Flow.Velocity.Magnitude",velocity.Value.ToString()+' ['+velocity.UnitString+']')
Finally, we write the command generated by creation of the boundary.

The following figure shows that the InOut ACT load weve created is now made available to be added
as a fluids boundary condition in AIM. This load includes all the properties defined in the extension.
96

Figure 51: InOut Load Available as a Fluids Boundary Condition in AIM
The following figure shows the status of the load once all the properties are defined.
Figure 52: InOut Load with Properties Defined
97
98
Custom Guided Processes

ANSYS ACT allows you to automate the simulation process with the creation of custom guided processes.
A guided process developed with ACT is part of a specific extension; in addition to accessing the functionality defined in that extension, it can also leverage the API scripting capabilities available with AIM
and Workbench-based ANSYS products.
A guided process is exposed in Workbench or in a target application (at 16.2, DesignModeler or Mechanical) as a wizard. A wizard walks non-expert end users step-by-step through a simulation.
A guided process is exposed in AIM as a custom template. A custom template automatically sets up
a simulation process by creating a workflow within AIM.
Both methods enable users to benefit from ANSYS simulation capabilities while minimizing interactions
with the standard application interface.
Types of Guided Processes

You can create ACT guided processes to be executed in either ANSYS Workbench or ANSYS AIM. The
following types of guided processes are available:
Workbench Wizards
A Workbench wizard can be created to be executed on the Workbench Project tab or across a combination of the Project tab and target applications such as Mechanical or DesignModeler.
Project Wizard
A Workbench Project wizard is executed in the ANSYS Workbench Project tab. It can incorporate any dataintegrated application with Workbench journaling and scripting capabilities, such as ANSYS DesignXplorer
or ANSYS Fluent, into the simulation workflow.
Mixed Wizard
A mixed wizard is executed across the ANSYS Workbench Project tab and one or more supported target
applications with Workbench journaling and scripting capabilities. A mixed process provides native
workflow guidance in both the Project tab and the target application.
Target Application Wizards

A target application guided process wizard is executed wholly in the specified ANSYS target application
(at 16.2, Mechanical or DesignModeler). It utilizes the functionality provided by the target application
and provides simulation guidance within the applications workflow.
AIM Custom Templates

An AIM custom template is based on AIM journaling and scripting capabilities. It sets up a simulation
project by creating a workflow within ANSYS AIM, enabling you to define a custom data panel with
custom properties to drive your simulation.
99

At present, guided processes in AIM are limited to a single step. Functionality for creating multi-step
guided processes is under development and will be available in future releases of ANSYS AIM.
Note
For examples of all the different types of guided processes, see Custom Guided Process Examples (p. 240).
Creating Guided Processes

To create any type of guided process, you must have an ACT license. Although you can execute a guided
process without an ACT license, the creation of the guided process requires the specification of an extensionthe creation of which, in turn, requires an ACT license.
To start creating guided processes, you can download templates from the ANSYS ACT Application
Store on the ANSYS Customer Portal.
Parts of a Guided Process

ACT-based guided processes are include the following files:
Required XML extension definition file and referenced IronPython script
These files are the same as required for a standard ACT extension and use the same XML and IronPython syntax. In fact, to create a guided process, you can simply begin with an existing extension and
modify it. For details on syntax, see the ANSYS ACT Developer's Guide and the ANSYS ACT Reference
Guide.
Optional custom help files
HTML files containing text, images, charts, or other control types can be used to provide instructions
or details for the guided process.
The XML Extension Definition File

To create a guided process, you must define it in the XML extension definition file. The existing requirements of a standard XML extension file apply. One or more guided processes can be added to the XML
extension file by integrating a <wizard> block for each guided process.
Within the <wizard> block, the definition of the guided process requires, at minimum:
Guided process attributes:
name
version
context
Step definitions:
Step attributes:
name
100

caption
version
context
Callbacks
Properties
Example: XML Extension File for a Project Wizard

To illustrate the definition of a guided process, we will use the XML extension file for a Workbench
Project wizard. Within the extension WizardDemos, we will define the guided process Project Wizard.
Note
Syntax differences for other kinds guided processes (other wizard types or custom templates)
will be noted.
Below is our XML extension file, WizardDemos.xml.
<extension version="2" minorversion="1" name="WizardDemos">
<guid>6D33EFFC-C521-4859-8273-BA320044B6B8</guid>
<author>ANSYS Inc.</author>
<description>Simple extension to test wizards in different contexts.</description>
</interface>
<wizard name="ProjectWizard" version="1" context="Project" icon="wizard_icon">
<description>Simple wizard for demonstration in the Workbench Project page.</description>
<step name="Geometry" caption="Geometry" version="1" context="Project"
CustomContentFile="help/geometry.html">
<description>Create a geometry component.</description>
<callbacks>
<onupdate>CreateGeometry</update>
<onreset>DeleteGeometry</reset>
</callbacks>
<propertygroup display="caption" name="definition" caption="Basic properties" >
<property name="filename" caption="Geometry file name" control="fileopen" />
<property name="myint" caption="Integer value" control="integer" />
<property name="mytext" caption="Text value" control="text" />
<property name="myquantity" caption="Quantity value" control="float" unit="Pressure" />
<property name="myreadonly" caption="Readonly value" control="text" readonly="true"
default="My value" />
<propertygroup display="property" name="myselect" caption="List of choice" control="select"
default="Option1">
<attributes options="Option1,Option2" />
<property name="option1" caption="Option1 value" control="text" visibleon="Option1" />
<property name="option2first" caption="Option2 first value" control="float" unit="Pressure"
visibleon="Option2" />
<property name="option2seond" caption="Option2 second value" control="float" unit="Length"
</propertygroup>
</propertygroup>
</step>
101

<step name="Mechanical" caption="Mechanical" enabled="true" version="1" context="Project"
CustomContentFile="help/mechanical.html">
<description>Create a mechanical component.</description>
<callbacks>
<onupdate>CreateMechanical</update>
<onreset>DeleteMechanical</reset>
</callbacks>
<property name="name" caption="System name" control="text" />
<propertytable name="table" caption="TabularData" display="worksheet" control="applycancel"
</propertytable>
</step>
<step name="Fluent" caption="Fluent" version="1" context="Project" CustomContentFile="help/fluent.html">
<description>Create a fluent component.</description>
<callbacks>
<onupdate>CreateFluent</update>
</callbacks>

<property name="dialog" caption="Dialog" control="text">
<callbacks>
<onvalidate>ValidateDialog</onvalidate>
</callbacks>
</property>
<property name="dialog2" caption="DialogProgress" control="text">
<callbacks>
<onvalidate>ValidateDialogProgress</onvalidate>
</callbacks>
</property>
</step>
<step name="ReportView" caption="ReportView" version="1" context="Project"
layout="ReportView@WizardDemos">
<description>Simple example to demonstrate how report can be displayed.</description>
<callbacks>
<onrefresh>RefreshReport</refresh>
</callbacks>
</step>
<step name="CustomStep" caption="CustomStep" enabled="true" version="1" context="Project"
layout="MyLayout@WizardDemos">
<callbacks>
<onrefresh>RefreshMechanical</refresh>
</callbacks>
</step>
</wizard>
</extension>
Extension definition:
The standard extension definition is the same. The name, version, and IronPython script reference are
unchanged. In our wizard example, the interface context is set to Project because the extension will
be run on the Workbench Project tab.
102

Guided process definition:
The required name, version, and context attributes are defined. In our wizard example, the context
is set to Project because the guided process will be executed from the Workbench Project tab.
The optional icon and description attributes are also defined. Icon files are stored in the images
folder in the extension directory.
Child nodes define the guided process steps.
Note
For a mixed wizard, the <wizard> context would still be set to Project because the
guided process will be launched from the Project tab. Each step in a mixed guided process
would have its context set to the application in which the step will be executedeither
DesignModeler or Mechanical.
For an AIM custom template, the <wizard> context is always set to Study. The name
value is the name of the newly created system that appears under Simulation Process
Templates.
Step definitions:
For each step, the required name, caption, and version attributes are defined. In our wizard example,
note that the optional context is set to Project for all the steps; the steps involve creation of a geometry
and two systems in the Project Schematic, so the steps are executed on the Workbench Project tab.
Note
For each step in a mixed guided process, the context would be set to the application
in which the step will be executedeither DesignModeler or Mechanical.
Optional attributes are defined for various steps. For example, the HelpFile attribute indicates
the file containing custom help content to be shown in the UI.
Child nodes define callbacks and properties.
Callback definitions:
Callbacks execute an action that has been defined in the IronPython script for the guided process. Each
callback receives the current step as a method argument.
The required <onupdate> callback is invoked when you click the Next button for a Workbench wizard.
In our wizard example, it executes the actions CreateGeometry, CreateMechanical, and CreateFluent.
The <onrefresh> callback is invoked when the next step is initialized. It initiates changes to the interface, so you can use this callback to change the appearance of the guided process, initialize a value to
be used in the current step, instantiate variables, access data of an existing project, etc. In our wizard
example, the <onrefresh> callback executes the RefreshReport and RefreshMechanical
actions.
103

The <onreset> callback resets the state of the step. In our example, it executes the DeleteGeometry
and DeleteMechanical actions.
Note
For an AIM custom template, only the <onupdate>, <onrefresh>, and <onreset>
callbacks are supported.
The <onupdate> callback is invoked when you click the Create Simulation Process
button. Typically, it is used to insert the content of an existing journal into the guided
process to create a workflow and establish boundary conditions, mesh, and solver
options.
The <onreset> callback is used to reset situations where the guided process has not
been completed correctly; it allows you to go back to the process properties and
modify them.
Property definitions:
Properties, property groups, and property visibility controls are defined with the same syntax as for a
standard extension property.
The required name , caption , and control attributes are defined for all the properties. The
control attribute specifies the control type for the property. The standard select, float, integer, scoping, text, and fileopen property types are supported. Advanced types such as
applycancel and custom are also supported.
Optional attributes are also defined for various properties.
The unit attribute specifies the units for the property value.
The readonly attribute specifies whether the property value is editable.
The default attribute specifies the default property value.
The visibleon attribute controls the visibility of the property. In our example, it is used to
control the display of conditional options in a property group.
The <propertygroup> node is used to create groupings of properties. In our example:
For the first property group, no control is defined, so the group is a list of individual properties
inside the <propertygroup> tags.
The second property group is embedded within the first.
In our example, the control attribute set to select , which provides a drop-down list.
The attributes options tag defines the available options.
The visibleon attribute defines the properties in the group are defined as conditional based
on selection from the drop-down.
The <onvalidate> property callback is used to validate the value entered for a property.
104

The <propertytable> node is used to create a table for the entry of property values in tabular
format. The Temperature and Pressure properties nested inside the <propertytable> tags
create columns for data entry.
The IronPython Script

The IronPython script is referenced by the XML extension definition file. It defines the functions that
will be used by the extension and also the actions that will be performed during each step of the guided
process.
ANSYS journaling and scripting commands can be used inside the callbacks. You can write the commands
manually or edit commands obtained from a session journal file (either from the temporary journal
stored in your %TEMP% folder or from a journal generated by using the Record Journal menu option).
Example: IronPython Script for a Project Wizard

To illustrate how the IronPython script is used in a guided process, we will continue with the example
used in the previous section, the Workbench Project wizard called Project Wizard.
Note
Syntax differences for other kinds guided processes (other wizard types or custom templates)
will be noted.
Below is the main.py script referenced by our XML extension file.
geoSystem = None
dsSystem = None
fluentSystem = None
def CreateGeometry(step):
global geoSystem
template1 = GetTemplate(TemplateName="Geometry")
geoSystem = template1.CreateSystem()
geometry1 = geoSystem.GetContainer(ComponentName="Geometry")
geometry1.SetFile(FilePath=step.Properties["definition/filename"].Value)
def DeleteGeometry(step):
global geoSystem
geoSystem.Delete()
def RefreshMechanical(step):
tree = step.UserInterface.GetPanel("Tree")
root = tree.CreateTreeNode("Root")
node1 = tree.CreateTreeNode("Node1")
root.Values.Add(node1)
node2.Values.Add(node1)
tree.SetTreeRoot(root)
def CreateMechanical(step):
global dsSystem, geoSystem
template2 = GetTemplate(
TemplateName="Static Structural",
Solver="ANSYS")
geometryComponent1 = geoSystem.GetComponent(Name="Geometry")
dsSystem = template2.CreateSystem(
ComponentsToShare=[geometryComponent1],
105

Position="Right",
RelativeTo=geoSystem)
if step.Properties["name"].Value=="error":
raise UserErrorMessageException("Invalid system name. Please try again.")
dsSystem.DisplayText = step.Properties["name"].Value
def DeleteMechanical(step):
global dsSystem
dsSystem.Delete()
def CreateFluent(step):
global dsSystem, fluentSystem
template3 = GetTemplate(TemplateName="Fluid Flow")
geometryComponent2 = dsSystem.GetComponent(Name="Geometry")
solutionComponent1 = dsSystem.GetComponent(Name="Solution")
componentTemplate1 = GetComponentTemplate(Name="CFDPostTemplate")
fluentSystem = template3.CreateSystem(
DataTransferFrom=[Set(FromComponent=solutionComponent1, TransferName=None,
ToComponentTemplate=componentTemplate1)],
Position="Right",
RelativeTo=dsSystem)
raise Exception("Invalid system name. Please try again.")
fluentSystem.DisplayText = step.Properties["name"].Value
def cbDialog(sender, args):
sender.Container.HideDialog(sender)
def ValidateDialog(step, prop):
dialog = step.UserInterface.GetPanel("ErrorMessage")
dialog.SetMessage("My own error message")
dialog.SetCallback(cbDialog)
dialog.Refresh()
step.UserInterface.Container.ShowDialog(dialog)
def worker(step):
progress = step.UserInterface.GetPanel("Progress")
stopped = progress.UpdateProgress("Start progress...", 0, True)
step.UserInterface.Container.ShowDialog(progress)
for i in range(100):
System.Threading.Thread.Sleep(100)
stopped = progress.UpdateProgress("Start progress...", i+1, True)
if stopped:
break
step.UserInterface.Container.HideDialog(progress)
def ValidateDialogProgress(step, prop):
thread = System.Threading.Thread(System.Threading.ParameterizedThreadStart(worker))
thread.Start(step)
def ValidatePropActivate(step, prop):
if prop.Value=="Yes":
step.NextStep.Enabled = True
else:
step.NextStep.Enabled = False
steps = step.UserInterface.GetPanel("Steps")
steps.UpdateData()
steps.Refresh()
def RefreshReport(step):
report = step.UserInterface.GetPanel("Report")
report.SetFilename(System.IO.Path.Combine(ExtAPI.Extension.InstallDir,"help","report.html"))
report.Refresh()
pass
This script defines all the actions executed by the callbacks in the XML file. Each step defined in the
XML file may include multiple actions. In our example XML extension file:
106

Step 1 (Geometry): The <onupdate> callback executes the CreateGeometry action and the <onreset> callback executes the DeleteGeometry action. These create a geometry on the Project
Schematic and delete it.
Step 2 (Mechanical): The <onupdate> callback executes the CreateMechanical action and the
<onreset> callback executes the DeleteMechanical action.
Step 3 (Fluent): The <onupdate> callback executes the CreateFluent action.
Actions executed by callbacks within property definitions are also defined.
Note
For a mixed wizard, the definition of the first step executed in the Project tab also specifies
the applications and component names from which subsequent steps will be executed. For
instance, in the excerpted code sample below, we can see that multiple actions are defined;
these will be called by the steps in the process definition file.
def action1(step):
template1 = GetTemplate( TemplateName="Static Structural", Solver="ANSYS")
system1 = template1.CreateSystem()
geometry1 = system1.GetContainer(ComponentName="Geometry")
geometry1.SetFile(FilePath=step.Properties["filename"].Value)
nextStep = step.NextStep
if nextStep!=None:
nextStep.SystemName = system1.Name
nextStep.ComponentName = "Geometry"
thirdStep = step.Wizard.Steps["Step3"]
if thirdStep!=None:
thirdStep.SystemName = system1.Name
thirdStep.ComponentName = "Model"
The Custom Help Files

You can use custom HTML help files to provide instructions or details about each step in a guided
process. The files can contain any valid HTML5 syntax and supported media to display your help content.
For wizards, help files can be stored in any folder inside the extension directory. For custom templates,
help files are stored in the help folder in the extension directory.
When the guided process is executed, the file contents will be displayed in the Help panel (at the
bottom of the wizard interface or to the left of the custom template interface).
Wizard Help
You can implement one HTML file for the wizard and one additional HTML file for each defined step.
To implement help files in your wizard, specify the HTML file for a step by using the HelpFile attribute
in the XML step definition.
In Step 1 (the geometry step) of our Project wizard example, the HelpFile attribute is set to
help/geometry.html.
<step name="Geometry" caption="Geometry" version="1" context="Project" HelpFile="help/geometry.html">
107
<callbacks>
<update>CreateGeometry</update>
<reset>DeleteGeometry</reset>
</callbacks>
...
The geometry.html file contains both text and a reference to the image geometry.png, along
with the necessary display information to display the file contents in the Help panel at the bottom of
the guided process UI.
Custom Template Help

You can implement one HTML file for the custom template and one additional HTML file for each defined
property.
Note
In order to use custom help in an AIM custom template, the user of the extension must have
write access to the following directory:
%AWP_ROOT162%\commonfiles\help\ACSHelpServer\docu_aim_html\custom
To implement help files in your custom template:
1. Create a help folder in your extension directory.
2. Create one HTML help file for your template and one for each of its defined properties, naming the files as
follows:
Template: <templatename>.html
Property: <templatename_propertyname>.html
When the extension is loaded to AIM, the folder will be copied into the %AWP_ROOT162%\commonfiles\help\ACSHelpServer\docu_aim_html\custom directory for display in the help panel.
Installing and Loading Guided Processes

Once you've created a guided process, the installation and loading process is the same as for any other
extension.
Installing Scripted Extensions

To install a guided process to disk, save the extension and associated files in one of the following locations:
%AWP_ROOT162%\Addins\AdvancedAddinPackage\extensions
Any of the include directories defined in the Additional Extension Folders field on the Extensions
page of the Options dialog.
108
Using Guided Processes
Installing Binary Extensions

Guided processes can also be created and installed as binary extensions (.wbex). To install a binary
guided process select Extensions > Install Extension and browse to the extension file.
Loading
Your guided processes will not be visible until you have loaded them to your project or Study. To load
a guided process:
1. In the main menu, select Extensions > Manage Extensions.
2. In the Extensions Manager, select the guided processes you want to load.
3. Click OK.
In Workbench or a target application, an Open Wizard button will be added to the toolbar.
In AIM, an icon for each loaded custom template will be added under Simulation Process Templates.

This section discusses accessing and executing an installed and loaded guided process.
The following topics are addressed:
Using a Workbench or Target Application Wizard
Using an AIM Custom Template
Viewing the Guided Process Log File
Using a Workbench or Target Application Wizard

Launching a Wizard
To launch a Workbench or target application wizard:
1. Click the Open Wizard toolbar button.
For a Workbench Project wizard or mixed wizard, the button is in the Project Schematic toolbar.
For a DesignModeler or Mechanical wizard, the button is in a toolbar inside the application.
The Wizard Start Page will open, showing a list of all loaded wizards, including an icon, name,
description, and version for each wizard.
109
2. Click the wizard you want to run.

The wizard interface will open, showing the first step of the wizard.
The Wizard Interface

The default interface for a Workbench-based wizard (i.e. either Project or mixed) is divided into four
panels, as shown below:
110
Top: Shows general information about the wizard and a logo of your choice.
Left: Shows a list of the steps in the wizard, with the current step highlighted.
Right: Shows the data-entry and data-display fields for the selected step.
Bottom: Shows the custom help for the selected step.
Note
The overall content and function of the wizard interface within the Mechanical or DesignModeler application will be the same as in Workbench. However, the display of the interface
may vary slightly according to the application.
Entering Data in a Wizard

For each step of the wizard, enter your data in the fields provided. Entered values will be validated as
specified in the extension.
When all the required values have been entered and pass validation, the Next button will become enabled. When you click this button, your data is submitted and the action defined in the step is executed.
There may be a progress bar for the steps execution, and a message confirming the completion of the
111

step execution will be displayed. You can also verify completion of the step by reviewing the Project
tab.
Once you are past the first step, the Back button is enabled. When you click this button, the wizard
returns to the previous step, but the data generated for that step is lost.
To enter tabular data:
1. Click the Edit button.
2. Click the Add icon to add a table row.
3. Enter values into the cells.
4. When finished entering data, click the green check box icon to save or the red "X" icon to cancel
Exiting a Wizard or Project

To exit a wizard, click the Exit Wizard button in the lower left corner of the interface. This will return
you to the Wizard Start Page. If you exit the wizard midway through, the changes to the project are
retained and can be saved, but the wizard itself is not. You cannot resume the wizard where you left
off when using Exit Wizard.
To exit the project with a wizard still in process, save the project and exit as usual. Upon reopening the
project, the wizard will still be in the state it was last saved in, so you can resume it where you left off.
Using an AIM Custom Template

To launch an AIM custom template:
1. Expand Simulation Process Templates.
The section will contain a custom template for each loaded guided process. (In the image below,
a custom template called Cooling Jacket has been added.)
112
2. Click the custom template you want to run.

On the Study panel, the first part of the workflow defined by the custom template is displayed
as a custom data panel.
Entering Data in a Custom Template

The single step of an AIM custom template creates a custom simulation workflow in AIM. Enter your
data into the initial custom data panel.
1. Enter values into the initial custom data panel, as shown below.
113
2. Click the Create Simulation Process button.

Entered values will be validated at this time as specified in the extension. When all the required
values pass validation, the new simulation process will be created.
Below, you can see that four tasks have been added to the newly created simulation process.
3. Now, with your custom workflow in place, you can work through the simulation as usual.
114
Accessing Custom Help

Custom help can be defined for the step and properties in your custom template. If help is available,
you can access it by expanding the Help panel to the right of the AIM interface, as shown below.
Note
When moving to a different property, you must click the data panel Help icon in order refresh
the Help panel content.
Viewing the Guided Process Log File

You can open the extension log file at any time, and can leave the window open while you are running
your guided process. To view the log file, go to the main menu and select Extensions > View Log File.
You can move or resize the log file window as needed.
115
116
APIs Description
ACT supports application customization with a set of interfaces for each supported application. This
chapter details aspects of the APIs delivered by ACT. The high-level member interfaces of the APIs expose
the properties and methods that allow access to the applications underlying data.
The extensions that are loaded by the Workbench Extension Manager are each configured and initialized
to support Python scripting. For each extension, a global variable ExtAPI gives access to the
DataModel property. This property returns an IDataModel object, which has properties that return
all of the high-level interfaces available for customizations. The complete list of member interfaces is
given in the Application Customization Toolkit Reference Guide.
APIs for ANSYS Mechanical

This section describes some of the APIs provided by ACT for the customization of the ANSYS Mechanical
application. These APIs provide access to all the objects in the Mechanical tree (Project, Model, and
Analysis), allowing you to manipulate the objects and their properties.
Using the APIs, you can both create new objects and modify existing ones.
Note
When you create a new object, Mechanical initializes the object's property values in the
Details window to the same default values used when you add an object via standard mouseclick operations. Some properties, such as scoping or the mass of a point mass, may be invalid
until you enter a value.
117
APIs Description
For more information on ANSYS Mechanical APIs and their properties, refer to the Application Customization Toolkit Reference Guide.
Directly Accessing an Object

You can get to an object by programmatically navigating the Mechanical tree.
The root node of the tree is ExtAPI.DataModel.Project. Each tree node has children that you
can access by calling Children property; this returns all of the child nodes in the project.
You can also call nested properties, such as Model , Geometry , Mesh , or Analyses, in order to
access all of the instances of a given object or tree level.
Connection = ExtAPI.DataModel.Project.Model.Children[3]
Mesh = ExtAPI.DataModel.Project.Model.Mesh
Handling Property Types

This section provides examples of how to handle the various property types used within the Mechanical
application.
Quantity: A unit-based value typically related to a physical quantity.
Example:
my_object.ElementSize = Quantity("0.1 [m]")
Numerical Value (float and integer): A property, such as Relevance or Rate, expecting a numerical
value (a number for which a unit is not specified).
Example:
my_object.TetraGrowthRate = 2
Boolean: A property expecting a True or False value.

Example:
my_object.WriteICEMCFDFiles = True
Geometry Scoping: A property whose value is one or more geometric entities. In these cases, you must:
1. Create selection information and specify the Ids of the entities you want to manipulate.
2. Assign this list of Ids to the Location / SourceGeometry properties.
Example:
my_selection = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
my_selection.Ids= [28,25]
My_object.Location = my_selection
API Examples: Model Object

This section addresses the programming calls that query for properties of Geometry, Mesh, and
Connections properties within the Model object of the ANSYS Mechanical tree.
118

The following examples all share the same four general steps:
1. Obtain the tree item under which the object will be created.
2. Create the object.
3. Create the selection information on which the object will be based.
4. Specify property values for the object.
Geometry: Point Mass

This example shows how to use ACT API to customize the Geometry object in the ANSYS Mechanical
tree. Specifically, it illustrates how to add a point mass on a face of the geometry and activate the pinball
region.
geometry = ExtAPI.DataModel.Project.Model.Children[0]
point_mass = geometry.AddPointMass()
my_selection.Ids = [22]
point_mass.Location = my_selection
point_mass.Mass = Quantity("12 [kg]")
point_mass.MassMomentOfInertiaX = Quantity("1.1 [kg m m]")
point_mass.MassMomentOfInertiaY = Quantity("1.2 [kg m m]")
point_mass.MassMomentOfInertiaZ = Quantity("1.3 [kg m m]")
point_mass.Behavior = LoadBehavior.Coupled
point_mass.PinballRegion = Quantity("0.2 [m]")
It results in the creation of the point mass and activation of the pinball region in ANSYS Mechanical, as
shown below:
Mesh: Mesh Control

This example shows how to use ACT API to customize the Mesh object in the ANSYS Mechanical tree.
Specifically, it illustrates how to create a meshing control that applies the Patch Independent algorithm
to the mesh.
mesh = ExtAPI.DataModel.Project.Model.Mesh
mesh_method = mesh.AddAutomaticMethod()
119
APIs Description
my_selection.Ids = [16]
mesh_method.Location = my_selection
mesh_method.Method = MethodType.AllTriAllTet
mesh_method.Algorithm = MeshMethodAlgorithm.PatchIndependent
mesh_method.MaximumElementSize = Quantity("0.05 [m]")
mesh_method.FeatureAngle = Quantity("12.000000000000002 [degree]")
mesh_method.MeshBasedDefeaturing = True
mesh_method.DefeaturingTolerance = Quantity("0.0001 [m]")
mesh_method.MinimumSizeLimit = Quantity("0.001 [m]")
mesh_method.NumberOfCellsAcrossGap = 1
mesh_method.CurvatureNormalAngle = Quantity("36 [degree]")
mesh_method.SmoothTransition = True
mesh_method.TetraGrowthRate = 1
It results in the creation of a Patch Independent meshing control in ANSYS Mechanical, as shown below:
Connections: Frictionless Contact and Beam

This example shows how to use the ACT API to customize the Connections object in the ANSYS Mechanical tree. Specifically, it illustrates how to add a frictionless contact and a beam connection.
connection = ExtAPI.DataModel.Project.Model.Connections
contact_region = connection.Children[0].Children[0]
contact_region.ContactType = ContactType.Frictionless
beam = connection.AddBeam()
beam.Radius = Quantity("0.005 [m]")
reference_scoping = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
reference_scoping.Ids = [110]
beam.ReferenceLocation = reference_scoping
beam.ReferenceBehavior = LoadBehavior.Deformable
beam.ReferencePinballRegion = Quantity("0.001 [m]")
mobile_scoping = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
mobile_scoping.Ids = [38]
beam.MobileLocation = mobile_scoping
beam.MobileZCoordinate = Quantity("6.5E-03 [m]")
beam.MobilePinballRegion = Quantity("0.001 [m]")
It results in the creation of a frictionless contact and beam connection in ANSYS Mechanical, as shown
below:
Analysis: Load Magnitude

This example shows how to use the ACT API to customize an Analysis object in the ANSYS Mechanical
tree, adding the magnitude of a load. Specifically, it illustrates how to customize a Static Structural
analysis, specifying the external and internal pressure exerted on a pipe and then applying a force to
a section of the pipe.
static_structural = ExtAPI.DataModel.Project.Model.Analyses[0]
analysis_settings = static_structural.AnalysisSettings.NumberOfSteps = 4
bolt = static_structural.AddBoltPretension()
bolt_scoping = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
bolt_scoping.Ids = [200]
bolt.Location = bolt_scoping
bolt.DefineBy = BoltLoadDefineBy.Load
bolt.Preload = Quantity("15 [N]")
support = static_structural.AddFixedSupport()
support_scoping = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
support_scoping.Ids = [104]
support.Location = support_scoping
pressure = static_structural.AddPressure()
pressure_scoping = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
pressure_scoping.Ids = [220]
pressure.Location = pressure_scoping
120

pressure.Magnitude.Output.Formula = '10*time'
pressure = static_structural.AddPressure()
pressure_scoping = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
pressure_scoping.Ids = [221]
pressure.Location = pressure_scoping
pressure.Magnitude.Output.DiscreteValues=[Quantity('6 [Pa]')]
force = static_structural.AddForce()
force_scoping = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
force_scoping.Ids = [219]
force.Location = force_scoping
force.Magnitude.Output.DiscreteValues=[Quantity('11.3 [N]'), Quantity('12.85 [N]')]
In our example, we apply the internal and external pressures to the pipe:
pressure.Magnitude.Output.Formula = '10*time'
pressure.Magnitude.Output.DiscreteValues=[Quantity('6 [Pa]')]
Then we use tabular data to apply a vector force to the pipe:
Note
If you use a constant ramped from t=0s to define the force, the first value cannot be
"0" .
force.Magnitude.Output.DiscreteValues=[Quantity('11.3 [N]'), Quantity('12.85 [N]')]
Script execution results in the creation of a Magnitude property for the applied Force, with time as an
input variable and a single output variable:
Although initially we used tabular data to define the Magnitude property, we can also use a constant
value or a time- or space-dependent formula. Below is an example of how to use a constant value to
define the property:
force.Magnitude.Output.DiscreteValues=[Quantity('10 [N]')]
121
APIs Description
We can also opt to define the Magnitude property with global coordinates, instead of a vector, by using
the following commands:
force.DefineBy = LoadDefineBy.Components
force.ZComponent.Output.DiscreteValues = [Quantity('0 [N]'),Quantity('-9 [N]')]
Result: Total Deformation Maximum

This example shows how to use the ACT API to customize the Result object in the ANSYS Mechanical
tree. Specifically, it illustrates how to add a Total Deformation result to a Static Structural analysis and
then solve for the minimum and maximum total deformation.
solution = ExtAPI.DataModel.Project.Model.Analyses[0].Solution
total_deformation = solution.AddTotalDeformation()
analysis = ExtAPI.DataModel.Project.Model.Analyses[0]
analysis.Solve(True)
minimum_deformation = total_deformation.Minimum
maximum_deformation = total_deformation.Maximum
It results in a solved analysis indicating the values for the Minimum and Maximum properties for the
Total Deformation result, as shown below:
122
API Examples: TraverseExtension

The examples in this section address programming calls that query geometry, mesh, simulation and
results properties. Each of the code samples are taken from the TraverseExtension extension.
Traversing the Geometry

The API for geometry data is organized to match the underlying hierarchical data model. The API offers
a variety of property queries through which the connectivity of the geometry entities can be determined.
For instance, it is possible to query for the faces upon which an Edge is defined by using the faces
property exposed by the edge interface. Refer to the Application Customization Toolkit Reference Guide
for a comprehensive list of these interfaces and their properties.
Shown below is the basic hierarchy of the geometry.
- Geometry
- Assembly
- Part
- Body
- Shell
- Face
- Edge
- Vertex
The Python script function traversegeometry() demonstrates how an extension could traverse
the geometry data. In this example, an object of type IGeoData is obtained from the Analysis object
using the GeoData property. This GeoData object is then used to query for a list of IGeoAssembly
objects by calling the Assembly property. For each of the IGeoAssembly objects in the returned
list, the Parts property is called and a list of IGeoPart objects is returned. This pattern is repeated
through the hierarchy of the geometry down to the vertices of each edge.
123
APIs Description
Below is the content of the traversegeometry() function.
def traversegeometry(analysis):
outFile = analysis.WorkingDir + "SolutionDetails.log"
f.write("*.*.*.*.*.*.*.*\n")
# --- IGeometry Interface
# +++ Properties and Methods
# +++
Assemblies
# +++
CellFromRefId
# +++
SelectedRefIds
geometry = analysis.GeoData
assemblies = geometry.Assemblies
assemblies_count = assemblies.Count
# --- IGeoAssembly Interface
# +++
Name
# +++
Parts
for assembly in assemblies:
assembly_name = assembly.Name
parts = assembly.Parts
parts_count = parts.Count
# --- IGeoPart Interface
# +++
Name
# +++
Bodies
for part in parts:
part_name = part.Name
bodies = part.Bodies
bodies_count = bodies.Count
# --- IGeoBody Interface
# +++
Name
# +++
Vertices
# +++
Edges
# +++
Faces
# +++
Shells
# +++
Material
for body in bodies:
faces = body.Faces
faces_count = faces.Count
# --- IGeoFace Interface
# +++
Body
# +++
Shell
# +++
Vertices
# +++
Edges
# +++
Loops
# +++
Area
# +++
SurfaceType
# +++
PointAtParam
# +++
PointsAtParams
for face in faces:
edges = face.Edges
edges_count = edges.Count
# --- IGeoEdge Interface
# +++
Faces
# +++
Vertices
# +++
StartVertex
# +++
EndVertex
# +++
Length
# +++
CurveType
# +++
Extents
# +++
IsParamReversed
# +++
ParamAtPoint
# +++
PointAtParam
# +++
PointsAtParams
for edge in edges:
vertices = edge.Vertices
124

vertices_count = vertices.Count
# --- IGeoVertex Interface
# +++ Edges
# +++ Faces
# +++ Bodies
# +++ X
# +++ Y
# +++ Z
for vertex in vertices:
xcoord = vertex.X
ycoord = vertex.Y
zcoord = vertex.Z
try:
f.write("
Vertex: "+vertex.ToString()+", X = "+xcoord.ToString()+",
Y = "+ycoord.ToString()+", Z = "+zcoord.ToString()+"\n")
except:
continue
f.close()
return
Traversing the Mesh

The Mesh API offers a variety of property queries through which the connectivity of the mesh entities
can be determined. For comprehensive information on the Mesh API interfaces and properties, see the
Application Customization Toolkit Reference Guide.
The following Python script function traversemesh() demonstrates how an extension could traverse
the mesh data. In the example shown below, an object of type IMeshData is obtained from the
IAnalysis object using the MeshData property. This mesh object is then used to query for a list of
element IDs with the Elements property. For each of the element IDs in the returned list, the Element
method is called and the corresponding IElement object is returned. This pattern is repeated for all
the nodes for each element. Finally, the coordinates of the nodes are queried. Comments are included
in the example below to clarify script functionality.
Below is the content of the traversemesh() function.
def traversemesh(analysis):
f.write("*.*.*.*.*.*.*.*\n")
# --- IMesh Interface
# +++ MeshRegion
# +++ Node
# +++ Element
# +++ Nodes
# +++ Elements
# +++ NumNodes
# +++ NumElements
elementids = mesh.ElementIds
# --- IElement Interface
# +++ Id
# +++ Type
# +++ Nodes
for elementid in elementids:
element = mesh.ElementById(elementid)
nodeids = element.NodeIds
# --- INode Interface
# +++ Id
# +++ X
# +++ Y
125
APIs Description
# +++ Z
# +++ Elements
for nodeid in nodeids:
node = mesh.NodeById(nodeid)
nodex = node.X
nodey = node.Y
nodez = node.Z
try:
f.write("
Element: "+elementid.ToString()+" Node: "+nodeid.ToString()+",
X = "+nodex.ToString()+", Y = "+nodey.ToString()+",
Z = "+nodez.ToString()+"\n")
except:
continue
f.close()
return
The Python script function elementcounter() demonstrates another example of how an extension
could access the mesh data. In this example, only the elements of user-selected geometry entities are
considered. First, the script obtains the IGeoData and IMeshData objects. Then the CurrentSelection.Ids property queries the IDs of the selected geometry entities using the ISelectionMgr
object. If no IDs are returned, a MessageBox displays the message "Nothing Selected." Otherwise, the
GeoEntityById and MeshRegionById methods obtain the IGeoEntity and IMeshRegion
objects corresponding to each selected entity. These two objects are used inside the try-except block
to query for the type of entity selected and the number of elements in each entity's mesh. The Type
property of the IGeoEntity interface and the NumElements property of the IMeshRegion interface
are used here and the results are displayed in a MessageBox.
def elementcounter(analysis):
geometry = analysis.GeoData
selectedids = ExtAPI.SelectionMgr.CurrentSelection.Ids
if selectedids.Count == 0:
MessageBox.Show("Nothing Selected!")
else:
for selectedid in selectedids:
entity = geometry.GeoEntityById(selectedid)
meshregion = mesh.MeshRegionById(selectedid)
try:
numelem = meshregion.ElementCount
MessageBox.Show("Entity of type: "+entity.Type.ToString()+
" contains "+numelem.ToString()+
" elements.")
except:
MessageBox.Show("The mesh is empty!")
return
return
Traversing Results
The Python function minmaxresults() computes the minimum and maximum component values
of the nodal displacement and the SXX stress component. It begins by instantiating a result reader using
the analysis.ResultsData method. Results are retrieved relative to the finite element model and
queried using either the elementID (elemental result) or the nodeID (nodal result). The displacement
result "U" is a nodal result, whereas the stress result "S" is a result on nodes of the elements. The displacement result stores a set of component values for each node, where the component names are X,
Y and Z.
The script minmaxresults first iterates over the nodeIDs to compute the minimum and maximum
values. Then, the script iterates over the elementIDs and the nodes of each element to compute the
minimum and maximum values. Note that the second loop over the nodes is filtered to the primary
nodes of the elements, since stress results are available only on these primary nodes. Finally, the results
are written to the output file.
126

Below are the contents of the minmaxresults() function.
def minmaxresults(analysis):
f.write("*.*.*.*.*.*.*.*\n")
#
# Get the element ids
#
meshObj = analysis.MeshData
elementids = meshObj.ElementIds
nodeids = meshObj.NodeIds
#
# Get the results reader
#
reader.CurrentResultSet = int(1)
#
# Get the displacement result object
disp = reader.GetResult("U")
num = 0
for nodeid in nodeids:
#
# Get the component displacements (X Y Z) for this node
#
dispvals = disp.GetNodeValues(nodeid)
#
# Determine if the component diplacement (X Y Z) is min or max
#
if num == 0:
maxdispx = dispvals[0]
mindispx = dispvals[0]
maxdispy = dispvals[1]
mindispy = dispvals[1]
maxdispz = dispvals[2]
mindispz = dispvals[2]
num += 1
if dispvals[0]
maxdispx =
if dispvals[1]
maxdispy =
if dispvals[2]
maxdispz =
if dispvals[0]
mindispx =
if dispvals[1]
mindispy =
if dispvals[2]
mindispz =
> maxdispx:
dispvals[0]
> maxdispy:
dispvals[1]
> maxdispz:
dispvals[2]
< mindispx:
dispvals[0]
< mindispy:
dispvals[1]
< mindispz:
dispvals[2]
# Get the stress result object

# Select the component to retrieve
stress.SelectComponents(["X"])
num = 0
for elementid in elementids:
element = meshObj.ElementById(elementid)
#
# Get the SXX stress component
#
stressval = stress.GetElementValues(elementid)
#
# Get the primary node ids for this element
#
nodeids = element.CornerNodeIds
for i in range(nodeids.Count):
127
APIs Description
#
# Get the SXX stress component at node "nodeid"
#
SXX = stressval[i]
#
# Determine if the SXX stress component is min or max
#
if num == 0:
maxsxx = SXX
minsxx = SXX
if SXX > maxsxx:
maxsxx = SXX
if SXX < minsxx:
minsxx = SXX
num += 1
#
# Write the results to the output
#
f.write("Max U,X:Y:Z = "+maxdispx.ToString()+" : "+maxdispy.ToString()+" : "+maxdispz.ToString()+"\n")
f.write("Min U,X:Y:Z = "+mindispx.ToString()+" : "+mindispy.ToString()+" : "+mindispz.ToString()+"\n")
f.write("Max SXX = "+maxsxx.ToString()+"\n")
f.write("Min SXX = "+minsxx.ToString()+"\n")
f.close()
User Interface and Toolbars

The UserInterface API provides methods to control the ACT-based GUI of Mechanical. The API is
available using the following entry point:
ExtAPI.UserInterface
This API allows access to toolbars and provides the ability to hide or gray-out ACT-based features. Note
that it cannot be used to create new items (e.g., toolbars); it only provides access to existing UI elements.
ExtAPI.UserInterface.Toolbars is a collection of toolbar objects. Each object has fields to access
Name/Caption/Visibility/Child Entries. Each child has the following properties: Caption,
Enabled, Entries, EntryType, Name, and Visible.
The boolean fields Visible and Enabled can be set to "show" or "hide" so that the user can control
the availability of the buttons depending on the current context.
APIs for ANSYS Design Modeler

The following sections describe some of the APIs provided by ACT for the customization of ANSYS
DesignModeler's interface and functionality. Once these customizations are in place, they can be used
to create and manipulate geometries. You can use them to first define and generate primitives and
bodies, and then to apply various operations, tools, or automated processes to the resulting geometries.
The examples provided in this chapter address working with a selected graphic, creating different types
of primitives, and applying different operations. The code for creating primitive bodies or applying operations must be integrated into the <ongenerate> callback.
For more comprehensive information on the DesignModeler API interfaces and their properties, refer
to the Application Customization Toolkit Reference Guide.
Using the Selection Manager in DesignModeler

The DesignModeler Selection Manager API allows you to work with graphical selections. It provides
service to get information from and to modify, clear, or retrieve the current selection. Additionally, it
enables you to create new selections or add entities to the new selection.
128
Working with the Current Selection

The following Selection Manager commands allow you to perform different actions on the currently
selected graphic.
To access the Selection Manager:
selection_manager = ExtAPI.SelectionManager
To clear the current selection:

selection_manager.ClearSelection()
To retrieve the current selection:

selection = selection_manager.CurrentSelection
This command returns an ISelectionInfo object that describes the selected entities.
To retrieve entities:
selection.Entities
Creating a New Selection and Adding Entities

The Selection Manager enables you to create new selections and add entities to the current selection.
Both of these tasks can be accomplished by either creating a new ISelectionInfo object or by
directly using a list of entities.
To create a new selection using a new ISelectionInfo object:
face = ExtAPI.DataModel.GeoData.Bodies[0].Faces[0]
selection = selection_manager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
selection.Entities = [face]
selection_manager.NewSelection(selection)
To create a new selection using a list of entities:

selection_manager.NewSelection([face])
To add entities to the current selection using a new ISelectionInfo object:

selection = selection_manager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
selection.Entities = [face]
selection_manager.AddSelection (selection)
To add entities to the current selection using a list of entities:

selection_manager.AddSelection([face])
Creating Primitives
The DesignModeler Primitives API provides you with the ability to create different types of primitive
bodies: sheet bodies, wire bodies, and solid bodies. For each primitive body type, multiple shape options
are available.
129
APIs Description
Figure 53: Primitive body type and shape options
The <primitives> variable ExtAPI.DataModel.GeometryBuilder.Primitives is the

gateway for designing a new geometric body. The code must be integrated into the <ongenerate>
callback.
The Python script function ongenerate() can be used to create a primitive body. The API provides
a variety of queries that allow you to specify properties such as body type, dimensions, shape, point
coordinates, and material.
Creating a Sheet Body

When creating a sheet body, you have the option of defining it in the shape of a cone, cylinder, polygon,
or sphere. Below is an example of the ongenerate() function when used to define a sheet body
cylinder.
def Ongenerate(feature,function):
width = 0.015
height = 0.3
sheetBodies = []
primitive = ExtAPI.DataModel.GeometryBuilder.Primitives
cylinder = primitive.Sheet.CreateCylinder([0.,0.,0.],[0.,0.,height],width)
cylinder_generated = cylinder.Generate()
sheetBodies.Add(cylinder_generated)
feature.Bodies = sheetBodies
feature.MaterialType = MaterialTypeEnum.Freeze
return True
In this example:
The width and height variables are used to define the width and the height of the cylinder.
The sheetBodies variable specifies the type of primitive to be created.
The primitive variable uses the global variable ExtAPI to access the data model and define the geometry
builder, which serves as entry point for ACT into DesignModeler.
130

The CreateCylinder () method is used to generate the new body, specifying that it is defined by the
following arguments:
Coordinates of the center point of the cylinders base
Coordinates of the center point of the upper face (which will define the direction of the cylinder)
Value of the radius
(This is a float. The integer value << 3 >>, for instance, will be refused, while a value of << 3. >>
will be accepted.)
With the cylinder_generated object, we use the Generate () method to generate the cylinder, as
shown below.
Figure 54: Generation of sheet body cylinder primitive
With the lines sheetBodies.Add(cylinder_generated) and feature.Bodies = sheetBodies,

we add the sheet body cylinder to the feature.bodies list so it will be added to DesignModeler after
generation. Bodies not added to this list will not be retained.
With the MaterialType line, we specify a material property of Freeze.
Creating a Wire Body

When creating a wire body, you have the option of defining it in the shape of an arc, curve, ellipse, or
polyline. Below is an example of the ongenerate() function when used to define a wire body polyline.
points_list = [0.,0.,0., 1.,0.,0., 1.,1.,0., 1.,1.,1.]
wireBodies = []
polyline = primitive.Wire.CreatePolyline(points_list)
polyline_generated = polyline.Generate()
wireBodies.Add(polyline_generated)
feature.Bodies = wireBodies
return True
131
APIs Description
In this example:
The points_list () method is defined for later use in the creation of the polyline body. For arguments,
it expects as a list of coordinate points (defined by three float values per point).
The CreatePolyline () method is applied to the object Wire to generate the new body. As arguments,
this method is expecting the coordinate points defined by the points_list method above.
With the polyline_generated object, we use the Generate () method to generate the polyline, as
shown below.
Figure 55: Generation of wire body polyline primitive
The new body is added to the feature.bodies list, as described in Creating a Sheet Body (p. 130).
With the MaterialType line, we specify a material property of Add.
Creating a Solid Body

When creating a solid body, you have the option of defining it in the shape of a box, cone, cylinder, or
sphere. Below is an example of the ongenerate() function when used to define a solid body box.
point1 = [0.,0.,0.]
point2 = [1.,2.,2.]
solidBodies = []
box1 = primitive.Solid.CreateBox(point1, point2)
box1_generated = box1.Generate()
solidBodies.Add(box1_generated)
feature.Bodies = solidBodies
return True
In this example:
The point1 () and point2 () methods are defined for later use in the creation of the solid body. For
arguments, they each expect as a list of coordinate points (defined by three float values per point).
132

The CreateBox () method is applied to the object Solid to generate the new body. For arguments,
this method is expecting the coordinate points defined by the point1 and point2 methods above.
With the box1_generated object, we use the Generate () method to generate the box, as shown
below.
Figure 56: Generation of solid body box primitive
The new body is added to the feature.bodies list, as described in Creating a Sheet Body (p. 130).
With the MaterialType line, we specify a material property of Freeze.
Applying Operations
The DesignModeler Operations API enables you to perform different operations on a geometric body.
Available operations can be divided into two different categories: Primary and Boolean Operations
and Tools Operations.
Figure 57: Operation types and options
133
APIs Description
The operation variable ExtAPI.DataModel.GeometryBuilder.Operations is the gateway
for performing operations. The code must be integrated into the <ongenerate> callback.
The Python script function ongenerate() can be used to perform various types of operations on a
geometry feature. The API provides primary and Boolean operations that allow you to specify properties
such as body type, dimensions, shape, point coordinates, and material. It also offers a number of tools
that can be used to manipulate your geometry, including actions such as copying or deleting a body
or using transform operations to create a body based on another body or topological components.
Applying the Extrude Operation

When using the Extrude operation, you must first create the geometry to which the extrusion will be
applied. You can create any of the sheet primitive shapes listed in Creating Primitives (p. 129). Once the
geometry has been created, you can define and apply the Extrude operation to it.
Below is an example of the ongenerate() function when used to create a polygon sheet body and perform
an Extrude operation.
length = 0.3
bodies = []
polygon=builder.Primitives.Sheet.CreatePolygon([0.,0.,3*length,0.,0.,2.*length,length,0.,2.*length])
polygon_generated = polygon.Generate()
extrude = builder.Operations.CreateExtrudeOperation([0.,1.,0.],length/2.)
bodies.Add(extrude.ApplyTo(polygon_generated)[0])
return True
In this example:
The first part of the function creates a polygon sheet body, using a process similar to the one used to create
a cylinder in Creating a Sheet Body (p. 130).
With the Extrude operation, we use the operations generator builder.Operations.CreateExtrudeOperation. The CreateExtrudeOperation method specifies that the operation is defined by
the following arguments:
Vector coordinates (which will define the direction of the extrusion)
Length of the extrusion
Note
In our example, the same Length variable is used for both the sheet body and the
extrusion definition. We also could have used a different variable for each.
The ApplyTo method specifies the geometry to which the extrude operation will be applied. The ApplyTo() method returns a list of bodies to which the operation will be applied.
134

With the lines bodies.Add(extrude.ApplyTo(polygon_generated)[0]) and feature.Bodies
= bodies, we add the extruded sheet body polygon to the feature.bodies list so it will be added to
DesignModeler after generation. Bodies not added to this list will not be retained.
Figure 58: Application of the Extrude operation to a sheet body polygon
Applying the Transform Edges to Wire Tool

When using the Transform Edges to Wire operation tool, you must first create a geometry that
has some edges. You can create any of the sheet body or solid body shapes listed in Creating Primitives (p. 129). Once the primitive has been created, you can obtain a wire body from its edges by defining
and applying the Transform Edges to Wire tool.
Below is an example of the ongenerate() function when used to create a polygon sheet body apply
the Transform Edges to Wire tool to it.
length = 0.3
bodies = []
polygon = builder.Primitives.Sheet.CreatePolygon([0.,0.,2.*length,0.,0.,1.*length,length,0.,0.7])
polygon_generated = polygon.Generate()
body = builder.Operations.Tools.EdgesToWireBody(polygon_generated.Edges);
bodies.Add(body)
return True
In this example:
The first part of the function creates a polygon sheet body, using a process similar to the one used to create
a cylinder in Creating a Sheet Body (p. 130).
With the body function, we use the operations generator builder.Operations.Tools.EdgesToWireBody. The EdgesToWireBody method specifies that the operation tool will transform the edges of the
sheet body polygon into a wire body.
Note
In our example, the same Length variable is used for multiple faces of the sheet body.
We also could have used a different variable for each face.
135
APIs Description
The new wire body is added to the feature.bodies list, as described in Applying the Extrude Operation (p. 134).
Figure 59: Application of the Edges to Wire Body tool to a sheet body polygon
APIs for ANSYS DesignXplorer

The APIs provided by ACT to customize the ANSYS DesignXplorer application are addressed in the following sections.
DOE APIs
This section discusses the APIs provided by ACT to customize DesignXplorer DOE functionality.
DOE Architecture
The object PSMtrxGenerator is responsible for the execution of the DOE. Regardless of whether the
sampling is built-in or external, it executes the same process via the sampling API.
The main elements of the API, shown below in Figure 60: DesignXplorer's Sampling Architecture (p. 137),
are as follows:
ISamplingMethod : the main interface between DX and the external sampling, which is required to implement it
IServices: the interface for the external sampling to access DX services, such as the calculation of one
or more points
DXPoint: the class that describes and stores the point data, such as variable values, calculation state, etc.
136

Figure 60: DesignXplorer's Sampling Architecture
For more details about the API, see the "API Description" section in the ACT Reference Guide for
DesignXplorer.
The Sampling Process

The PSMtrxGenerator object drives the sampling process as illustrated by the sequence diagram in
Figure 61: DesignXplorer's Sampling Process (p. 138).
First, it retrieves an instance of the sampling through the callback declared in the extension. It provides
the Services object and transfers the complete sampling definition: all variables, parameter and
settings.
Note that the PSMtrxGenerator object retrieves an instance of the sampling each time the sampling
process is started (by invoking the OnCreate callback) and released on completion (by invoking the
OnRelease callback).
After a final CanRun check, the sampling's Run method is invoked. From this point in the sequence,
the external sampling is driving: triggering the calculation of points as needed and also pushing progress
messages and log messages, depending on its capabilities.
137
APIs Description
Figure 61: DesignXplorer's Sampling Process
Optimization APIs
This section discusses the APIs provided by ACT to customize DesignXplorer optimization functionality.
Optimization Architecture
The object OptimizationEngineMgr is responsible for the execution of the optimization. Regardless
of whether the optimizer is built-in or external, it executes the same process via the optimization API.
The main elements of the API, shown below in Figure 62: DesignXplorer's Optimization Architecture (p. 139), are as follows:
IOptimizationMethod: the main interface between DX and the external optimizer, which is required
to implement it
IOptimizationServices: the interface for the external optimizer to access DX services, such as the
calculation of one or more points
DXOptimizationPoint: the class that describes and stores the points data, such as variable values, calculation state, etc.
138

Figure 62: DesignXplorer's Optimization Architecture
For more details about the API, see the "API Description" section in the ACT Reference Guide for
DesignXplorer.
The Optimization Process

The OptimizationEngineMgr object drives the optimization process as illustrated by the sequence
diagram in Figure 63: DesignXplorer's Optimization Process (p. 140).
First, it retrieves an instance of the optimizer through the callback declared in the extension. It provides
the Services object and transfers the complete optimization study definition: all variables, parameter
relationships, objectives, constraints, and settings.
Note that the OptimizationEngineMgr object retrieves an instance of the optimizer each time the
optimization process is started (by invoking the OnCreate callback) and released on completion (by
invoking the OnRelease callback).
After a final CanRun check, the optimizer's Run method is invoked. From this point in the sequence,
the external optimizer is driving: triggering the calculation of points as needed and also pushing progress
messages, history points, convergence values, and log messages, depending on its capabilities.
139
APIs Description
Figure 63: DesignXplorer's Optimization Process
140
Associated Libraries
This chapter describes the libraries installed with the ACT. These libraries include a set of Python functions
that can be used to develop extensions more efficiently.
The commands related to the examples provided below can be interactively tested using the ACTConsole
extension from the application. The ACTConsole extension is installed with ACT and you can refer to
ACT Console Extension (p. 202) for more detailed information.
The following sections describe a subset of the available libraries. You can access other libraries from
the ANSYS installation directory and consult the source code for a reference on their use. Libraries can
be found in the following directories:
%ANSYSversion_DIR%\..\Addins\AdvancedAddinPackage\libraries\Mechanical
%ANSYSversion_DIR%\..\Addins\AdvancedAddinPackage\libraries\Project
Query to Material Properties

Description
This library allows you to access to all material properties defined in Engineering Data. The material is
defined for each body and can be retrieved using the geometry API.
Location
libraries/Mechanical/materials.py
libraries/Project/materials.py
Usage
import materials
Functions
GetListMaterialProperties(mat)
This function returns a list of property names for the material mat given in argument.
GetMaterialPropertyByName(mat, name)
This function returns the material property name for the material mat.
InterpolateData(vx, vy, vin)
This function computes a linear interpolation vout = f(vin) with f defined by vy = f(vx).
vx represents a list of values for the input variable.
vy represents a list of values for the property that depends on the input variable defined by vx.
141
vin is the value on which the function has to evaluate the property.
Example
This command:
import materials
mat = ExtAPI.DataModel.GeoData.Assemblies[0].Parts[0].Bodies[0].Material
materials.GetListMaterialProperties(mat)
returns the following result:

['Compressive Ultimate Strength', 'Compressive Yield Strength', 'Density', 'Tensile Yield Strength',
'Tensile Ultimate Strength', 'Coefficient of Thermal Expansion', 'Specific Heat', 'Thermal Conductivity',
'Alternating Stress', 'Strain-Life Parameters', 'Resistivity', 'Elasticity', 'Relative Permeability']
This command:
prop = materials.GetMaterialPropertyByName(mat,"Elasticity")
prop

{"Poisson's Ratio": ['', 0.29999999999999999, 0.29999999999999999, 0.29999999999999999],
'Bulk Modulus': ['Pa', 166666666666.667, 175000000000.0, 183333333333.333],
'Temperature': ['C', 10.0, 100.0, 1000.0], "Young's Modulus": ['Pa', 200000000000.0,
210000000000.0, 220000000000.0],
'Shear Modulus': ['Pa', 76923076923.0769, 80769230769.2308, 84615384615.3846]}
This command:
val = materials.InterpolateData(prop["Temperature"][1:],prop["Young's Modulus"][1:],10.)
val
val = materials.InterpolateData(prop["Temperature"][1:],prop["Young's Modulus"][1:],20.)
val

200000000000.0
201111111111.0
Units Conversion
Description
This library implements a set of functions to manipulate the unit dependent quantities within an extension. This library is of particular interest each time quantities have to remain consistent with the current
unit system activated in the application.
Location
libraries/Mechanical/units.py
libraries/Project/units.py
Usage
import units
142
Units Conversion
Function
ConvertUnit(value,fromUnit,toUnit[,quantityName])
This function converts the value from the unit fromUnit to the unit toUnit. The user can specify
the quantity name to avoid conflict during conversion. This quantity name is not mandatory.
Example
This command:
import units
units.ConvertUnit(1,"m","mm")

1000.0
Function
ConvertUserAngleUnitToDegrees(api, value)
This function converts the angle value to the unit degrees. If the current activated unit is already degrees, then the value remains unchanged.
Example
This command:
import units
units.ConvertUserAngleUnitToDegrees(api,3.14)
returns
180. if the angle unit is set to radius when the command is called
3.14 if the angle unit is set to degrees when the command is called
Function
ConvertToSolverConsistentUnit(api, value, quantityName, analysis)
This function converts the valueof the quantity quantityName from the currently activated unit in
the application to the corresponding consistent unit used by the solver for the resolution of the analysis
analysis.
Example
This command:
import units
units.ConvertToSolverConsistentUnit(api,1.,pressure,Static Structural)
returns
10. if the unit system is set to Metric(mm,dat,N,s,mV,mA) when the command is called
Function
ConvertToUserUnit(api, value, fromUnit, quantityName)
143
This function converts the value of the quantity quantityName from the unit fromUnit to the
currently activated unit system in the application.
Example
This command:
import units
units.ConvertToUserUnit(api,1.,m,length)
returns
1000. if the current activated unit is millimeter when the command is called
Function
ConvertUnitToSolverConsistentUnit(api, value, fromUnit, quantityName, analysis)
This function converts the valueof the quantity quantityName from the unit fromUnit to the
consistent unit that is used by the solver for the resolution of the analysis analysis.
Example
This command:
import units
units.ConvertUnitToSolverConsistentUnit(api,1.,m,length,Static Structural)
returns
1000. if the consistent unit is millimeter when the command is called
Function
GetMeshToUserConversionFactor(api)
This function returns the scale factor to be applied to convert a length from the unit associated to the
mesh and the currently activated unit in the application.
Example
This command:
import units
units.GetMeshToUserConversionFactor(api)
returns
1000. if the unit associated to the mesh is meter and if the current activated unit in the application
is millimeter.
MAPDL Helpers
Description
This library implements some helpers to write APDL command blocks or to execute ANSYS Mechanical
APDL programs.
144
Journaling Helper
Location
libraries/Mechanical/ansys.py
libraries/Project/ansys.py
Usage
import ansys
Functions
createNodeComponent(refIds,groupName,mesh,stream,fromGeoIds=True)
This function writes the APDL command block (CMBLOCK) for the creation of a node component related
to the geometry entities identified by refIds into the stream stream. refIds refer to geometric IDs
if fromGeoIds is true and the node IDs are retrieved from geometric entities using the associativity
between the geometry and mesh. If fromGeoIds is false, then refIds refer directly to the node IDs to
be written in the component.
createElementComponent(refIds,groupName,mesh,stream,fromGeoIds=True)
This function writes the APDL command block (CMBLOCK) for the creation of an element component
related to the geometry entities identified by refIds into the stream stream. refIds refer to geometric
IDs if fromGeoIds is true and the element IDs are retrieved from geometric entities using the associativity between the geometry and the mesh. If fromGeoIds is false, the refIds refer directly to the
element IDs to be written in the component.
RunANSYS(api,args,[runDir[,exelocation]])
This function calls the ANSYS Mechanical APDL program with the command line initialized by args.
The user can specify the folder from which he wants to execute the program with runDir. The location
of the executable is also managed with exelocation.
api parameter must be ExtAPI.
Example
import ansys
ansys.createNodeComponent([refId],"myGroup",mesh,stream)
ansys.RunANSYS(ExtAPI,"")
Journaling Helper
Description
This library implements a helper that can be used to transfer data between Mechanical and the Project
page.
Location
libaries/Mechanical/wbjn.py
libraries/Project/wbjn.py
Usage
import wbjn
145
Functions
ExecuteCommand(api,cmd,**args)
This function executes a journal command specified by cmd You can get a result object by using the
function returnValue(obj) in your journal command. All arguments must implement the serialization
interface provided by .Net. The object sent to the function returnValue(obj) must also implement
the serialization interface. This interface is already implemented for many standard types of data (integer,
double, list). Please note that the standard Python dictionary does not implement this interface by
default. If a dictionary is required, use the SerializableDictionary class provided by ACT.
api parameter must be ExtAPI.
ExecuteFile(api,file,**args)
The same as above but executes a journal file specified by file.
Examples
This command:
import wbjn
wbjn.ExecuteCommand(ExtAPI,"returnValue(a+b)",a=2,b=3)

5
This command:
import wbjn
wbjn.ExecuteCommand(ExtAPI,"returnValue(a+GetAllSystems()[0].DisplayText+b)",
a="My first system is: ",b=" !")

My first system is: Static Structural !
This command:
import wbjn
dict = SerializableDictionary[str,int]()
dict.Add("e1",1)
dict.Add("e2",2)
wbjn.ExecuteCommand(ExtAPI,'returnValue(d["e1"]+d["e2"])', d=dict)

3
146

ACT supports application customization using a combination of Python and XML formatted specification
data. The XML file aims at describing the content of the extension.
This chapter focuses on the details of the XML tags and its relation to the application to be customized.
The HTML version of the ACT Reference Guide available from the ANSYS Customer Portal provides information similar to that presented in this chapter. The ACT Reference Guide allows interactive navigation
through the different elements of the extension XML file.
The extension XML file contains an <extension> XML element, which provides the information needed
for initialization and for the extension configuration. The XML file is comprised of the following main
parts:
The <guid> element specifies a unique identifier for the extension.
The <script> element specifies the Python script that defines the functions called by the extension.
The <interface> element specifies the customization to be done at the GUI level.
The <workflow> element defines a custom ACT workflow.
The <simdata> element specifies the custom features to be integrated in the application.
Note
The content of the XML file is case-sensitive.
<extension> Element
This represents the "root" element, or base tag, that all other tags/elements fall under.
The <extension> element contains the <guid>, <script>, <interface>, <workflow>, and
<simdata> elements.
<extension version="[version number]" minorversion="[minor version number]"
name="[extension name]">
<author>author name</author>
<description>description of the extension</description>
<assembly src="[source file name (string)]"
namespace="[namespace (string)]"/>
</extension>
Mandatory attributes
version="[version number (integer)]"
name="[extension name (string)]"
147
Optional attributes
minorversion="[minor version number (integer)]"
<GUID> Element
The GUID element allows a unique identification for the extension.
<extension version="[version id (integer)]"
<guid shortid="[name (string)]">GUID</guid>
</extension>
GUID
Optional attribute
shortid="[name]"
The GUID must remain the same along the evolutions of the extension, independently of the extension
version or name. It is used to uniquely identify an extension. The shortId attribute is needed for
compatibility with old projects. The shortId attribute provides backwards compatibility for extensions
which were developed before the GUID element was available.
<script> Element
<script src="[python file name (string)]"></script></extension>
You can either insert the IronPython script directly into the XML file, or use the src attribute to specify
the path to the script.
Additional paths can be specified by adding new <script> elements.
<script src="[Path]\filename.py" />
If the src attribute is defined, then the tag content is ignored.
Optional attribute
src="[file name.py]"
By default, ACT looks for IronPython scripts in the same directory as the extension. If the scripts are not
located in that directory, you can specify the path the scripts in addition to the file name.
For example:
<script src="my_path\main.py" />
<interface> Element
The <interface> element and its child elements define GUI elements, including custom toolbars.
148
<extension> Element
<interface context="[Project | Mechanical]">
...
</interface>
The interface element information pertains specifically to the GUI. The available elements under
the <interface> tag are presented in the next sections.
Optional attribute
context="[context name]
The context specifies the application for which the interface element applies. At the moment, the
supported contexts are Project, Mechanical, DesignModeler and DesignXplorer.
If no context is specified, then the interface element applies to all the available applications for ACT.
<images> Element
<images>[folder]</images>
...
</interface>
The appropriate folder in which the images to be integrated by the extension have been stored.
By default, ACT looks for images in the same directory as the extension. If images for the extension
have been stored in a subdirectory of the main extension directory called images, the following definition is appropriate. This is the most common situation:
<callbacks> Element
This section applies to the ANSYS Mechanical application only.
<interface context="[Project | Mechanical | ASim]">

<callbacks>
<oninit>[function(context)]</oninit>
<onterminate>[function(context)]</onterminate>
<onload>[function(currentFolder)]</onload>
<onsave>[function(currentFolder)]</onsave>
<resume>[function(binary reader)]</resume>
<save>[function(binary writer)]</save>
<onbeforesolve>[function(analysis)]</onbeforesolve>
<onaftersolve>[function(analysis)]</onaftersolve>
<isanalysisvalid>[function(analysis,firstCheck)] </isanalysisvalid>
<ondraw2d>[function()]</ondraw2d>
<getprecommands> [function(analysis,stream)]</getprecommands>
<getsolvecommands timedependent="[true | false(default)]">
[function(analysis,stream)]</getsolvecommands>
<getpostcommands>[function(analysis,stream)] </getpostcommands>
<onactiveobjectchange>[function(analysis)]</onactiveobjectchange>
<onpoststarted>[function(analysis)]</onpoststarted>
<onpostfinished>[function(analysis)]</onpostfinished>
</callbacks>
...
</interface>
149

The callbacks element and its children specify the Python functions that are invoked based on system
and user-generated events. The callbacks children are described below:
<oninit>[function name(application context)] </oninit>
The oninit element specifies the name of the IronPython function called when the GUI is initialized.
The declaration of the called function must be:
def function_name(context):
The context argument contains the name of the application as defined by the context attribute of
the <interface> element.
<onterminate>[function name(application context)]</onterminate>
The onterminate element specifies the name of the IronPython function called when the application
context is stopped. The declaration of the called function must be:
def function_name(context):
The context argument contains the name of the application as defined by the context attribute of
the <interface> element.
<onload>[function name(Folder)]</onload>
The onload element specifies the name of the IronPython function called when the project is opened
by the application. The declaration of the called function must be:
def function_name(folder):
The input argument folder defines the folder path of the project.
<onsave>[function name(Folder)]</onsave>
The onsave element specifies the name of the IronPython function called when the project is saved
def function_name(folder):
The input argument folder defines the folder path of the project.
The resume element specifies the name of the IronPython function called when the project is opened
def function_name(binary_reader):
The input argument binary_reader defines the reader to be used to get data previously stored by
the resume element. in this case, data are retrieved directly from the standard database of the application
(see the save element description below).
The save element specifies the name of the IronPython function called when the project is saved by
the application. The declaration of the called function must be:
def function_name(binary_writer):
The input argument binary_writer defines the writer to be used to store data. In this case, data
are stored in the standard database of the current application. No new external files are created to store
the specific data related to the extension.
150
<extension> Element
<onbeforesolve>[function name(analysis)] </onbeforesolve>
The onbeforesolve element specifies the name of the IronPython function called when the solve of an
analysis starts. The declaration of the called function must be:
def function_name(analysis):
The input argument analysis defines the current analysis. If the solve request invokes the resolution
of multiple analysis then this callback will be called for each analysis.
<onaftersolve>[function name(analysis)]</onaftersolve>
The onaftersolve element specifies the name of the IronPython function called when the solve of
an analysis is complete. The declaration of the called function must be:
The input argument analysis defines the current analysis.

<isanalysisvalid>[function name(analysis,firstCheck)] </isanalysisvalid>
The isanalysisvalid element specifies the name of the IronPython function called when Mechanical retrieves the status of the analysis. The declaration of the called function must be:
def function_name(analysis,firstCheck):
The input argument analysis defines the current analysis to check.

The input argument firstCheck indicates if Mechanical calls this function before or after the standard
validation. Mechanical will call this function with firstCheck set to True before the standard check
and will call a second time this function with firstCheck set to False after.
This function must return an integer value equal to -1, 0 or 1.
-1 indicates you do not want to check anything here, 0 means that the analysis definition is not yet
valid, and 1 means that the analysis is ready to be solved. If the returned value is not equal to -1 and
firstCheck is equal to True, then the standard check performed by Mechanical is skipped.
<ondraw2d>[function name()] </ondraw2d>
The ondraw2d element specifies the name of the IronPython function called each time the graphics
view of Mechanical is refreshed. This function can be used to draw 2D objects such as labels associated
with a node. The declaration of the called function must be:
def function_name():
<getprecommands> [function(analysis,stream)]</getprecommands>
The getprecommands element specifies the name of the IronPython function called when Mechanical
writes the solver input file. This function allows you to add input solver commands in the stream. The
commands added to this stream are located just after the mesh definition.
<getsolvecommands>[function(analysis,stream)]</getsolvecommands>
The getsolvecommands element specifies the name of the IronPython function called when Mechanical writes the first load step in the solver input file. Like the getprecommands element, this function
allows you to add input solver commands in the stream. The commands added to the stream are located
just after the definition of the first load step.
<getpostcommands> [function(analysis,stream)]</getpostcommands>
151

The getpostcommands element specifies the name of the IronPython function called when Mechanical writes the solver input file. Like the getprecommands element, this function allows you to add
input solver commands in the stream. The commands added to the stream are located just after the
first occurrence of the solve command.
<onactiveobjectchange>[function(object,location)]</onactiveobjectchange>
The onactiveobjectchange element specifies the name of the IronPython function called when
the active object has been changed.
<onpoststarted>[function name(analysis)]</onpoststarted>
The onpoststarted element specifies the name of the IronPython function called when the postprocessing of an analysis starts. The declaration of the called function must be:

<onpostfinished>[function name(analysis)]</onpostfinished>
The onpostfinished element specifies the name of the IronPython function called when the postprocessing of an analysis is complete. The declaration of the called function must be:
<toolbar> Element

<toolbar name="[toolbar internal name (string)]"
caption="[toolbar display name (string)]">

<entry name="[toolbar button internal name (string)]"
caption="[caption name (string)]"
icon="[name of an image located in images folders (string)]"
userobject="[object name (string)]">
<callbacks>

<onclick>[function()]</onclick>
</callbacks>
</entry>
...
</toolbar>
</extension>
The toolbar element supports two attribute nodes: name and caption. They are described below in
the following sections.
152
<extension> Element
name
The value of the name attribute specifies the name used by the application
to reference this toolbar.
caption
The value of the caption attribute specifies the name displayed in the
GUI for toolbar.
Child Elements
The toolbar element supports one or more entry child elements. Each entry element spawns the
creation of a toolbar button. An entry element supports an onclick callback, which specifies the
name of the IronPython function called when the user clicks on the button. The entry element for a
toolbar button is defined as follows:

caption="[caption name (string)]"
<callbacks>

<onclick>[function()]</onclick>
</callbacks>
</entry>
...
</toolbar>
Mandatory attribute
name
The name attribute specifies the name used by the context application to
reference this toolbar button.
Optional attributes
caption
The value of the caption attribute specifies the caption to be displayed when the
mouse is hovered over this toolbar button.
icon
The value of the icon attribute specifies the file name of the icon displayed in
the GUI for this toolbar button, without the file extension. (An icon is a 16x16 pixel
image in BMP, JPG, or GIF format.) This file has to be stored in one of the folders
previously defined in the <images> elements.
userobject
The name of the object to be connected with the entry.
When the userobject attribute is used, the onclick callback is ignored. Depending on the nature
of the object (load, result, general), the button associated with the entry will be activated or deactivated
153

depending on the current active object in the tree of the application. For example, a load object will
not be available from the toolbar when the current active object in the tree is a result object under the
solution folder in Mechanical. This process allows context dependent behavior in the ACT toolbar.
You can create an entry inside another entry to define a drop-down menu.
<workflow> Element
The workflow element defines a custom ACT workflow.
<workflow context="Project">
<tasks>
<task>
</task>
</tasks>
<taskgroups>
<taskgroup>
</taskgroup>
</taskgroups>
</workflow>
context
Specifies the context to which the custom workflow applies. Acceptable values: Project.
<tasks> Element
The tasks element is the top-level entry containing all task definitions.
<tasks>
...
</task>
</tasks>
<task> Element
The task element defines a single task within a workflow. A task captures one application, process, or
logic step.
<callbacks>
</callbacks>
<contextmenus>
</contextmenus>
<propertygroup name="" caption="">
</propertygroup>
<property/>
<parameters>
</parameters>
<inputs>
</inputs>
<outputs>
</outputs>
</task>
name
Specifies the task name. Acceptable values: any valid string.
154
<extension> Element
version
Specifies the task's version number.
Optional attributes
caption
Specifies the task display text. If not supplied, name will be used. Acceptable values: any valid string.
icon
Specifies the image displayed with the task. In the Workbench Project Schematic, this is the icon displayed on the left of a cell block. Acceptable values: a filename of a 16x16 pixel image of the .png
format.
<callbacks> Element
The callbacks element specifies the functions defined by the user's Python code. The callbacks are
described below:
<callbacks>
<onedit></onedit>
<onreset></onreset>
</callbacks>
onupdate
Called when the user updates the task.

onrefresh
Called when the user refreshes the task.

oninitialize
Called when the task is created.

onedit
Called when the user edits the task. By declaring this callback, ACT will automatically expose a default
Edit context menu for this task.
onreset
Called when the user resets the task.

onstatus
Called when the application (e.g. Workbench) asks the task for its current state.
onreport
Called when the user generates a project report. This allows the task to access the report object and
add its own task-specific reporting content.
155
<contextsmenus> Element
The contextmenus element specifies the user-defined context menus to expose on this task. Note
that you can receive an Edit context menu for free by supplying a Python method for the <onedit>
callback.
<contextmenus>
<entry name="" caption="" icon="" version="1" priority="" type="">
<callbacks>
<onclick></onclick>
</callbacks>
</entry>
</contextmenus>
<entry> Element
The entry element specifies the context menu entry.
name
Specifies the entry name. Acceptable values: any valid string.

version
Specifies the context menu version number. Acceptable values: an integer string.
Optional attributes
caption
Specifies the entry display name. If not supplied, name will be used. Acceptable values: any valid string.
icon
Specifies the icon associated with the context menu entry. Acceptable values: a filename of a 16x16
pixel image of the .png format.
priority
Specifies the context menu priority. Indicates where the entry should be placed when other entries are
specified for the same menu. Lower numbers appear at the top of the menu. You can specify groups
by using decimals to indicate {group}.{order}. Acceptable values: a float string.
type
Specifies the entry type. Acceptable values: ContextMenuEntry .

<callbacks> Element
The callbacks element specifies the callbacks defined on the context menu entry.
onclick
Called when the user invokes the context menu entry.
<propertygroup> Element
The propertygroup element specifies a group of properties. In the Workbench Project Schematic,
this exposes a new group in the property view to better organize multiple properties.
156
<extension> Element
<propertygroup name="" caption="">
<property name="" caption="" control="" default="" readonly="" needupdate="" visible=""
</propertygroup>
name
Specifies the property group name. Acceptable values: any valid string.
Optional attributes
caption
Specifies the property group display name. If not supplied, name will be used. Acceptable values: any
valid string.
<property> Element
The property element defines a piece of data to be stored within a task.
<property name="" caption="" control="" default="" readonly="" needupdate="" visible=""
name
Specifies the property name. Acceptable values: any valid string.

control
Specifies the property control type. Acceptable values: string, double, integer, datareference,
boolean, object, quantity, option, list, dictionary, datacontainerreference.
version
Specifies the property version number. Acceptable values: any valid string.
Optional attributes
caption
Specifies the property display text. If not supplied, name will be used. Acceptable values: any valid
string.
default
Specifies the property default value (the initial value). Acceptable values: any valid type-based string.
readonly
Indicates whether the property is an outuput (not editable by the user). Acceptable values: true or
false.
needupdate
Indicates if the property is an input and forcing a state change if the property value is modified. Acceptable values: true or false.
visible
Indicates if the property should be user-visible in the application. Acceptable values: true or false.
157

persistent
Indicates whether the property value should be saved with the project. Use this attribute if you want
to keep data on your task (e.g. display to the user) but not store it in the project file. Acceptable values:
true or false.
parameterizable
Indicates whether the property should be a candidate for parameterization. In Workbench, a true value
will result in a check box displayed to the right of the property to allow users to promote the property
as a Workbench parameter. Acceptable values: true or false.
keytype
The key type of a key-value pair for a property whose control attribute is set to dictionary. Acceptable
values: see control. (Nested collections are not supported at 16.2)
valuetype
The value type of a key-value pair for a property whose control attribute is set to dictionary. Acceptable
values: see control. (Nested collections are not supported at 16.2)
elementtype
The element type of a key-value pair for a property whose control attribute is set to dictionary. Acceptable values: see control. (Nested collections are not supported at 16.2)
<parameters> Element
The parameters element defines the parameters to be exposed by this task.
<parameters>
<parameter name="" caption="" usage="" control="" version="1"/>
</parameters>
<parameter> Element
The parameter element specifies the parameter value for this task. In Workbench, a parameter will be
automatically created for this entry. This will not be associated with a displayed data property.
name
Specifies the parameter name. Acceptable values: any valid string.

usage
Specifies whether the parameter is an input or output. Acceptable values: input or output.
control
Specifies the parameter data type.Acceptable values: Acceptable values: Double, Float, Long,
Quantity.
Optional attributes
caption
Specifies the parameter display text. If not supplied, name will be used. Acceptable values: any valid
string.
158
<extension> Element
version
Specifies the parameter version number. Acceptable values: any valid integer string.
<inputs> Element
The inputs element defines the task inputs for consuming upstream connections.
<inputs>
<input/>
</inputs>
<input> Element
The input element defines an input for this task.
Optional attributes
type
Specifies the data type string representing the data desired for input to this task. Acceptable values:
any valid string.
format
Specifies the format of data desired for input to this task. More specific than type (and always specified
with a corresponding type), this value provides an additional specification for formatting the requested
input data type. In Workbench, for example, you could specify a type as MeshingMesh and the format
as FluentMesh. The former indicates you want to consume a mesh. The latter provides the additional
detail that the mesh should be in the .msh fluent format. Acceptable values: any valid string.
<outputs> Element
The outputs element defines the task outputs for providing downstream connections.
<outputs>
</outputs>
<output> Element
Optional attributes
type
Specifies the data type string representing the data exposed and generated by this task. Acceptable
values: any valid string.
format
Specifies the format of data generated by this task. More commonly used on an input specification than
an output. Acceptable values: Any valid string.
<taskgroups> Element
The taskgroups element is the top-level entry containing the groups of tasks defined in this workflow.
<taskgroups>
<taskgroup name="" caption="" icon="" category="" abbreviation="" version="1"
isparametricgroup="False">
<includetask name=""/>
159

<includeGroup name=""/>
</taskgroup>
</taskgroups>
<taskgroup> Element
The taskgroup element defines a collection of tasks and taskgroups into one single unit.
name
Specifies the taskgroup name. Acceptable values: any valid string.

version
Specifies the taskgroup version. Acceptable values: any valid string.
Optional attributes
caption
Specifies the taskgroup display text. If not supplied, name will be used. Acceptable values: any valid
string.
icon
Specifies the icon associated with the taskgroup. Acceptable values: a filename of a 16x16 pixel image
of the .png format.
category
Specifies the taskgroup category. Use this value to group taskgroups into a general division. In Workbench, this defines the toolbox group into which your taskgroup will appear. Acceptable values: any
valid string.
abbreviation
Specifies the taskgroup abbreviation. In Workbench, this value determines the unique taskgroup directory
into which taskgroup information can be stored. Acceptable values: any valid string.
isparametricgroup
Indicates whether the taskgroup works only on parameters. In Workbench, this value determines
whether or not the group will appear below the Parameter Set bar. Acceptable values: true or false.
<includetask>
The includetask element specifies the task to include in the taskgroup.
name
Specifies the task name. Acceptable values: any valid string.
<includegroup>
The includegroup element specifies the group to include in the taskgroup.
160
<extension> Element
name
Specifies the taskgroup name. Acceptable values: any valid string.
<simdata> Element
The <simdata> element information pertains specifically to the simulation environment. Three child
elements are used for integrating custom loads, custom results and third party solvers into the application.
These three main features are nested as child elements within the <simdata> element.
<simdata context="[Project | Mechanical | DesignXplorer]">
<load> ... </load>
<object> ... </object>
<result> ... </result>
<solver> ... </solver>
</simdata>
</extension>
Optional attribute
context="[context name]
The context specifies the application to which the interface element applies.
If no context is specified, then the interface element applies to all the available applications for
the ACT.
<load> Element
The <load> element and its children allow you to configure the properties of a custom load and specify
the IronPython functions that are invoked based on system and user-generated events. The <load>
element supports eight attribute nodes. These are name, version, caption, icon, issupport,
isload, color and solveorder. These are defined inside the load element as described below:
<simdata context="[Project | Mechanical]">
<load name="[load internal name]"
version="[version identifier of the load]"
caption="[load display name]"
icon="[name of an icon file]"
issupport="[true | false]"
isload="[true | false]"
color="[#xxxxxx]"
contextual="[true(default) | false]"
161

class="[class name]"
unit="[Default unit name]"
...
</load>
</simdata>
The element has two child elements: the callbacks element and the property element. These two
elements and their children are presented in the next two sections.
name
to reference this load.
version
The value of the version attribute allows the load author to attach a
version number to this load.
caption
The value of the caption attribute specifies the name displayed in the
GUI for this load.
icon
The value of the icon attribute specifies the file name of the icon
displayed in the GUI for this toolbar button, without the file extension.
(An icon is a 16x16 pixel image in BMP, JPG, or GIF format.) This file has
to be stored in one of the folders previously defined in the <images>
elements.
Optional attributes
issupport
The value of the issupport attribute specifies that this load has to be
interpreted as a boundary condition.
isload
The value of the isload attribute specifies that this load has to be
interpreted as a load.
color
The value of the color attribute specifies the color to be used when
scoped geometry is displayed. Color is defined by a six-digit hexadecimal
number. This number consists of three two-digit numbers corresponding
to red, green and blue (RGB) values.
#XXxxxx = red
#xxXXxx = green
#xxxxXX = blue
contextual
If true, the load can be added directly from the Insert context menu on
the load object.
class
Class name to be linked with the load.
unit
Default unit to be used for contour display (if needed).
<callbacks> Element
<load name="[load internal name (string)]"
162
<extension> Element
version="[version identifier of the load (integer)]"
caption="[load display name (string)]"
color="[#xxxxxx]" >
<callbacks>
<onmigrate>[function(newLoad,oldLoad)]</onmigrate>
<onshow>[function(load)]</onshow>
<onhide>[function(load)]</onhide>
<oninit>[function(load)]</oninit>
<onadd>[function(load)]</onadd>
<onremove>[function(load)]</onremove>
<onsuppress>[function(load)]</onsuppress>
<onunsuppress>[function(load)]</onunsuppress>
<getcommands>[function(load,solverdata,stream)]</getcommands>
<getprecommands order="[(integer)]">[function(load,stream)]</getprecommands>
<getsolvecommands order="[(integer)]" timedependent="[true | false(default)]>
[function(load [,step],stream)]</getsolvecommands>
<getpostcommands order="[(integer)]">[function(load,stream)] </getpostcommands>
<getnodalvaluesfordisplay>[values=function(load,nodeIds)]</getnodalvaluesfordisplay>
<canadd>[function(analysis,loadName)]</canadd>
<onduplicate>[function(load)]</onduplicate>
<canduplicate>[function(load,parent object)]</canduplicate>
<canremove>[function(load)]</canremove>
<action name="[(string)]" caption="[(string)]" icon="[(string)]">
[function(load)]</action>
<ongenerate>[function(load,fct)]</ongenerate>
<onaftergenerate>[function(load)]</onaftergenerate>
<oncleardata>[function(load)]</oncleardata>
<isvalid>[function(load)]</isvalid>
</callbacks>
</load>
The <callbacks> element and its children enable you to specify the Python functions that are invoked
based on system and user-generated events related to the load behavior. The callbacks children are
described below:
<onmigrate>[function(new_load,old_load)] </onmigrate>
163

The onmigrate element specifies the name of the IronPython function called when Mechanical loads
the ACT customized load. This function allows you to maintain the extension from one version number
to another. The function is called if the current version of the load is greater than the last saved version.
The onshow element specifies the name of the IronPython function called when the load is selected
in the tree. This function is used to display customized graphical information associated with this load.
The onhide element specifies the name of the IronPython function called when the load switches
from a visible status to a hidden status. This event is called when the ACT object is unselected.
The oninit element specifies the name of the IronPython function called when the load is created.
The onadd element specifies the name of the IronPython function called when the load is added. This
event is called when the ACT object is added to the project.
The onremove element specifies the name of the IronPython function called when the load is deleted.
This event is called when the ACT object is deleted from the project.
The onsuppress element specifies the name of the IronPython function called when the load switches
from an active state to a suppressed state. This event is called when the ACT object is suppressed.
The onunsuppress element specifies the name of the IronPython function called when the load
switches from a suppressed state to an active state. This event is called when the ACT object is unsuppressed.
<getcommands location = [string] order = [integer]>
[function(load,solverdata,stream)]</getcommands>
The getcommands element specifies the name of the IronPython function called when Mechanical
writes the solver input file.
The callback named getcommands replaces the three callbacks getprecommands, getsolvecommands, and getpostcommands when the ANSYS solver is used.
When another solver other than the ANSYS solver is used, the getcommands callback is unavailable.
In such a case, the getprecommands, getsolvecommands, and getpostcommands callbacks
must be used.
The solverdata structure is associated to the getcommands callback. The solverdata structure
provides access to a set of data from the current model at the IronPython level. The solverdata
structure is useful when the solver commands to be generated by the extension need to add entities
in the model such as nodes or elements. Through the solverdata structure, ACT provides an efficient
method to manage the newly created IDs of these entities with the existing IDs previously generated
by the solver. Without the solverdata structure, the APDL command *GET must be used extensively
to determine the maximum ID before creating new entities.
164
<extension> Element
<getprecommands order = [integer]> [function(load,stream)]</getprecommands>
The getprecommands element specifies the name of the IronPython function called when Mechanical
writes the solver input file. This function allows you to add input solver commands in the stream. The
commands added to the stream are located just after the definition of the mesh. The order attribute
indicates the priority given to the generation of the solver commands in comparison to the other ACT
loads. Low order gives a high priority to the commands to be written. For command blocks with a same
order, the priority is given to the first object as defined in the tree of the application. By default, an
order equal to one is used.
The commands added to the stream are located at the location specified in the location attribute.
Possible values for the location attribute are:
pre
Commands are written at the end of the pre-treatment section (before entering into the /SOLU module).
preload
Commands are written before the first standard load definition.
solve
Commands are before the solve command and after all the standard loads have been defined.
post
Commands are written after the solve command.
The attribute order is used to define the priority of the command generation when the function is
called several times for one given location.
The second argument solverdata refers to the object that contains the model for the current analysis.
The solverdata type is ISolverData and contains the following fields:
MaxElementId
Current maximum element ID on the model.
MaxNodeId
Current maximum node ID on the model.
MaxElementType
Current maximum element type ID on the model.
CurrentStep
Current step number.
The methods available with the properties of solverdata are:
GetNewElementId
Generate a new element ID and increment the MaxElementId property by one.
GetNewNodeId
Generate a new node ID and increment the MaxNodeId property by one.
GetNewElementType
Generate a new element type ID and increment the MaxElementType property by one.
165

GetCoordinateSystemSolverId
Get the corresponding coordinate system solver ID for a given ID defining a coordinate system object in
the application.
GetMaterialSolverId
Get the corresponding material solver ID for a given body ID.
GetRemotePointNodeId
Get the corresponding node ID for a given remote point.
GetContactId
Get the solver contact ID.
GetContactTargetId
Get the target ID for a given contact.
GetSolveType
Get the type of solve in the case of multiple solves in one analysis.
To add elements to the solver input file, call the method GetNewElementId in order to get a new
value element ID and update the internal solver IDs. If the solver writes additional elements after the
ACT commands, these elements will have the expected IDs.
The third argument stream refers to the solver input file.
<getsolvecommands order = [integer] timedependent = true>[function(load,step,stream)] </getsolvecommands>
or
<getsolvecommands order = [integer] timedependent = false>[function(load,stream)] </getsolvecommands>
The getsolvecommands element specifies the name of the IronPython function called when Mechanical writes the solver input file. The commands added to the stream are located just after the definition
of the standard loads for the step number step if the attribute timedependent is set to True or just
after the first step if timedependent is set to False. Please refer to the getprecommands callback
for information on the order attribute.
Note
The argument step is expected only when the attribute timedependent is set to true.
<getpostcommands order = [integer]> [function(load,stream)]</getpostcommands>
The getpostcommands element specifies the name of the IronPython function called when Mechanical writes the solver input file. Commands added to the stream are located just after the solve command.
Please refer to the getprecommands callback for information on the order attribute.
<getnodalvaluesfordisplay> [values=function(load,nodeIds)] </getnodalvaluesfordisplay>
The getnodalvaluesfordisplay element specifies the name of the IronPython function called
prior to the display of the load. The user specifies the active load and an array of node ids. The function
must return an array containing one value per node. This output array needs to be consistent in terms
166
<extension> Element
of sequential storage with the input nodeIds. The ith value of the output will refer to the ith node
number from nodeIds. These values are displayed in Mechanical on the model (for example, a spatial
dependent thermal load).
The canadd element specifies the name of the IronPython function called when Mechanical checks
the availability of the load for the current analysis. The function takes two arguments: the current analysis and the name of the load to be checked. This function must return True or False.
<onduplicate>[function(load)]</onduplicate>
The onduplicate element specifies the name of the IronPython function called when Mechanical
duplicates the load object.
<canduplicate>[function(load,parent_object)]</canduplicate>
The canduplicate element specifies the name of the IronPython function called when Mechanical
checks if the load object can be duplicated depending on the current selected parent object in the
tree.
<canremove>[function(load)]</canremove>
The canremove element specifies the name of the IronPython function called when Mechanical checks
if the load object can be removed.
<action name="[(string)]" caption="[(string)]" icon="[(string)]"
function(load)
/action>
The action element specifies a new context menu option that will be available on the load object. The
name attribute defines the name of the action, the caption attribute defines the text displayed on the
context menu, and the icon attribute defines the name of the image to display on the context menu.
<ongenerate>state=[function(load,fct)]</ongenerate>
The ongenerate element specifies the name of the IronPython function called when the load must
be evaluated. The function takes two arguments: the load object and a function to manage the progress
bar. This function must return True or False: True if the evaluation ended correctly, False otherwise.
The onaftergenerate element specifies the name of the IronPython function called when the
generate callback is complete.
The oncleardata element specifies the name of the IronPython function called when the load need
to be cleared. The function takes one argument: the load object. This function is called each time the
mesh is cleaned and when the user clicks on the Clear Generated Data context menu option.
<isvalid>[function(load)]</isvalid>
The isvalid element specifies the name of the IronPython function called when Mechanical checks
the validity of the load object.
<property> Element
The property element and its children define the properties required for this load. Through this
definition, these properties appear in the details view of the application's Details pane.
167

color="[#xxxxxx]" >
unit="[string]"
control="[text(default) | select | float | integer | custom | applycancel |
[template name (string)]]"
visibleon="[values (separator '|')]"
needupdate="[true(default) | false]">
</property>
</load>
name
The value of the name attribute specifies the name used

by the context application to reference this property.
caption
The value of the caption attribute specifies the name

displayed in the GUI for this property.
Optional attributes
unit
The value of the unit attribute specifies the physical quantity to which
the result refers (for example, Length or Mass. See the ANSYS Workbench
User's Guide for details).
readonly
The value of the readonly attribute specifies that this property is

read-only. The supported values for this attribute are [true | false].
default
The value of the default attribute specifies the default value to use for
this property on initialization.
visible
This option indicates whether the property is visible in the detail view
window. The visible option can be used to show or hide a property
depending on another property value.
control
The value of the control attribute specifies the type of UI control to

use in the details view for this property.
168
<extension> Element
The text control activates a text area in which the user defines input data.
The select control activates a drop-down menu that contains a list of
available definitions.
The applycancelcontrol activates an Apply/Cancel button based on one
user-defined selection. This control is the most generic control type that can
be used with callbacks to integrate a variety of scenarios.
The template name: All pre-defined templates can be used as control type.
The following templates are available: scoping, component_selection,
geometry_selection, fileopen, entity_selection and
coordinatesystem_selection. Look at the file controltemplates.xml
in folder templates for more details on each template.
visibleon
The attribute is valid only if the property is a child of a propertygroup.

.
class
To define all the callbacks related to a property, you can create a class in
Python where each defined function matches the name of a callback. In
this case the class attribute must contain the name of this class.
needupdate
If this attribute is equal to true, each time the user change the value of
the property, solution will be invalidated. If this attribute is equal to false,
any change will not impact the status of the solution.
<callbacks> Element
datatype="[string | int | double | string[] | int[] | double[] | undef]"
unit="[string]"
control="[scoping | text(default) | select | tabular | custom |
applycancel | file]">
<callbacks class="[class name that implement a sub set of callbacks]">
<onmigrate>[function(new property,old property)]</onmigrate>
<onactivate>[function(load,property)]</onactivate>
<onvalidate>[function(load,property)]</onvalidate>
<isvalid>[isvalid=function(load,property)]</isvalid>
<isvisible>[isvalid=function(load,property)] </isvisible>
<onapply>[function(load,property)]</onapply>
<oncancel>[function(load,property)]</oncancel>
<string2value>[value=function(load,property,string)] </string2value>
<value2string>[string=function(load,property,value)] </value2string>
169

<getvalue>[value=function(load,property,value)]</getvalue>
<oninit>[function(load,property)]</oninit>
<onshow>[function(load,property)]</onshow>
<onhide>[function(load,property)]</onhide>
<onadd>[function(load,property)]</onadd>
<onduplicate>[function(load,property)]</onduplicate>
<onremove>[function(load,property)]</onremove>
<setvalue>[function(load,property)]<setvalue>
</callbacks>
</property>
The <callbacks> element and its children provide the means to specify the Python functions that
are invoked based on system and user-generated events related to load properties behavior. The callbacks
children are described below:
<onmigrate>[function(new_prop,old_prop)] </onactivate>
the ACT customized load. This function allows you to maintain the properties related to the load from
one version number to another one. The function is called if the current version of the load is greater
than the last saved version. The new_prop argument contains the definition of the property as defined
in the XML file and old_prop contains the definition of the load previously saved in the project. With
this function, you can convert legacy data read from the project file to the new property initialized by
the updated XML file.
The onactivate element specifies the name of the IronPython function called when the user selects
a load property in the details view. This callback is typically used to fill the options of a property when
the type select (ie. combo box) is used. The load and property are given as arguments.
The onvalidate element specifies the name of the IronPython function called when you change the
value of a load property in the Details view. This callback is typically used to validate the new value.
The load and property are given as arguments.
<isvalid>[isvalid=function(load,property)] </isvalid>
The isvalid element specifies the name of the IronPython function called when Mechanical queries
the validity of the property.
<isvisible>[isvisible=function(load,property)] </isvisible>
The isvisible element specifies the name of the IronPython function called when Mechanical checks
if the property is visible or not. This function must return True or False.
The onapply element specifies the name of the IronPython function called when the user selects the
Apply button in the load property control from the details view. The load and property are given
as arguments.
170
<extension> Element
The oncancel element specifies the name of the IronPython function called when the user selects
the Cancel button in the load property control from the Details view. The load and property are
given as arguments.
<string2value> [value=function(load,property,string)] </string2value>
The string2value element specifies the name of the IronPython function called when Mechanical
converts the string representation of a numeric value to a double. This function returns a double.
<value2string> [string=function(load,property,value)] </value2string>
The value2string element specifies the name of the IronPython function called when Mechanical
converts the numeric value to a string representation. This function returns a string.
<getvalue>[function(load,property,value)] </getvalue>
The getvalue element specifies the name of the IronPython function called each time the value of
the property is accessed. The load and property and the internal value of the property are given as
arguments.
The oninit element specifies the name of the IronPython function called when the property is initialized.
The onshow element specifies the name of the IronPython function called when the property is shown
in the targeted application.
The onhide element specifies the name of the IronPython function called when the property is hidden
<onadd>[function(load,property)]</onadd>
The onadd element specifies the name of the IronPython function called when the property is added
<onduplicate>[function(load,property)]</onduplicate>
The onduplicate element specifies the name of the IronPython function called when the property
is duplicated.
<onremove>[function(load,property)]</onremove>
The onremove element specifies the name of the IronPython function called when the property is removed.
<setvalue>[function(load,property,value)]</setvalue>
The setvalue element specifies the name of the IronPython function called when the property is set
to the given value defined by the value argument.
A propertygroup has one more attribute than a standard property. This optional attribute is described
below.
171
Optional attribute
display
This attribute defines how the propertygroup must be displayed:

none: the propertygroup itself is not displayed. Only its content (ie. the
child properties) is displayed. This option is used to better organize the XML
code.
caption: it's the default value. The propertygroup is displayed as a
caption and all its content is displayed under the caption.
property: the propertygroup is displayed as a standard property.
worksheet: the propertygroup is displayed as a standard property but
its content is displayed in a worksheet.
The callbacks associated to a propertygroup are the same as those associated to a standard property.
<propertytable> Element
A propertytable has one more attribute than a propertygroup. This optional attribute is described
below.
Optional attribute
allowempty
This attribute indicates if an empty table is valid.

The value must be true or false (default).
The callbacks associated to a propertytable are the same as those associated to a standard property.
<result Element>
The <result> element and its children allows the user to configure the properties of a custom result
and to specify the IronPython functions that are invoked based on system and user-generated events.
<simdata context="[Project | Mechanical | ASim]">
<result name="[result internal name (string)]"

version="[version identifier of the result (integer)]"
location="[node | elemnode | element]"
timehistory="[True | False]"
type="[scalar | vector]"
unit=""
contextual="[true(default) | false]"
172
<extension> Element
averaging="[Average | ElementalDifference | ElementalFraction |
ElementalMean | NodalDifference | NodalFraction |
Unaverage]"
class="[class_name]"
hasimaginary="[True | False]">
</result>
...
</simdata>
The <result> element supports a set of attributes, as described below, and two child elements: the
callbacks element and the property element. These two elements and their children are presented
in the next two sections.
name
The value of the name attribute specifies the name used

by the application to reference this result.
version
The value of the version attribute allows the result author

to affect a version number to this result.
caption
The value of the caption attribute specifies the name

displayed in the GUI for this result.
icon
The value of the icon attribute specifies the file name of

the icon displayed in the GUI for this toolbar button, without
the file extension. (An icon is a 16x16 pixel image in BMP,
JPG, or GIF format.) This file has to be stored in one of the
folders previously defined in the <images> elements.
In the case where the custom result is defined with a specific
icon, the file that describes this icon must be placed in the
following directory:
[ANSYS installation]\aisol\DesignSpace\DSPages\images
location
The value of the location attribute specifies if the result

has to be applied on nodes, on elements or on nodes of
elements.
type
The value of the type attribute specifies the type of the

result.
timehistory
The value of the timehistory attribute initializes the

CalculateTimeHistory property of the result. Defaults
to True when the attribute is omitted.
Optional attributes
unit
The value of the unit attribute specifies the physical quantity to which
the result refers (for example, Length or Mass. See the ANSYS Workbench
Documentation for details). If no unit is specified, then the result will be
considered as unitless.
173

contextual
If true, the result can be added directly from the Insert context menu
available on the load object.
averaging
Indicates the method used to display the original result.
class
Class name linked with the result.
hasimaginary
Indicates if the result has an imaginary part.
<callbacks> Element
type="[scalar | vector | tensor]"
timehistory="[True| False]"
unit="">
<callbacks>
<onmigrate>[function(newResult,oldResult)]</onmigrate>
<onshow>[function(result)]</onshow>
<onhide>[function(result)]</onhide>
<oninit>[function(result)]</oninit>
<onadd>[function(result)]</onadd>
<onsuppress>[function(result)]</onsuppress>
<onunsuppress>[function(result)]</onunsuppresss>
<oncleardata>[function(result)]</oncleardata>
<onstarteval>[function(result,step)]</onstarteval>
<onendeval>[function(result,step)]</onendeval>
<getvalue>[values=function(result,entityId)]</getvalue>
<onduplicate>[function(result)]</onduplicate>
<canduplicate>[function(result,parent_object)]</canduplicate>
<onremove>[function(result)]</onremove>
<canremove>[function(result)]</canremove>
<evaluate>[function(result,stepinfo,collector)]</evaluate>
<getfieldcount>[cuntion(result,entityId)]</getfieldcount>
<isvalid>[function(result)]</isvald>
</callbacks>
...
174
<extension> Element
</result>
The <callbacks> element and its children specify the Python functions that are invoked based on
system and user-generated events related to the result behavior. The children of the callbacks element
are described below:
<onmigrate> [function(new_result,old_result)] </onmigrate>
the ACT customized result. This function allows you to maintain the extension from one version number
to another. The function is called if the current version of the result is greater than the last saved version.
The onshow element specifies the name of the IronPython function called when the result is "visible"
(ie. the result in the tree is selected). This function is used to display customized graphical information
associated with this result.
The onhide element specifies the name of the IronPython function called when the result switches
from a visible status to a hidden status. This event is called when the ACT object is unselected.
The oninit element specifies the name of the IronPython function called when the result is created.
The onadd element specifies the name of the IronPython function called when the result is added. This
event is called when the ACT object is added to the project.
The onremove element specifies the name of the IronPython function called when the result is deleted.
This event is called when the ACT object is deleted from the project.
The onsuppress element specifies the name of the IronPython function called when the result switches
from an active state to a suppressed state. This event is called when the ACT object is suppressed.
<onunsuppress>[function(result)]</onunsuppress>
The onunsuppress element specifies the name of the IronPython function called when the result switches
from a suppressed state to an active state. This event is called when the ACT object is unsuppressed.
The oncleardata element specifies the name of the IronPython function called when the hosting
application requests that the data stored in relation to this result is cleared. This event may be fired by
direct user action or implicitly as the result of upstream data changes in the application which invalidate
the result.
The onstarteval element specifies the name of the IronPython function called when the evaluation
of the result is required. Operations such as memory allocations or file access can be done at this stage.
The argument step defines the step on which the evaluation has to be done.
175

The onendeval element specifies the name of the IronPython function called when the evaluation of
the result is completed. Operations related to clean-up, such as releasing memory allocations or closing
external files, should be done at this stage.
<getvalue>[values=function(result,entityId)] </getvalue>
The getvalue element specifies the name of the IronPython function called when Mechanical retrieves
the results values. EntityId refers to a node ID or an element ID, depending on the type of the result.
For scalar results on nodes, the size of values is 1
For vector results on nodes, the size of values is 3
For scalar results on elements, the size of values is 1
For vector results on elements, the size of values is 3
For scalar results on nodes of elements, the size of values is equal to the number of nodes related to the
element.
For vector results on nodes of elements, the size of values is equal to 3 multiplied by the number of nodes
related to the element.
<canadd>[function(analysis,resultName)]</canadd>
The canadd element specifies the name of the IronPython function called when Mechanical evaluates
if a result can be created for the current analysis. canadd takes two arguments: the current analysis
and the name of the result to be validated. This function must return True or False.
<onduplicate>[function(result)]</onduplicate>
The onduplicate element specifies the name of the IronPython function called when Mechanical
duplicates the result object.
<canduplicate>[function(result,loadName)]</canduplicate>
The canduplicate element specifies the name of the IronPython function called when Mechanical
checks if the result object can be duplicated, depending on the selected parent object in the tree.
The onremove element specifies the name of the IronPython function called when Mechanical removes
the result object.
<canremove>[function(result)]</canremove>
The canremove element specifies the name of the IronPython function called when Mechanical checks
if the result object can be removed.
<evaluate>[function(result,stepinfo,collector)]</evaluate>
The evaluate element specifies the name of the IronPython function called when Mechanical evaluates
the result.
The callback named evaluate replaces the two callbacks onstarteval and getvalue. This simplifies
the implementation of ACT results by combining the evaluation of the result with the passing of the
result to the application.
176
<extension> Element
The stepinfo argument is an object with properties that provides information on the current result
set number or the current time step.
The collector argument is used by the application for displaying the result. When the function is
called, collector is already initialized with expected information such as IDs of the FE entities on
which a result is expected.
For example, for a scalar result to be computed on nodes or elements, the following implementation
sends the constant value value to the set of appropriate FE entities:
def evaluate(result, stepinfo, collector):
value = 1
for Id in collector.Ids:
collector.SetValues(Id,value)
<getfieldcount>[function(result,entityId)]</getfieldcount>
The getfieldcount element specifies the name of the IronPython function called to get the number
of fields for the current result related to one given element or node ID.
<isvalid>[function(result)]</isvalid>
The isvalid element specifies the name of the IronPython function called when Mechanical evaluates
if the result is valid.
<property> Element
The description of the property element for a result is the same as that of the property element
for the load. Please refer to the section 8.1.3.1.2 for that purpose.
The description of the propertygroup element for a result is the same as that of the propertygroup
element for the load. Please refer to the section 8.1.3.1.3 for that purpose.
The description of the propertytable element for a result is the same as that of the propertytable
element for the load. Please refer to the section 8.1.3.1.4 for that purpose.
<solver> Element
The <solver> element and its children provide the means to configure a third party solver connection
and specify the IronPython functions that are invoked based on system and user-generated events.
...
<solver name="[solver internal name]"
version="[version identifier of the solver]"
caption="[solver display name]"
analysis="[string (analysis type (Static))]"
177
physics="[string (physics type (Structural))]"

contextual="[True (default) | False]"
toolbox="[toolbox name]">
</solver>
</simdata>
The <solver> element has two child elements. These are the callbacks element and the property
element. These two elements and their children are presented in the next two sections.
The <solver> element supports a set of attributes as described below:
name
to reference the solver.
version
The value of the version attribute allows to affect a version number to the
solver.
caption
The value of the caption attribute specifies the name displayed in the GUI
for the solver.
icon
The value of the icon attribute specifies the file name of the icon displayed
in the GUI for the solver. (An icon is a 16x16 pixel image in BMP, JPG, or GIF
format. Icon files are stored in the images sub-folder of the extension folder.)
analysis
The value of the analysis attribute specifies the analysis type that the
solver addresses. The current version of ACT only supports the Static analysis.
physics
The value of the type attribute specifies the physics to be used with the
solver. The current version of the ACT only supports the Structural physics.
Optional attributes
class
Class name of the controller of the object.
contextual
Indicates if the object has to be displayed in the current context.
toolbox
Name of the toolbox which defines the group in which the solve takes place.
<callbacks> Element
<solver name="[solver internal name (string)]"
version="[version identifier of the solver (integer)]"
physics="[string (physics type (Structural))]">
<callbacks>
178
<extension> Element
<onmigrate>[function(newSolver,oldSolver)]</onmigrate>
<oninit>[function(solver)]</oninit>
<onshow>[function(solver)]</onshow>
<onhide>[function(solver)]</onhide>
<onbeforesolve>[function(solver)]</onbeforesolve>
<onsolve>[function(solver)]</onsolve>
<oncleardata>[function(solver)]</ onwriteinputfile >
<onwriteinputfile>[function(solver)]</oncleardata>
<getsteps>[function(solver)]</getsteps>
<isanalysisvalid>[function(solver)]</isanalysisvalid>
<getreader>[function(solver)]</getreader>
<onadd>[function(parent object, object name)]</onadd>
<onremove>[function(solver)]</onremove>
<isvalid>[function(solver)]</isvalid>
<oncheckresults>[function(solver)]</oncheckresults>
</callbacks>
...
</solver>
The <callbacks> element and its children provide the means to specify the Python functions that
are invoked based on system and user-generated events related to the solver behavior. The callbacks
children are described below:
<onmigrate>[function(new_solver,old_solver)] </onmigrate>
The onmigrate element specifies the name of the IronPython function called when Mechanical is
launched. This function allows you to maintain the extension from one version to any other more recent
one to the next. The function is called if the current version of the solver is newer than the last saved
version.
The oninit element specifies the name of the IronPython function called when Mechanical is launched.
The onshow element specifies the name of the IronPython function called when the customized analysis settings object related to the solver is activated.
The onhide element specifies the name of the IronPython function called when the customized analysis settings object is deactivated.
179

The onbeforesolve element specifies the name of the IronPython function called just before the
solver is launched. The function is useful when an advanced customization is necessary before starting
the external solver.
The onsolve element specifies the name of the IronPython function called when the solver is launched.
<oncleardata>[function(solver)]</oncleardata>
The oncleardata element specifies the name of the IronPython function called when the hosting
application requests that the data stored in relation to this solver is cleared. This event may be fired by
direct user action or implicitly as the result of upstream data changes in the application which invalidate
the solution.
<onwriteinputfile>[function(solver)]</onwriteinputfile >
The onwriteinputfile element specifies the name of the IronPython function called when the
hosting application requests that the solver write the input stream. This event may be kicked off by
direct user action or implicitly as the result of upstream request in the application.
<getsteps>[function(solver)]</getsteps>
The getsteps element specifies the name of the IronPython function called to retrieve the list of the
step end time values. This function must return a list of double values.
<isanalysisvalid>[function name(solver,firstCheck)] </isanalysisvalid>
The isanalysisvalid element specifies the name of the IronPython function called when Mechanical retrieves the status of the analysis. The declaration of the called function must be:
def function_name(solver,firstCheck):
The input argument solver defines the current solver associated to the current analysis to be checked.
The input argument firstCheck indicates if Mechanical calls this function before or after the standard
validation. Mechanical will call this function with firstCheck set to True before the standard check
and will call a second time this function with firstCheck set to False after.
This function must return an integer value equal to -1, 0 or 1.
-1 means that the user doesn't want to check anything here, 0 means that the solver definition is not
yet valid, and 1 means that the solver is ready to be launched. If the returned value is not equal to -1
and firstCheck is equal to True, then the standard check performed by Mechanical is skipped.
<getreader>[function(solver)]</getreader>
The getreader element specifies the name of the IronPython function called to retrieve the name
and string arguments of the result reader associated with this solver. This function must return a list of
string values, where the first value is the name of the IronPython class.
<onadd>[function(solver)]</onadd>
The onadd element specifies the name of the IronPython function called when Mechanical is launched
for the first time with the solver connection.
The onremove element specifies the name of the IronPython function called when the system linked
with the solver is removed from the schematic.
180
<extension> Element
<isvalid>[function(solver)]</isvalid>
The isvalid element specifies the name of the IronPython function called when Mechanical checks
if the analysis settings object is valid. The function returns True or False.
<oncheckresults>[function(solver)]</oncheckresults>
The oncheckresults element specifies the name of the IronPython function called when Mechanical
starts a post-processing task. The function returns True or False.
<property> Element
The description of the property element on the solver is the same as the description for the
<property> element on the load. Please refer to the section 8.1.3.1.3 for more information.
Note
The applycancel and custom properties cannot be used in one customized analysis
settings object with the current version of ACT.
The description of the propertygroup element on the solver is the same as the description for the
<propertygroup> element on the load. Please refer to the section 8.1.3.1.3 for more information.
The description of the propertytable element on the solver is the same as the description for the
<propertytable> element on the load. So you can refer to the section 8.1.3.1.4 for more information.
<sampling> Element
This section applies to the ANSYS DesignXplorer application only.
The <sampling> element allows you to configure the properties of the sampling and specify the
functions that are invoked based on system and user-generated events.
<optimizer>
<callbacks> ... </callbacks>
<property>
<propertygroup>
<propertytable>
</optimizer>
Mandatory Attributes
name
The name of the object.
version
The version of the object.
Optional Attributes
Caption
The caption of the object.
Class

181

Provides messages to generate a log file.
LogFile
MaximumNumberOfDoubleListParameters Indicates the maximum number of double list

parameters supported.
Indicates the maximum number of double parameters

supported.
Indicates the maximum number of input parameters

supported.
Indicates the maximum number of integer list

parameters supported.
For more detailed information on attributes supported by the <sampling> element, see the "Sampling"
section in the ACT Reference Guide for DesignXplorer.
<callbacks> Element
The <callbacks> element lets you specify the Python functions that are invoked based on systemgenerated and user-generated events related to the optimizer behavior. Each child of the <callbacks>
element has a specific name and corresponds to a specific callback, as shown below.
<simdata context="DesignXplorer">
<sampling name="[sampling internal name]"
caption="[sampling display name]"
version="[version identifier of the sampling]">
<callbacks>
<OnCreate>[function(entity)]</OnCreate>
<CanRun>[function(entity)]</CanRun>
<Description>[function(entity)]</Description>
<Configuration>[function(entity)]</Configuration>
<Status>[function(entity)]</Status>
<QuickHelp>[function(entity)]</QuickHelp>
<InputParametersEdited>[function(entity)]</InputParametersEdited>
<MethodPropertiesEdited>[function(entity)]</MethodPropertiesEdited>
<OnMigrate>[function(newentity,oldentity)]</OnMigrate>
<OnRelease>[function(entity)]</OnRelease>
</callbacks>
</sampling>
</simdata>
When most callbacks are invoked, an entity object of the type DXUserSampling is passed to them,
allowing the function to easily access data and determine the context in which it has been invoked.
On the entity object,
Each attribute of the <sampling> element appears as a property. For example, the Python code entity.
LogFile allows you to access the value of the LogFile attribute.
Each <property> element appears in the Properties dictionary and is accessible by its name. For instance, if the <property> element MyProperty is defined, you can access its value in Python by writing
entity.Properties[MyProperty].Value.
Several additional properties associated with the sampling also appear as properties. For example, NumberOfInputParametersDefined is an additional property reflecting the current definition of the
samplingstudy. For a comprehensive list of properties, see the "IUserSampling" section in the ACT Reference Guide for DesignXplorer.
182
<extension> Element
The following table lists the callbacks available for the <sampling> element. Subsequent sections
provide information on using several of the most common callbacks. For more detailed information on
available callbacks, see the DOE section in the ACT Reference Guide for DesignXplorer.
CanAdd
Called to know if the object can be added. Indicates if the

sampling is able to process the design of experiments with
its current configuration.
CanRun
Indicates if the sampling is able to process the design of

experiments with its current configuration.
Configuration
Returns a user readable string summarizing the current

configuration of the sampling.
Description
Returns a user readable string describing the sampling and

its specific capabilities.
InputParametersEdited
Is invoked when the properties of input parameters have

changed.
MethodPropertiesEdited
Is invoked when the properties of the sampling have changed.
OnAdd
Called when the object is newly added. This callback is not

called when the project is reopened.
OnCreate
Is invoked to provide an instance of ISamplingMethod.
OnInit
Called when the object is initialized. This callback is called

after the OnAdd callback and when the project is reopened.
OnMigrate
Called when the object version has been changed. It allows

the migration of data from the old saved object to the new
one.
OnRelease
Is invoked to release the ISamplingMethod instance.
QuickHelp
Returns a user readable string helping to understand the

state of the sampling when CanRun is false.
Status
Returns a user readable string describing the status of the

sampling resolution.
<OnCreate> and <OnRelease> Callbacks

The OnCreate callback is mandatory for any sampling. It specifies the name of the function to call
when DX instantiates the external sampling class at the beginning of the sampling process (see The
Design Exploration Process (p. 72)). The function must return an object implementing the ISamplingMethod interface, which is assumed to be a new instance.
Here is an example of callback implementation. Given the partial sampling definition:
<sampling >
<callbacks>
<OnCreate>createRandomSampling</OnCreate>
</callbacks>
<property name="RandomSeed" caption="Random Seed" control="integer" default="0" />
</sampling>
The createRandomSampling function is defined by the following IronPython code:

def createRandomSampling(entity):
seed = entity.Properties["RandomSeed"].Value
instance = RandomSampling(seed)
return instance
183

The createRandomSampling function retrieves the value of the RandomSeed property and creates
a new instance of RandomSampling, passing the seed in an argument. The instance implements ISamplingMethod. It is returned to the caller.
The OnRelease callback specifies the function to allow DX to release the sampling instance at the
end of the sampling process. It is assumed that the callback will delete the instance initially created by
invoking OnCreate.
<canRun> and <QuickHelp> Callbacks

The declaration of the capabilities allows DX to determine if the sampling can run in many simple
contexts. For the custom and advanced situations, you can define the CanRun callback to apply your
own logic, based on the properties provided by the DXUserSampling object and with the internal
dependencies and conditions managed in your own code. For instance, this function could check with
your own mechanism whether the user has a valid license to use the sampling.. The function defined
for the CanRun callback must return a Boolean value: True if the optimizer can run, False otherwise.
If CanRun returns False, the sampling process is aborted.
def canRunSampling(entity):
numberOfSamples = entity.Properties["MyMaximumNumberOfSamples"].Value
if numberOfSamples <= 0 or numberOfSamples > 10000:
return False;
return True
This code checks:

MyNumberOfSamples property
In addition to the CanRun callback, the external sampling can provide a function for the QuickHelp
callback to generate a Quick Help message associated to the sampling context.
def getQuickHelp(entity):
numberOfSamples = entity.Properties["MyNumberOfSamples"].Value
return 'Number of Samples must be positive and lower than 10000'
return ''
This function returns a Quick Help message which can be displayed when the user clicks on the Quick
Help icon in the user interface, as shown in Figure 65: Quick Help in the Optimization Outline View (p. 190).
184
<extension> Element
Figure 64: Quick Help in the DOE Outline View
<optimizer> Element
This section applies to the ANSYS DesignXplorer application only.
The <optimizer> element allows you to configure the properties of the optimization and specify the
functions that are invoked based on system and user-generated events.
<optimizer>
<callbacks> ... </callbacks>
<property>
<propertygroup>
<propertytable>
</optimizer>
Mandatory Attributes
name
The name of the object.
version
The version of the object.
Optional Attributes
BasedOnDirectOptimizationOnly
True if the optimizer is only available in the context of

a Direct Optimization component; false otherwise.
BasedOnResponseSurfaceOnly
True if the optimizer is only available in the context of

a Response Surface component; false otherwise.
185

Caption
The caption of the object.
Class
ConstraintHandling
Supports constraint handling.
ConstraintImportance
Supports the Importance property of a constraint.
ConstraintOnInputParameter
Supports constraints defined on an input parameter.
ConvergenceData
Provides convergence data.
EqualToConstraint
Supports the Equal To constraint type.
GreaterThanConstraint
Supports the Greater Than constraint type.
HistoryChartXAxisType
Defines the X axis type for history charts.
Icon
The icon of the object.
InsideBoundsConstraint
Supports the Inside Bounds constraint type.
LessThanConstraint
Supports the Less Than constraint type.
LogFile
Provides messages to generate a log file.
MaximizeObjective
Supports the Maximize objective type.
MaximumNumberOfConstraints
Defines the maximum number of constraints supported

by the optimizer.
Indicates the maximum number of double list parameters

supported.
Indicates the maximum number of double parameters

supported.
Indicates the maximum number of input parameters

supported.
Indicates the maximum number of integer list parameters

supported.
MaximumNumberOfObjectives
Defines the maximum number of objectives supported

by the optimizer.
MinimizeObjective
Supports the Minimize objective type.
MinimumNumberOfConstraints
Defines the minimum number of constraints required.
MinimumNumberOfObjectives
Defines the minimum number of objectives required.
ObjectiveImportance
Supports the Importance property of an objective.
ObjectiveOnInputParameter
Supports objectives defined on an input parameter.
ParameterRelationship
Supports parameter relationships.
SeekObjective
Supports the Seek objective type.
StartingPointRequired
Requires a starting point.
For more detailed information on attributes supported by the <optimizer> element, see the "Optimizer" section in the ACT Reference Guide for DesignXplorer.
<callbacks> Element
The <callbacks> element lets you specify the Python functions that are invoked based on systemgenerated and user-generated events related to the optimizer behavior. Each child of the <callbacks>
element has a specific name and corresponds to a specific callback, as shown below.
186
<extension> Element
<simdata context="DesignXplorer">
<optimizer name="[optimizer internal name]"
caption="[optimizer display name]"
version="[version identifier of the optimizer]">
<callbacks>
<OnCreate>[function(entity)]</OnCreate>
<CanRun>[function(entity)]</CanRun>
<Description>[function(entity)]</Description>
<Configuration>[function(entity)]</Configuration>
<Status>[function(entity)]</Status>
<QuickHelp>[function(entity)]</QuickHelp>
<InputParametersEdited>[function(entity)]</InputParametersEdited>
<ObjectivesOrConstraintsEdited>[function(entity)]</ObjectivesOrConstraintsEdited>
<MethodPropertiesEdited>[function(entity)]</MethodPropertiesEdited>
<OnMigrate>[function(newentity,oldentity)]</OnMigrate>
<OnRelease>[function(entity)]</OnRelease>
</callbacks>
</optimizer>
</simdata>
When most callbacks are invoked, an entity object of the type DXUserOptimizer is passed to them,
allowing the function to easily access data and determine the context in which it has been invoked.
On the entity object,
Each attribute of the <optimizer> element appears as a property. For example, the Python code entity.SeekObjective allows you to access the value of the SeekObjective attribute.
Each <property> element appears in the Properties dictionary and is accessible by its name. For instance, if the <property> element MyProperty is defined, you can access its value in Python by
writing entity.Properties[MyProperty].Value.
Several additional properties associated with the optimization study also appear as properties. For example,
IsDirectOptimization and NumberOfInputParametersDefined are additional properties reflecting the current definition of the optimization study. For a comprehensive list of properties, see the
IUserOptimizer section in the ACT Reference Guide for DesignXplorer.
The following table lists the callbacks available for the <optimizer> element. Subsequent sections
provide information on using several of the most common callbacks. For more detailed information on
available callbacks, see the Optimizer section in the ACT Reference Guide for DesignXplorer.
CanAdd
Called to know if the object can be added.
CanRun
Indicates if the optimizer is able to process the optimization

study with its current configuration.
Configuration
Returns a user readable string summarizing the current

configuration of the optimizer.
ConvergenceDescription
Returns a DXConvergenceDescription object describing

the convergence data provided.
Description
Returns a user readable string describing the optimizer and

its specific capabilities.
InputParametersEdited
Is invoked when the properties of input parameters have

changed.
MethodPropertiesEdited
Is invoked when the properties of the optimization method

have changed.
187

ObjectivesOrConstraintsEdited
Invoked when the definition of objectives or constraints have

changed.
OnAdd
Called when the object is newly added. This callback is not

called when the project is reopened.
OnCreate
Is invoked to provide an instance of IOptimizationMethod.
OnInit
Called when the object is initialized. This callback is called

after the OnAdd callback and when the project is reopened.
OnMigrate
Called when the object version has been changed. It allows

the migration of data from the old saved object to the new
one.
OnRelease
Is invoked to release the IOptimizationMethod instance
ParameterRelationshipsEdited
Invoked when the definition of parameter relationships have

changed.
QuickHelp
Returns a user readable string helping to understand the

state of the optimizer when CanRun is false.
Status
Returns a user readable string describing the status of the

optimization resolution.
<OnCreate> and <OnRelease> Callbacks

The OnCreate callback is mandatory for any optimizer. It specifies the name of the function to call
when DX instantiates the external optimizer class at the beginning of the optimization process (see The
Optimization Process (p. 139)). The function must return an object implementing the IOptimizationMethod interface, which is assumed to be a new instance.
Here is an example of callback implementation. Given the partial optimizer definition:
<optimizer >
<callbacks>
<OnCreate>createRandomOptimizer</OnCreate>
</callbacks>
<property name="RandomSeed" caption="Random Seed" control="integer" default="0" />
</optimizer>
The createRandomOptimizer function is defined by the following IronPython code:

def createRandomOptimizer(entity):
seed = entity.Properties["RandomSeed"].Value
instance = RandomOptimizer(seed)
return instance
The createRandomOptimizer function retrieves the value of the RandomSeed property and creates
a new instance of RandomOptimizer, passing the seed in an argument. The instance implements
IOptimizationMethod. It is returned to the caller.
The OnRelease callback specifies the function to allow DX to release the optimizer instance at the
end of the optimization process. It is assumed that the callback will delete the instance initially created
by invoking OnCreate.
<canRun> and <QuickHelp> Callbacks

The declaration of the capabilities allows DX to determine if the optimizer can run in many simple
contexts. For the custom and advanced situations, you can define the CanRun callback to apply your
188
<extension> Element
own logic, based on the properties provided by the DXUserOptimizer object and with the internal
dependencies and conditions managed in your own code. For instance, this function could check with
your own mechanism whether the user has a valid license to use the optimizer. The function defined
for the CanRun callback must return a Boolean value: True if the optimizer can run, False otherwise.
If CanRun returns False, the optimization process is aborted.
def canRunOptimizer(entity):
maximumNumberOfCandidates = entity.Properties["MyMaximumNumberOfCandidates"].Value
if maximumNumberOfCandidates <= 0 or maximumNumberOfCandidates > numberOfSamples:
return False;
return False;
if entity.NumberOfObjectivesDefined == 0 and
entity.NumberOfConstraintsDefined == 0 and
entity.NumberOfObjectivesDefinedOnInputs == 0 and entity.NumberOfConstraintsDefinedOnInputs == 0:
return False
return True
This code checks:

The consistency between the MyMaximumNumberOfCandidates and MyNumberOfSamples properties.
That at least one objective or one constraint is defined.
In addition to the CanRun callback, the external optimizer can provide a function for the QuickHelp
callback to generate a Quick Help message associated to the optimization context.
def getQuickHelp(entity):
return 'Number of Samples must be positive and lower than 10000'
if maximumNumberOfCandidates <= 0 or maximumNumberOfCandidates > numberOfSamples:
return 'Maximum Number of Candidates must be positive and lower than
Number of Samples'
if entity.NumberOfObjectivesDefined == 0 and
entity.NumberOfConstraintsDefined == 0 and
entity.NumberOfObjectivesDefinedOnInputs == 0 and
entity.NumberOfConstraintsDefinedOnInputs == 0:
return 'At least one objective or constraint needs to be defined'
return ''
This function returns a Quick Help message which can be displayed when the user clicks on the Quick
Help icon in the user interface, as shown in Figure 65: Quick Help in the Optimization Outline View (p. 190).
189

Figure 65: Quick Help in the Optimization Outline View
<Description>, <Configuration>, and <Status> Callbacks

The Description, Configuration, and Status callbacks provide content to be directly exposed
in the user interface. When the Optimization node is selected in the Outline view, the Table view is
populated with a summary of the study, as shown in Figure 66: Information Exposed in the Optimization
Properties View (p. 190).
Figure 66: Information Exposed in the Optimization Properties View
In Figure 66: Information Exposed in the Optimization Properties View (p. 190), we can see that the Optimization Method group displays a summary of the information provided by the optimizer, as follows:
The first line contains a brief description of the optimization. The cell A4 contains the name of the optimizer
as defined in the XML file, and the cell B4 contains the string returned by the Description callback.
The second line contains the configuration of the current optimization. The cell B5 is contains the string
returned by the Configuration callback.
190
XML File Definition

The third line corresponds to the status of the optimization run. The cell B6 contains the string returned by
the Status callback.
Note
If the callbacks are not implemented, cells B4, B5, and B6 remain empty.
Here is an example of a callbacks implementation. Given the partial optimizer definition:
<optimizer >
<callbacks>
<Description>getDescription</Description>
<Configuration>getConfiguration</Configuration>
<Status>getStatus</Status>
</callbacks>
<property name="MyOptimizationStatus" caption="My Optimization Status" control="text"
readonly="true"></property>
<property name="MyNumberOfEvaluations" caption="My Number of Evaluations" control="integer"
readonly="true"></property>
</optimizer>
The following are the IronPython function implementations:

def getDescription(entity):
description = "Random screening - Python Example"
return description
def getConfiguration(entity):
configuration = 'Generates %d random points, and extracts %d candidates.'
%(numberOfSamples,maximumNumberOfCandidates)
return configuration
def getStatus(entity):
return entity.Properties["MyOptimizationStatus"].Value
XML File Definition

The section below describes in detail a generic XML file that includes all the available tags and attributes
that can be used by an extension. Your XML file does not have to integrate all of this data; select appropriate elements for the requirements that the extension is addressing.
<extension name="[extension name (string)]"
version="[version id (integer)]"
minorversion="[minor version id (integer)]">
<guid shortid="[extension name (string)]">GUID</guid>
<author>[Name of the author or organisation (string)]</author>
<description>[Description (string)]</description>
<assembly src="[file name]" namespace="[namespace]"/>
<script compiled="[false(default) | true]"
src="[python file name (string)]"></script>
<templates>
<controltemplate name="[template name (string)]"
version="[version id (integer)]">
191
<propertygroup>
<property> ... </property>
<propertygroup> ... </propertygroup>
</propertygroup>
</controltemplate>
</templates>
<images>[folder name that contains images]</images>
<callbacks>
<oninit>[function(context)]</oninit>
<onbeforesolve>[function(analysis)]</onbeforesolve>
<onaftersolve>[function(analysis)]</onaftersolve>
<isanalysisvalid>[function(analysis,firstCheck)]</isanalysisvalid>
<onload>[function(currentFolder)]</onload>
<onsave>[function(currentFolder)]</onsave>
<ondraw>[function()]</ondraw>
<ondraw2d>[function()]</ondraw2d>
<getprecommands>[function(analysis,stream)]</getprecommands>
<getsolvecommands timedependent="[true | false(default)]">
[function(analysis,stream)]</getsolvecommands>
<getpostcommands>[function(analysis,stream)]</getpostcommands>
<onpostfinished>[function(analysis)]</onpostfinished>
<onpoststarted>[function(analysis)]</onpoststarted>
<onterminate>[function(context)]</onterminate>
</callbacks>
caption="[toolbar button display name (string)]"
icon="[image located in images folders (string)]">
<callbacks>
192
XML File Definition
<onclick>[function(analysis)]</onclick>
</callbacks>
</entry>
<separator> ... </separator>
</entry>
<separator> ... </separator>
</toolbar>
</interface>
icon="[image name located in images folders (string)]"
color="[#xxxxxx]"
unit=""
contextual="[true | false]">
<attributes [attribute="" name=""]="[attribute value]" ...>
<[attribute_name (string)]>[attribute value (string)]
</[attribute_name (string)]>
</attributes>
<callbacks>
<action name="[name of the action (string)]"
icon="[image name located in images folders (string)]">
[function(load)]</action>
<onmigrate>[function(newLoad,oldLoad)]</onmigrate>
193
<ongenerate>[function(load)]</ongenerate>
<getprecommands order="[(integer)]">
[function(load,stream)]</getprecommands>
<getsolvecommands order="[(integer)]"
timedependent="[true | false(default)]">
[function(load,stream)]</getsolvecommands>
<getpostcommands order="[(integer)]">
[function(load,filename)]</getpostcommands>
<getnodalvaluesfordisplay>
[values=function(load,nodeIds)]
</getnodalvaluesfordisplay>
</callbacks>
caption="[property internal name (string)]"
unit="[string]"
control="[text(default) | select | float |
integer | custom | applycancel |
needupdate="[true(default) | false]"
class="[class name]">
<attributes> ... </attributes>
<callbacks>
<onmigrate>[function(new property,old property)]
</onmigrate>
<value2string>[string=function(load,property,value)]
</value2string>
194
XML File Definition
<string2value>[value=function(load,property,string)]
</string2value>
<isvalid>[isvalid=function(load,property)]</isvalid>
<isvisible>[isvalid=function(load,property)]
</isvisible>
<getvalue>[value=function(load,property,value)]
</getvalue>
</callbacks>
</property>
<propertygroup name="[property internal name (string)]"
unit="[string]"
display="[none | caption(default) |
property | worksheet]">
<callbacks>
...
</callbacks>
</propertygroup>
<propertytable name="[property internal name (string)]"
unit="[string]"
195

display="[none | caption(default) |
property | worksheet]"
allowempty="[true | false(default)]">
<callbacks>
...
</callbacks>
</propertytable>
</load>
<object> ... </object>
type="[scalar | vector | tensor]"
timehistory="[true | false]"
unit="[quantity nale (string)]" >
<callbacks>
<onmigrate>[function(newResult,oldResult)]</onmigrate>
<onunsuppress>[function(result)]</onunsuppress>
196
XML File Definition
<ongeneratedata>[function(result)]</ongeneratedata>
<getvalue>[values=function(result,entityId)]</getvalue>
</callbacks>
</result>
<solver name="[solver internal name (string)]"

caption="[solver display name (string)]"
version="[version identifier of the solver (integer)]"
class="[class name (string)]"
physics="[string (physics type (Structural))]"
toolbox="[name of the toolbox (string)]">
<callbacks>
<onmigrate>[function(newSolver,oldSolver)]</onmigrate>
<onsuppress>[function(solver)]</onsuppress>
<onunsuppress>[function(solver)]</onunsuppress>
<onadd>[function(solver)]</onadd>
<oncleardata>[function(solver)]</oncleardata>
<ongeneratedata>[function(solver)]</ongeneratedata>
<onwriteinputfile>[function(solver)]</onwriteinputfile>
<isanalysisvalid>[function(solver)]</isanalysisvalid>
<getsteps>[double[]=function(solver)]</getsteps>
<getreader>[string[]=function(solver)]</getreader>
</callbacks>
</solver>
</simdata>
197
</extension>
198
Development and Debugging Tips

Prerequisites
As described earlier, the functions used to run an extension are developed using the IronPython language.
The two following links provide documentation for this language.
IronPython documentation
Free python book
Debug Mode
When developing an extension, we recommend you activate the Debug mode option available in the
Extensions Options, accessed on the Tools>Options menu. The two figures below illustrate how to
access this mode.
199

Figure 67: Debug Options Menu
200
Debug Mode
Figure 68: Debug Mode for Extensions
The activation of the Debug mode option provides two additional buttons in the ACT toolbar of
Mechanical, as shown below.
Figure 69: ACT Debug Buttons
The Reload extensions button allows you to reload from Mechanical the extensions currently loaded.
This feature is of particular interest during the development of the extension, as it provides an efficient
method to interactively test the changes in an XML file or Python function. For major changes, ensure
the object acts as expected by deleting the ACT objects previously defined in Mechanical and recreating
them. When not in Debug mode, you can reload your extensions by quitting Workbench and restarting
your session.
The View log file button opens the log file. This file provides warning or error messages generated by
the extension. This feature is also very useful during the development of the extensions. Each time an
error occurs in an extension, the icon is shown in red. Note that you can also view the log file from the
main project page by selecting Extensions>View Log File.
201

Figure 70: View Log File Menu
The Debug mode is activated when the Mechanical application is next started. If Mechanical is already
open when the Debug mode is activated, close and restart Mechanical to use Debug mode.
If the Debug mode is not activated, and you have modified the extension XML file, you must close and
restart ANSYS Workbench to reload extensions. If you have made modifications to the Python functions,
you must close and restart only the Mechanical process.
ACT Console Extension

This extension is useful for interactively testing commands. The ActConsole extension adds a console
window to the application, in which the user can enter python commands and get the result. Information
on the available methods and prototypes are also provided on the top of the main window as described
below.
202
Debugging an Extension
Figure 71: Console Window for ACT Extension
When you enter a period . into the Command Line Editor, a list of available functions are displayed
into the Functions list box. This list is updated only when a period is entered.
When you click on an item in the Functions list box, the prototype of this function is displayed into
the Information pane. Please note that the self argument is an internal python argument, and this
argument does not have to be specified during the call of the function.
Each extension runs with a dedicated script engine. That means that to access to global variables or
functions associated to an extension the user needs first to select the appropriate extension by selecting
it using the extension selector.
Debug a running Python script using one of the following methods.
203

Debugging with Microsoft Visual Studio
Using Python Tools for Visual Studio
Debugging with Microsoft Visual Studio

If you have Microsoft Visual Studio, it is possible to use it to debug IronPython script.
Start Visual Studio, and attach it to the process AnsysWORKBENCHU.exe to debug an extension running
into Mechanical.
Before attaching the process to Visual Studio, make sure you are using the correct select code. The
Managed (v.4.0) option must be selected.
After attach, you can open your Python code and set some breakpoints into it.
Using Python Tools for Visual Studio

To ease the development of ACT extensions, we recommend you use the application Python Tools for
Visual Studio (PTVS).
204
Python Tools for Visual Studio (PTVS) is a free tool hosted by CodePlex.
Before installing PTVS, download and install Visual Studio 2010 Shell Isolated Mode Redistributable
package.
http://www.microsoft.com/downloads/en/details.aspx?familyid=8E5AA7B6-8436-43F0-B77800C3BCA733D3&displaylang=en
Then, download PTVS and install it.
http://pytools.codeplex.com/
You can use any version of Visual Studio from 2010 and above to develop and debug your ACT extensions.
205
206
Advanced Programming in C#
This section explains how to replace IronPython code with C# assemblies. C# is used in this document
but any language that creates .NET assemblies can also be used for that purpose. This section assumes
that you already know how to create an assembly in C#.
C# provides two major advantages over IronPython:
Better performance
Superior development environment which provides auto completion.
Initialize the C# Project

Once you have created a C# project and associated the type "Class Library" with this project, add a
reference to the Ansys.ACT.Interfaces assembly of ACT. This DLL is located at
<ANSYS_INSTALL_DIR>/Addins/AdvancedAddinPackage/bin/<Platform/Ansys.ACT.Interfaces.dll.
C# Implementation for a Load

The following XML file declares a load to be created in the ANSYS Mechanical application which requires
C# implementation:
<extension version="1" name="CSharp">
<author>ANSYS</author>
<description>This extension demonstrates how to use CSharp to write extension.</description>
<assembly src="CSharp.dll" namespace="CSharp" />
</interface>
<load name="CSharpLoad" caption="CSharp Load" version="1" icon="tload" unit="Temperature"
color="#0000FF" class="CSharp.Load">
<property name="Geometry" control="scoping">
<attributes>
<selection_filter>face</selection_filter>
</attributes>
</property>
</load>
<result name="CSharpResult" caption="CSharp Result" version="1" unit="Temperature" icon="tload"
location="node" type="scalar" class="CSharp.Result">
</result>
</simdata>
207
Advanced Programming in C#
</extension>
In the definition of the load object, the only change is the use of the attribute class. This attribute must
be set to the name of the class to be used for the integration of the load.
The CSharp.Load class is described below:
using
using
using
using
using
using
System;
System.Collections.Generic;
System.Linq;
System.Text;
Ansys.ACT.Interfaces.Mechanical;
Ansys.ACT.Interfaces.UserObject;
namespace CSharp
{
public class Load
{
IMechanicalExtAPI _ExtAPI = null;
public Load(IMechanicalExtAPI extApi,IUserLoad load)
{
_ExtAPI = extApi;
}
public IEnumerable<double> getnodalvaluesfordisplay(ISimLoad load, IEnumerable<int> nodeIds)
{
List<double> res = new List<double>();
var mesh = load.Analysis.MeshData;
foreach (int nodeId in nodeIds)
{
var node = mesh.NodeById(nodeId);
res.Add(Math.Sqrt(node.X * node.X + node.Y * node.Y + node.Z * node.Z));
}
return res;
}
}
}
To implement a callback in C#, create a new method in your class with the name of the callback in
lower case.
In the example, you implement the callback <getnodalvaluesfordisplay> by adding the method
getnodalvaluesfordisplay to the class.
C# Implementation for a Result

The following XML file declares a result to be created in the ANSYS Mechanical application which requires
C# implementation:
<extension version="1" name="CSharp">
<author>ANSYS</author>
<description>This extension demonstrates how to use CSharp to write extension.</description>
<assembly src="CSharp.dll" namespace="CSharp" />
</interface>
208
C# Implementation for a Result
<load name="CSharpLoad" caption="CSharp Load" version="1" icon="tload" unit="Temperature"

color="#0000FF" class="CSharp.Load">
<property name="Geometry" control="scoping">
<attributes>
<selection_filter>face</selection_filter>
</attributes>
</property>
</load>
<result name="CSharpResult" caption="CSharp Result" version="1" unit="Temperature" icon="tload"
location="node" type="scalar" class="CSharp.Result">
</result>
</simdata>
</extension>
For the load definition, the attribute class must be set to the name of the class to be used for the
integration of the result.
The CSharp.Result class is described below:
using
using
using
using
using
using
using
System;
System.Collections.Generic;
System.Linq;
System.Text;
Ansys.ACT.Interfaces.Mechanical;
Ansys.ACT.Interfaces.Post;
Ansys.ACT.Interfaces.UserObject;
namespace CSharp
{
public class Result
{
internal double[] res = new double[1];
public Result(IMechanicalExtAPI extApi, IUserResult result)
{
}
public void evaluate(IUserResult entity, IStepInfo stepInfo, IResultCollector collector)
{
foreach (var id in collector.Ids)
{
res[0] = id;
collector.SetValues(id, res);
}
}
}
}
As for the load definition, the implementation of a new callback simply requires you add a new method
with the name of the callback.
209
210
Limitations
You should be aware of the following limitations in the current version of ACT before developing your
extensions.
Localization of ACT is limited to the languages currently supported in ANSYS Workbench. This limitation
does not apply to the ability to manage various languages within the extension. For example, the property
names created by an extension do not have to be in the same language as the current activated language
in ANSYS Workbench. There is no mechanism to integrate localization for the property names defined by
an extension. You have to develop by yourself the localization if you want manage different languages for
your property names. Both regional settings based on the . or the , decimal symbol are available. However,
the implementation of the extension should use the . symbol for any value defined at the XML or Python
level.
You cannot specify a layer number for layered elements when using the reader to get access to ANSYS results.
Only the top of the top layer result and the bottom of the bottom layer results can be retrieved.
211
212
Examples
ACT supports application customization by exposing a set of interfaces for each supported application.
So far this discussion has focused on making simple additions to the ANSYS user interface and specifying
queries into the simulation project datum. This chapter focuses on more advanced usages of the API
for the data model of ANSYS Mechanical and ANSYs DesignXplorer. The examples in this section build
upon the methods and techniques discussed in the previous chapters.
ANSYS Mechanical Extension Examples

Von-Mises Stress as a Custom Result
The example provided in this section reproduces the result for the averaged Von Mises equivalent stress.
This result is already available in the standard results that can be selected in ANSYS Mechanical. This
example is given to demonstrate how you can define a custom result.
First, consider the support required in XML for the definition of the custom result. The interface XML
element contains information to add a toolbar and a toolbar button to the user interface. The callback
function <Create_Mises_Result> gets called when the toolbar button is clicked. Next the simdata
XML element is defined. The child XML element result encapsulates the information needed for the
custom result. One result level callback function is declared. The XML evaluate element provides the
name of the function that is called when the custom result (Von Mises Equivalent Stress) needs to be
computed and stored. This function is called when the custom result values are queried for graphical
display. The XML property element defines one property to be added in the Details pane of the custom
result. For this example, the property integrates a scoping method in the custom result.
<extension version="1" name="Mises">
<toolbar name="Von Mises Stress" caption="Von Mises Stress">
<entry name="Von Mises Stress" icon="result">
<callbacks>
<onclick>Create_Mises_Result</onclick>
</callbacks>
</entry>
</toolbar>
</interface>
<result name="Von Mises Stress" version="1" caption="Von Mises Stress" unit="Stress"
icon="result" location="node" type="scalar">
<callbacks>
<evaluate>Mises_At_Nodes_Eval</evaluate>
</callbacks>
<property name="Geometry" caption="Geometry" control="scoping"></property>
</result>
</simdata>
213
Examples
</extension>
Figure 72: Von-Mises Stress Details (p. 214) shows how the toolbar and result are added to the ANSYS
Mechanical user interface.
Figure 72: Von-Mises Stress Details
The Python script for the Mises extension, shown below, defines a callback function named <Create_Mises_Result>. When activated by the Von Mises Stress toolbar button, this callback creates
the result "Von Mises Stress." The callback invokes the Create_Mises_Result method on the
simDataMgr interface. The Mises.xml file provides the details needed to create the Von Mises
Stress toolbar/button and result.
In addition, the main.py file contains all the Python functions useful for this extension.
At the top of the script is the list definition for the node adjacency tables. The list, named "link," is a
list of hash maps. Each hash map uses as its hash key the numeral corresponding to the type returned
by the IElement Type property. The value for hash map is a list of arrays. The names of the arrays
match the local node numbers for a typical element of the key (element-type). Finally, the content of
each array provides the adjacent local node numbers for the corresponding elements node. This list of
arrays makes this extension compatible with all the different element topologies that Mechanical will
potentially create during the mesh generation.
The XML definition for "Von Mises Stress" specifies one other callback that we see in the Python script.
This callback is:
<evaluate>Mises_At_Nodes_Eval<evaluate>
214

The <evaluate> callback associated with the Mises_At_Nodes_Eval function is invoked as the
result of an event thrown by the ANSYS Mechanical application. The Mises_At_Nodes_Evalunction
computes the appropriate stress results and stores them. (The comments in the script below describe
the algorithm used.) It returns the nodal results set stored for the specified node ID. This callback is
used by the graphics system to display the results.
The Python script example also demonstrates the use of utility sub-functions. Using sub-functions to
perform common repetitive task helps to make the script modular and more understandable. The utility
sub-functions used in here are Mises and EigenValues. Mises is called by
Mises_At_Nodes_Eval and returns the computed equivalent stress for a given stress tensor
(SX,SY,SZ,SXY,SXZ,SYZ). The function EigenValues is used by the Mises function to compute the
Eigen vectors for a given stress tensor.
import units
import math
if ExtAPI.Context == 'Mechanical':
link = {}
#kHex20
link.Add(ElementTypeEnum.kHex20,{ 0:[3,1,4], 1:[0,2,5], 2:[1,3,6], 3:[2,0,7], 4:[5,0,7], 5:[1,4,6],
6:[5,7,2], 7:[6,3,4], 8:[0,1], 9:[1,2], 10:[2,3], 11:[3,0], 12:[4,5], 13:[5,6], 14:[6,7],
15:[7,4], 16:[0,4], 17:[1,5], 18:[2,6], 19:[3,7]})
#kHex8
link.Add(ElementTypeEnum.kHex8,{ 0:[3,1,4], 1:[0,2,5], 2:[1,3,6], 3:[2,0,7], 4:[5,0,7], 5:[1,4,6],
6:[5,7,2], 7:[6,3,4]})
#kPyramid13
link.Add(ElementTypeEnum.kPyramid13,{ 0:[3,1,4], 1:[0,2,4], 2:[1,3,4], 3:[2,0,4], 4:[0,1,2,3],
5:[0,1], 6:[1,2], 7:[2,3], 8:[3,0], 9:[0,4], 10:[1,4], 11:[2,4], 12:[3,4]})
#kPyramid5
link.Add(ElementTypeEnum.kPyramid5,{ 0:[3,1,4], 1:[0,2,4], 2:[1,3,4], 3:[2,0,4], 4:[0,1,2,3]})
#kQuad4
link.Add(ElementTypeEnum.kQuad4, { 0:[3,1], 1:[0,2], 2:[1,3], 3:[2,0]})
#kQuad8
link.Add(ElementTypeEnum.kQuad8, { 0:[3,1], 1:[0,2], 2:[1,3], 3:[2,0], 4:[0,1], 5:[1,2], 6:[2,3],
7:[3,0]})
#kTet10
link.Add(ElementTypeEnum.kTet10,{ 0:[2,1,3], 1:[0,2,3], 2:[1,0,3], 3:[0,1,2], 4:[0,1], 5:[1,2],
6:[2,0], 7:[0,3], 8:[1,3], 9:[2,3]})
#kTet4
link.Add(ElementTypeEnum.kTet4, { 0:[2,1,3], 1:[0,2,3], 2:[1,0,3], 3:[0,1,2]})
#kTri3
link.Add(ElementTypeEnum.kTri3, { 0:[2,1], 1:[0,2], 2:[1,0]})
#kTri6
link.Add(ElementTypeEnum.kTri6, { 0:[2,1], 1:[0,2], 2:[1,0], 3:[0,1], 4:[1,2], 5:[2,3]})
#kWedge15
link.Add(ElementTypeEnum.kWedge15,{ 0:[2,1,3], 1:[0,2,4], 2:[1,0,5], 3:[5,4,0], 4:[3,5,1],
5:[4,3,2], 6:[0,1], 7:[1,2], 8:[2,0], 9:[3,4], 10:[4,5], 11:[5,3], 12:[0,3], 13:[1,4],
14:[2,5]})
#kWedge6
link.Add(ElementTypeEnum.kWedge6,{ 0:[2,1,3], 1:[0,2,4], 2:[1,0,5], 3:[5,4,0], 4:[3,5,1],
5:[4,3,2]})
def Create_Mises_Result(analysis):
analysis.CreateResultObject("Von Mises Stress")
# This function evaluates the specific result (i.e. the Von-Mises stress) on each element
# required by the geometry selection
def Mises_At_Nodes_Eval(result, stepInfo, collector):
ExtAPI.Log.WriteMessage("Launch evaluation of the Mises result at nodes: ")
reader = result.Analysis.GetResultsData()
step = int(stepInfo.Set)
215
Examples
reader.CurrentResultSet = step
unit_stress = stress.GetComponentInfo("X").Unit
# Get the selected geometry
prop_geo = result.Properties["Geometry"]
ref_ids = prop_geo.Value.Ids
nodal_stress = [0.] * 6
# Get the mesh of the model
mesh = result.Analysis.MeshData
# Loop on the list of the selected geometrical entities
for ref_id in ref_ids:
# Get mesh information for each geometrical entity
mesh_region = mesh.MeshRegionById(ref_id)
node_ids = mesh_region.NodeIds
# Loop on the nodes related to the current geometrical refId
for node_id in node_ids:
for i in range(6):
nodal_stress[i] = 0.
element_ids = mesh.NodeById(node_id).ConnectedElementIds
num = 0
# Loop on the elements related to the current node
for element_id in element_ids:
tensor = stress.ElementValue(element_id,"X;Y;Z;XY;XZ;YZ")
element = mesh.ElementById(element_id)
# Look for the position of the node nodeId in the element element_id
# cpt contains this position
cpt = element.NodeIds.IndexOf(node_id)
# for corner nodes, cpt is useless.
# The n corner nodes of one element are always the first n nodes of the list
if cpt < element.CornerNodeIds.Count:
for i in range(6):
nodal_stress[i] = nodal_stress[i] + tensor[6*cpt+i]
else:
# For midside nodes, cpt is used and the link table provides the two neighbouring
# corner nodes for the midside node identified in the list by cpt
itoadd = link[element.Type][cpt]
for ii in itoadd:
for i in range(6):
nodal_stress[i] = nodal_stress[i] + tensor[6*ii+i] / 2.
num += 1
# The average stress tensor is computed before to compute the Von-Mises stress
# num is the number of elements connected with the current node node_id
for i in range(6):
nodal_stress[i] *= conv_stress / num
# Von-Mises stress computation
vm_stress = Mises(nodal_stress)
# Result storage
if node_id in collector.Ids:
collector.SetValues(node_id, [vm_stress])
# This function computes the Von-Mises stress from the stress tensor
def Mises(tensor):
216

(S1, S2, S3) = Eigen_Values(tensor)
return sqrt( ( (S1-S2)*(S1-S2) + (S2-S3)*(S2-S3) + (S1-S3)*(S1-S3) ) / 2. )
EPSILON = 1e-4
def Eigen_Values(tensor):
a
b
c
d
e
f
=
=
=
=
=
=
tensor[0]
tensor[1]
tensor[2]
tensor[3]
tensor[4]
tensor[5]

A = -(a+b+c)
p = B-A*A/3
q = C-A*B/3+2*A*A*A/27
R = sqrt(fabs(p)/3)
if q < 0: R = -R
z = q/(2*R*R*R)
if z < -1. : z = -1.
elif z > 1.: z = 1.
phi = acos(z)
S1
S2
S3
else:
S1
S2
S3
= -2*R*cos(phi/3)-A/3
= -2*R*cos(phi/3+2*math.pi/3)-A/3
= -2*R*cos(phi/3+4*math.pi/3)-A/3
= a
= b
= c
return (S1, S2, S3)
An Edge-Node Coupling Tool

The example provided in this section creates a tool that can be used to couple two set of nodes related
to two edges. This example is given to demonstrate how you can develop your own pre-processing
feature (such as a custom load) to address one specific need.
The name chosen for this extension is "Coupling." Shown below is an XML file that defines the custom
load. Just as we have seen in previous examples, interface XML element contains information to add a
toolbar and a toolbar button to the user interface. The callback function named <CreateCoupling>
gets called when the toolbar button is clicked. Next the simdata XML element is defined. The child XML
element load encapsulates the information that defines the support. Of particular importance is that
the issupport attribute value is set to "true." The issupport attribute tells ANSYS Mechanical which
type of boundary condition to apply. Three result level callback functions are declared. The function
SolveCmd is registered and called for an event that gets fired when the solver input is being written.
The ShowCoupling and HideCoupling functions are registered and called for events used to synchronize tree view selections with the content of the graphics pane. The details needed to define the
inputs and behavior of this special load consists of the three properties, "Source", "Target" and "Reverse,"
along with their behavioral callbacks.
<extension version="1" name="Coupling">
<guid shortid="Coupling">e0d5c579d-0263-472a-ae0e-b3cbb9b74b6c</guid>
217
Examples
<toolbar name="Coupling" caption="Coupling">
<entry name="Coupling" icon="support">
<callbacks>
<onclick>CreateCoupling</onclick>
</callbacks>
</entry>
</toolbar>
</interface>
<load name="Coupling" version="1" caption="Coupling" icon="support" issupport="true"
color="#FF0000">
<callbacks>
<getsolvecommands>SolveCmd</getsolvecommands>
<onshow>ShowCoupling</onshow>
<onhide>HideCoupling</onhide>
</callbacks>
<property name="Source" caption="Source" control="scoping">
<callbacks>
<isvalid>IsValidCoupledScoping</isvalid>
<onvalidate>OnValidateScoping</onvalidate>
</callbacks>
</property>
<property name="Target" caption="Target" control="scoping">
<callbacks>
<isvalid>IsValidCoupledScoping</isvalid>
<onvalidate>OnValidateScoping</onvalidate>
</callbacks>
</property>
<property name="Reverse" caption="Reverse" control="select" default="No">
<attributes options="No,Yes" />
<callbacks>
<onvalidate>OnValidateReverse</onvalidate>
</callbacks>
</property>
</load>
</simdata>
</extension>
Figure 73: Fully-defined Coupling in Mechanical (p. 219) shows how a fully defined coupling appears in
ANSYS Mechanical.
218

Figure 73: Fully-defined Coupling in Mechanical
The Python script for the Coupling extension, shown below, defines a callback function named <CreateCoupling>. When activated by the Coupling toolbar button, this callback creates the load "Coupling."
The callback invokes the CreateLoadObject method for the current analysis. The function SolveCmd
is called when the solver input is being generated. SolveCmd invokes GetListNodes to obtain two
lists of nodeids corresponding to the Target and Source edges. These nodeids are then used to write
APDL CP commands to the solver input. GetListNodes is also invoked by the <ShowCoupling> callback
function. In <ShowCoupling>, the IGraphics interface is used to create a graphics context. Using the
object returned, the inter-nodal lines are drawn to provide a visual representation of the coupling.
The graphics context associated with this custom load and the validation of the user inputs impose to
manage more various situations than for the first example described in the previous section. This explains
why more functions and sub-functions are required for this example.
import graphics
def CreateCoupling(analysis):
analysis.CreateLoadObject("Coupling")
#------------------------------#
Callbacks
#------------------------------def OnValidateReverse(load, prop):
ShowCoupling(load)
def OnValidateScoping(load, prop):
ShowCoupling(load)
def IsValidScoping(load, prop):
if not prop.Controller.isvalid(load, prop):
return False
selection = prop.Value
if selection == None: return False
if selection.Ids.Count != 1: return False
return True
219
Examples
def IsValidCoupledScoping(load, prop):
sProp = load.Properties["Source"]
tProp = load.Properties["Target"]
if not IsValidScoping(load, sProp):
return False
if not IsValidScoping(load, tProp):
return False
sIds = sProp.Value.Ids
tIds = tProp.Value.Ids
try:
sNum = mesh.MeshRegionById(sIds[0]).NodeCount
tNum = mesh.MeshRegionById(tIds[0]).NodeCount
if sNum == 0 or tNum == 0: return False
except:
return False
return sNum == tNum

#------------------------------#
Show / Hide
#------------------------------graphicsContext = {}
def getContext(entity):
global graphicsContext
if entity.Id in graphicsContext : return graphicsContext[entity.Id]
else : return None
def setContext(entity, context):
global graphicsContext
graphicsContext[entity.Id] = context
def delContext(entity):
context = getContext(entity)
if context != None : context.Visible = False
context = None
setContext(entity, None)
def ShowCoupling(load):
delContext(load)
ctxCoupling = ExtAPI.Graphics.CreateAndOpenDraw3DContext()
sourceColor = load.Color
targetColor = 0x00FF00
lineColor
= 0x0000FF
sProp = load.Properties["Source"] ; sSel = sProp.Value
tProp = load.Properties["Target"] ; tSel = tProp.Value
ctxCoupling.LineWeight = 1.5
if sSel != None:
ctxCoupling.Color = sourceColor
for id in sSel.Ids:
graphics.DrawGeoEntity(ExtAPI, load.Analysis.GeoData, id, ctxCoupling)
if tSel != None:
ctxCoupling.Color = targetColor
for id in tSel.Ids:
graphics.DrawGeoEntity(ExtAPI, load.Analysis.GeoData, id, ctxCoupling)
if IsValidSelections(load):
ctxCoupling.Color = lineColor
ctxCoupling.LineWeight = 1.5
220
sList, tList = GetListNodes(load)
for sId, tId in zip(sList, tList):
sNode = mesh.NodeById(sId)
tNode = mesh.NodeById(tId)
ctxCoupling.DrawPolyline([sNode.X,sNode.Y,sNode.Z,tNode.X,tNode.Y,tNode.Z])
ctxCoupling.Close()
ctxCoupling.Visible = True
setContext(load, ctxCoupling)
def HideCoupling(load):
delContext(load)
#------------------------------#
Commands
#------------------------------def SolveCmd(load, s):
s.WriteLine("! Coupling - CP")
sList, tList = GetListNodes(load)
for sId, tId in zip(sList, tList):
s.WriteLine("CP,NEXT,ALL,{0},{1}", sId, tId)
#------------------------------#
Utils
#------------------------------def IsValidSelections(load):
return load.Properties["Source"].IsValid and load.Properties["Target"].IsValid
def GetListNodes(load):
if IsValidSelections(load):
sProp = load.Properties["Source"] ; sIds = sProp.Value.Ids
tProp = load.Properties["Target"] ; tIds = tProp.Value.Ids
geometry = ExtAPI.DataModel.GeoData
sList = GetSubListNodes(geometry, mesh, sIds[0])
tList = GetSubListNodes(geometry, mesh, tIds[0])
rev = False
r = load.Properties["Reverse"].Value
if r == "Yes": rev = True
sList = sorted(sList, key=sList.get)
tList = sorted(tList, key=tList.get, reverse=rev)
return (sList, tList)
def GetSubListNodes(geometry, mesh, refId):
entity = geometry.GeoEntityById(refId)
region = mesh.MeshRegionById(refId)
result = {}
pt = System.Array.CreateInstance(System.Double, 3)
for nodeId in region.NodeIds:
pt[0], pt[1], pt[2] = (node.X, node.Y, node.Z)
result[nodeId] = entity.ParamAtPoint(pt)
return result
221
Examples
DesignXplorer Extension Examples

DOE Extension Examples
The ACT Developers Guide is supplemented by a package of examples DOEExtensionExamples.zip)
that illustrate a few solutions to implement a sampling extension with different programming languages.
The package contains instructions to install and build each extension and can be found in the Extensions
Library of the ANSYS Customer Portal.
The following examples are included:
Example Name
Description
PythonSampling
Fully implemented in IronPython (no build required), this example

is your sandbox. It illustrates many sampling extension features
and is definitely the best example to start with.
PythonSampling is running a simple random exploration of
the parametric space, generating the number of points requested
by the user.
CSharpSampling
This example demonstrates how an extension can be completely

set up when the ISamplingMethod interface is implemented
in C#.
Note that the optimization algorithm is also implemented in C#,
but one could use only the ISamplingMethod implementation
as an adapter to an existing implementation in C# or other
languages.
The project is provided for Microsoft Visual Studio 2010.
Optimization Extension Examples

The ACT Developer's Guide is supplemented by a package of examples (OptimizationExtensionExamples.zip) that illustrate a few solutions to implement an optimization extension with
different programming languages. The package contains instructions to install and build each extension
and can be found in the Extensions Library of the ANSYS Customer Portal.
The following examples are included:
Example Name
Description
PythonOptimizer
Fully implemented in IronPython (no build required), this example

is your sandbox. It illustrates many optimization extension features
and is definitely the best example to start with.
PythonOptimizer is running a simple random exploration of
the parametric space, generating the number of points requested
by the user and returning the best candidates found.
CSharpOptimizer
222
This example demonstrates how an extension can be completely

set up when the IOptimizationMethod interface is
implemented in C#.
Custom ACT Workflows in Workbench Examples

Note that the optimization algorithm is also implemented in C#,
but one could use only the IOptimizationMethod
implementation as an adapter to an existing implementation in
C# or other languages.
The project is provided for Microsoft Visual Studio 2010.
CppOptimizer
This example demonstrates how an extension can be implemented

from existing C/C++. The IOptimizationMethod interface is
implemented in IronPython as a wrapper to the C++ symbols, using
the ctypes foreign function library for Python.

Custom User-Specified GUI Operation
This custom Workbench workflow example implements a custom GUI operation for a task (specifically,
the addition of a custom context menu). This functionality is valuable when you require menu entries
beyond the default Edit menu created by the definition of the <onedit> callback.
Figure 74: Custom GUI Operation Schematic View
XML Extension Defintion File

The XML extension definition file (EmptyGUI.xml) performs the following actions:
References the IronPython script empty_gui.py.
Defines a single task in the <tasks> block. Within this block, a single context menu is defined in the
<contextmenus> block. Note that it has the <onclick> callback defined, as required.
Defines the inputs and outputs in the <inputs> and <outputs> blocks. Note that an empty input and
an output are defined.
Defines a single taskgroup which contains a single task in the <taskgroups> block.
223
Examples
The file, EmptyGUI.xml, contains the following code:
<extension version="1" name="EmptyGUI">
<guid shortid="EmptyGUI">69d0095b-e138-4841-a13a-de12238c83f6</guid>
<script src="empty_gui.py" />
</interface>
<workflow name="wf3" context="Project" version="1">
<tasks>
<task name="Empty" caption="Empty" icon="Generic_cell" version="1">
<callbacks>
</callbacks>
<inputs>
<input/>
</inputs>
<outputs/>
<contextmenus>
<entry name="Empty Gui Op" type="ContextMenuEntry" priority="1.0" icon="default_op"
version="1">
<callbacks>
<onclick>click</onclick>
</callbacks>
</entry>
</contextmenus>
</task>
</tasks>
<taskgroups>
<taskgroup name="Empty" caption="Empty" icon="Generic" category="ACT Custom Workflows"
abbreviation="MT" version="1">
<includeTask name="Empty" caption="Empty"/>
</taskgroup>
</taskgroups>
</workflow>
</extension>
IronPython Script
The IronPython script (empty_gui.py) contains the Python code the task executes from the context
menu and update callbacks.
Since the XML extension definition file has both the <onupdate> and <onclick> callbacks, the update
and click methods are defined in the script.
The file, empty_gui.py, contains the following code:
import clr
import Ansys.UI.Toolkit
def click(container):
Ansys.UI.Toolkit.MessageBox.Show("Empty Test!")
def update(container, context):
print 'empty update'
Custom, Lightweight, External Application Integration with Parameter

Definition
The following custom Workbench workflow example illustrates the use of parameter definitions to integrate an external application.
Driven by parameters defined in the XML extension definition file, the external application squares the
value of an input number, which is displayed in the Parameter Set tab. The external application updates
224

the output parameter to the computed square value. The use of parameters in this example enables
you to leverage DesignXplorer functionality.
Figure 75: Squares Example Schematic View
Figure 76: Squares Example in Parameter Set Tab
XML Extension Definiton File

The extension definition XML file (Squares.xml) performs the following actions:
References the IronPython script Squares.py.
Defines a single task in the <tasks> block.
Defines the inputs and outputs in the <inputs> and <outputs> blocks. Note that an empty input
is defined.
225
Examples
Defines two parameters in the <parameters> block.
The file, Squares.xml, contains the following code:
<extension version="1" name="Squares">
<guid shortid="Squares">69d0095b-e138-4841-a13a-de12238c83f4</guid>
<script src="squares.py" />
</interface>
<tasks>
<task name="Squares" caption="Squares" icon="squares_component" version="1">
<callbacks>
</callbacks>
<inputs>
<input/>
</inputs>
<outputs/>
<parameters>
<parameter name="Input" caption="Input" usage="Input" control="Double" version="1"/>
<parameter name="Output" caption="Output" usage="Output" control="Double" version="1"/>
</parameters>
</task>
</tasks>
<taskgroups>
<taskgroup name="Squares" caption="Squares" icon="squares" category="ACT Custom Workflows"
abbreviation="SQRS" version="1">
<includeTask name="Squares" caption="Squares"/>
</taskgroup>
</taskgroups>
</workflow>
</extension>
IronPython Script
The IronPython script (Squares.py) performs the following actions:
Obtains the parameters.
Prepares the inputs.
Writes the input file.
Runs the external solver.
Reads the output file.
Sets the parameters to the calculated solver values.
Since the XML extension definition file has <onupdate> callback, the update method is defined in
the script. All ACT workflow callbacks get a container (for the task) and a context.
The file, Squares.py, contains the following code:
import clr
clr.AddReference("Ans.Utilities")
clr.AddReference("Ans.Core")
import Ansys.Utilities
import Ansys.Core
#convenience method to look up parameters based on a predetermined ID
226

def GetParameterByName(parameters, id):
match = None
for param in parameters:
if param.ParameterName == id:
match = param
break
return match
activeDir = container.GetActiveDirectory()
extensionDir = ExtAPI.ExtensionManager.CurrentExtension.InstallDir
exeName = "ExampleAddinExternalSolver.exe"
solverPath = System.IO.Path.Combine(extensionDir, exeName)
#get parameters owned by container
params = None
lock = context.ContainerReadLock(container)
params = context.Project.GetDataReferencesByType(container, "ParameterAdapter")
lock.Dispose()
#isolate specific parameters
inputParam = GetParameterByName(params, "Input")
outputParam = GetParameterByName(params, "Output")
#prep i/o file paths
inputFileName = "input.txt"
outputFileName = "output.txt"
dpInputFile = System.IO.Path.Combine(activeDir, inputFileName)
dpOutputFile = System.IO.Path.Combine(activeDir, outputFileName)
#write input file
if inputParam != None and outputParam != None:
val = inputParam.Value
#write input file
f = open(dpInputFile, "w")
f.write('input='+val.ToString(System.Globalization.NumberFormatInfo.InvariantInfo))
f.close()
#run exe
runInMono = Ansys.Utilities.ApplicationConfiguration.DefaultConfiguration.IsRuntimeMono
monoPath = "mono"
monoArgs = System.String.Format("{0} \"{1}\" \"{2}\"", solverPath, dpInputFile, dpOutputFile)
info = None
if runInMono:
info = System.Diagnostics.ProcessStartInfo(monoPath, monoArgs)
else:
info = System.Diagnostics.ProcessStartInfo(solverPath, System.String.Format("\"{0}\" \"{1}\"",
dpInputFile, dpOutputFile))
info.CreateNoWindow = True
info.WindowStyle = System.Diagnostics.ProcessWindowStyle.Minimized
p = System.Diagnostics.Process.Start(info)
p.WaitForExit()
#read output file
outValue = None
f = open(dpOutputFile, "r")
currLine = f.readline()
while currLine != "":
valuePair = currLine.split('=')
outValue = System.Int32.Parse(valuePair[1], System.Globalization.NumberFormatInfo.InvariantInfo)
f.close()
#set output value
if outValue == None:
227
Examples
raise Exception("Error in update - no output value detected!")
else:
outputParam.Value = outValue
Custom, Lightweight, External Application Integration with Custom Data

The following custom Workbench workflow example illustrates the use of custom task properties to
integrate an external application.
Driven by the custom task properties defined in the XML extension definition file, the external application
squares the value of an input number, which is displayed in the Parameter Set tab. The external application updates the custom property values to the computed square value. This example also illustrates
progress and project reporting functionality.
Figure 77: Data Squares Example Schematic View
Figure 78: Data Squares Example Properties
XML Extension Definiton File

The extension definition XML file (DataSquares.xml) performs the following actions:
References the IronPython script datasquares_complete.py.
228

Defines the <onreport> callback, which is called when the user generates a project report. This allows
the task to access the report object and add its own task-specific reporting content.
Defines the inputs and outputs in the <inputs> and <outputs> blocks. Note that an empty input
is defined.
Defines two properties in the <properties> block.
The file, DataSquares.xml, contains the following code:
<extension version="1" name="DataSquares">
<guid shortid="DataSquares">69d0095b-e138-4841-a13a-de12238c83f2</guid>
<script src="datasquares_complete.py" />
</interface>
<workflow name="MyWorkflow" context="Project" version="1">
<tasks>
<task name="DataSquares" caption="Data Squares" icon="dsquares_component" version="1">
<callbacks>
<onstatus>status</onstatus>
<onreport>report</onreport>
</callbacks>
<propertygroup name="Inputs">
<property name="Input" caption="Input" control="double" default="0.0" readonly="False"
needupdate="true" visible="True" persistent="True" parameterizable="True" />
</propertygroup>
<propertygroup name="Outputs">
<property name="Output" caption="Output" control="double" default="0.0" readonly="True"
visible="True" persistent="True" parameterizable="True" />
</propertygroup>
<inputs>
<input/>
</inputs>
<outputs/>
</task>
</tasks>
<taskgroups>
<taskgroup name="DataSquares" caption="Data Squares" icon="dsquares"
category="ACT Custom Workflows" abbreviation="DSQRS" version="1">
<includeTask name="DataSquares" caption="Data Squares"/>
</taskgroup>
</taskgroups>
</workflow>
</extension>
IronPython Script
The IronPython script (dataquares_complete.py) performs the following actions:
Calls GetActiveDirectory to obtain the task-specific project directory.
Calls GetCustomEntity to obtain the data entity.
Calls GetCustomEntityPropertyValue to obtain the input property value.
Executes external solver.
Sets outputVal based on the retrieved solver output file.
Calls SetCustomEntityPropertyValue to update the output property to the solved value.
229
Examples
Updates progress information throughout the update process.
The file, datasquares_complete.py, contains the following code:
activeDir = container.GetActiveDirectory()
exeName = "ExampleAddinExternalSolver.exe"
solverPath = System.IO.Path.Combine(extensionDir, exeName)
monitor = context.ProgressMonitor
monitor.BeginTask("Data Sqaures Solver", 3, None)
monitor.TaskDetails = "Preparing solver input..."
monitor.UpdateTask(1, None)
#get param values
entity = ACT.GetCustomEntity(container)
inputValue = ACT.GetCustomEntityPropertyValue(entity, "Input")
#prep i/o file paths
inputFileName = "input.txt"
outputFileName = "output.txt"
dpInputFile = System.IO.Path.Combine(activeDir, inputFileName)
dpOutputFile = System.IO.Path.Combine(activeDir, outputFileName)
#write input file
f = open(dpInputFile, "w")
f.write('input='+inputValue.ToString(System.Globalization.NumberFormatInfo.InvariantInfo))
f.close()
monitor.TaskDetails = "Executing Solver..."
#run exe
runInMono = Ansys.Utilities.ApplicationConfiguration.DefaultConfiguration.IsRuntimeMono
monoPath = "mono"
monoArgs = System.String.Format("{0} \"{1}\" \"{2}\"", solverPath, dpInputFile, dpOutputFile)
info = None
if runInMono:
info = System.Diagnostics.ProcessStartInfo(monoPath, monoArgs)
else:
info = System.Diagnostics.ProcessStartInfo(solverPath, System.String.Format("\"{0}\" \"{1}\"",
dpInputFile, dpOutputFile))
info.CreateNoWindow = True
info.WindowStyle = System.Diagnostics.ProcessWindowStyle.Minimized
p = System.Diagnostics.Process.Start(info)
p.WaitForExit()
monitor.TaskDetails = "Retrieving results from solver..."
#read output file
outputValue = None
f = open(dpOutputFile, "r")
while currLine != "":
valuePair = currLine.split('=')
outputValue = System.Int32.Parse(valuePair[1], System.Globalization.NumberFormatInfo.InvariantInfo)
f.close()
#set output value
230
if outputValue == None:
raise Exception("Error in update - no output value detected!")
else:
ACT.SetCustomEntityPropertyValue(entity, "Output", outputValue)
monitor.TaskDetails = "Solve completed..."
monitor.EndTask(None)
import clr
clr.AddReference("Ans.ProjectSchematic")
clr.AddReference("ReportUtility.Interop")
import Ansys.ReportUtility.Interop
import Ansys.ProjectSchematic
def status(container, context):
status = Ansys.ProjectSchematic.Queries.ComponentState(Ansys.ProjectSchematic.State.Unfulfilled,
"This is unfulfilled!")
return None
def report(container, context, report):
root = report.GetRootSection()
section = Ansys.ReportUtility.Interop.ReportSection("My Custom ACT Task Report Content")
text = Ansys.ReportUtility.Interop.ReportText("", "Sample text from the data squares component")
section.AddChild(text)
root.AddChild(section)
Material Transfer
This custom Workbench workflow example implements a material transfer taskgroup that passes MatMLformatted material data to a downstream Engineering Data taskgroup. This example also illustrates
input/output specification and file management capabilities.
Figure 79: Material Transfer Example Engineering Data View
231
Examples
Figure 80: Material Transfer Example Schematic View
XML Extension Definition File

The XML definition file (GenericMaterialTransferSystem.xml) defines a system named Generic
Material, which appears in your custom system group in the Workbench Toolbox.
The XML extension definition file (GenericMaterialTransferSystem.xml) performs the following
actions:
References the IronPython script generic_material_transfer.py.
Specifies that the <onupdate> callback calls the producer_update IronPython function, which accesses
a materials file.
Defines the inputs and outputs in the <inputs> and <outputs> blocks. Note that an empty input and
an output are defined. The output type attribute is set to MatML31, specifying the kind of data exposed
and generated by this task.
The file, GenericMaterialTransferSystem.xml, contains the following code:
<extension version="1" name="GenericMaterialTransfer">
<guid shortid="GenericMaterialTransfer">69d0095b-e138-4841-a13a-de12238c83f8</guid>
<script src="generic_material_transfer.py" />
</interface>
<tasks>
<task name="Material" caption="Material" icon="material_cell" version="1">
<callbacks>
</callbacks>
<inputs>
<input/>
</inputs>
<outputs>
<output format="" type="MatML31"/>
</outputs>
</task>
</tasks>
<taskgroups>
<taskgroup name="GenericMaterialTransfer" caption="Generic Material" icon="material_system"
category="ACT Custom Workflows" abbreviation="GenMatXfer" version="1">
<includeTask name="Material" caption="Material"/>
</taskgroup>
</taskgroups>
</workflow>
</extension>
232
IronPython Script
The IronPython script (generic_material_transfer.py ) contains the IronPython code that
provides instructions for passing the MatML-formatted material data to a downstream Engineering
Data taskgroup. This includes the update method (called by the <onupdate> callback in the XML
extension definition file), which accesses the SampleMaterials.xml file.
The file, generic_material_transfer.py, contains the following code:
matFilePath = System.IO.Path.Combine(extensionDir, "Sample_Materials.xml")
matFileRef = None
isRegistered = IsFileRegistered(FilePath=matFilePath)
if isRegistered == True:
matFileRef = GetRegisteredFile(matFilePath)
else:
matFileRef = RegisterFile(FilePath=matFilePath)
AssociateFileWithContainer(matFileRef, container)
matOutputSet = outputRefs["MatML31"]
matOutput = matOutputSet[0]
matOutput.TransferFile = matFileRef
Material File
This file (Sample_Materials.xml), accessed by the IronPython update method, contains the
MatML-formatted material data:
<?xml version="1.0" encoding="UTF-8"?>
<EngineeringData version="16.1">
<Notes />
<Materials>
<MatML_Doc>
<Material>
<BulkDetails>
<Name>Sample Material</Name>
<Description>Sample material from Driver</Description>
<PropertyData property="pr0">
<Data format="string">-</Data>
<ParameterValue parameter="pa0" format="float">
<Data>494.1474492,912.7972764,1172.453938,1941.495468,2803.754154,3869.063522,5245.395513,
10378.82012,18192.58268,28438.67868,57755.1982,94951.87682,135751.6191,178064.7612,216504.4272,261538.9311,
304701.5076,333300.2826,364061.2544,397079.5705,432533.1159,457543.8578,483751.5301</Data>
<Qualifier name="Variable Type">Dependent,Dependent,Dependent,Dependent,Dependent,
Dependent,Dependent,Dependent,Dependent,Dependent,Dependent,Dependent,Dependent,Dependent,Dependent,
Dependent,Dependent,Dependent,Dependent,Dependent,Dependent,Dependent,Dependent</Qualifier>
</ParameterValue>
<ParameterValue parameter="pa1" format="float">
<Data>0.1338,0.2675,0.3567,0.6242,0.8917,1.1592,1.4268,2.051,2.586,3.0318,3.7898,4.3694,4.8153,
5.172,5.4395,5.707,5.9299,6.0637,6.1975,6.3312,6.465,6.5541,6.6433</Data>
<Qualifier name="Variable Type">Independent,Independent,Independent,Independent,
Independent,Independent,Independent,Independent,Independent,Independent,Independent,Independent,
Independent,Independent,Independent,Independent,Independent,Independent,Independent,Independent,
Independent,Independent,Independent</Qualifier>
</ParameterValue>
</PropertyData>
<PropertyData property="prDriver">
<Data format="string">-</Data>
<Qualifier name="Data Link Version">1</Qualifier>
<Qualifier name="Model Type">Linear;Isotropic</Qualifier>
<Qualifier name="Sample Property">Value</Qualifier>
</PropertyData>
</BulkDetails>
</Material>
<Metadata>
<ParameterDetails id="pa0">
<Name>Stress</Name>
233
Examples
<Units>
<Unit>
<Name>Pa</Name>
</Unit>
</Units>
</ParameterDetails>
<ParameterDetails id="pa1">
<Name>Strain</Name>
<Units>
<Unit>
<Name>m</Name>
</Unit>
<Unit power="-1">
<Name>m</Name>
</Unit>
</Units>
</ParameterDetails>
<PropertyDetails id="pr0">
<Unitless />
<Name>Sample Property</Name>
</PropertyDetails>
<PropertyDetails id="prDriver">
<Unitless />
<Name>Driver Link Details</Name>
</PropertyDetails>
</Metadata>
</MatML_Doc>
</Materials>
<Loads />
<BeamSections />
</EngineeringData>
Mesh Transfer
This custom Workbench workflow example implements a mesh transfer taskgroup.
This taskgroup has both "consuming" and "providing" connections with existing ANSYS applications,
consuming a mesh from an upstream Mesh taskgroup and passing it to a downstream Fluent taskgroup.
It also illustrates input/output specification, file management capabilities, and the default Edit context
menu.
234

Figure 81: End-to-End Mesh Transfer Between Mesh, Mesher, and Fluent Setup

The XML extension definition file (GenericMeshTransfer.xml) defines a taskgroup named Generic
Mesh, which appears in your custom taskgroup in the Workbench Toolbox.
The XML extension definition file (GenericMeshTransfer.xml) performs the following actions:
References the IronPython script generic_mesh_transfer.py.
Defines the <onedit> callback in the task block, which automatically creates a default Edit context menu
for the task.
Defines the an input and an output in the <inputs> and <outputs> blocks.
The input has type set to MeshingMesh, indicating that the input data type will be a mesh.
Both the input and output have format set to FluentMesh, specifying that the input and output files
will have the same FluentMesh format.
Defines a single taskgroup which contains a single task in the <taskgroups>> block..
The file, GenericMeshTransfer.xml, contains the following code:
235
Examples
<extension version="1" name="GenericMeshTransfer">
<guid shortid="GenericMeshTransfer">69d0095b-e138-4841-a13a-de12238c83f7</guid>
<script src="generic_mesh_transfer.py" />
</interface>
<tasks>
<task name="Mesher" caption="Mesher" icon="GenericMesh_cell" version="1">
<callbacks>
<onedit>edit</onedit>
</callbacks>
<inputs>
<input format="FluentMesh" type="MeshingMesh" count="1"/>
<input/>
</inputs>
<outputs>
<output format="FluentMesh" type="SimulationGeneratedMesh"/>
</outputs>
</task>
</tasks>
<taskgroups>
<taskgroup name="GenericMeshTransfer" caption="Generic Mesh" icon="GenericMesh"
category="ACT Custom Workflows" abbreviation="GenMeshXfer" version="1">
<includeTask name="Mesher" caption="Mesher"/>
</taskgroup>
</taskgroups>
</workflow>
</extension>
IronPython Script
The IronPython script (generic_mesh_transfer.py ) contains the IronPython code that provides
instructions for passing the mesh data to the downstream Fluent taskgroup .
The file, generic_mesh_transfer.py, contains the following code:
import clr
import Ansys.UI.Toolkit
print 'in system.py update method'
#obtain input data
upstreamData = container.GetInputDataByType(InputType="MeshingMesh")
meshFileRef = None
meshFileRef = upstreamData[0]
#set our output so that we are just a pass through.
meshOutputSet = outputRefs["SimulationGeneratedMesh"]
meshOutput = meshOutputSet[0]
#meshOutput.MeshFile = meshFileRef
meshOutput.TransferFile = meshFileRef
#if no new data...nothing to process from upstream sources.
def edit(container, context):
Ansys.UI.Toolkit.MessageBox.Show("Test!")
Custom Transfer
This custom Workbench workflow example implements a custom transfer from a producing taskgroup
to a consuming taskgroup, creating connections between custom tasks (no ANSYS installed products).
It also illustrates the creation of single-task vs. multi-task task groups.
236

Figure 82: Custom Transfer Example Schematic View

The XML extension definition file (CustomTransfer.xml) defines taskgroups named Producer,
Consumer, and CompleteTransfer, all of which appear in the Workbench Toolbox.
Figure 83: Custom Transfer Example Toolbox Taskgroup Entry
The XML extension definition file (CustomTransfer.xml) performs the following actions:
References the IronPython script customtransfer.py.
Defines two tasks in the <tasks> block: Producer and Consumer.
Defines three taskgroups in the <taskgroups> block: Producer, Consumer, and CompleteTransfer.
The Producer and Consumer taskgroups each contain a single task. The CompleteTransfer taskgroup
contains two tasks.
The file, CustomTransfer.xml, contains the following code:
<extension version="1" name="CustomTransfer">
<guid shortid="CustomTransfer">69d0095b-e138-4841-a13a-de12238c83f3</guid>
<script src="customtransfer.py" />
</interface>
237
Examples
<tasks>
<task name="Producer" caption="Producer" icon="test_component" version="1">
<callbacks>
<onupdate>producer_update</onupdate>
</callbacks>
<inputs>
<input/>
</inputs>
<outputs>
<output format="" type="MyData"/>
</outputs>
</task>
<task name="Consumer" caption="consumer" icon="test_component" version="1">
<callbacks>
<onupdate>consumer_update</onupdate>
</callbacks>
<inputs>
<input/>
<input format="" type="MyData"/>
</inputs>
<outputs/>
</task>
</tasks>
<taskgroups>
<taskgroup name="Producer" caption="Producer" icon="producer_system"
category="ACT Custom Workflows" abbreviation="Producer" version="1">
<includeTask name="Producer" caption="Producer"/>
</taskgroup>
<taskgroup name="Consumer" caption="Consumer" icon="consumer_system"
category="ACT Custom Workflows" abbreviation="Consumer" version="1">
<includeTask name="Consumer" caption="Consumer"/>
</taskgroup>
<taskgroup name="CompleteTransfer" caption="CompleteTransfer" icon="consumer_system"
category="ACT Custom Workflows" abbreviation="CompleteTransfer" version="1">
<includeTask name="Producer" caption="Producer"/>
<includeTask name="Consumer" caption="Consumer"/>
</taskgroup>
</taskgroups>
</workflow>
</extension>
IronPython Script
The IronPython script (customtransfer.py) contains the Python code that provides update instructions for the producing taskgroup and for the consuming task to obtain the output data from the upstream producer.
The file, customtransfer.py, contains the following code:
def consumer_update(container, context):
#obtain input data
upstreamData = container.GetInputDataByType(InputType="MyData")
fileRef = None
fileRef = upstreamData[0]
AssociateFileWithContainer(fileRef, container)
#if no new data...nothing to process from upstream sources.
def producer_update(container, context):
filePath = r"C:\Program Files\ANSYS Inc\v162\Addins\AdvancedAddinPackage\extensions\
CustomTransfer\Sample_Materials.xml"
fileRef = None
isRegistered = IsFileRegistered(FilePath=filePath)
if isRegistered == True:
fileRef = GetRegisteredFile(filePath)
else:
fileRef = RegisterFile(FilePath=filePath)
AssociateFileWithContainer(fileRef, container)
238

outputSet = outputRefs["MyData"]
myData = outputSet[0]
myData.TransferFile = fileRef>
Parametric
The following custom Workbench workflow example illustrates the creation of a parametric taskgroup
using the isparametricgroup attribute. When this attribute is set to true , it indicates that that
the taskgroup operates only on design points. As such, the taskgroup is added below the Parameter
Set bar. The focus on parameters in this example enables you to incorporate DesignXplorer-like functionality.
Figure 84: Parametric Example Schematic View

The XML extension definition file (Parametric.xml) performs the following actions:
References the IronPython script parametric.py.
Defines the inputs and outputs in the <inputs> and <outputs> blocks. Note that an empty input is
defined.
Defines a single taskgroup which contains a single task in the <taskgroups> block. Note that the isparametricgroup attribute is set to true.
The file, Parametric.xml, contains the following code:
<extension version="1" name="Parametric">
<guid shortid="Parametric">69d0095b-e138-4841-a13a-de12238c83f5</guid>
<script src="parametric.py" />
</interface>
<tasks>
<task name="Parametric" caption="Parametric" icon="parametric_component" version="1">
<callbacks>
</callbacks>
<inputs>
<input/>
</inputs>
<outputs/>
</task>
239
Examples
</tasks>
<taskgroups>
<taskgroup name="Parametric" caption="Parametric" icon="parametric"
category="ACT Custom Workflows" abbreviation="PARAMS" isparametricgroup="True" version="1">
<includeTask name="Parametric" caption="Parametric"/>
</taskgroup>
</taskgroups>
</workflow>
IronPython Script
The IronPython script (parametric.py) performs an update on the parameters. Since the XML extension definition file has <onupdate> callback, the update method is defined in the script.
The file, parametric.py, contains the following code:
print 'test'
Custom Guided Process Examples

This section contains examples of wizards and a custom template.
Wizard Examples:
For our different wizard examples, we'll use the same extension, WizardDemos. The following four
wizards are defined in this extension:
ProjectWizard: Project wizard
CreateBridge: Target app wizard (DesignModeler)
SimpleAnalysis: Target app wizard (Mechanical)
BridgeSimulation: Mixed wizard
For the wizard examples, we'll review excerpts from the XML extension file and the IronPython scripts.
Custom Template Example:

For our custom template example, we'll use the extension StudyDemo. The custom template StudyDemo1 is defined in this extension.
For the custom template example, we'll review the XML extension file, the IronPython script, and the
organization of custom help files.
Workbench Project Wizard

Our Workbench Project wizard example is called ProjectWizard. It is defined in the extension WizardDemos.

Below is an excerpt of the XML extension file, WizardDemos.xml.
240

Extension Definition
The name and version attributes define the extension name and version. The guid attribute specifies
a unique identifier for the extension.
Script Reference
The <script> block specifies the IronPython script referenced by the extension. This wizard references
the script main.py.
Interface Definition
In the <interface> block:
The context attribute is set to Project because the extension is executed in the Project tab
The <images> tag refers to the extension images folder; the image contained in this folder is displayed
as the icon for the custom template.
Wizard Definition
The wizard and its steps are defined in the <wizard> block.
The required name and version attributes define the wizard name and version.
Because the wizard will be executed on the Project tab, the required context attribute is set to Project.
Step Definitions
The <step> tag is used to define the steps of the wizard. There are six steps: Geometry, Mechanical,
Fluent, ReportView, CustomStep, and Charts.
For each step:
The name, version, and caption attributes define the step name, version, and display text for the
step.
The context attribute is set to the context in which the specific step is executed (i.e. Project, DesignModeler, Mechanical).
The HelpFile attribute references the HTML help file to be displayed for the step.
The <callbacks> block defines the callbacks to the functions defined in the Python script.
For the Geometry step, the <onupdate> callback executes the CreateGeometry action, creating
the geometry upon update; the <onreset> callback executes the DeleteGeometry action, removing the geometry when the Back button is clicked.
For the Mechanical step, the <onupdate> callback executes the CreateMechanical action
and the <onreset> callback executes the DeleteMechanical action.
For the Fluent step, the <onupdate> callback executes the CreateFluent action.
For the ReportView step, the <onrefresh> and <onreset> callbacks execute the RefreshReport and EmptyReset actions.
For the CustomStep, the <onrefresh>, <onupdate>, and <onreset> callbacks execute the
RefreshMechanical, LogReport, and EmptyReset actions
241
Examples
For the Charts step, the <onrefresh> callback executes the RefreshCharts action.
The <propertygroup> blocks define properties and property attributes for the steps. For properties
requiring validation, the <onvalidate> callback executes an appropriate Python validation function.
<script src="ds.py" />
<script src="dm.py" />
<interface context="Project|Mechanical">
</interface>
...
<description>Simple wizard for demonstration in Project page.</description>
<step name="Geometry" caption="Geometry" version="1" HelpFile="help/geometry.html">
<callbacks>
<onupdate>CreateGeometry</onupdate>
<onreset>DeleteGeometry</onreset>
</callbacks>
default="Option1">
</propertygroup>
</propertygroup>
</step>
<step name="Mechanical" caption="Mechanical" enabled="true" version="1" HelpFile="help/mechanical.html">
<callbacks>
<onupdate>CreateMechanical</onupdate>
<onreset>DeleteMechanical</onreset>
</callbacks>
</propertytable>
</step>
<step name="Fluent" caption="Fluent" version="1" HelpFile="help/fluent.html">
242

<callbacks>
<onrefresh>CreateDialog</onrefresh>
<onupdate>CreateFluent</onupdate>
<onreset>EmptyReset</onreset>
</callbacks>

<callbacks>
</callbacks>
</property>
<callbacks>
</callbacks>
</property>
<property name="nextstep" caption="Next Step" control="select" >
<callbacks>
<onvalidate>ValidateNextStep</onvalidate>
</callbacks>
</property>
</step>
<step name="ReportView" caption="ReportView" version="1" layout="ReportView@WizardDemos">
<callbacks>
<onrefresh>RefreshReport</onrefresh>
</callbacks>
</step>
<step name="CustomStep" caption="CustomStep" enabled="true" version="1" layout="MyLayout@WizardDemos">
<callbacks>
<onrefresh>RefreshMechanical</onrefresh>
<onupdate>LogReport</onupdate>
</callbacks>
</step>
<step name="Charts" caption="Charts" enabled="true" version="1" layout="GraphLayout@WizardDemos">
<description>Demonstrate all chart capabilities.</description>
<callbacks>
<onrefresh>RefreshCharts</onrefresh>
</callbacks>
</step>
</wizard>
IronPython Script
Below is the IronPython script, main.py.
This script defines all the functions executed by the callbacks in our XML extension file. Each step defined
in the XML file may include multiple actions.
geoSystem = None
dsSystem = None
fluentSystem = None
243
Examples
def CreateGeometry(step):
global geoSystem
template1 = GetTemplate(TemplateName="Geometry")
geoSystem = template1.CreateSystem()
geometry1 = geoSystem.GetContainer(ComponentName="Geometry")
geometry1.SetFile(FilePath=step.Properties["definition/filename"].Value)
def DeleteGeometry(step):
global geoSystem
geoSystem.Delete()
def RefreshMechanical(step):
tree = step.UserInterface.GetPanel("Tree")
root = tree.CreateTreeNode("Root")
tree.SetTreeRoot(root)
chart = step.UserInterface.GetPanel("Chart")
chart.Plot([1,2,3,4,5],[10,4,12,13,8],"b","Line1")
chart.Plot([1,2,3,4,5],[5,12,7,8,11],"r","Line2")
def CreateMechanical(step):
global dsSystem, geoSystem
template2 = GetTemplate(
TemplateName="Static Structural",
Solver="ANSYS")
geometryComponent1 = geoSystem.GetComponent(Name="Geometry")
dsSystem = template2.CreateSystem(
Position="Right",
RelativeTo=geoSystem)
raise UserErrorMessageException("Invalid system name. Please try again.")
dsSystem.DisplayText = step.Properties["name"].Value
def DeleteMechanical(step):
global dsSystem
dsSystem.Delete()
def CreateFluent(step):
global dsSystem, fluentSystem
template3 = GetTemplate(TemplateName="Fluid Flow")
geometryComponent2 = dsSystem.GetComponent(Name="Geometry")
solutionComponent1 = dsSystem.GetComponent(Name="Solution")
componentTemplate1 = GetComponentTemplate(Name="CFDPostTemplate")
fluentSystem = template3.CreateSystem(
DataTransferFrom=[Set(FromComponent=solutionComponent1, TransferName=None,
ToComponentTemplate=componentTemplate1)],
Position="Right",
RelativeTo=dsSystem)
raise Exception("Invalid system name. Please try again.")
fluentSystem.DisplayText = step.Properties["name"].Value
def CreateDialog(step):
dlg = step.UserInterface.Container.CreateDialog("MyDialog", "okCancelDialog", "MyTitle", 400, 150)
dlg.SetOkButton("Ok")
prop = step.Properties["nextstep"]
prop.Options.Clear()
s = step.NextStep
val = s.Caption
while s!=None:
prop.Options.Add(s.Caption)
s = s.NextStep
244

prop.Value = val
def cbDialog(sender, args):
sender.Container.HideDialog(sender)
def ValidateDialog(step, prop):
dialog = step.UserInterface.GetPanel("MyDialog")
dialog.SetMessage("My own message")
dialog.SetCallback(cbDialog)
dialog.Refresh()
step.UserInterface.Container.ShowDialog(dialog)
def worker(step):
progress = step.UserInterface.GetPanel("Progress")
stopped = progress.UpdateProgress("Start progress...", 0, True)
step.UserInterface.Container.ShowDialog(progress)
for i in range(100):
stopped = progress.UpdateProgress("Start progress...", i+1, True)
if stopped:
break
step.UserInterface.Container.HideDialog(progress)
def ValidateDialogProgress(step, prop):
thread = System.Threading.Thread(System.Threading.ParameterizedThreadStart(worker))
thread.Start(step)
def ValidateNextStep(step, prop):
prop = step.Properties["nextstep"]
s = step.NextStep
v = False
while s!=None:
if prop.Value==s.Caption:
v = True
s.IsEnabled = v
s = s.NextStep
steps = step.UserInterface.GetPanel("Steps")
steps.UpdateData()
steps.Refresh()
def RefreshReport(step):
report = step.UserInterface.GetPanel("Report")
report.SetFilename(System.IO.Path.Combine(ExtAPI.Extension.InstallDir,"help","report.html"))
report.Refresh()
def EmptyReset(step):
pass
def LogReport(step):
ExtAPI.Log.WriteMessage("Report:")
for s in step.Wizard.Steps.Values:
ExtAPI.Log.WriteMessage("Step "+s.Caption)
for prop in s.AllProperties:
ExtAPI.Log.WriteMessage(prop.Caption+": "+prop.DisplayString)
import random
import math
def RefreshCharts(step):
graph = step.UserInterface.GetPanel("Graph")
graph.Title("Line Bar Graph")
graph.ShowLegend(False)
graph.Plot([-1, 0, 1, 2, 3, 4], [0.5, -0.5, 0.5, -0.5, 0.5, 0.5], key="Variable A", color='g')
graph.Bar([-1, 0, 1, 2, 3, 4], [10, 20, 30, 10, 5, 20], key="Variable B")
graphB = step.UserInterface.GetPanel("GraphB")
graphB.Title("Plot Graph")
graphB.YTickFormat("0.2f")
xValues = []
yValues = []
for i in range(0, 100):
245
Examples
xValues.append(i)
yValues.append(abs(math.sin(i*0.2))*i/100.0)
graphB.Plot(xValues, yValues, key="y = a*sin(bx)", color="c")
graphB.Plot(xValues, yValues, key="y = x", color="m")
xValues = []
yValues = []
for i in range(0, 100):
xValues.append(i)
yValues.append(i/100.0)
graphB.Plot(xValues, yValues, key="y = x", color="m")
graphB.Plot([0, 10, 20, 30, 100], [0.2, 0.2, 0.2, 0.3, 0.3], key="Smth", color="r")
graphB.Plot([0, 10, 20, 30, 100], [0.2, 0.1, 0.3, 0.5, 0.7], key="Smth", color="r")
graphB.Plot([0, 10, 20, 30, 100], [0.2, 0.2, 0.2, 0.3, 0.3])
graphC = step.UserInterface.GetPanel("GraphC")
graphC.Title("Pie Graph")
graphC.Pie([1, 2, 3])
graphC.Pie([20, 30, 5, 15, 12], [0, "Banana", 2, 3, "42"])
graphD = step.UserInterface.GetPanel("GraphD")
graphD.Title("Bar Graph")
graphD.Bar(["Banana"], [70], key="key")
graphD.Bar([0, "Banana", 2, 3, 4], [20, 30, 5, 15, 12], key="key")
graphE = step.UserInterface.GetPanel("GraphE")
graphE.Title("Bubble Graph")
graphE.XTickFormat("f")
graphE.YTickFormat("f")
keys = ["one", "two", "three", "four", "five"]
colors = ["#BB3333", "#33BB33", "#3333BB", "#BBBB33", "#BB33BB"]
for c in range(0, 5):
xValues = []
yValues = []
sizeValues = []
for i in range(0, (c+1)*20):
rad = random.randrange(c+1, c+2) + (random.random()*2-1)
angle = random.random() * 2 * math.pi
xValues.append(math.cos(angle) * rad)
yValues.append(math.sin(angle) * rad)
sizeValues.append(random.random() * 2.0 + 0.5)
graphE.Bubble(xValues, yValues, sizeValues, key=keys[c], color=colors[c])
Target Application Wizard (DesignModeler)

Our DesignModeler wizard example is called CreateBridge. It is defined in the extension WizardDemos.
This is a two-step wizard that builds a bridge.

Script Reference
the script dm.py.
The <interface> block defines details of the interface.
246

The context attribute is set to DesignModeler because the extension is executed in the DesignModeler application.
The <images> block refers to the extension images folder; the image contained in this folder is displayed
as the icon for the wizard.
The <toolbar> block is used to define two toolbar buttons for exposure in DesignModeler. When the
buttons are clicked, the <onclick> callbacks execute the CreateDeck and CreateSupport
functions and create a deck geometry with supports.
Simdata Definition
The two <simdata> blocks provide data for the creation of the Deck and Support geometries.
Wizard Definition
The context attribute is set to DesignModeler because the wizard will be executed in the DesignModeler application.
Step Definitions
The <step> tag is used to define the steps of the wizard. There are two steps: Deck and Supports.
For each step:
step.
For the Deck step, the <onupdate> callback executes the UpdateDeck function to create the deck
geometry using the Deck feature.
For the Supports step, the <onupdate> callback executes the UpdateSupports function to
create the bridge supports using the Support geometry.
The <propertygroup> block defines geometry properties and their attributes.
...
<toolbar name="Deck" caption="Deck">
<entry name="Deck" icon="deck">
<callbacks>
<onclick>CreateDeck</onclick>
</callbacks>
247
Examples
</entry>
<entry name="Support" icon="Support">
<callbacks>
<onclick>CreateSupport</onclick>
</callbacks>
</entry>
</toolbar>
</interface>
<geometry name="Deck" caption="Deck" icon="deck" version="1">
<callbacks>
<ongenerate>GenerateDeck</ongenerate>
</callbacks>
<property name="Length" caption="Length" control="float" unit="Length" default="300 [m]" />
<property name="Width" caption="Width" control="float" unit="Length" default="20 [m]" />
<property name="Beams" caption="Beams" control="integer" default="31" />
</geometry>
</simdata>
<geometry name="Support" caption="Support" icon="support" version="1">
<callbacks>
<ongenerate>GenerateSupport</ongenerate>
</callbacks>
<property name="Height" caption="Height" control="float" unit="Length" default="100 [m]" />
<property name="Number" caption="Number" control="integer" default="3" />
</geometry>
</simdata>
...
<wizard name="CreateBridge" version="1" context="DesignModeler" icon="wizard_icon">
<description>Simple wizard for demonstration in DesignModeler.</description>
<step name="Deck" caption="Deck" version="1" HelpFile="help/dm1.html">
<description>Create the deck.</description>
<callbacks>
<onupdate>UpdateDeck</onupdate>
</callbacks>
<propertygroup display="caption" name="Deck" caption="Deck Definition" >
</propertygroup>
</step>
<step name="Supports" caption="Supports" enabled="true" version="1" HelpFile="help/dm2.html">
<description>Create supports.</description>
<callbacks>
<onupdate>UpdateSupports</onupdate>
</callbacks>
<propertygroup display="caption" name="Supports" caption="Supports Definition" >
</propertygroup>
</step>
</wizard>
248
IronPython Script
Below is the IronPython script, dm.py.
import units
def CreateDeck(ag):
ExtAPI.CreateFeature("Deck")
def CreateSupport(ag):
ExtAPI.CreateFeature("Support")
def GenerateDeck(feature,fct):
width = feature.Properties["Width"].Value
width = units.ConvertUnit(width, ExtAPI.DataModel.CurrentUnitFromQuantityName("Length"), "m")
num = feature.Properties["Beams"].Value
bodies = []
boxGen = builder.Primitives.Solid.CreateBox([0.,-width/2.,-0.3],[length,width/2.,0.])
bodies.Add(boxGen.Generate())
w = (length-0.1*num)/(num-1.)+0.1
for i in range(num-1):
beamGen = builder.Primitives.Solid.CreateBox([i*w,-width/2.,-0.6],[i*w+0.1,width/2.,-0.3])
bodies.Add(beamGen.Generate())
beamGen = builder.Primitives.Solid.CreateBox([length-0.1,-width/2.,-0.6],[length,width/2.,-0.3])
beamGen = builder.Primitives.Solid.CreateBox([0.,-width/2.,-1.],[length,-width/2.+0.2,-0.6])
beamGen = builder.Primitives.Solid.CreateBox([0.,width/2.-0.2,-1.],[length,width/2.,-0.6])
return True
def GenerateSupport(feature,fct):
height = feature.Properties["Height"].Value
height = units.ConvertUnit(height, ExtAPI.DataModel.CurrentUnitFromQuantityName("Length"), "m")
width = feature.Properties["Width"].Value
width = units.ConvertUnit(width, ExtAPI.DataModel.CurrentUnitFromQuantityName("Length"), "m")
num = feature.Properties["Number"].Value
bodies = []
w = (length-2.*num)/(num+1.)+2.
for i in range(num):
beamGen = builder.Primitives.Solid.CreateBox([(i+1)*w,-width/2.,-1.-height],
[(i+1)*w+2.,width/2.,-1.])
beamGen = builder.Primitives.Solid.CreateBox([0.,-width/2.,-5.],[2.,width/2.,-1.])
beamGen = builder.Primitives.Solid.CreateBox([length-2.,-width/2.,-5.],[length,width/2.,-1.])
249
Examples
return True
def UpdateDeck(step):
deck = ExtAPI.CreateFeature("Deck")
deck.Properties["Length"].Value = step.Properties["Deck/Length"].Value
deck.Properties["Width"].Value = step.Properties["Deck/Width"].Value
deck.Properties["Beams"].Value = step.Properties["Deck/Beams"].Value
ExtAPI.DataModel.FeatureManager.Generate()
def UpdateSupports(step):
supports = ExtAPI.CreateFeature("Support")
supports.Properties["Length"].Value = step.PreviousStep.Properties["Deck/Length"].Value
supports.Properties["Width"].Value = step.PreviousStep.Properties["Deck/Width"].Value+6
supports.Properties["Height"].Value = step.Properties["Supports/Height"].Value
supports.Properties["Number"].Value = step.Properties["Supports/Number"].Value
ExtAPI.DataModel.FeatureManager.Generate()
Target Application Wizard (Mechanical)

Our Mechanical wizard example is called SimpleAnalysis. It is defined in the extension WizardDemos.
It performs a simple analysis on the bridge built by our previous CreateBridge DesignModeler wizard.

Script Reference
the script ds.py.
The <interface> block defines details of the interface.
The context attribute is set to Mechanical because the extension is executed in the Mechanical
application.
The <images> block refers to the extension images folder; the image contained in this folder is displayed
as the icon for the wizard.
Wizard Definition
The context attribute is set to Mechanical because the wizard will be executed in the Mechanical
application.
Step Definitions
The <step> tag is used to define the steps of the wizard. There are three steps: Mesh, Solution, and
Results.
250

For each step:
step.
For the Mesh step, the <onreset> callback executes the RemoveControls function to clear existing
mesh controls; the <onupdate> callback executes the CreateMeshControls function to create
new mesh controls.
For the Solution step:
The <onrefresh> callback executes the RefreshLoads function to initialize various properties
(number of nodes, number of elements computed in the previous step, etc.).
The <onreset> callback executes the RemoveLoads function to clear loads.
The <onupdate> callback executes the CreateLoads to create new loads, create new results,
and perform the solve.
For the Results step, the <onrefresh> callback executes the RefreshResults function to fill
the property value associated to the result of the computation (Maximum of Total Deformation).
The <propertygroup> blocks define properties and property attributes for the steps. For properties
requiring location selection, the <isvalid> callback executes the IsLocationValid function to
validate the selection. A custom message can be displayed when the entered value fails validation.
</interface>
...
<wizard name="SimpleAnalysis" version="1" context="Mechanical" icon="wizard_icon">
<description>Simple wizard to illustrate how to setup, solve and analyse results of a simulation
process.</description>
<step name="Mesh" caption="Mesh" version="1" HelpFile="help/ds1.html">
<description>Setup some mesh controls.</description>
<callbacks>
<onreset>RemoveControls</onreset>
<onupdate>CreateMeshControls</onupdate>
</callbacks>
<propertygroup display="caption" name="Sizing" caption="Mesh Sizing" >
<property name="Location" caption="Edge Location" control="geometry_selection">
<callbacks>
<isvalid>IsLocationValid</isvalid>
</callbacks>
251
Examples
</property>
<property name="Ndiv" caption="Divisions" control="integer" />
</propertygroup>
</step>
<step name="Solution" caption="Solution" version="1" HelpFile="help/ds2.html">
<description>Setup loads.</description>
<callbacks>
<onrefresh>RefreshLoads</onrefresh>
<onreset>RemoveLoads</onreset>
<onupdate>CreateLoads</onupdate>
</callbacks>
<propertygroup display="caption" name="Mesh" caption="Mesh Statistics" >
<property name="Nodes" caption="Nodes" control="text" readonly="true" />
<property name="Elements" caption="Elements" control="text" readonly="true" />
</propertygroup>
<propertygroup display="caption" name="FixedSupport" caption="Fixed Support" >
<property name="Location" caption="Face Location" control="geometry_selection">
<callbacks>
<isvalid>IsLocationFSValid</isvalid>
</callbacks>
</property>
</propertygroup>
</step>
<step name="Results" caption="Results" version="1" HelpFile="help/ds3.html">
<description>View Results.</description>
<callbacks>
<onrefresh>RefreshResults</onrefresh>
</callbacks>
<property name="Res" caption="Deformation" control="text" readonly="true" />
</step>
</wizard>
IronPython Script
Below is the IronPython script, ds.py.
def IsLocationValid(step, prop):
if prop.Value==None:
return False
if prop.Value.Ids.Count!=1:
prop.StateMessage = "Select only one edge."
return False
return True
def CreateMeshControls(step):
model = ExtAPI.DataModel.Project.Model
mesh = model.Mesh
sizing = mesh.AddSizing()
sel = step.Properties["Sizing/Location"].Value
entity = ExtAPI.DataModel.GeoData.GeoEntityById(sel.Ids[0])
len = entity.Length
ids = []
for part in ExtAPI.DataModel.GeoData.Assemblies[0].Parts:
if abs(edge.Length-len)/len<1.e-6:
252

ids.Add(edge.Id)
sel = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
sel.Ids = ids
sizing.Location = sel
sizing.Type = SizingType.NumberOfDivisions
sizing.NumberOfDivisions = step.Properties["Sizing/Ndiv"].Value
step.Attributes.SetValue("sizing", sizing)
mesh.GenerateMesh()
def RemoveControls(step):
sizing = step.Attributes["sizing"]
sizing.Delete()
def IsLocationFSValid(step, prop):
if prop.Value==None:
return False
if prop.Value.Ids.Count!=1:
prop.StateMessage = "Select only one face."
return False
return True
def RefreshLoads(step):
step.Properties["Mesh/Nodes"].Value = model.Mesh.Nodes.ToString()
step.Properties["Mesh/Elements"].Value = model.Mesh.Elements.ToString()
panel = step.UserInterface.GetPanel("Properties")
panel.UpdateData()
panel.Refresh()
def CreateLoads(step):
analysis = model.Analyses[0]
support = analysis.AddFixedSupport()
sel = step.Properties["FixedSupport/Location"].Value
entity = ExtAPI.DataModel.GeoData.GeoEntityById(sel.Ids[0])
area = entity.Area
ids = []
for part in ExtAPI.DataModel.GeoData.Assemblies[0].Parts:
for face in body.Faces:
if abs(face.Area-area)/area<1.e-6:
ids.Add(face.Id)
sel = ExtAPI.SelectionManager.CreateSelectionInfo(SelectionTypeEnum.GeometryEntities)
sel.Ids = ids
support.Location = sel
loads = []
loads.Add(support)
step.Attributes.SetValue("loads", loads)
loads.Add(analysis.AddEarthGravity())
res = analysis.Solution.AddTotalDeformation()
step.Attributes.SetValue("res", res)
loads.Add(res)
analysis.Solve(True)
ExtAPI.Extension.SetAttributeValueWithSync("result", res.Maximum.ToString())
def RemoveLoads(step):
loads = step.Attributes["loads"]
for load in loads:
load.Delete()
def RefreshResults(step):
res = step.PreviousStep.Attributes["res"]
step.Properties["Res"].Value = res.Maximum.ToString()
panel = step.UserInterface.GetPanel("Properties")
panel.UpdateData()
panel.Refresh()
253
Examples
Mixed Wizard
Our mixed wizard example is called BridgeSimulation. It is defined in the extension WizardDemos.
It executes one step on the Project tab, reuses the bridge builder in our CreateBridge DesignModeler
wizard, reruns the bridge analysis in our SimpleAnalysis Mechanical wizard, and then returns to the
Project tab to execute a Results step.

Below is an excerpt of the XML extension file, WizardDemos.xml. Because this is a mixed wizard incorporating steps on the Project tab with steps from our existing DesignModeler and Mechanical wizards,
it uses all of the content in the XML extension defitinition file.
Script Reference
The <script> block specifies the IronPython scripts referenced by the extension. This wizard references
all three of the script files: main.py, dm.py, and ds.py.
The <interface> blocks define details of the interface. This wizard uses all of the interface blocks.
In one <interface> block, the context attribute is set to Project|Mechanical. In another
<interface> block, the context attribute is set to DesignModeler.
The <toolbar> block is used to define two toolbar buttons for exposure in DesignModeler. When the
buttons are clicked, the <onclick> callbacks execute the CreateDeck and CreateSupport
functions and create a deck geometry with supports.
Simdata Definition
The two <simdata> blocks provide data for the creation of the Deck and Support geometries in
DesignModeler.
Wizard Definition
The context attribute is set to Project because the wizard will be executed in the Project tab; it
accesses the target applications from the Project tab instead of executing in them directly.
Step Definitions
The <step> tag is used to define the steps of the wizard. There are six steps: Project, Deck, Supports,
Mesh, Solution, and Results.
For each step:
step.
254

For the Project step, the <onupdate> callback executes the CreateStaticStructural
function in main.py.
For the Deck and Supports steps, <onupdate> callback executes the UpdateDeck and UpdateSupports functions in dm.py.
For the Mesh step, the <onreset> and <onupdate> callbacks execute the RemoveControls
and CreateMeshControls functions in ds.py.
For the Solution step, the <onrefresh>, <onreset>, and <onupdate> callbacks execute the
RefreshLoads, RemoveLoads, and CreateLoads functions in ds.py.
For the Results step, the <onrefresh> callback executes the RefreshResultsProject
function in main.py.
The <propertygroup> blocks define properties and property attributes for the steps.
</interface>
<toolbar name="Deck" caption="Deck">
<entry name="Deck" icon="deck">
<callbacks>
<onclick>CreateDeck</onclick>
</callbacks>
</entry>
<entry name="Support" icon="Support">
<callbacks>
<onclick>CreateSupport</onclick>
</callbacks>
</entry>
</toolbar>
</interface>
<geometry name="Deck" caption="Deck" icon="deck" version="1">
<callbacks>
<ongenerate>GenerateDeck</ongenerate>
</callbacks>
</geometry>
</simdata>
<geometry name="Support" caption="Support" icon="support" version="1">
<callbacks>
<ongenerate>GenerateSupport</ongenerate>
</callbacks>
255
Examples
property name="Number" caption="Number" control="integer" default="3" />
</geometry>
</simdata>
<description>Simple wizard for demonstration in Project page.</description>
<step name="Geometry" caption="Geometry" version="1" HelpFile="help/geometry.html">
<callbacks>
<onupdate>CreateGeometry</onupdate>
<onreset>DeleteGeometry</onreset>
</callbacks>
default="Option1">
</propertygroup>
</propertygroup>
</step>
<step name="Mechanical" caption="Mechanical" enabled="true" version="1" HelpFile="help/mechanical.html">
<callbacks>
<onupdate>CreateMechanical</onupdate>
<onreset>DeleteMechanical</onreset>
</callbacks>
</propertytable>
</step>
<step name="Fluent" caption="Fluent" version="1" HelpFile="help/fluent.html">
<callbacks>
<onrefresh>CreateDialog</onrefresh>
<onupdate>CreateFluent</onupdate>
</callbacks>

<callbacks>
</callbacks>
</property>
256

<callbacks>
</callbacks>
</property>
<property name="nextstep" caption="Next Step" control="select" >
<callbacks>
<onvalidate>ValidateNextStep</onvalidate>
</callbacks>
</property>
</step>
<step name="ReportView" caption="ReportView" version="1" layout="ReportView@WizardDemos">
<callbacks>
<onrefresh>RefreshReport</onrefresh>
</callbacks>
</step>
<step name="CustomStep" caption="CustomStep" enabled="true" version="1" layout="MyLayout@WizardDemos">
<callbacks>
<onrefresh>RefreshMechanical</onrefresh>
<onupdate>LogReport</onupdate>
</callbacks>
</step>
<step name="Charts" caption="Charts" enabled="true" version="1" layout="GraphLayout@WizardDemos">
<description>Demonstrate all chart capabilities.</description>
<callbacks>
<onrefresh>RefreshCharts</onrefresh>
</callbacks>
</step>
</wizard>
<wizard name="CreateBridge" version="1" context="DesignModeler" icon="wizard_icon">
<description>Simple wizard for demonstration in DesignModeler.</description>
<step name="Deck" caption="Deck" version="1" HelpFile="help/dm1.html">
<callbacks>
</callbacks>
</propertygroup>
</step>
<step name="Supports" caption="Supports" enabled="true" version="1" HelpFile="help/dm2.html">
<callbacks>
</callbacks>
257
Examples
</propertygroup>
</step>
</wizard>
<wizard name="SimpleAnalysis" version="1" context="Mechanical" icon="wizard_icon">
<description>Simple wizard to illustrate how to setup, solve and analyse results of
a simulation process.</description>
<step name="Mesh" caption="Mesh" version="1" HelpFile="help/ds1.html">
<callbacks>
</callbacks>
<callbacks>
</callbacks>
</property>
</propertygroup>
</step>
<step name="Solution" caption="Solution" version="1" HelpFile="help/ds2.html">
<callbacks>
</callbacks>
</propertygroup>
<callbacks>
</callbacks>
</property>
</propertygroup>
</step>
<step name="Results" caption="Results" version="1" HelpFile="help/ds3.html">
<callbacks>
<onrefresh>RefreshResults</onrefresh>
</callbacks>
</step>
</wizard>
<wizard name="BridgeSimulation" version="1" context="Project" icon="bridge">
<description>Simple wizard for mixed wizard demonstration.</description>
258

<step name="Project" caption="Create Project" version="1" context="Project" HelpFile="help/prj1.html">
<description>Create a static structural analysis.</description>
<callbacks>
<onupdate>CreateStaticStructural</onupdate>
<onreset>DeleteStaticStructural</onreset>
</callbacks>
<property name="Name" caption="system name" control="text" />
</step>
<step name="Deck" caption="Deck" version="1" context="DesignModeler" HelpFile="help/dm1.html">
<callbacks>
</callbacks>
</propertygroup>
</step>
<step name="Supports" caption="Supports" context="DesignModeler" enabled="true" version="1"
HelpFile="help/dm2.html">
<callbacks>
</callbacks>
</propertygroup>
</step>
<step name="Mesh" caption="Mesh" version="1" context="Mechanical" HelpFile="help/ds1.html">
<callbacks>
</callbacks>
<callbacks>
</callbacks>
</property>
</propertygroup>
</step>
<step name="Solution" caption="Solution" version="1" context="Mechanical" HelpFile="help/ds2.html">
<callbacks>
</callbacks>
259
Examples
</propertygroup>
<callbacks>
</callbacks>
</property>
</propertygroup>
</step>
<step name="Results" caption="Results" version="1" context="Project" HelpFile="help/prj2.html">
<callbacks>
<onrefresh>RefreshResultsProject</onrefresh>
</callbacks>
</step>
</wizard>
</extension>
IronPython Script
Because this is a mixed wizard incorporating steps on the Project tab with steps from our existing
DesignModeler and Mechanical wizards, the XML file references the three script files shown in previous
sections:
main.py
dm.py
ds.py
AIM Custom Template

Our AIM custom template example is called StudyDemo1. It is defined in the extension StudyDemo.

Below is the XML extension file, StudyDemo.xml.
Script Reference
The <script> block specifies the IronPython script referenced by the extension. For this custom template,
the script is main.py.
In the <interface> block:
The context attribute is set to Study.
260

Custom Template Definition
The custom template is defined in the <wizard> block, which defines the single step of the custom
template (only single-step guided processes are supported at present).
Step Definitions
The <step> tag is used to define the single step of our custom template, step1.
The required name, version, and context attributes define the step name, version, and context.
Because the step will be executed in AIM, context is set to Study.
The <onupdate> callback executes the action function, which creates the Study in AIM.
The <onreset> executes the reset function, which allows you to modify the template properties.
The <properties> block defines the properties used in the custom template.
For the Geometry property, the control attribute is set to fileopen, which displays a file-selection
property initialized to the default attribute value.
For the NAnalysis property:
The control attribute is set to integer, which allows you to edit the integer value for the default
attribute. This value specifies the number of analyses to be performed.
The <isvalid> callback calls the isvalid function, which validates that the entered integer is
not less than 1. A custom message can be displayed when the entered value fails validation.
<extension version="1" name="StudyDemo">
<interface context="Study">
</interface>
<wizard name="StudyDemo1" version="1" context="Study" icon="icon">
<description>Wizard to demonstrate the concept inside AIM.</description>
<step name="Step1" caption="Load geometry file" version="1" context="Study">
<description>Import a geometry file.</description>
<callbacks>
<onupdate>action</onupdate>
<onreset>reset</onreset>
</callbacks>
<property name="Geometry" caption="Geometry file name" control="fileopen"
default="E:/Models/box.agdb" />
<property name="NAnalysis" caption="Number of Analysis" control="integer" default="1">
<callbacks>
<isvalid>isvalid</isvalid>
</callbacks>
</property>
</step>
</wizard>
261
Examples
</extension>
IronPython Script
Below is the IronPython script, main.py.
This script defines the functions called by the callbacks in the custom template's XML extension definition
file.
The action function is the single step in our custom template. When called by the <onupdate> callback
(invoked by the Create Simulation button), it creates the Study workflow by creating and updating the
Geometry, Mesh, and Physics tasks.
The reset function, when called by the <onreset> callback, resets the UI and allows the user to modify
properties defined for the custom template. This occurs when encountering an error during the execution
of the <onupdate> callback.
The isvalid function, when called by the <isvalid> callback in the <properties> block, validates
that the property value entered is not less than 1. A custom message can be displayed when the entered
value fails validation.
tasksToDelete = []
groupsToDelete = []
def action(step):
global tasksToDelete,groupsToDelete
tasksToDelete = []
groupsToDelete = []
system1 = GetSystem(Name="Study")
importComponent1 = Study.CreateTask(
Type="Import",
System=system1)
tasksToDelete.Add(importComponent1)
study1 = system1.GetContainer(ComponentName="Study")
import1 = importComponent1.GetTaskObject()
geometryImportSource1 = study1.CreateEntity(
Type="GeometryImportSource",
Association=import1)
geometryImportSource1.FilePath = step.Properties["Geometry"].Value
geometryImportSource1.GenerateImportSourceOperation()
step.UpdateProgressInformation(10.)
pct = 10.
for i in range(step.Properties["NAnalysis"].Value):
meshingComponent1 = Study.CreateTask(
Type="Meshing",
System=system1,
Input=importComponent1)
tasksToDelete.Add(meshingComponent1)
meshingComponent1.Refresh()
physicsSolutionGroup1 = Study.CreateGroup(Name="Physics Solution")
groupsToDelete.Add(physicsSolutionGroup1)
physicsDefinitionComponent1 = Study.CreateTask(
Type="Physics Definition",
System=system1)
tasksToDelete.Add(physicsDefinitionComponent1)
solvePhysicsComponent1 = Study.CreateTask(
Type="Solve Physics",
System=system1)
tasksToDelete.Add(solvePhysicsComponent1)
physicsSolutionGroup1.Add(Component=physicsDefinitionComponent1)
physicsSolutionGroup1.Add(Component=solvePhysicsComponent1)
AddSourceToComponentInSystem(
SourceComponent=physicsDefinitionComponent1,
262

TargetComponent=solvePhysicsComponent1)
AddSourceToComponentInSystem(
SourceComponent=meshingComponent1,
TargetComponent=physicsDefinitionComponent1)
physicsDefinitionComponent1.Refresh()
solvePhysicsComponent1.Refresh()
physicsDefinition1 = physicsDefinitionComponent1.GetTaskObject()
physicsRegion1 = study1.CreateEntity(
Type="PhysicsRegion",
Association=physicsDefinition1)
solverSettings1 = study1.CreateEntity(
Type="SolverSettings",
transcript1 = study1.CreateEntity(
Type="Transcript",
physicsDefinitionComponent1.Refresh()
solvePhysicsComponent1.Refresh()
meshing1 = meshingComponent1.GetTaskObject()
meshing1.EngineeringIntent = "StructuralOrThermalOrElectricConduction"
physicsRegion1.Location = ["BODY1"]
physicsRegion1.PhysicsType = "Structural"
materialAssignment1 = study1.CreateEntity(
Type="MaterialAssignment",
materialAssignment1.Location = ["BODY1"]
material1 = study1.CreateEntity(
Type="Material",
material1.ImportEngineeringData(Name="Structural Steel")
materialAssignment1.Material = material1
pct += 10.
step.UpdateProgressInformation(pct)
if i==9:
raise UserErrorMessageException("My own error message.")
def reset(step):
global tasksToDelete,groupsToDelete
system1 = GetSystem(Name="Study")
for group in groupsToDelete:
Study.DeleteTaskGroup(Group=group)
for task in tasksToDelete:
task.DeleteTask(System=system1)
def isvalid(step, prop):
if prop.Value<1:
prop.StateMessage = "Must be greater than 0."
return False
return True
Defining Custom Help

For our custom template, we've defined an HTML help file for the template and each of our two properties, named them according to our filename rules, and placed them in a help directory inside the
extension directory. Support files, such as the workflow.png file (referenced in StudyDemo1.html)
are placed at the same level as the HTML file.
Below, you can see the contents of our help directory.
263
264
Appendix A. ANSYS Workbench Task Inputs and Outputs

Table 1: Autodyn
Taskgroup
Task
Input
Output
AUTODYN_Remap
AutodynSetup
Autodyn
Setup
MechanicalSetup
SimulationGeneratedMesh
Analysis
None
None
Input
Output
None
TurboGeometry
Table 2: BladeGen
Taskgroup
Task
BladeGen
Blade Design
VistaGeometry
BladeGen (Beta)
Blade Design
None
TurboGeometry
VistaGeometry
Table 3: CFX
Taskgroup
Task
Input
Output
CFXSetup
CFXMesh
SystemCouplingSetupData
CFX (Beta)
Setup
MechanicalSetup
Solution
CFXSetup
CFXSolution
CFXSolution
CFX
Setup
CFXSetup
265
ANSYS Workbench Task Inputs and Outputs

Taskgroup
Task
Input
Output
CFXMesh
MechanicalSetup
Solution
CFXSetup
CFXSolution
CFXSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
PolyflowSolutionType
MechanicalSolution
ICEData
Table 4: Design Assessment
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Design
Assessment
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
SimulationEngineeringData
MechanicalModel
SimulationModelGeneratedMesh MechanicalMesh
CompositeEngineeringData
SolidSectionData
ExternalModelOutputProvider
SimulationModelGeneratedMesh
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
266
SimulationSetup
Taskgroup
Task
Input
Output
MechanicalMesh
MechanicalSetup
SimulationSolutionDataInternal
MechanicalSolution
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 5: Direct Optimization

Taskgroup
Task
Input
Output
DesignPointsDataTransfer
OptimizationModel
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Direct
Optimization
Optimization
Table 6: Electric
Taskgroup
Task
Electric
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
SolidSectionData
ExternalDataSetup
EngineeringData
267

Taskgroup
Task
Input
Output
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 7: Engineering Data

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Engineering
Data
Engineering
Data
Table 8: Explicit Dynamics

Taskgroup
Task
Explicit
Dynamics
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
268
Taskgroup
Task
Input
Output
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
EnhancedMechanicalModel
EnhancedModelData
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Explicit
Dynamics
(LS-DYNA
Export)
Engineering
Data
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
SolidSectionData
ExternalDataSetup
269

Taskgroup
Task
Input
Output
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
Input
Output
None
ExternalDataSetup
Input
Output
None
Input
Output
None
ExternalConnectionProperties
Input
Output
MechanicalSetup
FEMMesh
FEMSetup
MAPDLCdb
Geometry
Table 9: External Data

Taskgroup
Task
External Data
Setup
Table 10: External Model

Taskgroup
Task
External Model
Setup
Table 11: External Connection

Taskgroup
Task
External
Connection
External
Connection
Table 12: Finite Element Modeler

Taskgroup
Task
Finite Element
Modeler
Model
FEMSetup
SolidSectionData
270
Taskgroup
Task
Input
Output
Table 13: Fluent
Taskgroup
Task
Input
Output
FluentImportable
FluentSetup
AnsoftHeatLossDataObject
Fluent
Setup
FluentMesh
FluentCase
ICEData
ICESetupData
FluentTGridMesh
Solution
FluentSetup
FluentSolution
FluentSolution
Table 14: Fluid Flow Blow Molding (Polyflow)
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Fluid Flow
Blow
Molding
(Polyflow)
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Mesh
Geometry
MechanicalModel
MeshingGeneratedMeshOutput
Provider
MeshingMesh
MeshingGeneratedMeshOutputProvider
Setup
PolyflowSetup
PolyflowTransferMesh
Solution
271

Taskgroup
Task
Input
Output
PolyflowSetup
PolyflowSolution
PolyflowSolution
ExternalDataSetup
Results
CFXSolution
CFD Analysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 15: Fluid Flow Extrusion (Polyflow)
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Fluid Flow
Extrusion
(Polyflow)
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Mesh
Geometry
MechanicalModel
Provider
MeshingMesh
Provider
Setup
PolyflowSetup
Solution
PolyflowSetup
PolyflowSolution
PolyflowSolution
ExternalDataSetup
Results
CFXSolution
CFDAnalysis
FluentSolution
272
Taskgroup
Task
Input
Output
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 16: Fluid Flow (CFX)
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Fluid Flow
(CFX)
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Mesh
Geometry
MechanicalModel
Provider
MeshingMesh
Provider
Setup
CFXSetup
CFXMesh
MechanicalSetup
Solution
CFXSetup
CFXSolution
CFXSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
273

Taskgroup
Task
Input
Output
ICEData
Table 17: Fluid Flow (Fluent)
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Fluid Flow
(Fluent)
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Mesh
Geometry
MechanicalModel
Provider
MeshingMesh
Provider
Setup
FluentImportable
FluentSetup
FluentMesh
FluentCase
ICEData
ICESetupData
FluentTGridMesh
Solution
FluentSetup
FluentSolution
FluentSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
274
Taskgroup
Task
Input
Output
ICEData
Table 18: Fluid Flow (Polyflow)
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Fluid Flow
(Polyflow)
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Mesh
Geometry
MechanicalModel
Provider
MeshingMesh
Provider
Setup
PolyflowSetup
Solution
PolyflowSetup
PolyflowSolution
PolyflowSolution
ExternalDataSetup
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 19: Geometry
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Geometry
Geometry
275

Taskgroup
Task
Input
Output
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Table 20: Harmonic Response
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Harmonic
Response
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
EnhancedModelData
ExternalDataSetup
MechanicalSolution
AnsoftForceAndMomentDataObject
Solution
SimulationSetup
276
MechanicalSolution
Taskgroup
Task
Input
Output
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 21: Hydrodynamic Diffraction

Taskgroup
Task
Input
Output
FEMSetup
Geometry
Hydrodynamic
Diffraction
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
Geometry
AqwaModel
AqwaModel
AqwaSetup
AqwaSetup
AqwaSolution
AqwaSolution
AqwaResults
Setup
Solution
Results
Table 22: Hydrodynamic Response

Taskgroup
Task
Input
Output
FEMSetup
Geometry
Hydrodynamic
Response
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
Geometry
AqwaModel
AqwaModel
AqwaSetup
Setup
277

Taskgroup
Task
Input
Output
AqwaSolution
Solution
AqwaSetup
AqwaSolution
AqwaSolution
AqwaResults
Input
Output
None
ICEData
FEMSetup
Geometry
Results
Table 23: ICE

Taskgroup
Task
ICE
ICE
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Mesh
Geometry
MechanicalModel
Provider
MeshingMesh
Provider
ICE
Solver
Setup
SimulationGeneralMesh
ICESetupData
Setup
FluentImportable
FluentSetup
FluentMesh
FluentCase
ICEData
ICESetupData
FluentTGridMesh
Solution
FluentSetup
278
FluentSolution
Taskgroup
Task
Input
Output
FluentSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 24: ICEM CFD
Taskgroup
Task
Input
Model
FluentImportable
Output
ICEM CFD
Geometry
MeshingMesh
MechanicalMesh
Table 25: Icepak
Taskgroup
Task
Input
Output
Geometry
IcePakSetup
Icepak
Setup
Solution
IcePakSetup
IcePakResults
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Table 26: Linear Buckling

Taskgroup
Task
Eigenvalue
Buckling
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
279

Taskgroup
Task
Input
Output
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
EnhancedModelData
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 27: Linear Buckling (Samcef)

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Eigenvalue
Buckling
(Samcef )
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
280
Taskgroup
Task
Input
Output
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 28: Magnetostatic

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Magnetostatic
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
281

Taskgroup
Task
Input
Output
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
SimulationSetup
MechanicalSolution
Solution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 29: Mechanical APDL

Taskgroup
Task
Input
Output
MechanicalSetup
None
Mechanical
APDL
Analysis
FEMSetup
Geometry
SolidSectionData
MechanicalSolution
MAPDLSolution
MAPDLDatabase
MAPDLResults
MAPDLCdb
Table 30: Mechanical Model
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
Mechanical
Model
Engineering
Data
282
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Table 31: Mesh
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Mesh
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Mesh
Geometry
MechanicalModel
Provider
MeshingMesh
Provider
Table 32: Microsoft Office Excel

Taskgroup
Task
Input
Output
Microsoft
Office Excel
Analysis
283

Taskgroup
Task
Input
Output
None
MSExcelSetup
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Table 33: Modal (ABAQUS)

Taskgroup
Task
Modal
(ABAQUS)
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
284
MechanicalResults
Taskgroup
Task
Input
Output
SimulationResults
Table 34: Modal

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Modal
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
EnhancedModelData
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
285

Taskgroup
Task
Input
Output
SimulationResults
Table 35: Modal (NASTRAN)

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Modal
(NASTRAN)
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
SimulationSetup
MechanicalSolution
Solution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 36: Modal (Samcef)

Taskgroup
Task
Input
Output
Modal
(Samcef )
286
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 37: Parameters Correlation

Taskgroup
Task
Input
Output
ResponseSurfaceDataTransfer
CorrelationModel
Parameters
Correlation
Parameters
Correlation
287

Taskgroup
Task
Input
Output
Table 38: Polyflow Blow Molding

Taskgroup
Task
Input
Output
PolyflowSetup
Polyflow
Blow
Molding
Setup
Solution
PolyflowSetup
PolyflowSolution
PolyflowSolution
ExternalDataSetup
Table 39: Polyflow Extrusion

Taskgroup
Task
Input
Output
PolyflowSetup
Polyflow Extrusion
Setup
Solution
PolyflowSetup
PolyflowSolution
PolyflowSolution
ExternalDataSetup
Table 40: Polyflow

Taskgroup
Task
Input
Output
PolyflowSetup
Polyflow
Setup
Solution
288
PolyflowSetup
PolyflowSolution
PolyflowSolution
Taskgroup
Task
Input
Output
ExternalDataSetup
Table 41: Random Vibration

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Random
Vibration
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
EnhancedModelData
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
289

Taskgroup
Task
Input
Output
SimulationResults
Table 42: Response Spectrum

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Response
Spectrum
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
EnhancedModelData
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
290
MechanicalResults
Taskgroup
Task
Input
Output
SimulationResults
Table 43: Response Surface

Taskgroup
Task
Input
Output
None
ParametricContext
Response
Surface
Design
of
Experiments
DOEModel
Response
Surface
ParametricContext
ResponseSurfaceModel
DOEModel
Table 44: Response Surface Optimization

Taskgroup
Task
Input
Output
None
ParametricContext
Response
Surface
Optimization
Design
of
Experiments
DOEModel
Response
Surface
ParametricContext
DOEModel
Optimization
ParametricContext
OptimizationModel
Table 45: Results
Taskgroup
Task
Input
Output
Results
291

Taskgroup
Task
Input
Output
CFXSolution
CFDAnalysis
Results
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 46: Rigid Dynamics
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Rigid
Dynamics
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
SimulationSetup
MechanicalSolution
Solution
SimulationSolution
292
Taskgroup
Task
Input
Output
SimulationSolution
MechanicalResults
Results
SimulationResults
Table 47: Shape Optimization
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Shape
Optimization
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
293

Taskgroup
Task
Input
Output
SimulationSolution
MechanicalResults
Results
SimulationResults
Table 48: Six Sigma Analysis
Taskgroup
Task
Input
Output
Six Sigma
Analysis
Design of
Experiments
(SSA)
ParametricContext
DOEModel
Response
Surface (SSA)
ParametricContext
DOEModel
Six Sigma
Analysis
ParametricContext
SixSigmaModel
Table 49: Static Structural (ABAQUS)
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Static
Structural
(ABAQUS)
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
294
MechanicalModel
Taskgroup
Task
Input
Output
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 50: Static Structural

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Static
Structural
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
295

Taskgroup
Task
Input
Output
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
EnhancedModelData
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
AnsoftForceDataObject
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 51: Static Structural (Samcef)

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
Static
Structural
(Samcef )
Engineering
Data
Geometry
296
Taskgroup
Task
Input
Output
FEMSetup
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 52: Steady-State Thermal (ABAQUS)

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
Steady-State
Thermal
(ABAQUS)
Engineering
Data
297

Taskgroup
Task
Input
Output
MatML31
Material
FEMSetup
Geometry
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
FluentSolution
IcePakResults
MechanicalSolution
CFXSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 53: Steady-State Thermal

Taskgroup
Task
Input
Output
Steady-State
Thermal
Engineering
Data
298
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 54: Taskgroup Coupling

Taskgroup
Task
Input
Output
Taskgroup
Coupling
299

Taskgroup
Task
Input
Output
CouplingSetupProvider
Setup
ExternalDataSetup
Solution
None
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Table 55: Thermal-Electric

Taskgroup
Task
Thermal-Electric
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
300
Taskgroup
Task
Input
Output
SimulationSolution
MechanicalResults
Results
SimulationResults
Table 56: Throughflow
Taskgroup
Task
Input
Output
FEMSetup
Geometry
Throughflow
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Setup
VistaGeometry
VistaTFSetup
VistaTFPhysics
Geometry
Solution
VistaTFSetup
VistaTFSolution
VistaTFSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 57: Throughflow (BladeGen)
Taskgroup
Task
Input
Output
None
TurboGeometry
Throughflow
(BladeGen)
Blade
Design
VistaGeometry
Setup
VistaGeometry
VistaTFSetup
301

Taskgroup
Task
Input
Output
VistaTFPhysics
Geometry
Solution
VistaTFSetup
VistaTFSolution
VistaTFSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 58: Transient Structural (ABAQUS)
Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Transient
Structural
(ABAQUS)
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
302
Taskgroup
Task
Input
Output
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 59: Transient Structural

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Transient
Structural
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
303

Taskgroup
Task
Input
Output
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
EnhancedModelData
Setup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 60: Transient Structural (Samcef)

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Transient
Structural
(Samcef )
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
304
MechanicalModel
MechanicalMesh
Taskgroup
Task
Input
Output
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 61: Transient Thermal (ABAQUS)

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Transient
Thermal
(ABAQUS)
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
Model
305

Taskgroup
Task
Input
Output
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 62: Transient Thermal

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Transient
Thermal
Engineering
Data
Geometry
TurboGeometry
AnsoftCADObject
ICEData
Geometry
306
Taskgroup
Task
Input
Output
MechanicalModel
MechanicalMesh
SolidSectionData
Model
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 63: Transient Thermal (Samcef)

Taskgroup
Task
Input
Output
FEMSetup
EngineeringData
MatML31
Material
FEMSetup
Geometry
Transient
Thermal
(Samcef )
Engineering
Data
Geometry
TurboGeometry
307

Taskgroup
Task
Input
Output
AnsoftCADObject
ICEData
Geometry
Model
MechanicalModel
MechanicalMesh
SolidSectionData
ExternalDataSetup
EngineeringData
Geometry
Setup
MechanicalModel
SimulationSetup
MechanicalMesh
MechanicalSetup
CFXSolution
FluentSolution
IcePakResults
MechanicalSolution
ExternalDataSetup
Solution
SimulationSetup
MechanicalSolution
SimulationSolution
Results
SimulationSolution
MechanicalResults
SimulationResults
Table 64: Turbomachinery Fluid Flow (BladeEditor)

Taskgroup
Task
Input
Output
FEMSetup
Geometry
Turbomachinery
Fluid Flow
(BladeEditor)
Geometry
TurboGeometry
AnsoftCADObject
ICEData
308
Taskgroup
Task
Input
Output
Geometry
Turbo
Mesh
TurboGeometry
TurboMesh
Geometry
CFXMesh
FluentImportable
Setup
CFXSetup
CFXMesh
MechanicalSetup
Solution
CFXSetup
CFXSolution
CFXSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 65: TurboGrid
Taskgroup
Task
Input
Output
TurboGeometry
TurboMesh
Geometry
CFXMesh
TurboGrid
Turbo
Mesh
FluentImportable
Table 66: Vista TF
Taskgroup
Task
Input
Output
VistaGeometry
VistaTFSetup
Vista TF
Setup
VistaTFPhysics
Geometry
Solution
309

Taskgroup
Task
Input
Output
VistaTFSetup
VistaTFSolution
VistaTFSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
VistaTFSolution
IcePakResults
MechanicalSolution
ICEData
Table 67: Vista AFD
Taskgroup
Task
Input
Output
None
VistaAFDMeanlineProvider
VistaAFDDesignProvider
None
Input
Output
None
VistaCCDBladeDesignProvider
Input
Output
None
Vista AFD
Meanline
Design
Analysis
Table 68: Vista CCD

Taskgroup
Task
Vista CCD
Blade
Design
Table 69: Vista CCD (with CCM)

Taskgroup
Task
Vista CCD
(with CCM)
Blade
Design
Performance
Map
310
Taskgroup
Task
Input
Output
None
Table 70: Vista CPD

Taskgroup
Task
Input
Output
None
None
Input
Output
None
None
None
VistaGeometry
Vista CPD
Blade Design
Table 71: Vista RTD

Taskgroup
Task
Vista RTD
Blade Design
Table 72: Vista RTD (Beta)

Vista RTD (Beta)
Blade Design
VistaTFPhysics
Table 73: ACP (Pre)
ACP (Pre)
Engineering Data
FEMSetup
EngineeringData
MatML31
Material
AnsoftCADObject
Geometry
Geometry
FEMSetup
Geometry
ICEData
TurboGeometry
Model
MechanicalMesh
EngineeringData
MechanicalModel
ExternalDataSetup
SimulationEngineering
Data
ExternalModelOutputProvider SimulationGenerated
Mesh
Geometry
SimulationModelGenerated
Mesh
311

SolidSectionData
Setup
ACPSetupData
ACPSetupData
EngineeringData
CompositeEngineering
Data
Geometry
EnhancedModelData
SolidSectionData
FEMSetup
EngineeringData
MatML31
Material
AnsoftCADObject
Geometry
Table 74: ACP (Post)

ACP (Post)
Engineering Data
Geometry
FEMSetup
Geometry
ICEData
TurboGeometry
Model
MechanicalMesh
EngineeringData
MechanicalModel
ExternalDataSetup
SimulationEngineering
Data
ExternalModelOutputProvider SimulationGenerated
Mesh
Geometry
Mesh
SolidSectionData
Results
EngineeringData
MAPDLSolution
MechanicalSolution
312
Mesh
Table 75: Maxwell 3D
Maxwell 3D
Geometry
AnsoftCADGeometryEntity
AnsoftCADObject
AnsoftGeometryManagerData AnsoftCellInOutEntity
Object
Geometry
AnsoftGeometryManager
DataObject
AnsoftCellInOutEntity
Setup
FeedbackIteratorSetup
Solution
AnsoftForceAndMoment
DataObject
AnsoftHeatLossData
Object
Table 76: Maxwell 2D

Maxwell 2D
Geometry
AnsoftCADObject
AnsoftGeometryManagerData AnsoftCellInOutEntity
Object
Geometry
AnsoftGeometryManager
DataObject
Setup
Solution
AnsoftForceAndMoment
DataObject
AnsoftHeatLossData
Object
Table 77: RMxprt

RMxprt
Setup
313

Solution
Table 78: Simplorer
Simplorer
Setup
MechanicalSetup
Solution
Table 79: FeedbackIterator
FeedbackIterator
Feedback Iterator
FeedbackIteratorEntity
Table 80: Turbo Setup

Turbo Setup
Turbo Setup
Table 81: Turbo Machinery Fluid Flow (Bladegen) (Beta)
Turbomachinery
Fluid Flow
(BladeGen) (Beta)
Blade Design
TurboGeometry
VistaGeometry
Turbo Mesh
Geometry
CFXMesh
TurboGeometry
FluentImportable
TurboMesh
Setup
CFXMesh
CFXSetup
MechanicalSetup
SystemCouplingSetup
Data
Solution
CFXSetup
CFXSolution
CFXSolution
Results
CFXSolution
FluentSolution
314
CFDAnalysis
ICEData
IcePakResults
MechanicalSolution
VistaTFSolution
Table 82: Turbo Machinery Fluid Flow
Turbomachinery
Fluid Flow
Turbo Mesh
Geometry
CFXMesh
TurboGeometry
FluentImportable
TurboMesh
Setup
CFXMesh
CFXSetup
MechanicalSetup
SystemCouplingSetup
Data
Solution
CFXSetup
CFXSolution
CFXSolution
Results
CFXSolution
CFDAnalysis
FluentSolution
ICEData
IcePakResults
MechanicalSolution
VistaTFSolution
315
316
Appendix B. Data Transfer Types

Table 83: Data Transfer Types and Properties
Transfer Type
Property
ACPSetupData
ACPFileReference
ACPPreFileReference
GeometryFilePath
AnsoftCADObject
AnsoftTransferXMLString
AnsoftProjectResultsFolderAtCurrentDP
AnsoftForceAndMomentDataObject
AnsoftGeometryManagerDataObject
FeedbackIteratorEntity
MAPDLSolution
TransferFile
AuxiliaryFiles
MAPDLDatabse
TransferFile
AuxiliaryFiles
MAPDLResults
AuxiliaryFiles
MAPDLCdb
TransferFile
AuxiliaryFiles
AqwaModel
AqwaSetup
AqwaSolution
317
Data Transfer Types

Transfer Type
Property
AqwaResults
AutodynSetup
CFDAnalysis
PostStateFile
CFXSetup
CFXSolverInputFile
MAPDLSolverInputFile
CFXSolution
MResLoadOption
CFXResultsFile
AuxiliaryFiles
MAPDLResultsFile
Geometry
GeometryFilePath
PlugInName
ParametricContext
DOEModel
ResponseSurfaceDatTransfer
OptimizationModel
CorrelationModel
ROModel
SixSigmaModel
EngineeringData
TransferFile
Material
ExternalConnectionProperties
ExternalDataSetup
TransferFile
TransferFile
InputFiles
SolidSectionData
TransferFile
AuxiliaryFiles
CompositeSectionFiles
318
Transfer Type
Property
EnhancedModelData
FEMMesh
ACMOFile
FEMSetup
FEModelerFile
ANSYSInputFile
ParasolidFile
FiniteElementModelMaterials
AuxiliaryFiles
FluentTGridMesh
TransferFile
FluentSetup
CaseFile
ModelInfoFile
FluentCase
MeshFile
TransferFile
FluentSolution
CaseFile
DataFile
ICEData
ICESetupData
IcePakSetup
IcePakResults
MechanicalModel
File
EdaFile
MeshingGeneratedMeshOutputProvider
PMDBFile
ACMOFile
Mechdb
MeshingMesh
TransferFile
SimulationGeneralMesh
TransferFile
TransferFile
319
Data Transfer Types

Transfer Type
Property
MSExcelSetup
TransferFile
PolyflowSetup
DataFile
PubFile
GeneratedFiles
PolyflowSolution
MechanicalModel
MechanicalMesh
TransferFile
TransferFiles
TransferFile
SimulationSetup
MechanicalSetup
TransferFile
MechanicalSolution
SimulationSolution
MechanicalResults
SimulationResults
TurboGeometry
INFFilename
GeometryFilename
TurboMesh
FileName
CFXMesh
FileName
PreFileType
FluentImportable
MeshFile
FileType
Dimension
VistaGeometry
GeoData
320
Transfer Type
Property
TransferData
VistaTFPhysics
TransferData
VistaCCDBlaseDesignProvider
TransferData
TransferData
TransferData
VistaTFSetup
ControlFilename
GeoFilename
AeroFilename
CorrelationsFilename
VistaTFSolution
ResultsFile
RestartFile
AUTODYN_Remap
MatML31
TransferFile
TransferFile
FluentMesh
TransferFile
TransferFile
321
322

ANSYS ACT Developers Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ANSYS ACT Developers Guide

Caricato da

Copyright:

Formati disponibili

ANSYS ACT Developer's Guide

Copyright and Trademark Information

U.S. Government Rights