The Dutch have been exceptional water engineers for centuries, a necessity in a country where more than a quarter of its territory lies below sea level. After a devastating flood in the early 1950s, the country embarked on a decades’ long endeavor to build the massive Delta Works that now protect a large portion of the population from oceanic storm surges that would otherwise flood the countryside.

As part of their efforts to instill resiliency both along the coast and upstream, the Netherlands has shifted dykes, created floodplain habitats, and built water storage into new buildings. With communities around the world at greater flood risk than ever as our climate changes, the Netherlands serves as a shining example of what’s possible with proper planning and investment. (Video and image credit: TED-Ed)

In the 19th century, botanist Robert Brown observed pollen granules beneath his microscope jittering randomly. Einstein showed that this motion resulted from the impacts of much-smaller atoms against the particles. For small enough objects, the random walk of Brownian motion dominates their dynamics. A new study explores how flexible objects move at this Brownian scale.

The researchers used trios of colloids — microscopic particles — held together by a lipid fluid layer that allows the three particles to change shape without losing contact. Essentially, each trio forms a tiny hinge. As atoms strike the colloids, they both move and change shape.

Compared to rigid shapes, the researchers found their flexible hinges moved around in space about 3-15% faster. They also found coupling between the shape changes and motion. When the colloids hinge closed, it propels them in the direction the hinge points. Because this resembles the propulsion of scallops, the researchers refer to this as the “Brownian quasi-scallop mode.” (Image and research credit: R. Verweij et al.; via phys.org)

*Spoiler alert: it’s not magic. It’s science!

Just what makes this dropped cork float beneath the surface? Just like a normal cork, it’s buoyancy! But this seemingly straightforward video is hiding a few key elements. Firstly, the cork has been modified; it has a metal sphere inside it so that its effective density is higher than that of water.

Secondly, that liquid is not pure water; notice the hazy swirls near the bottom of the flask when the cork drops in? This is tap water that’s had a layer of salt dissolving in the bottom of it for the last day. That creates a density gradient with denser, salty water at the bottom and lighter, fresh water at the top. In fluid dynamics, we’d say the fluid is stably stratified; “stratified” meaning that there are distinct layers (strata) of different density and “stably” because the heavier ones are at the bottom.

When the cork is dropped in, it settles at the fluid layer that matches its density. Because the surrounding fluid is stably stratified, poking the cork makes it bounce slightly but return to its initial height. Our atmosphere behaves just like this when it’s stably stratified. If you displace a parcel of air, it will oscillate up and down before settling back to equilibrium. In fact, the cork and the air even bounce at the same frequency! (Video and submission credit: F. Croccolo)

Although we talk about fog rolling in, it’s rare for us to have a perspective where we can truly appreciate that flow. But this photograph from Tanmay Sapkal provides just that for the low summer fogs sweeping over Marin, CA. When hot summer temperatures make inland air rise, cold, moist air from the ocean sweeps in to replace it. Once the moisture condenses, it forms thick, low clouds of fog that surge past the Golden Gate Bridge and into San Francisco Bay. (Image credit: T. Sapkal; via NatGeo)

If you’re leaving home for a few days and want to keep your houseplants happy, you may have tried using a watering globe – those glass bulbs with long stems that slowly release water for your plant. And if you have used one, you’ve probably noticed what a pain it can be to fill. Pour water down the neck too quickly and you’ll get splashed by a sheet of water blown back at you.

That splashback happens for the same reason that blowing across the top of a bottle plays an audible note: you’re compressing the air inside the container. When water tries to pour continuously down the watering globe’s neck, it can block the escape path needed by the air already in the globe. The increasing weight of water atop that volume of air compresses it, raising its pressure until it’s eventually high enough that it blows all the water back out the neck and into your face.

The best method to ensure that doesn’t happen is to fill the globe slowly. Try tilting it at an angle and letting only a small stream of water fall into it such that there’s always an escape route for the air. (Image and video credit: E. Challita et al.)

Natural oils provide critical nutrients to filter feeders like zooplankton and barnacles. These creatures capture oil droplets on bristle-like appendages such as cilia and setae. But this droplet-catching turns into a disadvantage during petroleum spills, when capturing and ingesting oil can be lethal. A recent study looks at the fluid dynamics of oil droplet capture for these tiny creatures.

The authors found that filter feeders capture a range of droplets regardless of size and oil viscosity. But not all droplets stay attached long enough to get consumed, and the larger a droplet is, the lower the flow velocity necessary to detach it from the animal. That suggests a method of limiting uptake of spilled petroleum into the marine food chain: use surfactants to break up the oil into droplets large enough that they’ll detach from filter feeders before getting eaten. (Image credit: D. Pelusi; research credit: F. Letendre et al.; submitted by Christopher C.)

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.

In a competitive market, predictive computational fluid dynamics (CFD) can give you an edge when it comes to product design and development. Not only can you predict problem areas in your product before manufacturing, but you can also optimize your design computationally and devote fewer resources to testing physical models. To get accurate predictions in CFD, you need to have high-resolution grid-convergent meshes, detailed physical models, high-order numerics, and robust chemistry—all of which are computationally expensive. Using simulation to expedite product design works only if you can run your simulations in a reasonable amount of time.

The introduction of high-performance computing (HPC) drastically furthered our ability to obtain accurate results in shorter periods of time. By running simulations in parallel on multiple cores, we can now solve cases with millions of cells and complicated physics that otherwise would have taken a prohibitively long time to complete. 

However, simply running cases on more cores doesn’t necessarily lead to a significant speedup. The speedup from HPC is only as good as your code’s parallelization algorithm. Hence, to get a faster turnaround on product development, we need to improve our parallelization algorithm.

