Node Interaction in Mechanical, Part 3: Nodal Boundary Conditions

This article is Part three in a four-part series about taking advantage of the new nodal interaction capabilities in Workbench 14.0. In Part 1 I discussed how to pick nodes and retrieve information about them. In Part 2 I covered various methods of creating nodal Named Selections. In this installment I’ll address the procedures for applying loads and constraints to mesh nodes, as well as rotating them into different coordinate systems.

All of the nodal boundary conditions, including nodal rotations (which I realize isn’t a boundary condition, per se, but it does affect how boundary conditions are applied) may be found in the Direct FE pull-down menu when the Analysis branch is highlighted.


One key thing to note about all of the nodal boundary conditions is that they may only be scoped to Named Selections, not Geometry Selection. So before you continue, make sure you’re well versed in nodal Named Selection creation.

Stepping through the Direct FE commands in menu order, the first item we come to is Nodal Orientation. This is how we rotate a node to another coordinate system. Of course, to be able to reorient a node to another coordinate system, we will have to create one first. Once that’s done, select Nodal Orientation from the Direct FE pull-down menu.

In this case, we will rotate the nodes belonging to the named selection EndNodes to a cylindrical coordinate system I created at the end of the tube called Cylindrical Coordinate System (because I’m original like that).


Click Direct FE > Nodal Orientation. In the Details window set the Named Selection to EndNodes and Coordinate System to Cylindrical Coordinate System. Easy peasy. Note that the Scoping Method cell is grayed in with “Named Selection,” indicating that you can’t change it.


Just as in Mechanical APDL, all forces and constraints are applied in the nodal coordinate system, defined by the Nodal Orientation. In this example, I applied FE Displacement constraints in the X (radial) direction and Nodal Forces in the Y (theta) direction and verified them in Mechanical APDL.


One thing to keep in mind is that Nodal Orientation is rarely necessary, since loads and constraints applied to solid model entities may be applied in user defined coordinate systems and Frictionless Supports rotate nodes to be normal to the surface.

Moving along, for the Nodal Force example we will apply a downward force to the 12 nodes contained in the Named Selection EndFaceNodes.


Following a similar procedure as before, click Direct FE > Nodal Forces. Set the Named Selection to EndFaceNodes and enter –1200 lbf for the Y Component of force. Note that Nodal Coordinate System is set in gray for the Coordinate System selection. The key item to note, however, is the Divide Load by Nodes option. If set to Yes, the load will be split evenly between the nodes, in this case 1200 lbf/12 or 100 lbf per node, for a total of 1200 lbf applied. If set to No, the full load is applied to each node in the Named Selection, giving a total applied load of 1200 lbf x 12 = 14,400 lbf total.


Here are the Probes of the Reaction Loads with the Divide Load by Nodes option set to Yes and No.

Divide Load by Nodes = Yes


Divide Load by Nodes = No


To applied pressures to nodes, click Direct FE > Nodal Pressure and specify the Named Selection and pressure value. Note that the pressure can only be applied in the normal direction to nodes. Also note that, at a minimum, the nodal Named Selection has to consist of all the corners on an element face for the pressure to have any meaning.



Apply constraints directly to nodes by clicking Direct FE > FE Displacement. Specify the Named Selection and enter the displacement values in the nodal coordinate system X, Y, and Z direction (or leave Free).


Nodal rotations (Direct FE > FE Rotation) may only be applied to nodes attached to elements with rotational degrees of freedom, such as beams and shells. The rotations themselves can only be fixed (i.e. zero degrees) or free. At this time there is no capability to impose a finite nodal rotation.


In the next and final installment, I will discuss how to scope results to nodes and verify nodal and element orientations. Get ready to be thrilled.

Node Interaction in Mechanical, Part 2: Nodal Named Selections

This is the second entry in a thrilling saga about interacting with nodes in ANSYS Mechanical. In Part 1, I addressed the various methods for picking and querying nodes in a Mechanical model. In this entry, I discuss various methods for creating nodal Named Selections. Creating nodal Named Selections is a key step in executing the processes I’ll address in my next two entries: Applying nodal boundary conditions and scoping results to nodes.

I’ll start with the easy stuff. To create a Named Selection from picked nodes, simply pick the nodes you’re interested in as described in Part 1, right-click, and select Create Named Selection (or, in the Named Selection toolbar, click the Create Named Selection) and give it a name.


Note that the “Apply geometry items of same:” option does not work with nodes yet. However, there is another option: The Worksheet. The worksheet will allow you to define nodes based on location, node number, and attachment to solid model entities.

To activate the Worksheet mode, highlight the Named Selection branch (add it from the Model toolbar if necessary) and insert a new Named Selection. In the details window, change the Scoping Method from Geometry Selection to Worksheet.


The Selection worksheet appears.


To begin the selection process, right click on the first row and select Add Row.



The Add action is similar to selecting “from full” or “also select” in Mechanical APDL and is most likely the first action you will take in the selection process. Select Mesh Node from the pull-down menu under Entity Type.


For the criterion, select either Location X, Y, or Z or Node ID (node number).


Then select the appropriate Operator from the pull-down menu. Available options for both Location and Node ID are Equal, Not Equal, Less Than, Less Than or Equal, Greater Than, Greater Than or Equal, and Range. Options for Location additionally include Smallest and Largest.


Next, fill in the Value, Lower Bound, and/or Upper bound as appropriate. Also select the appropriate coordinate system when using one of the Location criteria.


When complete, click the Generate button to execute. The Geometry entry in the details will indicate the number of selected nodes. Click on the Graphics tab to verify the selection.



If desired, add additional selection actions. The Add action at this point behaves as “also select.” Remove behaves as “unselect.” Filter acts as a “reselect” operation. In this example, we will Filter the selection to nodes between Y = 0 and Y = 2.5 inches. (I also could’ve simply done Y > 0, but I wanted to show the Range Operator here.)



At this point, you’ve probably noticed that the Named Selection is named “Selection.” Simply rename it by right clicking on the Selection object and selecting Rename.

So now you know how to create nodal Named Selections based on location and node number, but how do you create a named selection from nodes attached to a face or some other solid model entity. That’s a little more complicated, but I’m here to take you through it. It’s not really difficult once you know the steps.

First, create a Named Selection from the geometric entities containing the nodes you want to select.


Then create a new Named Selection with the Worksheet scoping method. In the first row set Add as the Action. Set the entity type equal to the entity type the Named Selection was created from in the previous step. Set the Criterion to Named Selection and the Operator to Equal. Select the Named Selection created in the previous step from the pull-down menu under Value.


“Criminy, Strain! We’re just selecting the same Named Selection that we create in the previous step! What’s the point?! You’re wasting my time!” Read on; there’s another step here.

Add another row to the Worksheet. Set the Action to Convert to and the Entity Type to Mesh Node. Then click Generate and verify the selection in the graphics window. There, don’t you feel silly for getting so upset in the previous paragraph?



In these first couple of parts, we’ve spent a lot of time learning how to simply select the nodes. Now wouldn’t it be nice to actually do something with them? In the next two parts, we’ll do exactly that. First, we’ll see how to apply loads and constraints directly to nodes, and rotate them into different coordinate systems. For the last installment, we’ll discuss how to scope results to nodes.

Webinar Files: Moisture Diffusion Modeling with ANSYS at R14 and Beyond

