Cloud this.. Cloud that... What about Cloud Simulations? Cloud FEA/CFD?

Firstly, sorry for the long silence and no recent posts in a while.  Too many things happened...with the latest being me under the surgeon's needle.  I had a cervical disc hernia and it was so bad that no simulation could help ;)  I needed to undergo surgery.  I am slowly recovering now... but need your help on a question that has been on my mind lately:

Do you think Cloud FEA/CFD will actually see the daylight?  I have created a poll on this recently and already have seen some great comments and interest on this topic.  I would love to hear from you! Here you go:
Poll: Cloud Computing for FEA/CFD? Do you like it?

Once I have this poll completed (in 28 days from today), I plan to update this post (or publish a new post) with a final report and analysis of what the simulation community thinks.

I am really interested in hearing what you have to say!

The dreaded question: Is the solution converged?

This is perhaps the most asked and important, yet dreaded, question in CFD analysis. Some people will say “yes, the residuals were XXXX” just to dismiss the question. But is the answer that simple? Unfortunately it is not. That is just one measure we should use in determining whether a solution is converged. The definition of convergence is, in a mathematical sense, the approach towards a definite point. Basically we are trying to get our numerical solution sufficiently close (accurate) to a definite point (exact solution). To help understand what convergence is in practice, we must step back and look at what we are trying to accomplish in modeling.

Overview

The goal of CFD modeling is to obtain virtual flow field which represents the physical situation. In traditional CFD modeling, the first step in this process is to create a grid that represents the physical domain. Once the mesh has been created, the boundary conditions and other physics models are applied to complete the computational model. The computational model is then solved. As analysts we must think of the convergence ramifications when executing both the meshing and solving steps.

Meshing Convergence

Typically when people speak of meshing in regards to convergence they are considering refining the mesh in certain areas to reduce the residuals in this area. This is a technique that is commonly used, but is not what we will be discussing here.

However when you consider what we are representing the continuous flow field by using discrete approximations, we must ensure that our grid is sufficient fine—that it approximates, to sufficient accuracy, the physical flow field. Typically this is done by investigating successively finer and finer meshes to show that the solution converges to a fixed limit. Many people refer to this as “grid independence,” but in reality is it is convergence of the discrete computational model to the continuous physical system.

Solver Convergence

When monitoring a solver run, people generally just examine the residuals. Residuals are a measure of change of the solution between iterations at it tends towards the discretitized solution. Different solvers specify different levels at which the residuals must meet to be a “converged” solution. However these are just a general rule-of-thumb. In general the residuals can reduce to a certain level but the flow field may not have reached an iteration independent solution. Conversely the residuals could converge to a level higher than the specified tolerance yet could reach a fixed solution for the quantities of interest (although it we would still have to check the mesh convergence of this solution). Because of this it is typically recommended to monitor several relevant quantities during the solution phase to make sure these converge in addition to the residuals.

Of course the question that naturally arises is: What are the variables we should monitor? This is where our years of schooling and experience come into play. In general we want to monitor variables that are relevant for the problem we are solving. For instance for many problems we are concerned with the pressure drop through the domain so we should monitor this quantity as the solution progresses. If we were investigating the flow over an airplane it would be useful to monitor the lift and drag. If we were to model a heat exchanger, it would be useful to monitor the temperatures leaving the domain and the heat flux through the various surfaces. So there is no single monitor that that is sufficient to determine convergence for all problems. We must use our engineering judgment to determine the most useful quantities to monitor.

Summary

In summary, answering whether a solution is a converged solution is a complex answer. It is a question that, as a modeler, we must always have in the back of our mind. When we are developing a concept for the model in our mind we should be thinking about the variables we should monitor. When developing a mesh we should be thinking about developing another to test mesh convergence (grid independence). When crunching the numbers, we want to monitor both the residuals and the monitor points we have created. When the first results are displayed, we should be looking for unphysical discontinuities or other phenomena that would indicate poor convergence.

