The speed at which a dune migrates depends on its size; smaller dunes move faster than larger ones. That speed differential implies that small dunes should frequently collide into and merge with larger dunes, eventually forming one giant dune rather than a field of smaller separate ones. But that’s not what we observe in nature.

To figure out why dunes aren’t colliding that often, researchers built a dune field of their own in the form of a rotating water tank. Inside the tank, their two artificial dunes can chase one another indefinitely while the researchers observe their interactions. What they found is that the dunes “communicate” with one another through the flow.

As flow moves over the upstream dune, it generates turbulence in its wake, which the downstream dune then encounters. All that extra turbulence affects how sediment is picked up and transported for the downstream dune, ultimately changing its migration speed. For two dunes of initially equal size and close spacing, these interactions push the downstream dune further away until the separation between the dunes is large enough that they both migrate at the same speed. Even between dunes of unequal sizes, the researchers found that these repulsive interactions force the dunes away from collision and into migration at the same speed. (Image credit: dune field – G. Montani, others – K. Bacik et al.; research credit: K. Bacik et al.; via Cosmos; submitted by Kam-Yung Soh)

Joe Hanson over at “It’s Okay to Be Smart” has a great video on the random walk photons have to make to escape the core of the sun and other stars. Because the high-energy photons born in the star’s core have to bounce their way out rather than flying in a straight line, those photons can spend thousands of years escaping the sun. After that, the eight-and-a-half minute trip to Earth is nothing.

But there’s a key element missing in this explanation: convection! That radiative random walk photons do doesn’t last all the way from the core of the sun to its surface. From a depth of about 200,000 km onward, the dominant mode of transport in the sun is convection, actual fluid motion that carries heat and light much faster than simple molecular diffusion, or Brownian motion, does. That’s why the surface of the sun shines with convection cells similar to the ones you’ll see in your skillet when heating a layer of oil.

Fluid motion beyond molecular diffusion is also a big part of the other flows Joe describes in the video. If you had to wait on Brownian motion in order to smell your morning coffee, it would be cold long before you knew it was there! (Video and image credit: It’s Okay to Be Smart; sun surface image credit: Big Bear Solar Observatory/NJIT)

Moving the surface a droplet sits on creates some interesting dynamics, especially if the surface is hydrophobic. That’s what we see here with these droplets launched off an impulsively-moved plate.

On the left, the drop has some limited contact with the plate and it takes time for the droplet to completely detach. When accelerated, the droplet first flattens into a pancake, the rim of which quickly leaves the plate. The center of the droplet is slower to detach, stretching the drop into a vase-like shape. When the drop does finally lose contact, it creates a fast-moving jet that shoots upward at several meters per second!

In contrast the image on the left shows a levitating Leidenfrost droplet. Since this drop has no physical contact with the plate, the kick makes it leave the surface all at once, launching a pancake-like drop that quickly forms unstable lobes. (Image and research credit: M. Coux et al.)

Sound is an important aspect of many flows, from the scream of a rocket engine to the hum of electrical wires vibrating in the wind. Critically, those sounds carry important information about the flow. A new study extends these acoustic diagnostics to the popping of soap bubbles.

When a hole opens in a soap bubble, it throws the surface-tension-driven capillary forces of the bubble into disarray. The rim around the hole retracts, pushing fluid away from the expanding hole. At the same time, air is pushed out of the collapsing bubble. Using microphone arrays, the researchers found they could measure and distinguish sound from both sources — the escaping air and the expanding hole.

From the sound, they developed a model that predicts the rupture location, bubble thickness profile, and other properties of the bubble. They confirmed the model’s results by comparing with high-speed photography. The authors hope their new acoustic technique will shed light on bubble bursting events that are hard to observe visually, like the bubbling of magma. (Image and research credit: A. Bussonnière et al.; via Science News; submitted by Kam-Yung Soh)

Growing up, my summer nights often featured a chorus of crickets and bull frogs. Even now, the sound of those chirps reminds me of home. So how do crickets make their calls? As this video shows, it’s a matter of scraping the hard edge of one wing along a tiny series of spines, similar to the teeth of a comb, that sit on the other wing.

How fast the cricket’s wings move affects how frequently the chirps are heard. Being cold-blooded, the insects’ speed is affected by the external temperature, which is why you can count cricket chirps to estimate the temperature. Essentially, the chemical reactions necessary to regulate wing movement are temperature-dependent, so colder crickets produce slower chirps. (Video and image credit: Deep Look)

Photographer Eric Gross captured these surreal alpine landscapes in Colorado’s Rocky Mountains. Although the lake’s surface appears to have frozen waves, the prevailing theory is that these mounds and divots occur when snowdrifts form atop the lake, melt and refreeze. Over multiple melting and freezing cycles, the lake builds up with what appear to be wind-driven waves frozen in time. (Image credit: E. Gross; via Colossal)

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

read more

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

read more

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

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

read more

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

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

read more

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

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

read more

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

2 Hour Marathon Attempt

read more

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 interpolation method is polyLine (straight lines between interpolation points). An alternative interpolation method could be spline.

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 http://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.

So how do we create these images in paraview?

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:

Horizontal Knife Edge

Vertical Knife Edge

Now how about ShadowGraph?

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:

Shadowgraph Image

So what do the values mean?

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:

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):

import numpy as np
import matplotlib.pyplot as plt
from scipy.optimize import curve_fit

Now 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!

Summary

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.

Summary

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 http://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!

Download

You can download the script here:

https://github.com/curiosityFluids/curiosityFluidsAirfoilMesher

Here you will also find a template based on the airfoil2D OpenFOAM tutorial.

Instructions