Let’s Start With the Basics

Breaking a problem into parts and solving these parts simultaneously on multiple interlinked processors is known as parallelization. An ideally parallelized problem will scale inversely with the number of cores—twice the number of cores, half the runtime.

A common task in HPC is measuring the scalability, also referred to as scaling efficiency, of an application. Scalability is the study of how the simulation runtime is affected by changing the number of cores or processors. The scaling trend can be visualized by plotting the speedup against the number of cores.

How Does CONVERGE Parallelize?

Parallelization in CONVERGE 2.4 and Earlier

In CONVERGE versions 2.4 and earlier, parallelization is performed by partitioning the solution domain into parallel blocks, which are coarser than the base grid. CONVERGE distributes the blocks to the interlinked processors and then performs a load balance. Load balancing redistributes these parallel blocks such that each processor is assigned roughly the same number of cells.

This parallel-block technique works well unless a simulation contains high levels of embedding (regions in which the base grid is refined to a finer mesh) in the calculation domain. These cases lead to poor parallelization because the cells of a single parallel block cannot be split between multiple processors.

Figure 1 shows an example of parallel block load balancing for a test case in CONVERGE 2.4. The colors of the contour represent the cells owned by each processor. As you can see, the highly embedded region at the center is covered by only a few blocks, leading to a disproportionately high number of cells in those blocks. As a result, the cell distribution across processors is skewed. This phenomenon imposes a practical limit on the number of levels of embedding you can have in earlier versions of CONVERGE while still maintaining a reasonable load balance.

Parallelization in CONVERGE 3.0

In CONVERGE 3.0, instead of generating parallel blocks, parallelization is accomplished via cell-based load balancing, i.e., on a cell-by-cell basis. Because each cell can belong to any processor, there is much more flexibility in how the cells are distributed, and we no longer need to worry about our embedding levels.

Figure 2 shows the cell distribution among processors using cell-based load balancing in CONVERGE 3.0 for the same test case shown in Figure 1. You can see that without the restrictions of the parallel blocks, the cells in the highly embedded region are divided between many processors, ensuring an (approximately) equal distribution of cells.

The cell-based load balancing technique demonstrates significant improvements in scaling, even for large numbers of cores. And unlike previous versions, the load balancing itself in CONVERGE 3.0 is performed in parallel, accelerating the simulation start-up.

Case Studies

In order to see how well the cell-based parallelization works, we have performed strong scaling studies for a number of cases. The term strong scaling means that we ran the exact same simulation (i.e., we kept the number of cells, setup parameters, etc. constant) on different core counts.

SI8 PFI Engine Case

Figure 3 shows scaling results for a typical SI8 port fuel injection (PFI) engine case in CONVERGE 3.0. The case was run for one full engine cycle, and the core count varied from 56 to 448. The plot compares the speedup obtained running the case in CONVERGE 3.0 with the ideal speedup. With enough CPU resources, in this case 448 cores, you can simulate one engine cycle with detailed chemistry in under two hours—which is three times faster than CONVERGE 2.4!

Sandia Flame D Case

If the speedup of the SI8 PFI engine simulation impressed you, then just wait until you see the scaling study for the Sandia Flame D case! Figure 4 shows the results of a strong scaling study performed for the Sandia Flame D case, in which we simulated a methane flame jet using 170 million cells. The case was run on the Blue Waters supercomputer at the National Center for Supercomputing Applications (NCSA), and the core counts vary from 500 to 8,000. CONVERGE 3.0 demonstrates impressive near-linear scaling even on thousands of cores.

Conclusion

Although earlier versions of CONVERGE show good runtime improvements with increasing core counts, speedup is limited for cases with significant local embeddings. CONVERGE 3.0 has been specifically developed to run efficiently on modern hardware configurations that have a high number of cores per node.

With CONVERGE 3.0, we have observed an increase in speedup in simulations with as few as approximately 1,500 cells per core. With its improved scaling efficiency, this new version empowers you to obtain simulation results quickly, even for massive cases, so you can reduce the time it takes to bring your product to market. 

Contact us to learn how you can accelerate your simulations with CONVERGE 3.0.

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

From the Argonne National Laboratory + Convergent Science Blog Series

The world is waiting for us to develop the tools needed to design new engine architectures, new concepts, with a finer control over the combustion process. If we can continue to make the progress we’ve achieved over the last ten years, I think society and the environment will continue to reap large rewards.

—Dr. Don Hillebrand, Division Director of the Energy Systems Division, Argonne National Laboratory

The year 2020 marks the ten-year anniversary of a fruitful collaboration between Convergent Science and the U.S. Department of Energy’s Argonne National Laboratory. Over the years, the collaboration has facilitated exciting advances in engine technology, high-performance computing and machine learning, computational methods, physical models, gas turbine and detonation engine simulations, and more. Many engineers at both Argonne and Convergent Science have contributed to these projects, but the collaboration started with one individual.

The Story Origin

Dr. Sibendu Som was introduced to CONVERGE before it was even called CONVERGE. He was a graduate student at the University of Illinois at Chicago (UIC), and in the summer of 2006 Sibendu participated in an industry internship. He worked with engineers on a computational fluid dynamics (CFD) team who were using an internal version of a code in development by a small company named Convergent Science. When Sibendu’s internship ended, he went back to UIC and continued to work with the same CFD code—at the time called MOSES.

For his thesis, Sibendu focused on improving spray models, for which he was obtaining experimental data from Argonne. Spray modeling happens to be a specialty of Dr. Kelly Senecal, Co-Owner of Convergent Science, so Kelly assisted Sibendu in his endeavors.