This discussion is not meant to be an end-all be-all in regards to convergence. In fact entire books have been written about the subject, so I will not claim to have described in completely in this blog. I just wanted to present some questions that we, as modelers, should always be considering when developing and solving our models. We should understand the true nature of convergence, feel confident when asked whether our solution has converged, not simply rattle off the scripted response that the residuals were below some arbitrary value!

Get started with Entry-Level HPC and ANSYS

Ansys Mechanical has supported and been tightly integrated in the High Performance Computing (HPC) arena for many years and many versions. However, I've seen a quite some hesitation from users and companies to introduce HPC into their engineering simulation environment. Reasons generally come down to cost and complexity.

True, setting up a central cluster with many nodes is costly. The complexity of configuring it, optimizing it (for Ansys and the other array of applications that will share it), and maintaining it can be daunting.
However, I've worked with a large number of customers recently getting into "entry level HPC". Even though our primary workstations are getting more powerful (6-core processors are here, 12-core processors are coming soon) and we're able to run larger jobs on them, there's still a need to offload the job to an HPC environment. Let's face it - we've all closed our emails, web browsers, and office apps during those painfully slow solves to try a free up just a few more Mb's of ram, hoping the run won't crash.

What I consider "entry-level" is to have at minimum a 2nd workstation (or server), can be high or low end, expensive with lots of CPU/RAM/disk space, or inexpensive (assembled from all those spare components laying around). The idea here is to try HPC - a simple setup to send a solve over to a 2nd computer. If you have the compute power in your 2nd computer for high-end analysis, great! If not, get something set up to at least introduce yourself to the concepts and see how it works.

I recently worked with a customer who purchased a very high-end single-node compute server. Why just one? Simple answer... cost constraints. We were able to set it up, get the Ansys users up and running and accustomed to HPC (and adopting its advantages) and then when the budget allowed, the customer added additional compute nodes to the existing cluster.

Off-loading the solve can be done a number of ways, including Remote Solve Manager (RSM), batch scripts, Distributed Ansys, even simply using Remote Desktop. (Great discussion points for future topics!) This simple "entry level HPC" setup can free up your primary workstation during those intensive solves. It is amazingly convenient to build a model on my laptop, hit "Solve", shut down my laptop, go home, and come in the next morning with a fully solved model!

I love to hear your thoughts!

Jason.

When NOT to use comparative Charts for CFD software

Recently there was an article in Desktop Engineering where it compared several commercial CFD products in the marketplace today. I am all for this! Sure! What shocked most in the industry who read this article was how terribly inaccurate this was and how biased it was towards one single product. I wish it was featured in a "marketing section" vs. an engineering magazine such as Desktop Engineering. In this rebuttal article from Mentor Graphics (Dr. J), the author claims to even have received an apology from Desktop Engineering: "To their credit, when we notified them, Desktop Engineering apologised to us, sent out an apology to all of its readership and promised that such a chart would not go out again."

Here is a direct link to the rebuttal article: "Lies, Damned Lies, and "CFD Comparison Charts" - Part I" You can also see the original "comparative charts" here as reference.

In this article, Dr. J aptly points out the one-sided take by CF Design. Though he mainly talks about improper comparison of Mentor Graphics' FloEFD, there are several inaccuracies on this comparative chart when it comes to ANSYS CFD products (FLUENT, CFX) as well. Any current FLUENT and CFX user can testify to these inaccuracies! Dr. J, the count on "misleading statements" in the DE article are well beyond 27 if we include the ANSYS CFD products. I still don't believe this article ever got published! It begs more research and accurate information.

Having been in the simulation industry (FEA, CFD) for close to a decade, this false comparative chart regarding CFD products is really appalling, especially coming from a magazine such as DE. Negative marketing campaigns are not a good idea. If you do them, please know the facts about competition first! And then do not do it as a "guide" to helping engineers decide on what CFD code to chose!

