Thermal Submodeling in ANSYS Workbench Mechanical 15.0

If you've been following The Focus for a long time, you may recall my prior article about submodeling using ANSYS Mechanical APDL, which was a 'sub' model of a submarine.  The article, from 2006, begins on page 2 at this link:

Also, Eric Miller here at PADT wrote a Focus blog entry on the new-at-14.5 submodeling capability in ANSYS Workbench Mechanical.

Since both of those articles were about structural submodeling, I decided it was time we published a blog entry on how to perform submodeling in ANSYS Mechanical for thermal simulations.

Submodeling is a technique whereby we can obtain more accurate results in a small, detailed portion of a large model without having to build an incredibly refined and detailed finite element model of our complete system.  In short, we map boundary conditions onto a 'chunk' of interest that is a subset of our full model so that we can solve that 'chunk' in more detail.  Typically we mesh the 'chunk' with a much finer mesh than was used in the original model, and sometimes we add more detail such as geometric features that didn't exist in the original model like fillets.

The ANSYS Workbench Project Schematic for a thermal solution involving submodeling looks like this:


Figure 1 – Thermal Submodeling Project Schematic

Note that in the project schematic, the links are automatically established when we setup the submodel after completing the analysis on the coarse model as we shall see below.

First, here is the geometry of the coarse model.  It's a simple set of cooling fins.  In this idealized model, no fillets have been modeled between the fins and the block.


Figure 2 – Coarse Model Geometry, Idealized without Fillets

The boundary conditions consisted of a heat flux due to a  thermal source on the base face and convection to ambient air on the cooling fin surfaces.  The heat flux was setup to vary over the course of 3 load steps as follows:

Load Step        Heat Flux (BTU/s*in^2)

            1                      0.2

            2                      0.5

            3                      0.005

Thus, the maximum heat going into the system occurs in load step 2, corresponding to 'time' 2.0 in this steady state analysis.


Figure 3 – Coarse Model Boundary Conditions – Heat Flux and Convection

The coarse model is meshed with relatively large elements in this case.  The mesh refinement for a production model should be sufficient to adequately capture the fields of interest in the locations of interest.  After solving, the temperature results show a max temperature at the base where the heat flux is applied, transitioning to the minimum temperature on the cooling fins where convection is removing heat.


Figure 4 – Coarse Model Mesh and Temperature Results for Load Step 2

Our task now is to calculate the temperature in one of these fins with more accuracy.  We will use a finer mesh and also add fillets between the fin and base.  For this example, I isolated one fin in ANSYS DesignModeler, did some slicing, and added a fillet on either side of the base of the fin of interest.


Figure 5 – Fine Model (Submodel) Isolated Fin Geometry and Mesh, Including Fillets at Base


ANSYS requires that the submodel lie in the exact geometric position as it would in the coarse model, so it's a good idea to overlay our fine model geometry onto the coarse model to verify the positioning.


Figure 6 – Submodel and Coarse Model Overlaid


Figure 7 – Submodel and Coarse Model Overlaid, Showing Addition of Fillet

The next step is to insert the submodel geometry as a stand-alone geometry block in the Project Schematic which already contains the coarse model, as shown in figure 8.  A new Steady-State Thermal analysis is then dragged and dropped onto the geometry block containing the submodel geometry.


Figure 8 – Submodel Geometry Added to Project Schematic, New Steady-State Thermal System Dragged and Dropped onto Submodel Geometry


Next, we drag and drop the Engineering Data cell from the coarse model to the Engineering Data cell in the submodel block.  This will establish a link so that the material properties will be shared.


Figure 9 – Drag and Drop Engineering Data from Coarse Model to Submodel

The final needed link is established by dragging and dropping the Solution cell from the coarse model onto the Setup cell in the submodel.  This step causes ANSYS to recognize that we are performing submodeling, and in fact this will cause a Submodeling branch to appear in the outline tree in the Mechanical window for the submodel.


Figure 10 – Solution Cell Dragged and Dropped from Coarse Model to Submodel Setup Cell

After opening the Mechanical editor for the submodel block, we can see that the Submodeling branch has automatically been added to the tree.


Figure 11 – Submodeling Branch Automatically Added to Outline Tree

After meshing the submodel I specified that all three load steps should have their temperature data mapped to the submodel from the coarse model.  This was done in the Details view for the Imported Temperature branch, by setting Source Time to All.


Figure 12 – Set Imported Temperature Source Time to All to Ensure All Loads Steps Are Mapped

Next I selected the four faces that make up the cut boundaries in the submodel and applied those to the geometry selection for Imported Temperature.


Figure 13 – Cut Boundary Faces Selected for Imported Temperature


As mentioned above, the Imported Temperature details were set to read in all load steps by setting Source Time to All.  The Imported Temperature branch can now be right-clicked and the resulting imported temperatures viewed.  I also inserted a Validation branch which we will look at after solving.


Figure 14 – Setting Source Time to All, Viewing Imported Temperature on Submodel

Any other loads that need to be applied to the submodel are added as well.  For this model, it's convection on the large faces of the fin that are exposed to ambient air.


Figure 15 – Submodel Convection Load on Fin Exposed Faces

Since there are three load steps in the coarse model and we told ANSYS to map results from all time points, I set the number of steps to three in Analysis Settings, then solved the submodel.  Results are available for all three load steps.


Figure 16 – Submodel Temperature Results for Step 2 (Highest Heat Flux Value in Coarse Model)

Regarding the Validation item under the Imported Temperature branch, this is probably best added after the solution is done.  In my case I had to clear it and recalculate it.  Validation can display either an absolute or relative (percent difference) plot on the nodes at which loads were imported.  Figure 17 shows the relative difference plot, which maxes out at about 6%.  The validation information as well as mapping techniques are described in the ANSYS Help.


Figure 17 – Submodel Imported Temperature Validation Plot – Percent Difference on Mapped Nodes

Looking at the coarse model and submodel results side by side, we see good agreement in the calculated temperatures.  The temperature in the fillets shows a nice, smooth gradient.


Figure 18 – Coarse and Submodel Temperature Results Showing Good Agreement

Hopefully this explanation will be helpful to you if you have a need to perform submodeling in a thermal simulation in ANSYS.  There is a Thermal Submodeling Workflow section in the ANSYS 15.0 Help in the Mechanical User's Guide that you may find helpful as well.




ANSYS Workbench Installations and RedHat 6.6 – Error and Workaround

penguin_shWe were recently alerted by a customer that there is apparently a conflict with ANSYS installations if Red Hat Enterprise Linux 6.6 (RHEL 6.6) is installed. We have confirmed this here at PADT. This effects several versions of ANSYS, including 15.0.7, 14.5, and 14.0. The primary problem seems to be with meshing in the Mechanical or Meshing window.

The windows errors encountered can be: “A software execution error occurred inside the mesher. The process suffered an unhandled exception or ran out of usable memory.” or “an inter-process communication error occurred while communicating with the MESHER module.”

The error message popup can look like this:


Note that the Platform Support page on the ANSYS website does not list RHEL 6.6 as supported. RHEL is only supported up through 6.5 for ANSYS 15.0. This is the link to that page on the ANSYS website:

That all being said, there is a workaround that should allow you to continue using ANSYS Workbench with RHEL 6.6 if you encounter the error. It involves renaming a directory in the installation path:

In this directory:


Rename the folder ‘X11’ to ‘Old-X11’

After that change, you should be able to successfully complete meshes, etc,. in ANSYS Workbench. Keep in mind that RHEL 6.6 is not officially supported by ANSYS, Inc. and their recommendation is always to stick with supported levels of operating systems. These are always listed in the ANSYS Help for the particular version you are running as well as at the link shown above.

Since the renamed directory is contained within the ANSYS installation files, it is believed that this will not affect anything else other than ANSYS. Use at your own risk, however. Should you encounter one of more of the errors listed above, we hope this article has provided useful information to keep your ANSYS installations up and running.

ANSYS Workbench Mechanical: The Body Views Features Can Be a Huge Time Saver

ss1The following is a story of discovery. The discovery of an ANSYS feature that has been around since at least ANSYS14! How is that possible you ask? The PADT team members are the ANSYS experts of the Southwest, how could they have missed this! And we would agree with you on the former, but even we overlook some of the most fundamental and helpful features. And you are going to want to store this one away, so copy the link, bookmark the page, or make a mental note with your photographic memory and file it under productivity enhancer.

