CFD Automatic Optimisation using OpenFOAM in Grid Environments

Gregory Katsaros1, Francisco Campos2, Dimosthenis Kyriazis1 and Theodora Varvarigou1

1

Dept .of Electrical and Computer Engineering, National Technical University of Athens, 9, Heroon Polytechniou Str, 15773 Athens, Greece E-mail: {gkats, dkyr, dora}@telecom.ntua.gr ICON Rofel House, Colet Gardens, London W14 9DH, United Kingdom E-mail:f.campos@icon-cg.co.uk
2

Abstract A new approach for solving CFD design optimisation problems in Grid infrastructures is presented in this paper. The method relies on GRIA, a middleware for deploying data and job services within a Grid environment. The CFD code OpenFOAM was customised and deployed through GRIA as a Grid service to perform large number of fluid design evaluations in a remote HPC cluster. This process was then integrated with other commercial software (CATIA v5 and STAR-Design) in an automatic optimisation loop using the multi-disciplinary optimisation code modeFRONTIER. The effectiveness of the new method was evaluated using an industrial example. This work is part of the ongoing research effort in the framework of EU BEinGRID funded Project. Keywords: Automatic Optimisation, Grid Computing, Computational Fluid Dynamics, OpenFOAM

1. INTRODUCTION The advent of Grid environments has enabled the creation of virtual High Performance Computing (HPC) clusters by unifying large networks of geographically dispersed computers connected to the Internet. The resulting Grid infrastructure provides a cost effective way of accessing powerful distributed and heterogeneous computational resources for running demanding applications in a transparent way [1], [2]. Computational Fluid Dynamics (CFD) is an example of application requiring great computational power for solving complex fluid and heat transfer related problems. When CFD is employed for engineering design as part of an automatic optimisation process (usually driven by genetic type algorithms), many calculations are often needed in order to obtain an optimum design solution. Grid computing offers a suitable alternative to in-house hardware resources for performing this type of calculation. Enabling execution of demanding applications on Grid environment has been a research topic for some time. For example, [3], [4] and [5] present the work performed for various application domains on biocomputational, learning and medical fields. Similarly, in [6] an approach for deploying, testing and analysing multiphysics codes in Grid-based computing environments is described.

Regarding CFD optimisation using Grid infrastructures, in [7] and [8] the authors present a toolkit (Geodise) that includes client functionality to Globus compute resources and a job submission Web service which exposes a cycle-scavenging Condor pool within the Matlab environment. Both are exemplary cases for demonstrating the role of remote computation and data access in constructing a Grid-enabled problem solving environment. Other interesting studies on CFD optimisation in Grid infrastructures are presented in [9] and [10]. In the first the authors introduce an approach implemented in Matlab for optimising the shape of a two-dimensional airfoil using CFD within a Grid computing environment. In the second, a general purpose optimisation system framework that relies on Grid RPC is discussed. Further investigations on the field of CFD optimisation include the work described in [11], which integrates in Garuda Grid CAD, meshing and post-processing tools with a CFD solver (CFDExpert). Authors in [12] also describe a similar Grid computing application where CAD, mesh generation, and solving are automated within the Matlab scripting environment to perform Grid computations and database toolkits in the form of Matlab functions. Additionally, in [13] a web portal (CamCFDWP) and its functionalities, such as authentication, job submission and file transfer, are presented as a way to provide simple integration of CFD applications to Grid resources. The use of Globus and Condor for sharing computer resources and the definition of XML standards for the annotation of CFD datasets, along with a distributed database framework for them, is presented in [14]. Finally, in FlowGRID Project, a study and a set of simulations were performed and presented in [15] to enable access to CFD solutions through Grid environment. In this paper, a new approach for exploiting Grid computing to solve automatic CFD optimisation problems involving real industrial engineering designs is presented. The method relies on GRIA, a middleware for deploying data and job services within a Grid environment [16]. A real industrial design problem was employed to demonstrate the feasibility of the methods and the potential for future commercial exploitation of the technology as part of the ongoing research effort in the framework of EU BEinGRID funded Project.

2. BASIC DEFINITIONS IN AUTOMATIC OPTIMISATION The optimisation process can be defined as the search for the absolute maximum (or minimum) of a function, which depends on certain variables, respecting certain constraint equations. Some formal definitions can be useful to better understand the concept of automatic optimisation. Further details are available in [17], [18] and [19]. A distinction should firstly be made between mono-objective and multi-objective optimisation. In a mono-objective optimisation, the purpose of the problem can be mathematically described with only one objective function of the problem variables. In mathematical terms the problem may be written as follows:

Find the set of variables x1 x X = 2 ... xn which gives the maximum value of the objective function f(X) respecting the constrains: gj(X) = 0, j = 1,, m lk(X) < 0, k = 1,, p In multi-objective optimisation the problem is similar but instead of a unique objective function, a given number of functions have to be simultaneously maximised or minimised. Generally, the problem is finding X that maximises fi(X), with i = 1,, q. The search for the optimum can be performed using a variety of algorithms. A first distinction can be made between gradient-based algorithms and stochastic algorithms. Gradient-based algorithms evaluate the objective function gradient and try to find the increasing direction of the objective function. The new variable set is then selected according to this increasing direction within the function domain. Alternatively, stochastic algorithms search the whole domain through multiple concurrent design evaluations and are specially suited for multiobjective problems. One of the most commonly used type of stochastic algorithms is the so called Genetic algorithms, based on the natural genetic evolution of a group of individuals. Two additional concepts must also be considered when comparing the different algorithms: accuracy and robustness (see Figure 1). Robustness relates to the ability of the algorithm to find the absolute optimum of the objective function. Accuracy, on the other hand, relates to the ability of reaching a solution as close as possible to the optimum of the objective function.
f(x) f(x) Low accuracy

Low robustness

High accuracy High robustness

Figure 1. Graphical representation of robustness and accuracy of an optimisation algorithm. Another important feature of the optimisation algorithms is the convergence velocity; i.e. the number of iterations required to reach the convergence (to find the objective function maximum). The following table (Table 1) compares the gradient-based algorithms against the stochastic algorithms with respect to the three properties previously described.

Table 1. Gradient-based and stochastic algorithms comparison. Gradient-based Algorithms LOW HIGH HIGH Stochastic Algorithms HIGH LOW LOW

Robustness Accuracy Convergence velocity

In addition to the optimisation algorithms, other concepts of the optimisation theory relevant to this work are: Design Of Experiments (DOE) Statistical Analysis Pareto frontier

DOE is a fundamental part of the optimisation process when dealing with multiple objective functions and stochastic algorithms. A combination of input variables can be defined to produce an initial population of designs with the best possible distribution in the design space. The relationships among different variables, or among variables and objectives, can then be investigated using Statistical Analysis to locate the most important areas of the objective functions domains. Consequently, defining a congruent DOE and performing statistical analysis of the results from the DOE evaluation can help reducing the calculation time before the actual optimisation is performed. One last important concept in multi-objective optimisation is that of the Pareto frontier. In a mono-objective optimisation, the best solution is simply the design that gives the maximum (minimum) value of the objective function. In a multi-objective optimisation, where many objective functions are involved, the theoretical best solution would be the design that simultaneously provided the maximum value for all the objective functions. Such situation does not usually occur. Instead, the concept of best design is replaced with the concept of dominant designs which concentrate along a trade line usually known as Pareto frontier. Figure 2 shows a qualitative representation of a possible Pareto frontier for a two-objective optimisation (if the two objective functions f1 and f2 had to be maximised).
f2

Pareto Frontier

f1

Figure 2. Pareto frontier qualitative representation.

3. CFD IN THE DESIGN OPTIMISATION PROCESS The traditional CFD design process is often based on a trial-and-error type approach. Starting from an initial geometry, CAD changes are introduced manually based on results from a limited number of design iterations and CFD analyses. The process is usually complex, time-consuming and relies heavily on engineering experience, thus making the overall design procedure inconsistent, i.e. different best solutions are obtained from different designers. Moreover, there is no guarantee that the final solution is actually the best solution. The introduction of a mathematical framework to find an optimum design through the use of the latest optimisation techniques standardises to some extent the design procedure and eliminates most of the drawbacks found in the traditional approach. Designers are relying more and more on this type of automated methods in order to reduce the product development time and satisfy the growing design requirements to stay competitive in the market. In this sense, the benefits of parallel execution of CFD analyses are being exploited by taking full advantage of the most sophisticated IT frameworks available. More precisely, distributed computing based on high-performing CPU technology allows a massive use of optimisation tools, especially for designs involving computational fluid domains whose size was considered prohibitive until a few years ago. Grid enabled technologies offer further potential for expanding the current capabilities and improving the latest methods. In order to introduce the CFD process into the optimisation loop, the traditional manual methodology for defining a CFD case (i.e. CAD preparation, mesh generation, solver setup, calculation and post-processing) needs to be fully automated by means of user defined scripts or macros. When these scripts are read and executed in sequence using advanced optimisation software, the manual process becomes a parametric CFD tool. State-of-the-art gradient based or stochastic algorithms are then employed to define and screen several design variations in order to find an optimal solution. The overall process is described in Figure 3.

