ACT Basics

1 © 2011 ANSYS, Inc. December 3, 2012

 Agenda

• ACT Overview

• Extensions Menu

• Extensions Options

• Extension Basics

• Extension Types

• Understanding an example extension

• Q/A

2 © 2011 ANSYS, Inc. December 3, 2012

 What is ACT?
ACT enables to develop customization to capture knowhow, expertise, process, legacy tools… within
ANSYS Mechanical environment in order to take advantage of:
• A unified and consistent workflow
• A consolidated user environment that facilitates ease of use

Based on 10 years experience in Customization

“Similar” in concept to APDL, but for the Mechanical GUI
An add-on module to the Workbench Environment based on Python and XML
Programming is interactive/interpretive
– Like APDL (in MAPDL), allows you (in Workbench Mechanical Application) to:
• get, modify, and put data
• Add new capabilities
• Encapsulate process flow
• Automate repetitive tasks
• Integrates with external processes and codes
• Be creative…

3 © 2011 ANSYS, Inc. December 3, 2012

 What ACT offers

• Encapsulate APDL macros: Allows re-use of legacy APDL-

scripts enabling transition to Mechanical application
• MAPDL exposure: Fills the gap between MAPDL solver
capabilities and their exposure in ANSYS Mechanical
• New pre-processing features (custom loads and boundary
conditions)
• New post-processing features (custom results)
• In-house solver integration (Mechanical GUI)

4 © 2011 ANSYS, Inc. December 3, 2012

 ACT entry points in Mechanical
How standard Mechanical works:
• When user “solves” an analysis in Mechanical ,
the following things happen
1. All items in the tree (Mesh, Contacts,
Solver settings, Loads etc.) are converted
to APDL commands  written as “ds.dat”
2. MAPDL is invoked in background,
consumes this "ds.dat" and writes out the
result to “file.rst”
3. Mechanical reads back the result (file.rst)
and displays contours/vectors etc.

Where ACT comes into picture:

• Mostly ACT comes into picture in step-1 and 3
• ACT comes into picture in step-2 when one
uses in-house/3rd party solver (instead of
default MAPDL)

5 © 2011 ANSYS, Inc. December 3, 2012

 ACT entry points in Mechanical (2)
How ACT affects the step-1:
• Custom loads created via ACT also need to be
translated as APDL commands to go into
“ds.dat”
– Using Python APIs, user access all the data
(geometry, mesh, other data, inputs in
custom load etc.) and generates the desired
APDL commands

• ACT provides a lot of control in accessing the

data and where the additional commands
need to go into the “ds.dat”

• This part requires knowledge of APDL

commands

6 © 2011 ANSYS, Inc. December 3, 2012

 ACT entry points in Mechanical (3)
How ACT affects the step-3:
• Once, the results are available (from file.rst),
custom result object created via ACT access
those results using ACT Python APIs
• ACT provides the mechanism to generate
scalar/vector/tensor results at
nodes/elements by using the available results

• One can use external code along with the

Python APIs, to generate required results

• APDL commands are NOT required

– Although, optionally one can use APDL
commands to generate required results
• This approach is less efficient compared
to using ACT Python APIs directly

7 © 2011 ANSYS, Inc. December 3, 2012

 ACT entry points in Mechanical (4)
How ACT affects the step-2:
• In this step, user can invoke any in-house or
3rd part solver (instead of MAPDL) for the
solution
– This step is not of any importance when one
uses the standard MAPDL solver

• One can essentially create his own input file

format (instead of "ds.dat" for MAPDL) from
the items in the tree

• ACT provides the mechanism and controls in

writing the input, invoking external solver and
reading results back

• As the solver is not MAPDL, APDL commands

are NOT required

8 © 2011 ANSYS, Inc. December 3, 2012

 What more…
Apart from the 3 steps, ACT also provides access to:

• Mechanical Graphics for

– Displaying desired information (e.g. drawing lines, surfaces, texts etc.)
– Displaying load variation (for an custom load)

• Mechanical Application for

– Invoking JScript commands for performing automation etc.
– Publishing warning/errors from ACT objects

• Workbench application for

– Access to Engineering Data
– Invoking Python commands to get data, or perform automation etc.

• External Python modules for many different purposes, e.g.

– Displaying GUI panels,
– Plotting graphs etc.

9 © 2011 ANSYS, Inc. December 3, 2012

 ACT and JScript
• Scope of ACT is NOT to replace JScript automation inside Mechanical

• ACT creates a set of new customization possibilities on top of JScript automation methods
– ACT typically adds new pre-processing and post-processing features

• JScript can leverage new features exposed via ACT

• ACT can also leverage the JScript macros for automating existing features

• Examples:
– In your workflow, you want to automatically insert a few mesh controls and already
available boundary conditions [fixed support, pressure load etc.]
• You will use JScript macros to automate [as these features already exist in standard
Mechanical]
– In your workflow, you want to expose some new type load [e.g. super-element,
acoustics loads etc.] or functionality [typically for users to use interactively]
• You will use ACT to add these features *as they don’t exist in standard Mechanical+
– In your workflow, you want to expose some new features and automate existing and
these new features
• You will use ACT to expose the new features.
• You will use JScript to automate the new and existing features

10 © 2011 ANSYS, Inc. December 3, 2012

 Typical Use Case

“Super user” develops (e.g.:

tools/methods group) an
ACT-based extension that
encapsulates expertise,
know how… and provides it
to “everyday” user for
expanded usage of
simulation within the
customer’s organization

11 © 2011 ANSYS, Inc. December 3, 2012

 ACT Components

ACT Module (the development toolkit)

• Used to create ACT-based customizations or “extensions”
• License managed (ACT license)
• Maintained and supported by ANSYS

