Case Data Analysis Tool for Powerflow

Case Data Analysis Tool for PowerFLOW

Dassault Syst`emes- SIMULIA PowerFLOW R

GUILLERMO D´IAZ VAZQUEZ´

Master’s Degree Project Stockholm, Sweden June 2019

Case Data Analysis Tool for PowerFLOW

Dassault Syst`emes- SIMULIA PowerFLOW R

Guillermo D´ıazV´azquez

Master’s Degree Thesis Project MSc in Aerospace Engineering

Academic supervisor and examiner: Evelyn Otero

KTH Royal Institute of Technology Department of Aerospace Engineering Stockholm, Sweden, 114 28 URL: https://www.kth.se/en

ii Abstract

The field of computational fluid dynamics (CFD) is exponentially growing in terms of performance, robustness, and applications. The expansion of CFD also means more users and more simulations, which translates into more human errors and mistakes in the simulation set up. Because the simulation set up should be the correct in order to accurately reproduce the desired phenomenon, such errors must be mitigated in order to increase the reliability and robustness of the simulations. In this project a tool has been developed to tackle this issue, within the CFD software SIMULIA PowerFLOW. The tool extracts and analyzes the data of the cases before simulation, reporting the results to the user for error detection. The present work aims to present the implementation, the application and the benefits of the designed tool.

iii Referat

Case Data Analysverktyg f¨orPowerFLOW

Strömningsmekaniska beräkningar(CFD) omr˚adetväxerexponentiellt med avseende p˚aprestanda, robusthet och tillämpningar. Expansionen av CFD bidrar även till fler användareoch simuleringar, vilket i sin tur leder till fler mänskligafel och misstag i uppsättningenav simuleringar. Eftersom simuler- ingsuppsättningenbehöver vara korrekt föratt ˚aterskapa önskade fenomen, behöver s˚adanafel undvikas föratt kunna öka simuleringens tillförlitlighet och robusthet. Med avseende p˚adetta utvecklades ett verktyg i CFD mjuk- varan SIMULIA PowerFLOW. Verktyget extraherar och analyserar inställnin- garna föresimulering och rapporterar resultaten till användaren förfeldetek- tering. Det härarbetet redogörförutvecklingen, tillämpningenoch fördelarna med framställdaverktyget.

iv Acknowledgements

Firstly, I would like to thank Evelyn Otero for taking the role as my supervisor and examiner, for the careful follow up of my work, and for the eﬀort placed in increasing the quality of this project by giving me an outstanding feedback. I would also like to express my gratitude to the entire SIMULIA team in Stuttgart for their patience and help. In particular to Monti Indro for welcoming into his team. To Matthieu Plagnard for his support, guid- ance and supervision throughout the whole project. Additionally, to Filippo Boscolo for his technical assistance and continuous cooperation. Finally, I am thankfull for the unconditional support and motivation of my family and my girlfriend, Patricia.

v Contents

1 Introduction 1

2 Background 3 2.1 Dassault Syst`emes ...... 3 2.1.1 Field Oﬃce Stuttgart ...... 4 2.2 SIMULIA PowerFLOW Suite ...... 5 2.3 PowerFLOW background ...... 7 2.3.1 Navier-Stokes Equations and Continuum Theory . . . .7 2.3.2 Lattice Boltzmann Method ...... 9 2.3.3 Contrast of PowerFLOW and Traditional CFD . . . . 12

3 Tool Implementation 15 3.1 Background and Motivation ...... 15 3.2 Project Statement ...... 16 3.3 Methodology ...... 16 3.3.1 Tool Workﬂow ...... 17 3.3.2 Features and Content Generated ...... 18 3.4 Project Management ...... 20

4 Results 22 4.1 Python Routines ...... 22 4.1.1 Routines Common Sections ...... 22 4.1.2 Routine: CdiCheck.py ...... 23 4.1.3 Routine: CdiComp.py ...... 24 4.2 PowerINSIGHT ...... 26 4.2.1 File: CaseData AnalysisTool.pins ...... 26 4.3 Tool Evaluation ...... 26 4.3.1 CDI Check results ...... 27 4.3.2 CDI Comparison results ...... 36

5 Discussion 44

vi List of Figures

2.1 ”The 3D EXPERIENCE Platform” logo and its brands [12] .4 2.2 SIMULIA PowerFLOW suite [9] ...... 5 2.3 D3Q19 Model ...... 11 2.4 Overview of one cycle of the LB algorithm. The dark grey boxes show sub-steps that are necessary for the evolution of the solution. The lighter grey box indicates the optional output step. The lighter grey box has macroscopic ﬁelds to be written to the hard disk for visualisation or post-processing. [8] 12 2.5 NSM and LBM overview ...... 13

3.1 Case Data Analysis Tool workﬂow ...... 17 3.2 Case Data Analysis Tool PowerINSIGHT tree ...... 19

4.1 Case Data Analysis Tool Content Tree in PowerINSIGHT . . . 27 4.2 NAS Overview: EV12 Baseline ...... 28 4.3 Files in CDI and NOT in storage: EV12 Baseline ...... 28 4.4 Open Shells: EV12 Baseline ...... 29 4.5 Case Variables: EV12 Baseline ...... 29 4.6 Case Method Overview: EV12 Baseline ...... 30 4.7 VR07 Viewpoint: Ground-ISO EV12 Baseline ...... 30 4.8 VR08 Viewpoint: Ground-ISO EV12 Baseline ...... 30 4.9 VR09 Viewpoint: Ground-ISO EV12 Baseline ...... 30 4.10 Body Viewpoint: Ground-Front EV12 Baseline ...... 31 4.11 Body Viewpoint: Ground-ISO EV12 Baseline ...... 31 4.12 Body Viewpoint: Ground-Left EV12 Baseline ...... 31 4.13 Body Viewpoint: Ground-Top EV12 Baseline ...... 31 4.14 Engine Viewpoint: Ground-ISO EV12 Baseline ...... 31 4.15 Suspension Viewpoint: Ground-ISO EV12 Baseline ...... 31 4.16 Wheels Viewpoint: Ground-ISO EV12 Baseline ...... 32 4.17 Subsystems Viewpoint: Ground-Top EV12 Baseline ...... 32 4.18 NAS Overview: EV12 Variant ...... 32

vii Chapter 0

4.19 Files in CDI and NOT in Storage: EV12 Variant ...... 33 4.20 Files in Storage and NOT in CDI: EV12 Variant ...... 33 4.21 Name-Matching Files BUT Different Times: EV12 Variant . . 33 4.22 Open Shells: EV12 Variant ...... 34 4.23 Case Variables: EV12 Variant ...... 34 4.24 Case Method Overview: EV12 Variant ...... 35 4.25 VR07 Viewpoint: Ground-ISO EV12 Variant ...... 35 4.26 VR08 Viewpoint: Ground-ISO EV12 Variant ...... 35 4.27 VR09 Viewpoint: Ground-ISO EV12 Variant ...... 35 4.28 VR10 Viewpoint: Ground-ISO EV12 Variant ...... 35 4.29 Body Viewpoint: Ground-Front EV12 Variant ...... 36 4.30 Engine Viewpoint: Ground-ISO EV12 Variant ...... 36 4.31 Suspension Viewpoint: Ground-ISO EV12 Variant ...... 36 4.32 Wheels Viewpoint: Ground-ISO EV12 Variant ...... 36 4.33 Parts Analysis Overview ...... 37 4.34 Parts in Variant and NOT in Baseline ...... 37 4.35 Different Position Only ...... 38 4.36 Different Area and Position ...... 38 4.37 Faces Analysis Overview ...... 38 4.38 Faces in Variant and NOT in Baseline ...... 39 4.39 Faces with Different Area ...... 39 4.40 Case Analysis Overview ...... 40 4.41 Different Value or Unit Variables ...... 40 4.42 Percentage Difference ...... 41 4.43 VR10 Viewpoint: Ground-ISO EV12 Comparison ...... 41 4.44 VR10 Viewpoint: Ground-Left EV12 Comparison ...... 41 4.45 VR09 Viewpoint: Ground-Front EV12 Comparison ...... 42 4.46 VR09 Viewpoint: Ground-ISO EV12 Comparison ...... 42 4.47 Body Viewpoint: Ground-ISO EV12 Comparison ...... 42 4.48 Body Viewpoint: Ground-Front EV12 Comparison ...... 42 4.49 Engine Viewpoint: Ground-ISO EV12 Comparison ...... 43 4.50 Engine Viewpoint: Ground-Front EV12 Comparison ...... 43

viii Nomenclature

CFD - Computational Fluid Dynamics CAE - Computer Aided Engineering P LM - Product Lifecyle Management CAM - Computer Aided Manufacturing CAD - Computer Aided Design VR - Reﬁnement Regions N-S - Navier-Stokes LBM - Lattice Boltzmann Method PDE - Partial Diﬀerential Equation PF - SIMULIA PowerFLOW PI - SIMULIA PowerINSIGHT PV - SIMULIA PowerVIZ OS - Operating System LRF - Local Rotating Frame CDAT - Case Data Analysis Tool CSV - Comma-Separated Values PNG - Portable Network Graphics BB - Bounding Box

ix Symbols

∇· - Divergence ∂ - Partial derivative D Dt - Material Derivative ρ - Density p - Pressure q - Heat ﬂux v - Flow velocity τ 0 - Stress tensor e - Internal energy s - Entropy T - Temperature R - Speciﬁc gas constant

x Chapter 1

Introduction

The automotive industry encompasses a wide range of companies and organi- zations which are involved in the design, analysis and manufacturing of motor vehicles [2]. This industry generates one of the world largest revenue mar- kets. Just the top ten companies accumulated revenue of 1.64 trillion U.S. dollars in 2017 [11], producing more than 97 million vehicles in the same year [5]. The automotive industry is constantly evolving, seeking to fulfill customer needs and requests as well as imposed regulations for fuel efficiency, quality, functionality and cost. Manufacturers must carefully trade-off between those values when designing a product. Time is a very critical factor in the development of a product, and automobiles are not an exception. En- gineers need to understand the design compromises either very early in the process or very quickly in order to reduce costs and time, to deliver the best compelling products. Nowadays, such early feedback can be achieved with computer-aided engineering software due to their current levels of accuracy. In the field of CAD and PLM software, Dassault Systèmesis a world leader due to its vast portfolio of products as well as their quality, functionality and performance. Among its brands, SIMULIA focuses in software for virtual testing and realistic simulations of different fields. Within SIMU- LIA, the area of CFD is covered by the software conglomerated under the name of PowerFLOW. It is a unique CFD software, considering it is based on inherently transient Lattice Boltzmann physics, which differs from the conventional Navier-Stokes equations solvers. The ability to simulate transient complex shapes, true rotating geometry, wind tunnel conditions, couple simulations with thermal and aeroacoustic analysis, along with parallelization for quick turn-around times makes it the preferred CFD software in the automobile industry. Experienced engineers are based in strategically located field offices to provide fluid flow simulation and consulting services. This study was performed in one of the aforementioned offices located in

1 Chapter 1

Stuttgart, Germany. This thesis is determined to provide a deeper knowledge of the physics behind the CFD software PowerFLOW and how to employ it in real-world fluid dynamic problems. It is also intended to materialize the development and application of the performed project. The ambition of the project is to design a tool that will tackle the growing issue of human errors during the simulation set up in PowerFLOW. This is a very important factor to take into account when a phenomenon has to be simulated. The tool should be designed to add a layer of assurance and confidence in the cases ready to be simulated. To develop it, the programming language Python in combination with SIMULIA PowerINSIGHT will be used. The tool will extract the desired data from the simulation case files, will process this data and display it in an organized and user-friendly manner. This way user errors and mistakes can be easily found, and undesired differences between case runs discovered. With this tool, fail simulations and wrong results will decrease, time and costs will be reduced and more importantly results will be more reliable and robust. The report will start with a background review. This section will first introduce the company Dassault Systèmes,their software suite PowerFLOW and the field office in Stuttgart. Then, it will cover the theory behind Pow- erFLOW, the Lattice Boltzmann method. The next section, will present the problem to be tackled, the proposed solution and the methodology used. Then, the results are exposed with an inside explanation of the designed tool and actual tool evaluation. The report will finish with a discussion of the results and future work.

2 Chapter 2

Background

This section will provide with a brief background of Dassault Syst`emes,its branch SIMULIA, the software suit PowerFLOW and more important the theory behind it, the Lattice-Boltzmann method (LBM).