After all of that hype, what could I possibly be going tell you that is so earth shattering. Well, it’s not really a secret if you read the title but I’ll let you be the judge of this little nugget’s seismic impact. Now, if you’ll indulge me, I’ll set the stage.

A couple of weeks ago, I was compiling a report of an ANSYS Mechanical analysis. One of the report sections required details of the contact definition between each part. I hunkered down to spend what I thought would be a tedious hour of documenting each contact expecting to use a procedure that consisted in some form of isolating the two bodies of interest, capturing screenshots of the two parts in various relation to each other in order to adequately represent the contact context. As I sat looking at the screen creating my plan of attack, I thought to myself, I wish there was an ANSYS feature that would automatically isolate the two connected bodies so that I would not have to go through the finger numbing (or should I say finger cramping) task of “hiding all other bodies” (even though this is one of my other favorite features). As soon as the thought flashed through my mind, my eyes moved up the screen and, above the Mechanical graphics window, I saw it.

Body Views! The star of my post. You will find our elusive capability in the painfully obvious Connections Context Toolbar:


When I clicked on it, the graphics window transformed from this:


To this:


The relevant bodies were isolated into two different views, contact and target. I was elated. My task of manually isolating the bodies and adjusting the views while intermediately capturing the desired screens now turned into a joyful, albeit nerdy, moment of discovery. With some experimenting, I easily found that each view can be adjusted independently, unless of course you would like them all to move together. You can accomplish this by selecting the Sync Views option:ss5

Why this feature is helpful:

  • Use it to easily isolate contact/target body
  • Use it to easily identify missing or over defined contact regions
  • Use it to document contact definition
  • Use it in combination with the filtering and tagging capabilities to more easily parse through a large assembly model

Summary of steps to enable the Body Views feature:

  • Click on the Connections Branch in the Model Tree so that the Connections context toolbar appears


  • Click Body Views ssa1
  • Select your desired contact region to analyze


  • Use the two views to evaluate


  • Use the Sync Views option to force views to move together


To my chagrin, this option has been available in ANSYS for a few releases at least and I never took note. But the possibility that some of you might have also overlooked this option prompted me to highlight it for you and I hope you find it useful in the future.

Final thought:

If you found this article helpful and are interested in learning about or being reminded of some other excellent ANSYS time saver capabilities, check out the article by Eric Miller on filtering and tagging here.

Continue a Workbench Analysis in ANSYS MAPDL R15

stopsignThis article outlines the steps required to continue a partially solved Workbench based analysis using a Multi-Frame Restart and the MAPDL Batch mode.

In this article you will learn:

  • Some ways to interface between ANSYS Workbench and ANSYS MAPDL
  • How to re-launch a run using a Multi-Frame Restart in ANSYS Batch mode
  • The value of the jobname.abt functionality for Static Structural and Transient Structural analyses

Recently I was working in the ANSYS Workbench interface within the Mechanical application running a Transient Structural analysis. I began my run thinking that my workstation had the necessary resources to complete the analysis in a reasonable amount of time. As the analysis slowly progressed, I began to realize that I needed to make a change and switch to a computer that had more resources. But some of my analysis was already complete and I did not want to lose that progress. In addition, I wanted to be sure that I could monitor the analysis intermediately to ensure that it was advancing as I would like. This meant that however I decided to proceed I needed to make sure that I could still read my results back into Mechanical along with having the capability to restart again from a later point. Here were my options.

1: I could use the Remote Solve Manager (RSM) to continue running my analysis on a compute server machine. Check out this article for more on that.

I did use RSM in part but perhaps you do not have RSM configured or your computer resources are not connected through a network. Then I will show the other option you can use.

2: A Multi-Frame Restart using MADPL in ANSYS Batch mode

Here’s the process:

1. Make note of the current load step and last converged substep that your analysis completed when you hit the Interrupt Solution button

2. Copy the *.rdb, *.ldhi, *.Rnnn files from the Solver Files Directory on the local machine to the Working Directory on the computing machine

You can find your Solver Files Directory by right clicking on the Solution Branch in the Model Tree and selecting Open Solver Files Directory:

3. Write an MAPDL input file with the commands to launch a restart and save it in the Working Directory on the computing machine (save with extension *.inp)

Below is an example of an input that will work well for restarting an analysis, but feel free to adjust it with the understanding that the ANSYS Programming Design Language (APDL) is a sophisticated language with a vast array of capability.

4. Start the MADPL Product Launcher interface on the computing machine and:
    a: Set Simulation Environment to ANSYS Batch
    b. Navigate to your Working Directory
    c. Set the jobname to the same name as that of the *.rdb file
    d. Browse to the input file you generated in Step 3
    e. Give your output file a descriptive name
    f. Adjust parallel processing and memory settings as desired
    g. Run


5. Look at the output file to see progress and monitor the run

6. Write “nonlinear” in a text file and save it as jobname.abt inside the Working Directory to cleanly interrupt the run and generate restart files when desired

The jobname.abt will appear briefly in the Working Directory

The output file will read the following:

Note that the jobname.abt interruption process is the exact process that ANSYS uses in the background when the Interrupt Solution button is pressed interactively in Mechanical

Read more about the jobname.abt functionality in the Help Documentation links at the end of this article.

7. Copy all newly created files in Working Directory on the computing machine to the Solver Files Directory on the local machine

8. Back in the Mechanical application, highlight the Solution branch of the model tree, select Tools menu>Read Results Files… and navigate to the Solver Files Directory and read the updated *.rst file

After you have read in the results file, notice that the restart file generated from the interruption through the jobname.abt process appears as an option within the Mechanical interface under Analysis Settings

9. Review intermediate results to determine if analysis should continue or if adjustments need to be made

10. Repeat entire process to continue analysis using the new current loadstep and substep

Happy solving!

Here are some useful Help Documentation sections in ANSYS 15 for your reference:

  • Understanding Solving:
    • help/wb_sim/ds_Solving.html
  • Mechanical APDL: Multiframe Restart:
    • help/ans_bas/Hlp_G_BAS3_12.html#BASmultrestmap52199

And, as always, please contact PADT with your questions!

ANSYS Remote Solve Manager (RSM): Answers to Some Frequently Asked Questions

rsm-1For you readers out there that use the ANSYS Remote Solve Manager (RSM) and have had one or all of the below questions, this post might just be for you!

  1. What actually happens after I submit my job to RSM?
  2. Where are the files needed to run the solve go?
  3. How do the files get returned to the client machine, or do they?
  4. What if something goes wrong with my solve or in the RSM file downloading process, is there any hope of recovery?
  5. Are there any recommendations out there for how best to use RSM?

If your question is, how do I setup RSM as a user? You answers are here from a post by Ted Harris. The post today is a deeper dive into RSM.

The answers to questions 1 through 3 above are really only necessary if you would like to know the answer to question 4. My reason for giving you a greater understanding of the RSM process is so that you can do a better job of troubleshooting should your RSM job run into an issue.  Also, please note that this process is specifically for an RSM job submitted for ANSYS Mechanical. I have not tested this yet for a fluid flow run.

What happens when a job gets submitted to RSM?

The following will answer questions 1-3 above.

When a job is run locally (on your machine), ANSYS uses the Solver Files Directory to store and update data. That folder can be found by right clicking on the Solution branch in the Model tree and selecting Open Solver Files Directory.

The project directory will be opened and you can see all of the existing files stored for your particular solution:

When a job gets submitted to RSM, the files that are stored in the above folder will be transferred to a series of two temporary directories. One temporary directory on the client side (where you launched the job from) and one temporary directory on the compute server side (where the numbers get crunched).

After you hit solve for a remote solve, you will notice that your project solver directory gets emptied. Those files are transferred to a temporary directory under the _ProjectScratch directory:
p3 p4

Next, these files get transferred to a temporary directory on the compute server. The files in the _ProjectScratch directory will remain there but the folder will not be updated again until the solve is interrupted or finished.

You can find the location of the compute server temporary directory by looking at the output log in the RSM queueing interface:

If you navigate to that directory on your compute server, you will see all of the necessary files needed to run. Depending on your IT structure, you may or may not have access to this directory, but it is there.

Here is a graphical overview of the route that your files will experience during the RSM solve process.

Once your run is completed or you have interrupted it to review intermediate results and your results have been downloaded and transferred to the solver files folder, both of the temporary directories get cleaned up and removed. I have just outlined the basic process that goes on behind the scenes when you have submitted a job to RSM.

What if something goes wrong with my RSM job? Can I recover my data and re-read it into Workbench?

