In some parts of the world, fog is a major source of freshwater, but collecting it is a challenge. Most systems use a wire mesh to capture and collect droplets, but the process is highly inefficient, pulling only 1-3% of droplets from the fog. Researchers found that this is due largely to aerodynamic effects. The presence of the wire deflects droplets around it (bottom left). To solve this, engineers introduced an electric charge into the fog. The subsequent electric field actually pulls droplets to the wires (bottom right). When applied to a mesh (top), the efficiency of fog capture improves dramatically. 

The technique can also be used to capture water vapor that would otherwise escape from the cooling towers of power plants. The MIT researchers who developed the technique will conduct a full-scale test at the university’s power plant this fall. They hope the technique will recapture millions of gallons of water that would otherwise drift away from the plant. (Image credits: MIT News, source; image and research credits: M. Damak and K. Varanasi, source)

Noctilucent – literally night-shining – clouds are a phenomenon unique to high latitudes during the summer months. Too dim and sparse to see in daylight, these clouds shine at night because their altitude of around 80 km allows them to catch sunlight long after dusk has fallen at the surface. They form when temperatures in the summer mesosphere drop to nearly -150 degrees Celsius, driven by perturbations that can originate in lower layers of the atmosphere on the opposite side of the Earth. Complex interactions and feedback between atmospheric waves, buoyancy, and Coriolis effect circulate those disturbances in such a way that the summer mesosphere can reach temperatures colder than any other place on Earth. Those frigid temperatures allow clouds to form even in this dry region near the edge of space. (Image credit: S. Stephens; see also: B. Karlsson and T. Shepard)

Sand and other granular materials can be strikingly fluid-like. Here the impact of a solid sphere on sand generates a splash remarkably similar to what’s seen with water. When the ball hits, it creates a crater in the surface and sends up a bowl-like spray of sand. As the ball continues falling through the sand, the grains try to fill the empty space left behind. The walls of sand collapsing around the void meet somewhere between the surface and the depth of the ball. This generates the tall jet we observe, as well as a second one under the surface that we can’t see. We know that collapse traps an air bubble under the surface because of the eruption that occurs as the jet falls. That’s the air bubble reaching the surface. (Image credit: T. Nguyen et al., source; see also R. Mikkelsen et al.)

Day has turned into night for NASA’s Opportunity rover as a massive dust storm envelopes Mars. The first signs of the dust storm were reported May 30th, and over the last two weeks, the storm has grown to an area larger than North America and Russia combined. Despite the low pressure and density of Mars’ atmosphere, solar heating can create fairly strong winds – they don’t reach hurricane-force speeds, but they’d qualify as a very windy day here on Earth. With the lower gravity on Mars, this can lift dust well into the atmosphere, choking out the sunlight Opportunity needs to continue operating. The rover has entered a low-power mode and is no longer responding to communications. Martian dust storms have been known to last for weeks or even months, and this may be the last we hear from the intrepid rover on its fifteen year journey. Here’s hoping that Opportunity makes it through the storm and can eventually get the solar power needed to phone home again. (Image credit: NASA JPL)

Giving droplets a kick by accelerating the surface they sit on creates elaborate shapes as the drops respond. As the surface accelerates upward, the droplet flattens into a pancake. When the plate slows down, the droplet continues rising, stretching into a cone as its rim flies upward and its lower surface adheres to the surface. The rim retracts with a constant acceleration while the drop detaches with a constant velocity. That velocity depends on how well it adheres to the surface. The interplay between those two variables determines how conical or cylindrical the drop appears. See more in the full video below. (Image and video credit: P. Chantelot et al.)

Blocking blood vessels by creating embolisms is, under most circumstances, very bad. But researchers are exploring ways to fight cancer by intentionally and strategically creating these blockages. In gas embolotherapy, researchers inject fluid droplets, which can carry chemotherapy drugs, into the bloodstream. Once they circulate into a cancerous tumor, they use ultrasound to vaporize the droplet and create a gas bubble. Those bubbles lodge inside the capillaries of the tumor, starving it of fresh blood and trapping the chemotherapy drugs inside. It’s a one-two punch to the cancer. Without blood flow, the cancer cells die, and, since the cancer-killing drugs get mostly trapped inside the tumor, patients may require lower dosages and endure fewer side effects. The technique is currently in animal testing, but hopefully it will be a valuable therapy for human patients in the future. (Image credit: Chemical & Engineering News; research credit: Y. Feng et al.; via AIP)

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

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

read more

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

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

read more

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

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

read more

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

2 Hour Marathon Attempt

read more

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

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

read more

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

Active Aerodynamics on the Lamborghini Huracán Performante

read more

Here is an extremely simple simulation to set up that has a surprisingly beautiful output. In this post, we will simulation the classic Rayleigh–Bénard convection (see Wikipedia) in 3D using the buoyant solver, buoyantBoussinesqPimpleFoam.

buoyantBoussinesqPimpleFoam is a solver for buoyant, turbulent, incompressible flows. The incompressible part of the solver comes from the fact that it uses the Boussinesq approximation for buoyancy which is only suitable for flows with small density changes (aka incompressible). A good source for the equations in this solver is this blog post.

Simulation Set-up

The basic set-up for this case is simple: a hot bottom surface, a cold top surface, either cyclic or zero-gradient sides, and some initial conditions.

For this example, I used the properties of water, I set the bottom plate at 373 K (don’t ask me why… I know it’s close to boiling point of water), and the top plate at 273 K. For this case, we will not use any turbulent modeling and will simply use a laminar model (this simply means there is only molecular viscosity, there are no simplifications applied to the equations).

Geometry and Mesh

The geometry is shown below. As the geometry is so simple… I will not go over the blockMesh set up. The mesh discretization that I used was simplegrading (i.e. no inflation), with 200x200x50 cells.

Constant

For this case, we will simulate water. The transportProperties file should look like:

transportModel Newtonian;

// Laminar viscosity
nu [0 2 -1 0 0 0 0] 1e-06;

// Thermal expansion coefficient
beta [0 0 0 -1 0 0 0] 0.000214;

// Reference temperature
TRef [0 0 0 1 0 0 0] 300;

// Laminar Prandtl number
Pr [0 0 0 0 0 0 0] 7.56;

// Turbulent Prandtl number (not used)
Prt [0 0 0 0 0 0 0] 0.7;

I don’t typically delete unused entries from dictionaries. This makes using previous simulations as templates much easier. Therefore note that the turbulent Prandtl number is in the dictionary but it is not used.

Selecting Reference Temperature TRef for buoyantBoussinesqPimpleFoam. To answer this recall that when the Boussinesq buoyancy approximation is used, the solver does not solve for the density. It solves the relative density using the linear function:

Therefore, I think it makes sense that we should choose a temperature for that is somewhere in the range of the simulation. Thus I chose Tref=300. Somewhere in the middle!

And the turbulenceProperties file is:

simulationType laminar;

RAS
{
 RASModel laminar;

turbulence off;

printCoeffs off;
}

The g file tells the solver the acceleration due to gravity, as well as the direction:

dimensions [0 1 -2 0 0 0 0];
value (0 -9.81 0);

Boundary Conditions

