Combustion is ultimately a chemical reaction, and like any chemical reaction, it requires the right balance of ingredients. The only way to completely exhaust the reaction is to have the perfect amount of fuel (i.e. stuff to burn) and oxidizer (i.e. oxygen). When those ratios don’t match, the reaction can slow down or even appear to end, but that doesn’t mean a fire’s gone out.

Firefighters face one of the dangerous consequences of this situation in the form of backdrafts. When a fire has been burning in a sealed container and exhausted its oxygen supply, it can get extremely hot even if the flames seem to have died down. When oxygen is added back by opening a door or window, the fire can react explosively, as the Slow Mo Guys demonstrate above. The good news is that backdrafts are relatively rare and there are steps you can take to avoid them. (Image and video credit: The Slow Mo Guys)

As waves fold over and break, they trap air, creating bubbles of many sizes. The smallest of these bubbles can be only a few microns across and persist for long times compared to larger bubbles. When they burst, they create tiny droplets that can carry sea salt up into the atmosphere to seed rain. Understanding how these bubbles form and how many there are of a given size is key to predicting both oceanic and atmospheric behaviors. Numerical simulations like the one featured in the video above reveal the dynamic collisions that create these tiny bubbles and help researchers learn how to model the tiniest bubbles so that future simulations can be faster. (Image and video credit: W. Chan et al.)

When we think of resonance, we often think of it in simple terms: hit the one right note, and the wine glass will shatter. But resonance isn’t always about a one-to-one ratio between a driving frequency and the resonating system. Especially in fluid dynamics, we often see responses that occur at other, related frequencies.

One of the simplest places to see this is with a droplet bouncing on a bath of fluid. Above you see a liquid metal droplet bouncing on a bath of the same metal. At low amplitude, the pool surface moves at the driving frequency and a droplet bounces simply upon that surface, with one bounce per oscillation. Increase the amplitude, though, and the droplet’s bounce changes. It bounces twice – one large bounce and one small bounce – in the time it takes for the pool surface to go through one cycle. This is called period doubling because the bouncing occurs at twice the driving frequency.

Turn the amplitude up further, and the system undergoes another change. Faraday waves form on the surface. They resonate at half the driving frequency, and a droplet’s bouncing will sync up with the waves. That means the droplet returns to a one-to-one bounce with the waves, but the waves themselves are no longer reacting at the driving frequency. It’s this kind of complexity that makes fluid systems fertile grounds for studying paths toward chaos. (Image and research credit: X. Zhao et al.)

One of the deadliest features of some volcanic eruptions is the pyroclastic flow, a current of hot gas and volcanic ash capable of moving hundreds of kilometers an hour and covering tens of kilometers. Since volcanic particles have a high static friction, it’s been something of a mystery how the flows can move so quickly. Using large-scale experiments (top), researchers are now digging into the details of these fast-moving flows.

What they found is that the two-phase flow results in a pressure gradient that tends to force gases downward. This creates a gas layer with very little friction near the bottom of the pyroclastic flow (bottom), essentially lubricating the entire flow with air. This helps explain why pyroclastic flows are so fast and long-lived despite their inherent friction and the roughness of the terrain over which they flow. (Image and research credit: G. Lube et al.; video credit: Nature; submitted by Kam-Yung Soh)

The coalescence of two water droplets happens so quickly, it’s essentially impossible to see, even with high-speed cameras. For this reason, researchers have turned to simulating molecular dynamics – essentially building computer programs that model the actions of all the molecules contained in the water droplets. Viewed this way, the very first contact between drops comes from thermal fluctuations – the random jumping of molecules across the separating gap. Once the bridge starts to form, it continues to grow, driven by thermal forces and opposed by surface tension. Eventually, this thermal regime gives way to the more familiar hydrodynamic one, where the bridge is large enough for flow to drive its growth. (Image credits: experiment - S. Nagel et al.; simulation - S. Perumanath et al.; research credit: S. Perumanath et al.; submitted by Rohit P.)

Antlion larvae dig sandpits to catch their prey, and, according to a new study, they rely on the physics of granular materials to do so. The antlion digs in a spiral pattern (bottom), beginning from the outside and working its way inward. As it digs, it ejects larger grains and triggers avalanches that cause large grains to fall inward. This leaves the walls of the final pit lined with small grains, which have a shallower angle of repose and will slip out from under any prey that wander in. The subsequent avalanche will carry the victim to the antlion lying in wait at the center of the pit. (Image credits: antlion larva - J. Numer; antlion digging - N. Franks et al.; research credit: N. Franks et al.; submitted by Kam-Yung Soh)

It turns out that Computational Fluid Dynamics (CFD) has a key role to play in determining the behavior of long extinct creatures. In a previous, post we described a CFD study of parvancorina, and now Pernille Troelsen at Liverpool John Moore University is using CFD for insights into how long-necked plesiosaurs might have swum and hunted.

CFD Water Flow Simulation over an Idealized Plesiosaur: Streamline VectorsIllustration only, not part of the study

read more

Fossilized imprints of Parvancorina from over 500 million years ago have puzzled paleontologists for decades. What makes it difficult to infer their behavior is that Parvancorina have none of the familiar features we might expect of animals, e.g., limbs, mouth. In an attempt to shed some light on how Parvancorina might have interacted with their environment researchers have enlisted the help of Computational Fluid Dynamics (CFD).

CFD Water Flow Simulation over a Parvancorina: Forward directionIllustration only, not part of the study

read more

One of nature's smallest aerodynamic specialists - insects - have provided a clue to more efficient and robust wind turbine design.

Dragonfly: Yellow-winged DarterLicense: CC BY-SA 2.5, André Karwath

read more

The recent attempt to break the 2 hour marathon came very close at 2:00:24, with various aids that would be deemed illegal under current IAAF rules. The bold and obvious aerodynamic aid appeared to be a Tesla fitted with an oversized digital clock leading the runners by a few meters.

2 Hour Marathon Attempt

read more

The Giro d'Italia 2017 is in full swing, so how about an extensive aerodynamic study of various cycling tuck positions? You got it, from members of the same team that brought us the study of pursuit vehicles reducing the drag on cyclists.

Chris Froome TuckStage 8, Pau/Bagnères-de-Luchon, Tour de France, 2016

read more

Early on in the dash to develop ever faster racecars in the 1970s, aerodynamics, and specifically downforce, proved a revelation. Following on quickly from the initial passive downforce initiatives were active aerodynamic solutions. Only providing downforce when needed (i.e., cornering and braking) then reverting to a low drag configuration was an ideal protocol, but short lived due to rule changes in most motor sports (including Formula 1), which banned active aerodynamics. A recent exception to the rule is the highly regulated Drag Reduction System now used in F1. However, road-legal cars are not governed by such regulations and so we have the gloriously unregulated Lamborghini Huracán Performante.

Active Aerodynamics on the Lamborghini Huracán Performante

read more

Here is a useful little tool for calculating the properties across a normal shock.

If you found this useful, and have the need for more, visit www.stfsol.com. One of STF Solutions specialties is providing our clients with custom software developed for their needs. Ranging from custom CFD codes to simpler targeted codes, scripts, macros and GUIs for a wide range of specific engineering purposes such as pipe sizing, pressure loss calculations, heat transfer calculations, 1D flow transients, optimization and more. Visit STF Solutions at www.stfsol.com for more information!

Disclaimer: This calculator is for educational purposes and is free to use. STF Solutions and curiosityFluids makes no guarantee of the accuracy of the results, or suitability, or outcome for any given purpose.

Here, I’ll cover the basic workflow that I implement when I am using cfMesh.

First, when do I use cfMesh? I love cfMesh. I find it robust, easy to use (with this workflow), and gives high quality hex-dominant meshes for use with OpenFOAM. But there are a few cases where I do not use cfMesh. These are when I am meshing multiple regions (such as rotating zones or conjugate heat transfer) and when I have decided (for some reason) that I am going to do a tet-dominant mesh. With that said, both of those can be accomplished with cfMesh, but I prefer snappyHexMesh for multi-region meshing, and I prefer the built-in Netgen, and gmsh modules of Salome if I am doing a tet-mesh.

What do you need to start?

• For this workflow using cfMesh, you will obviously need a working installation of cfMesh. Luckily it now comes preloaded as part of OFv18. Even if you prefer a different openfoam flavor, you can use the OFv18 cfMesh to create the mesh, and the mesh will still work in the other flavors.
• You will also need a working installation of Salome.

Geometry Preparation

Typically, I first start in a CAD program (it doesn’t matter which) and produce a 3D .step, .iges, or .brep representation of the fluid domain. This means that if you are doing an internal flow, you want a geometry file representing everywhere the fluid will go. For an external flow, you want a large open domain with your geometry subtracted from it. This is easily accomplished with a simple Boolean subtraction. You can do this in pretty much any CAD programs. If you are like me and frequently just get the CAD file from a client, I usually load it into the CAD, draw my fluid domain, and perform the subtraction. My CAD software of choice is Onshape (primarily for cost reasons and its similarity Solidworks). Alternatively you can perform boolean subtractions directly in Salome.

For an example, I’ll use the Glider geometry shown in the figure above. I downloaded this model from Grabcad, loaded it into Onshape, cleaned up some of the surfaces and subtracted the glider from a fluid domain:

FMS File Preparation

FMS is the recommended file format for using cfMesh as it contains all of the information that the mesher needs. Even as a relatively heavy user of cfMesh I never knew the answer to the question HOW DO I PRODUCE A FULL FMS FILE?. Yes, you can use the surfaceFeatureEdges script from cfMesh to create an FMS file from your stl or obj file, but these files don’t typically contain all of the patch information you want.

For a very long time, I used cfMesh using a very tedious workflow where I would convert my geometry to fms or ftr, mesh it in using automatic patch naming from cfMesh, load it into paraview, and manually see which patch was which. Needless to say this was time consuming and frustrating. In one project, I was modeling a diffuser with over 100 slots in it. surfaceFeatureEdges extracted all of the sides of the slots as separate patches. I then manually renamed them all.. ugh. Luckily, I have learned my lesson, and I can share with you the trick. Salome.

cfMesh actually comes with two python scripts for Salome. These can be used to output an fms file that contains ALL of the information you need, and also lets you use the Salome GUI to name patches and refinement boundaries.

Selecting Patches

Back on topic: First load your STEP, IGES, or BREP file into geometry module of Salome. Now, we want to create and name our patches. To do this, use the menu New Entity -> Group -> Create Group. Make sure the geometry file is selected in the tree. A window will open where you can select points, edges, surfaces, or solids. We want surfaces.

Type the name of the patch you are going to select. Select the face in the viewer, and click add. Finally hit apply. Repeat this for each patch. In most cases, you will need to hide some surfaces to see the surfaces of the geometry. In those cases, just select the faces you aren’t currently selecting and then hit “Hide Selected”.

Extract Edges

Before we move on to creating our surface mesh, we should extract our edges for cfMesh. This is done by executing the “ExtractFeatureEdges.py” python script. Select your the geometry file in the tree, hit CTRL-t, then select the script. If you are running OF1806, it is located in OpenFOAM-v1806/modules/cfmesh/python/Salome.

Generate Surface Mesh

It seems tedious to generate a mesh… before generating a mesh. But rest assured we are only creating a surface mesh. And it should run fast, unless you have a complicated geometry. Regardless, if you choose the default settings of either Netgen 1D-2D, or Mefisto with adaptive wire discretization, it should be fast and produce a good surface triangulation. I have had one slow case, but with tweaking the settings a bit, it wasn’t a problem. For this glider example here, I used a Mefisto meshing and wire discretization on the glider edges to control the grid size.

After building the mesh (hitting the little gear button), we now just need to load our patches from the geometry module, and export to an FMS file.

Within the mesh module, select your mesh, and then go to Mesh->Create Groups from Geometry . Select your patches AND your featureEdges (as cfMesh needs these) and hit Apply and Close.