On May 24, 2012 Matt Sutton gave a well attended webinar on the new moisture diffusion modeling capabilities in ANSYS Mechanical APDL at R14.


Although we didn’t get a successful recording for this one (Matt has been chastised and done his penance for forgetting to turn on the recording…) we do have a PDF of the PowerPoint and a copy of the sample macro he used:

Node Interaction in Mechanical, Part 1: Picking Your Nodes

NosePicking1In version 14.0 of ANSYS Mechanical, ANSYS has rolled out its first capabilities for interacting with the underlying finite element model in addition to the geometry. In this version, the user can select nodes, create named selections from nodes, apply loads and constraints to nodes, and scope results to nodes. And it is glorious. In this posting, the first part in a four-part series on interacting with nodes in Mechanical, I will start of with the basics: selecting nodes in ANSYS Mechanical.

The default picking mode in Mechanical is to Select Geometry. In order to select nodes you will first need to display the mesh by either highlighting the Mesh branch or by clicking the Show Mesh (image) button. Next, switch the select mode to Select Mesh under the Select Type pull-down.


At this point you will be able to pick nodes in the same manner that you pick vertices. Note that the entity filter is automatically set to Vertex when you’re in Select Mesh mode, so you may need to reset the filter once you go back to Select Geometry mode.


You can also box select or lasso select nodes under the Select Mode pull-down. Note that there are two options for each: plain ol’ box and lasso select, and box and lasso volume select.


I’ve found that volume select vs. regular select is best illustrated using flat surfaces, so here we go: an example with flat surfaces.


Regular box or lasso select only selects nodes on the faces closest to the viewer.



Note: To lasso select, simply click and drag the cursor around in a loop.

On the other hand, volume select selects all the nodes throughout the depth of the model.



A related question that has come up when I demonstrate the new nodal interaction capabilities is, “Node numbers! Where are my node numbers? I want to see node numbers! Give me my node numbers!” OK, you can view node numbers now. (You can also view information about other entities, but this is a blog post about nodes, so I’m going to talk about nodes.) To view node information, first make sure you’re in node-picking mode, select the nodes of interest, and then click on the toolbar button featuring the blue ‘i’ with a black arrow next to it.  image (You can also do this in reverse order. Whatever floats your boat.) When you do this, the Selection Information will display the node X, Y, and Z location and Node ID in the lower left corner of the GUI.


If you had picked two nodes, it would also show the distance between those nodes. You can customize the display by clicking the green check box, though you probably won’t want to change anything with the node display.

In the next installment I will show you how to create nodal Named Selections starting with simple picking and moving on to such criteria as location, node number range, and nodes attached to solid model entities. This knowledge will come in handy for applying boundary conditions to nodes and scoping results to them, which I’ll cover in the third and fourth installments. Happy node picking!

Coordinating Coordinate Systems in ANSYS Mechanical

Coordinate systems are one of those things that are fundamental to Finite Element Analysis, but that most of us do not think about a lot.  They are there, but some users never fiddle with them. And some users are constantly futzing around with them.  We thought it would be a good idea to do a quick review of how they work in ANSYS Mechanical.  We will also go over the basics for  Mechanical APDL (MADL) in case you need to work with snippets.

Why Coordinate Systems Matter

ANSYS cares a lot about coordinate systems because they allow the program to solve in a standard, global, Cartesian system while allowing loads, constraints, material directions, layer information, beam sections, joints, result values, and a whole slew of other important aspects of the model to be specified in unique coordinate systems. This avoids making the user do coordinate system transformations.  At solve time, everything gets converted.

Since everyone reading this is an engineer, I’m going to assume that everyone already knows what a coordinate system is.

Coordinate Systems in DesignModeler and CAD Tools

It is important to start at the beginning.  Design Modeler and all CAD packages I’m aware of allow you to define some sort of coordinate system. Usually just Cartesian.  In workbench you can import those coordinate systems into ANSYS Mechanical by clicking “Import Coordinate Systems” from the “Advanced Geometry Options” properties for the Geometry cell in you systems.

For DesignModeler, there is an extra step.  Even if you turn on the import properties you need to dell DM which coordinate systems you want imported.  But first, be aware that there is no “coordinate system” entity in DM.  Instead it has planes, which is a coordinate system where you draw on the Z-normal plane. 

To make these available in ANSYS Mechanical, you need to scroll down to the bottom of the details for the planes you want converted over to coordinate systems, and set “Export Coordinate System” to Yes.

The following three images show setting it in DM, setting the property on the Project page, and how it shows up in Mechanical:

image  image  image

Creating Coordinate Systems in ANSYS Mechanical

In ANSYS Mechanical, coordinate systems reside in the Model Tree between Geometry and Connections.  Once you define a coordinate system it becomes available for use with any other object that can use a coordinate system.  This allows you to define it once, and then use it many times.

You always get a Global Cartesian coordinate system, called Global Coordinate System.  It is Cartesian, has an ID of 0, and sits at 0,0,0.  You can not change any of these values. Any imported coordinate systems will show up underneath the global.

To create a coordinate system you Right Mouse Button (RMB) on the Coordinate Systems branch and Insert->Coordinate System.  Or, when you click on the branch you also get a Coordinate System toolbar:


Click on the three color triad icon and a new system will be inserted.

Let’s look at each of the options in the details view.  But note before you go there, that the first set of group define a starting location and orientation, then you apply transformations in the last detail group in order to modify those locations.

  • Definition Group: This group specifies the type and MAPDL number for the Coordinate System
    • Type:  You can have the default Cartesian or Cylindrical here. The resulting coordinate system triads show up on your model like so.  As you can see, Z is the rotational axis, Y is tangential an X is radial.
      image   image
    • Coordinate System: In my opinion this should say Coordinate System ID because this detail lets you decide if you want ANSYS Mechanical to assign the number that MAPDL will use, or if you will.  Program Controlled is the default and is fine in most cases.  If you need to wrote a snippet to work with a coordinate system then you should change it to “Manual” and Coordinate System ID will show up.  Set it to any number over 11.


  • Origin Group:  This group defines where the center of the coordinate system is.
    • Define By:  You can specify a Geometry Selection or Global Coordinates. 
      • Geometry Selection: The cool thing about using Geometry Selection is that as you update your CAD model, the origin will shift with it.  As with any geometry specification, you click on a surface, line, vertex or a collection of these.  Mechanical will calculate the geometric center of the entity of entities that you picked and place the origin at that centroid.  It will also shows the position in the global coordinate system below your geometry selection, but you can not change them.
      • Global Coordinates: Here you simply put in an X, Y, and Z value in one of two ways. The easiest is to just type them in.  Or, you click “Click to Change” for Location and pick the coordinate picker image icon and move your mouse over your model.  Mechanical calculates the point under the cursor (surface closest to camera) and displays it. When you click it will create a little blue cross on the geometry.  Choose apply on Location an it will enter that point in as the origin.  Kind of cool, if a bit inaccurate…
  • Principal Axis Group: You need to tell Mechanical how to orient the coordinate system. By default it will align with the global.  But you can use Axis and Define By to specify that any of the three axis are aligned with a global axis, or with a piece of geometry.  Aligning with geometry is very useful because this is how you get coordinate systems aligned with your geometry. And when your geometry updates, that coordinate system aligns with the updated geometry.  This is especially useful when specifying a coordinate system in a cylinder because you can pick the cylinder face for your Z axis and it will move with the cylinder.
    Note that you can not specify align with Global –Z. If you want to do that you need to align with Z and use the transformation below to flip that.
    One option for “Define By” is “Fixed Vector” This uses the current orientation but disassociates it from the geometry.
  • Orientation about Principal Axis Group:  One point and a vector does not a coordinate system define. You have to specify an orientation around that principal axis.  You do that just like the how you specify that principal axis.  Define a global X, Y, or Z or a piece of geometry.
  • Direction Vectors Group:  These show the vectors for X, Y, and Z.  You can’t change them (I wish you could) and they are not a parameter. But they are useful.
  • Transformations Group:  This area allows you to stack offsets, rotations, and mirrors.
    You use the Coordinate System Toolbar to insert transformations into this group.  They are executed in order from top to bottom and the resulting orientation and position are shown in Directional Vectors and Transformed Configuration.
    There is a “Move Transform Up” and “Move Transform Down” icon as well in the toolbar to move the transformations around. There is also a delete to remove one.
    Note: When you click on a transformation in the list, the coordinate system on your model is shown AT THAT STEP, not at the final position.  This always confuses me.  So make your change, then click on the last step to see it.