In the “zero” folder, we need the following files: p, p_rgh, T, U, and alphat (this file needs to be present… however it is not used given the laminar simulationType.

T:

dimensions [0 0 0 1 0 0 0];

internalField uniform 273;

boundaryField
{
 floor
 {
 type fixedValue;
 value uniform 373;
 }
 ceiling
 {
 type fixedValue;
 value uniform 273;
 }
 fixedWalls
 {
 type zeroGradient;
 }
}

p_rgh:

dimensions [0 2 -2 0 0 0 0];

internalField uniform 0;

boundaryField
{
floor
{
type fixedFluxPressure;
rho rhok;
value uniform 0;
}

ceiling
{
type fixedFluxPressure;
rho rhok;
value uniform 0;
}

fixedWalls
{
type fixedFluxPressure;
rho rhok;
value uniform 0;
}
}

p:

dimensions [0 2 -2 0 0 0 0];

internalField uniform 0;

boundaryField
{
 floor
 {
 type calculated;
 value $internalField;
 }

ceiling
 {
 type calculated;
 value $internalField;
 }

fixedWalls
 {
 type calculated;
 value $internalField;
 }
}

U:

dimensions [0 1 -1 0 0 0 0];

internalField uniform (0 0 0);

boundaryField
{
 floor
 {
 type noSlip;
 }

ceiling
 {
 type noSlip;
 }

fixedWalls
 {
 type noSlip;
 }
}

Simulation Results

The results (as always) are the best part. But especially for this case since they are so nice to look at! I have made a couple animations of temperature fields and contours. Enjoy.

Conclusion

This case demonstrated the simple set up of a case using buoyantBoussinesqPimpleFoam. The case (Rayleigh-Bénard convection) was simulated in 3D on a fine grid.

Comments and questions are welcome! Keep in mind I set this case up very quickly.

This post is a simple demonstration of the timeVaryingFixedUniformValue boundary condition. This boundary condition allows a Dirichlet-type boundary condition to be varied in time. To demonstrate, we will modify the oscillating cylinder case.

Set-Up

Instead of using the oscillating boundary condition for point displacement. We will have the cylinder do two things:

• Move in a circular motion
• Move in a sinusoidal decay motion

The basics of this boundary condition are extremely simple. Keep in mind that although (here) we are modifying the pointDisplacement boundary condition for the cylinder, the basics of this BC would be the same if you were doing a time varying boundary condition for say pressure or velocity.

In the pointDisplacement file:

 cylinder
 {
 type timeVaryingUniformFixedValue;
 fileName "prescribedMotion";
 outOfBounds clamp;
 }

fileName points to the file where the time varying boundary condition is defined. Here we used a file called prescribedMotion however you can name it whatever you want. The outOfBounds variable dictates what the simulation should do if the simulation time progresses outside of the time domain defined in the file.

The additional file containing the desired motion prescribedMotion is formatted in the following way:

(
( 0 (0 0 0))
( 0.005 (-0.0000308418795848531 0.00392682932795517 0))
( 0.01 (-0.0001233599085671 0.00785268976953207 0))
( 0.015 (-0.000277531259507496 0.0117766126774107 0))
( 0.02 (-0.00049331789293211 0.0156976298823283 0))
...
( 9.99 (-0.0001233599085671 -0.00785268976953189 0))
( 9.995 (-0.0000308418795848531 -0.00392682932795479 0))
( 10 (0 -3.06161699786838E-016 0))
)

The first column is the time in seconds, and the vector defines the point displacement. In the present tutorial, these points were calculated in libreOffice and then exported into the text file.  I arbitrarily made up the motions purely for the sake of making this blog post.

The circular motion was defined as:

and 

Decaying sinusoidal motion was:

The rest of the set-up is identical to the set-up in the oscillating cylinder example. The solver pimpleDyMFoam is then run.

Results

Circular Motion

Sinusoidal Decay

Conclusions

This post demonstrated how a more complicated motion can be prescribed by using a little math and the timeVaryingUniformFixedValue boundary condition. Always like to hear questions and comments! Has anybody else done something like this?

The equations used to describe steady 1D isentropic flow are derived from conservation of mass, momentum, and energy, as well as an equation of state (typically the ideal gas law).

These equations are typically described as ratios between the local static properties (p, T, ) and their stagnation property as a function of Mach number and the ratio of specific heats, . Recall that Mach number is the ratio between the velocity and the speed of sound, a.

These ratios are given here:

Temperature:

Pressure:

Density:

In addition to the relationships between static and stagnation properties, 1D nozzle flow offers an equation regarding the choked cross-sectional flow area (recall that the flow is choked when M=1.)

Some excellent references for these equations are:

• Gas Dynamics Vol. I – Zucrow and Hoffman – 1976
• Gas Dynamics – John and Keith – 2nd Ed. – 2006

Establishing grid convergence is a necessity in any numerical study. It is essential to verify that the equations are being solved correctly and that the solution is insensitive to the grid resolution. Some great background and details can be found from NASA:

https://www.grc.nasa.gov/WWW/wind/valid/tutorial/spatconv.html

First, here is a summary the equations and steps discussed here (in case you don’t want to read the whole example):

1. Complete at least 3 simulations (Coarse, medium, fine) with a constant refinement ratio, r, between them (in our example we use r=2)
2. Choose a parameter indicative of grid convergence. In most cases, this should be the parameter you are studying. ie if you are studying drag, you would use drag.
3. Calculate the order of convergence, p, using:
   • 
4. Perform a Richardson extrapolation to predict the value at h=0
   • 
5. Calculate grid convergence index (GCI) for the medium and fine refinement levels
   • 
6. Ensure that grids are in the asymptotic range of convergence by checking:
   • 

So what is a grid convergence study? Well, the gist of it is that you refine the mesh several times and compare the solutions to estimate the error from discretization. There are several strategies to do this. However, I have always been a fan of the following method: Create a very fine grid and simulate the flow problem. Then reduce the grid density twice, creating a medium grid, and coarse grid.

There are several strategies to do this. However, I have always been a fan of the following method: Create a very fine grid and simulate the flow problem. Then reduce the grid density twice, creating a medium grid, and coarse grid. To keep the process simple, the ratio of refinement should be the same for each step. ie. if you reduce the grid spacing by 2 in each direction between the fine and medium grid, you should reduce it again by 2 between the medium and coarse grid. In the current example, I generated three grids for the cavity problem with a refinement ratio of 2:

• Fine grid: 80 cells in each direction – (6400 cells)
• Medium grid: 40 cells in each direction – (1600 cells)
• Coarse grid: 20 cells in each direction – (400 cells)

Velocity contour plots are shown in the following figures:

We can see from the figures that the quality of the simulation improves as the grid is refined. However, the point of a grid convergence study is to quantify this improvement and to provide insight into the actual quality of the fine grid.

The accuracy of the fine grid is then examined by calculating the effective order of convergence, performing a Richardson extrapolation, and calculating the grid convergence index. As well, (as stated in the article from NASA), it is helpful to ensure that you are in the asymptotic range of convergence.

What are we examining?

It is very important at the start of a CFD study to know what you are going to do with the result. This is because different parameters will converge differently. For example, if you are studying a higher order parameter such as local wall friction, your grid requirements will probably be more strict than if you are studying an integral (and hence lower order) parameter such as coefficient of drag. You only need to ensure that the property or parameter that you are studying is grid independent. For example, if you were studying the pressure increase across a shockwave, you would not check that wall friction somewhere else in the simulation was converged (unless you were studying wall friction as well).  If you want to be able to analyze any property in a simulation, both high and low order, then you should do a very rigorous grid convergence study of primitive, integrated and derived variables.

In our test case lets pretend that in our research or engineering project that we are interested in the centerline pressure and velocity. In particular, let’s say we are interested in the profiles of these variables along the centerline as well as their peak values. The centerline profiles of velocity and pressure are shown in the following figures:

Calculate the effective order of convergence

From our simulations, we have generated the following data for minimum pressure along the centerline, and maximum velocity along the centerline:

The order of convergence, p, is calculated with the following equation:

where r is the ratio of refinement, and f1 to f3 are the results from each grid level.

Using the data we found, p = 1.84 for the minimum pressure and p=1.81 for the maximum velocity.

Perform Richardson extrapolation of the results

Once we have an effective order, p, we can do a Richardson extrapolation. This is an estimate of the true value of the parameter we are examining based on our order of convergence. The extrapolation can be performed with the following equation:

recall that r is the refinement ratio and is which in this case is 2.

Using this equation we get the Richardson extrapolated results:

• at h=0  -> -0.029941
• at h=o  -> 0.2954332

The results are plotted here:

Calculate the Grid Convergence Index (GCI)

Grid convergence index is a standardized way to report grid convergence quality. It is calculated at refinement steps. Thus we will calculate a GCI for steps from grids 3 to 2, and from 2 to 1.

The equation to compute grid convergence index is:

where e is the error between the two grids and is an optional (but always recommended) safety factor.

Now we can calculate the grid convergence indices for the minimum pressure and maximum velocity.

Minimum pressure

Max velocity

Check that we are in the asymptotic range of convergence

It is also necessary to check that we are examing grid converegence within the asymptotic range of convergence. If we are not in the asymtotic range this means that we are not asymptotically approaching a converged answer and thus our solution is definitely not grid indipendent.

With three grids, this can be checked with the following relationship:

If we are in the asymptotic range then the left-hand side of the above equation should be approximately equal to 1.

In our example we get:

Minimum Pressure

Minimum Velocity

Applying Richardson extrapolation to a range of data

Alternatively to choosing a single value like minimum pressure or maximum velocity. Richardson extrapolation can be applied to a range of data. For example, we can use the equation for Richardson extrapolation to estimate the entire profile of pressure and velocity along the centerline at h=0.

This is shown here:

Conclusions and Additional References

In this post, we used the cavity tutorial from OpenFOAM to do a simple grid convergence study. We established an order of convergence, performed Richardson extrapolation, calculated grid convergence indices (GCI) and checked for the asymptotic range of convergence.

As I said before, the NASA resource is very helpful and covers a similar example:

• NASA – Examining Spatial (Grid) Convergence
  https://www.grc.nasa.gov/WWW/wind/valid/tutorial/spatconv.html

As well the papers by Roache are excellent reading for anybody doing numerical analysis in fluids:

• Roache, 1994:  “A method for uniform reporting of grid refinement studies”, Journal of Fluids Engineering
  https://www3.nd.edu/~coast/jjwteach/www/www/60130/CourseLectureNotes/Roache_1994.pdf
• Roache,  1997: “Quantification of uncertainty in computational fluid dynamics”, Annual Review Fluid Mechanics
  http://ftp.demec.ufpr.br/CFD/bibliografia/erros_numericos/Roache_1997.pdf

The Ahmed body is a geometric shape first proposed by Ahmed and Ramm in 1984. The shape provides a model to study geometric effects on the wakes of ground vehicles (like cars).

Image highlights:

In this post, I will use simpleFoam to simulate the Ahmed body at a Reynolds number of 10^6 using the k-omega SST turbulence model. The geometry was meshed using cfMesh which I will briefly discuss as well. Here is a breakdown of this post:

1. Geometry Definition
2. Meshing with cfMesh
3. Boundary Conditions
4. Results

The files for this case can be downloaded here:

Download Case Files

Note: I ran this case on my computer with 6 Intel – i7 (3.2 GHz) cores and 32 Gb of RAM. Throughout the simulation about 20-ish gigs of RAM were used.

Geometry Definition

STL Creation

The meshing utility cfMesh is similar to snappyHexMesh in that it depends on a geometry file of some type (.stl etc) to create the mesh. But it is different in that the entire domain must be part of the definition.

The ahmed body geometry can be found: http://www.cfd-online.com/Wiki/File:Ahmed.gif

For this simulation, I generated the geometry using SolidWorks. But this wasn’t for any particular reason other than that it was quick since I am familiar with it.

Preparation for Meshing

Once you have an STL file, you could go straight ahead to meshing it with cfMesh. However, some simple preparations to the STL geometry can improve the quality of the mesh created, and make setting up the case easier.

In particular, when you create the STL file in SolidWorks (or your 3D modeller of choice)  it contains no information about the boundaries and patches. As well, cfMesh works best if the geometry is defined using a .fms or .ftr file format.

Use surfaceFeatureEdge utility to extract edge information and create a .ftr file. Firstly let’s extract edge and face information from our STL file. We also define an angle. This angle tells cfMesh that any angle change large than this (in our case I chose 20 degrees) is a feature edge that must be matched.

surfaceFeatureEdge volume.stl volume.ftr -angle 20

After we run this, the new file volume.ftr contains a bunch of face and patch information. 13 surfaces with feature edges were extracted. The first 6 (volume_0 to volume_5) are the boundaries of the simulation (inlet, outlet, ground, front, back, and top).

mergeSurfacePatches volume.ftr ahmed -patchNames '(volume_6 volume_7 volume_8 volume_9 volume_10 volume_11 volume_12)'

After running this command, volume.ftr now contains 7 patches. We are now ready to move on to setting up cfMesh.

Meshing with cfMesh

Set up meshDict file in the system folder

Similar to snappyHexMesh and blockMesh, cfMesh using a dictionary file to control its parameters; meshDict. In this dictionary file we will be modifying a few parameters.

Tell cfMesh what file is to be meshed:

surfaceFile "volume_transformed.ftr";

Set the default grid size:

maxCellSize 0.2;

Set up refinement zones:

We want to set up two refinement zones; a larger one to capture most of the flow further away from the body (including the far wake), and a smaller more refined one to capture the near wake and the flow very close to the Ahmed body.

objectRefinements
{
 box1
 {
    cellSize 25e-3;
    type box;
    centre (2.4 0 6.5);
    lengthX 1;
    lengthY 1;
    lengthZ 3.5;
 }

box2
 {
    cellSize 5e-3;
    type box;
    centre (2.4 0 7);
    lengthX 0.5;
    lengthY 1;
    lengthZ 2;
 }

}

Set up boundaries to be renamed:

renameBoundary
{
 newPatchNames
 {
 volume_0
 {
 newName ground;
 type wall;
 }
 volume_1
 {
 newName back;
 type wall;
 }
 volume_2
 {
 newName inlet;
 type patch;
 }
 volume_3
 {
 newName front;
 type wall;
 }
 volume_4
 {
 newName outlet;
 type wall;
 }
 volume_5
 {
 newName top;
 type patch;
 }
 ahmed
 {
 newName ahmed;
 type wall;
 }
}

Set up boundary layering:

We require boundary layer on both the Ahmed body, as well as the volume_0 patch. Recall that the Ahmed body is surface mounted!

boundaryLayers
{
 patchBoundaryLayers
 {
 ahmed
 {
 nLayers 10;
 thicknessRatio 1.1;
 maxFirstLayerThickness 5e-3;
 }
 volume_0 
 {
 nLayers 10;
 thicknessRatio 1.05;
 maxFirstLayerThickness 10e-3;
 }

 }
}

Run cfMesh

We want to create a hex-dominant grid. This means that the 3D grid will consist primarily of hex cells. To achieve this we will use the cartesianMesh solver from cfMesh.

The results are shown below. The final mesh consisted of approximately 16.9 million cells. The majority of the cells were hexahedra (approximately 99%).

Boundary Conditions for the Solver

For this case, we are going to run a steady-state RANS simulation using the kwSST model and the solver simpleFOAM. This is simply to demonstrate the running of the solver.

The boundary conditions used are summarized in the following table:

As you can see I have used wall functions for the wall boundary conditions. This is due to the very small cell requirements that would be required to resolve the boundary layer on the ground, as well as on the Ahmed body which is at a Reynolds number of one million.

Simulation Results

The simulation took about a day and a half on 6 cores. Throughout the simulation, about 20 gb of RAM was used.

Cross-Section:

Streamlines and pressure on surface:

Vorticity surface in the near-wake

Conclusions

In this post, we meshed and simulated a surface-mounted Ahmed body at a Reynolds number of one million. We meshed it using the open-source meshing add-on cfMesh. We then solved it as a steady-state RANS simulation using the kwSST turbulence model, and the simpleFOAM solver.

The results gave some nice figures and a qualitatively correct result! And it was pretty fun. cfMesh was extremely easy to use and required much less user input than its OpenCFD counterpart snappyHexMesh.

Some references:

For more information on the Ahmed body:

http://www.cfd-online.com/Wiki/Ahmed_body

Some papers studying the Ahmed body:

-See the reference on the above CFD Online page!

As usual please comment and let me know what you think!

Cheers,

curiosityFluids

In this post I am going to simulate an oscillating cylinder in a cross-flow… just for fun… and to provide an additional tutorial case for those wishing to use some of the dynamic meshing features of OpenFOAM.

The case I am going to simulate is a cylinder in a Reynolds number 200 cross-flow (U=2 m/s, D=1 m, nu = 0.01 m^2/s), oscillating at a rate of 0.2 hz.

Tutorial Files

The tutorial files for this case can be downloaded from here:

Download Tutorial Files

Please let me know if the download does not work or if there is a problem running the tutorial files. Note: I ran this case in parallel on a relatively fast 6-core computer. It will take a long time if you try to run it as single core.

Mesh Generation

For this simulation, I built a simple two dimensional O-grid around the cylinder which joined to a series of blocks making a rectangular domain. I built this using the native OpenFOAM meshing utility blockMesh (which I like a lot).

If you are wondering about the blockMesh set up… I intend to a blockMesh tutorial post… not that it’s all that necessary since the OpenFOAM manual covers it pretty well.

Case Set-up

dynamicMeshDict

When running a dynamic mesh case a solver runs as part of the solution and solves for the new grid at each timestep. Several are available in OpenFOAM and I am not really trying to do a full post on that right now. So I’ll just tell you that in this case I decided to use the displacementLaplacian solver.

Along with the solver one must define the coefficients that go with the solver. For most of the solvers this means setting the diffusivity for the Laplace solver. Since I am relatively new to these types of solutions I did what we all do… and turned to the great CFD online forum! A discussion in this post (http://www.cfd-online.com/Forums/openfoam-meshing/97299-diffusivity-dynamicmeshdict.htm) made me think that a good starting point would be the inverseDistance model for the mesh diffusivity.

In the end my dynamicMeshDict (which belongs in the constant folder) looked like:

dynamicFvMesh dynamicMotionSolverFvMesh;

motionSolverLibs ( "libfvMotionSolvers.so" );

solver displacementLaplacian;


displacementLaplacianCoeffs
{
      diffusivity inverseDistance 1(cylinder);
}

The solver produces the grid movements through time as the simulation is performed. Here is what the mesh looks like while it is moving! I added the stationary mesh and the moving mesh. Click on them to get a clearer picture

Boundary Conditions

The set up for this case is simple. An inlet boundary (on the far left) where I specified the incoming velocity and pressure (both are uniform fixedValue). The top and bottom boundaries are slip boundaries (but could also be freestream depending on your preferred set-up style).

The cylinder itself requires some special treatment because of the moving mesh. It must obey the no-slip condition right? So do we set it as uniform (0 0 0) ? No! The cylinder is moving! Luckily there is a handy boundary condition for this in the U file:

 cylinder
 {
      type movingWallVelocity;
      value uniform (0 0 0);
 }

For a typical simulation using pimpleFoam a p and U file would be all that are required. However, since we are doing a moving mesh simulation there is another parameter that must be solved for and requires boundary conditions… pointDisplacement.

For the pointDisplacement boundary conditions, we know that all of the outer edges should NOT move. Therefore they are all fixed with a type of fixedValue and  a value of uniform (0 0 0).

The cylinder however is moving and requires a definition. In this simulation we are simulating and oscillating cylinder. Since we are using the displacement solver the type is oscillatingDisplacement. We input and omega (rad/s) and an amplitude (m) in the following way:

 cylinder
 {
 type oscillatingDisplacement;
 omega 1.256; 
 amplitude (0 0.5 0); // Max piston stroke
 value uniform (0 0 0);
 }

Results

Yay! Now its time to look at the results. Well since I am not doing this for any particular scientific study… let’s look at some pretty pictures!

Here is an animation of vorticity:

Looks pretty nice! I personally have a big nerd love for vortex shedding…. I don’t know why.

Obviously if you intend to do any scientific or engineering work with this type of problem you would need to think very carefully about the grid resolution, diffusivity model, Reynolds number, oscillation frequency  etc. All of these were arbitrarily selected here to facilitate the blog post and to provide a nice tutorial example!

Conclusion

In this post I briefly covered the set-up of this type of dynamic meshing problem. The main difference for running a dynamic mesh case is that you require a dynamic mesh solver (you must specify in the dynamicMeshDict), and you also require boundary conditions for that solver.

Let me know if there are any problems with this blog post or with the tutorial files provided.

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

ANSYS and PTC partner to deliver simulation for every engineer!

What if every engineer had digital tools that gave them perfect insight into the performance of their physical product and allowed them to almost effortlessly gauge the impact of every design choice made? That is of course the holy grail of digital exploration. While we are not there yet, today we take another big step on this quest by partnering with PTC.

PTC was the first to introduce a parametric modeling CAD system, giving engineers the tools to digitally design and document the form of their products and parts. Today, the parametric paradigm is pervasive across industries, and PTC Creo is one of the most used CAD systems in the engineering world.

As you know, at ANSYS we have a mission of making simulation pervasive, so every engineer can benefit from the insight CAE gives regarding the function of their product. So we are thrilled to partner with PTC to bring our Discovery simulation technology natively to PTC Creo and its users, combining form and function.

Hopefully­­­ you have by now experienced ANSYS Discovery Live and the breakthrough experience of intuitive, interactive, instantaneous simulation. Where simulation used to have a steep learning curve and take hours if not days to perform, we consistently hear that even novice users are up and running in 15 minutes and iterating through options and results in seconds.

The partnership between PTC and ANSYS will bring the two worlds of parametric modeling and interactive simulation together so engineers can digitally explore designs at the speed of thought. The first product to ship as part of this partnership will be PTC Creo Live. Subsequently we will work together to deliver the breadth of simulation capabilities in ANSYS Discovery AIM to PTC Creo as well. You can see a sneak preview of the product experience above.

For designers and engineers this should be great news. You get more tool choices so you can pick the ones that are right for you. If you are a PTC user or a fan of the parametric paradigm, check out PTC Creo Live. If you are looking for a purpose-built innovation and simulation tool give ANSYS Discovery Live a try. Both products provide a great experience and deliver on the promise of digital exploration.

My question to you is: What will it do to your product design if you can get engineering insight in almost real-time and iterate through multiple choices in minutes? At ANSYS and PTC, we are excited to see what you create!

The post Computer Aided Design + Computer Aided Engineering = Digital Exploration appeared first on ANSYS.

Join ANSYS at LiveWorx18, the world’s most respected digital transformation conference, June 17-20, in Boston, Massachusetts. As product development is transforming, we’re continuing our mission of making engineering simulation pervasive across the product lifecycle — from early exploration to digital prototyping and operations. Stop by Booth #316 to see live demonstrations of our new products that are transforming the simulation industry.

ANSYS Discovery Live: This game-changing technology is altering the nature of engineering simulation and the way we design products. For the first time, all designers can access broad, real-time simulation on their desktops and interactively explore their models to gain valuable insight. With our latest release of Discovery Live, users will see results that are more accurate and robust, and obtain instantaneous feedback in a shorter amount of time. Whether measuring pressure or velocity, transient solutions settle down significantly faster than before, resulting in a higher degree of confidence in the simulation in a shorter period of time.

Whether visualizing velocity as surfaces, iso-surfaces or a composite smoke-like view, users will gain faster, more accurate and smoother fluids simulation results in Discovery Live.

ANSYS Twin Builder: This just-released predictive maintenance tool quickly and easily builds, validates and connects your digital twin to industrial internet of things (IIot) platforms, including PTC ThingWorx. Using product-mounted sensors, users can collect operating data from the field in real time, and use that information to create an exact replica of the working product in a controlled virtual space. By studying how the simulated product model performs under real-world conditions, users can flag any performance issues, schedule predictive maintenance and reduce downtime. Twin Builder also reduces the twin creation time by half (through model reuse), optimizes product performance by 25 percent and improves operations with a 10 to 20 percent reduction in maintenance costs.

With ANSYS Twin Builder, you can quickly and easily build, validate and deploy digital twins.

ANSYS Additive Suite: Our new suite of products for metal additive manufacturing (AM) delivers the critical insights required by designers, engineers and analysts to avoid build failures and create parts that accurately conform to design specifications. This comprehensive solution spans the entire workflow — from design for additive manufacturing (DfAM) through validation, print design, process simulation and exploration of materials. It includes:

• Topology optimization for weight reduction and lattice density optimization.
• STL file and geometry manipulation for geometry repair, lattice creation and cleanup of parts using the software’s faceted data tools.
• Structural and thermal analysis and design validation that can be applied to models under a variety of thermal and structural loading conditions, for better understanding of performance and durability.

Layer-by-layer additive manufacturing (AM) process simulation

Please visit our event landing page for additional product information. And don’t forget to join us in Booth #316 to see live demonstrations. We hope to see you there!

The post ANSYS at LiveWorx18: Simulate. Iterate. Innovate. appeared first on ANSYS.

Combine the ANSYS Virtual Reality (VR) configurator with Aston Martin luxury in a powerboat, and you have a yacht that James Bond would have looked good in while chasing the bad guys in his inimitable style. (Bond loved driving his Aston Martin automobile starting in the series’ third movie, “Goldfinger,” in 1964 and continuing for a span of 11 films over 30 years.) That’s the experience that Quintessence Yachts, an Aston Martin official licensee, is presenting at TechXLR8 in London this week— the Quintessence AM37 boat configurator, based on ANSYS VR simulation technology — which is poised to revolutionize the design, feel and appearance of powerboats.

Instead of creating a CAD design and then making a series of physical models of a new yacht to explore the possibilities of materials and color, ANSYS virtual reality simulation makes it possible for designers, engineers and customers to view virtual models of the yacht in 3D from any angle. Working together, the designer and customer can customize the yacht’s design materials, determining how they interact with different high-quality paint colors in the Aston Martin palette under various lighting conditions, to achieve the customer’s dream yacht.

The dream yacht could be the AM37, a ‘gran turismo’ leisure powerboat with a maximum speed of around 44 knots and premium-class quality and refinement, or the AM37 S with twin 520 hp Mercury gasoline engines for a maximum speed of up to 50 knots (to catch the bad guys faster).

Using the Quintessence AM37 boat configurator, powerboat engineers can create and modify their products using a touch-screen to change the colors or ergonomics of the design, then view it in real-time 3D on the Quintessence website, a mobile phone or a VR headset. Viewing the details of the yacht from any angle is like exploring it in a showroom, only better. The customer can remotely climb into the cockpit, tour the cabin, walk on polished wood deck, and watch the sun gleaming off the chrome fixtures.

ANSYS VR simulation not only accelerates the design process to save time and money, but it ensures that the design will be optimized for aesthetics, ergonomics and performance. This kind of optimization is hard to achieve using traditional physical prototyping methods.

If you are attending TechXLR8 in London this week, you can see the Quintessence AM37 boat configurator in action at AR & VR World, one of the eight conferences brought together under the one roof of TechXLR8. Tell them “Bond — James Bond” sent you.

The post ANSYS Real Time Configurator Allows Yachting Industry to Navigate Design with Simulated Prototypes appeared first on ANSYS.

KN Trakcji i Torów is a registered organization in the department of electrical engineering at the Warsaw University of Technology in Poland. We are an ANSYS Academic Student Team conducting research and running electromagnetic simulation for better understanding of electric traction. During 2017 and 2018, we focused on two main projects:

• Designing electromagnetic passive brakes for a prototype hyperloop vehicle.
• Designing a permanent magnet, linear synchronous motor for personal rapid transit and Maglev technology.

Electromagnetic Brakes

In 2017, our student group was a part of the Hyper Poland University Team, which designed a prototype for the Hyperloop Pod II Competition organized by SpaceX. In August 2017, our design made it to the finals of the competition. This achievement was made possible by student engineers who designed passive electromagnetic brakes to slow down the Hyperloop pod from 100 m/s and bring it to a stop.

The electromagnetic brakes were based on NdFeB N52 permanent magnets. The vehicle used four Halbach arrays of permanent magnets as a primary braking system. A Halbach array works by strengthening the magnetic field on one side of a magnet pack while reducing the other side to near zero magnetic field using a spatially rotating magnetization pattern. Magnet packs were positioned symmetrically on both sides of the central aluminum rail, so that the strengthened magnetic field faced the aluminum rail. Permanent magnets were arranged radially, with the magnetization direction of every magnet cube rotated 45 degrees in relation to its neighbors (see magnetization arrows in individual magnets in Figure 1).

Figure 1. Braking magnets package with magnetization direction above aluminum rail (dimensions in mm)

While moving along the rail, permanent magnets cause eddy currents in the aluminum. The eddy currents create their own magnetic field, which counteracts the magnetic field of the permanent magnets. As a result, a perpendicular force repels the permanent magnets from the aluminum rail. Parallel forces also counteract the movement of the magnets, causing the Hyperloop pod to slow down.

To design the electromagnetic brakes, we conducted hundreds of 3D simulations using ANSYS Maxwell. In these simulations, two sets of permanent magnets moved along the aluminum plate in transient mode to reveal all the eddy currents and magnetic fields in the model (Figures 2 and 3).

Figure 2. Screenshot from transient simulation

Figure 3. Cross section of the model showing predicted magnetic field in the air gap

After a series of simulations, we were able to estimate the final dimensions of the brakes and required number of magnetic cubes. We obtained the following results for one braking Halbach array (Figures 4 and 5):

Figure 4. Characteristic stabilizing force generated by one braking Halbach array versus vehicle speed

Figure 5. Characteristic braking force generated by one Halbach array versus vehicle speed

Permanent Magnet Linear Synchronous Motor

At the end of 2017, our team became interested in personal rapid transit (PRT) and Maglev technology. We decided to design a single-sided, permanent magnet linear synchronous motor (PMLSM) for contactless propulsion and levitation of a PRT or Maglev train to transport people.

Figure 6. Screenshot from simulation of PMLSM propulsion for Maglev

We are still performing the simulations using the transient mode of ANSYS Maxwell 2D; the optimal dimensions have not been obtained yet. When we have determined the dimensions, we will conduct 3D simulations. In the next two years, we are planning to build a small-scale model of a Maglev train and begin investigating the requirements of a full-scale vehicle. To learn more about our team, please follow us on Facebook at https://www.facebook.com/KNTitT/.

The post Student Team Uses Electromagnetic Simulation to Design Hyperloop Brakes and Motor appeared first on ANSYS.

Some highly publicized benefits of autonomous vehicles (in addition to driver downtime) are the reduction of traffic congestion and increased safety. Today, much of autonomous systems engineering centers on adapting cars, trains, buses, trucks and drones that were originally designed for human operators. But, what if, in addition to changing how vehicles are driven, we also alter the environment to make it more conducive for autonomous navigation?

Autodrive Solutions, a startup from Madrid, is developing systems to make autonomous driving safer and more coordinated by mapping routes with plastic paint spots (for roads) or bars (for rail tracks). Using these markers and an onboard radar unit that reads them, a central host computer will determine each vehicle’s location to within a centimeter so that traffic flow can be synchronized and improved.

The company used software obtained through the ANSYS Startup Program to design portions of its Radar Positioning System (RPS). It leveraged ANSYS HFSS SBR+ to design the lens that focuses the radar waves onto the paint dots to achieve the 1-cm positioning accuracy required, and ANSYS SCADE to develop the safety-critical embedded software that will flawlessly control the hardware and meet rigid EU certification standards.

Those of us in North America understand roadway traffic jams and how a centrally controlled system could smooth our commutes. In other areas of the world where train travel is more common, the autonomous operation of railways can prove highly productive. Trains already perform a preprogrammed braking process when passing by a radio frequency identification (RFID) unit. However, a large number of variables (number of cars, wear, etc.) must be considered with regard to braking time, which a positioning system could help to quantify. And, considering the number of trains on a limited number of tracks, exact positioning would provide more accurate speedup and slowdown ranges to deliver faster passage and larger volumes on crowded routes. Continual speed adjustments on the rails could result in a savings of 20 percent of the 8-billion-euro energy cost of the European train fleet each year.

ANSYS SCADE proved to be mission-critical to Autodrive Solution’s engineers, saving the company 80 percent in development time in getting RPS to market. Learn more in the ANSYS Advantage article Autonomy on Roadways and Railways.

The post Position Tracking Yields Efficient Autonomous Travel appeared first on ANSYS.

Erosion of pipe walls due to solid particles suspended in a carrier fluid has been a matter of concern for many industries, but the oil and gas industry is the one that suffers the most. The production of sand as part of drilling operations makes it almost impossible to operate equipment without some erosion.

A tanker’s corroded pipes

Physical tests to determine part life are expensive and time-consuming.  The industry needs to be able to model this phenomenon with high-fidelity so they can predict life and set maintenance schedules accordingly. By high-fidelity, I mean not only the validity of the erosion model for the operating conditions, but also the ability to calculate local changes in flow due to material removal.

At ANSYS, we have been helping our clients in this area by providing a user-defined erosion module that is included in the latest release of ANSYS Fluent. Our customers who have been using the older method will find this new model mesh easier to set up, and will benefit from more robust wall deformation calculations. As usual, the new model has gone through rigorous testing and validations based on published material. Below, I will share some salient features of the model and a validation case. I will not discuss the basic overview of erosion as that was covered in an earlier blog by my colleague, Mohammad Elyyan.

The model is called Erosion Dynamic Mesh. It is activated as soon as erosion is checked under “physical models” in the discrete phase model (DPM) menu shown below.

Once the model is turned on, it is straightforward to set up a wall for erosion calculations and specify its density. There are four reference erosion models included. You can also modify model constants or load your own user-defined erosion rate model. The main panel also allows for automatic dynamic mesh setup, which takes care of the wall deformation. Within dynamic mesh setup, the boundary layer mesh on the wall moves with the deformation to keep the wall cells from stretching abnormally. The “Run Erosion-Dynamic Mesh Simulation” button in the software takes you to the run time settings, as shown in the picture. Here you can set the fixed or variable time stepping method, specify the total time of erosion, save files and pictures and generate an automated mesh deformation report. Simulation progress is shown as elapsed time at the bottom of the screen.

Several cases were tested using this new workflow. Here we describe a case that is based on the experimental paper published by Nguyen et al., 2014. This is a flat plate erosion scenario in which a jet of liquid hits the plate at 30 m/s. The suspended sand particles cause the plate surface to erode. The geometry setup is shown here.

Figure 1. Geometry setup shown (above) with flat plate erosion model (below)

The Oka erosion model with default settings was used, and the predicted erosion pattern was compared with the measured data. Figure 2 shows this comparison.

Figure 2.  Depth of erosion along a diametrical line at three different times

The x-axis runs across the eroded area as shown by the black line in the top right corner inset. The y-axis shows the current location of surface nodes compared to the original uneroded state. Our simulation results match the trends of Nguyen’s experiment quite well at three different times (5, 15 and 30 minutes). The absolute value of erosion is also close in the simulations and the experiments. These numbers can be improved by tuning the Oka model to the test condition.

The effect of the number of particle streams on the erosion magnitude is also important (see Figure 3).

Figure 3. Erosion rate dependence on the sample size of the discrete phase

More tracks result in a smoother erosion pattern. However, calculating more tracks means more CPU time. Hence, there is an optimum number of tracks beyond which the simulated results change very little. From Figure 3, this optimum number is somewhere between 50 and 100 tracks.

The mesh smoothing scheme is quite robust. Together with cell remeshing, it allows you to set up simulations with very large deformations. The wall node motion logic is general enough to be employed for other rate-based phenomena, such as corrosion or ablation due to surface reactions, as one example. For details, please contact me at Muhammad.sami@ansys.com.

Take a look at this video to see examples of erosion-dynamic mesh simulations:

To learn more about the latest fluids innovations, watch our webinar.

The post New ANSYS Fluent Dynamic Mesh Captures Wall Degradation Due to Erosion appeared first on ANSYS.

You may have seen the press release: starting May 31, a version of the Tecplot 360 flow visualization software will be packaged with CONVERGE. No corporate details here–this is an engineer’s viewpoint. I am a longtime Tecplot user, having worked extensively with nearly every version since 2008 R1. I’m not a trainer, so I won’t try to teach you how to use Tecplot (if you’d like to see a CONVERGE-focused introduction to Tecplot 360, Tecplot Product Manager Scott Fowler gave a webinar earlier this year). Rather, I’ll tell you what I like about it as a CFD research engineer, and what you might like too. The brief version: Tecplot for CONVERGE is a user-friendly tool that works well and makes sense.

To me, the most important characteristic of any tool is usability. If I can’t figure out how to make it work, it’s of no use to me. My introduction to Tecplot involved no formal training and no user guide (although I’m sure there was one available). I was working off of nothing except for my fellow graduate students and a willingness to experiment. It turned out that this was enough!

Tecplot’s user interface is approachable and unintimidating. The workflow is logical and smooth. Some software packages give the impression that they were designed by a GUI team with no engineering knowledge; some packages look like they were written by engineers with no clue about interface design. Tecplot bridges that gap. The answer to “How do I…” is usually logical and straightforward, and Tecplot feels like it was designed from the ground up by a team that had extensive experience with CFD.

Let me give you an example. Suppose I’m loading a complex 3D flowfield. When I first load that dataset, I don’t know exactly how I want to visualize it. I will probably pan, zoom, and rotate through a wide variety of views, trying to figure out the best perspective from which to visualize my flow. As with many packages, in Tecplot I can do this with just the mouse, without resorting to menu buttons to change modes. The difference is, once I find a view I like, Tecplot gives me precise control over the camera location and direction. If I alter the view and don’t like the change, I can revert the view setup. If I want to compare several different datasets, I don’t have to fiddle around with the mouse controls to get approximately the perspective I want. I can copy the center of rotation and spherical angles and get precisely the right view, with a minimum of fuss. As my understanding of my dataset grows from general familiarity to exacting detail, Tecplot offers me increasingly exacting controls.

I like Tecplot’s approach to data and file structuring. In my workflow, all data at a certain simulation time is written to a single <casename>_<filenumber>_<time>.plt file. Because of this one-to-one relationship, I can see at a glance how many datasets I have available for my case (rather than having different files for different variables). When I load my .plt file, data are structured by zone. Each zone might have different variables (e.g., a fluid zone versus a parcel zone), and I can display them differently. I can extract sub-zones (e.g., a slice from a fluid zone) and display those separately. If I loaded multiple data files, I can animate zones over time. If I write out a new .plt file, I can write specific zones to that file. This is especially helpful for, say, preserving interesting cross-sections of a very large volumetric dataset.

Importantly, Tecplot for CONVERGE retains nearly the entire feature set of a stand-alone Tecplot 360 installation. It is not limited in cell count, processor count, plot details, data alteration, or most other functional details. The chief restriction is in file formatting. Tecplot for CONVERGE is limited to output files that have been converted using a new post_convert executable. This post_convert will be released with Tecplot for CONVERGE and will be included with all future CONVERGE Studio and CONVERGE solver packages. Make sure to select the “Tecplot for CONVERGE” or “Tecplot 360” option in post_convert when converting output files. If you opt to purchase a full Tecplot 360 license, of course it is able to read these specially formatted files.

Tecplot offers powerful data alteration and calculation tools, as well as a robust scripting capability. Once you tell Tecplot which variable names correspond to which state variables, Tecplot can calculate on demand many derived quantities commonly used in CFD. No more trying to remember the functional form of the Q-criterion, because it’s built in. If the quantity you need is not included in this hundred-odd set, you can directly specify whatever calculation you wish to perform. Further, all of this can be scripted in a macro. You can record macros through the GUI (which journals all of the actions you’ve performed) and play them back, or you can write a plaintext macro directly.

Finally, Tecplot makes attractive images and animations! Much like the viewport commands, Tecplot adopts sensible defaults but gives you exacting control when you want it. I can add, adjust, and remove control points on the contour plot color map, banded or continuous, and drop in contour lines at specific values. I can plot spray parcels by various shapes and in various colors and sizes (including by spray variable values). Tecplot’s flexibility allows me to make a plot in twenty seconds that looks pretty good, spend twenty minutes making it look exactly right, or anywhere in between.

I love Tecplot, and I am very happy that Convergent Science is partnering with the Tecplot team. Not every engineer prefers the same tool, of course. CONVERGE will continue to support a wide range of flow visualization and analysis packages through the post_convert utility. But no matter your present visualization tool of choice, I encourage you to take Tecplot for CONVERGE out for a spin. I think you’ll like what you see.

A lot of things happened in 2008. There was a financial crisis. China hosted the Olympics. Barack Obama won the US presidency. Sarah Palin could even see Russia from her house! But something else was brewing in the Midwestern college town of Madison, Wisconsin. In 2008, Keith Richards, Eric Pomraning, and I realized that we had written a CFD code that could change the simulation world. Not only that, but it was finally ready to be shared with the public. We had spent the last seven years developing this software and now had to figure out how to market it, sell it, support it, and document it, all while running a business. A business that had focused on consulting services since its inception in 1997. How were we going to pull this off? Especially at a time when our biggest client base, the US automotive industry, was facing its own crisis, including bankruptcies and government bailouts. I’ll come back to that in a minute, but first, a bit more history on the CFD code that turns ten this year.

Many of you know that CONVERGE started out as MOSES (named by David Schmidt, one of the original founders of our company). But did you know that this stood for Modular Open Source Engine Simulation? That’s right, open source. CONVERGE was originally written with the intent of replacing KIVA, the software that we (and many others) had used in our graduate studies. We accomplished a lot with KIVA, and it taught us a lot about reacting flow CFD. However, there was one big problem with it and, frankly, all CFD codes at the time: the mesh. The mesh quality was often low and the resolution coarse, both of which significantly degraded the accuracy of CFD simulations. Moreover, for anything but a simple, stationary geometry, mesh creation was incredibly painful. In fact, much of the consulting we did in the early years was based around KIVA mesh generation. Keith had written a tool called G-Smooth, which allowed us to make full, complicated engine meshes for KIVA faster than anyone else—in one week. Are you kidding? An entire week of engineering time to make a mesh was considered fast? We knew something needed to change.

In 2001 we sent the US government a proposal called The MOSES Project: A Modular, Open Source Engine Simulation Code for Parallel Computation of Complex Geometries. Their response was something along the lines of “this sounds like a great idea; please come back when industry is interested.” In their defense, this was unsolicited, they weren’t asking for MOSES, and “never make a mesh again” probably sounded pretty far-fetched to the reviewers. This was the first of many times when it would have been easy to throw in the towel.

Instead, we went to industry, specifically to a large engine manufacturer (Engine Maker X). It wasn’t easy to convince them, but they too were frustrated with the time required for making meshes as well as the accuracy implications of using a poor quality mesh. A few key people at Engine Maker X believed in us enough to secure funding to help with early development. So in late 2001 we went to work—Keith and Eric developed the core solver while I kept up the consulting side of things to keep the lights on. A couple of years later, I joined them full-time on code development and started implementing the spray and combustion models. I’ll never forget the month of April 2004. The first version of MOSES was due on May 1, and like any good researchers, we pulled an all-nighter—that lasted the whole month! This month-long all-nighter was required because we’d scrapped our original approach when we realized that an immersed boundary method wasn’t going to work for our purposes. Yet another time when throwing in the towel would have been easy, but I’m so glad we didn’t.

Fast forward to 2008 and a lot of changes were about to drop. Our company, Convergent Thinking, LLC changed its name to Convergent Science, Inc. We also changed the name of our software from MOSES to CONVERGE (fun fact: believe it or not, we discovered there was another CFD code called MOSES!). We were entering the automotive CFD market at one of the worst times in history for that industry. But we quickly learned that the financial crisis was motivating companies to make changes. Companies needed to tighten their belts and find the most efficient and accurate simulation tools possible—enter CONVERGE.

Sales of CONVERGE unofficially started where else but at the SAE World Congress in 2008. Daniel Lee, who was one of the original founders of our company, had left to pursue a career at Fluent (and later ANSYS) after graduating from UW-Madison in 1998. Ten years later, he had honed his CFD sales chops and was ready to come back to Convergent Science. Good timing, as Eric, Keith, and I had no experience selling software. So the four of us met at SAE, ready to take on the big players in the engine industry. No booth, no brochures, just Dan’s little sales notebook and phrases like “imagine a car without gas” (trying to make an analogy with “imagine a CFD code where the user doesn’t have to make a mesh”). These days gasless cars are a little easier to imagine, but our analogy sounded good at the time!

Selling any software is difficult, but selling CFD software can be next to impossible when you’re dealing with companies that have an established workflow and years of experience with a legacy code. We heard a lot of “no” before hearing “yes.” We were told many times early on that we were, hands down, the best CFD code, but there was concern that our company was too small. Eventually, though, we convinced automotive engineers, and later engineers from a host of other industries, that we were (and still are!) a company dedicated to continued innovation and superlative customer service.

We’re also experts in our application fields. There really is something to all of the firsts that we’ve introduced to the community (autonomous meshing, direct detailed chemistry for combustion, grid-convergent Lagrangian spray modeling, cyclic variability with URANS, etc.), many of which were originally quite controversial. I like to tell students that if they’re not working on something at least somewhat disruptive in their research, it’s probably not that novel. Boy were we controversial with CONVERGE—many of the entrenched CFD best practices were based on software and hardware limitations rather than fundamental scientific concepts, and we challenged these practices with new ideas based on first principles. These innovations have no doubt succeeded in helping move the needle from postdiction to prediction over the last ten years, and these innovations have helped propel CONVERGE’s continued growth.

In 2018, ten years after we started selling CONVERGE, we have around 100 team members in our offices across the globe. Approximately 95% of engine makers in the US use CONVERGE, and around 85% of engine makers worldwide use CONVERGE. We’re taking our predictive CFD approach to new markets, and we’re once again changing the game with CONVERGE 3.0, which will be released later this year. CONVERGE has taken on a life of its own, with a large user community that includes engineers in industry, national labs, and universities. We have annual user conferences in both the US and in Europe (don’t miss our US event in Madison in September, celebrating CONVERGE’s ten-year anniversary!). Indeed, the quotation from Robert Fritz that I added to CONVERGE’s main.c subroutine many years ago has, in fact, come true: “At first, I am giving energy to the creation, but later the creation seems to be giving energy to me.” Happy tenth birthday, CONVERGE, may you continue to empower CFD users to never make a mesh again for years to come.

In 2017 Convergent Science saw tremendous growth and success in many areas. We now have nearly 100 employees (almost double the 2014 headcount), new clients are using CONVERGE CFD to investigate pumps and compressors, and our customer base using CONVERGE for aftertreatment and gas turbine design continues to grow. We’ve done all this while also increasing our majority share of the global internal combustion (IC) engine simulation market.

Our dedication to accurate and grid-convergent simulations ensures that CONVERGE offers cutting-edge CFD solutions for a wide variety of complex flow problems. Our teams dedicated to IC engines, gas turbines and aftertreatment, and new applications such as compressors and pumps ensure that CONVERGE can meet the unique challenges of each industry.

Continued Authority at SAE, DOE Merit Review, and ASME ICEF

The Society of Automotive Engineers World Congress Experience (SAE WCX17) once again reinforced the prevalence of CONVERGE in innovative IC engine design. In April, more than 35 papers demonstrated results achieved with CONVERGE, including publications from Aramco Research Center, Argonne National Laboratory, GE Global Research Center, Groupe Renault, IFP Energies nouvelles, King Abdullah University of Science and Technology, Oak Ridge National Laboratory, and University of Perugia.

In June, CONVERGE’s utility for innovative, energy-saving research was affirmed at the annual DOE Merit Review. Seventeen programs reviewed by the U.S. Department of Energy referenced partnerships with Convergent Science and work with CONVERGE. Topics ranged from clean combustion in light-duty engines to knock prediction to soot modeling with gas kinetics and surface chemistry.

Seattle played host to this year’s ASME Internal Combustion Engine Fall Technical Conference (ICEF 2017), where 25 papers featured results from CONVERGE. Topics of CONVERGE papers at ICEF included pressure oscillations in numerical simulations of IC engines, gasoline compression ignition calibration, selective catalytic reduction of NOX with detailed surface chemistry, and cycle-to-cycle variation prediction with LES turbulence modeling. Many of our most influential collaborators, including Argonne National Laboratory, GE Global Research Center, and Oak Ridge National Laboratory, presented their topics at this engaging conference in October. Two of Convergent Science’s most experienced support engineers, Shawn Givler and Sameera Wijeyakulasuriya, gave a popular workshop at ICEF that introduced engineers, students, and experimentalists to some of CONVERGE’s powerful tools for modeling heavy-duty engines.

Gas Turbine Relight with GE and Honeywell

Engineers from both GE Aviation and Honeywell Aerospace were interested in CONVERGE’s ability to predict high altitude ignition and relight in gas turbines. This phenomenon has been notoriously difficult to simulate due to the long meshing times associated with complex geometries and the need for accurate, detailed combustion modeling. But Scott Drennan’s Gas Turbine team was up to the task.

GE Aviation engineers gave Scott’s team a diverse range of operation conditions, and Scott’s team proved that CONVERGE can indeed accurately predict relight (or a failure to relight) across the varying conditions. GE Aviation engineers are now testing CONVERGE on fundamental and practical combustor designs for further validation, development of best practices, and optimization.

Honeywell Aerospace successfully used CONVERGE to model relight in their five-sector combustor geometry, and they noted that CONVERGE’s autonomous meshing capabilities help make CFD a viable option to assess all facets of gas turbine design.

CONVERGE-ing in Europe

We hosted our first European user conference in Vienna in early March. This inaugural European CONVERGE experience was a big hit with European clients as well as super-users from the United States who traveled to Vienna to share and learn with their counterparts across the pond. Networking sessions included a tour of a castle and a traditional evening at a Viennese tavern. Attendees from many institutions—including GE, Groupe PSA, IFP Energies nouvelles, Politecnico di Torino, Renault, University of Rome Tor Vergara, and Volvo Cars—helped make this inaugural event a memorable one.

Motor City Hosts Fourth Annual U.S. User Conference

Since so many automotive OEMs are based in Detroit, the Motor City was the perfect location for our fourth annual North American user conference. Two hundred fifteen people registered for this conference, making it the largest CONVERGE conference to date. Users from 42 companies, 19 universities, and six national laboratories experienced two days of informative presentations. Many also participated in some of the introductory and advanced CONVERGE training sessions that were offered. Social events included a Ford Rouge Factory Tour and a dinner social at The Dearborn Inn.

IDAJ’s Continued Success in Asia

IDAJ, our distributor in Asian markets—mainly Japan, China, and Korea—has continued to provide encouraging growth in sales, promotion, and support of CONVERGE users on the other side of the globe. In November, Daniel Lee, Eric Pomraning, and Yunliang Wang gave users an overview of the current status and future developments of CONVERGE at the IDAJ ICSC 2017 Conferences in Yokohama, Japan; Seoul, South Korea; and Shanghai, China. IDAJ continues to host regular CONVERGE training sessions and has expanded the CONVERGE user base in the automotive OEM market, non-engine markets, and academia.

Assorted Consortia

Convergent Science is proud to be a member of the High-Efficiency Dilute Gasoline Engine (HEDGE-IV) Consortium launched by Southwest Research Institute. This consortium gives Convergent Science the opportunity to work with some of the brightest minds in the engine world who are working together to produce cost-effective solutions to engine efficiency-related challenges.

Our Computational Chemistry Consortium (C3) was formed to bring together industry, academic, and government partners to refine existing computational chemistry tools. C3 is now in full swing, with a major global automotive OEM leading the way. With more than twenty years of experience developing comprehensive chemistry models to help predict real fuel behavior, Professor Henry Curran is well-positioned as Chief Technical Advisor of this consortium. Professor Curran and I are guiding C3 in its efforts to develop new models, tools, and mechanisms to lead the advancement of combustion and emissions modeling for the entire scientific community.

Convergent Science: India

A great opportunity presented itself when CEI (formerly our distributor in India) closed its office in Pune: Ashish Joshi, former CEI India manager, master of all things EnSight, and CONVERGE super-user and distributor, agreed to be the leader of our newly formed CS India office. Ashish is now helping to sell CONVERGE and support users in India and southeast Asia. According to Ashish, a distinct possibility for huge growth in the engine design market in India exists because by 2020 engine manufacturers will be held to a much stricter Euro VI-level emissions standard. This is an exciting time to have a solid foothold in the Indian engine design market.

Convergent Science Turns 20

Founded in December 1997 by a group of University of Wisconsin-Madison graduate students, Convergent Science (originally Convergent Thinking) made its debut as an engine CFD consulting group. Twenty years later, CONVERGE is now the global leader in IC engine CFD simulation and is continuing to grow in this market and in others.

2018 and Beyond

In 2018, we are looking forward to continuing to expand CONVERGE’s presence in the European, Asian, and Indian automotive markets. Equally exciting is our ongoing expansion into the compressor and pump industries, which are primed to implement accurate transient CFD. Finally, 2018 is a special year because it marks CONVERGE’s 10th anniversary as a commercially available CFD code (keep your eye out for a blog post commemorating this event in just a few months!). We look forward to bringing continued innovation and superlative customer service to all of our clients. Want to join us? Check out our website to find out how CONVERGE can help you solve the hard problems.

Same Face, New Name

Many CONVERGE users in India and Southeast Asia are quite familiar with the magnificently mustachioed Ashish Joshi, who was the head of CEI’s Pune office. Until recently, CEI was a CONVERGE distributor, and Ashish sold CONVERGE and provided technical support to many CONVERGE users. Now Ashish will continue serving in a similar capacity and will take on some additional duties as the leader of Convergent Science’s newest office, Convergent Science India LLP.

In opening the Indian office, we capitalized on some changes to the CEI organizational structure and brought Ashish officially onto the Convergent Science team. Ashish has six years of experience using CONVERGE in a support and distribution capacity, so he is perfectly equipped to succeed in his new role of promoting, selling, and supporting CONVERGE throughout India and southeast Asia.

Ashish is no stranger to new ventures. He helped create the CEI office in Pune back in 2011 after about seven years of working in sales and support for a different CAE software vendor. He is thrilled to use his organizational and planning talents to give Convergent Science a reputable presence in India from its new office in Pune.

Opportunity Abounds in India

We have recently extended Convergent Science’s Indian presence based not only on this country’s strong history of CFD in research, but also on the engine market’s growth opportunity and other expanding research and development efforts in this quickly industrializing nation.

“India’s government has lagged in its adoption of strict emissions standards,” Ashish says. “But by the year 2020, engine manufacturers will be held to a much stricter Euro VI-level standard. This means they’ll need CONVERGE’s unique ability to accurately predict engine performance and emissions in order to remain competitive and comply with regulations.”

India’s highly sought-after technical universities drive demand for CONVERGE in academic research. Consequently, these same researchers demand CONVERGE when they move to commercial R&D groups. IIT Bombay, IIT Delhi, IIT Madras, IISc (Indian Inst of Science), and several NITs are among the many academic research groups already using CONVERGE. Ashish has already begun work expanding CONVERGE’s presence in the most prestigious technical institutions of India.

Multinational corporations have been drastically increasing their presence in India. Indian engineers, scientists, and other professionals have seen an increase not only in the quantity of work in the past 10 years but also in the depth and quality of work for which they are responsible.

Beyond India

Ashish’s territory includes India, Australia, Malaysia, Indonesia, Singapore, and other southeast Asian nations. He’s especially excited to build on his past success by working with professionals in Singapore. “The business culture in Singapore is very progressive and results-focused,” notes Ashish. “There is very little bureaucracy. The researchers I worked with on wind turbine simulations were eager to use the cutting-edge technology that CONVERGE offers.”

Ashish has worked on fluid-structure interaction simulations with Indonesian aerospace researchers and has sold to universities in Malaysia, and Australia. With his efforts now fully dedicated to expanding the use of CONVERGE, Ashish is excited to develop collaborative networks in these nations to bring the benefits of CONVERGE to the swiftly changing nations of southeast Asia.

The Real Motivation

An expansion into India may seem like it was just the logical next step, but our main motivation to open an office in India is to better serve CONVERGE users. Our world-class support and applications team has developed a deep understanding of the needs of CONVERGE users in India. Based on this understanding, our leadership made the strategic decision to ask Ashish to represent Convergent Science in an official capacity from the new office in Pune.

Engineers and researchers using CONVERGE are more than just users. They are partners with Convergent Science. We know that when CONVERGE users succeed, Convergent Science succeeds, regardless of the type of simulation, organization affiliation, or country in which the researchers work. Ashish is an expert CONVERGE user, an excellent communicator, and a very important part of the success of CONVERGE as we expand into new geographic areas.

If you are based in India, Australia, or southeast Asia, please contact Ashish directly with any questions about how you can start using CONVERGE to gain insight into your research and design for IC engine combustion, gas turbine combustion, aftertreatment, or fluid flow through any complex system.

Contact

Ashish Joshi

Principal Engineer & Manager

Indian Operations

ashish@convergecfd.com | LinkedIn

I once saw a wind turbine blade traveling on an open-bed truck on a back country highway. It was more than a hundred feet long, white, smooth, and curved, and it filled me with awe. How very far we have come since a fictional Don Quixote tilted at windmills^[1]: we build these giant blades that sweep an acre (!) with each spin and mount them on towers taller than the Leaning Tower of Pisa.

So there was this blade being trucked along somewhere. How did they decide what it should look like and where to put it? Once you decide you want a wind farm (a network of individual wind turbines connected to the power grid), the first thing to do is to carry out detailed studies of weather, wind, and terrain at candidate sites. Then, the industry standard is to perform simple parameterized empirical simulations for wind turbine wakes using models such as the WAsP software suite^[2]. However, with growing computational resources and access to high-performance computing, you can design every aspect of the wind farm using CFD: from individual blade loading (valuable for blade design), to optimizing the location of the individual turbines to prevent interference from the other wakes, to estimating the impact of the environment on the tower and its associated structures. For example, Hannah Johlas, a graduate student at the University of Massachusetts Amherst, whose research is co-funded by Convergent Science, studies offshore support structures using CONVERGE. Other research has focused on the physical impact of the wind farm on the environment^[3] (such as land surface temperature^[4] and crops^[5]) or the weather^[6]. Local governments and stakeholders can find results from CFD persuasive.

But there’s a catch: getting detailed and accurate results from CFD in these scenarios can be computationally expensive and time-consuming for the engineers running the simulations. CONVERGE CFD can provide a detailed picture of any aspect of wind farm design and optimization and contains several features, including autonomous meshing, genetic algorithm optimization, and smooth handling of complex moving geometries, to make the cost of these simulations manageable.

Although wind farms have historically been sited on flat terrain, such as offshore or in Iowa, which now leads wind energy production in the United States^[7], wind farms are increasingly situated in more complex terrain, such as various sites in California^[8]. In the figures below, we show CONVERGE results of wind flow around four wind turbines placed in a complex terrain, containing a hill, a road, and a truck moving on the road.

The most powerful feature used here is CONVERGE’s autonomous meshing capabilities, including Adaptive Mesh Refinement (AMR), which adds cells exactly where additional resolution is required. Here we also use boundary embedding, which moves along with the blade. Previous CFD studies have used an actuator disk simplification for the wind turbine with a bulk source term^[9], but this neglects the impact of the blade motion on the downstream wake. CONVERGE can resolve the rotating blade motion and the consequent downstream wake effects (Figure 1). In Figure 2 below, you can see an isosurface of the Q criterion (a visualization of the vortex structure) with additional mesh resolution along the blade. By including blade motion instead of an actuator disk, the turbulent wake is resolved more accurately. This, in turn, lets you observe the flow field around a complex piece of terrain such as the hill (Figure 3).

It can be useful to look at the effects of other factors on the wind farm as well.​ ​In Figure 1, you can see​ a truck on the road in the simulation domain. With AMR and with boundary embedding along the surface of the truck,​ ​CONVERGE can resolve the​ effect of the moving truck on the flow field, as well as the interaction of the wakes of the turbines closest to the road and the truck.

CONVERGE offers many features to optimize and design a wind farm. You can set different roughnesses for different surfaces in the terrain (e.g., water, farmland, and hills). You can allow the towers to rotate and respond to changing winds (specified as a source on the boundary of the domain). You can specify an actuator-line model to simulate wind flow through a wind farm. When designing tower placement and height to compensate for wake effects, you can use genetic algorithm optimization (available within CONVERGE) to spawn a number of candidate configurations, which can save you design time upfront. You can then use CONVERGE CFD simulations to determine the optimal configuration for a wind farm with your particular topography and wind conditions.

Countries all over the world have been investing steadily in infrastructure to increase wind capacity, and the world’s cumulative capacity for wind power has tripled in the last five years^[10]. With the growing push toward renewable sources of energy, it is imperative to have tools to ensure effective planning for wind farm design. CONVERGE CFD can accurately (and easily!) simulate many aspects of wind farms so that you can take full advantage of this increasingly popular source of energy.

Citations:

When you purchase software, there are often many resources to bring you up to speed on its use and application for your industry—manuals, online tutorials, YouTube videos. How often, though, will the software vendor be available to work directly with you to optimize that software for your particular problem? Is it typical for the software vendor to have detailed knowledge not just of their product, but the particular problem you are trying to solve? How often will that vendor offer that detailed, industry-specific knowledge to help you use their software to solve a problem?

At Convergent Science, we not only supply our customers with our innovative CONVERGE CFD software, we work directly with our clients to help them apply CONVERGE in the most effective way to their particular engineering problems. By combining our deep knowledge of our software and of computational fluid dynamics in general with our clients’ understanding of their specific problems, we truly can solve the hard problems.

We at Convergent Science see long-term engineering collaborations with our clients as an indispensable part of our core product. It helps our users generate better results, and it helps our developers and applications engineers improve the modeling capabilities available in CONVERGE. Nearly half of our engineers work on the applications team, which directly supports our users. If you’re thinking about taking the plunge, you’ll be doing so hand-in-hand with subject matter experts in combustion modeling, numerical methods, practical engine development, and a myriad of other relevant topics.

Take, for example, a scenario where you, as a user, are faced with choosing the best physical models for the use in your simulation. It is a CFD truism that you must select appropriate numerics according to the physics, or you will generate physics based on your selection of numerics. That’s not wrong, but it’s not always very helpful. When you set up your case, you might need to choose one of a dozen turbulence models, one of two dozen flux limiter functions, one of more reaction mechanisms than I care to name… the design space is vast. CONVERGE’s example cases are a great starting point, but they may not address the subtleties of your specific case. It’s probably not practical for an organization or user to explore every last combination of case setup parameters, but that’s our bread and butter. With their detailed knowledge of this parameter space, our applications engineers can quickly guide you through case setup and help you select the most appropriate settings and models.

Here’s one example. A leading European automotive manufacturer had transitioned to CONVERGE. They were simulating NOx formation in a diesel engine, using the same physical models as they’d always used. Agreement with experimental measurements was, in a word, poor. Convergent Science applications engineers identified some case setup improvements, using physical models that the client was aware of but had never tested.

These setup improvements weren’t limited to maximizing out-of-the-box performance. They were a joint research effort. Convergent Science engineers applied real engineering knowledge to the problem. While running the client’s case on our local systems, Convergent Science engineers developed a hybrid reduced-order chemical mechanism for the client to improve the NOx formation prediction, without requiring a large and expensive mechanism set. Several setup iterations later, the simulated emissions were within the measurement tolerances of the experiment. The result of this collaboration was that the client had a predictive case setup that they applied to further studies, and Convergent Science had an improved chemistry mechanism that had been validated with experimental data.

The collaboration doesn’t end once the case is running. Because our engineers are highly experienced with and knowledgeable about both the numerical underpinnings of the software and with engine design, they can also help you interpret and understand the results.

For example, consider von Karman vortex shedding from a cylinder. Depending on tiny variations in the actual running of the case (different partitioning, machine truncation error, etc.), there will be a phase difference between two shedding cases. Which result is correct? Both, of course, are valid solutions of the Navier-Stokes equations. Both are correct. Complex engine simulations can display similar behavior (cycle-to-cycle variability), and our experienced and knowledgeable applications engineers can help you understand what you might be seeing. Sometimes what looks like the result of a setup error is physically correct and operationally important.

We see our applications team’s work as part of a true partnership, not just good customer support. The best way to improve our software and our understanding of challenging problems is to use our software to solve those problems! Every time we see simulated results trace through experimental data points, that’s another validation case. The aforementioned hybridized reduced-order chemical mechanism is a mechanism that we now recommend to clients as an example case. Our developers and applications engineers all benefit from this collaboration.

At Convergent Science, we don’t think of ourselves as your CFD vendor. We’re your CFD partner. Want to learn more? Please check out our Customer Experience page and don’t hesitate to get in touch.

How to select monitor points for profile plots in FloTHERM. Test drive FloTHERM FREE for 30 days in the cloud

Creating scenarios using the superpostion function in FloTHERM command center. Test drive FloTHERM FREE for 30 days in the cloud

Creating scenarios using the multiply variables function in FloTHERM command center. Test drive FloTHERM FREE for 30 days in the cloud.

Introduction to selecting input variables in the FloTHERM command center. Test drive FloTHERM FREE for 30 days in the cloud.

Viewing profile plots in FloTHERM V12. Test drive FloTHERM FREE for 30 days in the cloud

CONVERGE licenses to include complimentary Tecplot 360 license, creating powerful and seamless CFD and visualization.

BELLEVUE, WASHINGTON – May 31, 2018 – Tecplot is pleased to announce the formation of a new partnership with Convergent Science. As of June 1, each CONVERGE license will include a complimentary Tecplot license, giving CONVERGE users access to Tecplot 360’s powerful CFD visualization and analysis tools.

CONVERGE results in Tecplot 360 showing interior isosurface. See Tecplot for CONVERGE.

“We are very excited to be partnering with Convergent Science, a global leader in CFD,” says Tom Chan, President of Tecplot, Inc. “They have a great team and we look forward to working with Convergent Science to help their user base seamlessly use Tecplot 360 to better comprehend and communicate their CFD results.”

About Tecplot, Inc.

An operating company 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.

Tecplot visualization and analysis software allows customers using desktop computers and laptops to quickly analyze and understand information hidden in complex data, and communicate their results to others via professional images and animations. The company’s products are used by more than 47,000 technical professionals around the world.

Contact:
Margaret Connelly
Marketing Manager, Tecplot, Inc.
pr@tecplot.com
(425) 653-1200

About Convergent Science

Founded in 1997 in Madison, Wisconsin, Convergent Science is a global leader in computational fluid dynamics (CFD) software. Its customers include leading automotive and commercial vehicle manufacturers, tier one suppliers, and professional motorsport teams.

Its flagship product, CONVERGE, is an innovative CFD software with truly autonomous meshing capabilities that eliminate the grid generation bottleneck from the simulation process. CONVERGE is revolutionizing the CFD industry and shifting the paradigm toward predictive CFD.

Contact:
Tiffany Cook
Media & Partner Relations, Convergent Science
tiffany.cook@convergecfd.com
(830) 625-5005

Sizing Particles (Parcels) by Variable.

Video Script

In this example, we are using a CONVERGE data set with parcel information. We have previously colored the parcels by values of the film flag.

Sizing the parcels by a variable such as mass or number of particles can be done quite easily.

In the Zone Style dialog, select the zone that represents our parcels, here titled Particle. Right-click on Scatter Size and click Select variable… and select the variable to size by, in this case we’ll use dp_mass. Then, right-click again and select By: dp_mass.

The particles do not change size in this case because the scatter Symbol Shape is set to Point. We want to pick a scatter Symbol Shape that will represent size, so we choose Sphere. Now you can see different sizes. Tecplot 360 calculates a default size for the parcels. If you want to adjust the size of the parcels, right-click on Scatter Size and click Select variable… again. Here we can adjust the size particles multiplier.

That is how you change scatter symbols as associated with a size variable.

Thanks for watching!

Isolating Particles with Value Blanking

Video Script

The film flag is an integer with values from zero to five, which represent the different parcel properties. Shown here are the meanings for each film_flag integer value.

Film Flag Integer Values

Let’s open the Value Blanking dialog. Select the film flag variable, dp_film_flag.

We will first look at parcels that are in the wall film only. To do this, we remove all the values that are not equal to one. One being parcels that are in the wall film.

Then we toggle on Active and Include value blanking.

Now we see only the parcels that are in the wall film.

Next, we want to look at only the rebounded particles, which have a film flag value of two. We can do this by simply changing the value in the value blanking dialog to ‘2’. 

If you want an easier way to do this, you can use the Quick Macro Panel.

Seen here in the Quick Macro Panel we simply double-click on Show specific parcels, and enter the value for the parcels we want to display. This quick macro has a nice prompt to allow you to specify what you want to see and will adjust the Value Blanking settings for you.

Let’s take a closer look at the quick macro command, Show specific parcels. You can view and edit macros in any plain text editor.

We use a macro command, called PromptForTextString. This allows you to be prompted to enter text values. Zero for parcels not in a wall film, one for in a wall film, and so on.

 
Macro Command PromptForTextString

$!MacroFunction NAME = "Show specific parcels"
ShowInMacroPanel = TRUE
$!PromptForTextString |film_flag_value|
INSTRUCTIONS = "Enter the parcel type to display:\n0 = Parcel is not in wall film\n1 = Parcel is in wall film\n2 = Rebounded parcels\n3 = Splashed parcels\n4 = Separated parcels\n5 = Stripped parcels"

Below this are the constraints that we’ve set up, which you saw earlier in the Value Blanking dialog.

$!Blanking Value{Constraint 1 {Include = Yes}}
$!Blanking Value{Constraint 1 {VarA = 'dp_film_flag'}}
$!Blanking Value{Constraint 1 {RelOp = NotEqualTo}}
$!Blanking Value{Constraint 1 {ValueCutoff = |film_flag_value|}}
$!Blanking Value{ValueBlankCellMode = PrimaryValue}
$!Blanking Value{Include = Yes}
$!EndMacroFunction

And that is how you can easily isolate particles based on the film flag.

Thank you for watching!

CONVERGE post_convert Utility

Before I dive into the Tecplot 360 demo, I want make a statement about the post_convert utility. Convergent Science has put a nice bit of effort into post_convert. An update to post_convert was released in early March (2018), which does a really great job with the Tecplot format. So if you are running CONVERGE and have tried Tecplot 360 in the past or the Tecplot output from post_convert, please do give it a try again. They’ve done a really great job with the tool.

Tecplot 360 Tour

We will jump into Tecplot 360, and for those of you who have not seen Tecplot 360 before, I’ll give you a quick tour. When you first start Tecplot 360, you have what we call the Welcome Screen, with links to all of our documentation, online resources and version number at the bottom. On the left side, we call this the Plot Sidebar, which we will have more information about once I load a data set. We also have Pages. Think of Pages like a worksheet in Excel or a tab in Chrome. You can have multiple Pages in Tecplot 360.

We have here what we call our Quick Macro Panel, so if you have any custom scripts that you want to run, you can access them very easily. Then down here, Probing. If you need to find information about your data set, it is available using the Probe Tool.

Loading Cell-Averaged Output Files

We will start with loading a cell-averaged output file, emissions.out. To open this file, we are going to use our General Text Loader. We will select it to instruct Tecplot to use that specific loader. Now, we are presented with the user interface. This is a very general loader for any type of text file. What is really important here is to understand what that text file looks like in order to populate it with the proper instructions. Watch our video tutorial on the General Text Loader.

I’ll bring up Notepad++ with emissions.out. The important points on this file are the variables.

• Variables are listed on line 3.
• The data is listed on line 6 and goes through the end of the file.
• On the variable line, we have this hash mark that we need ignore.

Those are the three key points for loading this data. For those of you who have not run CONVERGE before, these .out files are produced as part of the run. Each one of these would represent an iteration of the solver.

• We will go into variables and we will say that variables start and end on line 3.
• In the data tab, we have this set up to start on line 6 and go through the end of the file.
• In general data filters, we are going to say ignore columns in position 1. That is how we ignore the hash mark.

If I want specific variables to load, I can go back into that variables dialog and say select variables to load. Here, let’s just load crank, NOx, and carbon monoxide.

Line Map

Now we have our plot. You can see that we only have NOx on the y-axis. To see the carbon monoxide, you go into what we call the Mapping Style dialog. We can see that we have what Tecplot calls a Line Map. We will just activate this. It is off the screen, so I’ll do a CTRL-F to fit. This is also available under View > Fit to Full Size. Now, we can see my entire data set.

What I really want to do here is to compare this against another run. Let’s go ahead and append another data set. We will go to Run 2. Again, we will look for emissions.out. We will open this and we will say Append Data to Active Frame. All of these settings have been retained, except for this one. We will go back and we will say I just want crank, NOx, and carbon monoxide.

Line Plots

Now the data has been loaded, but it does not show up. Let us find out where it went. We go into Data > Data Set Info. This is a key dialog in Tecplot 360. It tells you all about the data that you have loaded. We see that we have Zone 1 and Zone 1. This is from our first run, so we will just double click on this and say Run 1. We will double click on my second zone and say Run 2. That way we can identify these and we can see the differences. Run 1 we did 8,200 iterations, Run 2 a little over 12,000.

To get these to display, we will go into the Mapping Style dialog. We will select these two maps. We can copy them. But, we now want these to point to Run 2. We will display those. Now, we can see both Run 1 and Run 2 here, but we can’t quite tell them apart. Let’s add a legend (Plot > Line Legend, check Show Line Legend). Then, we will rename these to include the zone name to help identify them. Then, finally, we will give Run 1 symbols that are a Delta and a Gradient. We can turn on the symbols. Because there were so many iterations, the symbols are quite dense. We can set up the symbol spacing. I like my symbols a little smaller and filled with the line color. Now, we have a really nice plot showing the differences between Run 1 and Run 2.

What I’m really trying to get across here, in this plot, is that Tecplot gives you a lot of control over line plots. It helps you create nice production quality plots that you can be proud of when you put them into a paper or communicate with your colleagues. If you do need to share this outside of Tecplot, we do have some very nice export tools. In particular, for line plots, using the vector-based outputs such PostScript or WMF make really, really nice plots when you put those into papers or into PowerPoint.

That covers line plots. We will just rename this page here to Emission. Let’s add a new page and load some additional data. Here we are going to move onto working with parcel information.

We will go back into Run 1 and the output folder. We are going to select our Tecplot Data Loader. I have already run post_convert to convert the CONVERGE output to Tecplot format. We can just select all of these and hit open. You see that the files opened fairly quickly. What does this represent here? If we go to the Data > Data Set Info, we have a total of 93 million elements spread over about 145 time steps. Quite a lot of data loaded very quickly into Tecplot.

Solution Time Is Crank Angle

You’ll notice that one of the nice things that Convergent Science has done with post_convert utility is solution time is actually your crank angle. One of the first things that users have asked me is, “How do I get that crank angle on the plot?” A simple way to do that is using our Text Insert Tool (). We have what we call dynamic text. We will just type CA:&(SOLUTIONTIME). As we step through, you can see this updates. Now, the formatting is a little bit longer than I want, so we can do some formatting here to shorten the string. Quite a lot of flexibility in how you can add text and format it.

Macros and Customizing Workflows

I talked about macros and customizing. If you don’t want to have to remember everything, you can register a macro on our Quick Macro Panel here. I can just double click. You can see that added a piece of text. If you’re doing some of these actions all the time, using this Quick Macro Panel can be really nice way to customize your workflows. Watch the video tutorial on Quick Macros.

Parcels

On to parcels. In order to display parcels, we need to turn on our scatter layer. By default, scatters are turned on for all of our zones. To show scatters for the spray, go into the Zone Style dialog where all of the style settings about your data are set. Select all of our zones except for spray, then turn off scatter. It is left on just for spray. Let’s change this to scatter Points. Points render quite quickly and allow you to see all of your spray quite nicely. We will turn on scatter and we will advance time to where the spray is coming in. We can turn on Translucency and you can see the interior.

Understanding Attributes of Spray

This is quickly how you display scatter, but let’s say you want to understand some of the attributes of your spray. Let’s look at the DP_film_flag. This describes some attributes about your spray: whether it is in the wall film, whether it is in the volume, whether it is a rebounded parcel, etc. We can do that by turning on contour coloring. We will go here into Contour Details dialog and we will set up our contour coloring to use this DP_film_flag. See the video tutorial on Displaying Spray.

Color Maps

We know that CONVERGE uses the values from 0 to 5 to represent the film flag. We will say that we want levels from 0 to 5. Then, we will go back into the Zone Style dialog and we will tell this to use my contour group. Now, we can see the different coloring. If we want some more distinct coloring, we can choose a different color map. Qualitative Dark 2 works pretty nicely. You can see zero represents the parcels that are not in the wall film, blue now represents ones that are in the wall film. You can see how those change as you animate through your data set.

This is a really nice way to look at parcels and understand them.

Isolating Parcels with Value Blanking

Another thing you may want to do is isolate a certain set of parcels. Here we have quite a number of them. If I want to look at just the ones that are in the wall film, I can use what we call Value Blanking (Plot > Blanking > Value Blanking…). We will go into the Value Blanking dialog and we will select our DP_film_flag variable. We will say that we want value blanking to be included when it is not equal to zero. This is going to isolate just a single set of my parcels.

I can automate this in the Quick Macro Panel. We have a macro command called Prompt for Text String. Here I want to look at just the parcels that are in the wall film. The Quick Macro has adjusted that value blanking capability for me. We will rename this page to Spray.

Slices

We will add yet another page. Here we will just flip to 3D (In the Plot Sidebar, select 3D Cartesian). Doing this has shared the data set with the previous page. We have not actually loaded another data set, and are using shared memory in this case. It keeps Tecplot’s memory footprint quite low.

Now, we will look at using slices. To add a slice, it is quite easy. We have a Slice Tool () here. You can just click and place it. You can see that it slices inside the volume. Again, on our Quick Macro Panel, double click Clip Above Primary Slice to see what the slice looks like. All of the macros on the Quick Macro Panel are custom for this webinar. We will be sure to share out these items after the webinar. What I want to look at now is temperature. A nice way to do this is to simply double click on the Legend and then, we can just change it to temperature. A color map that I enjoy using is one called Viridis. This is not built into Tecplot yet, but you can incorporate your own color maps through the Import Color Maps, which is what I’ve done here.

I want to know what contour range to use here. Again, we will plot our maximum contour value over time. Our current contour value is temperature. I can simply double click on the quick macro, Plot Max Contour Over Time. You can see that we are advancing through time. The macro has just created a line plot showing the maximum temperature for my data set through time. You can see that prior to the combustion phase, temperature is fairly low. Let’s choose a contour range here of about … let’s use the Probe Tool() to find the range of temperatures. The temperature here is about 1200 and here it is about 2800. We will adjust our contour levels to about that range. We will say from 1000 to 3000.

Plot Layout Flexibility

Tecplot gives you a lot of flexibility in how you want the layout of your frame. What I have here is a multi-frame layout, multi-page layout. I like this view of my data.

One of the important things for people using CONVERGE is that it uses an adaptive mesh refinement. The first time you will see your mesh is when you bring in your data. If you want to put a mesh on your slice, you can see what the mesh that CONVERGE has created looks like. If we get a little bit closer to crank angle zero, where combustion is occurring, you can see how CONVERGE has refined that mesh and what a nice job it is done.

Multi-Frame and Multi-Page Layouts

Let’s create another view. I’ll just do a CTRL-C, CTRL-V, so now I have copied my frame. We will drag it over here. Now I have two frames of the same data, but let’s create a different view. Here I want to disable my clipping plane and I want to put my slice in a different position. I want to get it aligned right here with the valve. We will choose the Slice Tool again. I’m going to hit Y on the keyboard to make it Y-aligned. You can see how we got it aligned with the valves. Then, we will just put it in a planar position, turn off shade, and now I can see my slice in this position here. We will go ahead and animate. Now these frames are all linked through time.

This is a really nice way to create a multi-frame layout that communicates a lot about your data very quickly. I can really create a nice story to share with colleagues or communicate to my manager.

Animation and Movie File Export

If I do need to save this out as a movie file, I can do that quite easily as well. Right here in solution time controls, I can go into details and just click on this film icon and select a couple of different movie formats. MPEG-4, AVI are probably your best bets for the movie formats. Antialiasing with a super sample factor of three makes for really nice, crisp lines and really nice, crisp text. You can also enter the width.

Let me just show you an animation that I produced with an earlier layout. As you can see here, nice looking animation, nice, crisp text, and a great way to communicate your data, especially when you’re dealing with this transient data that are produced by these internal combustion cases.

Isosurfaces

I have not hit isosurfaces or streamlines yet. I’ll just briefly talk about them. Isosurfaces are set up, again, through what we call the derived objects. A derived object is something that is created from your volume data. We can simply go into Isosurfaces > Details. One thing that often times can be difficult is figuring out what is a good value for my isosurface. That is where the Probe Tool comes in nicely. You can see that we have a color band change here. We can click right on that and see our temperature. It is 1265, give or take. We can use that value for my isosurfaces.

Let me disable clipping. We will turn on Translucency and let’s make that even more translucent. We will go into Zone Style > Effects tab and say 90 percent translucent. Now, you can see your isosurface in that volume more clearly. Using the Probe Tool is a great way to figure out a good candidate value for isosurfaces.

Streamtraces

We have a couple of different types streamtraces (Streamtraces Details dialog).  Volume Line is a line that is going to go through your volume. Volume Rods and Volume Ribbons are also very nice ways to display your streamlines. Let’s grab a ribbon and we will place a streamline right here. It is very easy to place streamlines in your data set just with point and click. If you have very specific locations, you can also define those by entering X, Y, Z positions, etc. Watch the video tutorial on Streamtraces on a Slice.

Python

I’ve shown a couple of these capabilities that we put on the Quick Macro Panel. With the Python toolkits, PyQt, you can actually create custom user interfaces. Here, it took me about a few hours to write this custom user interface using the Python language. This has a lot of these capabilities that you have right here on the Quick Macro Panel as well. Again, if I want to show the crank angle or show RPM, just single click. If I want to jump to a specific crank angle, I can do that right here. Really, I’m centralizing a lot of the capabilities that you as a CONVERGE user might need in one nice easy to use dialog using the Python language.

Learn more about working with CONVERGE results

Tecplot 360 Basics: Data Alter (Specify Equations).

Video Script

In Tecplot equation syntax, creating a new variable or referencing a variable by name requires surrounding it in curly braces. However, variables on the right side of equations may be referenced by two other methods:

First by the variable index. Or secondly, if they are defined as Tecplot’s assigned variables axis or velocity components, in this case u and v. This indicates Tecplot should use whatever variable is assigned to the u and v vector component variables.

Additionally, common mathematical functionality such as SIN, COS, SQRT and other common mathematical operands are available in the equation syntax. Notably, squared or second power is indicated by double star.

For our velocity magnitude calculation, all three of these equations will achieve the same result.

{Vmag} = sqrt({X Velocity}**2 + {Y Velocity}**2)
{Vmag} = sqrt(V4**2 + V7**2)
{Vmag} = sqrt(u**2 + v**2)

If you would like to learn additional capabilities and examples of the Specify Equations dialog, check out previous tutorial videos:

• Comparing Grids in Tecplot 360
• Data Alter using If Conditions
• Comparing a CFD solution with Experimental Data

Tecplot General Text Loader.

Video Script

To do this we will use the General Text Loader, which is one of several text data loaders in Tecplot 360. The General Text Loader, by default, only identifies files with a .txt extension.

The first thing we want to do when we load our data (File > Load Data) is to select All Supported Files or All Files.

Next we select the emissions.out file, and instruct Tecplot to use the General Text Loader. This will be a slightly different workflow on Linux but it is very similar. Now we will go ahead and click Open.

Open the Output File

Now, we will need to instruct the General Text Loader on some of the attributes of our data file. Open the output file (emissions.out) in any general text editor.

We can see that line 3 starts with a hash mark. The hash mark is interpreted as a comment, and we will show you how to process this.

Line 3 lists our variable names.

Line 6 is where our data starts and the data goes all the way to the end of the file. And those are the three bits of information that we need to know to load this dataset.

1. First we will tell the General Text Loader where to look for the variable names, which again are on line 3.
2. We will tell the loader where to find the data, which starts on line 6 and goes through to the end of the file.
3. And then under General Filters we will tell it to ignore information in column number 1, which is where we saw the hash mark on line 3.

Scan for Errors

To scan for errors, select View Processed Data and Scan File. This is a check to confirm that the loader picked up all of the information about our data and variables, and there were no errors reported.

Click OK and now our data is loaded into Tecplot 360.

Our variables of interest are NOx and carbon monoxide. To view them, open the Mapping Style dialog.

Line Maps

Tecplot 360 automatically creates Line Maps only for the first variable in our file, and not for any other variables in the file. But we want to look at NOx and carbon monoxide, so we will deselect the first variable and select NOx and carbon monoxide. Then we can close the Mapping Style dialog.

To fit the data, click Ctrl+F. Now we can see the two line maps. We also see that they have very different scales.

We want to choose a separate scale for carbon monoxide. To do this, open the Mapping Style dialog, select the carbon monoxide row, right click on the Which Y-Axis column, and select Y2. This puts carbon monoxide on our secondary axis. Now click Ctrl+F to fit carbon monoxide on the new axis. We now see that the data are scaled similarly but with different values. We can also adjust the label layout by choosing the Adjust Tool and moving the labels where we want them.

To associate the line plots with their respective axes, we can color the axis to match the color of the line plot. If we open the Mapping Style dialog and click the Lines tab, we see that the pink line is carbon monoxide.

To color the Y2 axis, right-click on it to open the Axis Details dialog. Select Y2 and the Line tab, and choose the Color to match the line plot. Now we can see which line plot is associated with which axis.

Additionally, we can toggle on the Line Legend to see the mapping for each plotted line.

Learn more about working with CONVERGE results

The post Quick update on PTC + Rockwell appeared first on Schnitger Corporation.

The post Hexagon snaps up SPRING’s NCSIMUL for machining appeared first on Schnitger Corporation.

The post HxGN LIVE merges old and new, urges epic leaps forward appeared first on Schnitger Corporation.

The post Nemetschek NEVARIS addresses SMB construction with acquisition appeared first on Schnitger Corporation.

The post DS takes majority position in Centric Software appeared first on Schnitger Corporation.

The post Quickie: Historic AVEVA surged in FY18 appeared first on Schnitger Corporation.