Recently, I ran into a problem with one of my RSM jobs that resulted in me losing all of the data that had been generated during a two day run. The exact cause of this problem I haven’t determined but it did force me to dive into the RSM process and discover what I am sharing with you today. By pin-pointing and understanding what goes on after the job is submitted to RSM, I did determine that it can be possible to recover data, but only under certain circumstances and setup.

First, if you have the “Delete Job Files in Working Directory” box checked in the compute server properties menu accessed from the RSM queue interface (see below) and RSM sees your job as being completed, the answer to the above question is no, you will not be able to recover your data. Essentially, because the compute server is cleaned up and the temporary directory gets deleted, the files are lost.

To avoid lost data and prepare for such a catastrophe, my recommendation is that you or your IT department, uncheck the “Delete Job Files in Working Directory” box. That way, you have a backup copy of your files stored on the server that you can delete later when you are sure you have all of your files safely transferred to your solver files folder within your project directory structure.

The downside to having this box unchecked is that you have to manually cleanup your server. Your IT department might not like, or even allow you to do this because it could clutter your server if you do not stay on top of things. But, it could be worth the safety net.

As for getting your data back into Workbench, you will need to manually copy the files on the compute server to your solver files folder in your Workbench project directory structure. I explained how to access this folder at the beginning of this post. Once you have copied those files, back in the Mechanical application, with the Solution branch of your model tree highlighted, selects Tools>Read Results Files… (see below graphic), navigate to your solver files directory, select the *.rst file and read it in.

Once the results file is read in, you should see whatever information is available.


  • Though it is possible to run concurrent RSM jobs from the same project, my recommendation is to only run one RSM job at a time from the same project in order to avoid communication or licensing holdups

  • Unless you are confident that you will not ever need to recover files, consider unchecking the “Delete Job Files in Working Directory” box in the compute server properties menu.

    • Note: if you are not allowed access to your compute server temporary directories, you should probably consult your IT department to get approval for this action.

    • Caution: if you uncheck this box, be sure that you stay on top cleaning up your compute server once you have your files successfully downloaded

  • Depending on your network speed, when your results files get large, >15GB, be prepared to wait for upload and download times. There is likely activity, but you might not be able to “see” it in the progress information on the RSM output feed. Be patient or work outside of RSM using a batch MAPDL process.

  • Avoid hitting the “Interrupt Solution” command more than once. I have not verified this, but I believe this can cause mis-communication between the compute server and local machine temporary directories which can cause RSM to think that there are no files associated with your run to be transferred.


Default Contact Stiffness Behavior for Bonded Contact

p7It recently came to my attention that the default contact stiffness factor for bonded contact can change based on other contact regions in a model. This applies both to Mechanical as well as Mechanical APDL. If all contacts are bonded, the default contact stiffness factor is 10.0. This means that in our bonded region, the stiffness tending to hold the two sides of contact together is 10 times the underlying stiffness of the underlying solid or shell elements.

However, if there is at least one other contact region that has a type set to anything other than bonded, then the default contact stiffness for ALL contact pairs becomes 1.0. This is the default behavior as documented in the ANSYS Mechanical APDL Help, in section 3.9 of the Contact Technology Guide in the notes for Table 3.1:

“FKN = 10 for bonded. For all other, FKN = 1.0, but if bonded and other contact behavior exists, FKN = 1 for all.”

So, why should we care about this? It’s possible that if you are relying on bonded contact to simulate a connection between one part and another, the resulting stress in those parts could be different in a run with all bonded contact vs. a run with all bonded and one or more contact pairs set to a type other than bonded. The default contact stiffness is now less than it would be if all the contact regions were set to bonded.

This can occur even if the non-bonded contact is in a region of the model that is in no way connected to the bonded region of interest. Simply the presence of any non-bonded contact region results in the contact stiffness factor for all contact pairs to have a default value of 1.0 rather than the 10.0 value you might expect.

Here is an example, consisting of a simple static structural model. In this model, we have an inner column with a disk on top. There are also two blocks supporting a ring. The inner column and disk are completely separate from the blocks and ring, sharing no load path or other interaction. Initially all contact pairs are set to bonded for the contact type. All default settings are used for contact.

Loading consists of a uniform temperature differential as well as a bearing load on the disk at the top. Both blocks as well as the column have their bases constrained in all degrees of freedom.

After solving, this is the calculated maximum principal stress distribution in the ring. The max value is 41,382.

Next, to demonstrate the behavior described above, we changed the contact type for the connection between the column and the disk from bonded to rough, all else remaining the same.

After solving, we check the stresses in the ring again. The max stress in the ring has dropped from 41,283 to 15,277 as you can see in the figure below. Again, the only change that was made was in a part of the model that was in no way connected to the ring for which we are checking stresses. The change in stress is due solely to a change in contact type setting in a different part of the model. The reason the stress has decreased is that the stiffness of the bonded connection is less by a factor of 10, so the bonded region is a softer connection than it was in the original run.


So, what do we as analysts need to do in light of this information? A good practice would be to manually specify the contact stiffness factor for all contact pairs. This behavior only crops up when the default values for contact stiffness factor are utilized. We can define these stiffness factors easily in ANSYS Mechanical in the details view for each contact region. Further, we need to always remember that ANSYS as well as other analytical tools are just that – tools. It’s up to us to ensure that the results of interest we are getting are not sensitive to factors we can adjust, such as mesh density, contact stiffness, weak spring stiffness, stabilization factors, etc.

Using Probes to Obtain Contact Forces in ANSYS Mechanical

Recently we have had a few questions on obtaining contact results in ANSYS Mechanical. A lot of contact results can be accessed using the Contact Tool, but to obtain contact forces we use Probes. Since not everyone is familiar with how it’s done, we’ll explain the basics here.

Below is a screen shot of a Mechanical model involving two parts. One part has a load that causes it to be deflected into the other part.


We are interested in obtaining the total force that is being transmitted across the contact elements as the analysis progresses. Fortunately this is easy to do using Probes in Mechanical.

The first thing we do is click on the Solution branch in the tree so we can see the Probes button in the context toolbar. We then click on the Probe drop down button and select Force Reaction, as shown here:


Next, we click on the resulting Force Reaction result item under the Solution branch to continue with the configuration. We first change the Location Method from Boundary Condition to Contact Region:


We then specify the desired contact region for the force calculation from the Contact Region dropdown:


Note that the coordinate system for force calculation can either be Cartesian or Cylindrical. You can setup a coordinate system wherever you need it, selectable via the Orientation dropdown.

There is also an Extraction dropdown with various options for using the contact elements themselves, the elements underlying the contact elements, or the elements underlying the target elements (target elements themselves have no reaction forces or other results calculated). Care must be taken when using underlying elements to make sure we’re not also calculating forces from other contact regions that are part of the same elements, or from applied loads or constraints. In most cases you will want to use either Contact (Underlying Element) or Target (Underlying Element). If contact is non-symmetric, only one of these will have non zero values.

In this case, the setting Contact (Contact Element) was a choice that gave us appropriate results, based on our contact behavior method of Asymmetric:


Here are the details including the contact force results:


This is a close up of the force vs. ‘time’ graphs and table (this was a static structural analysis with a varying pressure load):



FX = -0.4640219E-04
FY = -251.1265
FZ = -0.1995618E-06
MX = 62.78195
MY = -0.1096794E-04
MZ = -688.9742
SUMMATION POINT= 0.0000 0.0000 0.0000

We hope this information is useful to you in being able to quickly and easily obtain your contact forces.

Video Tips: Using ACT to change Default Settings in ANSYS Mechanical

A short video showing how ACT (ANSYS Customization Toolkit) can be used to change Default Settings for analyses done in ANSYS Mechanical.  This is a very small subset of the capabilities that ACT can provide.  Stay tuned for other videos showing further customization examples.