Figure 3. Automatic CFD optimisation methodology.

4. GRID COMPUTING IN THE DESIGN OPTIMISATION PROCESS In the following paragraphs a conceptual architectural model is provided regarding the design optimisation process in a Grid environment. The architecture of the proposed solution presented in this paper can be distinguished in two major sides/levels, depending on the involved actors and roles. As shown on Figure 4, the first is the End User, while the second is the Service Provider side. A CFD engineer or an independent CFD service provider company can be an example of the End User role. The infrastructure on this side consists of the CAD and Meshing software as well as the Optimisation Algorithm (as presented in Figure 3). The orchestration of the whole CFD simulation is achieved by the optimisation application (e.g. modeFRONTIER), which is the actual front-end interface for the End User and the execution workflow composer utility (which is described in detail in Section 5.3). The infrastructure on the Service Provider (SP) side (e.g. computer industries, software vendors) hosts the CFD solver application (e.g OpenFOAM). The interaction between those two sides is succeeded through GRIA, the selected Grid middleware, which provides a Client as well as the Service Provide component.

Figure 4. Overview of the Grid architecture. 4.1 Components of the Architecture In the following figure (Figure 5) the main architectural components are depicted along with their interfaces. A detailed description of the components is presented thereafter.

Figure 5. Component Diagram 4.1.1 GRIA Command-Line Client GRIA command-line client component is a GRIA middleware module that provides the necessary client functionality for accessing GRIA Grid-services. The command-line interface (provided by the client) facilitates the automation of the execution procedure. The security provided by GRIA middleware is based on the Web Services and PKI security protocols and mechanisms to verify the identities (and roles) of users attempting to access services. As a result, the execution operations on the resources are not applied directly to the nodes but instead, users must request the latter from the Basic Application Service, which executes the commands on their behalf. 4.1.2 GRIA Basic Application Services GRIA Basic Application Services component is the major module of the GRIA middleware for the Service Provider side. This component hosts the Data and Job services (storage and processing) of the provider and in combination with the Service Provider Management (optional GRIA module) can provide accounting and billing functionality. The application that the Service Provider is willing to expose within the Job Service component is deployed using a wrapper script (Perl script that includes all appropriate operations for the execution) in order to be published to Grid environment. In our case we are focusing on the simpleFoam solver of the OpenFOAM package, which is deployed on the Job Service and is executed on the local cluster.

The security and access control on that point is based on the PBAC mechanism that GRIA supports. This dynamic access control system uses a Policy Decision Point (PDP) that answers to question like Can <some user> perform <some action> on <some resource>?. The answer of such a question depends on the users role on the resource, the state of the resource and the resources policy settings. 4.1.3 Service Provider Management The Service Provider Management module allows the Service Provider to support billing and accounting functionality. Via simple management protocols that can be used with GRIA Basic Application Services and other non-GRIA applications is able to propose customize Service Level Agreements (SLAs) and bill for the service usage. This module consists of the Trade Account Service and SLA Management Service components. The first is responsible for the trade account creation and management, depicting the trust relationship between the client and the Service Provider. Every trade account maintains a budget balance that is charged for every usage. The SLA Management Service exposes specific SLAs, presenting all the available resources (CPUs, applications etc) and the billing amount for every use. The custumer can choose between the provided SLAs and propose the agreement back to the provider. The confirmation of the proposed SLA, from the Service Provider, will allow the custumer to use the services and be automatically billed through his trade account with a pay-per-use scheme. 4.2 Interactions between Components In the Figure 6, below, we present the sequence diagram of the CFD execution on a Grid environment. 1. In this step the CFD engineer, or the batch script used on the automated optimisation process through modeFRONTIER, triggers the execution by using the command-line interface that the GRIA client provides. Using the execute job command of the client in combination with the appropriate parameters (Service Provider URL, application, input-data etc) starts the execution process. 2. The command-line client component automatically authenticates the clients account to the Account Service using the client certificate. In order to be able to access and use the Job Service of the SP, the End User must have an enabled and valid account on the SP side. This account is accompanied with a certificate signed from an authority trusted by the SP. 3. As soon as the account is confirmed the command-line client checks if the latter account has proposed an appropriate SLA, for the requested Job. The SLA control is applied on terms of validity period, permitted services, CPU time usage and all other constraints described on the proposed SLA. The luck of any SLA or a constraint exception will not let the client to use any provided service. 4. After a successful authentication and authorization to use the services, the client proceeds on creating the Job instance on the remote Job Service. 5. The input data are uploaded on the remote SP through the Data Service. A Data Stager is created, containing those data, which is linked with the Job instance that was created previously.

