Final Report Summary - FLOWHEAD (Fluid optimisation workflows for highly effective automotive development processes)
The automotive industry has recently seen a paradigmatic shift from design processes based on physical prototypes to a computationally aided Product development process (PDP) based on virtual prototypes. To maintain the competitiveness of European car manufacturers, a significant reduction of lead development time is required. The main potential for improvement lies in further exploitation of virtual development and especially in further automation of these virtual processes through optimal design techniques. Optimal design techniques are mature and are being used in routine design for structural mechanics in the automotive industry as the low runtimes of Computational structures (CS) analysis tools lend themselves to be integrated in black-box fashion with simple stochastic optimisation algorithms.
In Computational fluid dynamics (CFD) runtimes are of the order of days for a single analysis which prohibits the use of black-box stochastic algorithms requiring several hundreds of evaluations. Gradient-based algorithms are much more effective and can find the optimum in a much smaller number of evaluations, bringing numerical optimisation with CFD into reach for industrial application. However current commercial CFD solvers only provide the flow field with velocities and pressures from which the goal function that measures the fitness of the design can be calculated. They do not provide gradients of this goal function with respect to the design variables that control the shape and topology.
Adjoint methods have been developed over the past two decades for high-speed compressible flow in the aeronautical industry to compute these gradients at an affordable cost and these methods are now used widely in aeronautical and turbomachinery design. However, this potential has not yet been realised for CFD in the automotive industry. To integrate these methods into workflows within the routine PDP, the project has made significant advances with developing adjoint sensitivity methods for low-speed incompressible flows and coupling these with shape and topology optimisation. Complete CFD optimisation workflows, i.e. chains of optimisation techniques adapted to the automotive processes have been developed and applied to relevant use cases in automotive design.
Major advances have been achieved: the maturity and capabilities of existing adjoint solvers (open-source and commercial) have been substantially improved; new automatic parametrisation methods using grid surface nodes and using CAD variables have been developed; topology optimisation methods for low-speed ducted flows have been improved and enhanced for heat transfer; these methods have been integrated into an industrial workflow environment marketed by an SME that can now be used for industrial applications. Key use cases were defined by the two car manufacturers in the project such as external vehicle aerodynamics, side mirror acoustics, climatisation ducts and electric vehicle battery cooling. The optimisation of these cases has been demonstrated and exhibit a significant reduction in lead time will be validated.
Project context and objectives:
Virtual design techniques in PDP
In the automotive industry, product development processes (PDPs) are currently driven by virtual design techniques. Investigations based on physical prototypes are replaced mainly by Computational aided product development (CAPD); functionalities are analysed via digital mock-up, Computational aided engineering (CAE), and Computational aided prototyping, testing and manufacturing (CAP, CAT, CAM). Full virtual prototypes are developed to cover the full range of requirements to improve simultaneous engineering approaches with its interacting network of CAx tools and to consider functional aspects already in early stages of the PDP. The high degree of complexity and interdisciplinarity in current vehicle development can only be handled by such an integrated chain and network of computational approaches.
These achievements in CAPD have already led to a remarkable reduction in lead development time and related costs, but current market tendencies towards higher modularity, higher product plurality and faster time-to market development require further reduction. For maintaining competitiveness of European car manufacturers, their virtual development has to be improved in scope, robustness and flexibility to be able to react in time to new environmental, societal and market requirements and to take an active role in investigating and realising new technologies. One of the main steps to realise this consists of increasing the efficiency (increased automation, reduced redundancy, improved robustness) and quality (improved model accuracy and higher complexity with acceptable computational cost, adapted to the phases of the PDP) of CAE methods and their implementation into efficient CAE workflows and data management procedures.
Optimisation workflows for reduction of lead development time
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. The development teams work via step-by-step improvements with a high number of redundant processes. New design alternatives are integrated into the models, validated numerically with respect to a high number of functional aspects and finally rejected or accepted. A single of these development steps is normally a time consuming task and might take several days to be realised.
Identification of the best overall compromise by this current approach is a tedious process of equilibrating all constraints and objectives; proneness to errors in modelling, simulation and interpretation are the consequence. Due to conflicting functionalities the optimum can normally not be identified via this approach. This iterative procedure is hence one of the main time-consuming tasks in the PDP and - additionally - it is not goal oriented. Therefore, to increase efficiency and quality of this process, optimisation techniques and workflows should be applied to reduce repetitive work 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.
CAPD refers on the one-hand side to solid mechanics (e.g. finite element methods and multi body systems for crashworthiness, metal forming, driving dynamics) and on the other hand to CFD. The latter comprises numerical methods for example applied to external aerodynamics, exhaust and climate systems, internal combustion engines, interior and exterior acoustics, thermal management, painting, airbag and fuel cell design. In recent years, optimisation methods for solid mechanics were sufficiently developed and integrated into the PDP; they are used in current daily development (Lescheticky 2004, Duddeck 2007). Simultaneous optimisation workflows in the field of crashworthiness, NVH (noise, vibration and harshness) and acoustics were established which combined topology, shape and parameter optimisations. The corresponding workflows were then integrated into the PDP. A similar development in the field of CFD is still not realised. Therefore, one of the main possibilities to shorten development time lies in developing and establishing optimisation workflows especially for fluid problems.
New CFD optimisation workflows for the automotive industry
The conventional development workflow for fluid structures consists of several time-consuming iterations between part designer and CFD engineer. CFD optimisation methods, which are currently available (genetic algorithms, evolutionary strategies), can shortcut this iteration loop. However, due to their enormous computational cost (for e.g. an air duct, around 1,000 variants have to be computed requiring 2 to 3 weeks of computing time on 64 CPUs) and their limited design freedom (even for complex parts, more than 10-15 design parameters are unaffordable), they rarely constitute a significant process improvement as compared to the conventional development workflow. Therefore, these optimisation methods are used only in very particular cases with a more or less prototypic character. The full integration into the PDP is missing; definite development time reduction is not realised. Recent studies inspired from achievements in the aeronautic industry have shown that CFD optimisation workflows based on a different approach, i.e. on adjoint methods, will overcome these problems and will ensure - after integration in workflows and their embedding into the PDP - the full potential in reduction of lead development time of the PDPs.
Objectives of the project
The proposed project focuses therefore on:
1. developing and implementing discrete and continuous adjoint solvers for CFD problems in the automotive industry;
2. developing and implementing optimisation methods (shape and topology) for CFD problems based on these adjoint methods;
3. combining the latter to optimal design workflows (chain of adjoint methods - topology optimisation - shape optimisation); and
4. integrating these workflows into the PDP of the European automotive industries to realise reduction of lead development time.
In contrast to the underlying CFD techniques - they are well established in the automotive industry and are not topic of this proposal - new optimisation procedures (methods and workflows) will be derived and implemented. Because of the different characteristics of the phases of the PDP (strategy, concept and development phases), these optimisation approaches will be adapted to the special applications in the automotive disciplines: In the early phases, principal design concepts have to be determined that lead to robust design decisions which still enable design variability for the latter phases without generating high additional costs. Hence, workflows consisting of a chain of adjoint method - topology optimisation - shape optimisation will be developed for the strategy phase to enable identification of the best principal concepts.
In the later PDP phases, the design is already matured and principally fixed; only slight changes are possible. Optimisation strategies (parametric and non-parametric shape optimisation) for design refinement will be established, which are able to take into account the full complexity with all required constraints, to deliver the final optimal design. The developed concise workflows of adjoint methods and optimisation techniques will be especially designed to consider aspects of manufacturability, user-friendliness, effectiveness, robustness, etc. Interfaces between the different modules will be created and an overall monitoring developed. Finally, the required (and possible) modifications in the PDPs to integrate the derived workflows will be investigated. The developments will be disseminated especially to the OEMs and their partners and via exemplary studies validated with respect to the prior estimations of lead development time reduction. Further possibilities to shorten development time will be identified.
Project results:
The scientific and technological progress will be discussed within the framework of the Work package (WP) structure of the project. WP1 frames the entire project: it defines the application test cases relevant to the industrial application in automotive design. It also considers the overall integration of the methods developed in the other WPs into the existing processes and systems. WP2 develops an integrated optimisation workflow that is suitable for standalone application or for integration into the PDP using the interfaces of WP1. The workflow of WP2 integrates the most important developments of WPs 3-5. The enabling WP is WP3 where improved and novel adjoint solvers are developed; it is this technological advance that makes the entire approach possible. WP4 develops automatic shape parametrisation methods that make use of the efficiency of adjoint solvers for design spaces with many parameters. WP5 extended the adjoint solvers to include heat-transfer effects which allows the approach to be used for battery cooling optimisation of electric vehicles. Finally, WP6 looked at aspects of robust design optimisation methods that are insensitive to uncertainty.
WP1 - Definition of use cases for application and benchmarking
Based on an in-depth analysis of the CFD-related segments of their PDP, the OEM partners of FLOWHEAD specified the requirements for industrial CFD optimisation workflows. These requirements along with the created suite of representative automotive optimisation test cases served as a guideline for the methodological developments within the project, and can be used as benchmark cases for future developments beyond FLOWHEAD. The new methodologies were implemented prototypically into the PDPs in order to assess their performance under 'real-life conditions'. Their application to the suite of test cases was successful. Specifically for fluid dynamic topology optimisation, first applications have already entered routine design at Volkswagen. Furthermore, the experience gained on the test cases allowed to draw conclusions on the necessary modifications of the PDP in order to fully exploit the potential of the new methods and will guide future developments of adjoint-based optimisation techniques.
1.1 Demonstration cases
Characteristics of CFD applications of the PDP and specification of requirements for CFD optimisation workflows
In order to specify the requirements for the methods to be developed in the other WPs, a detailed analysis of the CFD applications within the Volkswagen / Renault PDP was conducted. According to the share of applications between the two OEM partners of FLOWHEAD, this analysis focused at VW on the climatisation and the aerodynamics / aeroacoustics applications and at Renault on the powertrain applications. A series of interviews with colleagues from the relevant departments were carried out. The outcome of these interviews was contributed to (a) the report (D1.1.1) and (b) to the report (D1.2.1) on the PDP interfaces and (c) resulted in the selection (D1.1.2) of validation test cases and relevant objective functions for CFD optimisation. While the definition of objective functions is documented in the report 'EC project FLOWHEAD: Relevant objective functions for fluid dynamic optimisation', the test cases are shown in the 'Final Technical Report' and briefly described in the following.
Demonstration cases for validation of the developments of the other WPs
Nine different test cases for topological and shape optimisation were defined within the first half of the FLOWHEAD project: three-dimensional (3D) S-bend airdurct for cabin ventilation, installation space for airduct (combined topo and shape optimisation), catalytic converter, Volkswagen Passat side mirror (aeroacoustic optimisation), full model of the Volkswagen Passat (drag optimisation), parametric Renault side mirror, parametric Renault concept car, engine intake port, simplified battery cooling plate (thermodynamic optimisation). These test cases were provided to the consortium and served both as an orientation for the methodological developments as well as for the final validation of the developed optimisation methods. The most demanding cases - the full model of the Volkswagen Passat and the airduct installation space definition - were selected for the final validation. Some geometries (S-bend, Renault side mirror) were given in CAD format in order to also allow for CAD-based optimisation as opposed to mesh-based (node-based and morphing) optimisation.
Development of interfaces for embedding CFD optimisation workflows into PDPs
Interfacing to the existing PDP has two major aspects, both of which have been explored in the project. The first one provides an implementation of CFD optimisation workflows into the PDPs is analysed and a general scheme has been developed. The specifics of data transfer between the preprocessing and optimisation module is studied, including the specifics of CAD data processing and used for the optimisation tools. A concept for the specific interfaces of the automotive PDPs is developed, at four geometry preparation approaches and levels of complexity, based on provided analysis of existing automotive industry PDPs. This combined multistep approach for PDP to CFD optimisation data interface is developed, which includes four different techniques, regarding input model specifics. A user-friendly interface, suitable for PDP integration, is developed to enable simple preparation of CFD optimisations - automated assistance of model generation; user-friendly preparations of the optimisations; effective and robust data storage of results, models; compatibility to existing systems. It enables a correct data handling between PDP and workflows as to reduce proneness to errors in definition of optimisation problems. Developed software demonstrator is supplied to project partners for further exploitation.
D2.1.1: Pre-processing: Design a process for the definition of design space based on CAD and DMU data: Design space definition is another important step of model generation. A concept for the process is developed, based on the specifics of the optimisation module and on a preliminary analysis of different possible tools for design space definition. Special focus is set on geometry clean-up stage by the proposed approach, which combines available automated tools and non-automated stage. Another major point is set up on the relevant manufacturing constraints that are identified and analysed basically for plastics and casted components. The entire process for the generation of design spaces for CFD topology optimisation based on CAD and / or DMU data is developed, with embedded manufacturing constraints. Both the concept and studied tools are evaluated through defined project demonstration cases.
Interfaces for embedding optimisation workflows into the PDP for all demonstration cases including documentation
An interface concept was developed, based on the specifics of the input parameters used by the optimisation module core OpenFOAM, and on the existing automotive PDPs. The concept includes different approaches, based on the level of complexity of the examined models. Integration of this concept was performed after validation through already defined demonstration cases. The final step - a new interface tool - covered the initially defined milestone M1.2 which was completed at M24. A typical workflow, as supported by this tool looks as follows:
Step 1: Technical specification (definition, description, CAD data upload).
Step 2: Project receipt (notification, techspec review, project receipt).
Step 3: Model classification.
Step 4: Optimisation CASE DEFINITION.
Step 5: Geometry processing (notification, download of input data, output definition, upload output data).
Step 6: Preprocessing (notification, download input data, define output, upload output data).
Step 7: OpenFOAM case definition (notification, download data, upload output data).
Step 8: Model approval.
Step 9: Model Finalisation (Notification, Download data, Upload Modified Data).
A summary of the achieved objectives is listed below:
- the implementation of CFD optimisation workflows into the PDPs has been analysed and a general concept has been developed;
- the specifics of data transfer between the preprocessing and optimisation module is considered, including the specifics of CAD data processing and used for optimisation OpenFOAM;
- the concept allows for the specific interfaces of the automotive PDPs, at four levels of complexity.
A software tool is developed, based on the proposed combined multistep approach. Major features in the Interface workflow software solution:
- browser-based interface;
- management of groups and users;
- internal and possible mail notifications;
- consistent information in a vault;
- possible connection to external databases;
- open Source (possible customisation).
The developed interface software tool is validated through prototypic demonstration cases; Additional review of the interface tool with particular focus laid to identify further potential of process accelerations, overall robustness and applicability of the developments.
Integration of the optimisation workflows into the PDP, Final validation of the integrated optimisation workflows via the two defined demonstration cases
These two deliverables were grouped into one, comprising both the integration of the workflows into the PDP as well as their validation with the two selected major demonstration cases. The work for these two deliverables was conducted as follows: RSA and VAG delivered the test cases as defined within D1.1.2 to the partners. Within their respective WPs, the partners used the test cases not only as a guide line for the development of their methodologies, but also performed the validation of the developed methods by themselves on the provided industrial test cases.
While these validations took place individually for each WP (i.e. TUM validated their regularisation technique on the VW and Renault test cases within WP4, DTU tested their thermal topology optimisation method on the battery test case within WP5), it was the task of the OEM partners RSA and VAG to perform the validations in a global sense: to apply the combination of the individual methods to the industrial test cases. This combined application necessitated the workflow software developed by FED in WP2, which interfaces with all the individual modules from the other WPs. Once a demonstrator of this software had been delivered, it was installed at RSA and VAG, who then tackled the optimisation test cases with this new tool and evaluated the performance of the workflow software as well as of the individual modules in an industrial environment.
For the considered test cases, both RSA and VAG were able to reproduce the objective improvements as demonstrated by the partners within their individual validations. Not only did the application of the newly developed methods result generally in a higher quality and performance of the investigated part (resp. vehicle) as compared to the conventional way of part design the time necessary to achieve this improved quality is also comparable or even shorter than conventionally (details see D1.3.2). Here, the workflow software developed in WP2 proved to be a useful tool especially for industrial users: it encapsulates the various modules of the different WPs into a single application with a single interface to the user. This is an essential feature for a smooth integration of the developed methodologies into existing industrial processes. Identified shortcomings of the workflow were the following:
Even though it already facilitates the usage of the complex optimisation modules, the workflow is still an error-prone expert tool. Improvements in the ease of use are highly desirable from the industrial end-user point of view.
Robustness of the adjoint solvers has been improved significantly during the project. Still, for complex geometries, it is often a question of parameter-tuning to obtain valid sensitivities from the adjoint solver. More work (both on the side of the software providers and the OEMs) is required in order to extend the best-practice guide developed within WP3 to universally valid recommendations for solution stability.
Manufacturing constraints, especially for topology optimisation, have been addressed in WP5. The workflow software provides the basis infrastructure for their consideration during the optimisation process. However, the state of their implementation can only be considered as preliminary. Future work needs to focus on the industrialisation of this implementation.
Report on the demonstration cases, report on possible further improvements and on recommendable modifications of the PDP
The developed methodologies and their implementation into the PDP were finally assessed based on two major test cases: the full vehicle drag optimisation of the Volkswagen Passat and the combined topo / shape optimisation case for the airduct installation space. Postprocessing has been developed to obtain sensitivity maps for the whole car by applying one of the adjoint solvers from WP3. These show clearly areas where drag decreases when pulled in the outward direction, and regions where drag decreases when pushed inwards. It is this kind of information - sensitivity maps - that constitute the 'unique selling point' of adjoint methods. Conventional methods are simply not capable of delivering such information. As a matter of fact, these maps add a new quality to CFD simulations and provide a wealth of information that was previously unavailable. Concerning their integration into the product development process, it can safely be stated that, at least for the computation of sensitivity maps for external aerodynamics, this integration is straightforward: The adjoint computation is a mere continuation of the regular (i.e. primal) computational process. Its pre-requisites geometry, mesh, input conditions, primal flow result - are all available from the conventional primal computation. It has a requirement for additional computational resources, approximately 12 hours on todays hardware, which still fits into the current time scale of aerodynamic development and does therefore not constitute a burden.
WP2 - Optimisation workflows
The major technical result of FE-DESIGN in the FLOWHEAD project is the development of a framework for an optimisation tool capable to be used for industrial sized problems by users in the industry. Based on the workflow concepts developed in the first period of the project FED focused on the development of this framework during the second period of the project. Together with the optimisation modules developed by project partners the framework realises a so-called industrial demonstrator.
The demonstrator is able to support two different kinds of optimisation approaches:
Topology optimisation
In topology optimisation the target is to get a good design proposal in an early design phase by only providing the available design space. In this case the porosity of each cell is used as a design variable.
Mesh based shape optimisation
For shape optimisation the geometry of the CFD model is changed to reach the requested optimisation target. The displacements of surface vertices are the design variables. Due to the mesh changes methods for regularisation have to be integrated to keep the mesh quality.
For FE-DESIGN a special focus has been the usability and stability of the developed software. The adjoint solvers developed in the project typically require extensive knowledge about the details of the implementation or a rather lengthy and complicated documentation. One target of FE-DESIGN was to realise a framework that helps industrial users, without a detailed understanding of the adjoint theory, to successfully apply the method to their problems.
Further results relevant for the application in industrial processes are the realisation of manufacturing constraints for topology optimisation. Topology optimisation often delivers results that are impossible to transfer to the industrial product development processes without appropriately restricting the solution space. The manufacturing constraints implemented in the FLOWHEAD project and provided within the industrial demonstrator are a first step into the direction of manufacturable results of topology optimisation. The final evaluation of the framework has shown that it provides the necessary mechanisms for targeting industrial users in the sense of usability and assistance while setting up industrial optimisation problems. The user is capable to easily set up an optimisation based on a CFD model and a parameter file that describes the optimisation task. Furthermore it has been shown that complex optimisations with multiple constraints are in principle possible and deliver reasonable results at least for the applied simple test case. None the less there are still a lot of open issues that have to be resolved before successfully applying the developed methods to real industrial problems. This clearly has become apparent when evaluating the framework using an industrial use case. One issue here is that the solution of the adjoint problem is the base for the optimisation and getting reliable and stable sensitivities even for 'low quality' meshes seems to be a necessary precondition for the workflow to get applied.
Developed optimisation workflow:
The workflow for the topology optimisation starts with the start-up of the solver and the optimisation system and enters the design cycle loop. This loop is executed until a defined stop condition is reached. The first action in a design cycle is an update of the design variables. Modules of the framework that change the design variables, like for example manufacturing constraints that work on the design variable field, are executed at this point except in the first design cycle. The final design variables of the current design cycle are then communicated from the optimisation system to the solver using the runtime interface. Since the design variables result only in changes of cell properties, like for example the porosity or the conductivity, the mesh does not change. An update of mesh data within the optimisation system is not required. The CFD solver solves the primal and dual equations and sends the sensitivities to the optimisation system. Pure CFD solver iterations in between two design cycles are indicated by the box OpenFOAM: primal / dual solution. I.e. this box contains multiple CFD solver iterations.
On the right hand side the workflow for the different modules integrated into the demonstrator framework is shown within the box labelled 'Optimisation modules'. Each module operates on the data provided by the framework. The module 'Optimisation algorithm', for example, uses sensitivity information and current design variables to compute updated design variables to be used for the next design cycle.
In case of a complex optimisation task the sensitivities calculated by the dual (adjoint) CFD solver may have to be combined before used as input to the optimiser itself. This is included in the box named 'Sensitivity combination'.
Manufacturing constraints that are implemented as dedicated filtering methods working on the sensitivity fields are executed before passing the sensitivities to the optimisation algorithm. Results can be found in the 'Final Technical Report', improvements in cost function of around 30 % have been achieved.
Post-processing of topology optimisation results
The 'raw' topology optimisation result is a (unchanged) CFD mesh containing a design variable distribution in the design space. For example, this can be a porosity distribution. The design variable distribution is not a 'digital' distribution but a continuous field of values between 0.0 and 1.0. Basically two types of results can be derived from the raw result:
1. Cell set
A subset of the cells contained in the CFD mesh, e.g. all cells with a porosity lower than a certain value. Cell set results typically are useful to get a quick impression of the resulting design.
2. Smooth surfaces
Created as a new surface mesh based for example on ISO surfaces of the design variable distribution. The construction of smooth surfaces is often more expensive in terms of computation time. It is typically used to create final result surfaces after the optimisation is completed.
For both types of results it is necessary to apply some sort of criterion to the design variable distribution. This criterion must decide whether or not a specific cell belongs to the result. To derive a cell set, a criterion could be 'Select all cells that have a porosity value less than a given threshold'.
A smoothened surface output can be applied using all the described result extraction methods and is either used by importing it to a CAD system or for performing an additional simulation / optimisation. The surface can be re-meshed for a validation CFD analysis or to perform a shape optimisation as fine tuning. The surface and volume remeshing steps are relatively straight forward from the workflow point of view but an issue addressed within the project is the reconstruction of the boundary conditions of the original CFD problem. To automate this step the regions for the boundaries have to be identified within the surface representation. This is realised by a STL output format with named groups that can be read by a lot of CFD preprocessors. After this reconstruction step either a validation of the topology design proposal or a succeeding shape optimisation can be performed. An overview of possible steps is shown in the 'Final Technical Report'.
Integration of topology optimisation into industrial demonstrator
The integration of topology optimisation into the industrial demonstrator required the adaptation of two different OpenFOAM adjoint solver implementations. The base adjoint solver has been provided by ICON in WP3. This solver is the default implementation used by the industrial demonstrator. The OpenFOAM adjoint solver for coupled flow and heat transfer problems developed by DTU in WP5 has been integrated as alternative solver, selectable by the solver configuration file of an optimisation job.
Due to the fact that a considerable amount of adaptations in the OpenFOAM adjoint solver code was required for the integration with the industrial demonstrator, the usage of a special OpenFOAM distribution provided by FE-DESIGN is required. A standard OpenFOAM distribution in combination with the adjoint solver packages provided by ICON and DTU is not compatible with the industrial demonstrator.
Manufacturing constraint identification for topology optimisation
For topology optimisation a set of relevant manufacturing constraints has been identified together with the partners VW and RSA. The table below lists the identified manufacturing constraints with their description, motivation and comments on the implementation realised in the industrial demonstrator and with respect to their validation in industrial use-cases. No use case provided in the project was suitable to be used for the evaluation of the symmetry constraint. Therefore it has been evaluated using the topology optimisation of a flow splitter. To get an initially asymmetrical result, different pressure boundary conditions at the outlet have been used. As objective function for the optimisation the total power loss has been used in combination with a volume constraint. The results of an optimisation without and with applied symmetry constraint are shown below.
Both optimisations are converged and the final improvement of the total power loss decreased when specifying the symmetry constraint which is expectable if feasible solution space is limited. A convergence plot for both optimisations is shown in the figure below. For evaluating the undercut prevention the same model has been used. For this case symmetrical pressure boundaries have been used. Optimisation was done with respect to the total power loss and the volume being constraint. The results of the optimisation and the convergence without and with the applied demoulding constraint are shown below. The minimum member size manufacturing constraint has been evaluated in combination with the OpenFOAM adjoint solver for coupled flow and heat transfer. For the optimisation the Navier Stokes equation together with a heat conduction and advection equation is solved. The objective is to keep the temperature within the design space as uniform as possible. In the figure below the optimisation results for an increasing minimum member radius are shown. The radius controls the smallest appearing features in the resulting topology. Additionally for each result the convergence plot is provided.
WP3 - Adjoint solvers
Adjoint solvers are at the core of this project, their ability to compute sensitivities of an arbitrarily large number of design variables at constant cost makes gradient-based CFD optimisation feasible in the first place. The project developed three different types of adjoint solvers, partly to mitigate risk, partly to explore innovative but not yet industrially mature concepts.
The overall objective of task 3.1 is the development of a robust, efficient and versatile open-source solver, based on continuous adjoint, suitable for inclusion into the automotive PDP. Initial development of this solver has been funded by VW and has been further developed in this project. This adjoint code has been integrated into the workflow of WP2 and has been used for the principal demonstration cases.
Task 3.2 performed by ESI group is related to the sensitivity analysis using adjoint methods and in particular the development of a solver-independent continuous adjoint solver suitable for pairing with any of the commercial CFD solvers in the automotive PDP. Task 3.3 involves the development at QMUL of a discrete adjoint Navier-Stokes flow solver, based on the code CFD-ACE+ from ESI by the application of automatic differentiation (AD) tools.
Continuous adjoint solver OpenFOAM
Icons overall objective was the development of a robust, efficient and versatile open-source solver, based on continuous adjoint, suitable for inclusion into the automotive PDP. Several steps were taken in order to achieve this goal. The first step was enhancement of an existing open source adjoint solver by implementing a variety of boundary conditions and cost functions necessary for solving various optimisation problems arising in automotive design cycle. Indicative cases of such problems were provided by the industrial partners for demonstrating the new functionalities. As a second step the solver was further enhanced by including an adjointed version of the Spalart-Allmaras turbulence model, so as to avoid the well-known inaccuracies in the calculated sensitivities that arise when a 'frozen turbulence' assumption is made. This enhancement allowed the solution of aeroacoustic design problems like noise reduction through minimisation of the turbulent kinetic energy. The final step was to make sure that the capabilities of the adjoint solver developed under the previous two steps were industrially useful. This final stage was necessary in order to ensure robustness and stability of the adjoint solver in an industrial environment. Effort was put to improve the non-functional characteristics of the code, since optimal performance is naturally highly advantageous in an industrial context. A best practise user guide was the outcome of this final task. The software and the user guide were provided to the rest of the consortium including the OEMs and were used as the key technology within most WPs enabling further developments for optimisation inclusion in the automotive PDP. Overall Icon's achievement can be summarised as the delivery of an adjoint solver that can tackle a variety of optimisation problems in the complexity of an industrial environment.
Summary of developments for the adjoint turbulence model
Abandoning the assumption of frozen turbulence leads, predictably, to a rather more complex adjoint problem. Because of the complexity of the mathematical expressions involved, the details of the modified adjoint problem will not be presented here. However, we give a brief overview.
There is an additional equation for the adjoint turbulence variable nuATilda with associated boundary conditions, and there are additional terms in the adjoint momentum equation. On the other hand, the adjoint pressure equation is unaffected, and so are the boundary conditions and additional momentum terms arising from the specified cost functions, since only cost functions depending explicitly on the turbulence quantities would introduce additional terms into the system. Hence to apply the adjoint turbulence version of the solver for the cost functions and application scenarios described in the FLOWHEAD technical annex it is enough to activate the adjoint turbulence model while leaving all other settings (i.e. boundary conditions and/or volume cost function switches) the same.
The boundary conditions for the adjoint turbulence variable are relatively straightforward. On solid walls and inlets, the variable vanishes, and while it is non-trivial at outlets, its form only depends on the cost function through the derivative of the boundary integrand wrt the adjoint turbulence variable, which in all the cases we are considering is zero. Hence there is a single boundary condition to be specified at outlets, and fixed value 0 elsewhere.
Summary of investigation and best practices guide and description of provided cases
The work task objective regarding Icons contribution was to address performance issues of the code arising from the user's experiences in WPs 4,5. Consequently, ICON investigated possible settings in order to achieve the efficiency for the required turnaround times.
Test cases for the investigation were provided by both the industrial partners a list of those is included in the deliverable D3.1.3. The goal of this task was to show converged adjoint solutions for the provided test cases and ensure convergence in similar cases. The overall task entailed:
- checking the discretisation schemes fvSchemes, and the solver settings fvSolution;
- define the settings that allow running the adjoint solver on test cases like the provided and of similar complexity;
- deliver a best-practices guide.
More time than originally planned was spenT on this task due to the depth of investigation and the time required to prepare and run such complex cases.
Investigation and representative results
In the relevant sections of the 'Final Technical Report' the investigation towards the most appropriate solver and discretisation settings for the adjoint solver and the 3 most representative cases are summarised. The remaining cases are presented in more details in D3.1.3 deliverable report. The enhanced OpenFOAM solver was successfully applied to external full vehicle cases, side mirror cases and duct geometry cases.
Task 3.2: Solver-independent adjoint, discrete adjoint of commercial flow solvers
After having concluded the separation of the continuous adjoint solver and implementing an automated optimisation process based on ESI proprietary simulation process management tools, extensive testing and optimisation of the process was pursued.
Among several improvements related to interfacing with third party codes some code specific interfaces were developed to ensure that the universal (and preferred) route via Ensight files is indeed reliable. Test cases defined in WP1 were pursed confirming the successful implementation of an independent adjoint solver and an efficient modelling process. Some of the examples and the improvements achieved after one optimisation loop are summarised in the following table:
- advancements and test cases results were presented during ESI global forum and export seminar in Germany, March 2012;
- parallel to the continuous independent adjoint efforts the kernel of a commercially available multi-physics tool - CFD-ACE+ - was adapted to enable automatic differentiation using AD tools. This effort was performed in close collaboration with researchers at QMUL.
Preparation of the ACE+ code
ESI's other main task in WP3 was to prepare a reduced kernel of the commercial multi-physics CFD code ACE+ to allow for automatic differentiation to be performed by QMUL. The task was initially planned in two stages, first application to a very reduced set of equations and functionality, then application to a more complex set.
Significant difficulties were encountered with the ACE+ differentiation, as discussed in the 'Final Technical Report'. The task at ESI was then altered to mainly focus on removing from the code statements and constructs that proved to be non-differentiable by Tapenade. The work was on the following areas:
- support to QMUL with decisions on source tree pruning;
- removal of memory allocation in the iterative loop;
- alterations to database call interface for field pointers.
ESI closely collaborated on the differentiation with QMUL as discussed in the next section. Task 3.3: Derivation of discrete incompressible adjoints using automatic differentiation differentiating the ACE+ incompressible commercial CFD code has been much more challenging than anticipated. The difficulties that were tackled were in three major areas:
Capability of the AD tool
ACE+ is written in Fortran90, the most commonly used AD Tool for F90 is Tapenade by INRIA (www.sop.inria.fr/tropics). However Tapenade was not able to parse ('understand and interpret') the ACE+ code due to a number of coding idiosyncrasies in ACE+ (e.g. use of call interfaces without dummy variables, instead queries into a database of allocated arrays returning pointers.), as well as inherent limitations with AD e.g. when dealing with pointers. In addition Tapenade at the beginning of the project was not sufficiently mature to deal with complexity of ACE+ and the range of F90 language elements that were used. This resulted in a large number of bugs (e.g. modules) when calling Tapenade on the initial ACE code. A number of avenues to remedy this were explored.
As alternative to the complex structure of ACE+, a simpler in-house code (gpde) was constructed from scratch that uses the same discretisation type (face-based incompressible SIMPLE scheme) as ACE+, is also written in F90, but has a more limited volume (fewer robustness/accuracy enhancing additions, simpler iterative solver) and a clearer argument passing method. This simpler code could then be modified to be suitable for Tapenade and the overall methodology could be developed using this bench code. See also the next subsection on gpde.
Alternative AD tools to Tapenade were explored. There is a commercial AD tool TAF from www.fastopt.de. However their business model is less to sell licenses for the AD tool, but rather to apply AD using their in-house tool to customer's codes. This approach was not budgeted for in FLOWHEAD.
The team around advisory board member Prof. Naumann develops operator-overloading AD tools (o-o AD). In o-o AD the code statements and arguments of the primal code are logged to a tape during the forward run of the primal, then differentiated in reverse from that tape. This is in contrast to the source-transformation AD of Tapenade (s-t AD) where the code is parsed at compile time and the actual source of the code is differentiated. O-o AD does not have the same issues as s-t AD with complex coding structures, but is much more limited in producing efficient adjoint code.
The team at QMUL collaborated with Prof. Naumann's team and developed a simple o-o adjoint of the gpde code which worked successfully. However improving the performance to acceptable levels for this simple code proved extremely difficult and being able to scale this methodology up to the entire ACE+ code seemed improbable without having access to and extensive experience with the o-o AD tool.
In parallel steady progress was made with the developing team of Tapenade at INRIA on resolving bugs in Tapenade brought up by the application to ACE+. Some issues with or design choices of Tapenade have been circumvented with scripting (see following subsection), all remaining bugs have been resolved by the end of 2011 and Tapenade has been successfully demonstrated on ACE+ in tangent-linear mode.
Discretisation of incompressible CFD codes
There is extensive knowledge on how to differentiate compressible flow solvers which use a fully coupled iterative scheme that advances all equations in the same way. Effective adjoint variants of this time-stepping can be devised as demonstrated in WP6. The common incompressible discretisation is the SIMPLE scheme which uses a two-stage predictor-corrector method where the momentum and pressure equations are discretised separately and loosely coupled through a projection step.
Applying the same approach as in the compressible fully-coupled discretisation also to the SIMPLE scheme would lead to a fully coupled scheme which may offer convergence benefits, but would require significantly more memory. The popularity of the SIMPLE scheme precisely stems from the fact that it does not require fully coupled storage while offering a very good convergence rate. Hence a fully-coupled adjoint would have unacceptable memory costs and has hence been disregarded.
An alternative is to apply 'brute-force' differentiation to the SIMPLE iterative step. The main elements of thIs step are a number of linear system solves, one for each momentum component solving a decoupled forced advection-diffusion equation, and one solving a Poisson problem for the pressure in a pressure-correction step. In the work by Oezkaya et al, the differentiation was also applied through these linear solves, resulting in significant complexity and a substantial computational overhead with poor runtimes.
In developing gpde we have hence chosen a novel and alternative approach. Linear systems are, by definition, linear and hence the differentiation of a linear solver is equivalent to solving the primal linear system with the perturbation of the right hand side as the right hand side. Hence we can substitute a simple but ineffective linear solver before submitting to AD, AD then traces the correct dependency of the variables, and then put the efficient linear solver back in with modified arguments when re-assembling the code. This will result in ideal performance identical to the primal solver for the linear system solves. The gpde solver indeed a achieves a run-time and memory cost of 2x the primal solver, which is optimal as 2 full sets of pdes, the primal and the adjoint are solved for.
Key results obtained with gpde on the S-Bend test case are shown for various Reynolds numbers in the following figures. The flow is attached after the S-Bend and both primal and adjoint solutions converge without problems for the standard low-Re case.
Increasing the Reynolds number by a factor of 10 to Re equal to 600, or an inlet velocity of 1 m / s results in a more problematic convergence. The primal converges partly, but then gets stuck in limit cycles. The flow field exhibits a large separation bubble right after the bend. The adjoint solution converges, but with a less stable convergence history. The surface sensitivities show a similar pattern to the lower Re, but one now finds a pronounced region at the sides of the bend where the geometry should be pushed in to reduce pressure drop. Shape optimisation results with this geometry are shown in the results for WP4.
This Re number represents the limit of stability, increasing it further will make the separation bubble unstable, the primal flow will only converge to an irregular limit cycle dominated by periodic detachment of the separation bubble. As a consequence, the discrete adjoint which bases its Jacobian on an arbitrary frozen snapshot of the primal, is also unstable and diverges. The next step of development in follow-up research is to develop unsteady adjoint methods.
Application to commercial ACE+ code
Even with improved maturity and a number of bug fixes, Tapenade will not be able to parse the ACE+ code 'out of the box'. A pre-processing methodology was developed that performs the following operations:
- Removal of irrelevant 'dead' code: certain code functionality are not to be differentiated and hence are pruned from the source code tree. Examples for such code is diagnostics, or special physical models such as icing, porous media, which are not of interest at this stage. Dead is wrapped into pragmas and permanently removed from the adjoint source. Removal of non-differentiated code: code such as screen printout, input/output should not be differentiated, but needs to be re-inserted into the final code. A second type of pragmas achieves this.
- Alternative code: hand-derived alternatives are provided e.g. for the linear solvers. Pragmas with if-else structure achieve this, substituting simple template code during differentiation and linear solver calls with modified argument lists for the adjoint version. The main difficulty is the first step, pruning dead code, but dead code only and obtaining a complete set of primal subroutines. In industrial legacy codes, the structure is often convoluted and complex, with many subroutines being generically written and re-used in various contexts. E.g. the manually reduced first set of ACE routines contains 680 files, 230 K lines or 8 MB of source code.
Relying on Tapenade's error messages of missing dependencies is not an appropriate approach to arrive at a complete source tree since each Tapenade differentiation run takes about 20 min runtime, considering the complexity of the source tree this becomes a prohibitive task. A semi-automatic loop was constructed in which the log files of Tapenade and the gprof code profiler are compared. The profiler very rapidly establishes a list of executed functions which can then be compared to the current version of the pruned source tree. Missing dependencies then need to be manually equipped with the appropriate pragmas and added to the source tree.
Once differentiation is completed, the source code for the adjoint needs to be re-assembled. Substituted source code such as linear solver calls need to be substituted back in. We also find it necessary to override Tapenade's behaviour to duplicate module definitions in a differentiated module. This behaviour leads to conflicting differentiated module definitions when differentiating a module multiple times w.r.t. different input variables as arises e.g. when differentiating a residual assembly routine w.r.t. the flow variables in the iterative loop, but differentiating it w.r.t. the face metrics to project the sensitivities onto the design surface once the adjoint solution is converged. As an alternative, scripting is used to copy the additional elements of the differentiated module definition into the primal module.
WP4 - Shape parametrisation
WP4 develops new shape parametrisation methods for CFD optimisation in the automotive industry. The aim of the WP was to develop all the necessary numerical methods for improving the design of industrial parts which are exposed to fluid flow. For instance, one of the main targets of shape optimisation is to change the shape of parts of a car such that its aerodynamic behaviour is improved or, in internal aerodynamics the minimisation of the pressure drop in pipe systems is of major importance. By making such a process systematic and efficient the optimisation can be a procedure integrated in the overall design process.
Node-based parametrisation
One task was to develop the methods as well as the efficient realisation of them for the parameter-free shape optimisation approach. Within this technique one can optimise complex shapes and free-form geometries and no additional control on the shape needs to be specified. Because of the fact that the optimised shape is not restricted and controlled by the user the resulting shapes are innovative and high improvements can be achieved. However, since no predefined control on the way that the shape modes are defined additional attention has to be given on avoiding unphysical resulting shapes. This is done by the developed 'out-plane regularisation method'. The method applies a filter so that the noisy modes are smoothed out. Besides the fact that the shape should be physical, the method has to guarantee that the change on the shape does not cause numerical discrepancies. The 'in-plane regularisation method' guaranties the numerical plausibility of such a problem.
Both in-plane and out-plane methods were tested successfully in benchmarks provided by the automotive industry.
Node-based parametrisation: in plane regularisation
In-plane regularisation is applied on the bounding design surface. Surface elements are identical to the faces of the CFD model which are located on the boundary. Topology of the surface elements (nodes and connectivity) is given to the in-plane regularisation module and this module modifies the position of the surface nodes such that the mesh has a better quality. As mentioned before, in-plane regularisation moves the nodes tangential to surface and therefore the surface geometry remains unchanged.
There is no limitation in the surface geometry neither in the number of nodes per element and since in-plane regularisation is solved only on the surface nodes, and only a linear step is performed, the computation time is much smaller compared to other modules of the optimisation loop.
In-plane regularisation can be used both for quality improvement of an existing mesh as a post-processing step or for maintaining the quality of the mesh during several design updates. Quality improvement is done based on the users desired mesh-quality measure. The second application (quality maintenance) is the main focus in FLOWHEAD project and tries to keep the initial properties of the mesh after design updates. Design update refers to any type of geometrical change such as rotations, bulk motion, curving, flattening, etc. Another important aspect is removing the possible in-plane noise existing in the surface mesh due to the design update proposed by the optimiser.
This technique is based on applying an artificial pre-stress field on the surface mesh, in an arbitrary reference configuration. Choice of this configuration determines the type of element geometry to be dominant in the domain. This is done by introducing an ideal element shape as the 'target element'. In-plane regularisation rearranges the position of nodes (preserving the original connectivity) such that the individual element shapes are as close as possible to the target element, in the global sense. In the case of quality maintenance, the ideal element is nothing but the original element shape (before any design update).
More details about in-plane regularisation, together with some examples showing the performance of this module can be found in the project's server.
Node-based parametrisation: out-of plane regularisation
Like in-plane regularisation module, out-of-plane regularisation is also developed and implemented in Carat++. The goal of this tool is to filter the normal-to-surface sensitivities. This step removes the noise from the sensitivity field and this prevents a noisy updated surface. Filtering can be also used in order to control the design process with the respect to the minimum geometrical detail size, based on the filter dimension. It should be mentioned that the sensitivity values are reported normal to the surface and therefore they are treated as a scalar field defined on the boundary surface.
There are different filter functions available. Furthermore, by proper selection of the filter size and number of filtering steps one can have a good control on the geometrical characteristics of the final design. The average number of neighbouring points which take part in the filtering is reported by the software and has to be considered as well. The out-plane regularisation is a separate part of the optimisation workflow which gets row sensitivities and delivers back a smooth sensitivity field. So no combination with in-plane regularisation is needed which makes the whole optimisation chain more modular and flexible.
In addition to the planned deliverables, TUM has delivered additional software for in-plane and out-plane regularisation, so the partners can perform local execution of the regularisation module within the project (independent of the overall optimisation workflow and the central database). This additional software use simple ASCII files to read the geometry as an alternative to the central database functions. The actual software, the user manual, as well as several examples are uploaded to the project's server.
Integration of the regularisation in the optimisation workflow
In this deliverable the methods of in-plane and out-of-plane regularisation, which have been already tested in the previous deliverables are integrated to the optimisation workflow. More precisely, in the core of the optimisation program an application programming interface (API) was implemented. The API functions enable the interaction with the in-plane and out-plane modules. These modules where connected to the API interface as a static c++ library. The library offers the access to a main regularisation object which can be initialised and sequentially perform the in-plane and out-plane actions. More details about the interface with the optimisation workflow as well as descriptive examples are uploaded to the projects server.
Principal concept tests
After developing the different modules, the optimisation workflow was created by bringing all the individual pieces together using an API interface. Here, this framework is tested with the benchmark examples provided by simple examples created by TUM and more involved examples given by VW. In the following two examples are presented: one for external and one for internal aerodynamics.
In the first example the performance of mesh control (in and out plane regularisation) was tested by applying the workflow on a circular cylinder subject to lateral fluid flow. Minimisation of the drag is the objective. As it can be seen in the following figure the quality of the mesh and smoothness of the surface is retained until the trivial optimised shape of an extremely thin geometry.
In the next example, the main benchmark of the project which is a 3-dimensional S-bend duct used for rear seat ventilation provided by VW is studied. In this geometry two optimisation cases were studied: one with the whole surface pipe as a design surface and one where only the bend part was allowed to change during optimisation.
List of websites: http://flowhead.sems.qmul.ac.uk
In Computational fluid dynamics (CFD) runtimes are of the order of days for a single analysis which prohibits the use of black-box stochastic algorithms requiring several hundreds of evaluations. Gradient-based algorithms are much more effective and can find the optimum in a much smaller number of evaluations, bringing numerical optimisation with CFD into reach for industrial application. However current commercial CFD solvers only provide the flow field with velocities and pressures from which the goal function that measures the fitness of the design can be calculated. They do not provide gradients of this goal function with respect to the design variables that control the shape and topology.
Adjoint methods have been developed over the past two decades for high-speed compressible flow in the aeronautical industry to compute these gradients at an affordable cost and these methods are now used widely in aeronautical and turbomachinery design. However, this potential has not yet been realised for CFD in the automotive industry. To integrate these methods into workflows within the routine PDP, the project has made significant advances with developing adjoint sensitivity methods for low-speed incompressible flows and coupling these with shape and topology optimisation. Complete CFD optimisation workflows, i.e. chains of optimisation techniques adapted to the automotive processes have been developed and applied to relevant use cases in automotive design.
Major advances have been achieved: the maturity and capabilities of existing adjoint solvers (open-source and commercial) have been substantially improved; new automatic parametrisation methods using grid surface nodes and using CAD variables have been developed; topology optimisation methods for low-speed ducted flows have been improved and enhanced for heat transfer; these methods have been integrated into an industrial workflow environment marketed by an SME that can now be used for industrial applications. Key use cases were defined by the two car manufacturers in the project such as external vehicle aerodynamics, side mirror acoustics, climatisation ducts and electric vehicle battery cooling. The optimisation of these cases has been demonstrated and exhibit a significant reduction in lead time will be validated.
Project context and objectives:
Virtual design techniques in PDP
In the automotive industry, product development processes (PDPs) are currently driven by virtual design techniques. Investigations based on physical prototypes are replaced mainly by Computational aided product development (CAPD); functionalities are analysed via digital mock-up, Computational aided engineering (CAE), and Computational aided prototyping, testing and manufacturing (CAP, CAT, CAM). Full virtual prototypes are developed to cover the full range of requirements to improve simultaneous engineering approaches with its interacting network of CAx tools and to consider functional aspects already in early stages of the PDP. The high degree of complexity and interdisciplinarity in current vehicle development can only be handled by such an integrated chain and network of computational approaches.
These achievements in CAPD have already led to a remarkable reduction in lead development time and related costs, but current market tendencies towards higher modularity, higher product plurality and faster time-to market development require further reduction. For maintaining competitiveness of European car manufacturers, their virtual development has to be improved in scope, robustness and flexibility to be able to react in time to new environmental, societal and market requirements and to take an active role in investigating and realising new technologies. One of the main steps to realise this consists of increasing the efficiency (increased automation, reduced redundancy, improved robustness) and quality (improved model accuracy and higher complexity with acceptable computational cost, adapted to the phases of the PDP) of CAE methods and their implementation into efficient CAE workflows and data management procedures.
Optimisation workflows for reduction of lead development time
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. The development teams work via step-by-step improvements with a high number of redundant processes. New design alternatives are integrated into the models, validated numerically with respect to a high number of functional aspects and finally rejected or accepted. A single of these development steps is normally a time consuming task and might take several days to be realised.
Identification of the best overall compromise by this current approach is a tedious process of equilibrating all constraints and objectives; proneness to errors in modelling, simulation and interpretation are the consequence. Due to conflicting functionalities the optimum can normally not be identified via this approach. This iterative procedure is hence one of the main time-consuming tasks in the PDP and - additionally - it is not goal oriented. Therefore, to increase efficiency and quality of this process, optimisation techniques and workflows should be applied to reduce repetitive work 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.
CAPD refers on the one-hand side to solid mechanics (e.g. finite element methods and multi body systems for crashworthiness, metal forming, driving dynamics) and on the other hand to CFD. The latter comprises numerical methods for example applied to external aerodynamics, exhaust and climate systems, internal combustion engines, interior and exterior acoustics, thermal management, painting, airbag and fuel cell design. In recent years, optimisation methods for solid mechanics were sufficiently developed and integrated into the PDP; they are used in current daily development (Lescheticky 2004, Duddeck 2007). Simultaneous optimisation workflows in the field of crashworthiness, NVH (noise, vibration and harshness) and acoustics were established which combined topology, shape and parameter optimisations. The corresponding workflows were then integrated into the PDP. A similar development in the field of CFD is still not realised. Therefore, one of the main possibilities to shorten development time lies in developing and establishing optimisation workflows especially for fluid problems.
New CFD optimisation workflows for the automotive industry
The conventional development workflow for fluid structures consists of several time-consuming iterations between part designer and CFD engineer. CFD optimisation methods, which are currently available (genetic algorithms, evolutionary strategies), can shortcut this iteration loop. However, due to their enormous computational cost (for e.g. an air duct, around 1,000 variants have to be computed requiring 2 to 3 weeks of computing time on 64 CPUs) and their limited design freedom (even for complex parts, more than 10-15 design parameters are unaffordable), they rarely constitute a significant process improvement as compared to the conventional development workflow. Therefore, these optimisation methods are used only in very particular cases with a more or less prototypic character. The full integration into the PDP is missing; definite development time reduction is not realised. Recent studies inspired from achievements in the aeronautic industry have shown that CFD optimisation workflows based on a different approach, i.e. on adjoint methods, will overcome these problems and will ensure - after integration in workflows and their embedding into the PDP - the full potential in reduction of lead development time of the PDPs.
Objectives of the project
The proposed project focuses therefore on:
1. developing and implementing discrete and continuous adjoint solvers for CFD problems in the automotive industry;
2. developing and implementing optimisation methods (shape and topology) for CFD problems based on these adjoint methods;
3. combining the latter to optimal design workflows (chain of adjoint methods - topology optimisation - shape optimisation); and
4. integrating these workflows into the PDP of the European automotive industries to realise reduction of lead development time.
In contrast to the underlying CFD techniques - they are well established in the automotive industry and are not topic of this proposal - new optimisation procedures (methods and workflows) will be derived and implemented. Because of the different characteristics of the phases of the PDP (strategy, concept and development phases), these optimisation approaches will be adapted to the special applications in the automotive disciplines: In the early phases, principal design concepts have to be determined that lead to robust design decisions which still enable design variability for the latter phases without generating high additional costs. Hence, workflows consisting of a chain of adjoint method - topology optimisation - shape optimisation will be developed for the strategy phase to enable identification of the best principal concepts.
In the later PDP phases, the design is already matured and principally fixed; only slight changes are possible. Optimisation strategies (parametric and non-parametric shape optimisation) for design refinement will be established, which are able to take into account the full complexity with all required constraints, to deliver the final optimal design. The developed concise workflows of adjoint methods and optimisation techniques will be especially designed to consider aspects of manufacturability, user-friendliness, effectiveness, robustness, etc. Interfaces between the different modules will be created and an overall monitoring developed. Finally, the required (and possible) modifications in the PDPs to integrate the derived workflows will be investigated. The developments will be disseminated especially to the OEMs and their partners and via exemplary studies validated with respect to the prior estimations of lead development time reduction. Further possibilities to shorten development time will be identified.
Project results:
The scientific and technological progress will be discussed within the framework of the Work package (WP) structure of the project. WP1 frames the entire project: it defines the application test cases relevant to the industrial application in automotive design. It also considers the overall integration of the methods developed in the other WPs into the existing processes and systems. WP2 develops an integrated optimisation workflow that is suitable for standalone application or for integration into the PDP using the interfaces of WP1. The workflow of WP2 integrates the most important developments of WPs 3-5. The enabling WP is WP3 where improved and novel adjoint solvers are developed; it is this technological advance that makes the entire approach possible. WP4 develops automatic shape parametrisation methods that make use of the efficiency of adjoint solvers for design spaces with many parameters. WP5 extended the adjoint solvers to include heat-transfer effects which allows the approach to be used for battery cooling optimisation of electric vehicles. Finally, WP6 looked at aspects of robust design optimisation methods that are insensitive to uncertainty.
WP1 - Definition of use cases for application and benchmarking
Based on an in-depth analysis of the CFD-related segments of their PDP, the OEM partners of FLOWHEAD specified the requirements for industrial CFD optimisation workflows. These requirements along with the created suite of representative automotive optimisation test cases served as a guideline for the methodological developments within the project, and can be used as benchmark cases for future developments beyond FLOWHEAD. The new methodologies were implemented prototypically into the PDPs in order to assess their performance under 'real-life conditions'. Their application to the suite of test cases was successful. Specifically for fluid dynamic topology optimisation, first applications have already entered routine design at Volkswagen. Furthermore, the experience gained on the test cases allowed to draw conclusions on the necessary modifications of the PDP in order to fully exploit the potential of the new methods and will guide future developments of adjoint-based optimisation techniques.
1.1 Demonstration cases
Characteristics of CFD applications of the PDP and specification of requirements for CFD optimisation workflows
In order to specify the requirements for the methods to be developed in the other WPs, a detailed analysis of the CFD applications within the Volkswagen / Renault PDP was conducted. According to the share of applications between the two OEM partners of FLOWHEAD, this analysis focused at VW on the climatisation and the aerodynamics / aeroacoustics applications and at Renault on the powertrain applications. A series of interviews with colleagues from the relevant departments were carried out. The outcome of these interviews was contributed to (a) the report (D1.1.1) and (b) to the report (D1.2.1) on the PDP interfaces and (c) resulted in the selection (D1.1.2) of validation test cases and relevant objective functions for CFD optimisation. While the definition of objective functions is documented in the report 'EC project FLOWHEAD: Relevant objective functions for fluid dynamic optimisation', the test cases are shown in the 'Final Technical Report' and briefly described in the following.
Demonstration cases for validation of the developments of the other WPs
Nine different test cases for topological and shape optimisation were defined within the first half of the FLOWHEAD project: three-dimensional (3D) S-bend airdurct for cabin ventilation, installation space for airduct (combined topo and shape optimisation), catalytic converter, Volkswagen Passat side mirror (aeroacoustic optimisation), full model of the Volkswagen Passat (drag optimisation), parametric Renault side mirror, parametric Renault concept car, engine intake port, simplified battery cooling plate (thermodynamic optimisation). These test cases were provided to the consortium and served both as an orientation for the methodological developments as well as for the final validation of the developed optimisation methods. The most demanding cases - the full model of the Volkswagen Passat and the airduct installation space definition - were selected for the final validation. Some geometries (S-bend, Renault side mirror) were given in CAD format in order to also allow for CAD-based optimisation as opposed to mesh-based (node-based and morphing) optimisation.
Development of interfaces for embedding CFD optimisation workflows into PDPs
Interfacing to the existing PDP has two major aspects, both of which have been explored in the project. The first one provides an implementation of CFD optimisation workflows into the PDPs is analysed and a general scheme has been developed. The specifics of data transfer between the preprocessing and optimisation module is studied, including the specifics of CAD data processing and used for the optimisation tools. A concept for the specific interfaces of the automotive PDPs is developed, at four geometry preparation approaches and levels of complexity, based on provided analysis of existing automotive industry PDPs. This combined multistep approach for PDP to CFD optimisation data interface is developed, which includes four different techniques, regarding input model specifics. A user-friendly interface, suitable for PDP integration, is developed to enable simple preparation of CFD optimisations - automated assistance of model generation; user-friendly preparations of the optimisations; effective and robust data storage of results, models; compatibility to existing systems. It enables a correct data handling between PDP and workflows as to reduce proneness to errors in definition of optimisation problems. Developed software demonstrator is supplied to project partners for further exploitation.
D2.1.1: Pre-processing: Design a process for the definition of design space based on CAD and DMU data: Design space definition is another important step of model generation. A concept for the process is developed, based on the specifics of the optimisation module and on a preliminary analysis of different possible tools for design space definition. Special focus is set on geometry clean-up stage by the proposed approach, which combines available automated tools and non-automated stage. Another major point is set up on the relevant manufacturing constraints that are identified and analysed basically for plastics and casted components. The entire process for the generation of design spaces for CFD topology optimisation based on CAD and / or DMU data is developed, with embedded manufacturing constraints. Both the concept and studied tools are evaluated through defined project demonstration cases.
Interfaces for embedding optimisation workflows into the PDP for all demonstration cases including documentation
An interface concept was developed, based on the specifics of the input parameters used by the optimisation module core OpenFOAM, and on the existing automotive PDPs. The concept includes different approaches, based on the level of complexity of the examined models. Integration of this concept was performed after validation through already defined demonstration cases. The final step - a new interface tool - covered the initially defined milestone M1.2 which was completed at M24. A typical workflow, as supported by this tool looks as follows:
Step 1: Technical specification (definition, description, CAD data upload).
Step 2: Project receipt (notification, techspec review, project receipt).
Step 3: Model classification.
Step 4: Optimisation CASE DEFINITION.
Step 5: Geometry processing (notification, download of input data, output definition, upload output data).
Step 6: Preprocessing (notification, download input data, define output, upload output data).
Step 7: OpenFOAM case definition (notification, download data, upload output data).
Step 8: Model approval.
Step 9: Model Finalisation (Notification, Download data, Upload Modified Data).
A summary of the achieved objectives is listed below:
- the implementation of CFD optimisation workflows into the PDPs has been analysed and a general concept has been developed;
- the specifics of data transfer between the preprocessing and optimisation module is considered, including the specifics of CAD data processing and used for optimisation OpenFOAM;
- the concept allows for the specific interfaces of the automotive PDPs, at four levels of complexity.
A software tool is developed, based on the proposed combined multistep approach. Major features in the Interface workflow software solution:
- browser-based interface;
- management of groups and users;
- internal and possible mail notifications;
- consistent information in a vault;
- possible connection to external databases;
- open Source (possible customisation).
The developed interface software tool is validated through prototypic demonstration cases; Additional review of the interface tool with particular focus laid to identify further potential of process accelerations, overall robustness and applicability of the developments.
Integration of the optimisation workflows into the PDP, Final validation of the integrated optimisation workflows via the two defined demonstration cases
These two deliverables were grouped into one, comprising both the integration of the workflows into the PDP as well as their validation with the two selected major demonstration cases. The work for these two deliverables was conducted as follows: RSA and VAG delivered the test cases as defined within D1.1.2 to the partners. Within their respective WPs, the partners used the test cases not only as a guide line for the development of their methodologies, but also performed the validation of the developed methods by themselves on the provided industrial test cases.
While these validations took place individually for each WP (i.e. TUM validated their regularisation technique on the VW and Renault test cases within WP4, DTU tested their thermal topology optimisation method on the battery test case within WP5), it was the task of the OEM partners RSA and VAG to perform the validations in a global sense: to apply the combination of the individual methods to the industrial test cases. This combined application necessitated the workflow software developed by FED in WP2, which interfaces with all the individual modules from the other WPs. Once a demonstrator of this software had been delivered, it was installed at RSA and VAG, who then tackled the optimisation test cases with this new tool and evaluated the performance of the workflow software as well as of the individual modules in an industrial environment.
For the considered test cases, both RSA and VAG were able to reproduce the objective improvements as demonstrated by the partners within their individual validations. Not only did the application of the newly developed methods result generally in a higher quality and performance of the investigated part (resp. vehicle) as compared to the conventional way of part design the time necessary to achieve this improved quality is also comparable or even shorter than conventionally (details see D1.3.2). Here, the workflow software developed in WP2 proved to be a useful tool especially for industrial users: it encapsulates the various modules of the different WPs into a single application with a single interface to the user. This is an essential feature for a smooth integration of the developed methodologies into existing industrial processes. Identified shortcomings of the workflow were the following:
Even though it already facilitates the usage of the complex optimisation modules, the workflow is still an error-prone expert tool. Improvements in the ease of use are highly desirable from the industrial end-user point of view.
Robustness of the adjoint solvers has been improved significantly during the project. Still, for complex geometries, it is often a question of parameter-tuning to obtain valid sensitivities from the adjoint solver. More work (both on the side of the software providers and the OEMs) is required in order to extend the best-practice guide developed within WP3 to universally valid recommendations for solution stability.
Manufacturing constraints, especially for topology optimisation, have been addressed in WP5. The workflow software provides the basis infrastructure for their consideration during the optimisation process. However, the state of their implementation can only be considered as preliminary. Future work needs to focus on the industrialisation of this implementation.
Report on the demonstration cases, report on possible further improvements and on recommendable modifications of the PDP
The developed methodologies and their implementation into the PDP were finally assessed based on two major test cases: the full vehicle drag optimisation of the Volkswagen Passat and the combined topo / shape optimisation case for the airduct installation space. Postprocessing has been developed to obtain sensitivity maps for the whole car by applying one of the adjoint solvers from WP3. These show clearly areas where drag decreases when pulled in the outward direction, and regions where drag decreases when pushed inwards. It is this kind of information - sensitivity maps - that constitute the 'unique selling point' of adjoint methods. Conventional methods are simply not capable of delivering such information. As a matter of fact, these maps add a new quality to CFD simulations and provide a wealth of information that was previously unavailable. Concerning their integration into the product development process, it can safely be stated that, at least for the computation of sensitivity maps for external aerodynamics, this integration is straightforward: The adjoint computation is a mere continuation of the regular (i.e. primal) computational process. Its pre-requisites geometry, mesh, input conditions, primal flow result - are all available from the conventional primal computation. It has a requirement for additional computational resources, approximately 12 hours on todays hardware, which still fits into the current time scale of aerodynamic development and does therefore not constitute a burden.
WP2 - Optimisation workflows
The major technical result of FE-DESIGN in the FLOWHEAD project is the development of a framework for an optimisation tool capable to be used for industrial sized problems by users in the industry. Based on the workflow concepts developed in the first period of the project FED focused on the development of this framework during the second period of the project. Together with the optimisation modules developed by project partners the framework realises a so-called industrial demonstrator.
The demonstrator is able to support two different kinds of optimisation approaches:
Topology optimisation
In topology optimisation the target is to get a good design proposal in an early design phase by only providing the available design space. In this case the porosity of each cell is used as a design variable.
Mesh based shape optimisation
For shape optimisation the geometry of the CFD model is changed to reach the requested optimisation target. The displacements of surface vertices are the design variables. Due to the mesh changes methods for regularisation have to be integrated to keep the mesh quality.
For FE-DESIGN a special focus has been the usability and stability of the developed software. The adjoint solvers developed in the project typically require extensive knowledge about the details of the implementation or a rather lengthy and complicated documentation. One target of FE-DESIGN was to realise a framework that helps industrial users, without a detailed understanding of the adjoint theory, to successfully apply the method to their problems.
Further results relevant for the application in industrial processes are the realisation of manufacturing constraints for topology optimisation. Topology optimisation often delivers results that are impossible to transfer to the industrial product development processes without appropriately restricting the solution space. The manufacturing constraints implemented in the FLOWHEAD project and provided within the industrial demonstrator are a first step into the direction of manufacturable results of topology optimisation. The final evaluation of the framework has shown that it provides the necessary mechanisms for targeting industrial users in the sense of usability and assistance while setting up industrial optimisation problems. The user is capable to easily set up an optimisation based on a CFD model and a parameter file that describes the optimisation task. Furthermore it has been shown that complex optimisations with multiple constraints are in principle possible and deliver reasonable results at least for the applied simple test case. None the less there are still a lot of open issues that have to be resolved before successfully applying the developed methods to real industrial problems. This clearly has become apparent when evaluating the framework using an industrial use case. One issue here is that the solution of the adjoint problem is the base for the optimisation and getting reliable and stable sensitivities even for 'low quality' meshes seems to be a necessary precondition for the workflow to get applied.
Developed optimisation workflow:
The workflow for the topology optimisation starts with the start-up of the solver and the optimisation system and enters the design cycle loop. This loop is executed until a defined stop condition is reached. The first action in a design cycle is an update of the design variables. Modules of the framework that change the design variables, like for example manufacturing constraints that work on the design variable field, are executed at this point except in the first design cycle. The final design variables of the current design cycle are then communicated from the optimisation system to the solver using the runtime interface. Since the design variables result only in changes of cell properties, like for example the porosity or the conductivity, the mesh does not change. An update of mesh data within the optimisation system is not required. The CFD solver solves the primal and dual equations and sends the sensitivities to the optimisation system. Pure CFD solver iterations in between two design cycles are indicated by the box OpenFOAM: primal / dual solution. I.e. this box contains multiple CFD solver iterations.
On the right hand side the workflow for the different modules integrated into the demonstrator framework is shown within the box labelled 'Optimisation modules'. Each module operates on the data provided by the framework. The module 'Optimisation algorithm', for example, uses sensitivity information and current design variables to compute updated design variables to be used for the next design cycle.
In case of a complex optimisation task the sensitivities calculated by the dual (adjoint) CFD solver may have to be combined before used as input to the optimiser itself. This is included in the box named 'Sensitivity combination'.
Manufacturing constraints that are implemented as dedicated filtering methods working on the sensitivity fields are executed before passing the sensitivities to the optimisation algorithm. Results can be found in the 'Final Technical Report', improvements in cost function of around 30 % have been achieved.
Post-processing of topology optimisation results
The 'raw' topology optimisation result is a (unchanged) CFD mesh containing a design variable distribution in the design space. For example, this can be a porosity distribution. The design variable distribution is not a 'digital' distribution but a continuous field of values between 0.0 and 1.0. Basically two types of results can be derived from the raw result:
1. Cell set
A subset of the cells contained in the CFD mesh, e.g. all cells with a porosity lower than a certain value. Cell set results typically are useful to get a quick impression of the resulting design.
2. Smooth surfaces
Created as a new surface mesh based for example on ISO surfaces of the design variable distribution. The construction of smooth surfaces is often more expensive in terms of computation time. It is typically used to create final result surfaces after the optimisation is completed.
For both types of results it is necessary to apply some sort of criterion to the design variable distribution. This criterion must decide whether or not a specific cell belongs to the result. To derive a cell set, a criterion could be 'Select all cells that have a porosity value less than a given threshold'.
A smoothened surface output can be applied using all the described result extraction methods and is either used by importing it to a CAD system or for performing an additional simulation / optimisation. The surface can be re-meshed for a validation CFD analysis or to perform a shape optimisation as fine tuning. The surface and volume remeshing steps are relatively straight forward from the workflow point of view but an issue addressed within the project is the reconstruction of the boundary conditions of the original CFD problem. To automate this step the regions for the boundaries have to be identified within the surface representation. This is realised by a STL output format with named groups that can be read by a lot of CFD preprocessors. After this reconstruction step either a validation of the topology design proposal or a succeeding shape optimisation can be performed. An overview of possible steps is shown in the 'Final Technical Report'.
Integration of topology optimisation into industrial demonstrator
The integration of topology optimisation into the industrial demonstrator required the adaptation of two different OpenFOAM adjoint solver implementations. The base adjoint solver has been provided by ICON in WP3. This solver is the default implementation used by the industrial demonstrator. The OpenFOAM adjoint solver for coupled flow and heat transfer problems developed by DTU in WP5 has been integrated as alternative solver, selectable by the solver configuration file of an optimisation job.
Due to the fact that a considerable amount of adaptations in the OpenFOAM adjoint solver code was required for the integration with the industrial demonstrator, the usage of a special OpenFOAM distribution provided by FE-DESIGN is required. A standard OpenFOAM distribution in combination with the adjoint solver packages provided by ICON and DTU is not compatible with the industrial demonstrator.
Manufacturing constraint identification for topology optimisation
For topology optimisation a set of relevant manufacturing constraints has been identified together with the partners VW and RSA. The table below lists the identified manufacturing constraints with their description, motivation and comments on the implementation realised in the industrial demonstrator and with respect to their validation in industrial use-cases. No use case provided in the project was suitable to be used for the evaluation of the symmetry constraint. Therefore it has been evaluated using the topology optimisation of a flow splitter. To get an initially asymmetrical result, different pressure boundary conditions at the outlet have been used. As objective function for the optimisation the total power loss has been used in combination with a volume constraint. The results of an optimisation without and with applied symmetry constraint are shown below.
Both optimisations are converged and the final improvement of the total power loss decreased when specifying the symmetry constraint which is expectable if feasible solution space is limited. A convergence plot for both optimisations is shown in the figure below. For evaluating the undercut prevention the same model has been used. For this case symmetrical pressure boundaries have been used. Optimisation was done with respect to the total power loss and the volume being constraint. The results of the optimisation and the convergence without and with the applied demoulding constraint are shown below. The minimum member size manufacturing constraint has been evaluated in combination with the OpenFOAM adjoint solver for coupled flow and heat transfer. For the optimisation the Navier Stokes equation together with a heat conduction and advection equation is solved. The objective is to keep the temperature within the design space as uniform as possible. In the figure below the optimisation results for an increasing minimum member radius are shown. The radius controls the smallest appearing features in the resulting topology. Additionally for each result the convergence plot is provided.
WP3 - Adjoint solvers
Adjoint solvers are at the core of this project, their ability to compute sensitivities of an arbitrarily large number of design variables at constant cost makes gradient-based CFD optimisation feasible in the first place. The project developed three different types of adjoint solvers, partly to mitigate risk, partly to explore innovative but not yet industrially mature concepts.
The overall objective of task 3.1 is the development of a robust, efficient and versatile open-source solver, based on continuous adjoint, suitable for inclusion into the automotive PDP. Initial development of this solver has been funded by VW and has been further developed in this project. This adjoint code has been integrated into the workflow of WP2 and has been used for the principal demonstration cases.
Task 3.2 performed by ESI group is related to the sensitivity analysis using adjoint methods and in particular the development of a solver-independent continuous adjoint solver suitable for pairing with any of the commercial CFD solvers in the automotive PDP. Task 3.3 involves the development at QMUL of a discrete adjoint Navier-Stokes flow solver, based on the code CFD-ACE+ from ESI by the application of automatic differentiation (AD) tools.
Continuous adjoint solver OpenFOAM
Icons overall objective was the development of a robust, efficient and versatile open-source solver, based on continuous adjoint, suitable for inclusion into the automotive PDP. Several steps were taken in order to achieve this goal. The first step was enhancement of an existing open source adjoint solver by implementing a variety of boundary conditions and cost functions necessary for solving various optimisation problems arising in automotive design cycle. Indicative cases of such problems were provided by the industrial partners for demonstrating the new functionalities. As a second step the solver was further enhanced by including an adjointed version of the Spalart-Allmaras turbulence model, so as to avoid the well-known inaccuracies in the calculated sensitivities that arise when a 'frozen turbulence' assumption is made. This enhancement allowed the solution of aeroacoustic design problems like noise reduction through minimisation of the turbulent kinetic energy. The final step was to make sure that the capabilities of the adjoint solver developed under the previous two steps were industrially useful. This final stage was necessary in order to ensure robustness and stability of the adjoint solver in an industrial environment. Effort was put to improve the non-functional characteristics of the code, since optimal performance is naturally highly advantageous in an industrial context. A best practise user guide was the outcome of this final task. The software and the user guide were provided to the rest of the consortium including the OEMs and were used as the key technology within most WPs enabling further developments for optimisation inclusion in the automotive PDP. Overall Icon's achievement can be summarised as the delivery of an adjoint solver that can tackle a variety of optimisation problems in the complexity of an industrial environment.
Summary of developments for the adjoint turbulence model
Abandoning the assumption of frozen turbulence leads, predictably, to a rather more complex adjoint problem. Because of the complexity of the mathematical expressions involved, the details of the modified adjoint problem will not be presented here. However, we give a brief overview.
There is an additional equation for the adjoint turbulence variable nuATilda with associated boundary conditions, and there are additional terms in the adjoint momentum equation. On the other hand, the adjoint pressure equation is unaffected, and so are the boundary conditions and additional momentum terms arising from the specified cost functions, since only cost functions depending explicitly on the turbulence quantities would introduce additional terms into the system. Hence to apply the adjoint turbulence version of the solver for the cost functions and application scenarios described in the FLOWHEAD technical annex it is enough to activate the adjoint turbulence model while leaving all other settings (i.e. boundary conditions and/or volume cost function switches) the same.
The boundary conditions for the adjoint turbulence variable are relatively straightforward. On solid walls and inlets, the variable vanishes, and while it is non-trivial at outlets, its form only depends on the cost function through the derivative of the boundary integrand wrt the adjoint turbulence variable, which in all the cases we are considering is zero. Hence there is a single boundary condition to be specified at outlets, and fixed value 0 elsewhere.
Summary of investigation and best practices guide and description of provided cases
The work task objective regarding Icons contribution was to address performance issues of the code arising from the user's experiences in WPs 4,5. Consequently, ICON investigated possible settings in order to achieve the efficiency for the required turnaround times.
Test cases for the investigation were provided by both the industrial partners a list of those is included in the deliverable D3.1.3. The goal of this task was to show converged adjoint solutions for the provided test cases and ensure convergence in similar cases. The overall task entailed:
- checking the discretisation schemes fvSchemes, and the solver settings fvSolution;
- define the settings that allow running the adjoint solver on test cases like the provided and of similar complexity;
- deliver a best-practices guide.
More time than originally planned was spenT on this task due to the depth of investigation and the time required to prepare and run such complex cases.
Investigation and representative results
In the relevant sections of the 'Final Technical Report' the investigation towards the most appropriate solver and discretisation settings for the adjoint solver and the 3 most representative cases are summarised. The remaining cases are presented in more details in D3.1.3 deliverable report. The enhanced OpenFOAM solver was successfully applied to external full vehicle cases, side mirror cases and duct geometry cases.
Task 3.2: Solver-independent adjoint, discrete adjoint of commercial flow solvers
After having concluded the separation of the continuous adjoint solver and implementing an automated optimisation process based on ESI proprietary simulation process management tools, extensive testing and optimisation of the process was pursued.
Among several improvements related to interfacing with third party codes some code specific interfaces were developed to ensure that the universal (and preferred) route via Ensight files is indeed reliable. Test cases defined in WP1 were pursed confirming the successful implementation of an independent adjoint solver and an efficient modelling process. Some of the examples and the improvements achieved after one optimisation loop are summarised in the following table:
- advancements and test cases results were presented during ESI global forum and export seminar in Germany, March 2012;
- parallel to the continuous independent adjoint efforts the kernel of a commercially available multi-physics tool - CFD-ACE+ - was adapted to enable automatic differentiation using AD tools. This effort was performed in close collaboration with researchers at QMUL.
Preparation of the ACE+ code
ESI's other main task in WP3 was to prepare a reduced kernel of the commercial multi-physics CFD code ACE+ to allow for automatic differentiation to be performed by QMUL. The task was initially planned in two stages, first application to a very reduced set of equations and functionality, then application to a more complex set.
Significant difficulties were encountered with the ACE+ differentiation, as discussed in the 'Final Technical Report'. The task at ESI was then altered to mainly focus on removing from the code statements and constructs that proved to be non-differentiable by Tapenade. The work was on the following areas:
- support to QMUL with decisions on source tree pruning;
- removal of memory allocation in the iterative loop;
- alterations to database call interface for field pointers.
ESI closely collaborated on the differentiation with QMUL as discussed in the next section. Task 3.3: Derivation of discrete incompressible adjoints using automatic differentiation differentiating the ACE+ incompressible commercial CFD code has been much more challenging than anticipated. The difficulties that were tackled were in three major areas:
Capability of the AD tool
ACE+ is written in Fortran90, the most commonly used AD Tool for F90 is Tapenade by INRIA (www.sop.inria.fr/tropics). However Tapenade was not able to parse ('understand and interpret') the ACE+ code due to a number of coding idiosyncrasies in ACE+ (e.g. use of call interfaces without dummy variables, instead queries into a database of allocated arrays returning pointers.), as well as inherent limitations with AD e.g. when dealing with pointers. In addition Tapenade at the beginning of the project was not sufficiently mature to deal with complexity of ACE+ and the range of F90 language elements that were used. This resulted in a large number of bugs (e.g. modules) when calling Tapenade on the initial ACE code. A number of avenues to remedy this were explored.
As alternative to the complex structure of ACE+, a simpler in-house code (gpde) was constructed from scratch that uses the same discretisation type (face-based incompressible SIMPLE scheme) as ACE+, is also written in F90, but has a more limited volume (fewer robustness/accuracy enhancing additions, simpler iterative solver) and a clearer argument passing method. This simpler code could then be modified to be suitable for Tapenade and the overall methodology could be developed using this bench code. See also the next subsection on gpde.
Alternative AD tools to Tapenade were explored. There is a commercial AD tool TAF from www.fastopt.de. However their business model is less to sell licenses for the AD tool, but rather to apply AD using their in-house tool to customer's codes. This approach was not budgeted for in FLOWHEAD.
The team around advisory board member Prof. Naumann develops operator-overloading AD tools (o-o AD). In o-o AD the code statements and arguments of the primal code are logged to a tape during the forward run of the primal, then differentiated in reverse from that tape. This is in contrast to the source-transformation AD of Tapenade (s-t AD) where the code is parsed at compile time and the actual source of the code is differentiated. O-o AD does not have the same issues as s-t AD with complex coding structures, but is much more limited in producing efficient adjoint code.
The team at QMUL collaborated with Prof. Naumann's team and developed a simple o-o adjoint of the gpde code which worked successfully. However improving the performance to acceptable levels for this simple code proved extremely difficult and being able to scale this methodology up to the entire ACE+ code seemed improbable without having access to and extensive experience with the o-o AD tool.
In parallel steady progress was made with the developing team of Tapenade at INRIA on resolving bugs in Tapenade brought up by the application to ACE+. Some issues with or design choices of Tapenade have been circumvented with scripting (see following subsection), all remaining bugs have been resolved by the end of 2011 and Tapenade has been successfully demonstrated on ACE+ in tangent-linear mode.
Discretisation of incompressible CFD codes
There is extensive knowledge on how to differentiate compressible flow solvers which use a fully coupled iterative scheme that advances all equations in the same way. Effective adjoint variants of this time-stepping can be devised as demonstrated in WP6. The common incompressible discretisation is the SIMPLE scheme which uses a two-stage predictor-corrector method where the momentum and pressure equations are discretised separately and loosely coupled through a projection step.
Applying the same approach as in the compressible fully-coupled discretisation also to the SIMPLE scheme would lead to a fully coupled scheme which may offer convergence benefits, but would require significantly more memory. The popularity of the SIMPLE scheme precisely stems from the fact that it does not require fully coupled storage while offering a very good convergence rate. Hence a fully-coupled adjoint would have unacceptable memory costs and has hence been disregarded.
An alternative is to apply 'brute-force' differentiation to the SIMPLE iterative step. The main elements of thIs step are a number of linear system solves, one for each momentum component solving a decoupled forced advection-diffusion equation, and one solving a Poisson problem for the pressure in a pressure-correction step. In the work by Oezkaya et al, the differentiation was also applied through these linear solves, resulting in significant complexity and a substantial computational overhead with poor runtimes.
In developing gpde we have hence chosen a novel and alternative approach. Linear systems are, by definition, linear and hence the differentiation of a linear solver is equivalent to solving the primal linear system with the perturbation of the right hand side as the right hand side. Hence we can substitute a simple but ineffective linear solver before submitting to AD, AD then traces the correct dependency of the variables, and then put the efficient linear solver back in with modified arguments when re-assembling the code. This will result in ideal performance identical to the primal solver for the linear system solves. The gpde solver indeed a achieves a run-time and memory cost of 2x the primal solver, which is optimal as 2 full sets of pdes, the primal and the adjoint are solved for.
Key results obtained with gpde on the S-Bend test case are shown for various Reynolds numbers in the following figures. The flow is attached after the S-Bend and both primal and adjoint solutions converge without problems for the standard low-Re case.
Increasing the Reynolds number by a factor of 10 to Re equal to 600, or an inlet velocity of 1 m / s results in a more problematic convergence. The primal converges partly, but then gets stuck in limit cycles. The flow field exhibits a large separation bubble right after the bend. The adjoint solution converges, but with a less stable convergence history. The surface sensitivities show a similar pattern to the lower Re, but one now finds a pronounced region at the sides of the bend where the geometry should be pushed in to reduce pressure drop. Shape optimisation results with this geometry are shown in the results for WP4.
This Re number represents the limit of stability, increasing it further will make the separation bubble unstable, the primal flow will only converge to an irregular limit cycle dominated by periodic detachment of the separation bubble. As a consequence, the discrete adjoint which bases its Jacobian on an arbitrary frozen snapshot of the primal, is also unstable and diverges. The next step of development in follow-up research is to develop unsteady adjoint methods.
Application to commercial ACE+ code
Even with improved maturity and a number of bug fixes, Tapenade will not be able to parse the ACE+ code 'out of the box'. A pre-processing methodology was developed that performs the following operations:
- Removal of irrelevant 'dead' code: certain code functionality are not to be differentiated and hence are pruned from the source code tree. Examples for such code is diagnostics, or special physical models such as icing, porous media, which are not of interest at this stage. Dead is wrapped into pragmas and permanently removed from the adjoint source. Removal of non-differentiated code: code such as screen printout, input/output should not be differentiated, but needs to be re-inserted into the final code. A second type of pragmas achieves this.
- Alternative code: hand-derived alternatives are provided e.g. for the linear solvers. Pragmas with if-else structure achieve this, substituting simple template code during differentiation and linear solver calls with modified argument lists for the adjoint version. The main difficulty is the first step, pruning dead code, but dead code only and obtaining a complete set of primal subroutines. In industrial legacy codes, the structure is often convoluted and complex, with many subroutines being generically written and re-used in various contexts. E.g. the manually reduced first set of ACE routines contains 680 files, 230 K lines or 8 MB of source code.
Relying on Tapenade's error messages of missing dependencies is not an appropriate approach to arrive at a complete source tree since each Tapenade differentiation run takes about 20 min runtime, considering the complexity of the source tree this becomes a prohibitive task. A semi-automatic loop was constructed in which the log files of Tapenade and the gprof code profiler are compared. The profiler very rapidly establishes a list of executed functions which can then be compared to the current version of the pruned source tree. Missing dependencies then need to be manually equipped with the appropriate pragmas and added to the source tree.
Once differentiation is completed, the source code for the adjoint needs to be re-assembled. Substituted source code such as linear solver calls need to be substituted back in. We also find it necessary to override Tapenade's behaviour to duplicate module definitions in a differentiated module. This behaviour leads to conflicting differentiated module definitions when differentiating a module multiple times w.r.t. different input variables as arises e.g. when differentiating a residual assembly routine w.r.t. the flow variables in the iterative loop, but differentiating it w.r.t. the face metrics to project the sensitivities onto the design surface once the adjoint solution is converged. As an alternative, scripting is used to copy the additional elements of the differentiated module definition into the primal module.
WP4 - Shape parametrisation
WP4 develops new shape parametrisation methods for CFD optimisation in the automotive industry. The aim of the WP was to develop all the necessary numerical methods for improving the design of industrial parts which are exposed to fluid flow. For instance, one of the main targets of shape optimisation is to change the shape of parts of a car such that its aerodynamic behaviour is improved or, in internal aerodynamics the minimisation of the pressure drop in pipe systems is of major importance. By making such a process systematic and efficient the optimisation can be a procedure integrated in the overall design process.
Node-based parametrisation
One task was to develop the methods as well as the efficient realisation of them for the parameter-free shape optimisation approach. Within this technique one can optimise complex shapes and free-form geometries and no additional control on the shape needs to be specified. Because of the fact that the optimised shape is not restricted and controlled by the user the resulting shapes are innovative and high improvements can be achieved. However, since no predefined control on the way that the shape modes are defined additional attention has to be given on avoiding unphysical resulting shapes. This is done by the developed 'out-plane regularisation method'. The method applies a filter so that the noisy modes are smoothed out. Besides the fact that the shape should be physical, the method has to guarantee that the change on the shape does not cause numerical discrepancies. The 'in-plane regularisation method' guaranties the numerical plausibility of such a problem.
Both in-plane and out-plane methods were tested successfully in benchmarks provided by the automotive industry.
Node-based parametrisation: in plane regularisation
In-plane regularisation is applied on the bounding design surface. Surface elements are identical to the faces of the CFD model which are located on the boundary. Topology of the surface elements (nodes and connectivity) is given to the in-plane regularisation module and this module modifies the position of the surface nodes such that the mesh has a better quality. As mentioned before, in-plane regularisation moves the nodes tangential to surface and therefore the surface geometry remains unchanged.
There is no limitation in the surface geometry neither in the number of nodes per element and since in-plane regularisation is solved only on the surface nodes, and only a linear step is performed, the computation time is much smaller compared to other modules of the optimisation loop.
In-plane regularisation can be used both for quality improvement of an existing mesh as a post-processing step or for maintaining the quality of the mesh during several design updates. Quality improvement is done based on the users desired mesh-quality measure. The second application (quality maintenance) is the main focus in FLOWHEAD project and tries to keep the initial properties of the mesh after design updates. Design update refers to any type of geometrical change such as rotations, bulk motion, curving, flattening, etc. Another important aspect is removing the possible in-plane noise existing in the surface mesh due to the design update proposed by the optimiser.
This technique is based on applying an artificial pre-stress field on the surface mesh, in an arbitrary reference configuration. Choice of this configuration determines the type of element geometry to be dominant in the domain. This is done by introducing an ideal element shape as the 'target element'. In-plane regularisation rearranges the position of nodes (preserving the original connectivity) such that the individual element shapes are as close as possible to the target element, in the global sense. In the case of quality maintenance, the ideal element is nothing but the original element shape (before any design update).
More details about in-plane regularisation, together with some examples showing the performance of this module can be found in the project's server.
Node-based parametrisation: out-of plane regularisation
Like in-plane regularisation module, out-of-plane regularisation is also developed and implemented in Carat++. The goal of this tool is to filter the normal-to-surface sensitivities. This step removes the noise from the sensitivity field and this prevents a noisy updated surface. Filtering can be also used in order to control the design process with the respect to the minimum geometrical detail size, based on the filter dimension. It should be mentioned that the sensitivity values are reported normal to the surface and therefore they are treated as a scalar field defined on the boundary surface.
There are different filter functions available. Furthermore, by proper selection of the filter size and number of filtering steps one can have a good control on the geometrical characteristics of the final design. The average number of neighbouring points which take part in the filtering is reported by the software and has to be considered as well. The out-plane regularisation is a separate part of the optimisation workflow which gets row sensitivities and delivers back a smooth sensitivity field. So no combination with in-plane regularisation is needed which makes the whole optimisation chain more modular and flexible.
In addition to the planned deliverables, TUM has delivered additional software for in-plane and out-plane regularisation, so the partners can perform local execution of the regularisation module within the project (independent of the overall optimisation workflow and the central database). This additional software use simple ASCII files to read the geometry as an alternative to the central database functions. The actual software, the user manual, as well as several examples are uploaded to the project's server.
Integration of the regularisation in the optimisation workflow
In this deliverable the methods of in-plane and out-of-plane regularisation, which have been already tested in the previous deliverables are integrated to the optimisation workflow. More precisely, in the core of the optimisation program an application programming interface (API) was implemented. The API functions enable the interaction with the in-plane and out-plane modules. These modules where connected to the API interface as a static c++ library. The library offers the access to a main regularisation object which can be initialised and sequentially perform the in-plane and out-plane actions. More details about the interface with the optimisation workflow as well as descriptive examples are uploaded to the projects server.
Principal concept tests
After developing the different modules, the optimisation workflow was created by bringing all the individual pieces together using an API interface. Here, this framework is tested with the benchmark examples provided by simple examples created by TUM and more involved examples given by VW. In the following two examples are presented: one for external and one for internal aerodynamics.
In the first example the performance of mesh control (in and out plane regularisation) was tested by applying the workflow on a circular cylinder subject to lateral fluid flow. Minimisation of the drag is the objective. As it can be seen in the following figure the quality of the mesh and smoothness of the surface is retained until the trivial optimised shape of an extremely thin geometry.
In the next example, the main benchmark of the project which is a 3-dimensional S-bend duct used for rear seat ventilation provided by VW is studied. In this geometry two optimisation cases were studied: one with the whole surface pipe as a design surface and one where only the bend part was allowed to change during optimisation.
List of websites: http://flowhead.sems.qmul.ac.uk