Update: Folks from Blue Ridge Numerics have responded on LinkedIN forums on this and seems like they are working on it. Good to know:) You can follow their comments here: www.linkedin.com/groups?home=&gid=66032

I look forward to your feedback.

Creating a Model with a Moving Wall in ANSYS CFX

Ever see those cool CFD animations of a model with a moving boundary? Ever wondered how much of a headache those are to set-up? Well it turns out it is not bad at all. I have run through a generic example below to show you how quickly you can do it in CFX.



Problem Description:
In this problem we are going to be modeling a moving wall on a tank. The assumption that the wall motion is know will be made and supplied to the CFX in a comma separated value (csv) format. The model will be general so that you can apply the method to similar problems.

Set-up:
The geometry was generated with two bodies combined in one part. The one domain, hereafter called the port, is the domain where the mesh is going to be deformed because of the moving wall. The other domain is the tank to which the fluid is being ejected. The mesh in this region will not be deformed.

So we move along to opening the mesh file in CFX and we begin by changing it over to a transient run. The next step would be to opening the Default Domain and in the panel change the Mesh Deformation option to Regions of Motion Specified. The next step is to create a sub-domain for the port region under the Default Domain. In the sub-domain panel, select the port region for the location and move over to the Mesh Motion tab.

We are going to use a specified mesh motion using ccl. In the current case the motion is in the z-direction so I specify a name of the cel expression MeshMotion which we will define next. A key point we are going to use is that we want to compress the mesh in the entire domain evenly to maintain the best quality mesh we can.

Defining a temporal functions from csv file
Since we are assuming we know the movement of the wall, we are going to read it in using a csv file. We first must make sure that it has the proper header. The header of the csv file should follow:

[Name]
SpecifiedMotion
[Spatial Fields]
X

[Data]
X [m], displacement []
…

Now the data should be a function of time. But we import it as a spatial variable. We will change it over when we define our cel expressions. To bring this file into CFX, we choose Tools -> Initialize Profile Data from the pull-down menu. After selecting the data file we notice the function is consistent with our header.

The next step is to change the spatial function into a temporal one. We will do this by creating an expression called MeshDeformation. We will then define this as SpecifiedMotion.displacement(t * 1[m] / 1 [s] ) * StrokeDistance. Note we will define StrokeDistance later.

Interpolation Functions and Other Expressions
First we will generate a function that will be used to make sure we compress the entire sub-domain evenly. We do this by generating a user-function we will call InterpolationLocation. We put unit of [m] in the Argument Units and [] for the Resulting Units. For the one-dimensional function we will supply the data pairs 0, 0 and 4, 1. We do this because the port mesh at 0 [m] will not be deformed and the port mesh at 4 [m] will deform the full amount we will specify (my port is 4 [m] long).

Next we must create our MeshMotion expression. For this we define it at MeshDeformation*InterpolationLocation(z-Total Mesh Displacement Z). Note the InterpolationLocation is the function we just defined and Total Mesh Displacement Z is the predefined expression that outputs the total mesh displacement in the z-direction relative to the initial mesh. We defined the MeshDeformation expression earlier.

The final expression we need to define is the StrokeDistance. We simply define this through a cel expression to be -4 [m]. The negative sign indicates that displacement will be in the –Z direction.

That is all there is to it. That wasn’t so bad was it? Now there are just the smaller things to add into the model such as transient result files and initial conditions. These are straightforward as in your other models. Hope you found it useful. Obviously more complexity can be built into the model, but this shows the basics of the moving mesh portion.
_____________________________________________________

Per requests, I have included some images to help you follow along.  The first image is shows how to set-up the CSV file.  Note you can do this in a text editor like notepad, or you can use Excel to develop the data and save the data as a CSV file.  Either way the ASCII data should look like:

How the CSV file should be spaced.