“Kelly helped me quite a bit,” Sibendu says, “so I actually invited him to be a part of my thesis defense committee.”

After completing his Ph.D.—and thoroughly impressing Kelly and the rest of his committee—Sibendu became a postdoc at Argonne National Laboratory in the research group of Mr. Doug Longman, Manager of Engine Research. At the time, there was only a little CFD work being done at Argonne in the combustion and spray area, so there was an opportunity to bring in a new code. Having used CONVERGE during his thesis, Sibendu was a proponent of using the software at Argonne.

Partnering with a renowned national laboratory was a big opportunity for Convergent Science. In 2010, Convergent Science had only recently switched from being a CFD consulting company to a CFD software company, and working with Argonne lent credibility to their code. Argonne also provided access to computational resources on a scale that a small company simply could not afford on their own.

“It was also a relationship thing,” Kelly says. “The partnership just started off on the right foot, and we were really happy to work with the Argonne research team.”

A Mutually Beneficial Partnership

Government and private industry have a long history of collaboration in the United States—and for good reason. These relationships are not only beneficial for both parties, but also for taxpayers. The mission of national laboratories is not to compete with industry, but to help support and enhance the missions of private companies for the benefit of the country.

“The national lab system in the United States is a national treasure,” says Dr. Don Hillebrand. “Our job is to look at big science, big physics, big chemistry, big engineering, and solve challenging problems that confront us. We make sure that knowledge or tools or technology solutions get transferred to industrial groups, who develop jobs and products and make the country competitive.”

National laboratories provide access to resources, including advanced technology and funding, that private companies are often unable to obtain on their own. For Convergent Science in particular, access to Argonne’s computational resources made it possible to test CONVERGE on large numbers of cores and to work on improving the scalability for clients who want to run highly parallel simulations. Getting access to these types of resources on the ground floor provides a huge advantage to industry partners.

Another important function of national labs is to investigate long-term or risky areas of research. Private companies survive on the profits they make, and investing in research that does not pay off in the end can be damaging to their business. In the same vein, companies tend to focus on products that they can bring to market relatively quickly to make sure they have a consistent revenue stream. However, long-term and riskier research is critical for developing innovative technologies that have the potential to transform our lives.

“The government drives a lot of research in cutting-edge technology,” says Dr. Dan Lee, Co-Owner of Convergent Science. “They also have advanced facilities and teams of expert engineers doing fundamental research for projects that are potentially going to shape the future.”

Of course, to have an impact on society, the technology developed in national laboratories must end up in the hands of consumers. Thus the end-goal of research and development at government institutions is to transfer that technology to industry.

Ann Schlenker, Director of the Center for Transportation Research at Argonne, spent more than 30 years in industry before transitioning to Argonne. That experience gave her a deep understanding of the synergistic relationship between government and private industry.

“You need to be extremely astute at listening to the voice of the customer. And that means understanding what the challenges are, where the hurdles and difficulties are stressing the system and how best to optimize processes. Because if you can do that, you can develop timely solutions,” Ann says.

Partnering with industry helps ensure that the research at the national labs is relevant, timely, and impactful. This is one way in which these relationships benefit the taxpayer—the results of government research directly address the needs of consumers and help make the country competitive on the world stage.

Delivering Results

The collaboration between Argonne and Convergent Science has resulted in significant advances for the modeling community and the transportation industry. While the details of this research will be discussed in depth in upcoming blog posts, the projects from the past decade generally fall into two categories: advancing simulation for propulsion technologies and improving the scalability of CONVERGE on high-performance computing architectures.

Many projects have focused on modeling processes relevant to the internal combustion engine, such as studying fuel injection and sprays using experimental data from Argonne’s Advanced Photon Source, implementing state-of-the-art nozzle flow models in CONVERGE, simulating ignition, and investigating cycle-to-cycle variation.

Other key areas of focus have been modeling challenging phenomena in gas turbine combustors and breaking ground on simulating rotating detonation engines. Enhancing the scalability of CONVERGE has made it possible to run larger, more complex cases and to obtain more accurate, more relevant results from these simulations.

The overarching goal for these projects continues to be to create better models and establish techniques that will be instrumental in developing the transportation technologies of the future. Perhaps Ann sums it up best:

The day of learning is not over for combustion processes. It’s germane to our gross domestic product for U.S. economic vitality. Our transportation and combustion researchers and industry engineers work side-by-side to achieve the societal goals of better fuel economy and lower emissions. And these strong collaborations and this visionary work allow us to move fully forward with model-based system engineering, with high-fidelity, predictive capabilities that we trust.

The collaboration between Convergent Science and Argonne National Laboratory will certainly help propel us into the future. Learn more about the research performed during this collaboration in upcoming blog posts!

Any CONVERGE user knows that our solver includes a lot of physical models. A lot of physical models! How many combinations exist? How many different ways can you set up a simulation? That’s harder to answer than you might think. There might be N turbulence models and M combustion models, but the total set of combinations isn’t N*M.

Why not? In some cases, our developers haven’t completed it yet! The ECFM and ECFM3Z combustion models, for example, could not be combined with a large eddy simulation (LES) turbulence model until CONVERGE version 3.0.11. We’re adding more features all the time. One interesting example is the thickened flame model (TFM). 

The name is descriptive, of course: TFM is designed to thicken the flame. If you’re not a combustion researcher, this notion may not be intuitive. A real flame is thin (in an internal combustion engine environment, tens or hundreds of microns). Why would we want to design a model that intentionally deviates from this reality? As is often the case with physical modeling, the answer lies in what we’re trying to study.