Using Coordinate Systems

This is the easiest part. You simply choose one of your defined coordinate systems from a dropdown list when you create an object that is dependent on a coordinate system.  Usually this is when you can define a value based Components rather than on geometry:



Do note that you can also use coordinate systems to transform directional result values.  Simply pick the Coordinate system from the dropdown list.  This is especially important when looking at hoop or radial stresses in a cylindrical part.

Coordinate Systems in ANSYS Mechanical APDL

Coordinate systems are huge in MAPDL.  Nodes have them, elements have them, sections have them. Plus you can make a coordinate system active and every command you execute is done in that active coordinate system, and converted for you to the global. Very powerful.

If you do a search in help on “Coordinate System” you get hundreds of hits in the MAPDL manual.  Way too much to go over here.  We do recommend that you start with:

Mechanical APDL // Modeling and Meshing Guide // 3. Coordinate Systems // 3.1. Global and Local Coordinate Systems

It explains the types, the math, and the commands needed.  Read that, then move on to 3.3, 3.4, and 3.5 which talk about nodal, element and result coordinate systems.

Some key things every user should know are:

  1. All coordinate systems are defined by a number.  0-10 are reserved by MAPDL for its use.  Users can do 11 or higher.
  2. MAPDL has 6 default coordinate systems:image
    0 = Cartesian
    1 is cylindrical down the Z axis
    2 is Spherical
    4 is Cartesian, same as 0
    5 is Cylindrical down the Y axis.
    6 is Cylindrical down the X axis (not shown)
    I have no idea what happened to 3 or why 4 is the same as 0.
  3. When you change the active coordinate system with CSYS, all commands that involve coordinates get transformed into that coordinate system.  So:
    Actually makes a node at 12.5,9.8481,1.7365 in the global coordinate system.
  4. You can show local coordinate system with /psymb,csys,1


  5. You can list your coordinate system definitions with CSLIST:


  6. Only Cartesian and cylindrical are supported in ANSYS Mechanical, so if you need to use spherical or Toroidal you need to use snippets


Make sure you understand how Mechanical is using coordinate systems by bringing your models up in MAPDL.  Look at your nodes and see if they are rotated and how.  Check the coordinate systems with a CSLIST. Make sure you feel comfortable, don’t take it for granted.

Writing Text files with *VWRITE

A very common need in the world of ANSYS FEA simulation is to write text to a text file from within Mechanical APDL. Sometimes you are running in MAPDL, sometimes you are using ANSYS Mechanical but you still need to write stuff out using APDL with a code snippet. The way most people do that is with *VWRITE. 

Originally written to write out data in arrays, it is a very flexible and powerful command that can be used to write pretty much any type of formatted output. Something that every ANSYS user should have in their back pocket.

The Command

*VWRITE, Par1, Par2, Par3, Par4, Par5, Par6, Par7, Par8, Par9, Par10, Par11, Par12, Par13, Par14, Par15, Par16, Par17, Par18, Par19

Looks pretty simple right, just *vwrite and list what you want printed. But there is a lot more to this command.

A Lot More

First off you need to open up a file to write to.  You have a couple of options.

  1. *CFOPEN,fname, ext, –, Loc
    This opens the specified file for writing with *cfwrite and *vwrite commands.  This is the preferred method.
  2. /output,fname, ext, –, Loc
    By default *VWRITE output to standard output – the jobname.out (batch) file or the command window (interactive). So if you use /output you can redirect to a file instead of the *.out or screen.  We don’t recommend this because other stuff might get written as well to the file.

Now you have a place to write to, next you need to use *VWRITE to write. *VWRITE is a unique command because it actually uses two lines.  The first contains *VWRITE and a list of parameters and/or arrays to write and the second contains a format statement.  We will cover the first line first, and the format second.

Parameter Arguments for *VWRITE

As you can see from the command, you can have up to 19 parameters listed on a *VWRITE command.  PAR1 through PAR19 can be array, scalar, or character parameters. They can also be a constant. This is where the real flexibility comes in.  You can do something like (just look at the *VWRITE line, we will talk about the rest further on):

   1: adiv = ' | '

   2: *dim,nds, ,10

   3: *dim,temps,,10

   4: *vfill,nds(1),ramp,1,1

   5: *vfill,temps(1),rand,70,1500

   6: *cfopen,vw1.out

   7: *VWRITE,'Temp: ',nds(1),temps(1),adiv, 'TREF: ',70

   8: (A6,F8.0,g16.8,A3,A6,F10.4)

   9: *cfclose

This mixes characters, arrays, and constants in one command.  As output you get:

Temp:       1.   429.56308     | TREF:    70.0000
Temp: 2. 263.55403 | TREF: 70.0000
Temp: 3. 1482.8411 | TREF: 70.0000
Temp: 4. 605.95819 | TREF: 70.0000
Temp: 5. 782.33391 | TREF: 70.0000
Temp: 6. 1301.1332 | TREF: 70.0000
Temp: 7. 1119.4253 | TREF: 70.0000
Temp: 8. 202.87298 | TREF: 70.0000
Temp: 9. 1053.4121 | TREF: 70.0000
Temp: 10. 805.71033 | TREF: 70.0000

Array Parameters

The first thing you will notice is no *do loop.  If you supply an array parameter, *vwrite loops on the parameter from the given index (1 in this case) to the end of the array.  But if you don’t want the whole array written, you can control by placing *VLEN and/or *VMASK in front of the *VWRITE command:

  • *VLEN,nrow,ninc
    This will only write out nrow times, skipping based on ninc (defaults to 1)
    • As an example, if you want to write just the fourth value in array A() you would do:
  • *VMASK,Par
    You make a mask array of 0’s and 1 that is the same size as your array, and supply it to *VMASK.  *VWRITE will only write out values for your array if the mask array is not zero for the same index.

You can have a multiple dimensions on your array. *VWRITE only increments the first index. Say you specify X, Y, and Z coordinates in an array call xyz.  It would look like:


String Parameters

Being an older program, you are limited in what you can do with character parameters.  You are limited to 8 characters. So you just use a long string parameter several times and increment the index by 8:

   1: *dim,mystring,string,80

   2: mystring(1) = 'This is a very long sentance'

   3: *cfopen,vw2.out

   4: *VWRITE,mystring(1), mystring(9), mystring(17), mystring(25), mystring(33)

   5: (5A) 

   6: *cfclose