Finally, we are ready to export to an FMS file. To do this, select your mesh on the tree. First you load the Salome module. Hit CTRL-t, and select the salomeTriSurf.py python script. This only loads the module. Now, in the python shell at the bottom the screen you write: triSurf().writeFms(‘FileName.fms’) and hit enter. This only takes a few seconds then writes the FMS file in your Salome directory. Copy it into your OpenFOAM directory and you are ready to mesh it with cfMesh.

Mesh Using cfMesh

From here on out, is basic cfMesh meshing. In your system/meshDict file you must select the FileName.fms that you created in the previous steps. I will not cover the meshDict options I used here, as the focus of this article was on the workflow described in the previous sections. But here are some images of the type of results you can expect from cfMesh:

As the general usage of cfMesh is covered in detail in the cfMesh manual, and in another post (the Ahmed Body) I will just give a couple tips and tricks here. A specific Tips and Tricks post may follow.

Use renameBoundary dict to simplify your case

In this workflow, I usually create surfaces for refinement within Salome, and export them. However, having a bunch of different patches can be a bit of a pain. To address this, I export the patches from Salome, select them for refinement within my meshDict, but also rename them in the renameBoundary sub-dict. If you have multiple patches renamed to the same thing, they all get grouped into a single patch. So you can have 10 different refinement patches that you created, but then group them all into a single patch afterwards. Making case setup simpler.

Use the generateBoundaryLayers command

I have found that I get much better results if I first mesh without boundary layers, and then add them after using the generateBoundaryLayers command. This is for a couple reasons. First, this lets you look at the basic mesh and make sure that it is satisfactory. Your mesh without boundary layers should be as high quality as you can make it. Secondly, you can see how the layer addition affects the final mesh. Layer addition can be somewhat an art. And doing it separately makes this much easier. If your base mesh has bad quality, it will be even worse after layering.

Use the crinkle-slice option in Paraview

When viewing your mesh, make sure to select the “crinkle-slice” option when viewing your mesh. If you just take a regular slice (a) you aren’t seeing the actual cells you are seeing a slice of them, and (b) the rendering puts some cross lines which don’t actually exist. You want to see the actual cells, and without extra non-existent lines.

Use the improveMeshQuality command

In some cases where I have had bad mesh quality, I have improved it by running the improveMeshQuality command. It basically runs through some of the improvement algorithms that are executed during the actual meshing, but runs through them again. I have had some success with it, but havent used it extensively. Try your best to have a good mesh quality right from the get-go (duh).

Use checkMesh

This sounds obvious… but checkMesh works. It gives you important statistics on the quality of your mesh. In my experience, take a very close note of nonOrthogonality. If it is high (>70 or so), you need to improve your mesh or introduce some special schemes to account for this. Regardless, you should know how orthogonal your mesh is.

Use .eMesh files for additional control

For some shapes, you may need extra refinement based on edges instead of faces. In this case, you can use the edgeMeshRefinement sub-dict and use an eMesh or vtk file defining the edges.

Good Luck!

If you are struggling with CFD, are interested in getting started, or are looking for consulting services, visit http://www.stfsol.com for information on CFD consulting services including training, development, private webinars and other simulation services.

When working on practical engineering applications, you often encounter problems where there are significant changes in temperature locally in the flow field. For instance, if you are doing a heat transfer calculation, you usually want to use the film properties (aka the properties adjacent to the wall). Doing this in any practical sense requires a model for viscosity and thermal conductivity.

For pure, non-reacting gas, the viscosity is only dependent on temperature (Anderson 2006). Therefore, viscosity can be modelled using temperature alone. One of these models, and one that is built in with software like OpenFOAM, is the Sutherland’s law.

It is given by:

It is also often simplified (as it is in OpenFOAM) to:

The right hand side gives the OpenFOAM notation. For air, , .

The coefficients for several other gases can be found in Frank White’s Viscous Fluid Flow (2006).

When is it applicable?

This is an important question. If you are doing engineering or research, you should know the limits of these equations. According to Anderson (2006), “Sutherland’s law is accurate for air over a range of several thousand degrees and is certainly appropriate for hypersonic viscous-flow calculations”. In the crucial undergraduate textbook by Frank White, states that it is “adequate over a wide range of temperatures”.

For air, another source (Rathakrishnan 2013) states that the relationship is valid from 0.01 to 100 atm, and between 0 and 3000K. And Frank White’s Viscous Fluid Flow mentions 2% error between 170K and 1900K for air.

What if you can’t find the coefficients?

If you can’t find a good reference listing the coefficients of the gas you are looking at, one option is to head over to the NIST Webbook, download 2 viscosity values at two different temperatures and solve for the 2 coefficients. Or curve-fit in Matlab using a series of data from NIST or some other source. Basically, something along those lines. This is explained in the undergraduate book by Munson (2014).

FYI that is a good idea anyway, if you want to quantify the error in your work or simulations.

References

Rathakrishnan, E. (2013). Theoretical aerodynamics. John Wiley & Sons.

Anderson Jr, J. D. (2006). Hypersonic and high-temperature gas dynamics. American Institute of Aeronautics and Astronautics.

Munson, B. R., Okiishi, T. H., Rothmayer, A. P., & Huebsch, W. W. (2014). Fundamentals of fluid mechanics. John Wiley & Sons.

White, F. M. (2009). Fluid mechanics. Boston, Mass: WCB/McGraw-Hill.

White, F. M., & Corfield, I. (2006). Viscous fluid flow (Vol. 3, pp. 433-434). New York: McGraw-Hill.

Here is a little calculator for calculating the properties of air. Enter the pressure (Pa) and Temperature (K), and the calculator should produce an estimate for the specific heat capacities, thermal conductivity, and density.

For information on Sutherland’s law, see the post on the topic.
If you found this useful, and have the need for more, visit www.stfsol.com. One of STF Solutions specialties is providing our clients with custom software developed for their needs. Ranging from custom CFD codes to simpler targeted codes, scripts, macros and GUIs for a wide range of specific engineering purposes such as pipe sizing, pressure loss calculations, heat transfer calculations, 1D flow transients, optimization and more. Visit STF Solutions at www.stfsol.com for more information!

Here, I’ll give a high-level overview of my opinions on open-source meshing for OpenFOAM. This post should help point you in direction of the mesher you could use to accomplish your simulating goals! But I won’t go into each mesher in detail here. As this would become a novel. This is just my opinion on what mesher I use in a few typical cases.

During my PhD we were very spoiled and used the software Pointwise to generate our meshes. I still love Pointwise, and if I ever decide to move away from open source meshing that will be my choice. But today is not that day! For users of open-sources software, including OpenFOAM, meshing is a constant struggle. Especially if you’re new. I have even known people who thought about using OpenFOAM and then gave up simply because they thought that blockMesh was the only way to make meshes in OpenFOAM. If that were the case – needless to say – countless applications would be impossible. Don’t give up! You can mesh pretty much anything given the tools that are out there!

In my experience the key meshing options for the user of OpenFOAM are:

• blockMesh (All version of OF)
• cfMesh (OF.org <=v4, foam-extend, OF.com V18+)
• SnappyHexMesh (All versions of OF)
• gmsh (independent)
• Salome (independent)

Of these, each meshing software has its own advantages and disadvantages and have types of meshing where they perform the best. I’ll try to break this down based on my experience. Of course, some people will disagree with my views as meshing (somehow) can be a deeply personal adventure.

Structured 2D or Simple 3D Meshes

In this case, the answer is pretty simple: blockMesh

blockMesh has a slightly steep learning curve but all it takes is practice and reminding yourself of the right-hand-rule. If your geometry is easily represented by a reasonable number of points and curves – blockMesh is a good option. You would be surprised what you can mesh in blockMesh – if you have the time… but who has the time! That being said, blockMesh is the ideal OpenFOAM mesher for simple 2D and 3D geometries. Because it is essentially a “structured” mesher you easily achieve very good mesh quality, excellent orthogonality, and have fine control over the mesh in ways unstructured meshers do not provide. (NOTE: Structured vs Unstructured has become a blurry terminology, and in fact, all OF meshes are unstructured…. even if you use a blocking strategy… Ugh.).

A major advantage of using the native OpenFOAM meshers is that they can interface seamlessly with whatever scripting language you prefer. If your code can interface with the OS, it can interface with OpenFOAM – and by extension its meshers. I frequently use blockMesh to build a template. I then leave blanks where my control variables will go and then fill them in at run-time using either bash or python scripting! This makes parametric studies a breeze.

Tetrahedral (Tet-Dominant) Meshes

There are lots of limitations of using tet-dominant meshes in CFD. However, I won’t go into those here. There are many times when a tet-mesh is the most straight-forward to produce. If you don’t have important boundary layer zones to produce, ripping out a quick tet-mesh can have huge time savings.

In these cases, I usually use either Salome’s built-in Netgen module or gmsh. cfMesh has a tet-mesh generator as well, but if I’m using cfMesh I am always using a hex-dominant mesh.

Key to the effective generation of tetrahedral dominant meshes is the ability to generate layers at the wall. This can be a challenge in each of these programs. So no matter what you use – prepare to be patient. I have found that the boundary layer generation in Salome is quite robust. However, it occasionally produces some very poor quality regions which you need to be careful of. I have not had much success with layer generation in gmsh, but if I’m being honest, I haven’t spent too long trying. I have other tools – and generally prefer hex-meshes anyway.

Hex-Dominant Meshing

For hex-dominant meshing, your options are blockMesh (if you can create your geometry easily enough), cfMesh, or snappyHexMesh.

snappyHexMesh is a pretty nice tool, and is my mesher of choice for any multi-region meshing (see next section). But compared to cfMesh I find it much less robust. The key area where this is true is in layer generation. There are ways to get consistent layer generation in snappyHexMesh (i.e. providing a separate meshQualityDict where you turn off many of the paraemeters) but even then it can still be challenging. I have found that in almost all cases, I can achieve consistent, high-quality, boundary layers using cfMesh. Not only this, but I have found the workflow using cfMesh to be a breeze. Especially if you use the supplied Salome scripts to produce your geometry file (separate post on this to follow).

Multi-Region Meshing

Multi-region meshing is required for several different applications. The main ones I have encountered are rotating zones (for machinery and turbines), and conjugate heat transfer (for separate solid and fluid regions). For multi-region meshing in OpenFOAM, I almost always use snappyHexMesh. The primary reason for this is that is extremely simple to create in your workflow. As an example, let’s consider the case of a simulation where you plan to have rotating and static zones separated by an arbitrary mesh interface (AMI). When using cfMesh, gmsh, or Salome you typically have to create both meshes, and then combine them using the mergeMeshes command. This is can be very tedious. However, in some cases it can be worth it if you can achieve better mesh quality with one of these programs. However, you can definitely get good mesh quality with snappyHexMesh.

A sobering exercise

If you want a sobering exercise, google the Drag Prediction Workshop website, get the geometry, and try to mesh it using open source software and meet their gridding requirements. Here are some of the requirements for the COARSEST MESH:

• Minimum of 8 cells across the trailing edge of the wing
• Y+ < 1.0 (equivalent to dy=0.0006 mm)
• 2 cells close to the wall with no growth
• Growth rate <1.25 for the rest of the layers

The list goes on – and some of the example meshes will have 20+ layers.

Anyway, I hope someone finds this post useful to point them in the direction of a good meshing software for their application!

If you are struggling with CFD, are interested in getting started, or are looking for consulting services, visit www.stfsol.com for information on CFD consulting services including training, development, private webinars and other simulation services.

Happy Open-Source Gridding!

Here is a simple tool to calculate the pressure drop along a pipe. It uses the Haaland equation for friction factor to approximate the Colebrook equation. If Re<2300 the flow is assumed to be laminar.

If you find a mistake in the calculation, please let us know!

If you found this useful, and have the need for more, visit www.stfsol.com. One of STF Solutions specialties is providing our clients with custom software developed for their needs. Ranging from custom CFD codes, to codes, scripts, macros and GUIs for a specific engineering purpose such as pipe sizing, pressure loss calculations and optimization. Visit STF Solutions at www.stfsol.com for more!