(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

Inputs

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.

Examples

12% Joukowski Airfoil

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:

Clark-y Airfoil

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:

MH60 – Flying Wing Airfoil

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

Summary

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 http://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.

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

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

(a) hpMusic 3rd Order, 9.6M DOFs

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

Figure 1. Comparison of Q-criterion and Schlieren  

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

Happy 2018!     

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

A Tank outside my taxi

A beautiful night in Zurich

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

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

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

Computational Schlieren and iso-surfaces of Q-criterion

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

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

Illini EV Concept Team Photo at Shell Eco Marathon 2018

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

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

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

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

Where to Start When Reducing the Weight of Electric Cars?

Front bump composite failure under a load of 2000N.

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

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

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

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

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

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

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

Iterate and Optimize the Design of Electronic Cars with Simulation

Front bump deformation under a load of 2000N.

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

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

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

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

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

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

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

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

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

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

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

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

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

Post-Processing Using Spatial Decomposition

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

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

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

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

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

Post-Processing Using Temporal Decomposition

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

A turbulence simulation created using EnSight Enterprise post-processing

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

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

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

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

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

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

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

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

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

High-Fidelity Simulation Through Physics-Aware Meshing

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

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

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

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

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

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

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

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

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

Gain Rapid Results in Important Areas You Might Miss

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

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

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

Field flow and streamlines for an electromagnetics simulation

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

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

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

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

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

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

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

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

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

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

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

How to Treat Pancreatic Cancer with a Little Electrochemistry

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

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

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

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

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

A diagram of ACT’s chemotherapy medical device.

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

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

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

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

Simulation Optimized the Fluid Dynamics in the Pancreatic Cancer Chemotherapy Implant

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How 5G Networks Will Send More Signals on Existing Bandwidths

A 28 GHz antenna for a cellular base station.

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

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

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

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

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

How to Design HBF Antennas for 5G Cellular Base Stations

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

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

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

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

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

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

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

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

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

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

At the upcoming CONVERGE User Conference, which will be held online from March 31–April 1, Andrea Piano will present results from experimental and numerical studies of the effects of ducted fuel injection on fuel spray characteristics. Dr. Piano is a Research Assistant in the e3 group, coordinated by Prof. Federico Millo at Politecnico di Torino, and these are the first results to be reported from their ongoing collaboration with Prof. Lucio Postrioti at Università degli Studi di Perugia, Andrea Bianco at Powertech Engineering, and Francesco Pesce and Alberto Vassallo at General Motors Global Propulsion Systems. This work is a great example of how CONVERGE can be used in tandem with experimental methods to advance research at the cutting edge of engine technology. Keep reading for a preview of the results that Dr. Piano will discuss in greater detail in his online presentation.

The idea behind ducted fuel injection (DFI), originally conceived by Charles Mueller at Sandia National Laboratories, is to suppress soot formation in diesel engines by allowing the fuel to mix more thoroughly with air before it ignites¹. Soot forms when a fuel doesn’t burn completely, which happens when the fuel-to-air ratio is too high. In DFI, a small tube, or duct, is placed near the nozzle of the fuel injector and directed along the axis of the fuel stream toward the autoignition zone. The fuel spray that travels through this duct is better mixed than it would be in a ductless configuration. Experiments at Sandia have shown that DFI can reduce soot formation by as much as 95%, demonstrating the enormous potential of this technology for curtailing harmful emissions from diesel engines.

While the Sandia researchers have focused on heavy-duty diesel applications, Dr. Piano and his collaborators are targeting smaller engines, such as those found in passenger cars and light-duty trucks. To understand how the fuel spray evolves in the presence of a duct, they first performed imaging and phase Doppler anemometry analyses of non-reacting sprays in a constant-volume test vessel. Figure 1 shows a sample of the experimental results. The video on the left corresponds to a free spray configuration with no duct, while the video on the right corresponds to a ducted configuration. Observe how the dark liquid breaks up and evaporates more quickly in the ducted configuration—this is the enhanced mixing that occurs in DFI.

Their next step was to develop a CFD model of the fuel spray that could be calibrated against the experimental results. Dr. Piano and his colleagues reproduced the geometry of the experimental setup in a CONVERGE environment, using physical models available in CONVERGE to simulate the processes of spray breakup, evaporation, and boiling, as well as the interactions between the spray and the duct. With fixed embedding and Adaptive Mesh Refinement, they were able to increase the grid resolution in the vicinity of the spray and the duct without a significant increase in computational cost. They simulated the spray penetration for both the free spray and the ducted configuration over a range of operating conditions and validated those results against the experimental data.

With a calibrated spray model in hand, the researchers were then able to run predictive simulations of DFI for reacting fuel sprays. They combined their spray model with the SAGE detailed chemical kinetics solver for combustion modeling, along with the Particulate Mimic model of soot formation. They ran simulations at different rail pressures and vessel temperatures to see how DFI would affect the amount of soot mass produced under engine-like operating conditions. Figures 2 and 3 show examples of the simulation results for a rail pressure of 1200 bar and a vessel temperature of 1000 K. Consistent with the findings of Mueller et al.¹, these results show a dramatic reduction in the mass of soot produced during combustion in the ducted configuration as compared to the free spray configuration.

While these early results are promising, Dr. Piano and his collaborators are just getting started. They will continue using CONVERGE to investigate phenomena such as the duct thermal behavior and to explore the effects of different geometries and operating conditions, with the long-term goal of incorporating DFI into the design of a real engine. If you are interested in learning more about this work, be sure to sign up for the CONVERGE User Conference today!

References

[1] Mueller, C.J., Nilsen, C.W., Ruth, D.J., Gehmlich, R.K., Pickett, L.M., and Skeen, S.A., “Ducted fuel injection: A new approach for lowering soot emissions from direct-injection engines,” Applied Energy, 204, 206-220, 2017. DOI: 10.1016/j.apenergy.2017.07.001

As computing technology continues to advance rapidly, running simulations on hundreds and even thousands of cores is becoming standard practice in the CFD industry. Likewise, CFD software is continually evolving to keep pace with the advances in hardware. For example, CONVERGE 3.0, the latest major release of our software, is specifically designed to scale well in parallel on modern high-performance computing (HPC) systems. It’s clear that HPC is the future of CFD, so how does this shift affect those of us running simulations and how can we make the most of the increased availability of computational resources? At the 2019 CONVERGE User Conference–North America, we assembled a panel of engineers from industry and government to share their expertise.

In the panel discussion, which you can listen to above, you’ll learn about the computing resources available on the cloud and at the U.S. national laboratories and how to take advantage of them. The panelists discuss the types of novel, one-of-a-kind studies that HPC enables and how to handle post-processing data from massive cases run across many cores. Additionally, you’ll get a look at where post-processing is headed in the future to manage the ever-increasing amounts of data generated form large-scale simulations. Listen to the full panel discussion above!

Panelists

Alan Klug, Vice President of Customer Development, Tecplot

Sibendu Som, Manager of the Computational Multi-Physics Section, Argonne National Laboratory

Joris Poort, CEO and Founder, Rescale

Kelly Senecal, Co-Founder and Owner, Convergent Science

Moderator

Tiffany Cook, Partner & Public Relations Manager, Convergent Science

2019 proved to be an exciting and eventful year for Convergent Science. We released the highly anticipated major rewrite of our software, CONVERGE 3.0. Our United States, European, and Indian offices all saw significant increases in employee count. We have also continued to forge ahead in new application areas, strengthening our presence in the pump, compressor, biomedical, aerospace, and aftertreatment markets, and breaking into the oil and gas industry. Of course, we remain dedicated to simulating internal combustion engines and developing new tools and resources for the automotive community. In particular, we are expanding our repertoire to encompass batteries and electric motors in addition to conventional engines. Our team at Convergent Science continues to be enthusiastic about advancing simulation capabilities and providing unmatched customer support to empower our users to tackle hard CFD problems.

CONVERGE 3.0

As I mentioned above, this year we released a major new version of our software, CONVERGE 3.0. We have frequently discussed 3.0 in the past few months, including in my recent blog post, so I’ll keep this brief. We set out to make our code more flexible, enable massive parallel scaling, and expand CONVERGE’s capabilities. The results have been remarkable. CONVERGE 3.0 scales with near-ideal efficiencies on thousands of cores, and the addition of inlaid meshes, new physical models, and enhanced chemistry capabilities have opened the door to new applications. Our team invested a lot of effort into making 3.0 a reality, and we’re very proud of what we’ve accomplished. Of course, now that CONVERGE 3.0 has been released, we can all start eagerly anticipating our next major release, CONVERGE 3.1.

Computational Chemistry Consortium

2019 was a big year for the Computational Chemistry Consortium (C3). In July, the first annual face-to-face meeting took place at the Convergent Science World Headquarters in Madison, Wisconsin. Members of industry and researchers from the National University of Ireland Galway, Lawrence Livermore National Laboratory, RWTH Aachen University, and Politecnico di Milano came together to discuss the work done during the first year of the consortium and establish future research paths. The consortium is working on the C3 mechanism, a gasoline and diesel surrogate mechanism that includes NOx and PAH chemistry to model emissions. The first version of the mechanism was released this fall for use by C3 members, and the mechanism will be refined over the coming years. Our goal is to create the most accurate and consistent reaction mechanism for automotive fuels. Stay tuned for future updates!

Third Annual European User Conference

Barcelona played host to this year’s European CONVERGE User Conference. CONVERGE users from across Europe gathered to share their recent work in CFD on topics including turbulent jet ignition, machine learning for design optimization, urea thermolysis, ammonia combustion in SI engines, and gas turbines. The conference also featured some exciting networking events—we spent an evening at the beautiful and historic Poble Espanyol and organized a kart race that pitted attendees against each other in a friendly competition. 

Inaugural CONVERGE User Conference–India

This year we hosted our first-ever CONVERGE User Conference–India in Bangalore and Pune. The conference consisted of two events, each covering different application areas. The event in Bangalore focused on applications such as gas turbines, fluid-structure interaction, and rotating machinery. In Pune, the emphasis was on IC engines and aftertreatment modeling. We saw presentations from both companies and universities, including General Electric, Cummins, Caterpillar, and the Indian Institutes of Technology Bombay, Kanpur, and Madras. We had a great turnout for the conference, with more than 200 attendees across the two events.

CONVERGE in the Big Easy

The sixth annual CONVERGE User Conference–North America took place in New Orleans, Louisiana. Attendees came from industry, academic institutions, and national laboratories in the U.S. and around the globe. The technical presentations covered a wide variety of topics, including flame spray pyrolysis, rotating detonation engines, machine learning, pre-chamber ignition, blood pumps, and aerodynamic characterization of unmanned aerial systems. This year, we hosted a panel of CFD and HPC experts to discuss scaling CFD across thousands of processors; how to take advantage of clusters, supercomputers, and the cloud to run large-scale simulations; and how to post-process large datasets. For networking events, we took a dinner cruise down the Mississippi River and encouraged our guests to explore the vibrant city of New Orleans.

KAUST Workshop

In 2019, we hosted the First CONVERGE Training Workshop and User Meeting at the King Abdullah University of Science and Technology (KAUST) in Saudi Arabia. Attendees came from KAUST and other Saudi Arabian universities and companies for two days of keynote presentations, hands-on CONVERGE tutorials, and networking opportunities. The workshop focused on leveraging CONVERGE for a variety of engineering applications, and running CONVERGE on local workstations, clusters, and Shaheen II, a world-class supercomputer located at KAUST. 

Best Use of HPC in Automotive

We and our colleagues at Argonne National Laboratory and Aramco Research Center – Detroit received this year’s 2019 HPCwire Editors’ Choice Award in the category of Best Use of HPC in Automotive. We were incredibly honored to receive this award for our work using HPC and AI to quickly optimize the design of a clean, highly efficient gasoline compression ignition engine. Using CONVERGE, we tested thousands of engine design variations in parallel to improve fuel efficiency and reduce emissions. We ran the simulations in days, rather than months, on an IBM Blue Gene/Q supercomputer located at Argonne National Laboratory and employed machine learning to further reduce design time. After running the simulations, the best-performing engine design was built in the real world. The engine demonstrated a reduction in CO2 of up to 5%. Our work shows that pairing HPC and AI to rapidly optimize engine design has the potential to significantly advance clean technology for heavy-duty transportation.

Convergent Science Around the Globe

2019 was a great year for CONVERGE and Convergent Science around the world. In the United States, we gained nearly 20 employees. We added a new Convergent Science office in Houston, Texas, to serve the oil and gas industry. In addition, we have continued to increase our market share in other areas, including automotive, gas turbine, and pumps and compressors.

In Europe, we had a record year for new license sales, up 70% from 2018. A number of new employees joined our European team, including new engineers, sales personnel, and office administrators. We attended and exhibited at tradeshows on a breadth of topics all over Europe, and we expanded our industry and university clientele. 

Our Indian office celebrated its second anniversary in 2019. The employee count nearly doubled in size from 2018, with the addition of several new software developers and marketing and support engineers. The first Indian CONVERGE User Conference was a huge success–we had to increase the maximum number of registrants to accommodate everyone who wanted to attend. We have also grown our client base in the transportation sector, bringing new customers in the automotive industry on board.

In Asia, our partners at IDAJ continue to do a fantastic job supporting CONVERGE. CONVERGE sales significantly increased in 2019 compared to 2018. And at this year’s IDAJ CAE Solution Conference, speakers from major corporations presented CONVERGE results, including Toyota, Daihatsu, Mazda, and DENSO.

Looking Ahead

While we like to recognize the successes of the past year, we’re always looking toward the future. Computing technology is constantly evolving, and we are eager to keep advancing CONVERGE to make the most of the increased availability of computational resources. With the expanded functionality that CONVERGE 3.0 offers, we’re also looking forward to delving into untapped application areas and breaking into new markets. In the upcoming year, we are excited to form new collaborations and strengthen existing partnerships to promote innovation and keep CONVERGE on the cutting-edge of CFD software.

When Eric, Keith, and I first wrote CONVERGE back in 2001, we wrote it as a serial code. That probably sounds a little crazy, since practically all CFD simulations these days are run in parallel on multiple CPUs, but that’s how it started. We ended up taking our serial code and making it parallel, which is arguably not the best way to create a parallel code. As a side effect of writing the code this way, there were inherent parts of CONVERGE that did not scale well, both in terms of speed and memory. This wasn’t a real issue for our clients who were running engine simulations on relatively small numbers of cores. But as time wore on, our users started simulating many different applications beyond IC engines, and those simulating engines wanted to run finer meshes on more cores. At the same time, computing technology was evolving from systems with relatively few cores per node and relatively high memory per core to modern HPC clusters with more cores and nodes per system and relatively less memory per core. We knew at some point we would have to rewrite CONVERGE to take advantage of the advancements in computing technology.

We first conceived of CONVERGE 3.0 around five years ago. At that point, none of the limitations in the code were significantly affecting our clients, but we would get the occasional request that was simply not feasible in the current software. When we got those requests, we would categorize them as “3.0”—requests we deemed important, but would have to wait until we rewrote the code. After a few years, some of the constraints of the code started to become real limitations for our clients, so our developers got to work in earnest on CONVERGE 3.0. Much of the core framework and infrastructure was redesigned from the ground up in version 3.0, including a new mesh API, surface and grid manipulation tools, input and output file formats, and load balancing algorithms. The resulting code enables our users to run larger, faster, and more accurate simulations for a wider range of applications.

Scalability and Shared Memory

Two of our major goals in rewriting CONVERGE were to improve the scalability of the code and to reduce the memory requirements. Scaling in CONVERGE 2.x versions was limited in large part because of the parallelization method. In the 2.x versions, the simulation domain is partitioned using blocks coarser than the solution grid. This can cause a poor distribution of workload among processors if you have high levels of embedding or Adaptive Mesh Refinement (AMR). In 3.0, the solution grid is now partitioned directly, so you can achieve a good load balance even with very high levels of embedding and AMR. In addition, load balancing is now performed automatically instead of on a fixed schedule, so the case is well balanced throughout more of the run. With these changes, we’ve seen a dramatic improvement in scaling in 3.0, even on thousands of cores. 

To reduce memory requirements, our developers moved to a shared memory strategy and removed redundancies that existed in previous versions of CONVERGE. For example, many data structures, like surface triangulation, that were stored once per core in the 2.x versions are now only stored once per compute node. Similarly, CONVERGE 3.0 no longer stores the entire grid connectivity on every core as was done in previous versions. The memory footprint in 3.0 is thus greatly reduced, and memory requirements also scale well into thousands of cores.

Inlaid Mesh

Apart from the codebase rewrite, another significant change we made was to incorporate inlaid meshes into CONVERGE. For years, users have been asking for the ability to add extrusion layers to boundaries, and it made sense to add this feature now. As many of you are probably aware, autonomous meshing is one of the hallmarks of our software. CONVERGE automatically generates an optimized Cartesian mesh at runtime and dynamically refines the mesh throughout the simulation using AMR. All of this remains the same in CONVERGE 3.0, and you can still use meshes exactly as they were in all previous versions of CONVERGE! However now we’ve added the option to create an inlaid mesh made up of cells of arbitrary shape, size, and orientation. The inlaid mesh can be extruded from a triangulated surface (e.g., a boundary layer) or it can be a shaped mesh away from a surface (e.g., a spray cone). For the remainder of the domain not covered by an inlaid mesh, CONVERGE uses our traditional Cartesian mesh technology. 

Inlaid meshes are always optional, but in some cases they can provide accurate results with fewer cells compared to a traditional Cartesian mesh. In the example of a boundary layer, you can now refine the mesh in only the direction normal to the surface, instead of all three directions. You can also align an inlaid mesh with the direction of the flow, which wasn’t always possible when using a Cartesian mesh. This feature makes CONVERGE better suited for certain applications, like external aerodynamics, than it was previously.

Combustion and Chemistry

In CONVERGE 3.0, our developers have also enhanced and added to our combustion models and chemistry tools. For the SAGE detailed chemistry solver, we optimized the rate calculations, improved the procedure to assemble the sparse Jacobian matrix, and we introduced a new preconditioner. The result is significant speedup in the chemistry solver, especially for large reaction mechanisms (>150 species). If you thought our chemistry solver was fast before (and it was!), you will be amazed at the speed of the new version. In addition, 3.0 features two new combustion models. In most large eddy simulations (LES) of premixed flames, the cells are not fine enough to resolve the laminar flame thickness. The thickened flame model for LES allows you to increase the flame thickness without changing the laminar flamespeed. The second new model, the SAGE three-point PDF model, can be used to account for turbulence-chemistry interaction (more specifically, the commutation error) when modeling turbulent combusting flows with RANS.

On the chemistry tools side, we’ve added a number of new 0D chemical reactors, including variable volume with heat loss, well-stirred, plug flow, and 0D engine. The 1D laminar flamespeed solver has seen significant improvements in scalability and parallelization, and we have new table generation tools in CONVERGE Studio for tabulated kinetics of ignition (TKI), tabulated laminar flamespeed (TLF), and flamelet generated manifold (FGM). 

CONVERGE Studio Updates

To streamline our users’ workflow, we have implemented several updates in CONVERGE Studio, CONVERGE’s graphical user interface (GUI). We partnered with Spatial to allow users to directly import CAD files into CONVERGE Studio 3.0, and triangulate the geometry on the fly in a way that’s optimized for CONVERGE. Additionally, Tecplot for CONVERGE, CONVERGE’s post-processing and visualization software, can now read CONVERGE output files directly, for a smoother workflow from start to finish.

CONVERGE 3.0 was a long time in the making, and we’re very excited about the new capabilities and opportunities this version offers our users. 3.0 is a big step towards CONVERGE being a flexible toolbox for solving any CFD problem.

[1] The National Center for Supercomputing Applications (NCSA) at the University of Illinois at Urbana-Champaign provides supercomputing and advanced digital resources for the nation’s science enterprise. At NCSA, University of Illinois faculty, staff, students, and collaborators from around the globe use advanced digital resources to address research grand challenges for the benefit of science and society. The NCSA Industry Program is the largest Industrial HPC outreach in the world, and it has been advancing one third of the Fortune 50® for more than 30 years by bringing industry, researchers, and students together to solve grand computational problems at rapid speed and scale. The CONVERGE simulations were run on NCSA’s Blue Waters supercomputer, which is one of the fastest supercomputers on a university campus. Blue Waters is supported by the National Science Foundation through awards ACI-0725070 and ACI-1238993.

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.

The Webinar is designed for anyone who wants to learn more about effectively approaching electric motor design with electromagnetic, thermal, system level simulation, and optimization software to reduce prototype costs and design cycle time.

Watch this short video to learn about cut planes in Simcenter Flotherm 2019.2 and how they can now work alongside with surface plots.

Have a question: Email: questions_mechanical@mentor.com

For more information on Simcenter Flotherm 2019.2, take a look at these:
https://blogs.sw.siemens.com/simcenter/introducing-simcenter-flotherm-2019-2/
https://youtu.be/ZXBFe-sr55Q

Learn how to quickly and easily create the three types of annotations now available in Simcenter Flotherm 2019.2. These include plot, scalar field and object annotations.

Have a question: Email: questions_mechanical@mentor.com

For more information on Simcenter Flotherm 2019.2, take a look at these:
https://blogs.sw.siemens.com/simcenter/introducing-simcenter-flotherm-2019-2/
https://youtu.be/ZXBFe-sr55Q

How to assign static surfaces in a rotating region smartpart in Simcenter Flotherm XT. This feature allows you to define static parts within a rotating assembly.

Have a question: Email: questions_mechanical@mentor.com

For more information on new features in Flotherm XT 2019.1, click here

Watch this video about using command center in Simcenter Flotherm 2019.2.

Have a question: Email: questions_mechanical@mentor.com

For more information on Simcenter Flotherm 2019.2, take a look at these:
https://blogs.sw.siemens.com/simcenter/introducing-simcenter-flotherm-2019-2/
https://youtu.be/ZXBFe-sr55Q

Watch this video showcasing the new Floscript features which enable automation in Simcenter Flotherm 2019.2.

Have a question: Email: questions_mechanical@mentor.com

For more information on Simcenter Flotherm 2019.2, take a look at these:
https://blogs.sw.siemens.com/simcenter/introducing-simcenter-flotherm-2019-2/
https://youtu.be/ZXBFe-sr55Q

Extracting data from a surface, through time, using PyTecplot

In this example we want to extract Pressure values through time from the wall of a simulation at specific XYZ locations. After the extractions, we want to plot the results with Time on the X-Axis and Pressure on the Y-Axis for each XYZ location.

To do this we must use the PyTecplot function tecplot.data.probe_on_surface(). Another probe function, tecplot.data.probe_at_position(), is available but is likely to fail since it expects data to exist at the exact XYZ location (rather than near the location). Since a surface is infinitely thin it’s unlikely that the supplied XYZ location will be exactly on the surface, so we use the tecplot.data.probe_on_surface() function to find the surface value closest to the XYZ location.

Download the Data, layout and Scripting Files

Download the ZIP file

Extract Data Instructions:

Figure 1. View of the wing inside the boundary

1. Load data.szplt and switch to the 3D Cartesian plot type.
2. Activate the ‘wall’ zone in the Zone Style dialog.
3. Turn on the Contour zone layer and change the contouring variable to Pressure.
4. Fit the data (Ctrl+F) and rotate the view as seen in Figure 1.
5. Allow Python connections via Scripting>PyTecplot Connections…
6. From a command prompt, ‘cd’ to the directory that contains ‘probe_on_surface_through_time.py’ and run the script using the command:
   > python –O probe_on_surface_through_time.py
7. The script extracts data from the XYZ locations specified in XYZ.txt and will create one zone for each XYZ location. These zones represent the Pressure values on the wall at each of those locations.
8. To plot the new data, create a new frame and switch to XY Line plot type. Create line mappings using the Create Mappings dialog (see Figure 2 below).
9. To show to timing marker in the XY plot, run the show_markergridline.mcr macro.
10. In the 3D plot, activate the three new zones and use the Scatter plot layer to display the XYZ locations in the 3D plot.
11. The final result is shown in Figure 4.

Figure 2. Create Mappings dialog

Figure 3. Pressure over time at each of the three XYZ locations on the wall

Final Result

This Tecpot image shows the line data and the XYZ locations in context of the 3D plot.

Figure 4. Final result showing the line data and the XYZ locations in context of the 3D plot

Also see the related Tecplot 360 Video Tutorial, External Flow – Comparing a CFD Simulation with Experimental Data.

The post How to Extract Data from a Surface, through Time appeared first on Tecplot.

Part 1: A Higher-Order Element Primer

This blog was written by Dr. Scott Imlay, Chief Technical Officer, Tecplot, Inc.

“DON’T PANIC!” Douglas Adams, Hitchhikers Guide to the Galaxy

In the next few blogs I’ll discuss our recent research on the visualization of results from higher-order element computational fluid dynamics (HOE CFD). If you are not one of the practitioners of this specialized form of CFD you may be asking “what?” If so, it’s OK, please just heed the advice of Douglas Adams and “DON’T PANIC!”

Partial Differential Equations

First, a quick primer on partial differential equations. Again, “DON’T PANIC!”

The behavior of a fluid flow is described by a set of partial differential equations which relate how the local state of the flow (density, momentum, energy; or alternatively pressure, temperature, velocity) changes over time and space. The simplest of these equations is the conservation of mass (continuity) equation

where ρ and u are the density and velocity of the fluid at a point in space and time (x and t). This equation is the mathematical version of the statement “mass cannot be created or destroyed”, or “if more mass flows into a region than flows out, the density must increase over time.”

If you’re not familiar with symbols in this equation, DON’T PANIC!

The ∂ symbol represents a partial derivative and is the rate at which the density, ρ, is changing in time. Likewise, is the rate at which momentum (density times velocity) increases with increasing spatial dimension x. Another way to think of the partial derivative is as the slope of the curve:

Figure 1. ∂ρu/∂x is the rate at which momentum (density times velocity) increases with increasing spatial dimension x, which is the slope of the curve.

In the above chart the red line is the variation of ρu with x and the slope (change in ρu over change in x) of the tangent green line is at the point of tangency.

Approximating the Derivative

Of course, we don’t generally know a functional form for ρu in terms of x, so we need to approximate the derivative. This is where the order of accuracy comes into play. In solving these partial differential equations we use a grid, with Δx being the grid spacings between grid points. If our approximation to the derivative, call it , has an error term proportional to Δxⁿ we call it an n-th order accurate scheme. For example, a second order scheme would approximate the derivative with an error proportional to Δx²

where the … represents terms containing higher exponents of ∆x like Δx³, Δx⁴, and so on. As the grid spacing Δx gets smaller the error terms with exponents higher than second order will vanish more quickly than the leading Δx² term, so the approximation is called second order accurate. The majority of CFD codes are second-order accurate.

Higher-order Schemes

Higher-order schemes have a leading error of greater than second order. For example, a third-order scheme will have a leading error term of Δx³. As the order of the scheme gets higher, the approximation error drops more rapidly as the grid spacing Δx gets smaller. A higher-order scheme gives a more accurate solution than a second-order scheme with a given grid spacing. Alternatively, you can say that the grid spacing doesn’t need to be as small to get a desired level of accuracy. It is the ability to use a coarser grid to get the same level of accuracy that makes the higher-order schemes attractive.

Figure 2. It is the ability to use a coarser grid to get the same level of accuracy that makes the higher-order element schemes attractive.

Finite-element Methods

For finite-element methods, the variation of the solution over the element is generally approximated as a polynomial with unknown coefficients. For example, in two-dimensions, the element shape may be triangular with a linear variation of solution over the triangle. The goal of the finite-element method, therefore, is to solve for coefficients of the polynomials for all elements in such a way to give the best approximation to the solution of the partial-differential equations.

Enough about the method, let’s focus on the finite-elements themselves!

Why Use Higher-order Elements?

The degree of the polynomial determines the order of accuracy of the scheme (at least the spatial derivatives). For example, linear elements are second order accurate, quadratic elements are third-order accurate, and cubic elements are fourth-order accurate. In general, if p is the degree of the polynomial approximation then p+1 is the order of accuracy.

Why use higher-order elements? In short, for a large class of problems, HOEs achieve a desired level of accuracy with less computation expense. The following chart (Figure 3) from the AIAA Higher-Order Workshop shows how this is true. The horizontal axis of this chart is “work units” (how much computational resources the code uses) and the vertical axis is the solution accuracy (not order-of-accuracy, but how close the solution is to the correct solution). As you can see, the “_P3_” results for each of the codes tend to perform better than the “_P1_” or “_P2_” results. Here “P3” indicates a cubic polynomial which would yield a fourth-order accurate scheme. Note that in the chart below, down is more accurate.

Figure 3. Higher-order elements achieve a desired level of accuracy with less computation expense. This chart, from the AIAA Higher-Order workshop, shows how this is true. The horizontal axis of this chart is “work units” (how much computational resources the code uses) and the vertical axis is the solution accuracy (not order-of-accuracy, but how close the solution is to the correct solution). Down is more accurate.

Legend for Figure 3.

Unsteady Flows

Unsteady flows with propagating vortices are the class of flows that benefit the most from higher-order methods. This is the type of flow you often get with large-eddy simulations, which are becoming more popular as computers get more powerful. For this reason, the usage of higher-order methods will likely increase in the future. Visual Analysis codes like Tecplot 360 need to be ready.

In the next blog I’ll discuss the challenge of visualizing higher-order finite-element solutions.

Subscribe to Tecplot 360

Get notified when the next blog is posted!

Subscribe to Tecplot 360

The post Visualization of Higher Order Elements appeared first on Tecplot.

This blog on Tecplot Macro Tutorials was written from a webinar entitled Ask the Expert About Tecplot 360 hosted by Scott Fowler, Tecplot 360 Product Manager. We received numerous questions about Tecplot macros and this blog pulls our macro resources together in one place.

What is a Tecplot macro? A Tecplot macro is a set of instructions, called macro commands, that perform actions in Tecplot 360. Macro commands can be used to accomplish virtually any task that can be done via the Tecplot 360 interface, offering an easy way to automate Tecplot 360 processes.

We recommend that you download the macros, datasets and layout files used in the descriptions below. If you do not already have Tecplot 360 running, you can download a Free Trial.

Macro, Data and Layout Files (17MB ZIP)

Using a Macro to Produce Transient Plots

This macro reads and edits different time steps and produces transient plots. This macro first finds out how many time steps are in your dataset, then it loops over those time steps. At each time step the current time step is set and an image is exported. That’s It!

export_over_time.mcr
$!EXTENDEDCOMMAND COMMANDPROCESSORID='extend time mcr' COMMAND='QUERY.NUMTIMESTEPS NUMTIMESTEPS' 
$!LOOP |NUMTIMESTEPS| 
    $!EXTENDEDCOMMAND COMMANDPROCESSORID='extend time mcr' COMMAND='SET.CURTIMESTEP |LOOP|' 
    $!EXPORTSETUP EXPORTFORMAT = PNG
    $!EXPORTSETUP EXPORTFNAME = "FILE_|LOOP|.png"
    $!EXPORT 
$!ENDLOOP

Extend Time Macro Addon

The Extend Time Macro add-on simplifies the macro interface by allowing you to use a simple loop to query the number of solution times in the dataset and advance the time step. This differs from the native Tecplot macro language as it does not require that you know the solution time of your data.

This add-on uses a different algorithm than Tecplot 360 EX for sorting the solution times. Because Tecplot 360 combines time steps that are sufficiently close together, the number of time steps reported by this add-on may differ from the number of time steps reported by Tecplot 360.

You can load this addon by adding the following line to your tecplot.add File. See chapters 31 – 3.5 and 31 – 1.2 in the Tecplot 360 User’s Manual.

$!LoadAddOn "tecutilscript_extendtime.mcr"

Converting Binary Files to ASCII

A question asked during the webinar was “How do I convert TEC files to binary?” The .tec file extension has been adopted by the greater Tecplot community. These files are usually ASCII, but in this case, the TEC file was a binary file. So, the question becomes “How do I convert from binary to ASCII?” Well, that’s easy!

Let’s backtrack for a moment and review the canonical Tecplot file extensions:

• PLT (.plt) – Tecplot binary format.
• DAT (.dat) – Tecplot ASCII format.
• SZL (.szplt) – Tecplot Subzone Load-on-demand binary format. This format allows you to load large volume metric grids with very little RAM.

» Read the “Comparison of Tecplot Data File Formats” blog on Tecplot file types.

We don’t have a standalone utility to convert binary files to ASCII, but you can do it using the macro binary_to_ascii.mcr (also included in the ZIP file mentioned above). In the macro, you simply use the ReadDataSet command and then a WriteDataSet command.

Converting ASCII Files to Binary

Another user wanted to convert ASCII files to binary.

You can use a utility called Preplot. Preplot is included with Tecplot 360 and it’s located in the bin directory in the Tecplot 360 installation. You just pass it an ASCII file (.dat) and tell it the output file name. Preplot will do the conversion for you.

> preplot myasciifile.dat mybinaryfile.plt

» Watch the video tutorial, Preplot and SZL Convert Tools.
» Read the Tecplot 360 User’s Manual.
» Reference the Data Format Guide.

A note about ASCII data, whenever Tecplot 360 loads an ASCII file we actually convert it to binary as it’s being loaded. Because of this, it is in your best interest, if you need to load that file over and over, to do the conversion only once. You will save yourself a lot of time!

Placing Streamlines and Streaklines Using Macros

During the webinar, one user was trying to create an arc of streamlines (which we call streamtraces in Tecplot 360). This is not possible using the onscreen “Rake” tool! The Rake tool only places straight lines of streamlines.

If you want to define an arc of streamlines, the best way to do it would be with PyTecplot (but that will be the topic of a future blog). I explain here how to do it with a Tecplot macro.

Here is the Tecplot macro for placing the streamtrace object associated with the frame. In the code below, I’m adding a streamtrace, defining it as a volume line, setting the direction to “both” (default is forward), and placing it at X= 0.5, Y=0.5, Z=0.5. You can create an arc by having multiple of these add commands at different locations.

$!STREAMTRACE ADD ​
  NUMPTS = 1 ​
  STREAMTYPE = VolumeLine​
  STREAMDIRECTION = Both​
  STARTPOS { X = 0.5 Y = 0.5 Z = 0.5 }​

Loading a Saved Frame Style Without the Position

How do I share data across frames without having to reload the data? In this example, I want to tile frames and then save the style from the upper left plot and load it into the lower right frame. You can do this, but not directly in the Tecplot 360 user interface. We will use a macro to do this (It can also be done with PyTecplot).

Copy Frame Style Steps

1. First, create a new frame (click the Frame icon and draw a new frame). Then change the plot type to 2D Cartesian. (Now I could easily click on the upper left frame and save the frame style (Frame>Save Frame Style). Then, I could click in the new frame and load the frame style, but that will also copy the frame size and position which will overlay the original position. I want to retain the position. So, I don’t want to do it this way.)
2. Drag and drop the copy_frame_style.mcr macro (from the ZIP file above) onto the Tecplot 360 user interface. Two new entries will appear in the Quick Macro Panel: “Copy frame Style” and “Paste frame Style.” Be sure the stylesheet directory in the macro is valid (C:\TEMP\temp_style.sty”).
3. Click on the frame you want to copy, click the Quick Macro “Copy frame Style” and click Play (or simply double-click on the macro name).
4. Select the new frame and double click on the “Paste frame Style” macro.
5. Voila! You now have a new frame with the same style. This is one of the macros I use most often.

Copy Frame Style Video Tutorial

Watch MP4 Video

The magic is in the macro’s last command “INCLUDEFRAMESIZEANDPOSITION=NO,” which loads the frame style but ignores the position.

Making Macros Persistent in Tecplot 360

If you want these macro functions always available, you can put them in the tecplot.mcr file (located in Tecplot 360 installation directory).

If you are sharing the Tecplot 360 installation, for example in a Linux environment, you can put the “.tecplot.mcr” file in your Linux home directory so as not to impact other users on your network.

More information can be found in the Tecplot 360 User’s Manual (search for “tecplot.mcr”).

The post Tecplot Macro Tutorials appeared first on Tecplot.

Ask the Expert about Tecplot 360

In this Webinar, customers ask questions of Tecplot 360 Product Manager, Scott Fowler. Scott will help you develop your own internal expertise as he answers your questions interactively. You’ll learn new and improved techniques, current best practices and implementation considerations.

Topics include:

• Streamlines and Streaklines
• Macros, PyTecplot
• MATLAB
• Frames & Styles

Download the files used in the webinar containing the presentation, data files, macros and Pytecplot scripts.

Download the 17MB ZIP file

The post Ask the Expert about Tecplot 360 – Learn New Techniques! appeared first on Tecplot.

These questions were asked during the Webinar, From Zero to Hero: Tecplot 360 Basics. Tecplot 360 Product Manager, Scott Fowler, provides the answers below. Most of the answers show Webinar timestamps so that you can follow along in the Webinar. Learn more about Tecplot 360.

View full Webinar page

1. How do you save all the steps to a macro?

The steps taken in the Webinar (timestamp 36:55) can be recorded to a macro file. Macros are the legacy scripting language of Tecplot 360, and the language on which many of our file formats are based.

• You can customize the Tecplot 360 user interface using the quick macro panel.
• You can customize defaults using what we call a configuration file, tecplot.cfg.
• You can save your current work by saving to a layout file. If you have created new variables, you will also be asked to save the data file. The saved layout file is in this macro language.

Macro Video Tutorials

Tecplot 360 also has a Python API, called PyTecplot, which is available to customers on TecPLUS maintenance. Learn more about PyTecplot.

2. Why is the cylinder surface not showing velocity magnitude?

The cylinder in the Webinar example (timestamp 38:07) is a no-slip wall. Because it is a boundary condition, there are no velocities on the wall. If I want to see the velocities near the wall, I could change J planes to, for example, J=2.

3. Can we plot stagnation energy?

Yes. That is a variable that can be computed. From the main menu (Webinar timestamp 38:46), select Analyze>Calculate Variables and click Select…, then choose Stagnation Energy. See Section 21-3.2 Identifying State Variables in the Tecplot 360 User’s Manual.

4. How do I export a figure without a borderline?

You can hide the border by editing the active frame. To edit a frame (Webinar timestamp 36:55), right-click on the edge of your frame, then choose Edit Active Frame. Uncheck Show border.

Some graphics cards will have a little drop shadow on the right and bottom of plots. This is graphics card dependent. If you see a drop shadow after turning off borders, please see this article on how to correct it in the Tecplot Knowledge Base.

5. When I save a layout and move the layout to another folder, it won’t load.

When you use the menu command File>Save Layout As, there is a toggle (under the Save as type) that says Use relative paths (Webinar timestamp 36:55).

• Checking the toggle saves the referenced data layout file as a relative path.
• Unchecking the toggle saves the layout file as an absolute path. You should be able to load your data when it is saved as an absolute path.

You can also edit the layout file because they are saved as human readable macro files. (timestamp 39:50). I’ll quickly open a macro file and you can see what the Tecplot macro language looks like.

Here is the layout that I saved earlier. You can see that I have a command to point to linedata.plt. To move this file to a different folder, I need to change the file path to an absolute path. I can update the path in the macro file.

Relative paths are often used by people doing optimization studies when they have a folder hierarchy with, for example, Mach alpha sweep and data within each sub folder. Using a relative path, they can copy a single layout into each subfolder and load that data by relative path.

6. Can you repeat extracting the line plot?

Yes. Use Tools>Probe To Create Time Series Plot, then single click on the plot, and that will update the time series plot (Webinar timestamp 41:20). You can see that as I single click, the line plot updates through time.

For more on extracting, see the Tecplot 360 User’s Manual

7. Is it possible to export a cropped image?

Images cannot be cropped in the traditional sense. However, selecting File>Export from the main menu gives you some options (Webinar timestamp 41:53). You can export three different regions of your plot:

• All frames – Exports all frames in your workspace.
• Current frame – Exports only the current frame.
• Work area – Exports entire “gray” region of your workspace.

To export only a portion of your image, you can do what we call a paper zoom. Zoom in on your plot by holding down the shift key, middle mouse button while moving the mouse up. A work area export will export the zoomed-in plot you see in the work area.

8. How can I get two plots in the same frame?

In XY line plots you can plot up to five X-axes and up to five Y-axes (Webinar timestamp 41:20).

In this case we’ll use multiple Y-axes. In the line plot, go into the Mapping Style dialog from the Plot sidebar, and you will see that there are multiple Y axes. For this example, select RHO and Velocity Magnitude to plot in the same frame, then press CNTL+F to fit the view. You can see that these have two very different scales. In the Mapping Style dialog, set RHO to Y2, and now row is on the Y2 axis.

This will give you two plots in the same frame. Select the adjuster tool to move the label.

9. Can I add LaTeX symbols to the legend?

Watch the Video on LaTeX Fonts

• Select the text tool .
• On your plot, click where you want to position the text, which brings up the Text Details dialog.
• Press the LaTeX button (upper right side of Text Details dialog).
• Add the LaTeX annotation, set the Size in points, and press Accept.
• Click on the legend, which brings up the contour & Multi-Coloring Details dialog.
• Toggle off Show header.
• Click on the Legend Box… and click No Box.
• Close the dialog.
• Click on your LaTeX annotation and move it above the legend.

That will mimic adding LaTeX symbols to the legend.

Watch the Video on LaTeX Fonts

10. What is the Shade used for?

In 3D plots, zone effects (translucency and lighting) cause color variation (shading) throughout the zone(s). Shading can also help you discern the shape of the plot. To add shading to your plot, toggle-on Shade in the Plot sidebar. Use the Shade page of the Zone Style dialog to customize shading.

For information on translucency and lighting zone effects refer to Chapter 13, and for information on shade, refer to section 12-1 in the Tecplot 360 User’s Manual.

11. How do I perform a Fourier Transform?

In XY line plots, navigate to the Data>Fourier Transform… menu option. Follow along in this video for a demonstration: Loading Excel Data and FFT in Tecplot 360.
 

The post 11 Questions About Tecplot 360 Basics appeared first on Tecplot.

Case study contributed by Michael Callaghan, PhD, P.Eng – Senior Applications Engineer, Aquanty

Aquanty is a leading-edge water resources science and technology firm specializing in predictive analytics, simulation and forecasting, research services, and IoT. Aquanty’s solutions and services are deployed globally across a broad range of industrial sectors including; agriculture, oil and gas, mining, watershed management, contaminant remediation, and nuclear storage and disposal. Aquanty’s flagship platform, HydroGeoSphere, is a class leader in fully integrated three-dimensional surface/subsurface modeling.
 

What Is an Integrated Surface-Subsurface Hydrologic Cycle Model?

Figure 1. Hydrological Cycle.

HydroGeoSphere (HGS) is a three-dimensional control-volume finite element simulator which is designed to simulate the entire terrestrial portion of the hydrologic cycle. It uses a globally-implicit approach to simultaneously solve the 2D diffusive-wave equation and the 3D form of Richards’ equation.

The basis for HGS’ integrated computation is multiple 1D, 2D, 3D ‘domains’ that interact with each other, including:

• a 2D overland flow domain,
• a 3D subsurface flow domain that can include separate discrete fractures and dual permeability domains,
• as well as 1D surface flow channels,
• 1D subsurface tile drains,
• and 1D water wells.

Data intensive model output for the hydrologic cycle benefits from the flexibility of Tecplot 360 for visualization, which often requires plotting of multiple domains simultaneously and in 3D.

“We chose Tecplot 360 because of the quality of the plots. We need to present our results to clients, and for that plot quality there is no substitute to Tecplot 360.”

– Michael Callaghan, PhD, P.Eng, Senior Applications Engineer, Aquanty

Visualization of Surface Water – Groundwater Interaction

Flood Inundation Visualization

The above visualization cases are made possible with Tecplot 360. HGS is highly integrated with Tecplot ecosystem using a powerful post-processing tool to directly produce results in Tecplot file formats. Tecplot 360 is an essential tool for everyday 2D data plotting, high quality 3D model visualization, results inspection and evaluation.

Learn more about Aquanty and HydroGeoSphere »

Try Tecplot 360 for Free

The post Multiple Domains, Multiple Scales, One Visualization Tool appeared first on Tecplot.

The post How your tech skills can help in the pandemic appeared first on Schnitger Corporation.

The post AVEVA adds production accounting toolset appeared first on Schnitger Corporation.

The post ESI on the impact of Covid-19: “It’s a 3-month event” appeared first on Schnitger Corporation.

The post Totally OT: Capybaras balance oranges appeared first on Schnitger Corporation.

The post Funny & wise from Mel Brooks’ family as we all try to flatten the curve appeared first on Schnitger Corporation.

The post PLMish ideas on whiling away social isolation appeared first on Schnitger Corporation.