ANSYS Icepak: Diverging Residuals, Find and Fix the Problem!

Over the past week I have found myself dealing with a stubborn natural convection ANSYS Icepak model with convergence plots that would have been more aptly named divergence plots that looked like this:

pic2

In this post I’m going to show you the process I went through to find and fix my problem.

First, a few things to know about Icepak:

  • Many of the problems associated with your Icepak model are very likely mesh related.

  • If the bad elements are in a solid, you are probably OK, but if they are in the fluid, watch out!!

So, what is the conclusion? I have a mesh problem.

Second, how do you find the problem?

According to the above “convergence” plot, the continuity equation is diverging (or to my frustrated, on-a-deadline mind, it was GOING CRAZY). Well, a diverging continuity equation indicates that I have a conservation of mass problem. After consulting with one of my more experienced colleagues, Clinton Smith, he suggested that I do the following to work towards pin-pointing the problem:

  • Plot the gravity direction velocity (in my case, this was Uy)

  • Look for the Minimum and Maximum Uy locations in the model

Plotting Uy along a cut plane produced this:

ansys-icepack-diverging-residuals-3

ansys-icepack-diverging-residuals-4

As Clinton thought, plotting Uy instantly showed me the section of my model that was producing un-physical results. Next, I looked for the maximum and minimum velocity locations because this would further show me problems.

ansys-icepack-diverging-residuals-6

ansys-icepack-diverging-residuals-5

Next, I need to determine why this area of my model is the problem. Like I said above, it is likely a mesh problem. In the Mesh Control panel under the Quality tab checking the Face alignment values often help to locate very bad elements:

ansys-icepack-diverging-residuals-7

Clicking on the pink block above displays the elements in the graphics window and it was instantly obvious that my problem was due to distorted elements in my area of interest:

ansys-icepack-diverging-residuals-8

ansys-icepack-diverging-residuals-9

When I look at these elements with a perspective of my model geometry I see that the elements are obviously in the fluid domain:

ansys-icepack-diverging-residuals-10

ansys-icepack-diverging-residuals-11

I have found my problem.

Third, how do I fix the problem? Well, the location of my bad elements happens to lie on a CAD body in Icepak. This means that I am limited in my ability to control the mesh on the actual body. So, though there are likely multiple ways that this problem could be solved, I had the idea to create an air block in the area above that I could much more easily control from a meshing perspective. Having a real Icepak primitive in that space would force the mesher to conform to the boundary of the CAD body.

ansys-icepack-diverging-residuals-12

Like I thought, the air block worked!

ansys-icepack-diverging-residuals-13

I should note that in order to get the mesh to conform exactly, I had to put the air block into its own meshed-separately assembly. And now my residuals look much better!

ansys-icepack-diverging-residuals-14

Summary:

  • Diverging continuity residuals indicate a conservation of mass problem

  • Plot velocities to locate problem region

  • Plot min/max velocity to further identify problem

  • If bad elements are in the fluid region, they must be fixed

  • Consider creating an air block in the region of interest to more finely control the mesh

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:

ss2

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

ss3

To this:

ss4

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

ss6

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

ssa2

  • Use the two views to evaluate

ss8

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

ss9

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
rs1

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

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

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.
rs4

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

rs5

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

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
rs8

rs9
The jobname.abt will appear briefly in the Working Directory

rs10
The output file will read the following:
rs11

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
rs12

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
rs13

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
rs14

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
rs15

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.

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

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

p5
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:
p6

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.
 ss1ss2

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.
p9

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.

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

Recommendations

  • 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.

p11

Recommendations to Avoid ANSYS Mechanical Database Corruption

It’s late. The report for the project that you have spent over 140 hours on in the past two weeks is due in the morning. It is crunch time. Your computer resources are maxed out while you are running a final test scenario, post-processing another Workbench Mechanical module, and grabbing screenshots while you finish up your report formatting. Then, the unutterable occurs, ok, well maybe isn’t utter-able since I’m writing it, but, in short, your run is complete, you hit save, your computer locks up, you have to force quit, but you are sure that your save was successful. And it was…mostly.

Upon re-opening your project you find that all but one of your Mechanical databases are healthy and happy. But that one, the one that you needed a final image from, is corrupted. You know this because of the error messages that pop up with the slew of text that might look something like this:

image

Your frustration is building. You have already used results from that Mechanical model and reflected it in your report, so you do not want to lose it. I feel your pain.

Since this error message pin-points the SYS.mechdb file as the problem, it is unlikely that you can recover it. I know, not what you wanted to hear. But there is a chance that the database is not corrupt. To verify that, follow the steps Ted Harris outlined in a post he made earlier this year here.

If your Mechanical model is, indeed, corrupt and you were not able to recover it from steps outlined by Ted, make note of the following list of guidelines to help avoid database corruption in the future. I received this list of recommendations from ANSYS Inc. after one of our customers experienced a similar scenario as described above.

  1. Open your project from a Local mounted disk drive
  2. Do not work off of a network drive. It is OK to save to it after you are done
  3. Do not work off of a portable USB flash drive. It is OK to save to it after you are done
  4. Software backup programs can often lock a file and prevent WB from writing to the file
  5. Virus scan programs can also lock the file, and prevent WB from writing to the file
  6. Virus scan program can sometimes find a false positive in the file, and “disinfect” it, causing corruption
  7. Determine if the problem is related to the particular computer. ANSYS has seen bad memory or failing disk drives cause problems with saving files
  8. Use Windows Update regularly
  9. Update graphics drivers as needed

Bullet points 4, 5, and 6 are items that can possibly cause corruption while running, so be aware of the times they are generally run. In addition, ANSYS has recommended that disabling the Pre-Load of the Mechanical (and Meshing) editors can reduce the risk of database corruption. Here are the steps to do that:

  1. Reboot the computer (or Close/kill all AnsysFWW.exe and AnsysWBU.exe processes)
  2. Start a new instance of Workbench to change the settings:
    Tools > Options > Mechanical > Pre-Load the Mechanical Editor (disable)
    Tools > Options > Meshing > Pre-Load the Meshing Editor
    (disable)
  3. Exit Workbench
  4. Start a new instance of Workbench and work normally

As a disclaimer, even if you follow the above guidelines, there is still the chance of losing data. To avoid losing all of your data, follow the motto: save early, save often, and with backups! You can create backups by archiving your project as you make progress so that there is always a version to fall back on. Or, if you have the disk space to handle it, you can simply “Save As.” We hope following these recommendations will save you from headache down the road.