The next step after we generate our CSV file is to import this into CFX.  This is done by selecting from the pull-down menu Tools -> Initialize Profile Data.  Point to the location of your CSV and select OK.  If you now look under User Functions in the tree, you will see SpecifiedMotion.  Double-click this and the image below would appear.

Function from CSV File

Now that we have this we can generate our CEL expressions.  These expressions are given above and shown in the image below.

CEL for the above Example

The file piece of the puzzle is to add the InterpolationLocation user-function.  The final syntax of this user-function is shown below.  Note that the 4 is length of the chamber we wish to compress.

Using a CFX user function for interpolation

 I hope you found the original demo interesting and new images helpful in generating these types of models.  Cheers!!!

Engineering Simulation at Olympics

I have been watching Vancouver Winter Olympics 2010 with great deal of attention. My loyalties lie with US but cheer any genuinely great sporting achievement. What fascinates me is the true grit and determination of these athletes to overcome great odds to attain perfection! And knowing our passion "engineering simulation" has helped them along towards these levels of perfection really brings a huge smile on my face.

Images Courtesy: www.fluent.com

I wanted to bring light to some of the engineering simulation such as FEA, CFD etc., that goes on in preparation towards these levels of perfections.

Above images show pressure contours on a simulated skeleton slider, with pathlines colored by velocity magnitude (Postprocessed by Ensight). The story behind the simulation is as interesting as the technology itself. You can read the complete story here. The story in short goes something like this: In preparation for 2006 Winter Olympics at Turin, Italy, Kristan Bromley, the top-ranked skeleton bobsled competitor in the UK, approached the Elite Sports CFD Unit - a part of the Sports Engineering Research Group (SERG) in Sheffield, UK - and asked them to provide CFD flow simulation support to increase his chances of success. Bromley's goal:
Minimize the overall aerodynamic drag by assessing small changes in surface texture of his skin-suit. Bromley ended up with a respectable 5th ranking in Turin Winter Olympics and went on to bring home the first gold medal for Britain since 1965 at the 2008 FIBT World Championships. Bromley maintains philosophy of using advanced technology to enhance on-ice performance. Although, the CFD analysis may have been just a drop in the ocean in terms of the dedication, grit and determination for such olympic athletes, it is still atleast a drop!

More information: http://www.bromley-aet.com/

Below are a few more articles that show the role of engineering simulation that goes into such perfection!
ANSYS Article: Giving Ski Racers an Edge
FLUENT Article: CFD for Bob Sled Team
ANSYS Article: Finite Element Analysis on Mountain Climbing Ice Axe to study crack initiation on serrated blade.

Hats off to all the fantastics athletes and the engineering simulation that is enhancing their performance on ice! :)

Engineering Simulation blog... a beginning.

First question we asked ourselves is why blog? Does this help our customers? The simulation community? Does it help us?

Being an engineering simulation consulting firm and working with a wide range of customers in various industries, we see several unique simulation requirements, from leading edge to bleeding edge!  We have seen several times how what we learn in simulating for one industry can so easily be transferable to another industry; how simple tricks or having "been there, done that" would have saved us hours and hours of frustration (if not days!).  We also have done some "cool" projects which we love to share with anyone over a cocktail discussion.  We have a love-hate relationship with simulation... years of passion and also sometimes days of frustration!

So, that being said, we thought, blogging about our experiences, analyses and physics in general could be a great way to help the simulation community, our customers and also create our voice!  So, we plan to post interesting analysis stories, tricks, tips, macros, glitches, software patches (or atleast direct to the right resource), FEA vs. Testing, our perspectives and more.... If our experience, macros, resources etc., can save a few hours for a fellow analyst, we will consider our blog a success!

Let us "Engineer, Simulate and Innovate" together.

This blog is maintained by our engineering analysis group out of Rochester, NY office. 
Our blogging team (The SimuSquad) includes:
Jeff Heckman, Jason Zbick, Rolf Orsagh, Mike Sobol, Nick Lynn and Sriram "Rob" Atchutuni.