The example .xml and python file is located below.  Please bear in mind that to use these “scripted” ACT extension files you will need to have an ACT license.  Compiled versions of extensions don’t require any licenses to use.  Please send me an email ( if you are wondering how to translate this example into your own needs.


Integrating ANSYS Fluent and Mechanical with Flownex

Component boundaries generated in Flownex are useful in CFD simulation (inlet velocities, pressures, temperatures, mass flow). Generation of fluid and surface temperature distribution results from Flownex can also be useful in many FEA simulations. For this reason the latest release of Flownex SE was enhance to include several levels of integration with ANSYS.  

ANF Import

By simply clicking on an Import ANF icon on the Flownex Ribbon bar users can select the file that they want to import. The user will be requested to select whether the file must be imported as 3D Geometry which conserves the coordinates system or as an isometric drawing.

The user can also select the type of component which should be imported in the Flownex library. Since the import only supports lines and line related items this will typically be a pipe component.

Following a similar procedure, a DXF importer allows users to import files from AutoCAD.

This rapid model construction gives Flownex users the ability to create and simulate networks quicker. With faster model construction, users can easily get to results and spend less time constructing models.


ANSYS Flow Solver Coupling and Generic Interface

The Flownex library was extended to include components for co-simulation with ANSYS Fluent and ANSYS Mechanical.

These include a flow solver coupling checks, combined convergence and exchanges data on each iteration, and a generic coupling that can be used for cases when convergence between the two software programs is not necessary.

The general procedure for both the Fluent and Mechanical co-simulation is the same:

  1. By identifying specified named selections, Flownex will replace values in a Fluent journal file or ds.dat file in the case of Mechanical.
  2. From Flownex, Fluent/Mechanical will then be run in batch mode
  3. The ANSYS results are then written into text files that are used inputs into Flownex.
  4. When applicable, specified convergence criteria will be checked and the procedure repeated if necessary.


Learn More

To learn more about Flownex or how Flownex and ANSYS Mechanical contact PADT at 480.813.4884 or  You can also learn more about Flownex at

Some Tips on Configuring RSM as a User

rsm1If you’re not familiar with it, RSM is the ANSYS Remote Solve Manager.  In short, it allows you to submit solutions from various ANSYS tools so they can be solved remotely, such as on a compute cluster, remote number cruncher, or perhaps just another computer that isn’t being used very much.  Note that there is no additional licensing or installation is required (other than perhaps ANSYS HPC licensing to take advantage of multiple cores).  RSM is installed automatically when ANSYS is installed; it just needs to be configured to be activated.

According to PC Revive, in version 14.5 and 15.0, there is a nicely documented Setup Wizard that helps with the setup and configuration of RSM on compute servers.  This setup wizard as well as the rest of the RSM documentation in the ANSYS Help does a great job of explaining RSM and what must be done to setup and configure it.  This Focus entry assumes that your crack IT staff has installed RSM on your compute machine(s) and has decided where the Compute Server will be (can be on your local machine or on your ‘number cruncher’ or on a different machine).  So, our focus here is on what needs to be done as a user to send your solutions off to the remote solver using RSM.

As an example, we have RSM 15.0 configured with the Compute Server on a remote computer named cs3a. The first time running RSM, using Start > All Programs > ANSYS 15.0 > Remote Solve Manager > RSM 15.0, we get the window shown here:


Notice that it only shows our local machine (My Computer) and nothing about the actual remote computer on which we want to solve.

Therefore, we need to add the information on our cluster node which contains the compute server.

To do this, click on Tools > Options.  This is the resulting window.  Notice the Add button at lower left is grayed out:


What it’s waiting for us to do is type in the name of our desired remote computer, like this:


Now that a new name has been typed in the Name field, the Add button is active.  After clicking Add, we get this:


After clicking OK, we will now see that the new remote computer has been added in the RSM window:


The next step is to set your login password for accessing this computer.  Right click on the new hostname in the RSM window in the tree at left, and select Set Password.


Then enter your network login and password information in the resulting window:


If your accounts are fully setup, at this point you can run a test by right clicking on the localhost item in the tree under the remote computer name and selecting Test Server:


If the test is successful, you will see that the test job completed with a green checkmark on the folder icon in the upper right portion of the RSM window:


If your login is not configured properly, you will likely get an error like this one shown below.  Notice that the upper right portion now states that the job has failed and there is a red X rather than a green checkmark on the folder icon.  By clicking on the job in the upper right panel, we can see the job log in the lower right panel.  In this case, it says that the login failed due to an incorrect password.


The fix for the password problem is to ensure that the correct login is being accessed by RSM on the remote computer.  This is done from the RSM window by right clicking on the remote computer name and selecting Accounts.


If your account and/or password are different on the remote computer than they are on your local machine, you will need to establish an alternate account so that RSM knows to use the correct login on the remote computer.  Right click on your account in the Accounts pane, and select Add Alternate Account:


Enter your username and password for the remote computer in the resulting window.  Next, we need to associate that login with localhost on the remote computer.  This is down by checking the localhost box in the Compute Servers pane, like this:


Another problem we have seen is that the user doesn’t have permission for ANSYS to write to the default solve directory on the remote computer.  In that case, the test job log will have an error like this:


This fix in this case is to establish a solve directory manually, first by creating one on the remote computer, if needed, and second by specifying that RSM use that directory rather than the default.  The second step is accomplished in the RSM window via right clicking on the localhost item for the remote computer, then selecting Properties.  On the General tab, you should be able to change the Working Directory Location to User Specified, then enter the desired directory location as shown in the image below.  If that option is greyed out, either your password for the remote machine has not been entered correctly, or you are not part of the admin group on the remote computer.  In the case of the latter, either your RSM administrator has to do it for you, or you have to be granted the admin access.


At this point, if the test server runs have completed successfully you should be ready to try a real solution using RSM.  We’ll use Mechanical to show how it’s done.  In the Mechanical editor, click on Tools > Solve Process Settings.  Here we will need to specify the remote computer and queue we’ll be using for the solution.  Click on the Add Remote button:


In the resulting Rename Solve Process Settings button, type in a name for your remote solve option that makes sense to you.  We called ours RemoteSolve1.  This new option will now show up on the left side of the Solve Process Settings window:


The next step is to type in the name of the Solve Manager over on the right side.  In our case, the Solve Manager is on computer cs3a.  Any queues that are available to RSM for this Solve Manager will show in the Queue field, after a brief period of time to make the connection.  In our case, the only queue is a local queue on cs3a.


We are now ready to solve our Mechanical model remotely, using RSM.  Instead of clicking the Solve button in Mechanical, we will click on the drop down arrow to the right of the solve button.  From the dropdown, we select the remote solve option we created, RemoteSolve1:


Assuming the solution completes with no errors, this job will show up in the RSM window with a status of Finished when it is done.


The final step in this case is to download the results from the remote computer back to the client machine.  In the Mechanical editor, this is done by right clicking on the Solution branch and selecting Get Results as shown below.  Also note that you can monitor a nonlinear solution via Solution Information.  You’ll just need to right click during solution to have a snapshot of the nonlinear diagnostics brought back from the remote computer.


We hope this helps with the setup and utilization of RSM from a user perspective.  There are other options and applications for RSM that we didn’t discuss, but hopefully this is useful for those needing to get ‘over the hump’ in using RSM.

Getting to know ANSYS – Rigid Body Dynamics (RBD)

This video is an introduction to ANSYS RBD – an add on module to ANSYS Mechanical for analyzing rigid mechanisms.

ACT Extension for a PID Thermostat Controller (PART 2)

(View part one of this series here.)

So, I’ve done a little of this Workbench customization stuff in a past life. My customizations involved lots of Jscript, some APDL, sweat and tears. I literally would bang my head against Eric Miller’s office door jamb wondering (sometimes out loud) what I had done to be picked as the Workbench customization guy. Copious amounts of alcohol on weeknights helped some, but honestly it still royally sucked. Because of these early childhood scars, I’ve cringed at the thought of this ACT thingy until now. I figured I’d been there, done that and I had zero, and I mean zero desire to relive any of it.

So, I resisted ACT even after multiple “suggestions” from upper management that I figure out something to do with it. That was wrong of me; I should have been quicker to given ACT a fair shot. ACT is a whole bunch better than the bad ol’ days of JScript. How is it better? Well, it has documentation… Also, there are multiple helpful folks back at Canonsburg and elsewhere that know a few things about it. This is opposed to the days when just one (brilliant) guy in India named Rajiv Rath had ever done anything of consequence with JScript. (Without him, my previous customization efforts would simply have put me in the mad house. Oh, and he happens to know a thing or two about ACT as well…)

Look Ma! My First ACT Extension!

In this post we are going to rig up the PID thermostat boundary condition as a new boundary condition type in Mechanical. In ACT jargon, this is known as adding a pre-processing feature. I’m going to refer you primarily to the training material and documentation for ACT that you can obtain from the ANSYS website on their customer portal. I strongly suggest you log on to the portal and download the training material for version 15.0 now.

Planning the Extension

When we create an ACT extension we need to lay things out on the file system in a certain manner. At a high level, there are three categories of file system data that we will use to build our extension. These types of data are:

  1. Code. This will be comprised of Python scripts and in our case APDL scripts.
  2. XML. XML files are primarily used for plumbing and for making the rest of the world aware of who we are and what we do.
  3. Resources. These files are typically images, icons, etc… that spice things up a little bit.

Any single extension will use all three of these categories of files, and so organizing this mess becomes priority number one when building the extension. Fortunately, there is a convention that ACT imposes on us to organize the files. The following image depicts the structure graphically.


We will call our extension PIDThermostat. Therefore, everywhere ExtensionName appears in the image above, we will replace that with PIDThermostat in our file structure.

Creating a UI for our Load

The beauty of ACT is that it allows us to easily create professional looking user experiences for custom loads and results. Let’s start by creating a user interface for our load that looks like the following:


As you can see in the above user interface, all of the controls and inputs for our little PID controller that we designed in Part 1 of this blog series are present. Before we discuss how we create these user elements, let’s start with a description of what they each mean.

The first item in the UI is named Heat Source/Sink Location. This UI element presents to the user a choice between picking a piece of geometry from the model and specifying a named selection. Internal to the PID controller, this location represents where in the model we will attach the control elements such that they supply or remove energy from this location. ACT provides us two large areas of functionality here. First, it provides a way to graphically pick a geometric item from the model. Second, it provides routines to query the underlying mesh associated with this piece of geometry so that we can reference the nodes or elements in our APDL code. Each of these pieces of functionality is substantial in its size and complexity, yet we get it for free with ACT.

The second control is named Temperature Monitor Location. It functions similarly to the heat source/sink location. It gives the user the ability to specify where on the model the control element should monitor, or sense, the temperature. So, our PID controller will add or remove energy from the heat sink/source location to try to keep the monitor location at the specified set point temperature.

The third control group is named Thermostat Control Properties. This group aggregates the various parameters that control the functionality of the thermostat. That is, the user is allowed to specify gain values, and also what type of control is implemented.

The forth control group is named Thermostat Setpoint Properties. This group allows the user to specify how the setpoint changes with time. An interesting ACT feature is implemented with this control group. Based on the selection that the user makes in the “Setpoint Type” dropdown, a different control is presented below for the thermostat setpoint temperature. When the user selects, “User Specified Setpoint” then a control that provides a tabular input is presented. In this case, the user can directly input a table of temperature vs time data that specifies how the setpoint changes with time. However, if the user specifies “Use Model Entity as Setpoint” then the user is presented a geometry picker similar to the controls above to select a location in the model that will define the setpoint temperature. When this option is selected, the PID controller will function more like a follower element. That is, it will try to cause the monitor location to “follow” another location in the model by adding or removing energy from the heat source/sink location. The offset value allows the user to specify a DC offset that they would like to apply to the setpoint value. Internally, this offset term will be incorporated into the constraint equation averaging method to add in the DC offset.

Finally, the last control group allows the user to visualize plots of computed information regarding the PID controller after the solution is finished. Normally this would be presented in the results branch of the tree; however, the results I would like to present for these elements don’t map cleanly to the results objects in ACT. (At least, I can’t map them cleanly in my mind…) More detail on the results will be presented below.

So, now that we know what the control UI does, let’s look at how to specify it in ACT

Specifying the UI in XML

As mentioned at the beginning, ACT relies on XML to specify the UI for controls. The following XML snippet describes the entire UI.

<extension version=“1” name=“ThermalTools”>

  <guid shortid=“thermaltools”>852acb16-4731-4e91-bd00-b464be02b361</guid>

  <script src=“” />


  <interface context=“Mechanical”>





    <toolbar name=“thermtools” caption=“Thermal Tools”>

      <entry name=“PIDThermostatLoad” icon=“ThermostatGray”

             caption=“PID Thermostat Control”>








  <simdata context=“Mechanical”>

    <load name=“pidthermostat” version=“1” caption=“PID Thermostat”

    icon=“ThermostatWhite” issupport=“false” isload=“true” color=“#0000FF”>


        <getcommands location=“solve”>writePIDThermostatLoad</getcommands>

        <getcommands location=“post”>writePIDThermostatPost</getcommands>








      <property name=“ConnectionGeo”  caption= “Heat Source/Sink Location”


        <attributes selection_filter=“vertex|edge|face” />


      <property name=“MonitorGeo”  caption= “Temperature Monitor Location”


        <attributes selection_filter=“vertex|edge|face|body” />


      <propertygroup name=“ControlProperties” caption=“Thermostat Control Properties”


        <property name=“ControlType” caption=“Control Type”

                  control=“select” default=“Both Heat Source and Sink”>

          <attributes options=“Heat Source,Heat Sink,Both Heat Source and Sink”/>


        <property name=“ProportionalGain” caption=“Proportional Gain”

                  control=“float” default=“0”/>

        <property name=“IntegralGain” caption=“Integral Gain”

                  control=“float” default=“0”/>

        <property name=“DerivativeGain” caption=“Derivative Gain”

                  control=“float” default=“0”/>


      <propertygroup name=“SetpointProperties” caption=“Thermostat Setpoint Properties”


        <propertygroup name=“SetpointType” display=“property” caption=“Setpoint Type”

                       control=“select” default=“User Specified Setpoint”>

          <attributes options=“User Specified Setpoint,Use Model Entity as Setpoint”/>

          <propertytable name=“SetPointTemp” caption=“Thermostat Set Point Temperature”

                         display=“worksheet” visibleon=“User Specified Setpoint”

                         control=“applycancel” class=“Worksheet.PropertyGroupEditor.PGEditor”>

            <property name=“Time” caption=“Time” unit=“Time” control=“float”></property>

            <property name=“SetPoint” caption=“Set Point Temperature”

                      unit=“Temperature” control=“float”></property>


          <property name=“SetpointGeo”  caption= “Setpoint Geometry”

                    visibleon=“Use Model Entity as Setpoint” control=“scoping”>

            <attributes selection_filter=“vertex|edge|face|body” />



        <property name=“SetpointOffset” caption=“Offset” control=“float” default=“0”/>


      <propertygroup name=“Results” caption=“Thermostat Results” display=“caption”>

        <property name=“ViewResults” caption=“View Results?” control=“select” default=“No”>

          <attributes options=“Yes,No”/>









Describing this in detail would take far longer than I have time for now, so I’m going to direct you to the ACT documentation. The gist of it is fairly simple though. XML provides a structured, hierarchical mechanism for describing the layout of the UI. Nested structures appear as child widgets of their parents. Callbacks are used within ACT to provide the hooks into the UI events so that we can respond to various user interactions. Beyond that, read the docs!! And, hey, before I hear any whining remember that in the old days of Jscript customization there wasn’t any documentation! When I was a Workbench Customization Kid we had to walk uphill, both ways, barefoot, in 8’ of snow for 35 miles… So shut it!

Making the Magic Happen

So, the UI is snazzy and all, but the heavy lifting really happens under the hood. Ultimately, what ACT provides us, when we are creating new BCs for ANSYS, is a clever way to insert APDL commands into the ds.dat input stream. Remember that at its core all Mechanical is, is a glorified APDL generator. I’m sure the developers love me reducing their hard labor to such mundane terms, but it is what it is… So, at the end of the day, our little ACT load objects are nothing more than miniature APDL writers. You thought we were doing something cool…

So, the magic happens when we collect up all of the input data the user specifies in our snazzy UI and turn that into APDL code that implemented the PID controller. This is obviously why I started by developing the APDL code first outside of WB. The APDL code is the true magic. Collecting up the user inputs and writing them to the ds.dat file occurs inside the getcommands callback. If you look closely at the XML code, you will notice two getcommands callbacks. The first one calls a python function named: writePIDThermostatLoad. This callback is scheduled to fire when Mechanical is finished writing all of the standard loads and boundary conditions that it implements natively and is about to write the first APDL solve command. Our commands will end up in the ds.dat file right at this location. I chose this location for the following reason. Our APDL code for the PID thermostat will be generating new element types and new nodes and elements not generated by Workbench. Sometimes workbench implements certain boundary conditions using surface effect element types. So, these native loads and boundary conditions themselves may generate new elements and element types. Workbench knows about those, because it’s generating them directly; however, it has no idea what I might be up to in my PID thermostat load. So, if it were to write additional boundary conditions after my PID load, it very well might reuse some of my element type ids, and even node/element ids. The safer thing to do is to write our APDL code so that it is robust in the presence of an unknown maximum element type/real constant set/node number/etc… Then, we insert it right before the solve command, after WB has written all of its loads and boundary conditions. Thus, the likelihood of id collisions is greatly reduced or eliminated.

Note, too, that ACT provides some utility functions to generate a new element type id and increment the internal counter within Workbench; however, I have found that these functions do not account for loads and boundary conditions. Therefore, in my testing thus far, I haven’t found them safe to use.

The second getcommands callback is setup to fire when Workbench finishes writing all of the solve commands and has moved to the post processing part of the input stream. I chose to implement a graphing functionality for displaying the relevant output data from the PID elements. Thus, I needed to retrieve this data from ANSYS after the solution is complete so that I can present it to the user. I accomplished this by writing a little bit of APDL code to enter /post26 and export all of the data I wish to plot to a CSV file. By specifying this second getcommands callback, I could instruct Workbench to insert the APDL commands after the solve completed.

Viewing the Results

Once the solution has completed, clicking on the “View Results?” dropdown and choosing “Yes” will bring up the following result viewer I implemented for the PID controller. All of the graphing functionality is provided by ACT in an import module called “chart”. This result viewer is simply implemented as a dialog with a single child control that is the ACT chart widget. This widget also allows you to layout multiple charts in a grid, as we have here. As you can see, we can display all of the relevant output data for the controls cleanly and efficiently using ACT! While this can also be accomplished in ANSYS Mechanical APDL, I think we would all agree that the results are far more pleasing visually when implemented in ACT.


Where Do We Go from Here?

Now that I’ve written an ACT module, my next steps are to clean it up and try to make it a little more production ready. Once I’m satisfied with it, I’ll publish it on this blog and on the appropriate ANSYS library. Look for more posts along the way if I uncover additional insights or gotchas with ACT programming. I will leave you with this, however. If you have put off ACT programming you really should reconsider! Being mostly new to ACT, I was able to get this little boundary condition hooked up and functioning in less than a week’s time. Given the way the user interface turned out and the flexibility thus far of the control, I’m quite pleased with that. Without the documentation and general availability of ACT, this effort would have been far more intense. So, try out ACT! You won’t be disappointed.

ACT Extension for a PID Thermostat Controller (PART 1)

I’m going to embark on a multipart blog series chronicling my efforts in writing a PID Thermostat control boundary condition for workbench. I picked this boundary condition for a few of reasons:

  1. As far as I know, it doesn’t exist in WB proper.
  2. It involves some techniques and element types in ANSYS Mechanical APDL that are not immediately intuitive to most users. Namely, we will be using the Combin37 element type to manage the control.
  3. There are a number of different options and parameters that will be used to populate the boundary condition with data, and this affords an opportunity to explore many of the GUI items exposed in ACT.

This first posting goes over how to model a PID controller in ANSYS Mechanical APDL.  In future articles I will share my efforts to refine the model and us ACT to include it in ANSYS Workbench.

PID Controller Background

Let’s begin with a little background on PID controllers. Full disclaimer, I’m not controls engineer, so take this info for what it is worth. PID stands for Proportional Integral Differential controller. The idea is fairly simple. Assume you have some output quantity you wish to control by varying some input value. That is, you have a known curve in time that represents what you would like the output to look like. For example:


The trick is to figure out what the input needs to look like in time so that you get the desired output. One way to do that is to use feedback. That is, you measure the current output value at some time, t, and you compare that to what the desired output should be at that time, t. If there is no difference in the measured value and the desired value, then you know whatever you have set the input to be, it is correct at least for this point in time. So, maybe it will be correct for the next moment in time. Let’s all hope…

However, chances are, there is some difference between what is measured and what is desired. For future reference we will call this the error term. The secret sauce is what to do with that information? To make things more concrete, we will ground our discussion in the thermal world and imagine we are trying to maintain something at a prescribed temperature. When the actual temperature of the device is lower than the desired temperature, we will define that as a positive error. Thus, I’m cold; I want to be warmer: that equals positive error. The converse is true. I’m hot; I want to be colder: that equals negative error.

One simple way we could try to control the input would be to say, “Let’s make the input proportional to the error term.” So, when the error term is positive, and thus I’m cold and wish to be warmer, we will add energy proportionate to the magnitude of the error term. Obviously the flip side is also true. If I’m hot and I wish to be cooler my negative error term would mean that remove energy proportionate to the magnitude of the error term. This sounds great! What more do you need? Well, what happens if I’m trying to hold a fixed temperature for a long time? If the system is not perfectly adiabatic, we still have to supply some energy to make up for whatever the system is losing to the surroundings. Obviously, this energy loss occurs even with the system is in a steady state configuration and at the prescribed temperature! But, if the system is exactly at the prescribed temperature, then the error term is zero. Anything proportionate to zero is… zero. That’s a bummer. I need something that won’t go to zero when my error term goes to zero.

What if I could keep a record of what I’ve done in the past? What if I accumulated all of the past error from forever? Obviously, this has the chance of being nonzero even if instantaneously my error term is zero. This sounds promising. Integrating a function of time with respect to time is analogous to accumulating the function values from history past. Thus, what if I integrated my error term and then made my input also proportional to that value? Wouldn’t that help the steady state issue above? Sure it would. Unfortunately, it also means I might go racing right on by my set point and it might take a while for that “mistake” to wash out of the system. Nothing is free. So, now I have kept a record of my entire past and used that to help me in the present, what if I could read the future? What if could extrapolate out in time?

Derivatives allow us to make a local extrapolation (in either direction) about a curve at a fixed point. So, if my curve is a function of time, which in our case the curves are, forward extrapolation is basically jumping ahead into the future. However, we can’t truly predict the future, we can only extrapolate on what has recently happened and make the leap of faith that it will continue to happen just as it has. So, if I take the derivative of my error term with respect to time, I can roll the dice a little a make some of my input proportional to this derivative term. That is, I can extrapolate out in time. If I do it right, I can actually make the system settle out a little faster. Remember that when the error term goes to zero and stays there, the derivative of the error term also goes to zero. So, when we are right on top of our prescribed value this term has no bearing on our input.

So, a PID controller simply takes the three concepts of how to specify an input value based on a function of the error term and mixes them together with differing proportions to arrive at the new value for the input. By “tuning” the system we can make it such that it responds quickly to change and it doesn’t wildly overshoot or oscillate.

Implementing a PID controller in ANSYS MAPDL

We will begin by implementing a PID controller in MAPDL before moving on to implementing the boundary condition in ANSYS Workbench via the ACT. We would like the boundary condition to have the following features:

  1. Ultimately we would like to “connect” this boundary condition to any number of nodes in our model. That is, we may want to have our energy input occur on a vertex, edge or face of the model in Workbench. So, we would like the boundary condition to support connecting to any number of nodes in the model.
  2. Likewise, we would like the “measured output” to be influenced by any number of nodes in our model. That is, if more than one node is included in the “measured value” set, we would like ANSYS to use the average temperature of the nodes in that set as our “measured output”. Again, this will allow us to specify a vertex, edge, face or body of the model to function as our measurement location. The measured value should be the average temperature on this entity. Averaging needs to be intelligent. We need to weight the average based on some measure that accounts for the relative influence of a node attached to large elements vs one attached to small elements.
  3. We would like to be able to independently control the proportional, integral and derivative components of the control algorithm.
  4. It would be nice to be able to specify whether this boundary condition can only add energy, only remove energy or if it can do both.
  5. We would like to allow the set point value to also be a function of time so that it too can change with time.
  6. Finally, it would be nice to be able to post process some of the heat flow quantities, temperature values, etc… associated with this boundary condition.

This is a pretty exhaustive list of requirements for the boundary condition. Fortunately, ANSYS MAPDL has built into it an element type that is perfectly suited for this type of control. That element type is the combin37.

Introducing the Combin37 Element Type

Understanding the combin37 element in ANSYS MAPDL takes a bit of a Zen state of mind… It’s, well, an element only a mother could love. Here is a picture lifted from the help:


OK. Clear as mud right? Actually, this thing can act as a thermostat whether you believe me from the picture or not. Like most/all ANSYS elements that can function in multiple roles, the combin37 is expressed in its structural configuration. It is up to you and me to mentally map it to a different set of physics. So, just trust me that you can forget the damping and FSLIDE and little springy looking thing in the picture. All we are going to worry about is the AFORCE thing. Mentally replace AFORCE with heat flow.

Notice those two little nodes hanging out there all by their lonesome selves labeled “control nodes”. I think they should have joysticks beside them personally, but ANSYS didn’t ask me. Those little guys are appropriately named. One of them, NODE K actually, will function as our set point node. That is, whatever temperature value we specify in time for NODE K, that same value represents the set point temperature we would like our “measured” location take on in time as well. So, that means we need to drive NODE K with our set point curve. That should be easy enough. Just apply a temperature boundary condition that is a function of time to that node and we’re good to go. Likewise, NODE L represents the “measured” temperature somewhere else in the model. So, we need to somehow hook NODE L up to our set of measurement nodes so that it magically takes on the average value of those nodes. More on that trick later.

Now, internally the combin37 subtracts the temperature at NODE K from NODE L to obtain an error term. Moreover, it allows us to specify different mathematical operations we can perform on the error term, and it allows us to take the output from those mathematical operations and drive the magical AFORCE thingy, which is heat flow. Guess what those mathematical operations are? If you guessed simply making the heat flow through the element proportional to the error, proportional to the time integral of the error and proportional to the time derivative of the error you would be right. Sounds like a PID controller doesn’t it? Now, the hard part is making sense of all the options and hooking it all up correctly. Let’s focus on the options first.

Key Option One and the Magic Control Value

Key option 1 for the combin37 controls what mathematical operation we are going to perform on the error term. In order to implement a full PID controller, we are going to need three combin37 elements in our model with each one keyed to a different mathematical operation. ANSYS calls the result of the mathematical operation, Cpar. So, we have the following:

KEYOPT(1) Value Mathematical Operation
0,1 image
2 image
3 image
4 image
5 image

Thus, for our purposes, we need to set keyopt(1) equal to 1,4 and 2 for each of the three elements respectively.

Feedback is realized by taking the control parameter Cpar and using it to modify the heat flow through the element, which is called AFORCE. The AFORCE value is specified as a real constant for the element; however, you can also rig up the element so that the value of AFORCE changes with respect to the control parameter. You do this by setting keyopt(6)=6. The manner in which ANSYS adjusts the AFORCE value, which again is heat flow, is described by the following equation:


Thus, the proportionality constant for the Proportional, Integral and Derivative components are specified with the C1 variable. RCONST, C3 and C4 are all set to zero. C2 is set to 1. Also note that ANSYS first takes the absolute value of the control parameter Cpar before plugging it into this equation. Furthermore, the direction of the AFORCE component is important. A positive value for AFORCE means that the element generates an element force (heatflow) in the direction specified in the diagram.  That is, it acts as a heat sink. So, assuming the model is attached to node J, the element acts as a heat sink when AFORCE is positive. Conversely, when AFORCE is negative, the element acts like a heat source. However, due to the absolute value, Cpar can never take on a negative value. Thus, when this element needs to act as an energy source to add heat to our model, the coefficient C1 must be negative. The opposite is true when the element needs to act as an energy sink.

Key Option Four and Five and when is it Alive?

If things weren’t confusing enough already, hold on as we discuss Keyopt 4 and 5. Consider the figure below, again lifted straight from the help.


The combination of these two key options controls when the element switches on and becomes “alive”. Let’s take the simple case first. Let’s assume that we are adding energy to the model in order to bring it up to a given temperature. In this case, Cpar will be positive because our set point is higher than our current value. If the element is functioning as a heat source we would like it to be on in this condition. Furthermore, we would like it to stay on as long as our error is positive so that we continue adding energy to bring the system up to temperature. Consider the diagram in the upper left. Imagine that we set ONVAL = 0 and OFFVAL = 0.001. Whenever Cpar is greater than ONVAL.  So this sounds like exactly what we want when the element is functioning as a heat source. Thus, keyopt(4)=0 and keyopt(5)=0.001 with OFFVAL=ONVAL=0 is what we want when the element needs to function as a heat source.

What about when it is a heat sink?  In this case we want the element to be active when the error term is negative; that is, when the current temperature is higher than the set point temperature.  Consider the diagram in the middle left.  This time let OFFVAL=0 and OFFVAL=-0.001.  In this case, whenever Cpar is negative (less than OFFVAL) then the element will be active.  Thus, keyopt(4)=0 and keyopt(5)=1 with OFFVAL=-0.001 ONVAL=0 is what we want when the element needs to function as a heat sink.  Notice, that if you set ONVAL=OFFVAL then the element will always stay on; thus, we need to provide the small window to activate the switching nature of the element.

Thus, we see that we need six different combin37 elements, three for a PID controlled heat sink and three for a PID controlled heat source, to fully specify a PID controlled thermal boundary condition. Phew… However, if we set all of the proportionality constants for either set of elements defining the heat sink or heat source to zero, we can effectively turn the boundary condition into only a heat source or only a heat sink, thus meeting requirement four listed above. While we’re marking off requirements, we can also mark off requirements three and five. That is, with this combination of elements we can independently control the P, I and D proportionality constants for the controller. Likewise, by putting a time varying temperature constraint on control node K, we can effectively cause the set point value to change in time. Let’s see if we can now address requirements one and two.

How do we Hook the Combin37 to the Rest of the Model?

We will address this question in two parts. First, how do we hook the “business” end of the combin37 to the part of the model to which we are going to add or remove energy? Second, how do we hook the “control” end of the combin37 to the nodes we want to monitor?

Hooking to the Combin37 to the Nodes that Add or Remove Energy

To hook the combin37 to the model so that we can add or remove energy we will use the convection link elements, link34. These elements effectively act like little thermal resistors with the resistance equation being specified as:


In order to make things nice, we need to “match” the resistances so that each node effectively sees the same resistance back to the combin37 element. We do this by varying the “area” associated with each of these convective links. To get the area associated with a node we use the arnode() intrinsic function. See the listing for details.

Hooking the Combin37 to the Nodes that Function as the Measured Value

As we mentioned in our requirements, we would like to be able to specify more than one or more nodes to function as the measured control value for our boundary condition. More precisely, if more than one node is included in the measurement node set, we would like ANSYS to average the temperatures at those nodes and use that average value as the measurement temperature. This will allow us to specify, for example, the average temperature of a body as the measurement value, not just one node on the body somewhere. However, we would also like for the scheme to work seamlessly if only one node is specified. So, how can we accomplish this? Constraint equations come to our rescue.

Remember that a constraint equation is defined as:


How can we use this to compute the average temperature of a set of nodes, and tie the control node of the combin37 to this average? Let’s begin by formulating an equation for the average temperature of a set of nodes. We would like this average to not be simply a uniform average, but rather be weighted by the relative contribution a given node should play in the overall average of a geometric entity. For example, assume we are interested in calculating the average temperature of a surface in our model. Obviously this surface will have associated with it many nodes connected to many different elements. Assume for the moment that we are interested in one node on this face that is connected to many large elements that span most of the area of this face. Shouldn’t this node’s temperature have a larger contribution to the “average” temperature of the face as say a node connected to a few tiny elements? If we just add up the temperature values and divide by the number of nodes, each node’s temperature has equal weight in the average. A better solution would be to area weight the nodal temperatures based on the area associated with each individual node. Something like:


That looks a little like our constraint equation. However, in the constraint equation I have to specify the constant term, whereas in the equation above, that is the value (Tavg) that I am interested in computing. What can I do? Well, let’s add in another node to our constraint equation that represents the “answer”. For convenience, we’ll make this the control node on our combin37 elements since we need the average temperature of the face to be driving that node anyway. Consider:


Now, our constant term is zero, and our Ci’s are Ai/AT and -1 for the control node. Voila! With this one constraint equation we’ve compute an area weighted average of the temperature over a set of nodes and assigned that value to our control node. CE’s rock!

An Example Model

This post is already way too long, so let’s wrap things up with a little example model. This model will illustrate a simple PI heat source attached to an edge of a plate with a hole. The other outer edges of the plate are given a convective boundary condition to simulate removing heat. The initial condition of the plate is set to 20C. The set point for the thermostat is set to 100C. No attempt is made to tune the PI controller in this example, so you can clearly see the effects of the overshoot due to the integral component being large. However, you can also see how the average temperature eventually settles down to exactly the set point value. clip_image026

The red squiggly represents where heat is being added with the PI controller. The blue squiggly represents where heat is being removed due to convection. Here is a plot of the average temperature of the body with respect to time where you can see the response of the system to the PI control.


Here is another run, where the set point value ramps up as well. I’ve also tweaked the control values a little to mitigate some of the overshoot. This is looking kind of promising, and it is fun to play with. Next time we will look to integrate it into the workbench environment via an actual ACT extension.


Part 2 is here

Model Listing

I’ve included the model listing below so that you can play with this yourself. In future posts, I will elaborate more on this technique and also look to integrate it into an ACT module.
























keyopt,P_et,1,0    ! Control on UK-UL

keyopt,P_et,2,8    ! Control node DOF is Temp

keyopt,P_et,3,8    ! Active node DOF is Temp

keyopt,P_et,4,0    ! Wierdness for the ON/OFF range

keyopt,P_et,5,0    ! More wierdness for the ON/OFF range

keyopt,P_et,6,6    ! Use the force, Luke (aka Combin37)

keyopt,P_et,9,0    ! Use the equation, Duke (where is Daisy…)



keyopt,I_et,1,4    ! Control on integral wrt time

keyopt,I_et,2,8    ! Control node DOF is Temp

keyopt,I_et,3,8    ! Active node DOF is Temp

keyopt,I_et,4,0    ! Wierdness for the ON/OFF range

keyopt,I_et,5,0    ! More wierdness for the ON/OFF range

keyopt,I_et,6,6    ! Use the force, Luke (aka Combin37)

keyopt,I_et,9,0    ! Use the equation, Duke (where is Daisy…)



keyopt,D_et,1,2    ! Control on first derivative wrt time

keyopt,D_et,2,8    ! Control node DOF is Temp

keyopt,D_et,3,8    ! Active node DOF is Temp

keyopt,D_et,4,0    ! Wierdness for the ON/OFF range

keyopt,D_et,5,0    ! More wierdness for the ON/OFF range

keyopt,D_et,6,6    ! Use the force, Luke (aka Combin37)

keyopt,D_et,9,0    ! Use the equation, Duke (where is Daisy…)


keyopt,mass_et,3,1 ! Interpret real constant as DENS*C*Volume





!!        S M A L L   T E S T   M O D E L       !!








! Thickness of plate



! Plane55 element



! Make a block






! Make a hole


! Punch a hole









! create an nodal component for the

! ‘attachment’ location





! create a nodal component for the

! ‘monitor’ location





!!        B E G I N   P I D   M O D E L         !!



! Real constant and mat prop for the mass element

mp,qrate,mass_et,0 ! Zero heat generation rate for the element

r,mass_et,1e-10  ! Extremely small thermal capacitance


! Material properties for convection element

! make the convection “large”



! Real constant for the combin37 elements

! that ack as heaters












! build the PID elements








! Create the nodes.  They can be all coincident

! as we will refer to them solely by their number.

! They will be located at the origin





! Put a thermal mass on the K and L nodes

! for each control element to give them

! thermal DOFs







! Proportional element






! Integral element






! Derivative Element








! Ground the base node



! Get a list of the attachment nodes








! Hook the attachment nodes to the

! end of the control element with

! convection links














! Hook up the monitor nodes








! We are going to need these areas

! so, hold on to them





! Write the constraint equations







! Create a transient setpoint temperature







! Constrain the temperature node to be

! at the setpoint value





! Apply an initial condition of

! 20 C to everything
















! Plot the response temperature

! and the setpoint temperature





ANSYS, Inc. Unleashes New ACT Extensions for Version 15.0

act_150_1If you haven’t noticed, ANSYS, Inc. has been making quite a few ACT extensions available for ANSYS 15.0 on the ANSYS Customer Portal. If you are not familiar with ACT (ANSYS Customization Toolkit) Extensions, please see our earlier blog entry, “There’s an Extension for That,” here.

As of this writing, there are 20 ACT extensions available for download from the Customer Portal for version 15.0. There is also a set of training files available from the same link.

Among the new additions is an extension allowing the use of Mechanical APDL User Programmable Features in the Mechanical editor. Previously this could only be done in MAPDL. You will still need to install the customization files as part of the ANSYS installation, and you will still need the proper versions of the FORTRAN compiler and Visual Studio. However, this extension unleashes a significant capability within the Workbench Mechanical tool that wasn’t there previously, access to UPF’s.

The documentation states that it works with both versions 14.5 and 15.0 of ANSYS.
To get to the 15.0 ACT Extensions download area, login to the ANSYS Customer Portal and navigate through Downloads > Extension Library > 15.0. We urge you to browse the list of available extension available from the Customer Portal to see which might have benefits to your simulations.

Here is a list of all of the current extensions:

ACT Intro Training_R150_v1

ACT Introductory Training Materials

ACT Templates for DM_R150_v1

Templates for educational purpose; demonstrates most common scenarios of ACT-based development needs in DesignModeler

ACT Templates for DX_R150_v1

Templates for educational purpose; demonstrate integration of external optimizers

ACT Templates_R150_v1

Templates for educational purpose; cover most common ACT-based development needs

Acoustics Extension R150_v42

Expose 3D acoustics solver capabilities

Convection Extension_R150_v4

Expose convection with pilot node capability in steady-state and transient thermal analyses

Coupled Diffusion_R150_v3

Introduce coupled diffusion analysis (structural diffusion, thermal diffusion, and structural thermal diffusion) in both static and full transient analysis

Coupled Field Physics Extension_R150_v1

Expose piezoelectric, thermal-piezoelectric and thermal-structural solver capabilities


Expose the Dynamic Design Analysis Method (DDAM) in Mechanical interface

Design Modeler Utility_R150_v1

Expose some useful functions in DM interface

Distributed Mass_R150_v2

Add distributed mass (rather than a point mass) to a surface as either “total mass” or “mass per unit area”

Enforced Motion_R150_v3

In Mode-Superposition Harmonic and Transient Analyses, allows applying base excitation (displacement or acceleration). Excitation can be either constant or frequency/time dependent

FE Info Extension_R150_v9

Expose node and element related information


Map temperature and pressure loads (from a CFD calculation) to a multi-step Mechanical analysis for transient one-way FSI. Includes CFD-Post macros

Follower Loads Extension_R150_v2

Create follower forces and moments to follow geometric deformation

Hydrostatic Fluid_R150_v5

Expose hydrostatic fluid elements in Mechanical


Expose MATLAB optimization algorithms and user programs in the Optimization component of ANSYS DesignXplorer


Change material ID to user specified value for the selected bodies


Expose the MAPDL offshore features in Mechanical

Piezo Extension_R150_v8

Expose piezo-electric solver capabilities

UPF Extension_R150_v1

Allow for the use of User Programmable Features (UPF) within Workbench

Be a View Master: Customizing and Managing Views in ANSYS Mechanical

Accessing various predefined views in Mechanical is easy. You can click on the triad axes (including the negative sides of the axes) and view the model down those axes, or click the turquoise isometric ball for an isometric view. Or you can right click the graphics area and select from a variety of views (top, back, left, etc.) from the View menu.

But what if you want a predefined view that has the model rotated “just so” and zoomed out “just so?” What if you want to store these settings not just in your current model, but bring them into other models as well? Starting in R14.5 you can do this, using the Manage Views window.

To open the Manage Views window, click on the eye-in-a-box icon that looks like it was designed by Freemasons. image The Managed Views window appears at the lower left of the GUI. The window consists of the following:image

The labels are pretty self-explanatory, but let’s delve into a couple of examples. As you can see by observing the triad, the model viewpoint shown here does not coincide with any pre-defined view.


Click the Create a View button image and give the view a name (defaults to View 1 but any name can be given):


After rotating, panning, and zooming, you can return to this view by clicking the Apply a View button. image


As mentioned before, you can apply the same view between different models by using the View Export/Import capabilities. To do this, simply highlight the named view to be exported in the originating model and click the Export button. image Specify the xml file to which the view is to be stored. In another model, click the Import button image and browse to the xml file containing the view to be imported. This is basically the Mechanical equivalent of an APDL file containing /VIEW and /ZOOM commands. Example follows.

The following view is to be stored and exported to another model. Highlight the view name (“Sulk”) and click the Export button.


Frankie the Frowning Finite Element Model worries that views can’t be shared between models.

Specify the xml file name and click Save.


In a different model, click the Import button, browse to the xml stored in the previous step, and click open.


Highlight the imported view name and click the Apply a View button.


Sammy the Smiling Simulation Model is happy that views can be transferred between models.

The Managed Views window provides a significant amount of viewing versatility over the standard viewing definitions.