• Built-in automatic grid generation
• Built-in 3D compressible Euler Solver for fast aerodynamics analysis.
• Built-in 3D laminar Navier-Stokes solver
• Built-in 3D Reynolds Averaged Navier-Stokes (RANS) solver
• Multi-core flow solver processing on your Windows laptop or desktop using OpenMP
• Inputs STL files for processing
• Built-in wing/hydrofoil geometry creation tool
• Enables stability derivative computation using quasi-steady rigid body rotation
• Up to 100 actuator disc (RANS solver only) for simulating jets and prop wash
• Reports the lift, drag and moment coefficients
• Reports the lift, drag and moment magnitudes
• Plots surface pressure, velocity, Mach number and temperatures
• Produces 2-d plots of Cp and other quantities along constant coordinates line along the structure

• Ability to handle complex geometries, and ease of mesh generation
• Robustness for a wide variety of flow problems
• Scalability on supercomputers

(a) hpMusic 3rd Order, 9.6M DOFs

(b) Commercial Solver, 2nd Order, 28.7M DOFs

Figure 1. Comparison of Q-criterion and Schlieren  

I certainly believe high-order solvers are ready for industrial LES. In fact, the commercial version of our high-order solver, hoMusic (pronounced hi-o-music), is announced by hoCFD LLC (disclaimer: I am the company founder). Give it a try for your problems, and you may be surprised. Academic and trial uses are completely free. Just visit hocfd.com to download the solver. A GUI has been developed to simplify problem setup. Your thoughts and comments are highly welcome.

Happy 2018!     

• Leicester won the Premier League in England defying odds of 5000 to 1
• Cubs won World Series after 108 years waiting

A Tank outside my taxi

A beautiful night in Zurich

The trip back to the US was complicated by the fact that the FAA banned all direct flight from Turkey. I was lucky enough to find a new flight, with a stop in Zurich...

In 2016, I lost a very good friend, and CFD pioneer, Professor Jaw-Yen Yang. He suffered a horrific injury from tennis in early 2015. Many of his friends and colleagues gathered in Taipei on December 3-5 2016 to remember him.

This is a CFD blog after all, and so it is important to show at least one CFD picture. In a validation simulation [1] with our high-order solver, hpMusic, we achieved remarkable agreement with experimental heat transfer for a high-pressure turbine configuration. Here is a flow picture.

Computational Schlieren and iso-surfaces of Q-criterion

To close, I wish all of you a very happy 2017!

1. Laskowski GM, Kopriva J, Michelassi V, Shankaran S, Paliath U, Bhaskaran R, Wang Q, Talnikar C, Wang ZJ, Jia F. Future directions of high fidelity CFD for aerothermal turbomachinery research, analysis and design, AIAA-2016-3322.

Illini EV Concept Team Photo at Shell Eco Marathon 2018

Weight is the enemy of all teams that design electric cars for the Shell Eco Marathon.

Reducing the weight of electric cars improves the vehicle’s acceleration and power efficiency. These performance improvements make all the difference come race day.

However, if the car’s weight is reduced too much, it could lead to safety concerns.

Illini EV Concept (Illini) is a Shell Eco Marathon team out of the University of Illinois. Team members use ANSYS academic research software to optimize the chassis of their electric car without compromising safety.

Where to Start When Reducing the Weight of Electric Cars?

Front bump composite failure under a load of 2000N.

The first hurdle of the Shell Eco Marathon is an initial efficiency contest. Only the best teams from this efficiency assessment even make it into the race.

Therefore, Illini concentrates on reducing the most weight in the shortest amount of time to ensure it makes it to the starting line.

Illini notes that its focus is on reducing the weight of its electric car’s chassis.

“The chassis is by far the heaviest component of our car, so ANSYS was used extensively to help design our first carbon fiber monocoque chassis,” says Richard Mauge, body and chassis leader for Illini.

“Several loading conditions were tested to ensure the chassis was stiff enough and the carbon fiber did not fail using the composite failure tool,” he adds.

Competition regulations ensure the safety of all team members. These regulations state that each team must prove that their car is safe under various conditions. Simulation is a great tool to prove a design is within safety tolerances.

“One of these tests included ensuring the bulkhead could withstand a 700 N load in all directions, per competition regulations,” says Mauge. If the teams’ electric car designs can’t survive this simulation come race day, then their cars are not racing.

Iterate and Optimize the Design of Electronic Cars with Simulation

Front bump deformation under a load of 2000N.

Simulations can do more than prove a design is safe. They can also help to optimize designs.

Illini uses what it learns from simulation to optimize the geometry of its electric car’s chassis.

The team found that its new designs have a torsional rigidity increase around 100 percent. This is after a 15 percent decrease in weight compared to last year’s model.

“Simulations ensure that the chassis is safe enough for our driver. It also proved that the chassis is lighter and stiffer than ever before. ANSYS composite analysis gave us the confidence to move forward with our radical chassis redesign,” notes Mauge.

The story optimization story continues from Illini. It plans to explore easier and more cost-effective ways to manufacture carbon fiber parts. For instance, the team wants to replace the core of its parts with foam and increase the number of bonded pieces.

If team members just go with their gut on these hunches, they could find themselves scratching their heads when something goes wrong. However, with simulations, the team makes better informed decisions about its redesigns and manufacturing process.

To get started with simulation, try our free student download. For student teams that need to solve in-depth problems, check out our software sponsorship program.

The post How to Increase the Acceleration and Efficiency of Electric Cars for the Shell Eco Marathon appeared first on ANSYS.

This engine intake simulation was post-processed using EnSight Enterprise. This allowed for the processing of a large data set to be shared among servers.

Simulation data sets have a funny habit of ballooning as engineers move through the development cycle. At some point, post-processing these data sets on a single machine becomes impractical.

Engineers can speed up post-processing by spatially or temporally decomposing large data sets so they can be post-processed across numerous servers.

The idea is to utilize the idle compute nodes you used to run the solver in parallel to now run the post-processing in parallel.

In ANSYS 19.2 Ensight Enterprise you can spatially or temporally decompose data sets. Ensignt Enterprise is an updated version of EnSight HPC.

Post-Processing Using Spatial Decomposition

EnSight is a client/server architecture. The client program takes care of the graphical user interface (GUI) and rendering operations, while the server program loads the data, creates parts, extracts features and calculates results.

If your model is too large to post-process on a single machine, you can utilize the spatial decomposed parallel operation to assign each spatial partition to its own EnSight Server. A good server-to-model ratio is one server for every 50 million elements.

Each EnSight Server can be located on a separate compute node on any compute resource you’d like. This allows engineers to utilize the memory and processing power of heterogeneous high-performance computing (HPC) resources for data set post-processing.

The engineers effectively split the large data set up into pieces with each piece assigned to its own compute resource. This dramatically increases the data set sizes you can load and process.

Once you have loaded the model into EnSight Enterprise, there are no additional changes to your workflow, experience or operations.

Post-Processing Using Temporal Decomposition

Keep in mind that this decomposition concept can also be applied to transient data sets. In this case, the dataset is split up temporally rather than spatially. In this scenario, each server receives its own set of time steps.

A turbulence simulation created using EnSight Enterprise post-processing

EnSight Enterprise offers performance gains when the server operations outweigh the communication and rendering time of each time step. Since it’s hard to predict network communication or rendering workloads, you can’t easily create a guiding principle for the server-to-model ratio.

However, you might want to use a few servers when your model has more than 10 million elements and over a hundred time steps. This will help keep the processing load of each server to a moderate level.

How EnSight Speeds Up the Post-Processing of Large Simulation Data Sets

Another good tip to ensure you are post-processed optimally within EnSight Enterprise. Engineers achieve the best performance gains by pre-decomposing the data and locating it locally to the compute resources they anticipate using. Ideally, this data should be in EnSight Case format.

To learn more, check out Ensight or register for the webinar Analyze, Visualize and Communicate Your Simulation Data with ANSYS EnSight.

The post Post-Processing Large Simulation Data Sets Quickly Over Multiple Servers appeared first on ANSYS.

Your design team will make informed decisions about the products they create when they bring detailed simulations up front in the development cycle.

The 19.2 release of ANSYS Discovery AIM facilitates the need of early simulations.

It does this by streamlining templates for physics-aware meshing and rapid results.

High-Fidelity Simulation Through Physics-Aware Meshing

Discovery AIM user interface with a solution fidelity slide bar (top left), area of interest marking tool (left, middle), manual mesh controls (bottom, center) and a switch to turn the mesh display on and off (right, top).

Analysts have likely told your design team about the importance of a quality mesh to achieve accurate simulation results.

Creating high quality meshes takes time and specialized training. Your design team doesn’t likely have the time or patience to learn this art.

To account for this, Discovery AIM automatically incorporates physics-aware meshing behind the scenes. In fact, your design team doesn’t even need to see the mesh creation process to complete the simulation.

This workflow employs several meshing best practices analysts typically use. The tool even accounts for areas that require mesh refinements based on the physics being assessed.

For instance, areas with a sliding contact gain a finer mesh so the sliding behavior can be accurately simulated. Additionally, areas near the walls of fluid-solid interfaces are also refined to ensure this interaction is properly captured. Physics-aware meshing ensures small features and areas of interests won’t get lost in your design team’s simulation.

The simplified meshing workflow also lets your design team choose their desired solution fidelity. This input will help the software balance the time the solver takes to compute results with the accuracy of the results.

Though physics-aware meshing can create the mesh under the hood of the simulation process, it still has tools allowing user-control of the mesh. This way, if your design team chooses to dig into the meshing details — or an analyst decides to step in — they can finely tune the mesh.

Capabilities like this further empower designers as techniques and knowledge traditionally known only by analysts are automated in an easy-to-use fashion.

Gain Rapid Results in Important Areas You Might Miss

The 19.2 release of Discovery AIM has seen improvements with its ability to enable your design team to explore simulation results.

Many analysts will know instinctively where to focus their post-processing, but without this experience, designers may miss areas of interest.

Discovery AIM enables the designer to interactively explore and identify these critical results. These initial results are rapidly displayed as contours, streamlines or field flow lines.

Field flow and streamlines for an electromagnetics simulation

Once your design team finds locations of interest within the results, they can create higher fidelity results to examine those area of interest in further detail. Designers can then save the results and revisit them when comparing design points or after changing simulation inputs.

To learn more about other changes to Discovery AIM — like the ability to directly access fluid results — watch the Discovery AIM 19.2 release recorded webinar or take it for a test drive.

The post Discovery AIM Offers Design Teams Rapid Results and Physics-Aware Meshing appeared first on ANSYS.

Traditional chemotherapy can often be blocked by a tumor’s stroma.

There are few illnesses as crafty as pancreatic cancer. It spreads like weeds and resists chemotherapy.

Pancreatic cancer is often asymptomatic, has a low survival rate and is often misdiagnosed as diabetes. And, this violent killer is almost always inoperable.

The pancreatic tumor’s resistance to chemotherapy comes from a shield of supporting connective tissue, or stroma, which it builds around itself.

Current treatments attempt to overcome this defense by increasing the dosage of intravenously administered chemotherapy. Sadly, this rarely works, and the high dosage is exceptionally hard on patients.

Nonetheless, doctors need a way to shrink these tumors so that they can surgically remove them without risking the numerous organs and vasculature around the pancreas.

“We say if you can’t get the drugs to the tumor from the blood, why not get it through the stroma directly?” asks William Daunch, CTO at Advanced Chemotherapy Technologies (ACT), an ANSYS Startup Program member. “We are developing a medical device that implants directly onto the pancreas. It passes drugs through the organ, across the stroma to the tumor using iontophoresis.”

By treating the tumor directly, doctors can theoretically shrink the tumor to an operable size with a smaller dose of chemotherapy. This should significantly reduce the effects of the drugs on the rest of the patient’s body.