Kind of hokey, but it works.


Sigh.  This is the one thing that I’m not fond of in *VWRITE. The original command did not support outputting integer values.  That is because the FORTRAN I descriptor was not supported, and ANSYS stores everything as an integer anyhow. But people needed to output integer values so they took the ‘C’ format routines for *MSG and made them work with *VWRITE. So you can do a %I.  See the section on ‘C’ formatting below for more information on this.

Close the File

Before you can do anything with the file you create you need to close it.  Not to hard: *CFCLOSE does the trick.

Other Stuff you Need to Know

Don’t put a blank in there.  If you do, *vwrite stops looking at parameters.  So if you need a blank in your file, put in a space ‘ ‘ or use the X FORTRAN descriptor.

Be aware of *CFWRITE as well.  It is a way to write APDL commands to a file. If what you want to do is have your macro write a macro, *CFWRITE is better because you don’t have to do format statements. And those can be a pain when you need commas.

If your arrays are of different lengths, *VWRITE will loop for the length of the longest array. Any shorter arrays will be replaced with zeros for number arrays and blanks for character/string arrays.

You can not use *VWRITE by pasting or typing into the command line.  You have to read it from a file.


The key, and the difficult part of using *VWRITE is the format statement. We recommend that you use the FORTRAN formatting when you are writing out large amounts of columnar data, and use the ‘C’ format if you are writing out text rich information for a report or to inform the user of something.

Many users today may not even know what a FORTRAN statement looks like.  A good place to look is:

Just remember that you can’t use the Integer (I) format.  The list directed format (*) also does not work.  If you are new to it also remember everything goes in parenthesis and it has to fit on one line.  It does not have to start in column 8 (if you think that is funny, you are old)

As to ‘C’ formatting, you have a lot more options but we have found that the behavior is not as consistent between Linux and windows as the FORTRAN.  But if you are more comfortable with ‘C’, do that. Not all of ‘C’ formatting works in APDL, but what does is actually documented under the *MSG command. 

Making it Work

We always recommend you work out your *VWRITE issues in a small macro that you can run over and over again as you work out the formatting.  If you are writing a snippet for ANSYS Mechanical. Go ahead and save your model, bring it up in MAPDL, then work on your *VWRITE statement till you get it right.

Some other useful suggestions are:

  • Keep things simple. Don’t try and format a novel or an HTML page with *VWRITE.  You probably could, but there are better tools for that.
  • Make sure you understand arrays, how they work in APDL, and how you have yours dimensioned.
  • Get familiar with *VMASK and *VLEN. They are useful

Turning on Beta Features in Workbench

It is a busy week and I’m in between meetings for about 30 minutes, just enough time for a very short Focus posting for the week.  So, I thought I would share something I had to remember for the first time in a long time: How to access beta features in ANSYS Workbench.

First off a word of warning:  Beta features are beta features. They are capabilities in the software that have either not finished testing, are not fully documented, or that have a known issue.  They therefore must be used AT YOUR OWN RISK!!!!   If you find a bug or a problem, report it to your technical support provider, they need that feedback. But don’t call up indignant because it is not working the way you want it, or because the documentation is non-existent.  It is a beta feature.

Set the Option

Not too difficult.  From the Project Schematic page go to the tools menu and select Options.


Now in the Options dialog click on Appearance in the tree on the left.  You will not see Beta Options.  Scroll down and near the bottom there are a bunch of check boxes. Check “Beta Options”image

Now, in your project toolbar you should see (Beta) next to the exposed beta functions:


This will also impact any beta features, if any, in the workbench native applications:  Parameter manager, Engineering Data, or DesignXplorer.

That is it. I promised short.  Off to another meeting.


Webinar Information: Constraint Equation Primer

Here are the files from the webinar held on Friday, April 27, 2012: A Constraint Equation Primer: How to Tie Degrees of Freedom Together


Link to webinar recording:

No models or anything on this one.

To GPU or Not, This is No Longer The Question…

imageExecutive Summary

Without losing you quickly due to fabulous marketing and product information. I thought it prudent if I get to the answer of my question as quickly as possible. What was the question? Should I invest in a companion processor and an ANSYS HPC Pack? Yes, now is the time.

  • If your current workstation is beginning to show its age and you are unable to purchase new hardware.
  • Get your critical results fast. It is painful waiting upwards of 50 hours for your solution to solve.
  • Assign a dollar value to your current frustration level.
  • Current pricing for Nvidia TESLA C2075 is around $2500. Current pricing for the NVidia Quadro 6000 is around $5,000.

“Keeping It Real”

Matt Sutton our Lead Software Development Engineer at PADT, Inc. was solving a very large ANSYS MAPDL acoustic ultrasound wave propagation model. The model labored over 12 hours to solve on Matt’s older Dell Precision 690 8 core workstation. We loaded the model onto our CUBE HVPC w8i with the NVidia Tesla C2075 and it solved the model in 50 minutes. That is a 15x speedup for Matt’s particular model!



I started off with our benchmark assault using an industry standard ANSYS benchmark for HPC. This is a benchmark that NVidia requested we use for testing our TESLA C2075. The next benchmark that I used was an internal PADT, Inc. modal coupler benchmark.

Nvidia V14sp-5 ANSYS R14 Benchmark Matrix (Sparse solver, 2100k)


CUBE HVPC – w12a-GPU – 64GB







Config A: Win v14 SMP In-Core

Config A: Win v14 SMP In-Core & GPU

Config A: Win v14 DIST In-Core

Config A: Win v14 DIST & GPU

Config A: Linux v14 SMP In-Core

Config A: Linux v14 SMP In-Core & GPU

Config A: Linux v14 DIST In-Core

Config A: Linux v14 DIST & GPU



  2 1388.20 463.40 1425.50 294.40 1324.40 466.30 1312.30 292.10      
  4 870.00 447.20 855.00 232.40 817.00 422.00 975.40 221.80      
  6 670.60 440.20 588.00 245.10 625.50 394.00 601.60 208.10      
  8 594.30 439.10 605.00 222.00 480.10 383.90 542.30 181.10      
  10 539.50 426.90 435.00 283.40 491.30 392.80 396.90 220.80      
  12 538.40 437.10 402.20 211.10 480.10 394.80 343.80 183.10     2x
CUBE HVPC – w8i-GPU – 64GB CONFIG B                
64GB # Cores Config B: Win v14 SMP In-Core Config B: Win v14 SMP In-Core & GPU Config B: Win v14 DIST In-Core Config B: Win v14 DIST & GPU Config B: Linux v14 SMP In-Core Config B: Linux v14 SMP In-Core & GPU Config B: Linux v14 DIST In-Core Config B: Linux v14 DIST & GPU      
  2 1078.50 361.00 1111.90 235.70 1036.00 350.20 1072.90 250.60      
  4 645.50 330.70 652.30 185.50 608.10 312.00 790.90 193.20      
  6 494.30 322.70 458.30 233.70 464.90 303.20 502.70 178.70      
  8 438.50 328.30 462.20 230.40 406.10 304.80 451.20 166.00     2.5x
CUBE HVPC – w16i-GPU – 128GB


