How To Create A Cdf Optimisation System

A

E

4(2010)2, ISSN 1846-5900

INTERFACES FOR EMBEDDING CFD OPTIMISATION

WORKFLOWS INTO THE PRODUCT DEVELOPMENT

PROCESS

Todorov, G.; Ovcharova, J.; Romanov, B. & Kamberov, K.

Abstract: The study previews and analyses the current state of the art of embedding CFD analysis data into the product development process. An approach for embedding CFD workflows connected to optimisation process is developed, based on the performed analyses. The main target is to enhance the conventional development workflow as to reduce iterations and time. Particular focus is set on the primary step of design models data extraction and transfer to the optimisation module, including numerical model pre-processing. Specifics of data transfer to OpenFOAM platform are examined in connection to the developed in the FLOWHEAD project fluid optimisation module. Complete research results in interface conception based on the proposed combined approach.

Keywords: PDP, CFD, OpenFOAM, approach.

1 INTRODUCTION

Applying optimisation techniques in engineering design processes can improve the performance and quality of existing products and potentially lead to novel designs, which can be crucial in maintaining competitiveness in world markets. The automotive industry has recently past through the change from design processes based on physical prototypes to a computationally aided product development process (PDP) based on virtual prototypes. [1, 3]

Numerical simulation methods (FEM, CFD etc.) used in the frame of CAE are currently well established in the PDP; for each single and small change in design, several iterative and time-consuming loops of numerical simulations are performed. Due to conflicting functionalities the optimum can normally not be identified via this approach. The tools for design optimization became more and more popular in the last few years, due to the integrated approach in the virtual product development. The aim is to increase efficiency and quality of this process and to enable the simultaneous consideration of the high range of functionalities and constraints required in the PDP. These optimal design strategies have to be integrated into the full complexity of the PDP to obtain a highly effective automotive design process. The use of tools for optimization requires a highly automated workflow. In an automated procedure all input data must be well defined to lead to a straight forward workflow. [2, 5]

This paper is based on the proceedings for a successful integration of a CFD optimisation module – subject of project “Fluid Optimisation Workflows for Highly Effective Automotive Development Processes” – in the PDPs that requires initial analysis of existing practices of beneficiaries and associates. Performed analyses of practices of leading automotive companies and possibilities for successful integration of Computational Fluid Dynamics (CFD) optimization could be used as a basis for

subsequent development of specific workflows. General view of the examined processes is shown in Figure 1. The scheme shows main stages of PDP stages and possible embedding of CFD optimisation process. Optimisation process could start with “refined design” or even with several conceptual variants.

Fig. 1. PDPs and CFD optimisation – embedding of workflows

2 INTERFACES PDP TO OPTIMISATION MODULE

Generally, two main interfaces exist in the depicted processes – data extraction from CAD model and data preparation to optimisation module (simulation model). Optimisation of the work for these two interfaces is important as to decrease efforts and facilitate the exchange between design team and simulations engaged engineers. They could also be defined as interface between CAD data and preprocessing and preprocessed data to optimisation module. The first interface should answer to the needs for data extraction from existing CAD format and geometry simplification – clean-up. This concerns mostly the available space determination (for enclosed components) or design line recommendations (for external components). Additional CAD model processing is required very often as to simplify the geometry and to prepare it for next stage – mesh generation. The second interface involves model preparation for the optimisation module – mesh generation and analysis parameters set-up. Transferred data and the stages for these interfaces are shown in Figure 2.

Fig. 2. PDPs to CFD optimisation module interfaces

Examining the above shown structure, two important points emerge – the type of interface file and the number of files. Generally, transfer from CAD model to CFD model could be performed by three types of files:

• Derived standard types: Two main existing derived file types could be

applicable as interface between PDM system and the developing CFD optimisation module:

o CGNS - CFD General Notation System – it provides a standard for recording and recovering computer data associated with the numerical solution of the equations of fluid dynamics;

o STEP - Standard for the Exchange of Product Model Data – also provides CFD data transfer system, especially in its application protocol 237;

Other standard types exist also as IGES, VDA, etc. Generally, derived standard files are widely used in data exchange between CAD and CAE systems. Additional advantage, especially of the above mentioned two formats, is the ability to include specific information as to describe work environment or other requirements.

• Digital Mock-Up (DMU) exchange types as:

o STL – a stereolithography CAD format, using raw unstructured triangulated surfaces, with ASCII and binary (more common and compact) formats. Widely used for CAD to CAM transfer and recently – for transfer to CAE systems.

o CGM – Computer Graphics Metafile – common format for the platform-independent interchange of bitmap and vector data, used primarily to store vector information. CGM uses three types of syntactical encoding formats – Character-based, Binary encoded, Clear-text encoded.