CONVERGE is often used to study the engineering operability of a premixed internal combustion or gas turbine engine. This requires accurate simulation of macroscopic combustion dynamics (flame properties), including the laminar flamespeed. A large eddy simulation (LES) might use cells on the order of 0.1 mm. 

The problem may now be clear. The flame is much too thin to resolve on the grid we want to use. In fact, a detailed chemical kinetics solver like SAGE requires five or more cells across the flame in order to reproduce the correct laminar flamespeed. An under-resolved flame results in an underprediction of laminar flamespeed. Of course, we could simply decrease the cell size by an order of magnitude, but that makes for an impractical engineering calculation.

The thickened flame model is designed to solve this problem. The basic idea of Colin et al. [1] was to simulate a flame that is thicker than the physical one, but which reproduces the same laminar flamespeed. From simple scaling analysis, this can be achieved by increasing the thermal and species diffusivity while reducing the reaction rate by a factor of F. Because the flame thickening effect decreases the wrinkling of the flame front, and thus its surface area, an efficiency factor E is introduced so that the correct turbulent flamespeed is recovered.

The combination of these scaling factors allows CONVERGE to recover the correct flamespeed without actually resolving the flame itself. CONVERGE also calculates a flame sensor function so that these scaling factors are applied only at the flame front. By using TFM with SAGE detailed chemistry, a premixed combustion engineering simulation with LES becomes practical.

Hasti et al. [2] evaluated one such case using CONVERGE with LES, SAGE, and TFM. This work examined the Volvo bluff-body augmentor test rig, shown below, which has been subjected to extensive study. At the conditions of interest, the flame thickness is estimated to be about 1 mm, and so SAGE without TFM should require a grid not coarser than 0.2 mm to accurately simulate combustion.

With TFM, Hasti et al. show that CONVERGE is able to generate a grid-converged result at a minimum grid spacing of 0.3125 mm. We might expect such a calculation to take only about 40% as many core hours as a simulation with a minimum grid spacing of 0.25 mm.

Understanding the topic of study, the underlying physics, and the way those physics are affected by our choice of physical models, are critical to performing accurate simulations. If you want to combine the power of the SAGE detailed chemical kinetics solver with the transient behavior of an LES turbulence model to understand the behavior of a practical engine–and to do so without bankrupting your IT department–TFM is the enabling technology.

Want to learn more about thickened flame modeling in CONVERGE? Check out these TFM case studies from recent CONVERGE User Conferences (1, 2, 3) and keep an eye out for future Premixed Combustion Modeling advanced training sessions.

References
[1] Colin, O., Ducros, F., Veynante, D., and Poinsot, T., “A thickened flame model for large eddy simulations of turbulent premixed combustion,” Physics of Fluids, 12(1843), 2000. DOI: 10.1063/1.870436
[2] Hasti, V.R., Liu, S., Kumar, G., and Gore, J.P., “Comparison of Premixed Flamelet Generated Manifold Model and Thickened Flame Model for Bluff Body Stabilized Turbulent Premixed Flame,” 2018 AIAA Aerospace Sciences Meeting, AIAA 2018-0150, Kissimmee, Florida, January 8-12, 2018. DOI: 10.2514/6.2018-0150
[3] Sjunnesson, A., Henrikson, P., and Lofstrom, C., “CARS measurements and visualizations of reacting flows in a bluff body stabilized flame,” 28th Joint Propulsion Conference and Exhibit, AIAA 92-3650, Nashville, Tennessee, July 6-8, 1992. DOI: 10.2514/6.1992-3650

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.

Come see Mentor Graphics automotive tools in action at Integrated Electrical Solutions Forum. This FREE event also includes industry presentations, case studies, product expo, networking events and technical tracks of industry and technical sessions.

Simcenter™ FLOEFD™ software, a CAD-embedded computational fluid dynamics (CFD) tool is part of the Simcenter portfolio of simulation and test solutions that enables companies optimize designs and deliver innovations faster and with greater confidence. Simcenter FLOEFD helps engineers simulate fluid flow and thermal problems quickly and accurately within their preferred CAD environment including NX, Solid Edge, Creo or CATIA V5. With this release, Simcenter FLOEFD helps users create thermal models of electronics packages easily and quickly. Watch this short video to learn how.

Simcenter™ FLOEFD™ software, a CAD-embedded computational fluid dynamics (CFD) tool is part of the Simcenter portfolio of simulation and test solutions that enables companies optimize designs and deliver innovations faster and with greater confidence. Simcenter FLOEFD helps engineers simulate fluid flow and thermal problems quickly and accurately within their preferred CAD environment including NX, Solid Edge, Creo or CATIA V5. With this release, Simcenter FLOEFD allows users to add a component into a direct current (DC) electro-thermal calculation by the given component’s electrical resistance. The corresponding Joule heat is calculated and applied to the body as a heat source. Watch this short video to learn how.

Simcenter™ FLOEFD™ software, a CAD-embedded computational fluid dynamics (CFD) tool is part of the Simcenter portfolio of simulation and test solutions that enables companies optimize designs and deliver innovations faster and with greater confidence. Simcenter FLOEFD helps engineers simulate fluid flow and thermal problems quickly and accurately within their preferred CAD environment including NX, Solid Edge, Creo or CATIA V5. With this release, the software features a new battery model extraction capability that can be used to extract the Equivalent Circuit Model (ECM) input parameters from experimental data. This enables you to get to the required input parameters faster and easier. Watch this short video to learn how.