128 GB # Cores Config C: Linux v14 SMP In-Core & GPU Config C: Linux v14 DIST & GPU                  
  2 296.6 208.10                  
  4 254.4 160.70                  
  6 254.2 164.20                  
  8 239.9 138.20                  
  10 238.6 159.70                  
  12 246.3 129.60                  
  14 237.6 129.1                  
  16 248.9 130.5                  


CUBE HVPC – PADT, Inc. – Coupling Modal Benchmark (PCG solver, ~1 Million DOF, 50 modes)



ANSYS 13.0

Shared Memory Parallel INTEL XEON 2×6 @3.47GHz /144GB of RAM w12i-GPU
  Processors Time Spent Computing Solution (secs) Date/Individuals Initials:
  2 5416.4 11/7/2011 – DRJM
  10+GPU 1914.2 (incore) 11/8/2011 – DRJM
  12+GPU 1946 (incore) 11/8/2011 – DRJM



Shared Memory Parallel INTEL XEON 2×4 @2.8GHz /64GB of RAM w8i-GPU
  6+GPU 3659.4 (out of core) 4/11/12 – DRJM
  8+GPU 3686.7 (out of core) 4/11/12 – DRJM



Shared Memory Parallel INTEL XEON e5-2690 2×8 @2.9GHz /128GB of RAM W16i-GPU
  14+GPU 2113 (incore) 4/18/12 – DRJM
  16+GPU 1533.9 (incore) 4/18/12 – DRJM



Summary, Debates, Controversy & Conclusions

One question that I hear often is this: “What operating systems is faster. Linux or Windows?”. My typical response will begin with “Well, it depends…” However, what the data illustrates with the two independent CPU workstations as well as Operating Systems. The ANSYS benchmarks were all performed in the same relative time frame. The only exception was the ANSYS modal analysis benchmark.

Are you ready for the answer? Here it is…yes Linux is faster than windows! Even if you come from the AMD CPU or INTEL CPU side of the tracks. Linux is faster! No big discovery right? I know we all knew this already but we were maybe afraid to ask by Operating system as well as CPU manufacture how much? Well with our 2.1 million degree of freedom Nvidia benchmark. Ummm, not very much as the data clearly indicates. However once again, the Linux based OS does give you a system performance advantage! If you use AMD or INTEL it is still faster. The next question that I hear next is: “What processor is faster AMD or INTEL?”. My typical response will begin with “Well, it depends…”

You did buy the NVidia TESLA C2075 GPU, okay this is great news! However, you figured it best that you keep it safe, stay the same, and continue to use Shared Memory Parallel solve method. As you ponder further on the speed up values. You will see once again that the best results are going to be found on the Linux Operating System and when you choose to solve in Distributed Memory Parallel mode. The AMD based CPU had the best speedup values when comparing the workstation against the two solve modes with a 2.2x’s speed up.

Lets begin to unpack this data even more and see if you can come up with your own judgments. This is where things might start to get controversial…so hang on.

Windows, Linux, AMD or INTEL

Time Spent Computing The Solution

  • ANSYS R14 Distributed Memory Parallel Results: (Incore)
    • LINUX 64-bit:
      • One minute forty-seven seconds faster on 2x AMD CPU (343.80 seconds vs. 451.20 seconds)
    • Windows 7 Professional 64-bit:
      • One minute faster on 2x AMD CPU (402.20 seconds vs. 462.20 seconds).
  • ANSYS R14 Shared Memory Parallel Results: (Incore)
    • LINUX 64-bit
      • One minute fourteen seconds faster on 2x INTEL XEON CPU (406.10 seconds vs. 480.10 seconds)
    • Windows 7 Professional 64-bit is sixty seconds faster solve time on AMD based CPU
      • One minute forty seconds faster on 2x INTEL XEON CPU (438.50 vs. 538.40 seconds)

The Nvidia TESLA C2075 GPU and ANSYS R14 – GPU to the rescue!

  • ANSYS R14 Distributed Memory Parallel with Nvidia TESLA C2075 GPU Assist Results
    • LINUX 64-bit:
      • Seventeen seconds faster on 2x INTEL XEON CPU (166 seconds vs. 183.10 seconds)
      • 129.1 seconds was the fastest overall solve time achieved for any operating system on this benchmark!
      • 2 x INTEL XEON E5-2690 – fourteen cores with ANSYS R14 DMP w/GPU assist
    • Windows 7 Professional 64-bit:
      • Nineteen seconds faster on 2x AMD CPU (211.10 seconds vs. 230.40 seconds).
      • 211 seconds was the fastest solve time achieved using Windows for this benchmark!
      • 2 x INTEL XEON X5560 – eight cores with ANSYS R14 DMP w/GPU assist
  • ANSYS R14 Shared Memory Parallel with Nvidia TESLA C2075 GPU Assist Results
    • LINUX 64-bit:
      • Seventeen seconds faster on 2x INTEL XEON CPU (166 seconds vs. 183.10 seconds)
      • Config C: 237.6 seconds was the fastest overall solve time achieved for any operating system on this benchmark!
      • 2 x INTEL XEON E5-2690 – fourteen cores with ANSYS R14 SMP w/GPU assist
    • Windows 7 Professional 64-bit:
      • Nineteen seconds faster on 2x AMD CPU (211.10 seconds vs. 230.40 seconds).
      • 211 seconds was the fastest solve time achieved using Windows for this benchmark!
      • 2 x INTEL XEON X5560 – eight cores with ANSYS R14 SMP w/GPU assist

ANSYS R14 Distributed Memory Parallel with GPU vs. ANSYS R14 Shared Memory Parallel with GPU speed up results:

Distributed Memory Parallel (DMP) or Shared Memory Parallel (SMP)

  • 2 x AMD Opteron 4184 based workstation vs. “DMP or SMP”
    • 2.2x’s speedup on Linux Operating System (183.10 seconds vs. 394.80 seconds)
    • 2x’s speedup on Windows Operating System (211.10 seconds vs. 437.10 seconds)
  • 2 x INTEL XEON E5-2690 based CPU vs. “DMP or SMP”
    • 1.9x’s speedup on Linux Operating System (129.41 seconds vs. 237.6 seconds)

With or Without GPU? ANSYS R14 Distributed Memory Parallel speed up results

Distributed Memory Parallel (DMP) with GPU vs. Distributed Memory Parallel without GPU

  • AMD Opteron 4184 based workstation
    • 2x’s speedup Linux Operating System (183.10 seconds vs. 343.80 seconds)
    • 2x’s speedup on Windows Operating System (211.10 seconds vs. 402.2 seconds)
  • INTEL XEON x5560 based workstation
    • 2.5x’s speedup on Linux Operating System (166 seconds vs. 451.20 seconds)
    • 1.4x’s speedup on Windows Operating System (230.40 seconds vs. 462.20 seconds)

Some Notes:

  • ANSYS Base License – unlocks up to 2 CPU Cores
  • ANSYS HPC Pack – unlocks up to 8 CPU Cores and GPU
  • The total amount of system RAM you have affects your Distributed solve times. A minimum of 48GB of RAM is recommended.
  • The processing speed of your CPU affects your Shared Memory Parallel solve times.
  • Model limits for direct will depend on largest front sizes
    • 6M DOF for 6GB Tesla C2075 and Quadro 6000
  • Model limits for iterative PCG and JCG
    • 3M DOF for 6GB Tesla C2075 and Quadro 6000



Hardware Specs of Workstations:


The AMD® based CUBE HVPC w12a FEA Simulation Workstation:

  • CPU: 2x AMD Opteron 4184 (2.8GHz Ghz 6 core)
  • GPU: NVIDIA TESLA C2075 Companion Processor
  • RAM: 64GB DDR3 1333Mhz ECC
  • HDD: (os and apps): 450GB WD Velociraptor 10k
  • HDD: (working directory): 6 x 1TB WD RE4 drives using LSI 2008 RAID 0
  • OS: Windows 7 Professional 64-bit, Linux 64-bit
  • OTHER: ANSYS R14, latest NVIDIA TESLA Drivers

(Here is a picture of Sam with two full
tower CUBE HVPC workstations getting
ready to ship out!)


The INTEL® based CUBE HVPC w8i FEA Simulation Workstation:

  • CPU: 2x INTEL XEON x5560 (2.8GHz 4 core)
  • GPU: NVIDIA TESLA C2075 Companion Processor
  • RAM: 64GB DDR3 1333Mhz ECC
  • HDD: (os and apps): 146GB SAS 15k
  • HDD: (working directory): 3 x 73GB SAS 15k – LSI RAID 0
  • OS: Windows 7 Professional 64-bit, Linux 64-bit
  • OTHER: ANSYS R14, latest NVIDIA TESLA Drivers


The INTEL® based CUBE HVPC w16i-GPU FEA Server:

  • CPU: 2x INTEL XEON e5-2690 (2.9GHz 8 core)
  • RAM: 128GB DDR3 1600 MHz ECC
  • HDD: (os and apps): 300GB SATA III 10k WD Velociraptor
  • HDD: (working directory): 3 x 600GB SATA III 10k WD
  • OS: Linux 64-bit
  • OTHER: ANSYS R14, latest NVIDIA TESLA Drivers


The INTEL® based CUBE HVPC w12i-GPU FEA Simulation Workstation: image

  • CPU: 2x INTEL XEON x5690 (3.47GHz 6 core)
  • RAM: 144GB DDR3 1333Mhz ECC
  • HDD: (os and apps): 256GB SSD SATA III
  • HDD: (working directory): 4 x 600GB SAS2 15k – LSI RAID 0
  • OS: Windows 7 Professional 64-bit


Happy 10th Birthday: The Focus

image_thumb1Don’t you hate it when you miss someone’s birthday?  I was looking up an old article in the Focus and noticed that the first issue was published on January, 13th, 2002. 

Happy Belated Birthday!

It was sometime in 2001 that Rod Scholl pointed out that there was no good ANSYS newsletter out there.  People would do one or two issues then get busy and never put out any more, or only publish once in a while.  So we decided that we would not only do a newsletter, but that we would keep it up and publish  on a regular basis. The first issue came out as an HTML email on January 13th of 2002. 


The First Issue of The Focus

And Rod was instrumental in keeping us on track and making sure that with it. Since then we published 74 actual newsletters before switching to a blog format in 2010.  Just before this one goes up on the blog, we will have published 59 The Focus articles.

Thank you to everyone who subscribes to The Focus and reads our postings, rates us, and sends us such great comments and questions.  

Here is to 10 more years!

Files for Webinar: A POST26 Primer

imageWe just finished our webinar for 4/12/2012 on the basics of the POST26 Time History Post Processor.  As promised, here are the files used for examples in the webinar, as well as the PowerPoint:

Tower-of-Test (ToT) test model, APDL:

Tower-of-Test (ToT) test model, ANSYS Mechanical with APDL Snippets:

tower-of-test-transient-2013.wbpz (note this is an R15 file.  See why here.)


imagePowerPoint Presentation:

A recording of this webinar will be available on the following site after 4/13/2012:

Click on  PADT ANSYS Webinar Series to see all recordings.

Some Revolutionary HPC Talk: 208 Cores+896GB < $60k, GPU’s, & ANSYS Distributed

imageThe last couple of weeks a bunch of stuff has gone on in the area of High Performance computing, or HPC, so we thought we would throw it all into one Focus posting and share some things we have learned, along with some advice, with the greater ANSYS user community.

There is a little bit of a revolution going on in both the FEA and CFD simulation side of things amongst users of ANSYS, Inc. products.  For a while now customers with large numbers of users and big nasty problems to solve have been buying lots of parallel licenses and big monster clusters. The size of problems that these firms, mostly turbomachinery and aerospace, have been growing and growing. And even more so for CFD jobs.   But also FEA for HFSS and ANSYS Mechanical/Mechanical APDL.  That is where the revolution started.

But where it is gaining momentum, where the greater impact is being seen on how simulation is used around the world, is with the smaller customers.  People with one to five seats of ANSYS products.  In the past they were happy with their two “included” Mechanical shared memory parallel tasks.  Or they might spring for 3 or 4 CFD parallel licenses.  But as 4, 6, and 8 core CPU chips become mainstream, even on the desktop, and as ANSYS delivers greater value from parallel, we are seeing more and more people invest in high performance computing. And they are getting a quick return on that investment.

Affordable High Value Hardware

208 Cores + 869 GB + 25 TB + Infiniband + Mobile Rack = $58k = HOT DAMN!