These formats are becoming more widely used in geometry transfer CAD to CAE models. Advantages of this technique is the usage of surface mesh, that could be a basis for subsequent model preprocessing, either using this light geometry version as boundaries for developing design space;

• Native CAD files

Depending on the particular problem, native cad files are also useful as they offer easy and full transfer of data by their associativity. All of the major CAD software offer interface modules for direct model transfer to CFD pre-processor or even mesh generation and direct transfer to CFD solver. The tendency of using native CAD files are strongly supported by CFD software suppliers and it could be a sufficient solution. Certain issues are connected if a geometry preparation is needed, as the CAD modellers are not straight oriented performing such type of operations.

Above brief preview of existing transfer formats shows that CGNS protocol deals only with CFD data, and thus not include geometry data nor optimisation data. STEP AP 237 is more close to complete solution, but it is under development and also requires usage of STEP AP 214 for geometry. Existing practices in leading automotive manufacturers shows active using of STEP format and as it is also developing as future standard, it is most advised one. Derived data format as STEP also has another advance – they are suitable to “outsource” the project – easy interaction with suppliers CAD data systems.

Finally, it could be resumed that usage of STEP AP 214 format, combined with additional description file for CFD specific parameters (in future – with STEP AP 237), is most applicable solution for examined system needs – to bind existing in PDPs CAD data to CFD optimisation module.

3 INTERFACE BETWEEN PREPROCESSING AND OPTIMISATION

MODULE (OPENFOAM). PREVIEW

CFD optimisation module, developed in the 7th Framework programme project “Fluid Optimisation Workflows for Highly Effective Automotive Development Processes” – FLOWHEAD – is planned to be based on OpenFOAM platform. OpenFOAM is supplied with pre- and post-processing environments. The interface to the pre- and post-processing are themselves OpenFOAM utilities, thereby ensuring consistent data handling across all environments. [4] The overall structure of OpenFOAM is shown in Figure 3.

Fig. 3. Overview of OpenFOAM structure

OpenFOAM mainly provides the solver. Thus, interfaces could be provided in different ways, as it is shown in Figure 4 bellow.

Fig. 4. Open source CFD “tool chain”

Focusing on preprocessing, three different approaches are available:

• Using OpenFOAM utilities: three different possibilities exist to generate meshes:

o Directly to describe the mesh (for simple cases);

o By BlockMesh utility – the principle behind blockMesh is to decompose the domain geometry into a set of one or more 3D, hexahedral blocks. Edges of the blocks can be straight lines, arcs or splines. The mesh is ostensibly specified as a number of cells in each direction of the block, sufficient information for blockMesh to generate the mesh data;

o By snappyHexMesh utility – generates 3-dimensional meshes containing hexahedra (hex) and split-hexahedra (split-hex) automatically from triangulated surface geometries in Stereolithography (STL) format. The

mesh approximately conforms to the surface by iteratively refining a starting mesh and morphing the resulting split-hex mesh to the surface;

• Using Open source utilities: Several open source utilities could be integrated as

to obtain mesh input for the OpenFOAM module. For instance, 3D content creation suite as Blender (surface mesh generator) could be integrated with CalculiX as to generate hexagonal grid which to be exported to OpenFOAM. Also, open source solid modelling systems as BRL-CAD, could be combined with 3D grid generators as gmsh;

• Using Commercial applications: Existing commercial applications could be

used for CAD preparation only (combined with other mesher), or entirely for CAD and mesh preparation. Meshes can be generated using other packages and convert them into the format that OpenFOAM uses. There are numerous mesh conversion utilities as:

o ansysToFoam - converts an ANSYS input mesh file;

o fluent3DmeshToFoam, fluentMeshToFoam, foamMeshToFluent –

exchange with Fluent;

o gambitToFoam - converts a GAMBIT mesh to OpenFOAM format

o sammToFoam, star4ToFoam, starToFoam, foamToStarMesh – exchange

with STAR-CD

o other – meshes, generated by KIVA, Adventure system, CFX 4, Gmsh,

Netgen, etc.

Some commercial preprocessors, as ANSA, could directly write an OpenFOAM case file, with mesh, fluid model information, boundary conditions and material properties included. There also other approaches, as for instance to use generated STEP model as input for surface mesher, as ANSA for instance, create surface mesh and generate STL file to be used by rather BlockMesh or snappyHexMesh utilities.

Brief review of these different approaches is presented in Table 1 below.

Type CAD input Used utility Notes

Using OpenFOAM utilities

STL BlockMesh snappyHexMesh

Good application for simple geometry; Requires CAD or CAE tool for complex geometry preparation Using Opensource utilities Blender BRL-CAD Netgen Gmsh