Simcenter™ FLOEFD™ software, a CAD-embedded computational fluid dynamics (CFD) tool is part of the Simcenter portfolio of simulation and test solutions that enables companies optimize designs and deliver innovations faster and with greater confidence. Simcenter FLOEFD helps engineers simulate fluid flow and thermal problems quickly and accurately within their preferred CAD environment including NX, Solid Edge, Creo or CATIA V5. With this release, Simcenter FLOEFD allows users to create a compact Reduced Order Model (ROM) that solves at a faster rate, while still maintaining a high level of accuracy. Watch this short video to learn how.

High semiconductor temperatures may lead to component degradation and ultimately failure. Proper semiconductor thermal management is key for design safety, reliability and mission critical applications.

Q&A from Tecplot 360 Basics – Load Custom Data File Formats with Python

Can PyTecplot compute a time average?

Yes! See the Time Average script on our GitHub site, TimeAveragy.py.

Can PyTecplot automatically do data probes over time?

A: Yes again! See the script on our GitHub site, tpprobe.py.

You may also want to try Tools>Probe to create a time series plot right in the Tecplot 360 user interface.

Is there a Python script to unite multiple meshes?

Of course! See the GitHub script, CombineFEZones.py. 

This script loads an example dataset, so you’ll have to modify it to load your data, or simply use data that’s already loaded.

Can we achieve high quality videos with PyTecplot? and can you show how to generate plots using PyTecplot?

Yes. PyTecplot uses the Tecplot 360 engine, so the image and video quality will be the same as if you exported directly from Tecplot 360. See the PyTecplot Export module here in our documentation

When exporting a sequence of images using a script, is there a significant difference between macros and PyTecplot?

No.  PyTecplot and Macros use the same Tecplot 360 engine, so there will be no difference in image quality. There may be slight differences in performance, as each language is an interpreted language and the cost of interpreting is different. 

PyTecplot in ‘batch’ mode runs faster than PyTecplot in ‘connected’ mode.

How can I find the cell that has the maximum and the minimum values?

To do this, use this script in our Tecplot GitHub repository. It finds and places a scatter point at the min or max values. This Knowledge Base article shows you how.

Where do I go for Tecplot Technical Support

To find support in your region, please visit see our Distributor Map, and scroll down for contact information.

The post Tecplot 360 Basics – Python Load Custom File Formats appeared first on Tecplot.

The Tecplot Europe engineering team specializes in custom solutions in the field of numerical simulation, especially CFD. For the past 25 years, they have been building long-term partnerships by understanding customers’ unique problems and delivering easy-to-implement solutions.  

Tecplot Europe (also known as Genias Graphics) provides Tecplot sales and support to the European and Western Asian markets.

On any given day, team members may be working on optimizing the output of a customer’s in-house solver, automating customer workflows with Python scripts, or extending the capability of Tecplot 360 with addons.

Implementing complex technical requirements in a tailor-made way for each and every customer is our most important task.
–Lothar Lippert, Tecplot Europe Manager.

Tecplot Output for Your In-House Solver – Optimizing Performance

Read the DLR Case Study »

Many customers are working on their own in-house codes and solvers. These solvers use different grid sizes, may have unsteady simulations, and use various mesh types – some of which may have meshes that change over time. The Tecplot 360 suite of tools can handle all of that with ease.

The key to optimal performance is a good output file. Tecplot Europe engineers are experts at optimizing a solver’s output to achieve the best possible performance and optimal user experience. Small changes to an output file often result in 10 times better performance, and it may take just a few minutes to change.

Automation with Python and Macros – Optimizing Your Time

Repetitive tasks and generating reports can eat up a lot of time. Automating these routine tasks is a tremendous time savings (as well as a relief from doing mundane tasks). Virtually every day, we help customers automate their workflows with Python and Macros scripts.

Often customers do not know what is possible, and what can be accomplished with macros and Python scripts. We can share and explain sample code and provide ready-to-use scripts and macros, which are also easy for customers to maintain and extend.

Tecplot Europe has several scripts, available on demand. For example, a user wanted to automate the creation of a plot of forces and moments vs span on a wing, together with a visualization of Cp plots along the 3D-view of the geometry. The Python script is available in our Tecplot’s GitHub repository.

Python scripts are available on Tecplot’s GitHub repository »

Tecplot Europe Add-On Development

Tecplot 360 is known as the most complete post-processing desktop solution for CFD visualization. However, some of our customers have very challenging requirements, which can be solved only by developing additional functionality. Tecplot 360 is extendable with add-ons. The additional capability is wide ranging, from developing data loaders for special file formats, connecting to Web Map Services, or connecting to larger database applications like a dedicated tool to compare wind tunnel data with CFD results.

Optimization with High-Quality Tools – A Case Study

In a recent case, Tecplot Europe engineers helped DLR use Tecplot 360 to optimize the tail strake position of a generic transport aircraft. Optimization with high-quality tools found the best position. Visualization with Tecplot 360 was crucial in helping understand the effects of each tail strake position.

Read the Case Study »

Tecplot Europe can Help You Optimize Your Workflows

Contact Tecplot Europe:
Phone: +49 (0)9402 9480–0
Email: info-eu@tecplot.com

Contact us for scripting help »

The post Tecplot Europe Solutions for CFD Visualization appeared first on Tecplot.

Without a visualization component in the design optimization loop, precisely configuring an aircraft’s tail strake position is simply impossible. Tail strakes are “fins” mounted horizontally on the rear fuselage that add stability and controllability. Engineers at the German Aerospace Center (DLR) found that the visualization component was crucial in understanding flow effects of a generic transport aircraft they were designing.

One requirement was the ability to load cargo at the aft end of the aircraft. This feature included a long, upswept ramp you can see in Figure 1. The fuselage upsweep created strong vortices as shown in Figure 2. The vorticies lead to flow detachment which reduced pressure recovery and increased drag. The DLR engineers needed to find a way to keep the flow attached and the drag reduced.