Yes, this is a commercial for PADT’s CUBE machines.  ( Even if you would rather be an ALGOR user than purchase hardware from a lowly ANSYS Chanel Partner, keep reading. Even if you would rather go to an ANSYS meeting at HQ in the winter than brave asking your IT department if you can buy a machine not made by a major computer manufacturer, keep reading.

Because what we do with CUBE hardware is something you can do yourself, or that you can pressure your name brand hardware provider into doing.

We just got a very large CFD benchmark job for a customer.  They want multiple runs on a piece of “rotating machinery” to generate performance curves.  Lots of runs, and each run can take up to 4 or 5 days on one of our 32 core machines.  So we put together a 208 core cluster.  And we maxed out the RAM on each one to get to just under 900 GB. Here are the details:

Cores: 208 Total
    3 servers x48 2.3 GHz cores each server
    2 servers x32 3.0 GHz cores each server
RAM: 896 GB
    3 servers  x128GB DDR3 1333MHz ECC RAM each server
    2 servers  x256GB DDR3 1600MHz ECC RAM each server
DATA Array:  ~25TB
Interconnect: 5 x Infiniband 40Gbps QDR
Infiniband Switch: 8 port 40Gbps QDR
Mobile Departmental Cluster Rack – 12U

All of this cost us around $58,000 if you add up what we spent on various parts over the past year or so.  That much horsepower for $58,000.  If you look at your hourly burden rate and the impact of schedule slip on project cost, spending $60k on hardware has a quick payback. 

You do need to purchase parallel licenses. But if you go with this type of hardware configuration what you save over a high-priced solution will go a long way towards paying for those licenses.  Even if you do spend $150k on hardware, your payback with the hardware and the license is still pretty quick.

Now this is old hardware (six months to a year –  dinosaur bones).  How much would a mini-cluster departmental server cost now and what would it have inside:

Cores: 320 Total
5 servers x64 2.3 GHz cores each server
RAM: 2.56 TB
5 servers x512 GB DDR3 RAM each server
DATA Array: ~50TB
Interconnect: 5 x Infiniband 40Gbps QDR
Infiniband Switch: 8 port 40Gbps QDR
Mobile Departmental Cluster Rack – 12U

The cost?  around $80,000.  That is $250/core.  Now you need big problems to take advantage of that many cores.  If your problems are not that big, just drop the number of servers in the mini-cluster.  And drop the price proportionally. 

Same if you are a Mechanical user.  The matrices in FEA just don’t scale in parallel like they do for CFD, so a 300+ core machine won’t be 300 times faster. It might even be slower than say 32 cores.  But the cost drop is the same.  See below for some numbers.

Bottom line, hardware cost is now in a range where you will see payback quickly in increased productivity.



We think they should have some 80’s era super model
draped over the front like those Ferrari posters we
had in our dorm rooms.

For you Mechanical/Mechanical APDL users, let’s talk GPU’s.

We just got an NVIDIA TESLA C2075 GPU.  We are not done testing, but our basic results show that no matter how we couple it with cores and solvers, it speeds things up.  Anywhere from 3 times faster to 50% faster depending on the problem, shared vs. distributed memory, and how many cores we throw in with the GPU.  

This is a fundamental problem with answering the question “How much faster?” because it depends a lot on the problem and the hardware. You need to try it on your problems on your hardware. But we feel comfortable in saying if you buy an HPC pack and run on 8 cores with a GPU, the GPU should double your speed relative to just running on 8 cores.  It could even run faster on some problems. 

For some, that is a disappointment.  “The GPU has hundreds of processors, why isn’t it 10 or 50 times faster?”  Well, getting the problem broken up and running on all of those processors takes time.  But still, twice as fast for between $2,000 to $3,000 is a bargain. I don’t know what your burden rate is but it doesn’t take very many hours of saved run time to recover that cost.  And there is no additional license cost because you get a GPU license with an HPC pack.

Plus, at R14 the solver supports a GPU with distributed ANSYS, so even more improvements.  Add to that support for the unsymmetrical or damped Eigensolvers and general GPU performance increases at R14.

PADT’s advice? If you are running ANSYS Mechanical or Mechanical APDL get the HPC Pack and a GPU along with a 12 core machine with gobs of RAM (PADT’s 12 core AMD system with 64GB or RAM and 3TB of disk costs only $6,300 without the GPU, $8,500 with).  You can solve on 8 cores and play Angry Birds on the remaining 4.

Distributed ANSYS

For a long time many of users out there have avoided distributed ANSYS. It was hard to install, and unless you had the right problem you didn’t see much of a benefit for many of the early releases. Shared Memory Parallel, or SMP, was dirt easy – get an HPC license and tell it to run on 8 cores and go.

Well at R14 of ANSYS Mechanical APDL it is time to go distributed.  First off they make the install much easier.  To be honest, we found that this was the biggest deterrent for many small company users.

Second, at R14 a lot more things are supported in distributed ANSYS. This has been going on for some time so most of what people use is supported. At this release they added subspace eigensolving, TRANS, INFINI and PLANE121/230 elements (electrostatics), and SURF251/252. 

Some “issues” have been fixed like restart robustness and you now have control on when and how multiple restart files are combined after the solve. 

All and all, if you have R14, you are solving mechanical problems, and you have an HPC pack, you should be using distributed most of the time.


We get a ton of questions from people about what they should buy and how much.  And every situation is different. But for small and medium sized companies, the HPC revolution is here and everyone should be budgeting for taking advantage of HPC:

    • At least one HPC pack
    • Some new faster/cheaper multicore hardware (CUBE anyone?)
    • A GPU. 

STOP!  I know you were scrolling down to the comments section to write some tirade about how ANSYS, Inc overcharges for parallel, how it is on a moral equivalence with drowning puppies, and how much more reasonable competitor A, B, or C is with parallel costs.  Let me save you the time.

HPC delivers huge value.  Big productivity improvements.  And it does not write itself. It is not an enhancement to existing software.  Scores of developers are going into solver code and implementing complex logic that allows efficiency with older hardware, shared memory, distributed memory, and GPU’s. It has to be written, tested, fixed, tested again, and back and forth every release.  That value is real, and there is a cost associated with it.

And the competitors pricing model? The only thing they can do to differentiate themselves is charge nothing or very little. They have not put the effort or don’t have the expertise to deliver the kind of parallel performance that the ANSYS, Inc. solvers do.  So they give it away to compete.  Trust me, they are not being nice because they like you. They have the same business drivers as ANSYS, Inc.  They price the way they do because they did not incur as much cost and they know if they charged for it you would have no reason to use their solvers.

ANSYS users of the world unit!  Load your multicore hardware with HPC packs, feed it with a GPU, and join the revolution!

Changing Results Values in ANSYS Mechanical APDL–DNSOL and *VPUT

So it is Friday afternoon and that big, involved, deep-dive into some arcane ANSYS capability is still not written.  So, time for plan B and the list of not so involved but still somewhat arcane capabilities that we like to expose in The Focus.  At the top of that list right now is how to change the results in an ANSYS Mechanical APDL (MAPDL) solve. 

One might ask why would you want to do this?  Well the most common usage is that you want to use APDL to calculate some result value and then display it in a plot.  Similarly, you may want to do some sort of calculation or post processing on MAPDL results but using and external piece of code, but still show the results in ANSYS.  Another common usage is to use MAPDL as a post processor for some external solver. 

And, it turns out, it is pretty easy.  And, as you probably have learned by now if you use MAPDL a lot, there is more than one way to do it.

The “Database”

Before we get into how to do this, we need to talk about the “database” in MAPDL. If you read through the documentation on the commands we will use, it will talk about the database.  This is not the jobname.db file.  That is the db file.  The database refers to the representation of your model, including results and the currently active loads, in memory when you are running MAPDL. 

When you do a RESUME command, MAPDL reads the DB file and stores the model, including geometry, mesh, loads, and run parameters, in memory.  When you do a SET command, it then adds the results and related information into memory. 

So when we use the commands we will talk about next, you are changing what is in the database, not what is in the DB file on your disk.  And you are storing it temporarily.  Many different commands cause the database to go back to its original values.  So you need to be very careful in how you use these tools, and don’t assume that once you have used them, the changes are permanent.  


The simplest way to do it is with the DNSOL command: DNSOL, NODE, Item, Comp, V1, V2, V3, V4, V5, V6

So, if you do a dnsol,32,u,x,3.145  the value in memory for deflection in the X direction will be changed to 3.145.  dnsol,32,s,x,1.1,2.2,3.3 will change the stress on node 32 in the X direction to 1.1, in the Y direction to 2.2, and in the Z direction to 3.3. 

The second argument can also be a component, so you can assign a uniform result value to many nodes at the same time. 

Here is an example, very simple, of a block where we set the deflection on the top nodes to 1 in.

   1: finish

   2: /clear

   3: /prep7

   4: blc4,-2,-2,4,4,20

   5: et,1,185

   6: mptemp,1,70

   7: mpdata,ex,1,1,20e6

   8: mpdata,nuxy,1,1,.23

   9: mpdata,dens,1,1,.001


  11: vmesh,all

  12: /view,1,1,1,1

  13: /vup,1,z

  14: /RGB,INDEX,100,100,100, 0

  15: /RGB,INDEX, 80, 80, 80,13

  16: /RGB,INDEX, 60, 60, 60,14

  17: /RGB,INDEX, 0, 0, 0,15

  18: /show,png

  19: eplot


  21: nsel,s,loc,z,0

  22: cm,nbt,node

  23: d,all,all

  24: nsel,s,loc,z,20

  25: cm,ntp,node

  26: f,all,fx,10

  27: f,all,fy,12

  28: allsel

  29: save


  31: /solu

  32: solve

  33: finish

  34: /post1

  35: plnsol,u,sum


  37: dnsol,ntp,u,y,1

  38: plnsol,u,sum


  40: /show,close



aa1003The Fancy Mesh

aa1004The Normal Solution

aa1005Solution with 1” deflection DNSOL’d onto the top nodes

Pretty simple. 

NOTE: One key thing to remember is you can not use this with Powergraphics. You must have /graph,full turned on.


The DNSOL is great for a few nodes here and there, or a constant value. But it makes for a big nasty *do loop if you want to do a lot of nodes. So ANSYS, Inc. give us the *VPUT command:

*VPUT, ParR, Entity, ENTNUM, Item1, IT1NUM, Item2, IT2NUM, KLOOP

As you can see, this command has a lot of options, so read the Help before you use it. Most of the time you have an array that stores the value you want stuck on your model in an array (ParR).  Then you specify what MAPDL result you want to overwrite and it takes care of it for you.

*vput,nws1(1),node,1,s,1 will place new values for maximum principal stress on all the nodes covered in the array , starting at 1. 

Here is an example of the code, after the same solve as above, to do a *vput instead of a DNSOL:

   1: finish

   2: /post1

   3: plnsol,u,sum


   5: *get,nmnd,node,,num,max

   6: *dim,nwux,,nmnd

   7: *do,i,1,nmnd

   8:     nwux(i) =  i

   9: *enddo


  11: *vput,nwux(1),node,1,u,x

  12: plnsol,u,sum


The code places a displacement in the X direction equal to its node number.  So node 80 has a UX of 80. 

A key thing to note with *vput is that it is much more transient. Pretty much any other command that involves anything other than plotting or listing blows away the values you assigned with *VPUT.  So we recommend that you do a *vput before every plot or listing you do.

Thoughts, Questions, and Conclusion

Of course you should never use this to fudge results. 

You can get very fancy with this. When I use it I often turn off all the plot controls and then create my own legend. That way I can put hours of life on as temperature or SX and then make my own legend that says LIFE or something of the sort. 

Another thing to note is that if you DNSOL or *VPUT a displacement, then ANSYS will distort your plot by that much.  That is OK if you are changing deflection, but not so good if you are plotting life or some esoteric stress value.

A common question when you play with these commands is if you can store the modified results in the RST file.  You can for degree of freedom results, but not for stresses.  You use LCDEF and RAPPND. 

And what about ANSYS Mechanical?  Well it works totally different, and better. You can do all of this using Design Assessment, which was covered in a webinar and a Focus article you can find here.

The key to using these two commands is pretty much the same as any APDL command: Start on a small test model, write a macro to do it, and keep things simple. And, read the manual.  Everything you need to know is in there.

Utilizing Element Birth and Death for Contact Elements in Workbench Mechanical

In case you missed it, Doug Oatis wrote a Focus blog entry on general use of element birth and death in ANSYS Workbench back in November, 2011, which you can access here:

This new article narrows the focus to contact elements specifically.  We recently had a tech support question about how to utilize element birth and death for contact elements in ANSYS Workbench.  So, a simple example was put together and is explained below. 

The main idea is that we need multiple load steps (labeled Steps in Workbench) in order for elements to change status from alive to dead or vice versa.  We also need a way to select the elements so that we can identify which ones will be killed or made alive.

Keep in mind that ANSYS Workbench Mechanical is a newer pre- and post-processor for good old ANSYS Mechanical APDL.  That means we can insert ANSYS commands into the object tree in Workbench Mechanical and those commands will be executed when the solver reads the batch input file that is created when we click the solve button.

So, we need at least one set of Mechanical APDL commands to identify which contact/target pairs or contact regions we need to kill or make alive.  In our example we’ll focus on killing elements but the same principal applies to making killed elements come alive.  Note that killing elements does not remove them from the model.  Rather, it reduces their stiffness by a default value of six orders of magnitude so that effectively they do not participate.  The Mechanical APDL commands needed are for the contact/target pair identification are scalar parameter commands. 

ANSYS Workbench employs some ‘magic’ parameter names that automatically plug in the integer pointers used behind the scenes for identification of element types and material properties.  In the case of contact and target elements, these parameter names are ‘cid’ for the contact elements and ‘tid’ for the target elements.  Thus, for each contact region we want to be able to kill, we need to create unique scalar parameter names, such as:


If we had more than one pair, we might use


and increment the ‘1’ in the parameter names on the left side for each contact pair so that we end up with mycont1, mycont2, etc.

These commands need to be inserted directly under each desired contact region so that they will be located in the appropriate place in the solver batch input file at solution time.


The next command snippet needed is the one that selects the desired contact and target elements and then employs the ANSYS Mechanical APDL command to kill them.  Finally we need to re-select all the elements in the model so that they are all active when the solution takes place.  An example of this command object is:


!kill selected elements (contact and target)

!select everything

Note that anything that occurs to the left of a “!” is considered a comment.  This second command object needs to be inserted under the analysis type branch.


Next, we need to tell ANSYS to perform at least 2 steps (load steps).  This is accomplished in the Details view for Analysis Settings.  For Step Controls, number of steps needs to be 2 (or more than 2).  Once 2 load steps are specified, we can tell ANSYS to only activate the EKILL command snippet for load step 2.  This is done in the Details view for the command snippet.  Step Selection Mode can be set to By Number and the Step Number set to 2, meaning that the command object will only be active for load step 2.  This will result in the contact elements that have been selected by the above commands being killed in load step 2.


In our example, we have two semicircular rings, connected by contact elements where they touch.  One side of the interface uses bonded contact, active for both loads steps.  The other side of the interface uses frictionless contact, active in load step 1 and killed in load step 2.  We would expect that under a compressive load, the frictionless contacts will prevent penetration in load step 1 but allow penetration in load step 2 since they have been killed.


That is exactly what the results show.  The contact status for the frictionless contact region goes from 2 (sliding) at the end of load step 1 to zero (far or not touching) at the end of load step 2.


Deformation plots indicate that penetration is prevented in load step 1.


In load step 2, penetration is allowed because the contact elements at this location have been killed.


So, here is a fairly simple Workbench Mechanical example of utilizing command objects to select contact and target elements, and to kill those elements using the Mechanical APDL EKILL command.  You can read up on element birth and death in the Mechanical APDL Help for more details on element birth and death.  We hope this is useful information to you.

Workshops for “Intro to Workbench Framework Scripting”


At noon Phoenix time today we will be presenting the Webinar “Intro to Workbench Scripting: Controlling Projects, Materials, and Solution Execution with Python”  This is a very high level, and probably short, introduction to the basics of using the python scripting in Workbench.

To support the talking, I’ve put together four workshops, mostly based on ANSYS material or examples we have presented before here on the Focus.  They should be enough for anyone that is a good programmer or better to customize the Workbench Framework.  We also present it here as a tool for those who don’t attend the webinar (and as this weeks Focus posting, cause we didn’t have time to write one…)

Warning: These were done in a hurry between meetings and some travel… so they are not great from a grammar or typo standpoint. Regardless, we hope you find them useful.

The files you need to run them are in this zip file:

The Workshop Document is here: 

We hope to add to this document over the next year or so and provide it as a more or less complete tutorial for those who want to automate their analysis.