Open source tools are used; 4 stages modelling – geometry export from original CAD system, geometry preparation in CAD open source utility, mesh generation and export to OpenFOAM

Using Commercial applications All exchange formats (STL, STEP, IGES, etc.) STAR-CD ANSYS / Fluent Gambit ANSA

Simpler data processing - export from original CAD system, geometry/mesh preprocessing in CAE software, import in OpenFOAM

Direct OpenFOAM case definition (ANSA) Combined approach STEP, STL ANSA STAR-Design BlockMesh snappyHexMesh

Flexible approach, involving geometry data preparation in original CAD system, surface mesh generation in commercial preprocessor (ANSA or STAR-Design), import in OpenFOAM and volume meshing

Generally, the combined approach, using native CAD system to prepare geometry (CATIA) input (STEP), commercial preprocessor (STAR-Design or ANSA for instance) to prepare initial mesh input (STL) and OpenFOAM mesh utilities (Block Mesh, snappyHexMesh) to prepare mesh model, is the most suitable for the developed optimisation system. Depending on the model complexity, different stages could be excluded. Thus, three sub-approaches could be stated:

- for simple models – direct definition, using OpenFOAM utilities;

- for middle level of complexity – geometry preparation in the native CAD system, STL transfer directly to OpenFOAM utility (snappyHexMesh);

- for complex models – geometry preparation in CAD native system or in specialized CAD tool, neutral export (STEP) to commercial preprocessor (STAR-Design or ANSA) for preparing surface mesh and additional meshing in snappyHexMesh via STL format transfer.

4 INTERFACE CONCEPTION

Complete solution for interfaces conception is developed, based on the above described specific data formats and their parameters. Two interfaces are to be developed:

• PDP stage “Refined Design” to CAD Model (prepared to optimisation):

This interface collects information, connected to CFD analysis, from PDM system. Two variants are possible:

o Two separate models could be used, as it is shown on figure 3 – Geometry model and Non geometry model. STEP AP 214 is well known and widely used format for geometry information transfer. Any other non geometric data could be saved in CGNS format or in similar to STEP AP 237 one. The non geometric data could be written in separate text files as to be processed further to OpenFOAM required format.

o Possible another solution is to use single model, which will include both geometry and non geometry data. Anyway, it will be useful to use data definitions, as for STEP / CGNS formats.

• CAD Model (prepared to optimisation) to CFD model (for optimisation module input):

This interface is based on already created interface, described above, and should contain next main data groups:

o Meshed model(s); o Geometry data;

o Design space (for optimisation); o Material properties (solid and fluid); o Boundary conditions;

o Simulation model data (e.g. turbulence model, wall definitions, etc.). First three groups could be processed and described by a single file, while next data (mainly in text format), should be assigned as parameters and written in suitable file format.

Combined approach could be used to generate mesh model, depending on the model complexity, as it was described in the previous chapter.

General data workflow could be seen in Figure 5 bellow. It describes possible data workflows, depending on the task complexity. Two different approaches are available to obtain CAD input to the mesher – by definition of the design space by the original CAD tool, or using specialized CAD tool. Also, two different inputs in OpenFOAM should be available – through STL formatted file – for surface meshes that are to be processed further in snappyHexMesh utility, or direct 3D mesh input through the available in OpenFOAM conversion utilities.

This structure gives flexibility concerning task level and time needed to prepare the optimisation. Depending on the task level of complexity, the user should be available to choose among various approaches as to reduce time to define the optimisation model in means of geometry description.

Another important point is the processing of the case definition data. Described in external files data for materials, simulation models, etc. should be converted in OpenFOAM format. This will be performed using specialized GUI for needed files creation, which will be next task, outside the current project. Currently, direct files generation will be used as the project focus is mainly in the field of optimisation procedures.

Above described approaches will be used for the planned demonstration cases as to probe their availability.

5 PRACTICAL EXAMPLES

Two test cases, using practical samples, are described bellow, as to present discussed approaches and techniques. First test case includes air duct optimization, based on 2D geometry. Initial geometry is shown on figure 6, as it is defined according to surrounding geometry. 12 points are defined as positions initially. Possible variations in their positions are included in separate files. Thus, the design space is defined directly, by proper parameters’ values. The air duct generally has no complex geometry and the task is in 2D. This makes possible using simple approach by direct definition of the duct (descriptive text file - dictionary, that includes vertices, blocks, patches etc. information) to obtain initial mesh of the geometry.

Fig. 6. 2D air duct. Geometry input

Input text file and resulting initial mesh of the model are shown together on figure 7 bellow, opened in OpenFOAM visualization tool - ParaView. The mesh is generated using built-in mesh module of OpenFOAM – BlockMesh. Generated mesh is used as a start point for further optimization purposes.