Figure 1. Long upswept ramp feature on generic transport aircraft. Figure 2. Vorticies along the ramp.

Finding an Optimal Tail Strake Position

Figure 3. The problem was finding the optimal tail strake position.

The Goal

Our goal was to weaken the tail vorticies caused by the ramp. To do this, tail strakes needed to be precisely configured to produce effective counter-rotating vortices.

The Challenge

The problem was to find the optimal tail strake position and orientation (Figure 3).

The Method

A design optimization – from CAD to mesher to solver and optimizer – included a visualization tool, Tecplot 360, which helped in understanding and trusting the results.

Figure 4. Design optimization loop: Parametric CAD (CATIA V5), Parametric Mesher (CENTAUR), Solver (TAU+2xAdaptions, Optimizer (SUBPLEX) and Visualization with Tecplot 360.

Figure 5. Three parameters were investigated.

Three parameters were investigated as shown in Figure 5:

• Strake position along u-isocurve of tail surface (generally the fore-aft position)
• Strake position along v-isocurve (radial location on the fuselage)
• Rotation angle φ against tangent in u-direction (angle of the strake against the fuselage)

The Results

The resulting XY plots, produced by Tecplot 360, are shown in Figure 6.

• The optimizer did a good job, showing ideal asymptotic convergence of objective and design variables.
• The optimization resulted in a 4% improvement of lift to drag ratio due to strake location – a very significant improvement.
• A 28% difference between worst (No. 4) and best (No. 44) strake position showed the importance of precisely locating the strake for maximum benefit. See Figure 7.

Figure 6. The results are shown in Tecplot 360 XY plots.

Best and Worst Tail Strake Position

In the worst tail configuration, the strake amplified the tail vortex, leading to a larger area of separation and high drag. In the optimal configuration, the strake truncated the tail vortex and minimized separation. While optimizers are generally good at driving to a desired result, understanding and trusting the underlying physics requires good visualization. Best and worst scenarios are shown in figure 8.

Optimization with high-quality tools found the best position. Visualization with Tecplot 360 was crucial in helping understand the effects.

---

 

Get Help Optimizing Your Workflows

Contact Tecplot Europe:
Phone: +49 (0)9402 9480–0
Email: info-eu@tecplot.com

Learn more about Tecplot Europe Support

Figure 7. Comparison of tail configurations.

Figure 8. Best and worst tail configuration.

The post Tail Strake Position Optimization for Generic Transport Aircraft appeared first on Tecplot.

Vela Software is pleased to announce the acquisition of Compusense which will report into Vela’s subsidiary Tecplot, augmenting an expanding range of statistical tools with the industry-leading platform for Consumer and Sensory Science testing.

September 1, 2020 – Compusense develops Compusense Cloud and Compusense20, powerful SaaS tools used by major food and beverage companies, CPG multinationals and luxury brands to plan, execute, and analyze consumer and sensory tests, leading to insights that help these companies launch and refine successful products. With over 30 years of research and innovation, Compusense sets the standard for sensory research software.

Founders Karen Phipps and Chris Findlay will lead the transition to an all-internal management team comprised of employees with a combined 55 years of experience at the company.

“Karen and I are delighted that we can place the company that we have grown and nurtured for 34 years into the strong hands of Vela,” Findlay said. “Their expertise in growing software companies gives Compusense a solid foundation upon which it can build into the future. We are very pleased that our management team will be able to retain Compusense’s culture and continue to support our amazing clients as we always have.”

Tom Chan, President of Tecplot, thanked Karen and Chris, adding, “they have worked tirelessly to build a great company, and more importantly a great team, who are passionate about helping customers and advancing sensory testing. With the profound disruptions caused by COVID, brands need valued partners more than ever to help them be successful in the marketplace and Compusense is key to ensuring that products hit the right notes with consumers. We look forward to working closely to bring their important technology to more clients across the globe.”

Compusense is based in Guelph, ON, and serves customers world-wide.

If you have any questions about this acquisition, or the capabilities of Compusense’s products, please contact Compusense at info@compusense.com.

About Tecplot, Inc.

An operating company of Vela Software International, Inc., itself an operating group of Toronto-based Constellation Software, Inc. (CSI), Tecplot is the leading independent developer of visualization and analysis software for engineers and scientists. CSI is a public company listed on the Toronto Stock Exchange (TSX:CSU). CSI acquires, manages, and builds software businesses that provide mission-critical solutions in specific vertical markets.

The post Compusense Aquired by Vela Software appeared first on Tecplot.

Q&A from the Equations Training

Can I compute a time average over an interval?

This capability is not directly available in the Tecplot 360 user interface. But we do have a robust Python API for Tecplot 360. Scripts are available on the public GitHub, Tecplot Handyscripts, Python scripts. Scroll to find TimeAverage.py. This script uses another behind the scenes script called tpmath.py, which has a phased-average function available in it. It was written by a Tecplot customer, and we thank them for writing it! Because it is on GitHub, it’s supported by our user community.

Can contours be classified and generated based on categories?

The Tecplot 360 contour legend typically shows only numeric values. But sometimes you may want to show values that are string based. For example, if you have different material properties like sand or soil in a geoscience case, or in the case of a CONVERGE dataset where you have particles that may be in the fluid or have bounced or rebounded. You can show strings using our custom label set. We have blog, Creating a Materials Legend, that uses a bit of Tecplot Kung Fu to add a string-based custom label set. You can use that blog as a guide.

Can I do a while loop in specify equations?

In the Tecplot 360 user interface, the answer is no. But with our Python API, PyTecplot, the answer is yes! In the video example, Jared showed finding the difference between the two zones, with a blended wing body shape. If that were a time-dependent simulation, you could use our looping capability to compute that difference over time. The Tecplot 360 macro language has “for” and “while” loop capabilities. And Python, of course, has many logical and flow control operations. You can use these scripts in conjunction with equations.

Is there a discount for academic licenses for students and faculty? And how do I get one?

We have several academic license options for those at degree-granting universities or institutions. You can email Jared McGarry at campus@tecplot.com, and he can help you decide which type of license you need – single user, department, college, campus, or site licenses (with effectively unlimited seats). You can also visit us at Tecplot Academic Suite.

Can we get a PDF of the presentation to help remember the equations?

We don’t have a PDF of this presentation. But you can watch the recording (above). Also, click on the help button in the specified equations dialog. You’ll see a reference to the functions available.

Can an equation reference data in a different frame?

No – equations can only operate on data in the active frame. If you have to datasets that you want to compare, you’ll need to load both into the same frame.

What is the best way to calculate the difference between different zones that have different meshes?

In the video, the blended wing body example, those two zones have the same mesh and you can simply subtract one zone from the other. If you have different meshes, you will need to interpolate results onto a common mesh with the same number of points. See this video tutorial Comparing Grids: Interpolation of Differing Meshes.

Do you have license roaming, and how does it work?

License roaming is enabled for network licenses. You must be connected to your license server to roam your license. Go to Help>License Roaming.

Is there a quick way in alter equation to find a deviation from a node value?

Sure, let’s look at an example: I want to find the difference of U from its value at X=1, Y=1, Z=1. First use the Probe tool to find the value of U at that XYZ location. From the Probe results you can Copy the U value. Then in the Data Alter dialog you would use this equation:

{U_delta} = {U} – 1.234

Where 1.234 is the value you copied from the Probe dialog. This will create a new variable called “U_delta”.

Can we use alter equation to find max-min of a variable and its location?

The best way to find min-max is with a Python script available on our GitHub site: Tecplot Handyscripts on Github, and look for display_max_variable_value.py.

You supply the zone and the variable through Python. Then the script will, in Tecplot 360, point to the location of the maximum value on your plot and display it in a text box.

There are two options for polyline point extraction. Which one should I use?

There are several options for extracting data along a line in Tecplot 360. Which one to use depends on your use case.

1. Use the menu option Data>Extract>Precise Line. This will allow you to enter two X, Y, Z locations. You can then extract data across a perfectly straight line between those two points.
2. Use the menu option Data>Extract>Polyline Over Time. We also have the extract points from polyline, I think it is. Jared, can you go back to the data extract menu? Yeah, polyline over time.
3. Select a polyline on your plot, right-click, and you can select Extract Points from the context menu.

Is there any plan in the future to duplicate a page like we do for a frame?

We have no immediate plans for this capability. We could create a Tecplot macro or a Python script that would mimic the behavior by looping over each individual frame on a page and copying and pasting it to a new page. If this is something you do frequently, contact support@tecplot.com, and we can create a custom solution for you.

If I extract the line across the wall, do I get wall quantities?

In the internal combustion case from the video [timestamp: 38:46], we have volume data representing the fluid, and boundary data representing the wall. When you extract across the line, Tecplot 360 will extract points from the first zone that it encounters. In this case, it will encounter the wall. If you want to make sure of that, open the Zone Style dialog and ensure the wall zone is the only active zone.

The post Tecplot 360 Basics – Equations appeared first on Tecplot.

Visualization of Higher-Order Elements – Part 3: Isosurface Algorithms

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

In this blog I’ll be discussing our research into isosurface algorithms for higher-order finite-element solutions. The first blog on this topic was A Primer on Visualizing Higher-Order Elements and the second was on the Complex Nature of Higher-Order Finite-Element Data.

Big cells beget little cells
That model their complexity
And little cells have smaller cells
That we choose selectively

In the second blog, I described how the isosurface passing through a linear tetrahedra is a simple plane described entirely by its intersections with the edges. Since the solution varies linearly along the edges you can calculate these intersections very quickly. You can also quickly exclude edges based on the range of the nodal values at either end of the edge. If the isosurface value is greater than the maximum node value, or less than the minimum node value, no further computation is needed. In this way, the vast majority of the edges can be excluded from further computation by a couple of simple floating-point compares. This, among other optimizations, make this technique very fast.

Isosurfaces in a Quadratic, Higher-Order Element

In comparison, an isosurface in a quadratic, or even higher-order, element can be quite complex. The isosurface is not, in general, planar and it doesn’t even have to intersect the edges or surfaces of the element (see Figure 2). You can have isosurfaces that are entirely contained within an element like little islands. How do we extract these isosurfaces?

Figure 1. Isosurface in linear tetrahedron (left). Figure 2. Isosurface in quadratic tetrahedron (right)

Nearly all visualization techniques for higher-order isosurfaces involve subdividing the higher-order element into a large number of linear sub-elements. The variation of the solution across these sub-elements approximates the non-linear solutions and the approximation error decreases as the number of sub-elements increase. Once you have the sub-element, you can use existing isosurface algorithms for linear elements to extract an approximate non-linear isosurface. Sounds easy, right?

Visualization Techniques for Higher-Order Isosurfaces

It is fairly easy to implement an algorithm where all higher-order elements are sub-divided into a large number of linear elements. A quadratic tetrahedra, for example may be divided into eight sub-tetrahedra using the existing ten nodes. This sub-division is shown in Figure 3. Each of those sub-tetrahedra may be further subdivided into eight sub-sub-tetrahedra by creating new nodes at the edge centers, interpolating to those nodes using the full quadratic element basis function, and subdivide as done for the original element. This process can be repeated until the non-linear isosurface is sufficiently resolved.

Unfortunately, the number of sub-cells grows exponentially: after the first sub-division it is eight sub-cells, after the second level of sub-divisions it is 64, after the third level of sub-divisions it is 512, and so on. If you start with 500 thousand higher-order cells you will have 256 million linear sub-cells after three levels of sub-division. It is not cheap to create those 256 million linear sub-cells!

Figure 3. Tetrahedron sub-division.

Most of my research has been on optimizations to make this faster. Specifically, are there simple tests that will allow us to eliminate cells early in the process?

For example, for linear elements, we compute the min/max range of the isosurface variable for all nodes in the element, and we exclude cells where the isosurface value is not in that range. We do this because the cell extrema (min’s and max’s) in linear cells are guaranteed to be at the nodes.

Unfortunately, for most basis functions the extrema in a higher-order cell is not generally at the nodes but may be anywhere within the cell. If we can find a way to quickly exclude higher-order cells, we can significantly reduce the computational cost and memory usage of the subdivision process.

Optimizing the Isosurface Algorithm

It turns out you can eliminate many cells based on the min/max values of the isosurface variable at the nodes. A heuristic formula that seems to work is to keep any cell where the isosurface value satisfies this formula:

2φ_min-φ_max<φ_iso<2φ_max-φ_min

I wish I had a mathematical proof that this formula always works, but it has worked in all the cases I’ve tested so far. This formula basically has a buffer equal to the range of the isosurface variable in the non-linear cell. The same formula, with smaller buffers, is applied to the sub-cells at each level of recursion. That is, the formula is also applied when sub-dividing the sub-cells, and again when subdividing the sub-sub-cells, but the size of the buffer on the isosurface variable range is smaller each time.

Selectively subdividing elements based on the formula above dramatically reduces the cost of extracting higher-order isosurfaces. In Figure 4 you can have four levels of subdivision for an isosurface of constant radius from a point. By the fourth level of subdivision, all but 8,617 out of a possible 663,552 sub-cells have been excluded. Over 98.7% of the sub-cells have been discarded and further computations should be nearly a factor of 100 faster!

Figure 4. Selective subdivision for quadratic tetrahedral isosurface extraction.

Figure 5 shows the extracted isosurface at various levels of subdivision. Four levels of subdivision are sufficient to create a very smooth isosurface.

Figure 5. Quadratic tetrahedral isosurface with increasing levels of subdivision.

In my next blog, I will discuss the results of our research into higher-order finite-element curved surface visualization algorithms. See all blogs on higher order elements.

Subscribe to Tecplot

Get all the latest news from Tecplot, Inc.

Subscribe to Tecplot 360

The post Isosurface Algorithms – Visualizing Higher Order Elements appeared first on Tecplot.

The post BSY rings the Nasdaq bell last week appeared first on Schnitger Corporation.

Bentley shares started trading under the BSY symbol at around 11:15 on Wednesday. Someone told me that the bookmaker, the brokerage firm that handles trading of the shares, had to determine the opening price, which I thought would be the price Bentley set last night, $22. Nope — turns out it was $28, and the price went up from there, as you can see in this screen capture from Marketwatch at 4:04 PM on September 23, 2020:

As you can see, the price wobbled a bit but eventually closed at $33.49, up a whopping 52% on the day — and on a day when technology shares, in general, went up 2.6% while the Nasdaq overall fell 3%. Not a bad day for Bentley, at all.

By the way, I was wrong when I said we didn’t know who wanted to sell shares in this IPO. In the latest version of the S-1, on numbered page 188 is a chart that shows the number of shares owned before and after the sale — by subtraction then, we can figure it out. Many people will be selling — but not Greg, Keith, Barry or Raymond Bentley, who all keep their shares. Not Siemens, which maintains its 14%ish stake. The sellers are longtime and recently retired employees, a charitable giving fund, and clumps of employees in aggregate — in other words, as we expected, it’s a liquidity event for some of the people that made Bentley Systems, Bentley Systems.

What did we learn today? That IPOs are unpredictable, even with all the prep in the world. Some shares go absolutely crazy after they start trading, like Snowflake last week: Shares started the day at $120 and closed at $253.93, more than double their IPO price of $120 — and that was triple what the company initially thought it could get just a week earlier. Other shares go in the opposite direction, as the market makers can’t find buyers for the shares they’ve guaranteed. Basic economics: desirable things that are scarce command higher prices than stuff no one wants, or that there’s too much of. So much is out of the offeror’s control — had there been a dire political, social, or pandemic event, Snowflake and Bentley might have seen very different results.

Oh, and Snowflake also took time to get going. It started trading right around noon on its first day — apparently, it takes that long to match up buyers and orders and begin trading. I thought this was all done by computer nowadays, especially since the NASDAQ doesn’t have a trading floor. It’s charming to think of a guy in an old-fashioned eyeshade, still making all this happen.

← PTC acquires ioxt for cognitive AR BSY rings the Nasdaq bell last week →

The post Bentley’s IPO. Done. Finally. appeared first on Schnitger Corporation.

The post PTC acquires ioxt for cognitive AR appeared first on Schnitger Corporation.

The post Quickie: Bentley IPO now at $22/share appeared first on Schnitger Corporation.

The post Quickie: Bentley raises price in IPO appeared first on Schnitger Corporation.

The post Quickies: Bentley sets IPO price, Altair acquires for HPC appeared first on Schnitger Corporation.