How to Treat Pancreatic Cancer with a Little Electrochemistry

Simplified diagram of the iontophoresis used by ACT’s chemotherapy medical device.

Most of the drugs used to treat pancreatic cancer are charged. This means they are affected by electromotive forces.

ACT has created a medical device that takes advantage of the medication’s charge to beat the stroma’s defenses using electrochemistry and iontophoresis.

The device contains a reservoir with an electrode. The reservoir connects to tubes that connect to an infusion pump. This setup ensures that the reservoir is continuously filled. If the reservoir is full, the dosage doesn’t change.

The tubes and wires are all connected into a port that is surgically implanted into the patient’s abdomen.

A diagram of ACT’s chemotherapy medical device.

The circuit is completed by a metal panel on the back of the patient.

“When the infusion pump runs, and electricity is applied, the electromotive forces push the medication into the stroma’s tissue without a needle. The medication can pass up to 10 to 15 mm into the stroma’s tissue in about an hour. This is enough to get through the stroma and into the tumor,” says Daunch.

“Lab tests show that the medical device was highly effective in treating human pancreatic cancer cells within mice,” added Daunch. “With conventional infusion therapy, the tumors grew 700 percent and with the device working on natural diffusion alone the tumors grew 200 percent. However, when running the device with iontophoresis, the tumor shrank 40 percent. This could turn an inoperable tumor into an operable one.” Subsequent testing of a scaled-up device in canines demonstrated depth of penetration and the low systemic toxicity required for a human device.

Daunch notes that the Food and Drug Administration (FDA) took notice of these results. ACT’s next steps are to develop a human clinical device and move onto to human safety trials.

Simulation Optimized the Fluid Dynamics in the Pancreatic Cancer Chemotherapy Implant

Before these promising tests, ACT faced a few design challenges when coming up with their chemotherapy implant.

For example, “There was some electrolysis on the electrode in the reservoir. This created bubbles that would change the electrode’s impedance,” explains Daunch. “We needed a mechanism to sweep the bubbles from the surface.”

An added challenge is that ACT never knows exactly where doctors will place the device on the pancreas. As a result, the mechanism to sweep the bubbles needs to work from any orientation.

Simulations help ACT design their medical device so bubbles do not collect on the electrode.

“We used ANSYS Fluent and ANSYS Discovery Live to iterate a series of designs,” says Daunch. “Our design team modeled and validated our work very quickly. We also noticed that the bubbles didn’t need to leave the reservoir, just the electrode.”

“If we place the electrode on a protrusion in a bowl-shaped reservoir the bubbles move aside into a trough,” explains Daunch. “The fast fluid flow in the center of the electrode and the slower flow around it would push the bubbles off the electrode and keep them off until the bubbles floated to the top.”

As a result, the natural fluid flow within the redesigned reservoir was able to ensure the bubbles didn’t affect the electrode’s impedance.

To learn how your startup can use computational fluid dynamics (CFD) software to address your design challenges, please visit the ANSYS Startup Program.

The post Simulation Optimizes a Chemotherapy Implant to Treat Pancreatic Cancer appeared first on ANSYS.

The demand for wireless communications with high data transfer rates is growing.

Consumers want wireless 4K video streams, virtual reality, cloud backups and docking. However, it’s a challenge to offer these data transfer hogs wirelessly.

Peraso aims to overcome this challenge with their W120 WiGig chipset. This device offers multigigabit data transfers, is as small as a thumb-drive and plugs into a USB 3.0 port.

The chipset uses the Wi-Fi Alliance’s new wireless networking standard, WiGig.

This standard adds a 60 GHz communication band to the 2.4 and 5 GHz bands used by traditional Wi-Fi. The result is higher data rates, lower latency and dynamic session transferring with multiband devices.

In theory, the W120 WiGig chipset could run some of the heaviest data transfer hogs on the market without a cord. Peraso’s challenge is to design a way for the chipset to dissipate all the heat it generates.

Peraso uses the multiphysics capabilities within the ANSYS Electronics portfolio to predict the Joule heating and the subsequent heat flow effects of the W120 WiGig chipset. This information helps them iterate their designs to better dissipate the heat.

How to Design High Speed Wireless Chips That Don’t Overheat

Systems designers know that asking for high-power transmitters in a compact and cost-effective enclosure translates into a thermal challenge. The W120 WiGig chipset is no different.

A cross section temperature map of the W120 WiGig chipset’s PCB. The map shows hot spots where air flow is constrained by narrow gaps between the PCB and enclosure.

The chipset includes active/passive components and two main chips that are mounted on a printed circuit board (PCB). The system reaches considerably high temperatures due to the Joule heating effect.

To dissipate this heat, design engineers include a large heat sink that connects only to the chips and a smaller one that connects only to the PCB. The system is also enclosed in a casing with limited openings.

Simulation of the air flow around the W120 WiGig chipset without an enclosure. Simulation was made using ANSYS Icepak.

Traditionally, optimizing this set up takes a lot of trial and error as measuring the air flow within the enclosure would be challenging.

Instead, Peraso uses ANSYS SIwave to simulate the Joule heating effects of the system. This heat map is transferred to ANSYS Icepak, which then simulates the current heat flow, orthotropic thermal conductivity, heat sources and other thermal effects.

This multiphysics simulation enables Peraso to predict the heat distribution and the temperature at every point of the W120 WiGig chipset.

From there, Peraso engineers iterate their designs until they reached their coolest setup.

This simulation led design tactic helps Peraso optimize their system until they reached a heat transfer balance they need. To learn how Peraso performed this iteration, read Cutting the Cords.

The post Making Wireless Multigigabit Data Transfer Reliable with Simulation appeared first on ANSYS.

There is only so much communication bandwidth available. This will make it difficult to handle the boost in cellular traffic expected from the 5G network using conventional cellular technologies.

In fact, cellular networks are already running out of bandwidth. This severely limits the number of users and data rates that can be accommodated by wireless systems.

One potential solution is to leverage beamforming antennas. These devices transmit different signals to different locations on the cellular network simultaneously over the same frequency.

Pivotal Commware is using ANSYS HFSS to design beamforming antennas for cellular base stations that are much more affordable than current technology.

How 5G Networks Will Send More Signals on Existing Bandwidths

A 28 GHz antenna for a cellular base station.

Traditionally, cellular technologies — 3G and 4G LTE — crammed more signals on the existing bandwidth by dividing the frequencies into small segments and splitting the signal time into smaller pulses.

The problem is, there is only so much you can do to chop up the bandwidth into segments.

Alternatively, Pivotal’s holographic beamforming (HBF) antennas are highly directional. This means they can split up the physical space a signal moves through.

This way, two cells in two locations can use the same frequency at the same time without interfering with each other.

Additionally, these HBF antennas use varactor (variable capacitors) and electronic components that are simpler and more affordable than existing beamforming antennas.

How to Design HBF Antennas for 5G Cellular Base Stations

A parametric study of Pivotal’s HBF designs allowed them to look at a large portion of their design space and optimize for C-SWaP and roll-off. This study looks at roll-off as a function of degrees from the centerline of the antenna.

Antenna design companies — like Pivotal — are always looking to design devices that optimize cost, size, weight and power (C-SWaP) and performance.

So, how was Pivotal able to account for C-SWaP and performance so thoroughly?

Traditionally, this was done by building prototypes, finding flaws, creating new designs and integrating manually.

Meeting a product launch with an optimized product using this manual method is grueling.

Pivotal instead uses ANSYS HFSS to simulate their 5G antennas digitally. This allows them to assess their HBF antennas and iterate their designs faster using parametric studies.

For instance, Pivotal wants to optimize their design for performance characteristics like roll-off. To do so they can plug in the parameter values, run simulations with these values and see how each parameter affects roll-off.

By setting up parametric studies, Pivotal assess which parameters affect performance and C-SWaP the most. From there they could weigh different trade-offs until they settled on an optimized design that accounted for all the factors they studied.

To see how Pivotal set up their parametric studies and optimize their antenna designs, read 5G Antenna Technology for Smart Products.

The post Designing 5G Cellular Base Station Antennas Using Parametric Studies appeared first on ANSYS.

I recently attended an internal Convergent Science advanced training course on turbulence modeling. One of the audience members asked one of my favorite modeling questions, and I’m happy to share it here. It’s the sort of question I sometimes find myself asking tentatively, worried I might have missed something obvious. The question is this:

Reynolds-Averaged Navier Stokes (RANS) turbulence models and Large-Eddy Simulation (LES) turbulence models have very different behavior. LES will become a direct numerical simulation (DNS) in the limit of infinitesimally fine grid, and it shows a wide range of turbulent length scales. RANS does not become a DNS, no matter how fine we make the grid. Rather, it shows grid-convergent behavior (i.e., the simulation results stop changing with finer and finer grids), and it removes small-scale turbulent content.

If I look at a RANS model or an LES turbulence model, the transport equations look very similar mathematically. How does the flow ‘know’ which is which?

There’s a clever, physically intuitive answer to this question, which motivates the development of additional hybrid models. But first we have to do a little bit of math.

Both RANS and LES take the approach of decomposing a turbulent flow into a component to be resolved and a component to be modeled. Let’s define the Reynolds decomposition of a flow variable ϕ as

$$\phi = \bar \phi \; + \;\phi’,$$

where the overbar term represents a time/ensemble average and the prime term is the fluctuating term. This decomposition has the following properties:

$$\overline{\overline{\phi}} = \bar \phi \;\;{\rm{and}}\;\;\overline{\phi’} = 0.$$

LES uses a different approach, which is a spatial filter. The filtering decomposition of ϕ is defined as

$$\phi  = \left\langle \phi  \right\rangle + \;\phi ”,$$

where the term in the angled brackets is the filtered term and the double-prime term is the sub-grid term. In practice, this is often calculated using a box filter, a spatial average of everything inside, say, a single CFD cell. The spatial filter has different properties than the Reynolds decomposition,

$$\left\langle {\left\langle \phi  \right\rangle } \right\rangle \ne \left\langle \phi  \right\rangle \;\;{\rm{and}}\;\;\left\langle {\phi ”} \right\rangle  \ne 0.$$

To derive RANS and LES turbulence models, we apply these decompositions to the Navier-Stokes equations. For simplicity, let’s consider only the incompressible momentum equation. The Reynolds-averaged momentum equation is written as

$$\frac{{\partial \overline {{u_i}} }}{{\partial t}} + \frac{{\partial \overline {{u_i}}\; \overline {{u_j}} }}{{\partial {x_j}}} = – \frac{1}{\rho }\frac{{\partial \overline P }}{{\partial {x_i}}} + \frac{1}{\rho }\frac{\partial }{{\partial {x_j}}}\left[ {\mu \left( {\frac{{\partial \overline {{u_i}} }}{{\partial {x_j}}} + \frac{{\partial \overline {{u_j}} }}{{\partial {x_i}}}} \right) – \frac{2}{3}\mu \frac{{\partial \overline {{u_k}} }}{{\partial {x_k}}}{\delta _{ij}}} \right] – \frac{1}{\rho }\frac{\partial }{{\partial {x_j}}}\left( {\rho \color{Red}{\overline {{{u’}_i}{{u’}_j}}} } \right).$$

This equation looks the same as the basic momentum transport equation, replacing each variable with the barred equivalent, with the exception of the term* in red. That’s where the RANS model will make a contribution.

The LES momentum equation, again neglecting Favre filtering, is written

$$\frac{{\partial \left\langle {{u_i}} \right\rangle }}{{\partial t}} + \frac{{\partial \left\langle {{u_i}} \right\rangle \left\langle {{u_j}} \right\rangle }}{{\partial {x_j}}} =  – \frac{1}{\rho }\frac{{\partial \left\langle P \right\rangle }}{{\partial {x_i}}} + \frac{1}{\rho }\frac{{\partial \left\langle {{\sigma _{ij}}} \right\rangle }}{{\partial {x_j}}} – \frac{1}{\rho }\frac{\partial }{{\partial {x_j}}}\left( {\rho \color{Red}{\left\langle {{u_i}{u_j}} \right\rangle}}  – \rho \left\langle {{u_i}} \right\rangle \left\langle {{u_j}} \right\rangle  \right).$$

