• No results found

Case Data Analysis Tool for PowerFLOW

N/A
N/A
Protected

Academic year: 2022

Share "Case Data Analysis Tool for PowerFLOW"

Copied!
57
0
0

Loading.... (view fulltext now)

Full text

(1)

Dassault Syst` emes - SIMULIA PowerFLOW

R

GUILLERMO D´IAZ V´ AZQUEZ

Master’s Degree Project

Stockholm, Sweden June 2019

(2)
(3)

for PowerFLOW

Dassault Syst` emes - SIMULIA PowerFLOW

R

Guillermo D´ıaz V´ 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

(4)

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.

(5)

Case Data Analysverktyg f¨ or PowerFLOW

Str¨ omningsmekaniska ber¨ akningar (CFD) omr˚ adet v¨ axer exponentiellt med

avseende p˚ a prestanda, robusthet och till¨ ampningar. Expansionen av CFD

bidrar ¨ aven till fler anv¨ andare och simuleringar, vilket i sin tur leder till fler

m¨ anskliga fel och misstag i upps¨ attningen av simuleringar. Eftersom simuler-

ingsupps¨ attningen beh¨ over vara korrekt f¨ or att ˚ aterskapa ¨ onskade fenomen,

beh¨ over s˚ adana fel undvikas f¨ or att kunna ¨ oka simuleringens tillf¨ orlitlighet

och robusthet. Med avseende p˚ a detta utvecklades ett verktyg i CFD mjuk-

varan SIMULIA PowerFLOW. Verktyget extraherar och analyserar inst¨ allnin-

garna f¨ ore simulering och rapporterar resultaten till anv¨ andaren f¨ or feldetek-

tering. Det h¨ ar arbetet redog¨ or f¨ or utvecklingen, till¨ ampningen och f¨ ordelarna

med framst¨ allda verktyget.

(6)

Acknowledgements

Firstly, I would like to thank Evelyn Otero for taking the role as my super-

visor and examiner, for the careful follow up of my work, and for the effort

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.

(7)

1 Introduction 1

2 Background 3

2.1 Dassault Syst` emes . . . . 3

2.1.1 Field Office 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 Workflow . . . . 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

(8)

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 out- put step. The lighter grey box has macroscopic fields 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 workflow . . . . 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

(9)

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

(10)

Nomenclature

CF D - Computational Fluid Dynamics CAE - Computer Aided Engineering P LM - Product Lifecyle Management CAM - Computer Aided Manufacturing CAD - Computer Aided Design

V R - Refinement Regions N -S - Navier-Stokes

LBM - Lattice Boltzmann Method

P DE - Partial Differential Equation

P F - SIMULIA PowerFLOW

P I - SIMULIA PowerINSIGHT

P V - SIMULIA PowerVIZ

OS - Operating System

LRF - Local Rotating Frame

CDAT - Case Data Analysis Tool

CSV - Comma-Separated Values

P N G - Portable Network Graphics

BB - Bounding Box

(11)

∇· - Divergence

∂ - Partial derivative

D

Dt - Material Derivative ρ - Density

p - Pressure q - Heat flux v - Flow velocity τ 0 - Stress tensor e - Internal energy s - Entropy

T - Temperature

R - Specific gas constant

(12)

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 be- tween 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` emes is a world leader due to its vast portfolio of products as well as their quality, function- ality 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 tran- sient complex shapes, true rotating geometry, wind tunnel conditions, couple simulations with thermal and aeroacoustic analysis, along with paralleliza- tion 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