ACT Extensions (the resulting customizations)

• What becomes visible to the end-user in the GUI (similar to UDF)
• At R14.5, created extension under binary format (no license)
• Outside of ANSYS’s standard support model
• Don't need a license (beyond the one to run ANSYS Mechanical) to run the
extensions

12 © 2011 ANSYS, Inc. December 3, 2012

 ACT Extension Development and Use
• Typically, “Super users” (e.g.: tools or methods group) need to ‘standardize a simulation
process’. This involves:
– Need to create new features (not existing in Mechanical already)
– Need to automate existing and new features in Mechanical
– Use of other Workbench capabilities such as CAD Connection, DP/DX, Meshing etc.

• Also, there is need to:

– Reduce learning curve for new engineers (not have to be APDL experts)
– Avoid a solution where user
• Can deviate from the standard process
• Or, has to change things and adapt to his/her needs
– Be able to upgrade the solution and deploy it easily
• Avoid multiple versions etc.

An ACT based customization addresses all these requirements very well.

• A “Super user” develops an ACT-based extension that encapsulates expertise, know how…
• And provides it to “everyday” user for a larger usage of simulation within the organization
A “Super user” needs ACT development module to develop extensions
The “everyday” user doesn’t need ACT development module for using the extensions
13 © 2011 ANSYS, Inc. December 3, 2012
 ACT Extension Basics
• An ACT extension consists at least of
– One XML file
• Configures the UI content
• Defines the extensions properties
• Binds application events to IronPython
script functions.
• Configures behaviors for custom loads and
results.
– One IronPython script file
• Implements the extensions functionality
• Event driven
– Functions are invoked by application generated events
• Supports access to external libraries
• The script file is typically placed in a folder named with the same name as the XML file

• One may have additional files/folders to organize the content better

– E.g. a separate folder for images, other resources etc.
• An extension can potentially be made of additional components
– E.g. external Python libraries or even C# code
14 © 2011 ANSYS, Inc. December 3, 2012
 Extensions Menu
The “Extensions” option is
available in the menu bar of
the project page
Extension Manager to Load /
Unload available extensions
Install extensions

View log file to review

messages generated Build binary extensions
from the extensions

•No additional installation is

! required for ACT module
•ACT module is installed
15 © 2011 ANSYS, Inc. December 3, 2012 along with Workbench 14.5
 ACT Extension Types
The ACT handles two different types of extensions

• Scripted extensions
– Used during the development phase
– Need the ANSYS Customization Suite license to use
– Made of .XML and IronPython functions

• Binary extensions
– Provided by the developer to the users (once the
extension is completed)
– Doesn't need a license (beyond the one to run ANSYS
Mechanical) to use
– Result of the “Build Binary Extension…” for one
scripted extension  .WBEX file
– This .WBEX [WorkBench EXtension] file is installed
from Extensions menu
16 © 2011 ANSYS, Inc. December 3, 2012
 Loading ACT extensions

• Extensions are loaded with an application if they are pre-selected in the Workbench
Extension Manager tool

• This pre-selection is done automatically for extensions that were loaded and saved
with the project

Extensions are listed by type: binary or scripted

17 © 2011 ANSYS, Inc. December 3, 2012

 Install Binary Extension

Extension gets installed in the current user’s Application Data (%appdata%) folder
Installation also creates a new folder in addition to the WBEX file

Both the folder and the WBEX file are necessary for the extension to work
Don’t keep the same extension as both script and binary form
! – Only one will be loaded based on the path priority
18 © 2011 ANSYS, Inc. December 3, 2012
 Building Binary Extension

A binary format extension is not be readable by any other user

The resulted .WBEX file contains all the necessary files/directories of the extension

19 © 2011 ANSYS, Inc. December 3, 2012

 Building Binary ACT extensions
• Three security levels are available:
– 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.
– 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.
– 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.

Note: These security options only apply if the user wants to save the
extension with the project, and are otherwise not applicable.

20 © 2011 ANSYS, Inc. December 3, 2012

 Extensions Options

Automatically load the specified

extensions each time ANSYS
Workbench is launched
Define additional folders in which
ACT will search for extensions in Reloads the extension
order to expose them in the and updates Mechanical
Extension Manager (without having to close it
Exposes two additional features in and reopen)
Mechanical to help debug the
extension under development Opens the ACT log file
21 © 2011 ANSYS, Inc. December 3, 2012
 Demo
• Enable/Disable extension

• Extension information is stored in the Project

• File/Folder structure of an example extension

22 © 2011 ANSYS, Inc. December 3, 2012

 An example ACT extension

The <extension> element contains the version

and name attributes for this extension

The <script> element contains the src attribute.

Defines the path to the iron python script file.
<interface>
expanded <interface> is the parent element for custom UI
controls It contains the application’s context
attribute.

The <images> element value defines the location

of icon files used for UI customizations

The <callbacks> element is parent to

event/function mapping elements

The <toolbar> element defines a toolbar and its

properties
23 © 2011 ANSYS, Inc. December 3, 2012
 An example ACT extension (2)

The <oninit> element has a Python function

The <callbacks> element is parent to
name to be called when the interface is initialized
event/function mapping nodes

The <toolbar> element defines a toolbar and its The <entry> element defines a toolbar button
properties and its properties

The <onclick> element has a Python function

name to be called when this button is clicked
24 © 2011 ANSYS, Inc. December 3, 2012
 An example ACT extension (3)

25 © 2011 ANSYS, Inc. December 3, 2012

 Demo

• Build a binary extension

• Installing a binary extension from WB Project page

26 © 2011 ANSYS, Inc. December 3, 2012

 Q/A

27 © 2011 ANSYS, Inc. December 3, 2012