 |
 |
 |
|
|
|
[Sponsors] | ||||
Strong winds blowing across Lake Michigan created this diamond-shaped wave pattern after the incoming waves reflected off the breakwater on the right. The formal name for these waves are clapotis gaufré, meaning “waffled standing waves”. As seen in the animation above, the waves aren’t perfect standing waves; otherwise they would stay in one place rather than propagating toward shore. This happens because the angle of reflection is not exactly 90 degrees.
As neat as clapotis gaufré waves look, they’re a significant problem for the builders of coastal infrastructure. The waves generate vortices underwater that are extremely good at eroding underlying sediment. (Image and video credit: T. Wenzel; via EPOD; submitted by Vince D.)
These colorful swirls show sediment and organic matter carried into the Arctic Ocean. Like dyes or tracer particles in a lab experiment, this run-off reveals the complicated patterns of mixing where freshwater and salt water mix. Delicate as they appear, these eddies are tens of kilometers across. Zoom in on the full resolution image to really appreciate the details, like the feathery edges between layers. (Image credit: N. Kuring; via NASA Earth Observatory)
Scientists do all manner of odd things in the name of science. To teach bar-headed geese – birds capable of flying at the altitude of Everest – to fly in a wind tunnel, one group of researchers fostered a group of geese from the moment they hatched. They taught them to fly, first by chasing their bicycling parent and then following her on a motor scooter. Only then could they train the geese to fly in a wind tunnel designed to test how these birds manage to keep flying with only 30% of the oxygen found at sea level*.
The birds’ secret, it turns out, is metabolic. As the oxygen dropped, so did the temperature of the geese’s blood. Hemoglobin, which binds oxygen in blood cells, is more efficient at lower temperatures, allowing the birds to get more oxygen. At the same time, though, their overall metabolism slowed down, meaning that they required less oxygen overall to function. Taken together, these adaptations make the geese excellent fliers in conditions most animals cannot tolerate. (Image and research credit: J. Meir et al.; via WashPo; submitted by Marc A.)
* Occasionally I get comments pointing out that drag decreases with altitude, thereby making it easier to cut through the air. While this is true, I can say from my own experience of living and exercising at altitude that, for most of us, the effects of low oxygen levels far outweigh the savings in drag. It’s hard to appreciate a tiny drop in drag when your heart rate is sky high!
Last December, the collapsing flank of the Anak Krakatoa volcano caused a deadly tsunami in Indonesia. Using satellite imagery, scientists have now constructed a timeline of the island’s dramatic restructuring. In the process, they found that the landslide that triggered the tsunami was likely much smaller than originally estimated.
Their evidence shows that the landslide and tsunami (Image B) occurred before the eruption that destroyed the volcano’s cone. In fact, the landslide seems to have created a vent that opened directly underwater, which explains the increased violence of the eruption in late December and the eventual destruction of the volcano’s cone (Image C). After that, the underwater vent closed off and the eruption returned to its quieter state as the volcano began rebuilding its cone (Image D).
The key finding here is that the initial landslide contained roughly a third of the material originally estimated. That means our tsunami models have been seriously underestimating the catastrophic potential of smaller volcanic landslides. Hopefully the lessons we learn from Anak Krakatoa will help us avoid future tragedies. (Image and research credit: R. Williams et al.; via BBC; submitted by Kam-Yung Soh)
In an avalanche, grains spontaneously flow when a slope reaches a critical angle, and they continue flowing until they settle at a new, lower angle. Scientists have long debated why this angle mismatch occurs, and, in recent years, the general opinion was that the avalanche’s inertia kept it flowing long enough to settle at a lower angle. But a new experiment, using a slowly-rotating drum similar to the one above*, shows that friction, not inertia, is the key player.
The researchers used silica beads suspended in water, which allowed them to cleverly control the interparticle friction. In water, silica beads build up negative electrostatic charges, which push the grains apart and eliminate friction. In that frictionless state, the researchers found that the beads tumbled smoothly; their starting and ending angles were always the same.
By adding salt to the water, the researchers were able to eliminate some of the electrostatic charge and thereby tune the friction. When they did that, the difference between starting and stopping angles came back and grew more substantial as the friction increased. All in all, the results indicate that friction between particles is what makes an avalanche avalanche. (Image credit: J. Gray and V. Chugunov, source; research credit: H. Perrin et al.; via APS Physics; submitted by Kam-Yung Soh)
* If you’re curious about the patterns in the image, I explain them in this previous post.
Even when the sky is mostly blue, there’s a lot going on at different altitudes. The winds do not move in a consistent direction or at the same speed, something which becomes apparent when watching clouds move relative to one another. When different layers of air move past one another, there is shear between them, not unlike the friction you feel when running your hand along a table. Under the right circumstances, this shear creates Kelvin-Helmholtz waves like the ones in this image over Helena Valley, Montana. Fast-moving winds (blowing right to left in the image) above a layer of clouds created these breaking wave-like curls. The same phenomenon creates many of the ocean’s waves from the shear caused by wind blowing across water. (Image credit: H. Martin, via EPOD)
There is an interesting new trend in using Computational Fluid Dynamics (CFD). Until recently CFD simulation was focused on existing and future things, think flying cars. Now we see CFD being applied to simulate fluid flow in the distant past, think fossils.
CFD shows Ediacaran dinner party featured plenty to eat and adequate sanitation
Let's first address the elephant in the room - it's been a while since the last Caedium release. The multi-substance infrastructure for the Conjugate Heat Transfer (CHT) capability was a much larger effort than I anticipated and consumed a lot of resources. This lead to the relative quiet you may have noticed on our website. However, with the new foundation laid and solid we can look forward to a bright future.
Conjugate Heat Transfer Through a Water-Air Radiator
Simulation shows separate air and water streamline paths colored by temperature
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
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
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
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
#!/bin/sh
cd ${0%/*} || exit 1 # Run from this directory
# Test if gnuplot exists on the system
command -v gnuplot >/dev/null 2>&1 || {
echo "gnuplot not found - skipping graph creation" 1>&2
exit 1
}
gnuplot<<GNUPLOT
set term post enhanced color solid linewidth 2.0 20
set out "graphs.eps"
set encoding utf8
set termoption dash
set style increment user
set style line 1 lt 1 linecolor rgb "blue" linewidth 1.5
set style line 11 lt 2 linecolor rgb "black" linewidth 1.5
time = system("foamListTimes -case .. -latestTime")
set xlabel "x"
set ylabel "u'"
set title "T3A - Flat Plate - turbulent intensity"
plot [:1.5][:0.05] \
"../postProcessing/kGraph/".time."/line_k.xy" \
u (\$1-0.04):(1./5.4*sqrt(2./3.*\$2))title "kOmegaSSTLM" w l ls 1, \
"exptData/T3A.dat" u (\$1/1000):(\$3/100) title "Exp T3A" w p ls 11
set xlabel "Re_x"
set ylabel "c_f"
set title "T3A - Flat Plate - C_f"
plot [:6e+5][0:0.01] \
"../postProcessing/wallShearStressGraph/".time."/line_wallShearStress.xy" \
u ((\$1-0.04)*5.4/1.5e-05):(-\$2/0.5/5.4**2) title "kOmegaSSTLM" w l, \
"exptData/T3A.dat" u (\$1/1000*5.4/1.51e-05):2 title "Exp" w p ls 11
GNUPLOT
#------------------------------------------------------------------------------
# #!/bin/sh
# cd ${0%/*} || exit 1 # Run from this directory
# # Test if gnuplot exists on the system
# command -v gnuplot >/dev/null 2>&1 || {
# echo "gnuplot not found - skipping graph creation" 1>&2
# exit 1
# }
# gnuplot<<GNUPLOT
set term post enhanced color solid linewidth 2.0 20
set out "graphs2.eps"
set encoding utf8
set termoption dash
set style increment user
set style line 1 lt 1 linecolor rgb "blue" linewidth 1.5
set style line 11 lt 2 linecolor rgb "black" linewidth 1.5
time = system("foamListTimes -case .. -latestTime")
# set xlabel "x"
# set ylabel "u'"
# set title "T3A - Flat Plate - turbulent intensity"
# plot [:1.5][:0.05] \
# "../postProcessing/kGraph/".time."/line_k.xy" \
# u (\$1-0.04):(1./5.4*sqrt(2./3.*\$2))title "kOmegaSSTLM" w l ls 1, \
# "exptData/T3A.dat" u (\$1/1000):(\$3/100) title "Exp T3A" w p ls 11
set xlabel "Re_x"
set ylabel "c_f"
set title "T3A - Flat Plate - C_f"
plot [:6e+5][0:0.01] \
"/home/purnp2/OpenFOAM/purnp2-v1812/run/T3A/postProcessing/wallShearStressGraph/269/line_wallShearStress.xy" \
u (($1-0.04)*5.4/1.5e-05):(-$2/0.5/5.4**2) title "kOmegaSSTLM" w l, \
"/home/purnp2/OpenFOAM/purnp2-v1812/run/T3A/validation/exptData/T3A.dat" u ($1/1000*5.4/1.51e-05):2 title "Exp" w p ls 11
# GNUPLOT
#------------------------------------------------------------------------------
In this post, I’ll give a simple example of how to create curves in blockMesh. For this example, we’ll look at the following basic setup:
As you can see, we’ll be simulating the flow over a bump defined by the curve:
First, let’s look at the basic blockMeshDict for this blocking layout WITHOUT any curves defined:
/*--------------------------------*- C++ -*----------------------------------*\
========= |
\\ / F ield | OpenFOAM: The Open Source CFD Toolbox
\\ / O peration | Website: https://openfoam.org
\\ / A nd | Version: 6
\\/ M anipulation |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
convertToMeters 1;
vertices
(
(-1 0 0) // 0
(0 0 0) // 1
(1 0 0) // 2
(2 0 0) // 3
(-1 2 0) // 4
(0 2 0) // 5
(1 2 0) // 6
(2 2 0) // 7
(-1 0 1) // 8
(0 0 1) // 9
(1 0 1) // 10
(2 0 1) // 11
(-1 2 1) // 12
(0 2 1) // 13
(1 2 1) // 14
(2 2 1) // 15
);
blocks
(
hex (0 1 5 4 8 9 13 12) (20 100 1) simpleGrading (0.1 10 1)
hex (1 2 6 5 9 10 14 13) (80 100 1) simpleGrading (1 10 1)
hex (2 3 7 6 10 11 15 14) (20 100 1) simpleGrading (10 10 1)
);
edges
(
);
boundary
(
inlet
{
type patch;
faces
(
(0 8 12 4)
);
}
outlet
{
type patch;
faces
(
(3 7 15 11)
);
}
lowerWall
{
type wall;
faces
(
(0 1 9 8)
(1 2 10 9)
(2 3 11 10)
);
}
upperWall
{
type patch;
faces
(
(4 12 13 5)
(5 13 14 6)
(6 14 15 7)
);
}
frontAndBack
{
type empty;
faces
(
(8 9 13 12)
(9 10 14 13)
(10 11 15 14)
(1 0 4 5)
(2 1 5 6)
(3 2 6 7)
);
}
);
// ************************************************************************* //This blockMeshDict produces the following grid:
It is best practice in my opinion to first make your blockMesh without any edges. This lets you see if there are any major errors resulting from the block topology itself. From the results above, we can see we’re ready to move on!
So now we need to define the curve. In blockMesh, curves are added using the edges sub-dictionary. This is a simple sub dictionary that is just a list of interpolation points:
edges
(
polyLine 1 2
(
(0 0 0)
(0.1 0.0309016994 0)
(0.2 0.0587785252 0)
(0.3 0.0809016994 0)
(0.4 0.0951056516 0)
(0.5 0.1 0)
(0.6 0.0951056516 0)
(0.7 0.0809016994 0)
(0.8 0.0587785252 0)
(0.9 0.0309016994 0)
(1 0 0)
)
polyLine 9 10
(
(0 0 1)
(0.1 0.0309016994 1)
(0.2 0.0587785252 1)
(0.3 0.0809016994 1)
(0.4 0.0951056516 1)
(0.5 0.1 1)
(0.6 0.0951056516 1)
(0.7 0.0809016994 1)
(0.8 0.0587785252 1)
(0.9 0.0309016994 1)
(1 0 1)
)
);The sub-dictionary above is just a list of points on the curve 
The following mesh is produced:
Hopefully this simple example will help some people looking to incorporate curved edges into their blockMeshing!
Cheers.
This offering is not approved or endorsed by OpenCFD Limited, producer and distributor of the OpenFOAM software via www.openfoam.com, and owner of theOPENFOAM® andOpenCFD® trademarks.
Experimentally visualizing high-speed flow was a serious challenge for decades. Before the advent of modern laser diagnostics and velocimetry, the only real techniques for visualizing high speed flow fields were the optical techniques of Schlieren and Shadowgraph.
Today, Schlieren and Shadowgraph remain an extremely popular means to visualize high-speed flows. In particular, Schlieren and Shadowgraph allow us to visualize complex flow phenomena such as shockwaves, expansion waves, slip lines, and shear layers very effectively.
In CFD there are many reasons to recreate these types of images. First, they look awesome. Second, if you are doing a study comparing to experiments, occasionally the only full-field data you have could be experimental images in the form of Schlieren and Shadowgraph.
Without going into detail about Schlieren and Shadowgraph themselves, primarily you just need to understand that Schlieren and Shadowgraph represent visualizations of the first and second derivatives of the flow field refractive index (which is directly related to density).
In Schlieren, a knife-edge is used to selectively cut off light that has been refracted. As a result you get a visualization of the first derivative of the refractive index in the direction normal to the knife edge. So for example, if an experiment used a horizontal knife edge, you would see the vertical derivative of the refractive index, and hence the density.
For Shadowgraph, no knife edge is used, and the images are a visualization of the second derivative of the refractive index. Unlike the Schlieren images, shadowgraph has no direction and shows you the laplacian of the refractive index field (or density field).
In this post, I’ll use a simple case I did previously (https://curiosityfluids.com/2016/03/28/mach-1-5-flow-over-23-degree-wedge-rhocentralfoam/) as an example and produce some synthetic Schlieren and Shadowgraph images using the data.
Well as you might expect, from the introduction, we simply do this by visualizing the gradients of the density field.
In ParaView the necessary tool for this is:
Gradient of Unstructured DataSet:
Once you’ve selected this, we then need to set the properties so that we are going to operate on the density field:
To do this, simply set the “Scalar Array” to the density field (rho), and change the name of the result Array name to SyntheticSchlieren. Now you should see something like this:
There are a few problems with the above image (1) Schlieren images are directional and this is a magnitude (2) Schlieren and Shadowgraph images are black and white. So if you really want your Schlieren images to look like the real thing, you should change to black and white. ALTHOUGH, Cold and Hot, Black-Body radiation, and Rainbow Desatured all look pretty amazing.
To fix these, you should only visualize one component of the Synthetic Schlieren array at a time, and you should visualize using the X-ray color preset:
The results look pretty realistic:
The process of computing the shadowgraph field is very similar. However, recall that shadowgraph visualizes the Laplacian of the density field. BUT THERE IS NO LAPLACIAN CALCULATOR IN PARAVIEW!?! Haha no big deal. Just remember the basic vector calculus identity:
Therefore, in order for us to get the Shadowgraph image, we just need to take the Divergence of the Synthetic Schlieren vector field!
To do this, we just have to use the Gradient of Unstructured DataSet tool again:
This time, Deselect “Compute Gradient” and the select “Compute Divergence” and change the Divergence array name to Shadowgraph.
Visualized in black and white, we get a very realistic looking synthetic Shadowgraph image:
Now this is an important question, but a simple one to answer. And the answer is…. not much. Physically, we know exactly what these mean, these are: Schlieren is the gradient of the density field in one direction and Shadowgraph is the laplacian of the density field. But what you need to remember is that both Schlieren and Shadowgraph are qualitative images. The position of the knife edge, brightness of the light etc. all affect how a real experimental Schlieren or Shadowgraph image will look.
This means, very often, in order to get the synthetic Schlieren to closely match an experiment, you will likely have to change the scale of your synthetic images. In the end though, you can end up with extremely realistic and accurate synthetic Schlieren images.
Hopefully this post will be helpful to some of you out there. Cheers!
Sutherland’s equation is a useful model for the temperature dependence of the viscosity of gases. I give a few details about it in this post: https://curiosityfluids.com/2019/02/15/sutherlands-law/
The law given by:
It is also often simplified (as it is in OpenFOAM) to:
In order to use these equations, obviously, you need to know the coefficients. Here, I’m going to show you how you can simply create your own Sutherland coefficients using least-squares fitting Python 3.
So why would you do this? Basically, there are two main reasons for this. First, if you are not using air, the Sutherland coefficients can be hard to find. If you happen to find them, they can be hard to reference, and you may not know how accurate they are. So creating your own Sutherland coefficients makes a ton of sense from an academic point of view. In your thesis or paper, you can say that you created them yourself, and not only that you can give an exact number for the error in the temperature range you are investigating.
So let’s say we are looking for a viscosity model of Nitrogen N2 – and we can’t find the coefficients anywhere – or for the second reason above, you’ve decided its best to create your own.
By far the simplest way to achieve this is using Python and the Scipy.optimize package.
Step 1: Get Data
The first step is to find some well known, and easily cited, source for viscosity data. I usually use the NIST webbook (
https://webbook.nist.gov/), but occasionally the temperatures there aren’t high enough. So you could also pull the data out of a publication somewhere. Here I’ll use the following data from NIST:
| Temparature (K) | Viscosity (Pa.s) |
| 200 |
0.000012924 |
| 400 | 0.000022217 |
| 600 | 0.000029602 |
| 800 | 0.000035932 |
| 1000 | 0.000041597 |
| 1200 | 0.000046812 |
| 1400 | 0.000051704 |
| 1600 | 0.000056357 |
| 1800 | 0.000060829 |
| 2000 | 0.000065162 |
This data is the dynamics viscosity of nitrogen N2 pulled from the NIST database for 0.101 MPa. (Note that in these ranges viscosity should be only temperature dependent).
Step 2: Use python to fit the data
If you are unfamiliar with Python, this may seem a little foreign to you, but python is extremely simple.
First, we need to load the necessary packages (here, we’ll load numpy, scipy.optimize, and matplotlib):
![\nabla^2\left[\right] = \nabla \cdot \nabla \left[\right]](https://s0.wp.com/latex.php?latex=%5Cnabla%5E2%5Cleft%5B%5Cright%5D++%3D+%5Cnabla+%5Ccdot+%5Cnabla+%5Cleft%5B%5Cright%5D&bg=ffffff&fg=000000&s=0 "\nabla^2\left[\right] = \nabla \cdot \nabla \left[\right]")
import numpy as np
import matplotlib.pyplot as plt
from scipy.optimize import curve_fitNow we define the sutherland function:
def sutherland(T, As, Ts):
return As*T**(3/2)/(Ts+T)Next we input the data:
T=[200,
400,
600,
800,
1000,
1200,
1400,
1600,
1800,
2000]
mu=[0.000012924,
0.000022217,
0.000029602,
0.000035932,
0.000041597,
0.000046812,
0.000051704,
0.000056357,
0.000060829,
0.000065162]Then we fit the data using the curve_fit function from scipy.optimize. This function uses a least squares minimization to solve for the unknown coefficients. The output variable popt is an array that contains our desired variables As and Ts.
popt = curve_fit(sutherland, T, mu)
As=popt[0]
Ts=popt[1]Now we can just output our data to the screen and plot the results if we so wish:
print('As = '+str(popt[0])+'\n')
print('Ts = '+str(popt[1])+'\n')
xplot=np.linspace(200,2000,100)
yplot=sutherland(xplot,As,Ts)
plt.plot(T,mu,'ok',xplot,yplot,'-r')
plt.xlabel('Temperature (K)')
plt.ylabel('Dynamic Viscosity (Pa.s)')
plt.legend(['NIST Data', 'Sutherland'])
plt.show()Overall the entire code looks like this:
import numpy as np
import matplotlib.pyplot as plt
from scipy.optimize import curve_fit
def sutherland(T, As, Ts):
return As*T**(3/2)/(Ts+T)
T=[200, 400, 600,
800,
1000,
1200,
1400,
1600,
1800,
2000]
mu=[0.000012924,
0.000022217,
0.000029602,
0.000035932,
0.000041597,
0.000046812,
0.000051704,
0.000056357,
0.000060829,
0.000065162]
popt, pcov = curve_fit(sutherland, T, mu)
As=popt[0]
Ts=popt[1]
print('As = '+str(popt[0])+'\n')
print('Ts = '+str(popt[1])+'\n')
xplot=np.linspace(200,2000,100)
yplot=sutherland(xplot,As,Ts)
plt.plot(T,mu,'ok',xplot,yplot,'-r')
plt.xlabel('Temperature (K)')
plt.ylabel('Dynamic Viscosity (Pa.s)')
plt.legend(['NIST Data', 'Sutherland'])
plt.show()
And the results for nitrogen gas in this range are As=1.55902E-6, and Ts=168.766 K. Now we have our own coefficients that we can quantify the error on and use in our academic research! Wahoo!
In this post, we looked at how we can simply use a database of viscosity-temperature data and use the python package scipy to solve for our unknown Sutherland viscosity coefficients. This NIST database was used to grab some data, and the data was then loaded into Python and curve-fit using scipy.optimize curve_fit function.
This task could also easily be accomplished using the Matlab curve-fitting toolbox, or perhaps in excel. However, I have not had good success using the excel solver to solve for unknown coefficients.
The most common complaint I hear, and the most common problem I observe with OpenFOAM is its supposed “steep learning curve”. I would argue however, that for those who want to practice CFD effectively, the learning curve is equally as steep as any other software.
There is a distinction that should be made between “user friendliness” and the learning curve required to do good CFD.
While I concede that other commercial programs have better basic user friendliness (a nice graphical interface, drop down menus, point and click options etc), it is equally as likely (if not more likely) that you will get bad results in those programs as with OpenFOAM. In fact, to some extent, the high user friendliness of commercial software can encourage a level of ignorance that can be dangerous. Additionally, once you are comfortable operating in the OpenFOAM world, the possibilities become endless and things like code modification, and bash and python scripting can make OpenFOAM worklows EXTREMELY efficient and powerful.
Anyway, here are a few tips to more easily tackle the OpenFOAM learning curve:
(1) Understand CFD
This may seem obvious… but its not to some. Troubleshooting bad simulation results or unstable simulations that crash is impossible if you don’t have at least a basic understanding of what is happening under the hood. My favorite books on CFD are:
(a) The Finite Volume Method in Computational Fluid Dynamics: An Advanced Introduction with OpenFOAM® and Matlab by
F. Moukalled, L. Mangani, and M. Darwish
(b) An introduction to computational fluid dynamics – the finite volume method – by H K Versteeg and W Malalasekera
(c) Computational fluid dynamics – the basics with applications – By John D. Anderson
(2) Understand fluid dynamics
Again, this may seem obvious and not very insightful. But if you are going to assess the quality of your results, and understand and appreciate the limitations of the various assumptions you are making – you need to understand fluid dynamics. In particular, you should familiarize yourself with the fundamentals of turbulence, and turbulence modeling.
(3) Avoid building cases from scratch
Whenever I start a new case, I find the tutorial case that most closely matches what I am trying to accomplish. This greatly speeds things up. It will take you a super long time to set up any case from scratch – and you’ll probably make a bunch of mistakes, forget key variable entries etc. The OpenFOAM developers have done a lot of work setting up the tutorial cases for you, so use them!
As you continue to work in OpenFOAM on different projects, you should be compiling a library of your own templates based on previous work.
(4) Using Ubuntu makes things much easier
This is strictly my opinion. But I have found this to be true. Yes its true that Ubuntu has its own learning curve, but I have found that OpenFOAM works seamlessly in the Ubuntu or any Ubuntu-like linux environment. OpenFOAM now has Windows flavors using docker and the like- but I can’t really speak to how well they work – mostly because I’ve never bothered. Once you unlock the power of Linux – the only reason to use Windows is for Microsoft Office (I guess unless you’re a gamer – and even then more and more games are now on Linux). Not only that- but the VAST majority of forums and troubleshooting associated with OpenFOAM you’ll find on the internet are from Ubuntu users.
I much prefer to use Ubuntu with a virtual Windows environment inside it. My current office setup is my primary desktop running Ubuntu – plus a windows VirtualBox, plus a laptop running windows that I use for traditional windows type stuff. Dual booting is another option, but seamlessly moving between the environments is easier.
(5) If you’re struggling, simplify
Unless you know exactly what you are doing, you probably shouldn’t dive into the most complicated version of whatever you are trying to solve/study. It is best to start simple, and layer the complexity on top. This way, when something goes wrong, it is much easier to figure out where the problem is coming from.
(6) Familiarize yourself with the cfd-online forum
If you are having trouble, the cfd-online forum is super helpful. Most likely, someone else is has had the same problem you have. If not, the people there are extremely helpful and overall the forum is an extremely positive environment for working out the kinks with your simulations.
(7) The results from checkMesh matter
If you run checkMesh and your mesh fails – fix your mesh. This is important. Especially if you are not planning on familiarizing yourself with the available numerical schemes in OpenFOAM, you should at least have a beautiful mesh. In particular, if your mesh is highly non-orthogonal, you will have serious problems. If you insist on using a bad mesh, you will probably need to manipulate the numerical schemes. A great source for how schemes should be manipulated based on mesh non-orthogonality is:
http://www.wolfdynamics.com/wiki/OFtipsandtricks.pdf
(8) CFL Number Matters
If you are running a transient case, the Courant-Freidrechs-Lewis (CFL) number matters… a lot. Not just for accuracy (if you are trying to capture a transient event) but for stability. If your time-step is too large you are going to have problems. There is a solid mathematical basis for this stability criteria for advection-diffusion problems. Additionally the Navier-Stokes equations are very non-linear and the complexity of the problem and the quality of your grid etc can make the simulation even less stable. When I have a transient simulation crash, if I know my mesh is OK, I decrease the timestep by a factor of 2. More often than not, this solves the problem.
For large time stepping, you can add outer loops to solvers based on the pimple algorithm, but you may end up losing important transient information. Excellent explanation of how to do this is given in the book by T. Holzmann:
https://holzmann-cfd.de/publications/mathematics-numerics-derivations-and-openfoam
For the record, this points falls into point (1) of Understanding CFD.
(9) Work through the OpenFOAM Wiki “3 Week” Series
If you are starting OpenFOAM for the first time, it is worth it to work through an organized program of learning. One such example (and there are others) is the “3 Weeks Series” on the OpenFOAM wiki:
https://wiki.openfoam.com/%223_weeks%22_series
If you are a graduate student, and have no job to do other than learn OpenFOAM, it will not take 3 weeks. This touches on all the necessary points you need to get started.
(10) OpenFOAM is not a second-tier software – it is top tier
I know some people who have started out with the attitude from the get-go that they should be using a different software. They think somehow Open-Source means that it is not good. This is a pretty silly attitude. Many top researchers around the world are now using OpenFOAM or some other open source package. The number of OpenFOAM citations has grown every year consistently (
https://www.linkedin.com/feed/update/urn:li:groupPost:1920608-6518408864084299776/?commentUrn=urn%3Ali%3Acomment%3A%28groupPost%3A1920608-6518408864084299776%2C6518932944235610112%29&replyUrn=urn%3Ali%3Acomment%3A%28groupPost%3A1920608-6518408864084299776%2C6518956058403172352%29).
In my opinion, the only place where mainstream commercial CFD packages will persist is in industry labs where cost is no concern, and changing software is more trouble than its worth. OpenFOAM has been widely benchmarked, and widely validated from fundamental flows to hypersonics (see any of my 17 publications using it for this). If your results aren’t good, you are probably doing something wrong. If you have the attitude that you would rather be using something else, and are bitter that your supervisor wants you to use OpenFOAM, when something goes wrong you will immediately think there is something wrong with the program… which is silly – and you may quit.
(11) Meshing… Ugh Meshing
For the record, meshing is an art in any software. But meshing is the only area where I will concede any limitation in OpenFOAM. HOWEVER, as I have outlined in my previous post (https://curiosityfluids.com/2019/02/14/high-level-overview-of-meshing-for-openfoam/) most things can be accomplished in OpenFOAM, and there are enough third party meshing programs out there that you should have no problem.
Basically, if you are starting out in CFD or OpenFOAM, you need to put in time. If you are expecting to be able to just sit down and produce magnificent results, you will be disappointed. You might quit. And frankly, thats a pretty stupid attitude. However, if you accept that CFD and fluid dynamics in general are massive fields under constant development, and are willing to get up to speed, there are few limits to what you can accomplish.
Please take the time! If you want to do CFD, learning OpenFOAM is worth it. Seriously worth it.
This offering is notapproved or endorsed by OpenCFD Limited, producer and distributorof the OpenFOAM software via www.openfoam.com, and owner of theOPENFOAM® andOpenCFD® trade marks.
Here I will present something I’ve been experimenting with regarding a simplified workflow for meshing airfoils in OpenFOAM. If you’re like me, (who knows if you are) I simulate a lot of airfoils. Partly because of my involvement in various UAV projects, partly through consulting projects, and also for testing and benchmarking OpenFOAM.
Because there is so much data out there on airfoils, they are a good way to test your setups and benchmark solver accuracy. But going from an airfoil .dat coordinate file to a mesh can be a bit of pain. Especially if you are starting from scratch.
The two main ways that I have meshed airfoils to date has been:
(a) Mesh it in a C or O grid in blockMesh (I have a few templates kicking around for this
(b) Generate a “ribbon” geometry and mesh it with cfMesh
(c) Or back in the day when I was a PhD student I could use Pointwise – oh how I miss it.
But getting the mesh to look good was always sort of tedious. So I attempted to come up with a python script that takes the airfoil data file, minimal inputs and outputs a blockMeshDict file that you just have to run.
The goals were as follows:
(a) Create a C-Grid domain
(b) be able to specify boundary layer growth rate
(c) be able to set the first layer wall thickness
(e) be mostly automatic (few user inputs)
(f) have good mesh quality – pass all checkMesh tests
(g) Quality is consistent – meaning when I make the mesh finer, the quality stays the same or gets better
(h) be able to do both closed and open trailing edges
(i) be able to handle most airfoils (up to high cambers)
(j) automatically handle hinge and flap deflections
In Rev 1 of this script, I believe I have accomplished (a) thru (g). Presently, it can only hand airfoils with closed trailing edge. Hinge and flap deflections are not possible, and highly cambered airfoils do not give very satisfactory results.
There are existing tools and scripts for automatically meshing airfoils, but I found personally that I wasn’t happy with the results. I also thought this would be a good opportunity to illustrate one of the ways python can be used to interface with OpenFOAM. So please view this as both a potentially useful script, but also something you can dissect to learn how to use python with OpenFOAM. This first version of the script leaves a lot open for improvement, so some may take it and be able to tailor it to their needs!
Hopefully, this is useful to some of you out there!
You can download the script here:
https://github.com/curiosityFluids/curiosityFluidsAirfoilMesher
Here you will also find a template based on the airfoil2D OpenFOAM tutorial.
(1) Copy curiosityFluidsAirfoilMesher.py to the root directory of your simulation case.
(2) Copy your airfoil coordinates in Selig .dat format into the same folder location.
(3) Modify curiosityFluidsAirfoilMesher.py to your desired values. Specifically, make sure that the string variable airfoilFile is referring to the right .dat file
(4) In the terminal run: python3 curiosityFluidsAirfoilMesher.py
(5) If no errors – run blockMesh
PS
You need to run this with python 3, and you need to have numpy installed
The inputs for the script are very simple:
ChordLength: This is simply the airfoil chord length if not equal to 1. The airfoil dat file should have a chordlength of 1. This variable allows you to scale the domain to a different size.
airfoilfile: This is a string with the name of the airfoil dat file. It should be in the same folder as the python script, and both should be in the root folder of your simulation directory. The script writes a blockMeshDict to the system folder.
DomainHeight: This is the height of the domain in multiples of chords.
WakeLength: Length of the wake domain in multiples of chords
firstLayerHeight: This is the height of the first layer. To estimate the requirement for this size, you can use the curiosityFluids y+ calculator
growthRate: Boundary layer growth rate
MaxCellSize: This is the max cell size along the centerline from the leading edge of the airfoil. Some cells will be larger than this depending on the gradings used.
The following inputs are used to improve the quality of the mesh. I have had pretty good results messing around with these to get checkMesh compliant grids.
BLHeight: This is the height of the boundary layer block off of the surfaces of the airfoil
LeadingEdgeGrading: Grading from the 1/4 chord position to the leading edge
TrailingEdgeGrading: Grading from the 1/4 chord position to the trailing edge
inletGradingFactor: This is a grading factor that modifies the the grading along the inlet as a multiple of the leading edge grading and can help improve mesh uniformity
trailingBlockAngle: This is an angle in degrees that expresses the angles of the trailing edge blocks. This can reduce the aspect ratio of the boundary cells at the top and bottom of the domain, but can make other mesh parameters worse.
Inputs:
With the above inputs, the grid looks like this:
Mesh Quality:
These are some pretty good mesh statistics. We can also view them in paraView:
The clark-y has some camber, so I thought it would be a logical next test to the previous symmetric one. The inputs I used are basically the same as the previous airfoil:
With these inputs, the result looks like this:
Mesh Quality:
Visualizing the mesh quality:
Here is an example of a flying with airfoil (tested since the trailing edge is tilted upwards).
Inputs:
Again, these are basically the same as the others. I have found that with these settings, I get pretty consistently good results. When you change the MaxCellSize, firstLayerHeight, and Grading some modification may be required. However, if you just half the maxCell, and half the firstLayerHeight, you “should” get a similar grid quality just much finer.
Grid Quality:
Visualizing the grid quality
Hopefully some of you find this tool useful! I plan to release a Rev 2 soon that will have the ability to handle highly cambered airfoils, and open trailing edges, as well as control surface hinges etc.
The long term goal will be an automatic mesher with an H-grid in the spanwise direction so that the readers of my blog can easily create semi-span wing models extremely quickly!
Comments and bug reporting encouraged!
DISCLAIMER: This script is intended as an educational and productivity tool and starting point. You may use and modify how you wish. But I make no guarantee of its accuracy, reliability, or suitability for any use. This offering is not approved or endorsed by OpenCFD Limited, producer and distributor of the OpenFOAM software via www.openfoam.com, and owner of the OPENFOAM® and OpenCFD® trademarks.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
As the 2019 CONVERGE User Conference in New Orleans approaches, I’ve been thinking about the past five years of CONVERGE events. Let me take you back to the first CONVERGE User Conference. It was September 2014 in Madison, Wisconsin, and I was one of the first speakers. I talked about two-phase flows and the spray modeling we were doing at Argonne National Laboratory. Many of the people in the audience didn’t know you could do the kinds of calculations in CONVERGE that we were doing. Take needle wobble, for example. At the time, people didn’t know that you could not only move the needle up and down, but you could actually simulate it wobbling. After my talk, we had many interesting discussions with the other attendees. We made connections with international companies that we otherwise would not have had the chance to meet, and we formed collaborations with some of those companies that are still ongoing today.
At Argonne National Laboratory, I lead a team of more than 20 researchers, all of them focused on simulating either piston engines or gas turbines using high-performance computing. Our goal is to improve the predictive capability of piston engine and gas turbine simulations, and we do a lot of our work using CONVERGE. We develop physics-based models that we couple with CONVERGE to gain deeper insights from our simulations.
We routinely attend and present our work at conferences like SAE World Congress and ASME, and what really sets the CONVERGE User Conference apart is the focus of the event—it’s dedicated towards the people doing simulation work with piston engines, gas turbines, and other real-world applications. The user conference is the go-to place where we can meet all of the people doing 3D CFD simulations, so it’s a fantastic networking opportunity. We get to speak to people from academia and industry and learn about their research needs—understand what their pain points are, what their bottlenecks are, where the physics is not predictive enough. Then we take that information back to Argonne, and it helps us focus our research.
Apart from the networking, the CONVERGE User Conference is also a great venue for presenting. My team has presented at the CONVERGE conferences on a wide variety of topics, including lean blow-out in gas turbine combustors, advanced ignition systems, co-optimization of engines and fuels, predicting cycle-to-cycle variation, machine learning for design optimizations, and modeling turbulent combustion in compression ignition and spark ignition engines. The attendees are engaged and highly technical, so you get direct, focused feedback on your work that can help you find solutions to challenges you may be encountering or give ideas for future studies.
The presenters themselves take the conference seriously. The quality of the presentations and the work presented is excellent. If you’ve never attended a CONVERGE User Conference before, my advice to you is to try to be a sponge. Bring your notebooks, bring your laptops, and take as many notes as you can. The amount of useful information you will gain from this conference is enormous and more relevant than other conferences you may attend, since this event is tailored for a specific audience. The CONVERGE User Conference also draws speakers from all over the world, which provides a unique opportunity to hear about the challenges that automotive original equipment manufacturers (OEMs), for example, face in other countries, which are different challenges than those in the United States. Listening to their presentations and getting access to those speakers has been very helpful for us. And since there are plenty of opportunities for networking, you can interact with the speakers at the conference and connect with them later on if you have further questions.
Overall, the CONVERGE User Conference is a great opportunity for presenting, learning, and networking. This is a conference where you will gain a lot of useful knowledge, meet many interesting people, and have some fun at the evening networking events. If you haven’t yet come to a CONVERGE User Conference—I highly recommend making this year your first.
Interested in learning more about the CONVERGE User Conference? Check out our website for details and registration!
On July 16th, I will look up at the night sky and celebrate the 50-year anniversary of the launch of Apollo 11. As I admire the full moon, the CFDer in me will think about the classic metaphor of the three-legged stool. Modern engineering efforts depend on theory, simulation, and experiment: Theory gives us basic understanding, simulation tells us how to apply this theoretical understanding to a practical problem, and experiment confirms that our applied understanding is in agreement with the physical world. One element does not seek to replace another; instead, each element reinforces the others. By modern standards, simulation did not exist in the 1960s—NASA’s primary “computers” were the women we saw in Hidden Figures, and humans are limited to relatively simple calculations. When NASA sent people to the moon, it had to build a modern cathedral balanced atop a two-legged stool.
I like the cathedral metaphor for the Saturn V rocket because it expresses some unexpected similarities between the efforts. A medieval cathedral was a huge, societal construction effort. It required workers from all walks of life to contribute above and beyond, not just in scale but in care and diligence. Designers had to go past what they fully understood, overcoming unknown engineering physics through sheer persistence. The end product was a unique and breathtaking expression of craftsmanship on a colossal scale.
In aerospace, we are habituated to assembly lines, but each Saturn V was a one-off. The Apollo program as a whole employed some 400,000 people, and the Saturn family of launch vehicles was a major slice of the pie. Though their tools were certainly more advanced than a medieval artisan’s, these workers essentially built this 363-foot-tall rocket by hand. They had to, because the rocket had to be perfect. The rocket had to be perfect because there was so little margin for error, because engineers were reaching so far beyond the existing limits of understanding. Huge rockets are not routine today, but I want to highlight a few design challenges of the Saturn V as places where modern simulation tools would have had a program-altering effect.
The mighty F-1 remains the largest single-chambered liquid-fueled rocket engine ever fired. All aspects of the design process were challenging, but devising a practical combustion chamber was particularly torturous. Large rocket engines are prone to a complex interaction between combustion dynamics and aeroacoustics. Pressure waves within the chamber can locally enhance the combustion rate, which in turn alters the flow within the engine. If these physical processes occur at the wrong rates, the entire system can become self-exciting and unstable. From a design standpoint, engineers must control engine stability through chamber shaping, fuel and oxidizer injector design, and internal baffling.
Without any way to simulate the fuel injection, mixing, combustion, and outflow, engineers were left with few approaches other than scaling, experimentation, and doggedness. They started with engines they knew and understood, then tried to vary them and enlarge them. They built a special 2D transparent thrust chamber, then applied high-speed photography to measure the unsteadiness of the combustion region. They literally set off tiny bombs within an operating engine, at a variety of locations, monitoring the internal pressure to see whether the blast waves decayed or were amplified. Eventually they produced a workable design for the F-1, but, in the words of program manager Werner von Braun:
…lack of suitable design criteria has forced the industry to adopt almost a completely empirical approach to injector and combustor development… [which] does not add to our understanding because a solution suitable for one engine system is usually not applicable to another…
It was being performed by engineers, but in some senses, it wasn’t quite engineering. Persistence paid off in the end, but F-1 combustion instability almost derailed the whole Apollo program.
Imagine if Rocketdyne engineers had had access to modern simulation tools! A tool like CONVERGE can simulate liquid fuel spray impingement directly, allowing an engineer to parametrically vary the geometry and spray parameters. A tool like CONVERGE can calculate the local combustion enhancement of impinging pressure fluctuations, allowing an engineer to introduce different baffle shapes and structures to measure their moderating effect. And the engineer can, in von Braun’s words, add to his or her understanding of how to combat combustion instability.
Fuel slosh in the colossal lower-stage tanks presented another design challenge. The first-stage liquid oxygen tank was 33 feet in diameter and about 60 feet long. How do you study slosh in such an immense tank while subjecting it to what you think will be flight-representative vibration and acceleration? What about the behavior of leftover propellant in zero gravity? In the 1960s, the answer was you built the rocket and flew it! In fact, the early Saturn launches (uncrewed, of course) featured video cameras to monitor fuel flow within the tanks. Cameras of that era recorded to film, and these cameras were housed in ejectable capsules. After collecting their several minutes of footage, the capsules would deploy from the spent stage and parachute to safety. I bet those engineers would have been over the moon if you had presented them with modern volume of fluid simulation tools.
Readers who have watched Apollo 13 may recall that the center engine of the Saturn V second stage failed during the launch. This was due to pogo, another combustion instability problem. In a rocket experiencing pogo, a momentary increase in thrust causes the rocket structure to flex, which (at the wrong frequency) can cause the fuel flow to surge, causing another self-exciting momentary increase in thrust. In severe cases, this vibration can destroy the vehicle. Designers added various standpipes and accumulators to de-tune the system, but this was only performed iteratively, flying a rocket to measure the effects. Today, we can study the fluid-structure interaction before we build the structure! Modern simulation tools are dramatic aids to the design process.
Today’s aerospace engineering community is doing some amazing things. SpaceX and Blue Origin are landing rockets on their tails. The United Launch Alliance has compiled a perfect operational record with the Delta IV and Atlas V. Companies like Rocket Lab and Firefly Aerospace are demonstrating that you don’t need to have the resources of a multinational conglomerate to put payloads into orbit. But for me, nothing may ever surpass the incredible feat of engineers battling physical processes they didn’t fully understand, flying people to the moon on a two-legged stool.
Interested in reading more about the Saturn V launch vehicle? I recommend starting with Dr. Roger Bilstein’s Stages to Saturn.
As I’ve started to cook more, I’ve learned the true value of multipurpose kitchen utensils and appliances. Especially living in an apartment with limited kitchen space, the fewer tools I need to make delicious meals, the better. A rice cooker that doubles as a slow cooker? Great. A blender that’s also a food processor? Sign me up. Not only do these tools prove to be more useful, but they’re also more economical.
The same principle applies beyond kitchen appliances. CONVERGE CFD software is well known for its flow solver, autonomous meshing, and fully coupled chemistry solver, but did you know that it also features an extensive suite of chemistry tools, with even more coming in version 3.0? Whether you need to speed up your abnormal combustion simulations, create and validate new chemical mechanisms, expedite your design process with 0D or 1D modeling, or compare your chemical kinetics experiments with simulated results, CONVERGE chemistry tools have you covered. The many capabilities of CONVERGE translate to a broadly applicable piece of software for CFD and beyond.
Zero-Dimensional Simulations
CONVERGE 3.0 expands on the previous versions’ 0D simulation capabilities with a host of new tools and reactors that are useful across a wide range of applications. If you’re running diesel engine simulations, you can take advantage of CONVERGE’s autoignition utility to quickly generate ignition delay data for different combinations of temperature, pressure, and equivalence ratio. Furthermore, you can couple the autoignition utility with 0D sensitivity analysis to determine which reactions and species are important for ignition or to determine the importance of various reactions in forming a given species.
The variable volume tool in CONVERGE 3.0 is a closed homogeneous reactor that can simulate a rapid compression machine (RCM). RCMs are ideal for chemical kinetics studies, especially for understanding autoignition chemistry as a function of temperature, pressure, and fuel/oxygen ratio.
Another new reactor model is the 0D engine tool, which can provide information on autoignition and engine knock. HCCI engines operate by compressing well-mixed fuel and oxidizer to the point of autoignition, and so you can use the 0D engine tool to gain valuable insight into your HCCI engine.
For other applications, look toward the well-stirred reactor (WSR) model coming in 3.0. The WSR assumes a high rate of mixing so that the output composition is identical to the composition inside the reactor. WSRs are thus useful for studying highly mixed IC engines, highly turbulent portions of non-premixed combustors, and ignition and extinction limits on residence time such as lean blow-out in gas turbines.
In addition to the new 0D reactor models, CONVERGE 3.0 will also feature new 0D tools. The chemical equilibrium (CEQ) solver calculates the concentration of species at equilibrium. The CEQ solver in CONVERGE, unlike many equilibrium solvers, is guaranteed to converge for any combination of gas species. The RON/MON estimator finds the research octane number (RON) and motor octane number (MON) for a fuel by finding the critical compression ratio (CCR) at which autoignition occurs and correlates this with the CCR of PRF fuel composition using the LLNL Gasoline Mechanism.
One-Dimensional Simulations
For 1D simulations, CONVERGE contains the 1D laminar premixed flame tool, which calculates the flamespeed of a combustion reaction using a freely propagating flame. You can use this tool to ensure your mechanisms yield reasonable flamespeeds for specific conditions and to generate laminar flamespeed tables that are needed for some combustion models, such as G-Equation, ECFM, and TFM. In CONVERGE 3.0, this solver has seen significant improvement in parallelization and scalability, as shown in Fig. 1. You can additionally perform 1D sensitivity analysis to determine how sensitive the flamespeed is to the various reactions and species in your mechanism.
CONVERGE 3.0 also includes a new 1D reactor model: the plug flow reactor (PFR). PFRs can be used to predict chemical kinetics behavior in continuous, flowing systems with cylindrical geometry. PFRs have commonly been applied to study both homogeneous and heterogeneous reactions, continuous production, and fast or high-temperature reactions.
Chemistry Tools
Zero- and one-dimensional simulation tools aren’t all CONVERGE has to offer. CONVERGE also features a number of tools for optimizing reaction mechanisms and interpreting your chemical kinetics simulation results.
Detailed chemistry calculations can be computationally expensive, but you can decrease computational time by reducing your chemical mechanism. CONVERGE’s mechanism reduction utility eliminates species and reactions that have the least effect on the simulation results, so you can reduce computational expense while maintaining your desired level of accuracy. In previous versions of CONVERGE, mechanism reduction was only available to target ignition delay. In CONVERGE 3.0, you can also target flamespeed, so you can ensure that your reduced mechanism maintains a similar flamespeed as the parent mechanism.
CONVERGE additionally offers a mechanism tuning utility to optimize reaction mechanisms. This tool prepares input files for running a genetic algorithm optimization using CONVERGE’s CONGO utility, so you can tune your mechanism to meet specified performance targets.
If you’re developing multi-component surrogate mechanisms, or you need to add additional pathways or NOx chemistry to a fuel mechanism, the mechanism merge tool is the one for you. This tool combines two reaction mechanisms into one and resolves any duplicate species or reactions along the way.
CONVERGE 3.0 will feature new table generation and visualization tools. With the tabulated kinetics of ignition (TKI) and tabulated laminar flamespeed (TLF) tools, you can generate ignition or flamespeed tables that are needed for certain combustion models. To visualize your results, you can run a CONVERGE utility to prepare your tables for visualization in Tecplot for CONVERGE or other visualization software.
CONVERGE’s suite of chemistry tools is just one of the components that make CONVERGE a robust, multipurpose solver. And just as multipurpose kitchen appliances have more uses during meal prep, CONVERGE’s chemistry capabilities mean our software has a broad scope of applications for not just CFD—but for all of your chemical kinetics simulation needs. Interested in learning more about CONVERGE or CONVERGE’s chemistry tools? Contact us today!
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.
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’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.
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.
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. 
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.
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 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.
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.
Flow Science named one of the fastest growing technology companies in New Mexico for the fourth year running.
Santa Fe, NM, September 11, 2019 — Flow Science was named one of New Mexico Technology’s Flying 40 recipients yet again. The New Mexico Technology Flying 40 awards recognize the 40 fastest growing technology companies in New Mexico each year.
“It is an honor to be recognized for the fourth year in a row by the Flying 40. As Flow Science continues to grow and expand its operation in New Mexico, we strive to appear on this list for years to come,” said Flow Science CEO, Amir Isfahani.
Governor Lujan Grisham said in a personal note to our CEO,
Your company is part of a thriving technology industry… Please keep up the exceptional work, your impact to our state’s economy and growth is crucial.
These awards are given out by the Flying 40 program based on three revenue categories: the top revenue growth companies with revenues between $1 million and $10 million, the top revenue growth companies with revenues of more than $10 million, and the top revenue-producing technology companies irrespective of revenue growth.
“If New Mexico is to become viable outside of oil and gas, it will be because of technology-based businesses and industry. These are the best jobs that are created in terms of income, benefits and longevity. We do the Flying 40 to illustrate why it’s important to have long-term coherent focus on technology based job creation,” said Sherman McCorkle, Chairman of the Sandia Science and Technology Park Development Corporation.
The 22nd annual Flying 40 Awards ceremony was held Wednesday, June 19 at the Albuquerque BioPark Zoo. More information about the Flying 40 program can be found online at http://www.flying40.com/.
Flow Science, Inc., in Santa Fe, New Mexico, has a job opportunity for a motivated, creative and collaborative IT Administrator.
Our software, FLOW-3D, is used by engineers, designers, and scientists at top manufacturers and institutions throughout the world to simulate and optimize product designs. Many of the products used in our daily lives, from many of the components in an automobile to the paper towels we use to dry our hands, have actually been designed or improved through the use of FLOW-3D.
As IT Administrator of this cutting-edge software company, you will work with the company’s internal network and be responsible for system security, infrastructure, performance, and troubleshooting. You will manage user accounts and assist staff with maintenance and upkeep of their hardware and software environments.
This challenging and dynamic role requires the following skills to be successful:
Exceptional candidates will usually have the following skills and experience:
Flow Science offers an exceptional benefits package to full-time employees including medical, dental, vision insurances, life and disability insurances, 401(k) with generous employer matching, and an incentive compensation plan that offers a year-end bonus opportunity up to 30% of base salary.
Still interested? Submit your resume and a cover letter to careers@flow3d.com. Paper copies may be submitted via mail (Attention: Human Resources, 683 Harkle Road, Santa Fe, NM 87505) or fax (505-982-5551). Not quite what you’re looking for? Check out our other openings on our Careers Page >
In this technical webinar, metal casting engineer Ajit D’Brass will provide a review of the advanced simulation options available to engineers and designers in FLOW-3D CAST’s high pressure die casting workspace. After a brief introduction to FLOW-3D CAST’s simulation platform, Ajit will explain the use of event history probes to trigger cooling channels, control shot sleeves, and will detail venting options. P-Q2 control, spray cooling and thermal stress evolution options will also be reviewed.
Who should attend: Foundry/Casting Engineers, Project Managers, Pattern Makers, Sand Foundry Managers and Owners, CAE/Simulation Engineers, Foundry Educational Society, American Foundry Society Members, CAST Expo registrants, Manufacturing Engineering Students
October 10 at 1:00 pm EST
Ajit D’Brass studied manufacturing engineering with a concentration on metal casting at Texas State University. His current work focuses on how to expedite the design phase of a casting through functional, efficient, user-friendly process simulations. Ajit helps customers use FLOW-3D CAST to create streamlined, sustainable workflows.
Come work in one of the best small cities in the US1 for one of the best companies in New Mexico2! Flow Science is growing tech company with deep roots looking for outstanding engineers with an interest or expertise in the aerospace, automotive, additive manufacturing, and consumer products industries.
CFD engineers work at the intersection of classical physics, numerical methods, and computer science. We spend our days using our expertise in these fields to solve complex real-world engineering problems, to teach others about applied CFD, and to guide our development teams to create new models that grow our capabilities and application areas. This challenging and dynamic role requires the following skills to be successful:
Exceptional CFD engineers usually draw heavily on the following skills and experience:
Flow Science offers an exceptional benefits package to full-time employees including medical, dental, vision insurances, life and disability insurances, 401(k) and profit-sharing plans with generous employer matching, and an incentive compensation plan that offers a year-end bonus opportunity up to 30% of base salary.
Still interested? Submit your resume and a cover letter to careers@flow3d.com. Paper copies may be submitted via mail (Attention: Human Resources, 683 Harkle Road, Santa Fe, NM 87505) or fax (505-982-5551). Not quite what you’re looking for? Check out our other openings on our Careers Page >
1 HuffPost listed Santa Fe, NM as one of the top 5 small cities in the US
2 Flow Science has been named one of the Best Places to Work in New Mexico by Albuquerque Business First.
The FLOW-3D European Users Conference 2019 will be held June 3-5 at the Sheraton Diana Majestic in Milan, Italy. Join engineers, researchers and scientists from some of Europe’s most renowned companies and institutions to hone your simulation skills, explore new modeling approaches and learn about the latest software developments. This year’s conference features metal casting and water & environmental application tracks, advanced training for workflow automation with a focus on optimization, in-depth technical presentations by FLOW-3D users, and the latest product developments presented by Flow Science’s senior technical staff. The conference will be co-hosted by XC Engineering, the official distributor of FLOW-3D products in Italy and France.
We are pleased to announce that the conference proceedings for the FLOW-3D European Users Conference 2019 are now available for download. As always, our users have outdone themselves with the originality and quality of their presentations.
Engineers need to be able to deliver project analyses faster and more efficiently than ever before. This is why FLOW-3D and FLOW-3D CAST have built-in options for workflow automation, a modular text-driven structure that allows for easy scripting, and batch postprocessing. In this advanced training, we will review the features that can help you save time and money through automation and optimization.
The Workflow Automation advanced training will take place the afternoon of June 3, from 14:00 – 18:00 at the Diana Majestic Sheraton. You can sign up for the training when you register for the conference.
Past conference presentations are available through our website.
We invite you to see the sights of Milan! All conference attendees are invited to a complimentary city tour on Tuesday, June 4. The tour will take place after the conference on June 4 from 17:30 – 19:15. Immediately following the tour, we will convene for the conference dinner at Toscanino. Please sign up for the tour when you register for the conference. Thank you to our tour sponsor, Protesa SACMI.
The conference will commence with an Opening Reception on Monday, June 3 at 19:00. We invite all conference attendees and their guests for a welcome aperitif and appetizers. The reception will take place in the Gazebo in the conference hotel’s garden.
We are excited to announce that this year’s conference dinner will be held at ToscaNino. Attendees will experience an excellent representation of the cuisine of Tuscany. The dinner will be held the evening of Tuesday, June 4. All conference attendees are invited to the conference dinner as part of their registration.
Each presenter will have a 30 minute speaking slot, including Q & A. All presentations will be distributed to the conference attendees and on our website after the conference. A full paper is not required for this conference. Please contact us if you have any questions about presenting at the conference. XC Engineering will sponsor this year’s Best Presentation Award.
The conference will be held at the Sheraton Diana Majestic. The Sheraton Diana Majestic is a historical hotel located in the heartbeat of Milan that works as the perfect base for shopping, business or discovering the city’s rich history. The hotel is located at Viale Piave 42, 20129. If you wish to book accommodations at the hotel, please contact the Sheraton Diana Majestic directly through their website or call +39 02 20581.
There are many hotels near the Sheraton Diana Majestic. We’ve researched some of these possibilities and ranked our choices below, along with their distance from the conference hotel.
#1: Hotel Teco
Via Lazzaro Spallanzani 27, 20129 Milan (0.7 km)
TripAdvisor Review
#2: Hotel Sanpi Milano
Via Lazzaro Palazzi 18 | Corso Buenos-Aires/Area Porta Venezia, 20124 Milan (0.65 km)
TripAdvisor Review
#3: WORLDHOTEL Cristoforo Colombo
Corso Buenos Aires 3, 20124 Milan (0.35 km)
TripAdvisor Review
#4: Best Western Plus Hotel Galles
Piazza Lima 2, 20124 Milan (1.0 km)
TripAdvisor Review
#5: Hotel Manin
Via Daniele Manin 7, 20121 Milan (1.2 km)
TripAdvisor Review
#6: Hotel Cavour
Via Fatebenefratelli 21, 20121 Milan (1.2 km)
TripAdvisor Review
Milan is the second most populous city in Italy, after Rome and is Italy’s first industrial city, with a multifaceted identity that offers attractions in the field of art, commerce, design, education, fashion, finance, and tourism. The city is brimming with iconic art and architecture from Roman times to the Renaissance and beyond to the contemporary era. Famous symbols of the city include the Duomo, an Italian Gothic cathedral that took 600 years to complete and now stands as the largest church in Italy, and Sforza Castle, home to several Dukes and Duchesses of Milan, as well as artists including Leonardo da Vinci and Michelangelo. Today the city is recognized as the world’s fashion and design capital, thanks to several international events and fairs including Milan Fashion Week and the Milan Furniture Fair, which are among the world’s largest in terms of revenue, visitors and growth.
If you are coming from the airport to the conference hotel, you can take the Milan Underground. The stop for the hotel is P.ta Venezia.
2019 marks the 500th anniversary of Leonardo da Vinci’s death. A series of events are planned around the world and of course in Italy, and Florence and Milan in particular, the two cities where Da Vinci spent most of his time. Milan is preparing for this period with many events: usually-closed rooms containing Leonardo’s fresco of the Sforza Castle will be open to the public, and Leonardo’s Codex and other art pieces, including tapestries and models, will be shown throughout the city.
‘Realizing Da Vinci’s Il Cavallo’ was a collaboration between XC Engineering and Institute and Museum of the History of Science (IMSS). Using Da Vinci’s notes on the casting of Il Cavallo, collected in a 34-page handbook, the IMSS and XC Engineering were able to demonstrate that Il Cavallo, often referred to as “the horse that never was,” can be successfully cast as designed. Read the full case study >
Do you have questions about the conference? Please call or email Amanda Ruggles at +1 505-982-0088 or amanda@flow3d.com.
Receiving a high quality CFD education is crucial in the world of civil, mechanical, computational and bio-chemical engineering. Accurate, versatile CFD software that offers state-of-the-art visualization and high-performance computing capabilities can enhance the learning experience of students and help them become CFD experts. This is why Flow Science offers Research and Teaching Assistance programs that provide free CFD software to students and teachers.
Many academic researchers face the same problem: a lack of affordable, accessible, high-quality CFD software. Commercial software can be out of the budget of an academic program. And while open-source software tools are free, they require command-line expertise and a lot of troubleshooting, which takes time away from learning CFD.
At Flow Science we know that the quality of CFD education is an invaluable part of students’ success during their academic career and beyond. Our academic assistance program is designed to support the educational goals of participants and improve the quality of their research.
Flow Science offers two academic assistance programs in the US and Canada: the Research Assistance program and the Teaching Assistance program.
This program was created for individual researchers (students or teachers) at universities. A Research Assistance license is limited to a 4-month period, with the possibility of extensions. Researchers can request FLOW-3D, our multi-application CFD product or FLOW-3D CAST, our dedicated metal casting product. We also include our state-of-the-art post-processing and visualization tool FlowSight with all our CFD software.
Many universities are currently using or have used our Research Assistance program. Researchers at the Western Michigan University are using FLOW-3D CAST to estimate the erosion on various sand-casting systems for manufacturing automotive parts. The process involves complex turbulent flows and solidification. At the University of Ottawa, researchers are using FLOW-3D to estimate scour caused by tsunami-induced coastal inundation around structures. FLOW-3D is being used at the University of Cincinnati to determine the extent of lateral dispersion in the Ohio River. And researchers at the University of Pretoria used FLOW-3D to simulate the inkjet printability of inks through a piezo-electric nozzle.
FLOW-3D has also been used in cutting-edge research. At the University of California, San Diego, researchers used the software to model ways to mitigate congenital heart defects.
This program is designed for teachers who want to integrate CFD simulation software into their courses. An instructor can request FLOW-3D or FLOW-3D CAST software. FlowSight will be included. The Teaching Assistance license is annual and renewable. We provide enough seats per class/department so that each student can fully explore the software.
Some of our FLOW-3D Teaching Assistance participants include California State University, Texas A&M University, the University of Michigan, National Technical University of Athens and the University of Wisconsin-Madison.
The application is quick and easy to fill out. Research Assistance applicants will find an optional section to upload a research proposal. A good proposal should contain the summary of your research and a description of how you want to use the software. If your research proposal is accepted, we promptly provide you with a license without any limitations. If your proposal is not accepted or your application does not include a research proposal, your license will have cell count and core count limitations. All licenses include access to online video tutorials and instructions to get you started.
The Teaching Assistance application is similar to the Research Assistance application. Applicants are also asked to provide course IDs, details about the number of students in the class, and the percentage of FLOW-3D component in the final student grade.
While we do not offer technical support as part of the academic assistance programs, we have developed a series of tutorials to help you familiarize yourself with the software interface, suggested workflows, and best practices.
Yes, you can apply for both programs!
Please contact me at adwaith@flow3d.com for any questions regarding these academic programs.
Brian Philofsky, product marketing engineer (power & thermal) of Xilinx, details how the company uses Simcenter Flotherm to determine optimal thermal solution for microchip design. The interface helps them to model, understand, iterate and realize more optimal thermal solutions to address the global demands placed on thermal design.
Leverage the power of CAD-embedded CFD simulation to drastically improve engineering productivity.
This video describes how to create a new scenario for analysis from a point identified on a response surface.
This video describes how to connect Simcenter Flotherm XT to HEEDS MDO via the external optimiser section of the parametric study.
This video describes how to extend the number of scenarios used for a Design of Experiments study.
Earning your Tecplot 360 Certification helps build engineering skills and shows your knowledge of this popular visualization and analysis tool. Listing your certification on your resume, CV and LinkedIn profile can help future employers match your skills to their job requirements.
To earn your certification, use a Tecplot 360 free trial, or upgrade your licensed software to the latest version. We recommend using the newest version of Tecplot 360.
The training materials include:
Click the button below for all instructions and materials you need to get certified.
Tecplot 360 Basics Certification
The training covers Tecplot 360 Basics:
Once you complete the test and upload your plot, we will review your work and send you your Certificate! Note that certification is given at the sole discretion of Tecplot, Inc. and is based on evaluation of your submitted answers and plot.
Are you already Tecplot 360 Certified and looking to learn more advanced topics? Here are more ways to learn Tecplot 360.
A complete set of documentation is included with your Tecplot 360 installation, and links can also be found on our website Documentation. Four tutorials that get progressively more advanced are in our Getting Started Manual. The tutorials include:
Datasets used in these examples are included with your installation of Tecplot 360, or they can be found in our Getting Started Bundle.
Over the past few years, we have built up an extensive Video Library – 82 videos to date! Topics range from loading data to working with transient data, and everything in between. The videos are sorted by most current first, but there is a long list of categories to help you find the topic most interesting to you. Many of the videos have been transcribed if you prefer reading the tutorial as you work.
Speaking of learners who prefer reading to watching videos, the Tecplot Blog contains a number of tutorials. The blog tutorials are in the “Tecplot Tip” category.
We offer one hour of free online training when you purchase a Tecplot 360 license, or when you download a Tecplot 360 Free Trial. The training can be tailored to meet your specific workflows, or we can walk you through the standard training modules – answering your specific questions along the way.
Last but not least, companies have found it very helpful to get all their engineers and scientists up-to-speed quickly on Tecplot 360. We can address your specific business challenges and cover designated topics. You provide the facilities and computers, we provide the expert instructor and in-depth materials. To find out more, please email at support@tecplot.com or use the Contact Form.
For Tecplotters in Europe and Western Asia, our Tecplot Europe office holds Tecplot User Days for beginning through advanced users. These training sessions are free of charge! The schedule and registration forms are up on our Tecplot Europe Training page.
The post Learning Tecplot 360 Just Got Easier! appeared first on Tecplot.
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.
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.
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.
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.
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
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.
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.
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 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.
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:
Using Tecplot 360 has allowed Jonathan to create professional plots that enhance the impact of their modeling work.
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.
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…
Driving to Spokane
Snow whirlwinds on pavement
Must make conference!
Stay up-to-date by subscribing to the TecIO Newsletter, events and product updates.
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.
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
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.
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:
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:
| 10M Cells | 47.5M Cells | 118M Cells | |
| Time for CFD Step | 17.6 sec | 70 sec | 88 sec |
| Time Restart write | 6.1 sec | 10.7 sec | 31.4 sec |
| Time SZL File Write | 43.9 sec | 171 sec | 216 sec |
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.
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.
Scott Imlay
Chief Technical Officer
Tecplot, Inc.
The post Parallel SZL Output from SU2 appeared first on Tecplot.
TecIO-MPI was first released in 2016. Since then, we’ve received feedback from some customers that its parallel performance for outputting unstructured-grid solution data needed improvement. So we embarked on an effort to understand and eliminate bottlenecks in TecIO-MPI’s execution.
Customer reports 15x speed-up in writing data from FUN3D when using the new TecIO-MPI library!
Learn more and download the TecIO Library
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 system1. 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
Using iForge hardware and Arm Forge software, we were able to identify two sources of performance problems in TecIO-MPI:
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!
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:
1This 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.
Engineers using Tecplot 360 often need to create a new variable which is based on a numeric relationship of existing variables already loaded into Tecplot.
This powerful capability for calculating a new variable uses a simple method. To start, load your data into Tecplot 360. In this example, we loaded the VortexShedding.plt data located in the Tecplot 360 examples folder.
Choose Alter -> Specify Equations from the Data menu.
Alternately, click the equations icon 
You will see the Specify Equations dialog shown at right.
We will now calculate the difference between two variables. In the Zones to Alter list, click All.
Initialize the new variable T(K)Difference, by typing in the Equation(s) window:
{T(K)Difference} = 0
Click Compute
Now find the difference for variable T(K) between zone 2 and 3 (for example, T(K) in zone 3 – T(K) in zone 2) to T(K)Difference). You can do this for any two variables that have a similar structure.
Select the zones you want to receive the difference value. Type the following equation using the exact variable name from the Data Set Information dialog.
{T(K)Difference} = {T(K)}[3]-{T(K)}[2]
Click Compute
The new variable T(K)Difference is now available for plotting. Open the Data Set Information dialog from the Data menu and view the new variable T(K)Difference.
Note that changes made to the dataset in the Specify Equations dialog are not made to the original data file. You can save the changes by saving a layout file or writing the new data to a file. Saving a layout file will keep your data file in its original state, but use journaled commands to reapply the equations.
Learn more in Chapters 20 and 21 of the Tecplot 360 User Manual.
This blog was originally published in 2013 and has been updated and expanded.
The post Calculating a New Variable appeared first on Tecplot.
Technically, ANSYS will acquire Livermore Software Technology Corporation (LSTC), maker of LS-DYNA but, ya know …
And it’s a BIG bucks deal: ANSYS will pay a purchase price $775 million, 60% cash and 40% via the issuance of ANSYS common stock to the current owners of LSTC. And get this: “ANSYS expects that the transaction will add $60 million to $65 million of non-GAAP revenue to its 2020 results and will be neutral to modestly accretive to non-GAAP operating margins and diluted earnings per share.” That’s a more than 10x multiple for a profitable-ish company. (Accounting for subscriptions and perpetuals makes this a bit fuzzy.)
ANSYS is holding its investor day tomorrow and may disclose more there.
A long time ago, ESI owned the vehicle crash market, with expensive, hard-to-use solutions. LSTC essentially stole the US market from them, with a simpler, cheaper solution — and, as ANSYS says, “The automotive industry has widely adopted … LS-DYNA, a highly scalable multiphysics solver, to accurately predict a vehicle’s behavior and the effects on occupants during a collision. To do this, LS-DYNA simulates the behavior of the vehicle structure and all components including tires, seats, seatbelts, airbags, accelerometers, sensors and batteries in a fully coupled mathematical framework. LSTC counts the vast majority of tier one automotive suppliers among its customers.”
Like everyone else, LSTC built out its portfolio and today has a lot more to offer than crash: structures, fluids, electromagnetics, optics, safety and machine learning will, says ANSYS “deliver a powerful solution for autonomous and electric vehicles to global automotive manufacturers and their suppliers”.
LSTC’s founder and CEO, John Hallquist said this about the deal” As an ANSYS partner for nearly 25 years, I am excited to formally join ANSYS and contribute to their place as the leader in engineering simulations. ANSYS is the perfect home for LSTC’s world-class team of scientists, mathematicians and engineers to continue advancing state-of-the-art, scalable and fully coupled, multiphysics computations. The ANSYS Workbench platform provides their customers with access to a uniquely broad portfolio of simulation technologies packaged into a user-friendly interface that is the envy of the industry. I expect that the combination of Workbench and LS-DYNA will expand our user base by at least an order of magnitude. Here at LSTC, nothing makes all of us happier than when our research enables more customers to imagine, design and implement ambitious projects that were previously impossible.”
It sounds as though Dr. Hallquist will, at least initially, be joining ANSYS; no word yet on other LSTC staff or how the companies will deal with areas of product and channel overlap.
The post Quickie: ANSYS to acquire LS-DYNA appeared first on Schnitger Corporation.
If you’re Siemens, apparently it’s plenty. If you tuned into the PLMish news last week, you’ll likely know that Siemens PLM Software is now Siemens Digital Industries Software and that the overarching umbrella brand for that software is Xcelerator. Why, you rightly ask, do this? After all, the Siemens PLM brand has market credibility, we all know (or can argue to the death about) what PLM is, and don’t believe we want or need a new super-brand in the mix. So, what’s up?
Siemens AG has been buying up software assets, to the tune of $11 billion since the UGS acquisition a decade ago and ending, most recently, with Mendix, Lightworks, Saab Medav, a South African distributor, Stech. Along the way, there were Mentor, CD-adapco and a whole lot more — none, it should be noted, were what one could call pure-play PLM. So the PLM thing was being diluted almost right from the start.
Then, add in the fact that Siemens has always had a software business –that’s what drives all of those production line controllers and monitors the trains and turbines that other parts of Siemens make– that it merged into the PLM business unit a couple of years ago and the PLM name became even more insufficient.
Now, most recently, we add the Mendix software coding environment — a totally agnostic, cross-industry offering. Mendix doesn’t care if you’re a PLMer, an insurance firm or a bakery; you can use Mendix to develop apps to run your business and communicate with customers and employees.
“PLM” no longer represents what the “PLM business” was up to. A name change was warranted, parent company Siemens AG did a reorg and, presto, the Siemens Digital Industries business unit was created. Within that, Siemens Digital Industries Software encompasses the brands we all know.
So, why the Xcelerator superbrand? That’s a more difficult question to answer and one that Siemens really hasn’t yet made clear.
Last week at the analyst and press event that unveiled both the new name and the Xcelerator tag. VP Marketing Brenda Discher and CEO Tony Hemmelgarn both stood in front of a ginormous screen with the Xcelerator logo and the tagline “Where today meets tomorrow”. (The cover image is of the slide, courtesy of Siemens.) Honestly, what does that even mean? Both execs buried that lead in their initial presentations and no one who followed really addressed it until Ms. Discher closed the main part of the event — when she said that the Xcelerators are meant to accelerate (get it?) customers’ time to value from their technology investments.
I’m still not sure what it means and could certainly be wrong, but here’s my take: Xcelerator is all of Siemens’ design, engineering and manufacturing offerings across all of its industries, plus the Mendix app development platform plus MindSphere, Siemens’ cloud-based IoT operating system.
This part isn’t new and it’s what Siemens PLM has been working on for the last year. What I think is new, and maybe the reason for the Xcelerator platformish concept, is that Siemens wants to blur/merge/smooth the edges between engineering/design and operations, and it intends to do that by releasing apps that combine its traditional technologies and MindSphere, using the Mendix coding platform as the base.
Siemens Digital Industries Software (goodness, what a mouthful) focused on three attributes during the analyst event which I think are intended to be core values of Xcelerator:
Tie this all together, and we get a platform that can build a job-specific app that presents a version of a digital twin of an operating machine, say, that can capture user input about some aspect of operations, merge that with IoT-captured performance data and eventually feed those insights back into design and manufacturing, when that product needs to be refreshed.
We’ll have to wait to see what the rebranded SDIS (no? Siemens DIS?) does with Xcelerator but we can’t argue how massive this company is. Mr. Hemmelgarn said that his part of Digital Industries includes 22,000 people, with revenue over $4 billion (nope, no details), organic PLMish revenue growth in the double digits (highest rate among his competitors, Mr. Hemmelgarn notes), and that 65% of the business is from recurring revenue sources. He claims that Siemens’ software business (of which DIS is a large part) makes one of the top ten software companies in the world — substantial, backed by a company that generated €83 billion in revenue in its last fiscal year, and clearly relying on its former PLM business to propel it into the digital age.
There’s lots more to cover from the event: the first release of the Bentley+Teamcenter partnership, called CALM; rebranding of the Manufacturing Operations Management (MOM) solution as Siemens Opcenter and adding in Mentor’s Valor; some really cool stuff in Simcenter; and lots of new case studies for Mendix and MindSphere. I’ll get to that as I can but here’s my
Bottom line, for now: Siemens Digital Industries Software is big and acts bigger because it has its parent’s total support. It continues to integrate all of its engineering and design acquisitions with one another, while also leveraging those assets via MindSphere and Mendix into new areas. The end-goal really is a digital factory, where the production line is designed, optimized and operated using Siemens technology. The gizmo that comes off the production line will have been designed using Siemens tech, is run via apps that tie together the digital twin from design and the as-operated twin from MindSphere, presented in a user-friendly way via Mendix. And, yes, all of that is made possible by NX, Teamcenter, Simcenter, Mentor, and all of the brands that got us to this point. Now for factory, sub in oil rig or office building or train, and you get a sense of how big this vision really is.
Note: Siemens graciously covered some of the expenses associated with my participation in the event but did not in any way influence the content of this post.
The post What’s in a name? appeared first on Schnitger Corporation.
Now this is interesting: RIB, the German maker of the iTWO/MTWO* BIM-focused solution set for the construction industry, just announced that it has acquired a 60% share of U.S. CAD, an Autodesk reseller based in California and with offices across the Western US. According to RIB’s press release, U.S. CAD reported “over 50% revenue growth [so far in 2019] compared to 2018”, with “over 50.000 active subscribers across United States … [RIB expects that] the company will contribute over 30 Million Euro yearly revenue with 20-30% EBIT/DA margin to the RIB Group in 2020”.
U.S. CAD is an Autodesk Authorized Platinum Reseller Partner (the top tier) that helps customers with selection, implementation, training, etc. — most, at the moment, on the design end of the BIM spectrum. Autodesk has recently gotten into the construction side of things with the Plangrid and BuildingConnected acquisitions.
RIB has been saying that it wants to get serious about the North American market, and this deal clearly further those ambitions. RIB expects to leverage U.S. CAD by having it sell the MTWO cloud solutions for contractors and owners starting in January 2020, alongside its historic Autodesk sales offers.
U.S. CAD founder and CEO, Daniel Counts, and President, Jeff Rachel, remain at the helm. Mr. Coonts said in prepared remarks that he has “always envisioned U.S. CAD joining up with a strategic investor like RIB and I am excited about our future … The top priorities for U.S. CAD and RIB will be to continue scaling the business in the USA, by way of both strong organic and acquisitional growth, in other words, we will continue to execute the U.S. CAD strategic plan for growth … With Autodesk BIM 360 and MTWO from RIB, U.S. CAD will be scaling these technologies and increasing adoption throughout the USA. These software platforms are complementary to each other and are transforming the building industry in the USA.”
RIB paid $26.4 million for a 60% share of U.S. CAD.
** Yes, it’s confusing. iTWO is RIB’s cloud-based platform for contractors and others involved in building projects. MTWO is the result of a partnership with Microsoft to bring iTWO onto the Microsoft Azure platform.
The post Quickie: RIB invests in US Autodesk reseller appeared first on Schnitger Corporation.
I’ve been getting a lot of questions about AI –what is it, how do I use it, what data do I need to gather to feed the machine, what does it even MEAN?? (very angsty, usually in an “am I already behind” panic)– and thought I’d try to answer some of the questions about where we are at this moment. I’m using an AEC example because Autodesk and one of their premier customers graciously gave me some of their time earlier this year, but this technology will eventually be applicable many more use cases. Even if you’re not building schools or roads, read on!
First, a recap: A subsegment of AI, artificial intelligence, are technologies called machine learning, ML. ML is further broken down into two broad categories: Supervised ML, where humans help teach an algorithm and Non-supervised ML, where the algorithm attempts to learn on its own by classifying things via pattern examination. In supervised ML, for example, a human trains an algorithm to recognize a specific type of car (sedan) in an airport parking lot by clicking on all of the sedans in an image. The algorithm then tries it on another parking lot; the human corrects, rinse and repeat. Unsupervised ML is still pretty rare in commercial applications, but one could see the algorithm identifying all vehicles with truck beds, for example, as belonging to one class.
Think of ML this way: It’s like having an assistant who analyzes whatever data you throw at them, never gets tired or takes a sick day, and isn’t irritated when you ignore their suggestions.
The first real example of an off-the-shelf AI solution that I know of in our world is Autodesk’s Project IQ, now commercialized as Construction IQ.
It arose out of the recognition that Autodesk customers were entering reams of data from a construction site into Autodesk BIM 360 as part of their routine tasks. Hmmm … perhaps we can use that data for other purposes that add value to the project. Wandering around the site and see a safety rules violation? Snap a photo with your BIM 360 field app to bring it to the attention of the site manager, who may call out the individual after repeated violations. See it happening again? or with other individuals from the same supplier? Now we’re into analytics territory: Is this a training issue? Are the rules unclear? How does this affect the site’s insurance or legal exposure? Keeping track of all of the incidents and drawing conclusions is exactly what ML is meant to do. There are dozens of potential use cases on a typical construction job, from subcontractor management to construction site environment monitoring, safety, and planning, to name just a few. The construction industry also uses standardized reporting and stylized terminology, making it easy for pattern-recognition algorithms to wade through data.
Autodesk, along with a number of key construction company customers, chose to focus its first AI efforts on water infiltration aka leaks. Lots of potential causes (improper cladding installation, poor workmanship, shoddy materials) and huge potential impact when owners experience leaks, therefore an important and rewarding challenge to tackle. Workers on the job site were already entering data about potential problems into Autodesk’s BIM 360 cloud apps, so it became a matter of analyzing that data to predict whether an issue would/could cause damage if not resolved.
Remember that the AI can’t actually DO anything to fix the problem; it identifies a trend that a human needs to know about, decide if actionable and then the human does whatever is appropriate.
How does it work? By using the descriptions that construction quality managers already observe and note as they monitor their projects. For example, someone notices that the flashing outside a window is improperly installed and records it in BIM 360, as is usually the practice to spawn a work order to get it fixed. That happens as per normal, but overnight (weekly, etc.) the AI algorithms run through all of the reports and flag any potential water intrusion issues.
The point: AI, in this case Autodesk Construction IQ, repurposes data already entered and used to draw new conclusions and alert humans to potential problems.
Autodesk Construction IQ is very specific right now, focused on quality and safety risks on a single job site as well as giving program managers an overview of risk potential across projects. It’s all based on data analytics that show up on heat maps (as per usual, red is bad) that identify specific items of risk. Is the same subcontractor always messing up the window cladding? What projects are they on? And so on. Project leaders are likely to use Construction IQ daily to check which subcontractors are flagged as high risk and to drill down to understand why the algorithm flagged these risk factors. Many may be flags that arose out of perfectly ordinary circumstances (late materials arrival meant a contractor was late in doing a task — flagged on the facts but not actionable because not their fault), while others need the human to take action. People with cross-project responsibility can track bigger trends, such as a contractor who has 1 safety violation on each project — not flagged in the specific project, but worrisome across them all.
So how does this work in real life? I talked with Michael Murphy, Digital Construction Operations Manager, BAM Ireland about why BAM decided to try Construction IQ, how the use it, and what he sees as reasonable next steps. Mr. Murphy works in the Irish subsidiary of Dutch Royal BAM Group, which prides itself on the quality of its builds, safety, sustainability and, of course, completing projects on time and on budget.
“We aim for right first time,” he told me, which is crucial in meeting the schedule and financial targets of each project, but also contributes to the company’s reputation — helping to secure future work. Part of achieving that goal is a transition from traditional workflows to a “build it (digital) before we build it (physical)’ mindset, which makes it possible to anticipate problems and brainstorm solutions before anything goes critical. BAM has figured out that, at each stage of a project, an error costs 10x what it did in the prior step — so a $20 mistake identified in design would cost $200 to fix in construction, or $2,000 at the end of construction — all the way to $200,000 once the building is in use.
Once on the job site, Construction IQ enables project managers to be proactive in identifying problems, and heading them off before they become crises. Construction IQ, says Mr. Murphy, enables his teams to focus on the issues that matter: “it highlights what’s truly important according to its algorithm, rather than what most recently walked into the supervisor’s trailer”.
BAM may be a bit ahead of the curve in terms of technology adoption, but this is true of all enterprises, everywhere: “We generate so much data in our projects”, Mr. Murphy says, “Construction IQ gives BAM the ability to interrogate this data, gain insights and leverage our field work and design data”.
Honestly, what I liked most about my time speaking with Mr. Murphy and his team was their description of how it works: “It’s just on. We’d gather the data anyway through our normal work procedures. Construction IQ presents the issues dashboard when we log in. It’s seamless — yes, there is AI in the background, but we don’t see it. We do see complex information, presented in a way that’s easy to understand — graphically, with colors and heat maps.”
I asked about how BAM’s field workers are taking to this, thinking that AI is far from most people’s comfort zone. It may be, but that doesn’t seem to matter. Mr. Murphy said that they’ve rolled out tablet apps to many foremen, who see benefits after just a bit of training. In exchange for logging issues digitally, they get access to change orders and other information, instantly. Employees and contractors, who are now being evaluated by Construction IQ and find themselves in red on a heat map, he says, are being motivated to do better.
Bottom line? Construction projects create vast amounts of data anyway –they have to– so why not use it to greater benefit? Finding and resolving issues is a supervisor’s job; if they can get a head start on identifying which issues matter, that’s only a positive.
We see the beautiful building or cutting-edge health care facility. Contractors like BAM see risk: cost, schedule, and safety can be affected by even the most minor incident. ML enables BAM to identify potential problems, be proactive rather than reactive and rely on data rather than intuition.
Outside of AEC? It’s coming — we just need to standardize on terminology and use cases. But learn from the BAM example: what data do you already have, that you could repurpose with ML, to gain new insights?
Many thanks to Mr. Murphy and the team at BAM Ireland for speaking with me, and to Autodesk’s AEC PR team for connecting us. The title image is from Autodesk, of a Construction IQ heat map showing safety issues by contractor name. (I believe it’s all made up, so don’t ascribe these values to a real entity with the same name.)
The post AI hits the commercial mainstream appeared first on Schnitger Corporation.
Altair has had a rough time since announcing their Q2 results earlier this month, with the stock down 10% since the news hit the wires. Why? Investors were seemed OK with the Q2 report but were underwhelmed by the company’s guidance for Q3 and the year as a whole. More after the details:
Altair CEO Jim Scapa told investors that he saw a deterioration in his end-markets during the quarter (a bad thing) and a faster than expected switch by Datawatch customers to subscriptions (arguably a good thing). How much faster? Datawatch software revenue in Q2 was 91% recurring, up from 61% at the end of 2018. Together, these trends led the company to lower their FY 2019 total revenue guidance by $10 million. But that’s still very strong: Total revenue growth of 16% to 17% and software revenue growth of 20% to 22%.
For Q3, Altair expects software product of about $80 million, up around 24% and total revenue of $104 million up 20% from 2018.
CFO Howard Morof added more on what is happening in Altair’s end-industries, especially automotive: “trade disputes with China and others are resulting in a stronger dollar, affecting our manufacturing customers … [as a result] we expect a slight [negative] impact on software growth for the rest of the year, especially since a healthy percentage of our business is international”. [That’s a paraphrase –Ed.]
Q2 was actually quite good, economic uncertainty and license transitions notwithstanding. Altair clearly feels that Q3 and the rest of 2019 will continue to feel these effects even as the core simulation business continues to drive revenue growth.
—
Update: some of you received this via email with the title chopped off — sorry to hit your inbox with a subject line of just “Altair”. Not sure how that happened; we’ll try to figure it out!
The post Altair’s Q2 solid, Q3? Hmmm appeared first on Schnitger Corporation.
One giant deal, several large deals and new accounting rules helped ANSYS report a Q2 that knocked most metrics out of the park**. Details are below, but the main takeaway, for me, of ANSYS’ Q2 is this: being a one-stop shop matters. Having the ability to support a global account that buys $49 million worth of one type of physics solver in one deal, matters. Just think about that: for the sake of argument, a one-year license for a solver is $49,000. Totally making that up for this equation. $49 million buys 1,000 concurrent licenses or 50 licenses for 20 years or …. you get it. That giant deal was a massive endorsement of ANSYS’ current ability and its future potential.
Details:
When talking about lease versus perpetuals, ANSYS said that it is “experiencing a shifting preference from perpetual licenses to time-based licenses across a broader spectrum of its customers”.
ANSYS tweaked its guidance for the rest of the year, to revenue between $1460 million and $1500 million — that would be growth of 12% to 15% as reported and 14% to 17% cc. ACV, annualized contract value, which was up 14% in Q2, is expected to rise 10% to 13% cc. All of that includes an expected $5 million to $10 million less from China, that’s expected to be made up elsewhere.
Why tell you about ACV, when I usually try to stay away from non-GAAP metrics? Because the accounting rules ANSYS now follows (as does nearly everyone else) add volatility to quarterly results. Large subscription and lease deals, under ASC 606, are recognized with a big chunk of revenue up front, just as if they were perpetual. That means a smoothing, as with ACV, gives a steadier measurement that smoothes out the bumps by mega deals (like the $49 million in Q2) and by unusually large quarters, like Q4. ANSYS defines ACV as “the annualized value of maintenance and lease contracts … plus the value of perpetual license contracts … plus the annualized value of fixed-term services contracts … plus the value of work performed … on fixed-deliverable services contracts” during the period.
So, bottom line? As I said above, scale matters. It enables ANSYS to sell to huge clients that expect massive support in exchange for massive payments. Of course, big deals are hard to predict and close and it would be a mistake for ANSYS (or any of us) to rely on them to run the business. Its scale also enables ANSYS to snare partners like PTC and SAP as it works to move simulation to new user types. And with industrial companies like BMW, which is working with ANSYS to “create a holistic simulation tool chain for developing autonomous vehicle technologies”. I’m not sure I know what that means, but Mr. Gopal told investors that the end-result will be a “development framework around rigorous safety planning, efficient test space exploration and data analytics in a virtual driving environment” that ANSYS will be able to commercialize for the automotive and aerospace and defense markets.
It’s good to be ANSYS right now.
***”Hitting it out of the park” is a baseball term. It means hitting a home run, which advances all runners on base to home plate. It’s fun and thrilling. No quarterly earnings report is ever truly thrilling, but this came close.
The post ANSYS hit Q2 out of the park appeared first on Schnitger Corporation.
.jpg){kind=link}