Once again, we have introduced a single unclosed term*, shown in red. As with RANS, this is where the LES model will exert its influence.

These terms are physically stress terms. In the RANS case, we call it the Reynolds stress.

$${\tau _{ij,RANS}} =  – \rho \overline {{{u’}_i}{{u’}_j}}.$$

In the LES case, we define a sub-grid stress as follows:

$${\tau _{ij,LES}} = \rho \left( {\left\langle {{{u}_i}{{u}_j}} \right\rangle  – \left\langle {{u_i}} \right\rangle \left\langle {{u_j}} \right\rangle } \right).$$

By convention, the same letter is used to denote these two subtly different terms. It’s common to apply one more assumption to both. Kolmogorov postulated that at sufficiently small scales, turbulence was statistically isotropic, with no preferential direction. He also postulated that turbulent motions were self-similar. The eddy viscosity approach invokes both concepts, treating

$${\tau _{ij,RANS}} = f\left( {{\mu _t},\overline V } \right)$$

and

$${\tau _{ij,LES}} = g\left( {{\mu _t},\overline V } \right),$$

where \(\overline V \) represents the vector of transported variables: mass, momentum, energy, and model-specific variables like turbulent kinetic energy. We have also introduced \({\mu _t}\), which we call the turbulent viscosity. Its effect is to dissipate kinetic energy in a similar fashion to molecular viscosity, hence the name.

If you skipped the math, here’s the takeaway. We have one unclosed term* each in the RANS and LES momentum equations, and in the eddy viscosity approach, we close it with what we call the turbulent viscosity \({\mu _t}\). Yet we know that RANS and LES have very different behavior. How does a CFD package like CONVERGE “know” whether that \({\mu _t}\) is supposed to behave like RANS or like LES? Of course the equations don’t “know”, and the solver doesn’t “know”. The behavior is constructed by the functional form of \({\mu _t}\).

How can the turbulent viscosity’s functional form construct its behavior? Dimensional analysis informs us what this term should look like. A dynamic viscosity has dimensions of density multiplied by length squared per time. If we’re looking to model the turbulent viscosity based on the flow physics, we should introduce dimensions of length and time. The key to the difference between RANS and LES behavior is in the way these dimensions are introduced.

Consider the standard k-ε model. It is a two-equation model, meaning it solves two additional transport equations. In this case, it transports turbulent kinetic energy (k) and the turbulent kinetic energy dissipation rate (ε). This model calculates the turbulent viscosity according to the local values of these two flow variables, along with density and a dimensionless model constant as

$${\mu _t} = {C_\mu }\rho \frac{{{k^2}}}{\varepsilon }.$$

Dimensionally, this makes sense. Turbulent kinetic energy is a specific energy with dimensions of length squared per time squared, and its dissipation rate has dimensions of length squared per time cubed. In a sufficiently well-resolved solution, all of these terms should limit to finite values, rather than limiting to zero or infinity. If so, the turbulent viscosity should limit to some finite value, and it does.

LES, in contrast, directly introduces units of length via the spatial filtering process. Consider the Smagorinsky model. This is a zero-equation model that calculates turbulent viscosity in a very different way. For the standard Smagorinsky model,

$${\mu _t} = \rho C_s^2{\Delta ^2}\sqrt {{S_{ij}}{S_{ij}}},$$

where \({C_s}\) is a dimensionless model constant, \({S_{ij}}\) is the filtered rate of strain tensor, and Δ is the grid spacing. Once again, the dimensions work out: density multiplied by length squared multiplied by inverse time. But what do the limits look like? The rate of strain is some physical quantity that will not limit to infinity. In the limit of infinitesimal grid size, the turbulent viscosity must limit to zero! The model becomes completely inactive, and the equations solved are the unfiltered Navier-Stokes equations. We are left with a direct numerical simulation.

When I was a first-year engineering student, discussion of dimensional analysis and limiting behaviors seemed pro forma and almost archaic. Real engineers in the real world just use computers to solve everything, don’t they? Yes and no. Even those of us in the computational analysis world can derive real understanding, and real predictive power, from considering the functional form of the terms in the equations we’re solving. It can even help us design models with behavior we can prescribe a priori.

Detached Eddy Simulation (DES) is a hybrid model, taking advantage of the similarity of functional forms of the turbulent viscosities in RANS and LES. DES adopts RANS-like behavior near the wall, where we know an LES can be very computationally expensive. DES adopts LES behavior far from the wall, where LES is more computationally tractable and unsteady turbulent motions are more often important.

The math behind this switching behavior is beyond the scope of a blog post. In effect, DES solves the Navier-Stokes equations with some effective \({\mu _{t,DES}}\) such that \({\mu _{t,DES}} \approx {\mu _{t,RANS}}\) near the wall and \({\mu _{t,DES}} \approx {\mu _{t,LES}}\) far from the wall, with \({\mu _{t,RANS}}\) and \({\mu _{t,LES}}\) selected and tuned so that they are compatible in the transition region. Our understanding of the derivation and characteristics of the RANS and LES turbulence models allows us to hybridize them into something new.

*This term is a symmetric second-order tensor, so it has six scalar components. In some approaches (e.g., Reynolds Stress models), we might transport these terms separately, but the eddy viscosity approach treats this unknown tensor as a scalar times a known tensor.

The Convergent Science GmbH team is based in Linz, Austria and provides support to our European clients and collaborators alike as they tackle the hard problems. One of the most interesting and challenging problems in the design of high efficiency modern spark-ignited (SI) internal combustion engines is the prediction of knock and the development of knock-mitigation strategies. At the 2018 European CONVERGE User Conference (EUC), several speakers presented recent work on engine knock.

This winter, when I cold-started my car, I heard a loud knocking noise. Usually, though, knocking is more prevalent in engines that operate near the edge of the stability range. The first step of knocking is spontaneous secondary ignition (autoignition) of the end-gases ahead of the flame front. When the pressure waves from this autoignition hit the walls of the combustion chamber, they often make a knocking noise and damage the engine. Knock is challenging to simulate because you must correctly calculate critical local conditions and simultaneously track the pressure waves that are traveling rapidly across the combustion chamber.

To enable you to easily model these conditions, CONVERGE offers autonomous meshing, full-cycle simulation, and flexible boundary conditions. Adaptive Mesh Refinement allows you to add cells and spend computational time on areas where the knock-relevant parameters (such as local pressure difference, heat release rate, and species mass fraction of radicals that indicate autoignition) are rapidly changing. CONVERGE can predict autoignition with surrogate fuels, changing physical engine parameters, and a spectrum of operating conditions.

EUC keynote speaker Vincenzo Bevilacqua from Porsche Engineering presented an intriguing new approach (re-defining knock index) to evaluate the factors that may contribute to knock and to identify a clear knock limit. In another study, researchers from Politecnico di Torino investigated the feasibility of water injection as knock mitigation strategy. In yet another study, Max Mally and his colleagues from VKA RWTH Aachen University used RANS to successfully reproduce combustion and knock with a spark-timing sweep approach at various exhaust gas recirculation (EGR) percentages. You can see in the figure below that they were able to capture the moving pressure waves.

Advancing the spark, using lean burn, turbo-charging, or running at a high compression ratio can increase the likelihood of knock. However, each cycle in an SI engine is unique, and thus autoignition is not a consistent phenomenon. When simulating an SI engine, it is critical to simulate multiple cycles to identify the limits of the operating conditions at which knock is likely to occur. (Fortunately, CONVERGE can easily run multi-cycle simulations!)

Knock is one of the limiting factors in engine design because many of the techniques that improve the thermal efficiency and enable downsizing of the engine increase the likelihood of knock. Here at Convergent Science, we encourage you to solve the hard problems. Go on, knock it out of park.

Convergent Science thrived in 2018, with many successes, rapid growth, and consistent innovation. We celebrated the tenth anniversary of the commercial release of CONVERGE. The Convergent Science employee count surpassed 100, and our India office tripled in size. We formed new partnerships and collaborations and continued to bring CONVERGE to new application areas. Simultaneously, we endeavored to increase the prominence of CONVERGE in internal combustion applications and grew our market share.

Our dedicated team at Convergent Science ensures that CONVERGE stays on the cutting-edge of CFD software—implementing new models, enhancing CONVERGE features, increasing simulation speed and accuracy—while also offering exceptional support and customer service to our clients.

New Application Successes

Increasingly, clients are using CONVERGE for new applications and great strides are being made in these fields. Technical presentations and papers on gerotor pumps, blood pumps, reciprocating compressors, scroll compressors, and screw machines this year reflected CONVERGE’s increased use in the pumps and compressors markets. Research projects using CONVERGE to model gas turbine combustion, lean blow-out, ignition, and relight are going strong. In the field of aftertreatment, new acceleration techniques have been implemented in CONVERGE to enable users to accurately predict urea deposits in Urea/SCR aftertreatment systems while keeping pace with rapid prototyping schedules. In addition, we were thrilled to see the first paper using CONVERGE for offshore wind turbine modeling published this year, as part of a collaborative effort with the University of Massachusetts Amherst.

CONVERGE Featured at SAE, DOE Merit Review, and ASME ICEF

CONVERGE’s broad use in the automotive industry was showcased at the Society of Automotive Engineers World Congress Experience (SAE WCX18), with more than 30 papers presenting CONVERGE results. Convergent Science cultivates collaboration with industry, academic, and research institutions, and the benefit of these collaborations was prominently displayed at SAE WCX18. Organizations such as General Motors, Caterpillar, Ford, Jaguar Land Rover, Isuzu Motors, John Deere, Renault, Aramco Research Center, Argonne National Laboratory, King Abdullah University of Science and Technology (KAUST), Saudi Aramco, and the University of Oxford all authored papers describing CONVERGE results. These papers spanned a wide array of topics, including fuel injection, chemical mechanisms, HCCI, GCI, water injection, LES, spray/wall interaction, abnormal combustion, machine learning, soot modeling, and aftertreatment systems.

At the 2018 DOE Merit Review, CONVERGE was featured in 17 of the advanced vehicle technologies projects that were reviewed by the U.S. Department of Energy. The broad range of topics of the projects is a testament to the versatility and broad applicability of CONVERGE. The research for these projects was conducted at Argonne National Laboratory, Lawrence Livermore National Laboratory, Oak Ridge National Laboratory, Sandia National Laboratories, the Department of Energy, National Renewable Energy Laboratory, and the University of Michigan.

CONVERGE was once again well represented at the ASME Internal Combustion Engine Fall Technical Conference (ICEF). At ASME ICEF 2018, 18 papers included CONVERGE results, with topics ranging from ignition systems and injection strategies to emissions modeling and predicting cycle-to-cycle variation. I was honored to have the opportunity to further my cause of defending the IC engine in a keynote presentation.

New Partnerships and Collaborations

At Convergent Science, we take pride in fostering partnerships and collaborations with companies and institutions to spark innovation and bring our best software to the CFD community. This year, we renewed our partnership with Roush Yates Engines, who had a fantastic 2018 season, achieving the company’s 350th win and winning the Monster Energy NASCAR Cup Series Championship. We formed a new partnership with Tecplot and integrated their industry-leading visualization software into CONVERGE Studio. In addition, we entered into new partnerships with the National Center for Supercomputing Applications and two Dassault Systèmes subsidiaries, Spatial Corp. and Abaqus. These partnerships improve the usability and applicability of CONVERGE and help CONVERGE reach new markets.

CONVERGE in Italy

We had a great showing of CONVERGE users at our second European CONVERGE User Conference held this year in Bologna, Italy. Attendees shared their latest research using CONVERGE for a host of different applications, from modeling liquid film boiling and mitigating engine knock to developing turbulent combustion models and simulating premixed burners with LES. For one of our networking events, we rented out the Ferrari Museum in Maranello, where we were treated to a tour of the museum and ate dinner surrounded by cars we wished we owned. We also enjoyed traditional Bolognese cuisine at the Osteria de’ Poeti and a reception at the Garganelli Restaurant. 