6. The Submit Job action of the command-line client triggers the execution of the specified application on the SPs Job Service. The proposed SLA accompanies the Submit Job request in order to ensure the non-breaching of the constraints set. 7. The SimpleFoam execution starts when the wrapper script, deployed on the Job Service, is executed. The necessary input parameters are forwarded to the wrapper through the Job Service. The wrapper script is set properly in order to execute SimpleFoam using LAM/MPI on the SPs cluster infrastructure. 8. After the successful execution of the SimpleFoam, the output results are returned to the Job Service in a zip archive mode. 9. The output data returned by the wrapper are uploaded through the Data Service to a Data Stager in order to by accessed and downloadable from the End User. 10. The billing procedure for the provided service occurs in this step. Based on the values set on the SLA, an appropriate amount is removed from the End Users account balance. 11. The returning of the output results back to the command-line client signals the end of the Job instance lifecycle. 12. The command-line client forwards the results back to modeFRONTIER in the specified file path.

Figure 6. CFD Execution sequence diagram During the execution, monitoring details are returned to the Command-line Client and a relevant log file is created. In case of execution failure the whole processed is stopped and the failure details are printed on the log file created.

5. TEST CASE: Optimisation of an Underbonnet Cooling Duct A test case is employed here to demonstrate the potential of Grid computing to solve CFD optimisation problems involving industrial applications, following the original work presented in [20]. The geometry, provided by AUDI AG, is a cooling duct located in the underbonnet region of a vehicle. The duct is responsible for delivering air from the outside, through the left side bottom grill, and towards the transmission. Providing additional convective cooling is considered beneficial for the reduction in the transmission surface and oil temperatures.

Figure 7. Left side grill on the new Audi TT (courtesy of AUDI AG). The objective of the optimisation exercise was to optimise the shape of the side duct in order to (i) minimise the total pressure drop from inlet to outlet, and (ii) maximise the discharge velocity. The former is required to increase the mass flow rate through the duct, while the later is sought to improve the convective heat transfer coefficient. The optimisation process consisted of creating a parametric CAD model of the duct geometry in CATIA v5; generating a polyhedral type CFD volumetric mesh in STAR-Design; performing a CFD analysis in batch mode in OpenFOAM using GRIA middleware for submitting and executing the job to Grid environment; and using the multi-objective optimisation product modeFRONTIER to establish the optimal design configuration. The various stages in the optimisation process are described in the following sections. 5.1 CAD Generation and Volume Meshing The first stage in the optimisation process was to create a parametric CAD model of the duct geometry in CATIA v5 (as depicted in Figure 3). A total of 14 geometric variables were defined in order to modify the shape of the duct. Figure 8 highlights two of these variables at the duct outlet. Additionally, two shape variations for deliberately extreme values are also depicted for demonstration purposes.

Figure 8. Examples of duct parameters and extreme duct shapes.

A simplified version of the underbonnet components surrounding the duct were also considered to avoid clashes. An intersection check was carried out for every design using an external script for CATIA v5. Any duct configuration that collided with other parts was automatically discarded during the optimisation process. The geometries from CATIA v5 were exported as step files, read in, volume meshed in STAR-Design. The resulting computational grids were polyhedral with two wall extrusion layers of 0.6mm and 1.1mm respectively. The size of the meshes varied from 40,000 to 45,000 cells. The meshing process was recorded in a batch script to be employed in the optimisation procedure. An example of a computational grid is shown in Figure 9.