(13)

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` emes, 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.

(14)

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` emes, 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 soft- ware 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` emes’ PLM products are DELMIA for manufac- turing, 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

(15)

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 aforemen- tioned field offices, in this case, located in Stuttgart, Germany. The city of Stuttgart was selected for its large automotive industry, having the head- quarters 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 appli- cation 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 im- portant 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

(16)

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,

(17)

removing CAD defects, making it watertight and then meshing it. Pow- erDELTA is also used to modify the model, wrap complex geometries, per- form 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 CDI 1 file contains all the necessary information for the simulation. [9]

In the second stage, which is the core of the simulation process, the com- putational domain is actually discretized and the Lattice Boltzmann equa- tions 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 deforma- tion. 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 pre- dict 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 re- sults from the solver into flow parameters and 3D visualization solutions. It provides a wide range of capabilities including volume, fluid and surface mea- surement 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 engi- neering and design are carried out with PowerREALITY. [9]

1

The CDI is the name used to refer to the compiled case file in ”.cdi” format containing

all the simulation data.

(18)

Chapter 2

2.3 PowerFLOW background

In the early 1990s, the testing of the Lattice Boltzmann method reached so- lutions equivalent to the classical approach based on the Navier-Stokes equa- tions. 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 difficulties 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 differences 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 be- havior 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 conti- nuity, 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 en- ergy contained in a fluid volume V f (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.

∂ρ

∂t + ∇ · (ρv) = 0 (2.1)

An alternative expression of the continuity equation (2.2) can be inter-

preted as the variation of the density following the fluid particle being ex-

(19)

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 ρ

Dt = −∇ · v (2.2)

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

Dt = −∇p + ∇ · τ 0 + ρf m (2.3)

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 equa- tion 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 inter- nal 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 repre- sented by the rates of heat release due to chemical Q c and radiation Q r , and by heat conduction through the surface ∇ · q [6].

ρ De

Dt = −p∇ · v + φ v − ∇ · q + Q c + Q r (2.4) 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)

(20)

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 solu- tion 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 combina- tion 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 equa- tions 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·s 3 /m 6 ]. 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, there-

fore, representing the density of mass in three-dimensional physical space

and three-dimensional velocity space. The distribution function is related

(21)

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.

ρ(~ x, t) =

Z

f (~ x, ~ ξ, t)d 3 ξ (2.6)

ρ(~ x, t)~ u(~ x, t) =

Z

ξf (~ x, ~ ξ, t)d 3 ξ. (2.7)

ρ(~ x, t)e(~ x, t) = 1 2

Z

(~ ξ − ~ u) 2 f (~ x, ~ ξ, t)d 3 ξ (2.8) 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 dt = ∂

∂t f (~ x, ~ ξ, t) + ~ ξ · ∇f (~ x, ~ ξ, t) = Ω(f ) (2.9) The Boltzmann equation (2.9) can be interpreted as an advection 2 equa- tion. Overall it describes the rate of change of the velocity distribution func- tion 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.

Ω(f ) = − 1

τ (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 dis- tribution function f i (x, t) must me introduced. Analogous to the distribution

2

In the field of physics advection refers to the transport of a substance or quantity by

bulk motion. The properties of that substance are carried with it.

(22)

Chapter 2

function f , f i describes the density of particles with velocity ~c i = (c ix , c iy , c iz ) at time t and position ~ x with a major difference, which resides on the argu- ment variables of f i being discrete. ~c i , to which the subscript i in f i refers, is one of the discrete set of velocities {~c i }. This f i is defined at point ~ x which are located as a square lattice in space, with lattice spacing ∆x. Finally, f i 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 f i moments

ρ(~ x, t) = X f i (~ x, t) (2.11) ρ~ u(~ x, t) = X ~c i f i (~ x, t). (2.12) The set of discrete velocities ~c i can have different number of spatial di- mensions d and number of velocities q. These sets are denoted as Dd Qq, 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 func- tion 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 + ~c i ∆t according to their velocity ~c i .

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 ”lat- tice”, as previously introduced, refers to the grid used to discretize the com- putational domain [7]. The collision operator which determines if the lattice system produces a physically meaningful fluid behavior, is obtained from the discretized version of the BGK operator (2.10).

f i (~ x + ~c i ∆t, t + ∆t) = f i (~ x, t) + Ω i (~ x, t) (2.13)

(23)

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 find the equilibrium distribution f i eq and post-collision distribution f i . After the collision, the resulting distribution f i 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 fields to be written to the hard disk for visualisation or post-processing. [8]

To finalize 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 efficiently 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 equa-

tions. 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 compli-

cated cases, a discrete approximation of the PDE is necessary for numerical

(24)

Chapter 2

integration. The equations are numerically resolved for a given mesh and boundary conditions. On the other hand, LBM uses a ”Lattice” discretiza- tion of kinetic theory based on Boltzmann equation. No further discretiza- tion is required to numerically integrate, solving lattices and applying kinetic based boundary conditions. Finally, a simple conversion to fluid 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 simu- lations. 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.

(25)

However, LBM is still a very young method that needs further devel-

opment 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 com-

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

(26)

Chapter 3

Tool Implementation

After having introduced the SIMULIA PowerFLOW suite, its methodology and its core technology, the following sections will revolve around the engi- neering project performed at the SIMULIA field office 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 intro- duced 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

(27)

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 be-

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

(28)

Chapter 3

The first programming language considered was shell scripting for direct command-line interaction. Even though this method would be very advan- tageous 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 fulfilled 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 workflow

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

(29)

3.3.2. Once the pins file 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 men- tioned 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 gener- ated 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

(30)

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 regions 1 : VR10, VR9, VR8 and VR7.

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

• The different modules of the geometry. In the case of a complete vehi- cle, it comprises the body, the power train, the suspension, the subsys- tems, the porous media and wheels if they do not rotate.

1

Variable Resolution regions refer to the volume around the geometry with different

mesh resolution. From the largest refinement VR10 found in critical areas, the following

VR regions (VR9, VR8...) decrease by a factor of two.

(31)

Every component has eight images from four different viewpoints (Front, Left, Top, Iso) taken from different 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 com- parison 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

(32)

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.

(33)

Results

This chapter aims to expose the results of the CDAT project. First, the python routines and the PowerINSIGHT template are described from a tech- nical perspective. To finish a case example will expose the features and advantages of the CDAT.

Due to confidentiality requirements with Dassault Syst` emes and 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 in- troduced 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