Turning 10 at the U.S. CONVERGE User Conference

It seemed only fitting to celebrate ten years of CONVERGE back where it all started in Madison, Wisconsin. During the fifth annual North American User Conference, we commemorated CONVERGE’s tenth birthday with a festive evening at the historic Orpheum Theater in downtown Madison. During the celebration, we heard from Jamie McNaughton of Roush Yates Engines, who discussed the game-changing impact of CFD on creating winning racing engines. Physics Girl Dianna Cowern entertained us with her live physics demonstrations and her unquenchable enthusiasm for all things science. I concluded the evening with a brief presentation (which you can check out below) reflecting on the past decade of CONVERGE and looking forward to the future. We were incredibly grateful to be able to celebrate the successes of CONVERGE with our users who have made these past ten years possible.

In addition to our 10-year CONVERGE celebration, we hosted our third trivia match at the Convergent Science World Headquarters. At the beautiful Madison Club, we heard a fascinating round of presentations on topics including gas turbine modeling, offshore fluid-structural dynamics, machine learning, and a wide range of IC engine applications.

Convergent Science India

The Convergent Science India office in Pune celebrated its one-year anniversary in August. The office has transformed in the span of the last year and a half. The employee count more than tripled—from two employees at the end of 2017 to seven at the end of 2018. Five servers are now up and running and the office is fully staffed. We’re thrilled with the service and support our Pune office has been able to offer our clients all around India.

CONVERGE 3.0 Coming Soon

CONVERGE 3.0 is slated to be released soon, and we truly believe this new version of CONVERGE will once again change the CFD game. In 3.0, you can look forward to our new boundary layer mesh and inlaid mesh features, which will allow greater meshing flexibility for accurate results at less computational cost. Our new partnership with Spatial Corp. will enable CONVERGE users to directly import CAD files into CONVERGE Studio, greatly streamlining our Studio users’ workflow. We’ve also focused a lot of our attention this year towards enhancing our chemistry tools to be more efficient, robust, and applicable to an even greater range of flow and combustion problems. We’ve added new 0D and 1D reactors, including a perfectly stirred reactor, 0D HCCI engine, RON and MON estimators, plug flow reactors, and improved our 1D laminar flame solver. Additionally, we enhanced our mechanism reduction capability by targeting both ignition delay and laminar flamespeed. But perhaps the most anticipated aspect of CONVERGE 3.0 is the scaling. 3.0 demonstrates dramatically superior parallelization compared to 2.4 and shows significant speedup even on thousands of cores.

Looking Ahead

2019 promises to be an exciting year. With the upcoming release of CONVERGE 3.0, we’re looking forward to growing CONVERGE’s presence in new application areas, continuing our work on pumps and compressors, and expanding our presence in aftertreatment and gas turbine markets. We will continue working hard to expand the usage of CONVERGE in the European, Asian, and Indian automotive markets. Above all, we look forward to more innovation, more collaboration, and continuing to provide unparalleled support to our clients. Want to join us? Check out our website to find out how CONVERGE can help you solve the hard problems.

Imagine that you are modeling an engine. Engines are complex machines, and accurately modeling an engine is not an easy undertaking. Capturing in-cylinder dynamics, intake and exhaust system characteristics, complicated boundary conditions, and much more creates a problem that often takes multiple software suites to solve.

Convergent Science has a solution: CONVERGE Lite—and we’ve just introduced a new licensing option.

CONVERGE Lite is a reduced version of CONVERGE that comes free of charge with every GT-SUITE license. Gamma Technologies, the developer of GT-SUITE, and Convergent Science combined forces to allow users of GT-SUITE to leverage the power of CONVERGE.

CONVERGE LITE + GT-SUITE OVERVIEW

GT-SUITE is an industry-leading CAE system simulation tool that combines 1D physics modeling, such as fluid flow, thermal analysis, and mechanics, with 3D multi-body dynamics and 3D finite element thermal and structural analysis. GT-SUITE is a great tool for a wide variety of system simulations, including vehicles, engines, transmission, general powertrains, hydraulics, and more.

Let’s think again about modeling an engine. GT-SUITE is ideal for the primary workflow of engine design. But, what if you want to model 3D mixing in an intake engine manifold to track the cylinder-to-cylinder distribution of recirculated exhaust gas? Or simulate complex 3D flow through a throttle body to find the optimal design to maximize power? In these scenarios, 1D modeling is not sufficient on its own.

In this type of situation where 3D flow analysis is critical, GT-SUITE users can invoke CONVERGE Lite to obtain detailed 3D analysis at no extra charge. CONVERGE Lite is fully integrated into GT-SUITE and is known for being user friendly. One of the biggest advantages of CONVERGE Lite is that it allows GT-SUITE users access to CONVERGE’s powerful autonomous meshing. With automatic mesh generation, fixed mesh embedding, and Adaptive Mesh Refinement, CONVERGE Lite eliminates user meshing time and allows for efficient grid refinement. In addition, CONVERGE Lite comes with automatic CFD species setup and automatic setup of fluid properties to match the properties in the GT-SUITE model. And as if that weren’t enough, recently CONVERGE Lite has been enhanced to include a license for Tecplot for CONVERGE, an advanced 3D post-processing software.

LICENSING

You can run CONVERGE Lite in serial for free if you have a GT-SUITE license. If you want to run CONVERGE Lite in parallel, you can purchase parallel licenses from Convergent Science. We have just introduced a new low-cost option for running CONVERGE Lite in parallel. For one flat fee, you can obtain a license from Convergent Science to run CONVERGE Lite on an unlimited number of cores. Even though CONVERGE Lite contains many features to enhance efficiency, 3D simulations can be computationally expensive. This new option is a great way to affordably speed up your integrated GT-SUITE + CONVERGE Lite simulations.

CONVERGE Lite is a robust tool, but it does not contain all of the features of the full CONVERGE solver. For example, if you want to take advantage of advanced physical models, like combustion, spray, or volume of fluid, or you want to simulate moving walls, such as pistons or poppet valves, a full CONVERGE license is required. With both a full CONVERGE license and a GT-SUITE license, you can also take advantage of CONVERGE’s detailed chemistry solver, multiphase flow modeling, and other powerful features while performing advanced CONVERGE + GT-SUITE coupled simulations.

The combined power of CONVERGE and GT-SUITE opens the door to a whole array of advanced simulations, like engine cylinder coupling, exhaust aftertreatment coupling, or fluid-structure interaction coupling, that cannot be accomplished with just one of the programs.

Contact a Convergent Science salesperson for licensing details and pricing information.

Contact sales

One of the more controversial subjects we talk about here at Convergent Science is the role of turbulence-chemistry interaction (TCI) when using our SAGE detailed chemistry solver.

What is TCI?

TCI is used to describe two separate but linked processes: enhanced mixing in momentum, energy, and species due to turbulence and the commutation error in the reaction rate evaluation. A good turbulence model should always account for the enhanced mixing due to turbulence.

The commutation error is more difficult to address. In an LES simulation, the commutation error is the difference between evaluating the reaction rates using the spatially filtered quantities and using the un-filtered quantities (the latter is exact and the former is an approximation) and then filtering the reaction rates. It is usually convenient to use the averaged or filtered values to evaluate the reaction rates, which unfortunately means more error. For LES, the commutation error reduces as the cell size is reduced^[1], and thus, with sufficient grid resolution, the commutation error becomes negligible.

In this blog post, we briefly describe a study that demonstrates that with sufficient grid resolution, CONVERGE CFD (with LES and detailed chemistry) can resolve the enhanced mixing due to turbulence without explicitly assigning a sub-grid model for the commutation error. For more details, please see the accompanying white paper.

Simulation Strategy

We simulate a canonical turbulent partially premixed flame, Sandia Flame D. We leverage Adaptive Mesh Refinement (AMR) and adaptive zoning as acceleration strategies to speed up the computationally expensive LES simulations. Figure 1 shows the fine resolution around a subsection of the flame due to AMR, which allows us to get good resolution when and where we need it.

Conclusion In Brief

We first conduct grid convergence studies and find that 0.25 mm minimum grid size is sufficient to resolve most of the velocity and species fluctuations.

Then, we demonstrate that the commutation error becomes smaller and we resolve more velocity and species fluctuations as we use finer meshes. With the finest mesh, we match not only the the mean and RMS to the experimental value, but also the conditional mean and the shape of joint probability distribution function.

Finally, we take on the challenge of accurately predicting of non-equilibrium combustion processes. These processes (i.e., extinction and reignition) are dependent on two factors:

1. An accurate mechanism for the range of conditions simulated and
2. A good LES solver with sufficient grid resolution.

We compare thousands of data points from experiments to the equivalent points from the LES to determine that CONVERGE correctly predicts the extinction and reignition trends.

So what?

The SAGE detailed chemistry solver with LES has demonstrated success in a host of applications^[2,3,4,5,6], including gas turbines and internal combustion engines.

We show in this white paper that when you resolve most of the velocity and species fluctuations and significantly reduce the commutation error, you can predict mixing-controlled turbulent combustion without a model for the commutation error in the reaction rates.

CONVERGE contains multiple acceleration strategies that make SAGE detailed chemistry + LES a reasonable strategy as far as computational costs go. Ready to dive more in-depth? Our TCI white paper is waiting for you!

[1] Davidson, L., “Fluid mechanics, turbulent flow and turbulence modeling,” Chalmers University, 2018. www.tfd.chalmers.se/~lada/postscript_files/solids-and-fluids_turbulent-flow_turbulence-modelling.pdf

[2] Drennan, S.A., and Kumar, G., “Demonstration of an Automatic Meshing Approach for Simulation of a Liquid Fueled Gas Turbine with Detailed Chemistry,” 50th AIAA/ASME/SAE/ASEE Joint PropulsionConference, AIAA 2014-3628, Cleveland, OH, United States, July 28-30, 2014. DOI:10.2514/6.2014-3628

[3] Kumar, G., and Drennan, S., “A CFD Investigation of Multiple Burner Ignition and Flame Propagation with Detailed Chemistry and Automatic Meshing,” 52nd AIAA/SAE/ASEE Joint Propulsion Conference, Propulsion and Energy Forum, AIAA 2016-4561, Salt Lake City, UT, United States, July 25-27, 2016. DOI:10.2514/6.2016-4561

[4] Yang, S., Wang, X., Yang, V., Sun, W., and Huo, H., “Comparison of Flamelet/Progress-Variable and Finite-Rate Chemistry LES Models in a Preconditioning Scheme,” 55th AIAA Aerospace Sciences Meeting, AIAA SciTech Forum, AIAA 2017-0605, Grapevine, TX, United States, January 9-13, 2017. https://doi.org/10.2514/6.2017-0605

[5] Pei, Y., Som, S., Pomraning, E., Senecal, P.K., Skeen, S.A., Manin, J., Pickett, L.M., “Large Eddy Simulation of a Reacting Spray Flame with Multiple Realizations under Compression Ignition Engine Conditions,” Combustion and Flame, 162, 4442-4455, 2015. DOI:10.1016/j.combustflame.2015.08.010

[6] Liu, S., Kumar, G., Wang, M., and Pomraning, E., “Towards Accurate Temperature and Species Mass Fraction Predictions for Sandia Flame-D using Detailed Chemistry and Adaptive Mesh Refinement,” 2018 AIAA Aerospace Sciences Meeting, AIAA SciTech Forum, AIAA 2018-1428. DOI:10.2514/6.2018-1428.

As a general purpose CFD solver, CONVERGE is robust out of the box. Autonomous meshing technology built into the solver eliminates the meshing bottleneck that has traditionally bogged down CFD workflows. Despite this advantage, however, performing computational fluid dynamics analyses is still a complex task. Challenges in pre-processing and post-processing can slow your workflow. To streamline the simulation process, CONVERGE CFD software includes a wide array of tools, utilities, and documentation as well as support from highly trained engineers with every license.