Figure 9. Example of polyhedral mesh in the original duct geometry. 5.2 OpenFOAM in Grid The open-source CFD suite OpenFOAM was deployed as a web service through GRIA to solve the flow characteristics of every duct layout in a remote Grid environment. The polyhedral mesh created in the previous stage was first imported into OpenFOAM format using the ccm26ToFoam conversion tool. A series of input text files (or scripts) were then employed to: set up the CFD problem (i.e.: apply boundary conditions, thermophysical properties, turbulence models, solver controls, etc.); solve the parallel CFD problem to convergence in the Grid; and post-process the CFD solutions to extract the values of the flow field variables corresponding to the objectives functions of the optimisation problem. Each of these actions was automatically performed from within modeFRONTIER. The air flow was computed as an incompressible subsonic turbulent gas using parallel simpleFoam. The standard high Reynolds k- turbulence model was applied, and the y+ values verified for selected geometries. The SIMPLE solution procedure for pressure-velocity coupling was employed in the calculations in conjunction with the AMG solver for pressure and the BICCG solver for all other flow variables. The upwind differencing scheme was utilised for both velocity and turbulence. An upper limit of 300 iterations was specified to achieve numerical convergence. A fixed velocity, normal to the boundary face, was applied at the duct inlet with a value of 11 m/s. The turbulence intensity was set to 10%, while the length scale was set to 0.013 m. These conditions were approximated from aerodynamic simulations and wind-tunnel data for the full vehicle at a driving speed of 250 km/h. At the duct outlet, the static pressure was fixed at

0 Pa (relative to the operating pressure of 101325 Pa). The surfaces representing walls in the model were all defined to be adiabatic and no-slip stationary boundaries. Finally, post-processing of the simulation results was also automated so that modeFRONTIER could run the model analysis and extract the values of the objective functions. This information included the area-averaged total pressure difference between the inlet and outlet as well as the area-weighted average velocity at the outlet boundary. 5.3 modeFRONTIER Workflow The main phase of the optimisation work is the workflow definition, presented in Figure 10 for the cooling duct application. The different components in the workflow define each of the stages in the automated CFD process, the input variables, the objectives and the optimisation loop settings, including the DOE and the optimisation algorithm.

Figure 10. modeFRONTIER workflow for duct optimisation. The execution of each node in modeFRONTIER is described below: CATIA v5 was run on a Windows machine via an ssh server, including data transfer from and to the local Linux execution server. STAR-Design was executed on the local Linux machine. The Non-dominated Sorting Genetic Algorithm II (NSGA-II) [21] was selected in combination with the SOBOL DOE to carry out the optimisation process. The OpenFOAM case was set up in the local Linux machine. The data transfer and execution of simpleFoam were carried out through GRIA Command-line Client in an infrastructure consisting of four (4) Grid nodes running GRIA basic application services with the following specifications (Table 2): Table2. Specifications of the Computers comprising the Grid Nodes.
CPU x86 Intel P4 3GHz Memory 512MB RAM Disk Capacity 80GB HDD Network 1Gbps LAN Operation System LINUX Fedora core 5 CPU x86 Intel P4 3GHz

The multi-objective optimisation was launched and all the applications described above were run in batch mode to perform the evaluation of each duct layout. Starting from an initial random SOBOL DOE population of 30 individuals, 15 generations were created by the NSGA-II algorithm for a total of 450 CFD design evaluations. The averaged time per calculation turned out to be 8.7 min, while the overall optimisation process lasted 2.5 days uninterrupted. Local executions of similar cases showed an averaged time of 6.2 min; a reduction of 20% which can be attributed to transfer times linked to internet connection speeds. Of a total of 450 designs tested, 369 turned out to be feasible and 81 failed due to intersection checks or problems in the CFD process (e.g. failed CAD or mesh, solution divergence, etc). The latter represents a failure rate of 18%. The results for the 369 feasible duct geometries are discussed in the following section. 5.4 Optimisation Results The input values and the corresponding results for each design tested in modeFRONTIER are kept in a database created along the optimisation process. The user can manipulate this data, generate plots and perform advanced analysis on any combination of parameters to decide on the best design. When the two optimisation objectives are plotted against each other, as shown in Figure 11, a clear trade-off line can be identified along which the best designs are located. This boundary is the Pareto frontier described earlier in Figure 2. Further more, the chart also shows the design IDs, represented by the colour of the bubbles. The higher IDs are concentrated along the Pareto frontier, thus confirming the evolving nature of the Genetic Algorithm and how designs improve as new generations are introduced.