Fig. 7. 2D air duct. Prepared initial geometry mesh

This approach is useful for simple geometries definition, where all entities could be defined easily, using available simplified descriptions by base primitives and objects. Nevermind, certain manual work is involved and future automation of the process should be provided.

Similar task, but in 3D, is developed and previewed as sample for optimization input preporcessing. The geometry of the model, shown on figure 8 bellow, is not with high complexity, but is processed by two other possible approaches:

o By STL format conversion;

o By surface mesh generation in commercial preprocessor and input through available convertors in OpenFOAM.

Direct geometry conversion approach by STL involves next steps:

o Initial geometry clean-up and export in STL format – involves certain manual operations, as to simplify geometry and set-up STL export settings;

o Background hex mesh preparation, using blockMesh (defines the extent of the computational domain and a base level mesh density)

o Combining of STL and background meshes by snappyHexMesh tool. This approach is illustrated by the generated STL file for the examined 3D duct, imported in OpenFOAM, shown also on figure 8 bellow, again in paraView tool.

It is important to note that usually, STL format meshes flat surfaces roughly and subsequent mesh optimization should be required. Otherwise, this approach is relatively simple and is fast and applicable for cases where no significant geometry clean-up is needed.

Fig. 8. 3D air duct. Geometry and STL input

Another possible approach, as it is included in chapter 3 above, is to use commercial utilities – for the geometry clean-up and for preprocessing. This approach is illustrated again by a solution for the second demonstration case.

Initially, the geometry could be cleaned-up using the preprocessor utilities (GAMBIT is used for this sample). Next step is to obtain mesh in the same tool and to input it in OpenFOAM media. Existing convertor is used for the last step – gambitToFoam. Various tools are available, including starToFoam. The result is shown on figure 9 bellow, again in paraView tool, OpenFOAM. Next step is to combine the result with the generated by blockMesh background hex mesh.

This possible variant involves less manual operations and could be used also for simple cases. Its universality could be used as to be the sole approach for preparing of the input data for the optimization module. It will require two main interfaces:

o Native CAD file-to-CAE preprocessor: STEP file issued by CAD software to transfer data to CAE preprocessor;

o CAE preprocessor-to-OpenFOAM: Native preprocessor format or STL.

6 CONCLUSION

Current state of the art of embedding CFD analysis data into the product development process is examined in the presented paper. This results in developed approach for embedding CFD workflows connected to optimisation process, where the main goal is to enhance the conventional development workflow by reducing iterations and time. This approach includes 3 possible methods for data extraction and delivery to the numerical analysis module, depending on model complexity. Particularly, the approach involves specifics of data transfer to OpenFOAM platform, which is basis of the developed in the FLOWHEAD project CFD optimisation module.

Presented approach is illustrated by two samples – test cases, extracted from real practice of leading automotive manufacturers. Performed tests show decreased time and efforts for data processing and will be used in future project development.

Acknowledgments:

This research study is performed by the support of 7th Framework programme project “Fluid Optimisation Workflows for Highly Effective Automotive Development Processes” – FLOWHEAD and of project D002–11/05 of National Science Fund, Ministery of Education, Youth and Science, Bulgaria.

References:

[1] Chroneer, Z. (2007). The CFD process for aerodynamics at Volvo cars using

HARPOON-FLUENT, Proceedings of 3rd European Automotive CFD Conference EACC 2007, pp.

25-34, Frankfurt, Germany, 5-6 July 2007

[2] King, M. L.; Fisher, M. J. & Jensen, C. J. (2006). A CAD-centric approach to CFD

analysis with discrete features, Computer-Aided Design & Applications, Vol. 3, Nos. 1-4,

2006, pp 279-288

[3] Lescheticky, J.; Duddeck, F.; Willmes, L. & Girona, S. (2004). Efficient product

development of car bodies using multi-disciplinary optimisation, Numerical Analysis and Simulation, VDI-Report No 1846, pp 583-601

[4] Lewis, R.; Mosedale, A. & Annetts, I. (2009). Using OpenFOAM and ANSA for road and

race car CFD, Proceedings of 3rd ANSA and μETA International Conference, pp. 68-85,

Porto Carras, Halkidiki, Greece, 9-11 September 2009

[5] Sauter, J.; Lauber, B.; Haeussler, P. & Vieker, D. (2003). Structural optimisation –

integration and gaps in workflows of numerical simulation processes. Proceedings of NAFEMS seminar: “Integration of Numerical Simulation into Development Process”, pp.

82-96, Wiesbaden, Germany, 17-18 November 2003 Received: 2010-08-04