Pre-Processing

• Although you do not have to create a volume mesh, your surface geometry must be watertight and meet several quality standards related to triangulation and normal vector orientation. CONVERGE Studio includes several native surface repair tools to quickly detect, show, and resolve these issues. With an additional license for the Polygonica toolkit, you can leverage powerful surface repair capabilities from within CONVERGE Studio.
• For engine simulations, a popular acceleration technique is to use a sector (an axisymmetric geometry representing a portion of the model) instead of the full geometry. In CONVERGE, the make_surface utility allows you to quickly create a properly prepared sector geometry based on the piston bowl profile and just a few more geometry inputs. CONVERGE Studio includes a graphical version of this tool.
• With any CFD software, the multitude of input parameters to control the complex physical models can be overwhelming. In CONVERGE CFD, we provide several checks to help you validate your case setup configuration before beginning a simulation. In CONVERGE, run the check_inputs utility to write information about missing or improperly configured parameters to the terminal. In CONVERGE Studio, you can use the Validate buttons throughout the application to validate input parameters incrementally as you configure the case. Additionally, the Final Validation tool examines the geometry and case setup parameters and provides suggestions for anything that may need to be revised.
• A staple of the CONVERGE feature set is the ease with which you can simulate complex moving geometries. One requirement is that boundaries cannot intersect during the simulation. There are several ways to verify that your setup meets this requirement. Running CONVERGE in no hydrodynamic solver mode does not solve the spray, combustion, and transport equations. Instead, this type of simulation checks surface motion and grid creation. In CONVERGE Studio, use the Animation tab of the View Options dock to preview boundary motion and check for triangle intersections at each step of the motion. 
• Many complex engine, pump, compressor, and other machinery simulations employ the sealing feature to prevent flow between regions at various times during a simulation. To test your seal setup, run the CONVERGE sealing test utility by supplying the check-sealing argument after your CONVERGE executable. This command uses a simplified test with only a single level of cells and most options (including AMR, embedding, sources, mapping, events, etc.) automatically turned off.
• Full multi-cylinder simulations provide accurate predictions for fluid-solid heat transfer, intake and exhaust flow, and other important engine design parameters. Setting up the multiple cylinder geometries and timing can be a frustrating exercise in bookkeeping. The Multi-cylinder wizard in CONVERGE Studio makes this process painless. The wizard is a step-by-step tool that guides you through the process of configuring cylinder phase lag, copying geometry components for additional cylinders, and setting up timing of events such as spark ignition. After your configuration is complete, the wizard provides a quick reference sheet that catalogs the salient details for each cylinder. 
• Because surface triangles cannot intersect during a CONVERGE simulation, valves (e.g., intake and exhaust valves in an IC engine) must be set to a minimum lift value very close to the valve seats but not technically closed. CONVERGE Studio includes a tool to automatically and quickly move the valves to this position based on profiles of intake and exhaust valve motion.
• In compressor simulations, the working fluid is often far from an ideal gas. In addition to multiple equation of state models in CONVERGE, you can directly supply custom fluid properties for the working fluid. CONVERGE reads properties such as viscosity, conductivity, and compressibility as a function of temperature from supplied tabular data, obviating the need to link CONVERGE with a third-party properties library.
• As CONVERGE is a very robust tool, you can use it for many different types of simulations: compressible or incompressible flow, multiphase flow, transient or steady-state, moving geometry, non-Newtonian fluids, and much more. Each of these regimes and scenarios requires you to configure relevant parameters. CONVERGE Studio includes a full suite of example cases across a range of these regimes including IC engines, compressors, gas turbines, and more. It is as simple as clicking File > Load Example Case to open an example case with Convergent Science-recommended default parameters for the given simulation type. You can use the example cases as starting points for your own simulations or run them as-is while you learn to use CONVERGE. 

Post-Processing

• The geometry triangulation for a CONVERGE simulation may differ from that for a finite element analysis (FEA) simulation because the FEA geometry may have higher resolution in areas most relevant to the heat transfer analysis. CONVERGE includes an HTC mapper utility that maps near-wall heat transfer data from the CONVERGE simulation output to the triangulation of the FEA surface. That way, you can iterate between the two simulation approaches to understand and optimize designs.
• CONVERGE Studio includes a powerful Line Plotting module to create two-dimensional plots. In addition to providing a high level of plot customization, the module is designed to plot some of the two-dimensional *.out files unique to CONVERGE. Also, you can use the Line Plotting module to monitor simulation properties such as mass flow rate convergence in a steady-state simulation. 
• One of the post-processing tools available in CONVERGE Studio is the Engine performance calculator. This tool automatically calculates engine work and other relevant engine design parameters for 360 degree or 720 degree ranges from CONVERGE output and the engine parameters in your case setup. The results are collated in a table so that you can easily export them to a spreadsheet.

Documentation

• Several case setup tutorial video series on the Convergent Science YouTube channel provide step-by-step walkthroughs of full case setups. Refer to these for information on surface preparation, case setup, simulation, and post-processing of some basic CONVERGE example cases.
• On our CFD Online support forum, you can interact with other CONVERGE CFD users and our knowledgeable and approachable support team for assistance.

Performing CFD analyses can be difficult due to the number of unknowns, uncertainty of boundary conditions, and complexity of flows. CONVERGE CFD helps you by removing the necessity of meshing and giving you auxiliary tools to simplify your workflow.

In this installment of the Smart Design Series, a library of videos developed to help you become familiar with Computational Fluid Dynamics (CFD), we take a closer look at free surface simulation with the help of Simcenter FLOEFD. Simcenter FLOEFD is an award-winning CAD-embedded fluid flow and heat transfer simulation solution which allows you to frontload CFD simulation during the design stage where you can fully explore the design envelope. Free surface capability can be used to simulate filling, emptying and sloshing of liquids and non-Newtonian fluids. In this video we focus on an automotive surge tank. By simulating the behavior of liquid, you can gain valuable insight into the performance of your model. A wide range of visualization tools including cut plots and animations are at your disposal to fully probe the model. For example, with the help of the Transient Explorer you can see the filling process and by using the gravitation or acceleration changes over time, you can imitate the effect of accelerated or decelerated movement. While this 4-minute video features Simcenter FLOEFD for NX, you can expect the same level of integration with CATIA V5, Creo and Solid Edge from the world’s most popular CFD program for the design engineer.

Watch this 4 minute presentation to learn more.

Optimizing thermal fluid system design using virtual prototyping and costing simulations.

Wendy Luiten explains the Ease of Use of Command Center in Simcenter Flotherm. All, In Just a Minute! 

The latest version of Simcenter Flomaster V9.2 features a new colourization tool displaying color and direction to assist rapid system level understanding

PyTecplot and the Python multiprocessing module was the subject of our recent Webinar. PyTecplot already has a lot of great capability, and bringing in the Python multiprocessing toolkit allows you to accelerate your work and get it done even faster. This blog answers some questions asked during the Webinar.

1. What is PyTecplot?

Watch the Webinar: Analyze Your Time-Dependent Data 6x Faster

PyTecplot is an API to control Tecplot 360. PyTecplot is a separate installation from Tecplot 360. When you have Tecplot 360 installed, PyTecplot will need to be installed separately. Because this is a Python module you have to install it as part of your Python installation. A 64-bit installation of Python 2.7 or Python 3.4 and newer is required. All of this information is in our (very thorough) documentation.

PyTecplot Documentation

2. What is Python multiprocessing?

Multiprocessing is a process-based Python “threading” interface. “Threading” is in quotes because it is not actually using multi-threading. It’s actually spawning separate processes. We encourage you to read more in the Python documentation, Python multiprocessing library.

In the Webinar we show you a method to use the Python Multiprocessing Library in conjunction with PyTecplot to accelerate the generation of movies and images. This technique can go beyond just the generation of images. You can extract information from your simulation data as well. The recent Webinar shows you how to use the multiprocessing toolkit in conjunction with PyTecplot. We use a transient simulation of flow around a cylinder as the example, but have timings from several different cases.

The recording and the scripts from the Webinar “Analyze Your Time-Dependent Data 6x Faster” can be found on our website.

Watch the Webinar

3. Is PyTecplot included in the package of Tecplot for CONVERGE?

Request a quote for the full version of Tecplot 360

Last year we partnered with Convergent Science, which makes a CFD code that is used quite heavily in internal combustion, but they also can work with many other application areas. In our partnership if you buy CONVERGE, you get free access to Tecplot for CONVERGE. Tecplot for CONVERGE allows you to use PyTecplot but only through the Tecplot 360 Graphical User Interface.

To have the capability of running PyTecplot in batch mode, as shown in the Webinar, you will need to upgrade to the full version of Tecplot 360.

Request a Quote

4. Does Tecplot 360 run well with other software like Star-CCM+?

Tecplot 360 does not have a direct loader for Star-CCM+. However, you can export from Star-CCM+ to CGNS, Ensight or Tecplot format, all of which can be read by Tecplot 360.

Tecplot 360 Compatible Solvers

5. When running PyTecplot in batch mode, Is session.stop required to clean up the temporary files? Or can you just let the process exit?

Yes and no. We found that on Linux, the multiprocessing toolkit just terminates the process resulting in a core dump. It is very important to call session.stop to avoid these core dump files.

6. What PyTecplot Resources Do You Have?

• Many commonly asked questions are answered in our PyTecplot FAQs.
• Learn more about PyTecplot.
• See all of our PyTecplot Video Tutorials.

The post Python Multiprocessing Accelerates Your CFD Analysis Time appeared first on Tecplot.

Jonathan Whiting is a member of the hydrodynamic modeling group at Pacific Northwest National Laboratory in Washington State. He has been a Tecplot 360 user since 2014.

PNNL and the Salish Sea Model

Pacific Northwest National Laboratory (PNNL) is a U.S. Department of Energy laboratory with a main campus in Richland, Washington. The PNNL mission is to advance the frontiers of knowledge by taking on some of the world’s greatest science and technology challenges. The lab has distinctive strengths in chemistry, earth sciences and data analytics and deploys them to improve America’s energy resiliency and to enhance national security.

Jonathan is part of the Coastal Sciences Division at PNNL’s Marine Sciences Laboratory. The hydrodynamic modeling group in Seattle, WA works primarily to promote both ecosystem management and the restoration of the Salish Sea and Puget Sound with the Salish Sea Model.

The Salish Sea Model is a predictive ocean modeling tool for coastal estuarine research, restoration planning, water-quality management, and climate change response assessment. It was initially created to evaluate the sensitivity of Puget Sound acidification to ocean and fresh water inputs and to reproduce hypoxia in the Puget Sound while examining its sensitivity to nutrient pollution, funded by the Washington State Department of Ecology. Now it is being applied to answer the most pressing environmental challenges in the greater Salish Sea region.

PNNL is currently in the first year of a three-year project to enhance the Salish Sea Model. The goals are to increase the model’s resolution and to make it operational, which means assuring the model runs on schedule and gets results that are continuously available to the public—including predictions a week or so ahead. This will allow for new applications such as the tracking of oil spills during response activities.

Jonathan has worked with the modeling team on several habitat restoration planning projects along the Snoqualmie and Skagit rivers in Washington’s Puget Sound region. Jonathan was responsible for post-processing model outputs into analytical and geospatial products to meet client expectations and to convey findings that aid project planning and stakeholder engagement.

The Challenge: Creating Consistent, High-Quality Visualization for Model Post-Processing

The hydrodynamics modeling group uses the Finite Volume Community Ocean Model (FVCOM) simulation code.

For the recent Skagit Delta Hydrodynamic Modeling project, a high-resolution triangular unstructured grid was created with 131,471 elements and 10 terrain-following sigma layers in the vertical plane. Post-processing was conducted on five time snapshots per scenario across 11 scenarios (including a baseline). Each file was about 55MB in uncompressed binary format.