Figure 11. Discharge velocity vs. total pressure drop (Bubbles coloured by design ID).

The final design must be a compromise between pressure drop and velocity. This is typical of multi objective problems involving contradictory objectives. In this particular case, the discharge velocity was limited to 90 m/s in order to avoid high Mach numbers and possible sources of aeroacoutic noise. On this basis, a parallel chart was employed to highlight the designs in the Pareto frontier with velocities between 80 and 90 m/s. In this range only one design was detected as shown in Figure 12.

Figure 12. Parallel chart for Pareto frontier designs discharge velocity = 80 to 90 m/s. The final design (ID=354), selected using the parallel chart above, showed considerable improvement in terms of velocity and total pressure loss when compared to the baseline duct geometry. The discharge velocity was increased from 39.4 m/s to 82.13 m/s, while the total pressure drop was reduced from 932.5 Pa to 332.8 Pa. Similarly, Figure 13 compares the midspan velocities in the original and optimised ducts. The reduction in separation/stagnation areas is evident in the latter.

Figure 13. Velocity magnitude at mid-span (Left: original duct Right: optimised duct).

6. CONCLUSIONS AND PROSPECTS OF GRID ENABLED TECHNOLOGIES The potential of Grid to provide access to high performance computing resources for solving CFD automatic optimisation problems were highlighted via an industrial example. The shape of an underbonnet cooling duct was optimised using results obtained running OpenFOAM in a remote Grid environment. The process was successfully integrated in modeFRONTIER and all tasks performed fully automatically, including Grid execution on OpenFOAM and other licensed commercial software, such as CATIA v5 and STAR-Design. The overall time per calculation in the Grid machines turned out to be 20% slower than a comparable execution in a local server with similar CPU power. The difference was attributed to data transfer and available ADSL internet connection speeds. The latter remains a fundamental issue for exploiting Grid technologies at industrial level, but can be mitigated by relying on T3 or fiber/dark fiber OC line connections widely available for business use. CFD is a performance-oriented service with great computational demands. Problems to be investigated often have very complex geometry and physics which require the use of high resolution computational models, parallel computing and powerful HPC clusters. As a result, hardware costs become high to achieve these results. Recent technological trends, like the use of clusters of loosely-coupled Linux nodes (often called Beowulfs) are a reasonable price/performance compromise for high-performance computing in certain academic environments; but the effort of machine setup and maintenance are a deterrent for most SME and occasional users, as well as for small research groups. Against this backdrop, Grid offers itself as a unique opportunity where computing power, state-of-the-art software and human expertise can be found on demand, and hence very cost-effective. End-user participation from different industrial sectors, where CFD simulations is the main tool for design and optimisation purposes, will provide real, challenging applications for the assessment of the Grid-enabled CFD solvers and the use of Grid-resources to demonstrate the concept of CFD on-demand. The power of the Grid, and the unique features of the CFD software, would provide an advantage to the client, who will deliver functionality of setting-up the problem, monitor graphically the solution, visualising data in real time as the problem is solved, discovering Grid resources and submitting jobs on the Grid. Furthermore, industrial users would be able to increase productivity by accessing Grid resources, previously not accessible to them, and perform routine design and optimisation simulations without the need to invest on expensive hardware and/or software. In this sense, open source technologies could play a fundamental role as a perfect partner for solving CFD problems in remote Grid infrastructures. Similarly, CFD software vendors would be able to expand their business by providing services through the Grid. They would be able to lower their operating IT costs, provide better service level performance, respond faster to changing business, and achieve a higher resource optimisation.

Grid technology would also enable businesses to shift their budget from maintaining IT and provide a potential to solve very large parallel problems. The Grid technology gives an opportunity to the users to share databases in a secure environment, and also to use high amount of storage and computing power in a simple and transparent way. The initial steps for understanding the needs and challenges involved on delivering a feasible process for implementing and exploiting Grid technologies at industrial level were introduced in this paper with a simple industrial example. Further CFD related experiments are to follow as part of the ongoing EU funded BEinGRID Project.