2.1 Dassault Syst`emes

Dassault Systèmes,known as ”the 3DSEXPERIENCE Company”, is a Euro- pean software company subsidiary of Dassault Group and with headquarters in France. It was created in 1981 to develop a new CAD software called CA- TIA. The software became well received by the industry, which positioned Dassault as a leader in the field, allowing it to grow and expand. New software were developed or acquired, and by the end of the 20th century the describing term CAD/CAM had become too restrictive to be identified with its products. The acronym PLM, which stands for Product Lifecycle Manage- ment, covers more accurately the portfolio of products offered. The branches that comprise Dassault Systèmes’PLM products are DELMIA for manufacturing, ENOVIA to support internal and external collaboration, SIMULIA for analysis and simulation, SolidWorks for 3D modeling and 3DVIA for 3D visualization. [12] [1] Nowadays, Dassault resources are focused on the development of its most important business, a software platform that comprises all its branches, called ”The 3D EXPERIENCE Platform”. It aims to provide software solutions for every possible area of operations, from marketing to engineering, for any company or organization. The logo with its macro-areas and its respective software suits are illustrated in Figure 2.1. As of 2018, the company has a staff of more than 16000 employees over 100 countries, with annual revenue of 3 billion U.S. dollars. Dassault’s revenue

3 Chapter 2

Figure 2.1: ”The 3D EXPERIENCE Platform” logo and its brands [12] originates from selling permanent or temporal licensed to specific products or to the whole 3D Experience. This was usually done on the customer site computer, however, the same software is more and more being licensed through the 3DS Cloud instead. In addition, support and training are pro- vided for any customer and offered tool. Such business requires to have experience engineers strategically based in field offices around the world to provide customer consultancy services.

2.1.1 Field Office Stuttgart The project covered in this report was carried out at one of the aforementioned field offices, in this case, located in Stuttgart, Germany. The city of Stuttgart was selected for its large automotive industry, having the headquarters of Daimler and Porche. The office hosts three different teams with different functions. There is a small software group in charge of the Pow- erVIZ development, a sub-program of PowerFLOW. There is an aerospace team that focuses on turbine engine aeroacoustics. Finally, the biggest team is the automotive one, whose scope is the automotive industry in Germany, Italy and Sweden. The automotive, as well as the aerospace team, are composed of application engineers who are in charge of the service aspect of the company’s software. The goal is to promote and sell licenses if possible but more important to provide technical support and consultancy services to customers. The technical support aspect covers from training to assistance as well as advice with issues, discrepancies and best practices. Complete projects that span from the customer initial geometry to simulation results and comparison

4 Chapter 2 studies are also carried out often.

2.2 SIMULIA PowerFLOW Suite

The SIMULIA brand was created in 2005 with the acquisition of Abacus Inc. Since then, Dassault has acquired other state-of-the-art simulation tools to create a complete portfolio ranging from electromagnetic to structural analysis as well as CFD. The latest acquisition, in 2017, was Exa Corporation, which brought the CFD software suit PowerFLOW into SIMULIA. PowerFLOW is a CAE software suit employed in aerodynamics, thermal and aeroacoustic simulations. It is a well-established tool in the automobile industry, but quite new in the aeronautical field. However, in this latter field, its usage is growing exponentially. The suite consists of nine individual computer programs, each one devoted to a specific stage of the simulation, as shown in Figure 2.2.

Figure 2.2: SIMULIA PowerFLOW suite [9]

Once the CAD geometry is acquired, the pre-processing stage is initiated with PowerDELTA. This program is responsible to prepare the geometry,

5 Chapter 2 removing CAD defects, making it watertight and then meshing it. Pow- erDELTA is also used to modify the model, wrap complex geometries, perform quality repairs and morphing among others. Afterward, the data is exported as ”.stl” or ”.nas” to the next program, PowerCASE. As its name suggests, it is responsible for the case setup, where the desired simulation conditions are assigned. The main parameters have to be defined such as the boundary conditions and the refinement of the VR regions. The VR regions are predefined volumes around the geometry used to refine the discretization in critical regions. Templates are used to facilitate and speed up the case setting based on best practices. Once the case is finalized and ready, it is saved in a ”.cdi” format. The CDI1 file contains all the necessary information for the simulation. [9] In the second stage, which is the core of the simulation process, the computational domain is actually discretized and the Lattice Boltzmann equations are numerically solved for a given lattice by PowerFLOW, which is the main solver. PowerFLOW offers solutions for aerodynamic efficiency, driving dynamics, vehicle handling, water management and panel deformation. If the sought application is thermal management and climate control of surfaces temperature and heat fluxes, a conduction and radiation solver, PowerTHERM, is coupled with PowerFLOW. PowerTHERM allows to predict under-body and engine thermal protection, brake cooling, electronics and battery cooling, HVAC system performance, cabin comfort, defrost and demist among some. The third additional solver, PowerCOOL, can also be coupled to predict the heat transferred between the airflow calculated by PowerFLOW and heat exchangers as the car engine, the radiator or a con- denser. [9] At last, the post-processing stage uses the software available to display the results. The main program, PowerVIZ, is in charge to interpret the results from the solver into flow parameters and 3D visualization solutions. It provides a wide range of capabilities including volume, fluid and surface measurement and visualization, quantitative analysis, particle tracking, rendering and animations. The second post-processing program, PowerINSIGHT, aims to automatize the simulation analysis and result generation to efficiently ac- celerate the overall engineering process towards conclusions. Aeroacoustic inquires are processed with PowerACOUSTICS, while photo-realistic engineering and design are carried out with PowerREALITY. [9]

1The CDI is the name used to refer to the compiled case ﬁle in ”.cdi” format containing all the simulation data.

6 Chapter 2

2.3 PowerFLOW background

In the early 1990s, the testing of the Lattice Boltzmann method reached solutions equivalent to the classical approach based on the Navier-Stokes equations. This theoretical proof laid the foundation for the company’s DIGITAL PHYSICS technology to be based on the LBM. The motivation behind the development and the spread of this new method are the unsolved issues and diﬃculties with the traditional CFD approach as well as the LBM numerous advantages. Some of the advantages are being inherently transient which allows to simulate time-dependent phenomena, which are numerically stable and highly accurate for complex geometries [10]. To reach insightful knowledge of the novelty brought by LBM, as well as to understand the diﬀerences with respect to the classic Navier-Stokes method, a theory portrayal for both approaches is exposed in the following sections.

2.3.1 Navier-Stokes Equations and Continuum Theory Classic fluid dynamics focuses in the macroscopic phenomena of the fluid behavior where fluids are described as a continuum, which means treating them as continuous blobs of matter. The Navier-Stokes (N-S) equations, named after Claude-Louis Navier and George Gabriel Stokes, describe the motion of viscous fluid substances based on the premise that fluid is a continuum. They are derived from the conservation laws: Conservation of mass or continuity, conservation of momentum or Newton’s second law and conservation of energy or the first law of thermodynamics. The conservation equations describe the variation with time of the amount of mass, momentum and energy contained in a fluid volume Vf (t) delimited by a closed surface Σf (t) [6]. These equations in the integral form are only useful for simple cases with many simplifications. They are not suitable when one is interested in computing the local properties of the flow. For that purpose, they must be transformed using Gauss formula to express the rate balances locally based on fluid elements. The continuity equation (2.1), states that the addition of the rate of local density variation and the rate of mass loss by convective outflow equals zero [6]. It is a PDE that reflects the conservation of mass. ∂ρ + ∇ · (ρv) = 0 (2.1) ∂t An alternative expression of the continuity equation (2.2) can be interpreted as the variation of the density following the fluid particle being ex-

7 Chapter 2 clusively due to the rate of volume variation [6]. The material derivative denotes the rate of change as the fluid elements move rather than the rate of change at a fixed point in space. 1 Dρ = −∇ · v (2.2) ρ Dt The incompressible momentum equation (2.3) can be interpreted as representation of Newton’s second law expressed per unit volume of fluid [6]. The right-hand side of the equation has the contribution of forces acting on the fluid, which can be differentiated in body and surface forces. Body forces f m act over the whole volume of the body as gravity or magnetic fields. Surface forces on the other hand act over the surface. Normal surface forces, in this case, are the divergence of the pressure ∇p, while the shear is represented by the stress tensor component ∇ · τ 0. Dv ρ = −∇p + ∇ · τ 0 + ρf (2.3) Dt m At this point, there are four equations, one from continuity and three from each spatial component in the momentum equation, but there are five unknowns (v, p, ρ) making an unsolvable system. To resolve it an extra equation is necessary. The usual approach adds the conservation of energy equation, also known as energy equation (2.4). It shows clearly how the rate of variation of internal energy is related to the heat addition and the surface forces deformation work rate. The compression work, represented by −p∇ · v, is reversible and increases the internal energy when the compression work reduces the fluid volume. The term φv accounts for the deformation work done by viscous forces. It is a positive term that correlates to the rate of mechanical energy dissipation per unit volume and unit time [6]. The heat addition is represented by the rates of heat release due to chemical Qc and radiation Qr, and by heat conduction through the surface ∇ · q [6]. De ρ = −p∇ · v + φ − ∇ · q + Q + Q (2.4) Dt v c r Introducing the energy equation to solve for the extra unknown variable also adds four more variables to solve, which need additional approximations or relations as the state principle of equilibrium thermodynamics. It states that any state variable (ρ, p, T, e, s) can be related to any other two with the equation of state. The most famous equation is the Ideal gas law (2.5) [8].

p = ρRT (2.5)

8 Chapter 2

The system of equations is a set of non-linear partial differential equations deeply dependent on the boundary and initial conditions. The non-linearity is due to the convective acceleration, which is associated with the change in velocity with respect to the position. Due to this non-linearity, a general solution can no be obtained, except for very simple cases. The turbulence, which is a time-dependent chaotic behavior of the fluid, is generally considered to be produced by the inertia of the fluid or in other words by the combination of time-dependency and convective acceleration [4]. The turbulence is modeled through the aforementioned non-linearity of the equations. Even with numerical methods, the N-S equations are very difficult to solve for turbulent flow. To obtain a stable solution, direct numerical simulations are very computational expensive due to the required high mesh resolution, begin prohibited for practical cases. To solve such issue, time-average equations such as Reynolds-averaged Navier–Stokes equations (RANS), combined with turbulence models as Spalart–Allmaras, k–ω, k– or SST are used for efficient CFD. Another option, more costly but more accurate, is the time and spatial averaging given by the large eddy simulation (LES) [3]. The N-S equations with additional equations and well-defined conditions model quite accurately the fluid, even for turbulent cases. Their main issue is not on the physics but on the mathematics to solve their non-linearity. Moreover, it is important to remind that N-S equations assume that the fluid is continuum, thus infinitely divisible and not composed of particles, which makes them imprecise at very small scales or extreme conditions.

2.3.2 Lattice Boltzmann Method In the field of fluid analysis, one refers to the molecular description of the fluid as ”microscopic”, while ”macroscopic” is used for a continuum picture of it with tangible qualities. Microscopic systems are governed by Newton’s dynamics, while the previously discussed N-S equations govern the continuum fluid. In between both descriptions, there is the ”mesoscopic” description, which tracks distributions or representative collections of molecules. The mesoscopic fluid description is modelled with Kinetic theory, the cornerstone of the LBM [8]. Kinetic theory describes the fluid behavior using the conservative interac- tions of air molecules. The central variable in kinetic theory is the particle or velocity distribution function f(~x, ξ,~ t) with units [kg·s3/m6]. It represents ~ the density of particles with velocity ξ = (ξx, ξy, ξz) at position ~x and time t. It can be interpreted as a density that accounts for particles velocity, therefore, representing the density of mass in three-dimensional physical space and three-dimensional velocity space. The distribution function is related

9 Chapter 2 to macroscopic variables, like density or velocity, throughout its moments. These are integrals of the distribution function weighted with a function of ξ over the velocity space, accounting the density of particles of all velocities at position x and time t. Mass, momentum and internal energy density can be found in equations 2.6, 2.7 and 2.8 respectively. Z ρ(~x,t) = f(~x, ξ,~ t)d3ξ (2.6)

Z ρ(~x,t)~u(~x,t) = ξf(~x, ξ,~ t)d3ξ. (2.7)

1 Z ρ(~x,t)e(~x,t) = (ξ~ − ~u)2f(~x, ξ,~ t)d3ξ (2.8) 2 Having introduced the distribution function f, the next step is to char- acterize its evolution in time with an equation. Such equation is obtained throughout its total derivative with respect to time. Inserting the renown notation for the total differential Ω(f) = df/dt, the Boltzmann equation (2.9) is obtained [8]. df ∂ = f(~x, ξ,~ t) + ξ~ · ∇f(~x, ξ,~ t) = Ω(f) (2.9) dt ∂t The Boltzmann equation (2.9) can be interpreted as an advection2 equation. Overall it describes the rate of change of the velocity distribution function due to non-equilibrium. In the right-hand side, there is the so-called collision operator Ω, which is a source term that describes the local redistri- bution of the distribution function f, due to collisions. The collision term satisfies the mass, momentum and energy conservation laws [8]. The Boltzmann’s collision operator considers all possible outcomes when two particles collide for any inter-molecular force, leaving a complicated dou- ble integral over the velocity space. LBM uses a simpler collision operator called BGK (2.10) after its inventors Bhatnagar, Gross and Krook. 1 Ω(f) = − (f − f eq). (2.10) τ This operator modules the relaxation distribution function towards the equilibrium distribution, where f eq is the equilibrium distribution and τ the relaxation time which determined the speed of such equilibrium [8]. In order to discretize Boltzmann equation, first the discrete-velocity distribution function fi(x, t) must me introduced. Analogous to the distribution

2In the ﬁeld of physics advection refers to the transport of a substance or quantity by bulk motion. The properties of that substance are carried with it.

10 Chapter 2

function f, fi describes the density of particles with velocity ~ci = (cix, ciy, ciz) at time t and position ~x with a major diﬀerence, which resides on the argu- ment variables of fi being discrete. ~ci, to which the subscript i in fi refers, is one of the discrete set of velocities {~ci}. This fi is deﬁned at point ~x which are located as a square lattice in space, with lattice spacing ∆x. Finally, fi is only characterized at time t with time step ∆t [8]. Similar to its continuous sibling the mass density and momentum density can be expressed through fi moments X ρ(~x,t) = fi(~x,t) (2.11) X ρ~u(~x,t) = ~cifi(~x,t). (2.12)

The set of discrete velocities ~ci can have different number of spatial dimensions d and number of velocities q. These sets are denoted as DdQq, and the most common ones are D1Q3, D2Q9, D3Q15, D3Q19 and D3Q27 [8]. PoweFLOW solver uses the set D3Q19 Figure 2.3, which has the best accuracy-efficiency ratio. This means that the continuous distribution function is defined on a lattice of equally shaped regular cubic cells. Therefore, during a time interval ∆t, particles can only hop from one center of a cell ~x to one of the q positions of the neighboring cells ~x + ~ci∆t according to their velocity ~ci.

Figure 2.3: D3Q19 Model

The particle dynamics are now described by the discretized Boltzmann equation, known as Lattice Boltzmann Equation (2.13). The term ”lattice”, as previously introduced, refers to the grid used to discretize the computational domain [7]. The collision operator which determines if the lattice system produces a physically meaningful ﬂuid behavior, is obtained from the discretized version of the BGK operator (2.10).

fi(~x + ~ci∆t, t + ∆t) = fi(~x,t) + Ωi(~x,t) (2.13)

11 Chapter 2

Overall, the LBE concept consists of move and collide. The collision, which conserves local mass, momentum and energy is a local algebraic op- eration where the density and macroscopic velocity are calculated to ﬁnd eq ∗ the equilibrium distribution fi and post-collision distribution fi . After the ∗ collision, the resulting distribution fi is streamed to neighbour nodes com- pleting a time step. Afterward, these operations are repeated. Figure 2.4 illustrates a sketch of one LB algorithm cycle.

Figure 2.4: Overview of one cycle of the LB algorithm. The dark grey boxes show sub-steps that are necessary for the evolution of the solution. The lighter grey box indicates the optional output step. The lighter grey box has macroscopic ﬁelds to be written to the hard disk for visualisation or post-processing. [8]

To ﬁnalize this section about LBM with a note about PowerFLOW core technology, it is important to state that PowerFLOW is based on the Lattice Boltzmann Method, but combines it with models to robustly and eﬃciently deal with unsteadiness and turbulence. The turbulence model used is the Very Large Eddy Simulation (VLES) while the boundary layer model is the Advance Boundary Layer Model (ABLM).

2.3.3 Contrast of PowerFLOW and Traditional CFD PowerFLOW differs from the competing RANS-based CFD technology in fundamental ways. Recapping, conventional CFD methods assume the fluid as a continuum and construct the fluid equations as partial differential equations. For most of the cases, these equations flawlessly describe the real fluid behavior, but the main issue comes from the mathematical perspective and not in the equations themselves. Because the equations are complex and highly non-linear, and characterized by many degrees of freedom, analytical solutions are only possible for straightforward cases [10]. For more complicated cases, a discrete approximation of the PDE is necessary for numerical

12 Chapter 2 integration. The equations are numerically resolved for a given mesh and boundary conditions. On the other hand, LBM uses a ”Lattice” discretization of kinetic theory based on Boltzmann equation. No further discretization is required to numerically integrate, solving lattices and applying kinetic based boundary conditions. Finally, a simple conversion to ﬂuid variables is required. A graphical representation of the aforementioned information can be observed in Figure 2.5.

Figure 2.5: NSM and LBM overview

Fundamentally, the initial advantage of LBM lies on its approach based on microscopic particle physics instead of the continuum assumption of fluid mechanics equations. The method allows to have a wider physical validity, from complex fluids and from micro to macro scale. Being time-dependent and inherently unsteady it makes it advantageous for unsteady flow simulations. It should be noted as an advantage that no artificial dissipation is needed and boundary conditions are physically realized. In general, all of these make the method strongly accurate and robust. From the software development point of view, it is appreciated for its intrinsically simpler mathematical background and implementation of the algorithm. Also, it is naturally suitable for parallelization, since each time step update is local to each node, and this allows to divide the computational domain into sub-domains handled by different processors. Other advantages which are worth mention, are the incorporation of the thermal fluctuations originated on the microscopic level and sound-flow interaction simulation.

13 Chapter 2

However, LBM is still a very young method that needs further development in terms of physical and numerical aspects in order to completely overtake traditional N-S based CFD. On the negative side, LBM is an inten- sive memory consumer and its turbulence modeling framework is not completely understood. Moreover, capturing compressible flow phenomena for high supersonic and hypersonic aerospace applications has not yet reached a complete level of maturity. At last, LBM is quite inefficient dealing with steady flows due to its inherently time-dependency.

14 Chapter 3

Tool Implementation

After having introduced the SIMULIA PowerFLOW suite, its methodology and its core technology, the following sections will revolve around the engineering project performed at the SIMULIA ﬁeld oﬃce in Stuttgart.

3.1 Background and Motivation

The reliability and robustness of CFD analysis are higher than ever. It is usually attributed to new modeling physics, new numerical solver methods as well as a further refinement of the discretization. However, it is sometimes forgotten that this increase in reliability and robustness could not be achieved without the application of best practices, which can only be gained through experience in the field and the software. SIMULIA PowerFLOW software is no exception, and these best practices are materialize through the application engineers in field offices. This business method brings to the table an overall more expensive product and service but with superior support and assistance that channels into higher reliability and robustness. An issue that best practices aim to fix is human factors. It does not refer to the quality of the work, but to the errors, mistakes and flaws introduced in any stage of the simulation process. This is a well known issue in the world of CFD and highlighted in the automotive and aerospace indus- tries where numerous cases are simulated with only some specific elements modified for comparison purposes. Stuttgart’s field office engineers who deal with issues and projects of fewer experience customers, heavily suffer from this user mistakes. Solving or minimizing this problem can be translated into more reliable results and less misused simulation hours in the SIMULIA PowerFLOW cluster, which means huge savings for the customer. Having a tool capable of extracting, analyzing and efficiently presenting

15 Chapter 3 the desired information of a case to be simulated has been in discussion for years in the Stuttgart. It was not until one of the engineers was asked by a customer to resurface an old project whose original responsible engineer was not available anymore. The lack of information led to problems with the procedure used, the geometry, the naming and the case set up of all the runs. This set the wheels in motion to develop a tool to solve this problem of information lack and to minimize human errors in the simulation set up phase.

3.2 Project Statement

The ambition is to create a fast, intuitive, user-friendly tool that can analyze numerous cases. The idea with this is to extract, process and conveniently expose, very sensitive and specific information from the massive amount of data comprised in the case file before simulation. Such file is known as CDI, due to its file format ”.cdi”. The data to be analyzed is selected based on the two premises of very critical data and error recurring inputs. Having this tool, the user can efficiently revise the runs before sending them to simulation avoiding inaccurate results and costly running hours of the computer cluster. Moreover, the tool is intended to compare the data extracted between the cases. Large number of runs of the same project with specific discrepancies are a notorious source of error, therefore, the tool should also be capable of comparing the runs and expose their differences. By highlighting the differences, the user will be able to detect the undesired features. From now on the tool will be referred to as the Case Data Analysis Tool (CDAT).

3.3 Methodology

Since the beginning, it was clear that the CDAT will be based on a script that would extract and analyze data, and a user interface that would display the results. Consequently, a programming language and a graphical user interface are needed. The graphical user interface (GUI) chosen is PowerINSIGHT, which belongs to the PowerFLOW suit. Two main reasons explain this decision. The first one is because the program was conceived for a similar task, offering a graphical interface to easily configure and generate comparative results, in- teractively browse results as well as serve intermediary between the script and its interpreter. The second one, was business related, to encourage customers interested in the tool to use SIMULIA software.

16 Chapter 3

The ﬁrst programming language considered was shell scripting for direct command-line interaction. Even though this method would be very advantageous internally, where Unix-like OS is used, it was quickly realized that it would be useless for windows based customers. Therefore, a free high-level cross-platform programming language was required. Python was an obvious choice because it fulﬁlled all those requirements and has many advantages, such as being easy syntax, object-oriented, widely supported and with over 300 standard library modules that contain modules and classes for a wide variety of programming tasks.

3.3.1 Tool Workflow The tool works around two main pillars, the Python routines and the GUI PowerINSIGHT. The technical development of the tool resides mostly in the Python routines, where the data extraction and processing is carried out. The second pillar is PowerINSIGHT, it is the interface where the CDAT is implemented and the results displayed. It also functions as a link to Pow- erVIZ and the CDI files. The workflow of the tool is represented in Figure 3.1.

Figure 3.1: Case Data Analysis Tool workﬂow

As previously defined, PowerINSIGHT (PI) is a software that aims to automatize data exposure and comparison, and it works by sourcing a unique template that has been created in advance for the desired content. In the Case Data Analysis Tool, the file is named CaseData AnalysisTool.pins. This file contains the template of the information which will be created when the tool is run. The results generated by the tool are described in the next Section

17 Chapter 3

3.3.2. Once the pins ﬁle is loaded, the CDIs to be studied and compared are selected through PI. Then, the routines are loaded by PI. The scripts access the requested content and the CDI information to extract their data and process it. The images are generated by PowerVIZ when the script asks PI for them. At last, the results are saved and displayed also in PI.

3.3.2 Features and Content Generated The advantage of this tool lays on the carefully selected information that is produced. Accordingly, an important effort was placed on thoroughly under- standing what content should be included and how to organize it. As mentioned before, the information displayed was chosen based on the premises of important data of the simulation and common sources of errors. Even though the major features were agreed on during the definition of the project scope, smaller characteristics were included after testing and user feedback. Initially, only one script was developed to perform the whole analysis, but it was quickly understood that two were necessary to first check the CDI and then compared it. The first routine originally meant to only extract data, but it grew to become a meaningful analysis by itself. Therefore, the tool performs two divided but interrelated assignments. First, the CdiCheck.py script carries out a check of each CDI, afterward, the CdiComp.py executes a comparison between the preceding CDIs. The corresponding content generated by each routine is displayed in Figure 3.2. Both analysis are divided into three separated study categories based on different topics of the simulation: Model Geometry, Case Analysis and Pictures. The described information is visually represented in Figure 3.2. Following there is a more detail explanation of each feature of the tool.

CDI Check The first analysis of the tool is performed by the routine CdiCheck.py and it is divided into three sections. The first section is the CDI Check - Model Geometry. It reads from the CDI the information about the parts conforming the geometry (e.g., the engine, the body and the wheels among others) and their last modified date. Then, such information is compared with the parts found in the storage of the work station. It shows the user if there are parts missing in the CDI or if the parts are not updated to the latest version. Secondly, the Model Geometry also shows which parts in the CDI have open shells, which can be critical for the simulation. An open shell is a surface made of continuous facets where at least one of the edges belongs to only one facet. Facets are the smallest

18 Chapter 3

Figure 3.2: Case Data Analysis Tool PowerINSIGHT tree entities of the geometry, which have a triangular shape delimited by edges and vertex. Having a part containing an open shell is generally undesired. The CDI Check - Case Analysis is the second study of the CDI Check. It extracts and shows the case variables and their value. The case variables which are some of the most important inputs define the environment and boundary conditions of the simulation. Inside the Case Analysis, it is also exposed the floor configuration set up, which is a common source of error. The floor configuration, only used in vehicle simulations, refers to the type of floor that will be simulated to match the desired condition. The options are Moving Road, Moving Center Belt+Wheel Belt, Moving Center Belt, Static Floor With Friction and Friction-less Floor. Finally, the CDI Check - Pictures is in charge of generating the images of the following:

• The most important VR regions1: VR10, VR9, VR8 and VR7.

• The rotating parts, known as LRF, as the fans or wheels of the vehicle.

• The diﬀerent modules of the geometry. In the case of a complete vehicle, it comprises the body, the power train, the suspension, the subsystems, the porous media and wheels if they do not rotate.

1Variable Resolution regions refer to the volume around the geometry with diﬀerent mesh resolution. From the largest reﬁnement VR10 found in critical areas, the following VR regions (VR9, VR8...) decrease by a factor of two.

19 Chapter 3

Every component has eight images from four diﬀerent viewpoints (Front, Left, Top, Iso) taken from diﬀerent reference coordinate systems. Every image generated in this section helps visualize the geometry and the other components, but more importantly they will be later on used for comparison purposes.

CDI Comparison The second part of the tool, the CDI Comparison compares the data of the CDI Check as well as additional data from the CDIs. The section CDI Comparison - Model Geometry performs a comparison of parts and faces contained in the geometry of the two runs being compared. The parts, their names, areas and positions of each are compared with their analogous to identify discrepancies. As for the faces, only the areas are compared. This geometry comparison provides a direct tag to the parts and faces with differences between the runs. The CDI Comparison - Case Analysis section performs a comparison between the case variables and wind tunnel floor configuration of the runs. A different value or unit of the analogous case variables will be highlighted as well. This comparison aims to decrease the frequent mistakes of setting incorrect values for important variables between runs. At last, the CDI Comparison - Pictures performs a pixel-by-pixel deduction between the analogous images of the runs being compared. To do so, the images generated during the CDI Check are used. This comparison shows the visual differences between the cases in a scale of gray, which allows for a more visual correlation.

3.4 Project Management

During the development of the project no management method was strictly followed, however, it can be said that the method used was encompassed under the umbrella of what is known as Agile approach. During the first stages of the project, a general description of the scope was defined along with the path and overall features needed. Then, the approach was to work in a collaborative environment, where the next steps of the project were discussed with co-workers and managers fairly often. Occasionally, the first aimed client of the tool was also involved in such discussions. This meant to discuss the specific features of the tool and how to achieve them. Then, the new features were added into the tool to be immediately tested for errors and improvements. This approach helped to deliver requirements incrementally

20 Chapter 3 throughout the project life cycle and therefore archiving a robust tool. When all the main features discussed were included and the tool was internally agreed to be ready, it was deployed to customers. This was done with an onsite visit to the aerodynamic department of the automotive maker, where a presentation was given on the tool advantages and usage. Afterward, a workshop was given to the engineers so they could test the tool and famil- iarize themselves with it. The workshop was also planned to test the tool on the customer machines and solve any error that might have appeared.

21 Chapter 4

Results

This chapter aims to expose the results of the CDAT project. First, the python routines and the PowerINSIGHT template are described from a technical perspective. To finish a case example will expose the features and advantages of the CDAT. Due to confidentiality requirements with Dassault Systèmesand its clients sensitive information was omitted from this report. The routines are exposed to the highest detail permitted and the case example will be based on a concept vehicle property of SIMULIA.

4.1 Python Routines

An exhaustive description of the routines CdiCheck.py and CdiComp.py introduced in Section 3.3 is unfeasible and unauthorized for confidentiality reasons. Even then, this section will attempt to give an overall overview of the structure, the functionality, the most important characteristics and other details that may be relevant to understand the scripts as well as the work and effort they required. The information exposed remains inside the boundaries of legal privacy established by the employer. The written structure of the routines can be divided into five sections: Information Gathering, Data Generation, Model Geometry, Case Analysis, and Pictures. The last three correspond to the features described in Section 3.3.

4.1.1 Routines Common Sections Some section share a similar procedure and sometimes even the same lines of code in both routines, thus, it will be explain altogether before deviating

22 Chapter 4 to each routine independently. The first section found in both routines is the Information Gathering, which starts importing the necessary libraries. Libraries are a collection of functions and methods that help reduce the amount of code and its complex- ity. The libraries os, sys, subprocess and multiprocesing provide aid managing the OS, external programs and files. For data analysis, the libraries numpy, re, collections, fnmatch, time and datetime are imported. From Python Im- ageing Libray, Image, ImageChops and ImageOps are imported for image processing. Finally, for graphical user interface generation Tkinter and tk- FileDialog are used. The desire to generalize the tool as much as possible required the implementation of routines for Unix-like OS as well as for Windows. The next component found in both routines is the operating system check. It will de- termine the usage of specific functions or approaches depending on the OS. The next features are two GUIs asking the user to check the correct path to the CaseData AnalysisTool.pins for auto-saving purposes, and the path to ExaTOOL. If the path is not correct the routines ask the user to input a new path. The auto-saving feature was added in case PI stop functioning and existed without the chance of saving the data. The software ExaTOOL will be later used to transform the CDI into a readable format and therefore the path to it must also be checked as it may change in each workstation or OS. The last aspect of this section is the definition of variables for PowerIN- SIGHT, the launch PowerVIZ services and the extraction of the user set up information. Such information extracted from PI, are the file names of the CDIs, where they are saved and the run names. With this information, the routines are able to prepare the analysis, organized the content and access the CDI to read the data. The Data Generation section employs the information assembled previously to access the CDIs and with the help of the ExaTOOL create the files CDI-DUMP and SUMCDI for each CDI. Such files are txt readable data, containing different information of the case. The SUMCDI is more or less a summary while the CDI-DUMP is a heavy text file with additional information of the case. This process differs for Windows to Linux machines.

4.1.2 Routine: CdiCheck.py The routine named CdiCheck.py contains 1133 lines of code and is responsible to perform the CDI Check. Following the Data Generation section, comes the Model Geometry. The ﬁrst feature in the Model Geometry is the comparison of parts between

23 Chapter 4 the CDI and the Storage. The information of the parts is filtered from the CDI-DUMP and the storage to compare them. The data of the CDI-DUMP is read line by line and the desired lines are saved based on filters of recurrent structure naming. Then the data is organized into two dictionaries, one for Nastran format and anohter for STL. The computer folder where the CDI is saved is scanned for geometry parts of the case base on the file name extension ”.nas” and ”.stl”. The last modified date of the parts is read for each file. Again the data is organized in dictionaries. The next step is the comparison of the data contained in the dictionaries. All the parts are first compared by name to see which ones are in the CDI and not in the Storage and vice versa. The parts whose names coincide have their modified date compared as well. To do so, the time zone, date and time of each part is converted into seconds based on a reference date. The results are organized and appended to the corresponding table to be exported as comma-separated values (CSV) files. Subsequently, the geometry parts that contain open shells are read from the SUMCDI. A similar procedure as previously described is used to read the desired information. The routine continues with the Case Analysis. The first feature is the Case Variables analysis. This section extracts the case variables, their value and unit from the SUMCDI following the same reading procedure as before. The data is then sorted and appended to a table to be written as a CSV file. The second feature of this section is the wind tunnel configuration analysis. Because the information about such configuration is not available in either of the created files, the analysis requires reverse engineering. Depending on the configuration, there are different auto-generated parts contained in the CDI. Therefore, all the parts are read from the corresponding sections of the SUMCDI, with the same technique as before, being filtered based on the corresponding conditions identified for each wind tunnel configuration. The final section is the Pictures Generation. In this section, the script asks PI to generate the pictures of the modules, which are defined in the pins file. To do so, PI calls PowerVIZ to read the CDI and produce the requested content in the background. The last few lines of code request PI to fill in its empty templates from the information processed by the routine.

4.1.3 Routine: CdiComp.py The second routine is named CdiComp.py, which includes 1550 lines of code and it is in charge of carrying out the CDI Comparison. Again, the routine begins with the Information Gathering and Data Generation section already

24 Chapter 4 described. However, this script compares two runs and therefore extra lines are required to the preparation and organization of the analysis material. The following section is the CDI Comparison Model Geometry. This section performs a comparison of parts and faces between the CDIs being compared. The routine first reads each of the SUMCDI files. Then, using the corresponding filters and following the technique previously introduced, it extracts the names of the parts, their area and the coordinates of their bounding box (BB). With a similar practice, the names of the faces and their area are read as well. The data is organized into Python libraries to later facilitate its handling. These operations are repeated for the second CDI of the comparison. Subsequently, the actual comparison is performed, starting with the parts. They are first contrasted by name to find the ones only included in one case. After that, the center of gravity of the BB is calculated, to be employed as based for the comparison of the position of the corresponding parts. Lastly, the corresponding parts are contrasted based on their area. The results obtained are appended to tables and saved. Concluded the study of the parts, the faces are compared following the same method as the parts except for the position, because the SUMCDI does not inform about the BB of the faces. Again the results are exported as CSV files. Phase two corresponds to the CDI Comparison Case Analysis. This section compares the case variables and wind tunnel configuration of the two CDIs. Instead of extracting the information from the SUMCDI again, the routine access the tables saved during the CDI Check Case Analysis, which are already filled in with the desired information. After the data is read and placed in libraries, it is then compared by name to find non corresponding variables. In case of analogous variables, they have their value and unit check to find differences. At last, the wind tunnel configurations are examined to find out if they match. All the results are exported as tables in CSV format. The final section is the CDI Comparison Pictures. First, the images created during the CDI Check are copied and changed to PNG format. It is done because they are in PI format (.image). Once the images are readable, the routine scans for analogous images from both runs and pairs them. After that, they are changed to grey scale and superposed to each other pixel-by- pixel, to highlight any difference. The number of non-white pixels of the comparison image are measure in percentage to the number of non-white pixels from the original baseline image to create a table showing the larges percentage difference between the images. Again the tables are saved as CSV files and the images are saved as PNG. Once again, the last lines of the routine ask PI to generate content and fill in its template based on the tables and images created by CdiComp.py.

25 Chapter 4

4.2 PowerINSIGHT

Even though the technical work of the project relies on the python routines, PowerINSIGHT is the connection between all the branches of the tool and the user interface that sets up and displays the results.

4.2.1 File: CaseData AnalysisTool.pins As early described, PI works with templates that will be later filled in with content. A template had to be customized for the content generated by the routines and its name is CaseData AnalysisTool.pins. The template is created based on the naming and structure developed in the Python routines. There is a folder for the CDI Check and other for the CDI Comparison. Inside of each, there are the mentioned subsections with the corresponding tables and images templates. This means that PI has the structure, the names of the images and tables as well as their headers. The results are then read by PI, filled in its templates and finally displayed.

4.3 Tool Evaluation

The objective of this section is to show a real case scenario for the avaluation of the tool. Doing so, the content generated by the tool can be described in detail. Moreover, the tool benefits and advantages will be more visible. Due to confidentiality reasons with customers, none of their cases could be used in this report, instead two dummy cases were created. They were created using a concept car designed by the SIMULIA PowerFLOW team, the EV12. It is a five doors suburban highly optimized for aerodynamic efficiency with fewer confidentiality issues. To understand the results of the analysis, the created cases must be ex- plained first. The idea is to reproduce a very common real project where a variant case is simulated with respect to a baseline model for comparison. Multiple variants are usually created, in this case there will be only one variant. The baseline was created based on the original geometry of the EV12 and a typical aerodynamic template to set up the standard practices and variables of the simulation. The variant is intended to be identical with the exception of the side mirrors, which are 21% larger. Intentional errors were included in the cases for the tool to find them. This should help the reader understand the purpose and advantages of the tool. Once the cases are set up, they are saved in CDI format ready to be simulated. The next step is to proceed with the set up of the tool. First the CDIs

26 Chapter 4 are linked to PI, then the routines are loaded and ran. The tree of generated content is shown in Figure 4.1. The ﬁrst node, named EV12 Baseline Run00, corresponds to the analysis of the CDI Check for the baseline, while the EV12 Run01 contains the CDI Check of the variant. At last, the CDI comparison analys between both runs is shown in the node RunCompari- son1 (Variant:EV12 Run01 vs Baseline:EV12 Baseline Run00). Under each node we ﬁnd the three independent analysis introduced in previous chapters. Again, the Flow Monitors is an auto-generated node not part of this tool.

Figure 4.1: Case Data Analysis Tool Content Tree in PowerINSIGHT

4.3.1 CDI Check results This section will revise and discuss in detail the output of the CDI Check analysis for the Run00 and Run01. Both nodes follow the same template of content described in Section 3.3.2. It means that the tables and images produced have the same structure, but they contain the individual results of each CDI analysis. The results are the following:

EV12 Baseline 1. CdiCheck - Model Geometry

(a) NAS: Folder with the analysis of the Nastran format parts. It will show the geometrical parts included or not in the CDI and if they are up to date. • NAS Overview: The table in Figure 4.2 shows that there are 107 parts with the same name between the CDI and the storage. Moreover, no parts were found to be only in the CDI or the storage and all the corresponding parts have the same

27 Chapter 4

modiﬁed date. This means that all the parts in the storage were used to generate the CDI and that all the geometry has the most updated version.

Figure 4.2: NAS Overview: EV12 Baseline • Files in CDI and NOT in Storage: The objective of this table is to show the names of the parts corresponding to such category. Because the result is zero the table displays no parts.

Figure 4.3: Files in CDI and NOT in storage: EV12 Baseline • Files in Storage and NOT in CDI: Table displaying the parts corresponding to such category. In this case there are none, thus the table is not displayed. • Name-Matching Files BUT Different Times: Table with the names of the parts, their date and time corresponding to this category. Again the table is not shown because there are zero parts. (b) STL: This folder contains the same analysis and tables as the NAS analysis but for STL files. However, there are no STL files in the CDI or storage as all the parts of the EV12 are in Nastran format. Thus, the tables are empty and therefore not included. (c) Open Shells • Open Shells: The table highlights the parts that have one or more open shells. The geometry must be watertight for the simulation, this means that these parts must be revised to check if the open shells are in contact to the flow, and if so, fix them.

28 Chapter 4

Figure 4.4: Open Shells: EV12 Baseline 2. CdiCheck - Case Analysis

• Case Variables: All the variables of the case are exposed in alphabetical order to help the user check if they are correct. They will be used later on in the comparison section. Due to the large number of variables, only some of them are displayed in Figure 4.5 because they are too many to include here.

Figure 4.5: Case Variables: EV12 Baseline • Case Method Overview: The wind tunnel ﬂoor conﬁguration is shown here. For this case it is set as ”Static Floor With Friction” as indicate for this simulation.

29 Chapter 4

Figure 4.6: Case Method Overview: EV12 Baseline 3. CdiCheck - Pictures: This section has three folders for the images corresponding to the VR volumes, LRFs and Modules. There are pictures for four views from two reference frames of each module and VR, so the total number of images for a run is more than a hundred. The most relevant pictures have been selected to illustrate the EV12 and the tool.

(a) VR Volumes: Figures 4.7 - 4.9 show the VR 07, 08 and 09 of the baseline respectively. The VRs are correct and as expected. It is important to remind that the higher the number of the VR is, the higher the resolution deﬁned in the region.

Figure 4.7: VR07 Viewpoint: Figure 4.8: VR08 Viewpoint: Ground-ISO EV12 Baseline Ground-ISO EV12 Baseline

Figure 4.9: VR09 Viewpoint: Ground-ISO EV12 Baseline (b) LRFs: This vehicle has no local rotating frames defined, therefore no images are produced. LRF is usually applied to the wheels or the cooling fans. (c) Modules: This folder contains the images of the main geometry components or modules. They refer to a conglomerate of parts defined by the user. For the EV12 there are six modules: Body, Engine, Suspension, Wheels, Subsystems and Porous Media. Fig- ures 4.10, 4.11, 4.12 and 4.13 correspond to the four different

30 Chapter 4 viewpoints from the ground reference frame.

Figure 4.10: Body Viewpoint: Figure 4.11: Body Viewpoint: Ground-Front EV12 Baseline Ground-ISO EV12 Baseline

Figure 4.12: Body Viewpoint: Figure 4.13: Body Viewpoint: Ground-Left EV12 Baseline Ground-Top EV12 Baseline From the rest of the modules, only the isometric view of the images are included in Figures 4.14, 4.15, 4.16 and 4.17.

Figure 4.15: Suspension View- Figure 4.14: Engine Viewpoint: point: Ground-ISO EV12 Base- Ground-ISO EV12 Baseline line

31 Chapter 4

Figure 4.17: Subsystems View- Figure 4.16: Wheels Viewpoint: point: Ground-Top EV12 Base- Ground-ISO EV12 Baseline line

EV12 Variant 1. CdiCheck - Model Geometry

(a) NAS: Same analysis as before but this case for the EV12 variant. In this case, the results highlight some user mistakes. • NAS Overview: The table in Figure 4.18 shows that there are 6 parts that coincided and 101 in the CDI. This is due to the fact that this new case was created from the previous baseline and only desired parts were brought from the original geometry to be modified and to later update the variant. The file in the storage but not in CDI means that there is a part that has not been included. At last, out of the six matching files, five had different times which can mean that the CDI was not up to date with the latest geometries.

Figure 4.18: NAS Overview: EV12 Variant • Files in CDI and NOT in Storage: Figure 4.19 shows a portion of the table with the 101 names of the parts only in the CDI.

32 Chapter 4

Figure 4.19: Files in CDI and NOT in Storage: EV12 Variant • Files in Storage and NOT in CDI: If any part falls in this category is most likely due to a user error that has forgotten to include a part to the CDI. Such an example is seen here where a spoiler for the EV12 variant was created but was not incorporated into the CDI.

Figure 4.20: Files in Storage and NOT in CDI: EV12 Variant • Name-Matching Files BUT Different Times: Six parts had name matching but only one also had the same last modified date. This means that five geometry files could have not been updated into the CDI with the latest geometry. This is the case for the parts shown in Figure 4.21 where the mirror sails were modified for this comparison study but were not updated into the CDI. The other parts shown, have been intentionally created for demonstration of the tool, but they could have come from the same mistake.

Figure 4.21: Name-Matching Files BUT Different Times: EV12 Variant (b) STL: This folder contains the same analysis and tables as the NAS analysis but for STL files. However, there are no STL files in the

33 Chapter 4

CDI or Storage as all the parts of the EV12 are in Nastran format. (c) Open Shells • Open Shells: The table highlights the parts that have one or more open shells. These parts must be revised to check if the open shells are in contact with the ﬂow and if so, they need to be ﬁxed.

Figure 4.22: Open Shells: EV12 Variant 2. CdiCheck - Case Analysis

• Case Variables: All the variables of the variant are displayed together in alphabetical order. No errors are spotted, but they will be used again later on in the comparison section. Only some of the variables are displayed in Figure 4.23.

Figure 4.23: Case Variables: EV12 Variant

34 Chapter 4

• Case Method Overview: As expected, the wind tunnel floor configuration for the variant case is defined as ”Static Floor With Friction”.

Figure 4.24: Case Method Overview: EV12 Variant 3. CdiCheck - Pictures: Same as for the baseline CDI Check, this section shows the pictures for four views from two reference frames of each module. Only the most relevant ones were selected and exposed. Again, these images will be used in the comparison section afterwards.

(a) VR Volumes: Figures 4.25, 4.26, 4.27 and 4.28 show the VR 07, 08, 09 and 10 of the variant for the user to spot major errors. In this case the VR regions seem to be correct.

Figure 4.25: VR07 Viewpoint: Figure 4.26: VR08 Viewpoint: Ground-ISO EV12 Variant Ground-ISO EV12 Variant

Figure 4.27: VR09 Viewpoint: Figure 4.28: VR10 Viewpoint: Ground-ISO EV12 Variant Ground-ISO EV12 Variant (b) LRFs: The variant has no local rotating frames deﬁned either, thus, no images are produced. The images seem to be correct, no major errors are found. (c) Modules: Only the isometric view of the body, engine, suspension and wheels are shown.

35 Chapter 4

Figure 4.29: Body Viewpoint: Figure 4.30: Engine Viewpoint: Ground-Front EV12 Variant Ground-ISO EV12 Variant

Figure 4.31: Suspension View- Figure 4.32: Wheels Viewpoint: point: Ground-ISO EV12 Vari- Ground-ISO EV12 Variant ant

4.3.2 CDI Comparison results The comparison between both cases is a very insightful analysis that will allow the user to quickly identify the diﬀerences and correct the mistakes for correct simulation comparison. It is important to point out again that the only diﬀerence between the EV12 Baseline and the EV12 Variant should be the side mirrors and the parts auto-generated based on the mirrors. The rest of the case set up should remain the same.

1. CdiComp - Model Geometry

(a) Parts: • Parts Analysis Overview: The table in Figure 4.33 shows the numerical results of the comparison of the parts. From the table, the ﬁrst thing to point out is the mismatch of the number of total parts. Moreover, the number of parts with diﬀerent area and position seems to be more than expected.

36 Chapter 4

A more detailed examination of the results can be achieved through the following tables. It is important to note that the section Parts With NEGLIGIBLE Area or Position was introduced to filter parts comparisons with very small differences which is usually due to round off errors in the import of parts.

Figure 4.33: Parts Analysis Overview • Parts in Baseline and NOT in Variant: There are no parts only contained in the Baseline, and the table is not attached.

• Parts in Variant and NOT in Baseline: There are two parts corresponding to VR offsets that are only in the variant. An offset is a way to define a VR region around a specific critical geometry. This allows to apply higher resolution in critical areas. Thus, this table shows there is an undesirable difference because the VR should be the same. The baseline CDI did not have those parts defined and therefore they need to be corrected.

Figure 4.34: Parts in Variant and NOT in Baseline • Diﬀerent Area Only: There are no parts with a diﬀerent geometry only and therefore the table is not attached.

• Diﬀerent Position Only: The battery and the engine of the variant were intentionally displaced 10mm for the tool to capture such a mistake. The table in Figure 4.35 shows the results of this intentional error. Besides the distance between the centers of gravity, the table shows the maximum and min- imum coordinates of the bounding box containing the part in

37 Chapter 4

the baseline and variant. Note that in the ﬁgure, only the ﬁrst column of the coordinates appears.

Figure 4.35: Different Position Only • Different Area and Position: There are five parts with a different area and position. As expected, the body mirror is one of them, with a 21% larger area. It also has a different position because the center of gravity of each mirror was displaced to suit the rest of the body. The other four parts with a different area and position are apparently also correct. Be- cause they are auto-generated VR regions for the boundary layer analysis, PowerCASE generates them based on the geometry and if the mirrors are bigger those parts adapt to the new shape. The geometry is almost the same, the largest difference resides in their position. This table also contains the delta difference, the values and the coordinates of the bounding box of each part.

Figure 4.36: Diﬀerent Area and Position (b) Faces: This comparison is very similar to the previous section, but sourcing the faces that form the parts. No position is compared here because that information is not given in the SUMCDI. • Faces Analysis Overview: As expected from the comparison of the parts, two faces are in the variant but not in the baseline, and some faces have diﬀerent areas, in this case 14.

Figure 4.37: Faces Analysis Overview

38 Chapter 4

• Faces in Baseline and NOT in Variant: There are no additional faces only in the baseline. Therefore no table is attached.

• Faces in Variant and NOT in Baseline: The faces found to be only in the variant case correspond to the parts also found in the analogous analysis, the VR oﬀset regions. Again, these same components should be added to the baseline case.

Figure 4.38: Faces in Variant and NOT in Baseline • Faces with Diﬀerent Area: The six faces corresponding to the body mirror part, prove once again the correctness of the mirrors modiﬁcation. The parts of the VR boundary layer were bigger, therefore its constituting faces must be as well. The faces Fluid Zero Velocity, Unsteady HorizPlane Green- house HighFreq and Unsteady HorizPlane WheelAxle High- Freq are also auto-generated based on the outer dimensions of the car which has changed due to the larger mirrors, and therefore those faces have to change as well.

Figure 4.39: Faces with Different Area It should be noted that the Fluid Zero Velocity face defines a region around the vehicle where the velocity of the fluid is defined to be zero at the beginning of the simulation. It aims to help the solver to converge faster. The Unsteady Horiz- Plane Greenhouse HighFreq and Unsteady HorizPlane Whee- lAxle HighFreq are measurement faces auto-generated meant

39 Chapter 4

to capture unsteady parameters of the greenhouse and the wheel axle for aeroacoustic analysis.

2. CdiComp - Case Analysis • Case Analysis Overview: The case analysis overview table shows 66 matching variables, zero different variables, two with a different value and one with the wrong unit. These are major errors because they might completely change the simulation conditions which should be the same for both cases. The wind tunnel floor configuration is the same for both runs.

Figure 4.40: Case Analysis Overview • Diﬀerent Named Variables: No additional case variables were found in any of the cases.

• Different Value or Unit Variables: This table shows the variables with discrepancies in their units and values. The defined flow velocity has a difference of 40 km/h between both cases. It is a large error if the comparison of the mirror effects is meant to be under the same conditions. The defined tire roughness has an undesired significance difference as well. The last row shows an error on the assigned temperature unit, one in Celsius and the other in Fahrenheit. These three mistakes must be fixed before simulating both cases.

Figure 4.41: Different Value or Unit Variables 3. CdiComp - Pictures: This section carries out a pixel-by-pixel comparison of the corresponding images and then performs a percentage calculation. (a) Percentage Difference: After the comparison image is created, its percentage difference with respect to the baseline image is cal-

40 Chapter 4

culated and attached to a table, Figure 4.42, sorted by the highest percentage. From this table, it can be seen that the VR 10 volumes are totally different. For VR 09, the engine and the body have also significant differences. Knowing this, the mentioned images can be accessed directly for visual information.

Figure 4.42: Percentage Difference (b) VR Volumes: Figures 4.43 and 4.44 appear to show once again what was discussed in the Model Geometry section. The VR 10 regions were not added to the baseline design and such error is visible in these images. The Figures 4.45 and 4.46 show a difference for VR 09. The larger mirrors of the variant explain the difference in VR 09 around such an area, as the region is defined according to the geometry. As for the difference observable in the front rack, it is due to the presence of the VR 10 in the variant. The VR 10 offset around the front grill conditions the VR 09 in that regions as well. Straightening out the VR 10 situation in the baseline should solve these problems.

Figure 4.43: VR10 Viewpoint: Figure 4.44: VR10 Viewpoint: Ground-ISO EV12 Comparison Ground-Left EV12 Comparison

41 Chapter 4

Figure 4.45: VR09 Viewpoint: Figure 4.46: VR09 Viewpoint: Ground-Front EV12 Comparison Ground-ISO EV12 Comparison (c) LRFs: No local rotating frames defined, thus no material to compare. (d) Modules: From the percentage table, only two of the modules have some visual data. Figures 4.47 and 4.48 show how the mirrors are the only part of the body with different position or geometry. On the other hand, Figures 4.49 and 4.50 show that the engine and battery have been displaced. Even though the engine is not a critical flow, because is not an aerodynamic and thermal combined simulation, to achieve the best comparison results it should be located equally.

Figure 4.47: Body Viewpoint: Figure 4.48: Body Viewpoint: Ground-ISO EV12 Comparison Ground-Front EV12 Comparison

42 Chapter 4

Figure 4.49: Engine Viewpoint: Figure 4.50: Engine Viewpoint: Ground-ISO EV12 Comparison Ground-Front EV12 Comparison

Case Summary and Conclusions Based on the previously problems exposed by the tool, may aspects need to be considered:

• Several parts with open shells in both cases must be revised, the variant does not have the most updated geometry in some parts, the VR 10 was not included into the baseline, the battery and the engine parts seem to be displace in position and at last, there are three case variables with some diﬀerences.

• The rest seems to be correct and ﬁxing those problems should leave the baseline and the variant with larger mirrors ready to be simulated under the same conditions.

This analysis can be concluded with a positive note. The tool captures the desired differences and exposed valuable information for simulation confidence. Then, it also exposed abundant undesired errors in the cases and differences between them. Some of such errors were intentionally placed for showing purposes, while others were accidentally included while setting up the case example.

43 Chapter 5

Discussion

The Case Data Analysis Tool has achieved all the initial requirements agreed with higher management as well as customers. It is an efficient user-friendly tool which analyzes cases and compares them before the simulation, in order to detect errors fast and common or uncommon mistakes conveniently. The tool contains more features than initially defined, and therefore exceeding our expectations. These features were defined and then showed using the tool with two cases of a concept car. The example helped to prove the usefulness and advantages that the tool can bring to the pre-processing stage of CFD. It is important to mention how the tool usefulness and value increase exponentially when the number of cases to be analyzed grows, something which could not be exposed in this report. On the customer front, the tool evaluation was very satisfactory from the managers to the engineers point of view. The introduction of the Case Data Analysis Tool into their CFD process was understood as an added value step. This would increase assurance in what is being simulated and it would reduce expensive misused simulation hours. From the business perspective, this tool achieved the task to prove to the customer, that once again, the field office in Stuttgart aims to give the best support and improve their process in any possible way. As for future work, the CDAT is considered to have space for further development and improvements. For the time being, it is being used by customers and engineers in the Stuttgart team. This generates very useful feedback, which can range from common scripting errors in the routines to new required features, to keep improving the tool. On the long term, Stuttgart engineers are in contact with SIMULIA headquarter to present the CDAT and to define its future. The ambition is to hand it over to PowerFLOW software developers to continue adding features and possibly include the Case Data Analysis Tool directly into PowerINSIGHT.

44 Bibliography

[1] Francis Bernard. The Dassault Systemes Success Story. 2010. url: http://deelip.com/the- dassault- systemes- success- story- part-1. [2] Alan K. Binder and John Bell Rae. Encyclopedia Britannica: Automo- tive industry. 2018. url: https://www.britannica.com/technology/ automotive-industry. [3] John D. Anderson Jr. Modern Compressible Flow With Historical Per- spective. University of Maryland: Mc Graw Hill, 2003. [4] Rita G. Lerner and George L. Trigg. Encyclopaedia of Physics. Ger- many: VHC publishers, 2nd Edition, 1991. [5] International Organization of Motor Vehicle Manufacturers. Oica. 2019. url: oica.net. [6] Antonio L. Sanchez and Javier Rodriguez-Rodriguez. Fluid Mechanics: an Introduction and some Relevant Applications. Madrid: Carlos III de Madrid, 2011. [7] Thomas C. Schuetz. Aerodynamics of Road Vehicles. SAE Interna- tional, 2016. [8] Timm Kr¨uger; Halim Kusumaatmaja; Alexandr Kuzmin; Orest Shardt; Goncalo Silva and Erlend Magnus Viggen. The Lattice Boltzmann Method. Springer, 2017. [9] SIMULIA. PowerFLOW Website. 2019. url: https://exa.com/en. [10] SIMULIA. The Technology Behind SIMULIA PowerFLOW: Lattice Boltzmann-based Physics. 2019. url: https://exa.com/en/company/ exa-lattice-boltzmann-technology. [11] Statista. Car manufacturers by revenue. 2017. url: https://www. statista . com / statistics / 232958 / revenue - of - the - leading - car-manufacturers-worldwide/.

45 Chapter

[12] Dassault Syst`emes. Dassault Syst`emesHistory. 2019. url: https:// www.3ds.com/.