(34)

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 imple- mentation 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 pre- viously 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 first feature in the Model Geometry is the comparison of parts between

(35)

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

(36)

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.

(37)

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 vari- ant. 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 simu-

lated. The next step is to proceed with the set up of the tool. First the CDIs

(38)

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 first 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 find 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

(39)

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

(40)

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 floor configuration is shown here. For this case it is set as ”Static Floor With Friction”

as indicate for this simulation.

(41)

Figure 4.6: Case Method Overview: EV12 Baseline

3. CdiCheck - Pictures: This section has three folders for the images cor- responding 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 defined in the region.

Figure 4.7: VR07 Viewpoint:

Ground-ISO EV12 Baseline

Figure 4.8: VR08 Viewpoint:

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

(42)

Chapter 4

viewpoints from the ground reference frame.

Figure 4.10: Body Viewpoint:

Ground-Front EV12 Baseline

Figure 4.11: Body Viewpoint:

Ground-ISO EV12 Baseline

Figure 4.12: Body Viewpoint:

Ground-Left EV12 Baseline

Figure 4.13: Body Viewpoint:

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.14: Engine Viewpoint:

Ground-ISO EV12 Baseline

Figure 4.15: Suspension View-

point: Ground-ISO EV12 Base-

line

(43)

Figure 4.16: Wheels Viewpoint:

Ground-ISO EV12 Baseline

Figure 4.17: Subsystems View- point: Ground-Top EV12 Base- 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.

(44)

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 mod- ified 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 mir- ror 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

References

Related documents

För att uppskatta den totala effekten av reformerna måste dock hänsyn tas till såväl samt- liga priseffekter som sammansättningseffekter, till följd av ökad försäljningsandel

Från den teoretiska modellen vet vi att när det finns två budgivare på marknaden, och marknadsandelen för månadens vara ökar, så leder detta till lägre

Generella styrmedel kan ha varit mindre verksamma än man har trott De generella styrmedlen, till skillnad från de specifika styrmedlen, har kommit att användas i större

Parallellmarknader innebär dock inte en drivkraft för en grön omställning Ökad andel direktförsäljning räddar många lokala producenter och kan tyckas utgöra en drivkraft

I dag uppgår denna del av befolkningen till knappt 4 200 personer och år 2030 beräknas det finnas drygt 4 800 personer i Gällivare kommun som är 65 år eller äldre i

På många små orter i gles- och landsbygder, där varken några nya apotek eller försälj- ningsställen för receptfria läkemedel har tillkommit, är nätet av

Detta projekt utvecklar policymixen för strategin Smart industri (Näringsdepartementet, 2016a). En av anledningarna till en stark avgränsning är att analysen bygger på djupa

DIN representerar Tyskland i ISO och CEN, och har en permanent plats i ISO:s råd. Det ger dem en bra position för att påverka strategiska frågor inom den internationella