The sheer quantity of plots was very challenging to handle, and it was important to generate clean plots that clearly conveyed results.

The Solution – Tecplot 360

Jonathan most often uses Tecplot 360 to generate top-down plots and videos that visualize parameters geospatially across an area. He then uses that visualization to convey meaningful project implications to his clients, who in turn use the products to inform program stakeholders and the public.

To handle the quantity of data Jonathan was working with, Tecplot 360 product manager Scott Fowler gave him a quick demonstration of Tecplot 360 and showed him how to use Chorus, the parametric design space analysis tool within Tecplot 360. Chorus allowed Jonathan to analyze a single dataset with multiple plots in a single view over time by using the matrix tool, easing the bulk generation of plots.

Tecplot support and development teams have been working closely with Jonathan, especially by adding new geospatial features to the software that enhance its automation and efficiency.

According to Jonathan, the key strengths in Tecplot’s software have been:

• Ease of use
• Availability of scripting to assist bulk processing
• Variety of tools and features, such as georeferenced images

Using Tecplot 360 has allowed Jonathan to create professional plots that enhance the impact of their modeling work.

How Will Jonathan Use Tecplot In the Future?

Jonathan’s personal niche has become trajectory modeling, so he is also interested in using Tecplot to generate visuals associated with the movement of objects on the surface by using streamlines, velocity gradients, slices, and more. He intends to take a deeper dive into the vast capabilities of Chorus and PyTecplot in the future!

Tecplot 360’s latest geoscience-focused release, Tecplot 360 2018 R2, includes the popular FVCOM loader and has the ability to insert georeferenced images that put your data in context. Tecplot 360 will automatically position and scale your georeferenced Google Earth or Bing Maps images.

Learn more about how Tecplot 360 is used for geoscience research.

Try Tecplot 360 for Free

The post Predictive Ocean Model Helps Coastal Estuarine Research appeared first on Tecplot.

At the end of February 2019, I did a presentation at the SIAM Conference on Computer Science and Engineering (CSE) in Spokane Washington. I live in the Seattle area, and Spokane is reasonably close, so I decided to drive instead of fly. Unfortunately, the entire nation, including Washington state, was still in the grips of the dreaded “polar vortex.” The night before my drive to Spokane all of the mountain passes were closed due to heavy snowfall. They opened in time but the drive was slippery and slow. I probably should have taken a flight instead! On the drive, I came up with this Haiku…

The Goal: Adding Parallel SZL Output to SU2

My presentation at the SIAM CSE conference was on the progress made adding parallel SZL (SubZone Load-on-demand) file output to SU2. The SU2 suite is an open-source collection of C++ based software tools for performing Partial Differential Equation (PDE) analysis and solving PDE-constrained optimization problems. The toolset is designed with Computational Fluid Dynamics (CFD) and aerodynamic shape optimization in mind, but is extensible to treat arbitrary sets of governing equations such as potential flow, elasticity, electrodynamics, chemically-reacting flows, and many others. SU2 is under active development by individuals all around the world on GitHub and is released under an open-source license. For more details, visit SU2 on Github.

The Challenge: Building System Compatibility

We implemented parallel SZL output in SU2 using the TecIO-MPI library, available for free download from the TecIO page. In some CFD codes, such as NASA’s FUN3D code, each user site is required to download and link the TecIO library. However, in the case of SU2 we decided to include the obfuscated TecIO source code directly into the distribution of SU2. This makes it much easier for the user – they need only download and build SU2 and they have SZL file output available.

However, this did add some complications from our end.

The main complication is that SU2 is built using the GNU configure system whereas TecIO is built using CMake. We had to create new automake, autoconfig, and m4 script files to seamlessly build TecIO as a part of the SU2 build.

If you find yourself integrating TecIO source into a CFD code built with the GNU configure system, feel free to shoot me some questions – scottimlay@tecplot.com

Implementing Serial vs. Parallel TecIO

Once TecIO was building as part of the SU2 build, it was straight-forward to get the serial version of SZL output working. SU2 already included an older version of TecIO, so we simply replaced those calls with the newer TecIO calls.

To get the parallel SZL output (using TecIO-MPI) working was a little more complicated. Specifically, it required knowing which nodes on each MPI rank were ghost nodes. Ghost nodes are nodes that are duplicated between partitions to facilitate the communication of solution data between MPI ranks. We only want the node to show up once in the SZL file, so we need to tell TecIO-MPI which nodes are the ghost nodes. In addition, CFD codes often utilize ghost cells (finite-element cells duplicated between MPI ranks) which must be supplied to TecIO-MPI. This information took a little effort to extract from the SU2 “output” framework.

The first test case is the Common Research Model from the
High-Lift Prediction workshop.

How Well Does It Perform?

We now have a version of SU2 that is capable of writing SZL files in parallel while being run on an HPC system. The next obvious questions: “How well does it perform?”

Test Case #1: Common Research Model (CRM) in High-Lift Configuration

The first test case is the Common Research Model from the High-Lift Prediction workshop. It was run with 3 grid refinement levels:

• 10 million cells
• 5 million cells
• 118 million cells

These refinements allowed us to measure the effect of problem size on the overhead of parallel output. All three cases were run on 640 MPI Ranks on the NCSA Blue Waters supercomputer. The results are shown in the following table:

For comparison we include the cost of incrementing the solution a single CFD time step and the cost of writing an SU2 restart file. It should be noted that the SU2 restart file only contains the conservative field variables – no grid variables and no auxiliary variables – so there is far less writing involved with the creation of the restart file. The cost of writing the SZL file is roughly 2.5 the cost of a single time step. If you write the SZL file infrequently (every 100 steps or so) this overhead is fairly small (2.5%).

Test Case #2: Inlet

The second test case is an inlet like you might find on the next generation jet fighter. It aggressively compresses the flow to keep the inlet as short as possible.

The inlet was analyzed using 93 million tetrahedral cells and 38 million nodes. As with the CRM case, the inlet case was run on the NCSA Blue Waters computer using 640 MPI ranks.

SU2 takes 74.7 seconds to increment the inlet CFD solution by one time-step and 31 seconds to write a restart file. To write the SZL plot file requires 216 seconds – 2.9 times as long as a single CFD time step.

Availability

The parallel SZL file output is currently in the pull-request phase of SU2 development. Once it is accepted it will be available in the Develop branch on GitHub. On occasion (I’m told every six months to a year), the develop branch is merged into the master branch. If you are interested in trying the parallel SZL output from SU2, send me an email (scottimlay@tecplot.com) and I’ll let you know which branch to download.

Better yet, subscribe to our TecIO Newsletter and we will send you the updates.

Subscribe to Tecplot

Scott Imlay
Chief Technical Officer
Tecplot, Inc.

The post Parallel SZL Output from SU2 appeared first on Tecplot.

Understanding What Customers are Seeing

To understand what our customers were seeing, we needed to be able to run our software on hardware representative of what our customers were running on, namely, a supercomputer. The problem is that we don’t own one. We also needed parallel profiling software that would help us identify bottlenecks, or “hot spots,” in our code, including in the MPI inter-process communication. We made some progress in Amazon EC2 using open-source profiling software, but had greater success using Arm (formerly Allinea) Forge software at the National Center for Supercomputing Applications (NCSA).

NCSA has an industrial partners program that provides access to their iForge supercomputer and a wide array of open source and commercial software, including Arm Forge. iForge has over 2,000 CPU cores and runs IBM’s GPFS parallel file system, so it was a good platform to test our software. Arm Forge, specifically its MAP profiling tool, provided the ability to easily identify hot spots in our software, and to drill down through the layers of our source code to see exactly where the performance problems lay.

An additional application to NCSA also gave us access to their Blue Waters petascale supercomputer, which features about 400,000 CPU cores and the Lustre parallel file system¹. This gave us the ability to scale our testing up to larger problems, and to test the performance on another popular parallel file system.

Arm MAP with Region of Time Selected

Performance Improvement Results

Using iForge hardware and Arm Forge software, we were able to identify two sources of performance problems in TecIO-MPI:

• Excessive time spent in writing small chunks of data to disk.
• Too much inter-process exchange of small chunks of data.

Consolidating these has led to an order-of-magnitude reduction in output time. Testing with three different computational fluid dynamics (CFD) flow solvers indicates output times, for structured or unstructured grids, roughly equal to the time required to compute a single solver iteration.

We will continue to collect feedback from users with an eye to additional improvements as TecIO-MPI is implemented in additional solvers. We invite you to provide us with your own experience!

Take our TecIO Survey

How to Obtain TecIO Libraries

TecIO and TecIO-MPI, along with instructions in Tecplot’s Data Format Guide, are installed with every Tecplot 360 installation.

It is recommended, however, that you obtain and compile source for TecIO-MPI applications, because the various MPI implementations are not binary-compatible. Source for TecIO and TecIO-MPI, and the Data Format Guide, are all available via a My Tecplot account.

For more information and access to the TecIO Library, please visit:

TecIO Library

¹This research is part of the Blue Waters sustained-petascale computing project, which is supported by the National Science Foundation (awards OCI-0725070 and ACI-1238993) and the state of Illinois. Blue Waters is a joint effort of the University of Illinois at Urbana-Champaign and its National Center for Supercomputing Applications.

By Dr. David E. Taflin
Senior Software Development Engineer | Tecplot, Inc.
Read Dave’s employee profile »

The post Improving TecIO-MPI’s Parallel Output Performance appeared first on Tecplot.

Data Alteration through Equations

This blog was originally published in 2013 and has been updated and expanded.

The post Calculating a New Variable appeared first on Tecplot.

Developing a method of simulating fish behavior can lead to protecting and preserving migratory fish runs. One of our most loved blogs, originally titled “Some Fishy Business for the Army Corps of Engineers” was written in 2011. It has been updated and is re-posted here.

The U.S. Army Corps of Engineers’ (USACE) mission is to provide vital public engineering services in peace and war to strengthen our nation’s security, energize the economy, and reduce risks from disasters. Maintaining the nation’s inland waterways is found beneath that large umbrella and in support of that mission, USACE has been developing an exciting new way of protecting and preserving migratory fish runs.

Tecplot 360 Reads Many CFD Solution File Formats

Dr. Goodwin contracts with companies to produce the CFD results he needs. Due to the large number of CFD simulation codes in use today, he was finding it increasingly important to modify his code to read a wide variety of CFD solution file formats, including the n-faced polyhedral meshes used by two of the most popular CFD solvers.

After examining a number of options, he selected Tecplot 360 to do this work for him. This was a good fit because Tecplot 360 already reads the most popular CFD file formats, and has an extensible architecture that allows Dr. Goodwin’s solver to interact with any data Tecplot 360 can read. And I was the lucky Tecplot developer selected to do the interfacing work.

I subsequently wrote a CFD post-processing Tecplot add-on to perform some clean-up operations on legacy CFD data to make it suitable input for Dr. Goodwin’s simulations. This “fishy business” was challenging and interesting, and I have enjoyed seeing the results that Dr. Goodwin produced with Tecplot assistance.

And finally, a required disclaimer: Any statements, opinions, findings, conclusions, or recommendations expressed in this material are those of the authors and do not necessarily reflect the views or policies of the federal sponsors, and no official endorsement should be inferred.

By Dave Taflin
Developer | Tecplot, Inc.
Read Dave’s employee profile »

The post Simulating Fish Behavior to Protect Migratory Fish Runs appeared first on Tecplot.

The post AVEVA says full steam ahead appeared first on Schnitger Corporation.

The post Helping to rebuild Notre Dame appeared first on Schnitger Corporation.

The post First steps to AI: data, man appeared first on Schnitger Corporation.

The post Nemetschek ups rendering with Redshift appeared first on Schnitger Corporation.

The post Quickie: AVEVA adds asset performance assets appeared first on Schnitger Corporation.

The post OnScale secures $10 million investment appeared first on Schnitger Corporation.