7. REFERENCES
[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

Ian Foster, Carl Kesselman, Jeffrey M. Nick and Steven Tuecke. The Physiology of the Grid: An Open Grid Service Architecture for Distributed Systems Integration, 2002. I. Foster, C. Kesselman, S. Tuecke, The Anatomy of the Grid: Enabling Scalable Virtual Organizations International Journal Supercomputer Applications, Vol. 15, No. 3, 2001. P. Katsaloulis, E. Floros, A. Provata, Y. Cotronis, T. Theoharis, Gridification of the SHMap Biocomputational Algorithm, International Special Topic Conference on 'Information Technology in Biomedicine' by IEEE and EMB, Ioannina, 2006. O. Ardaiz, L. Diaz de Cerio, A. Gallardo, R. Messeguer, K. Sanjeevan, ULabGrid Framework for Computationally Intensive Remote and Collaborative Learning Laboratories, IEEE International Symposium on Cluster Computing and the Grid, 2004. Tristan Glatard, Johan Montagnat, Xavier Pennec, Grid-enabled workflows for data intensive medical applications, Computer Based Medical Systems (CBMS'05), Special Track on Grids for Biomedicine and Bioinformatics, Dublin, Ireland, June 23-24, 2005. Toan Nguyen, Lizhe Wang, Vittorio Selmin, Virtual Private Environments for Multiphysics Code Validation on Computing Grids, International Conference East West High-Speed Flow Field (EWHSFF'2005), Beijing, 2005. G.E. Pound, M.H. Eres, J.L. Wason, Z. Jiao, A.J. Keane & S.J. Cox. A Grid-Enabled Problem Solving Environment (PSE) for Design Optimisation within Matlab, Proceedings of the IPDPS 2003. G. E. Pound, M. H. Eres, M. J. Fairman, G. Xue, A. J. Keane and S. J. Cox, Grid middleware for engineering design search and optimisation, Lecture Notes in Computer Science, Springer, Proceedings of EuroPar 2003. Wenbin Song, Andy Keane, Hakki Eres, Graeme Pound, and Simon Cox, Two Dimensional Airfoil Optimisation Using CFD in a Grid Computing Environment, Lecture Notes in Computer Science, 2003. Tomoyuki HIROYASU Mitsunori MIKI Hisashi SHIMOSAKA, Optimisation Problem Solving System using Grid RPC, 3rd IEEE/ACM International Symposium on Cluster Computing and the Grid, Tokyo, Japan, May, 2003. Bhakti S. Lad, Mridula U. Pillai, Ashish Choudhari and Yatish Gupta, A Grid Computing Tool for Engineering Simulations, International Conference on High Performance Computing, HiPC 2006. Wenbin Song, Andy Keane, and Simon Cox, CFD-Based Shape Optimisation with GridEnabled Design Search Toolkits, Lecture Notes in Computer Science, Springer, Proceedings of EuroPar 2003.

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

Xiaobo Yang, Mark Hayes, Karl Jenkins, and Stewart Cant, The Cambridge CFD Grid Portal for Large-Scale Distributed CFD Applications, Lecture Notes in Computer Science, Springer, Proceedings of Computational Science - ICCS 2004. Karl Jenkins, Xiaobo Yang, Mark Hayes, Stewart Cant, Distributed computational fluid dynamics, Lecture Notes in Computer Science, Springer, Proceedings of Computational Science - ICCS 2004. FlowGRID Project Final Report, http://www.unizar.es/flowgrid/download/flowgridd83.pdf GRIA, Service Oriented Collaborations for Industry and Commerce: http://www.gria.org, 2007. Quagliarella, D., Priaux J., Poloni C., Winter G. Genetic Algorithms And Evolution Strategies In Engineering And Computer Science. Recent Advantages And Industrial Applications. J. Wiley & Sons, 1998. Del Vecchio, R. J. Understanding Design Of Experiments. Hanser Publisher, Mnich, 1997. Singiresu S. Rao. Engineering Optimisation Theory And Practice (3rd Edition). Wiley, Interscience, 1996. F. Campos, P. Geremia, S. Weston, and M. Islam, Automatic Optimisation of Aerodynamic Designs using CFD-based Methods, 6th MIRA International Vehicle Aerodynamics Conference, Warwick, 25 October 2006. Kalyanmoy Deb, Amrit Pratap, Sameer Agarwal, T. Meyarivan, A Fast Elitist MultiObjective Genetic Algorithm: NSGA-II, Proceedings of the Parallel Problem Solving from Nature VI Conference.