- Email: [email protected]
A holistic framework for engineering simulation platform development gluing open-source and home-made software resources
Advances in Engineering Software 76 (2014) 99–109
Contents lists available at ScienceDirect
Advances in Engineering Software journal homepage: www.elsevier.com/locate/advengsoft
A holistic framework for engineering simulation platform development gluing open-source and home-made software resources Zhao Tang ⇑, Weihua Zhang, Pingbo Wu State Key Laboratory of Traction Power, Southwest Jiaotong University, Chengdu, People’s Republic of China
a r t i c l e
i n f o
Article history: Received 7 April 2014 Received in revised form 22 May 2014 Accepted 8 June 2014 Available online xxxx Keywords: Simulation platform development Open-source resources Framework Gluing component Codes coupling Data exchange
a b s t r a c t The budgetary pressure of engineering simulation platform development is continuing to increase in industry, especially for those scientific institutions, while simulation platform is becoming increasingly important for the researchers in their daily work. Plenty of basic components provided for free by open-source communities can be used to develop simulation platform; however, using open-source components is much more technically difficult than directly utilizing commercial simulation platform. We propose a novel gluing components to tackle the existing difficulties of engineering simulation platform development by using open-source components and home-made resources. In order to reduce the development cost, a holistic framework named TPL.Frame, whose core is the gluing component, is designed to develop engineering simulation platform that consists of SALOME simulation platform, OGRE engine and some other home-made numerical codes. Unlike general commercial simulation solutions, the framework provides not only the basic functionalities, including CAD (Computer-Aided Design) and CAE (Computer-Aided Engineering), but also advanced features, such as real-time 3D visualization, interoperability between FE (Finite Element) method and MB (Multi-Body) dynamics, distributed simulation modeling and other user-defined features. To compare with traditional development method, several cases studied in railway industry are given to demonstrate how to rapidly develop engineering simulation platform using TPL.Frame, thus to prove the effectiveness of the proposed framework. Ó 2014 Elsevier Ltd. All rights reserved.
1. Introduction In the past few decades, the simulation platform has become more and more important in both research and industry and simulation models have continued to grow more complex and larger. Therefore, the continuing growth of the demand for simulation platform with better performance, wider interoperability, higher reliability, and shorter development cycles, has produced great budgetary pressure in industry and scientific community. In this situation, both researchers and developers have been trying to find a framework of simulation platform development to promote the achievement of arriving at an operational state, on time and with low costs. Engineering simulation platform development needs to use a lot of fundamental software components or modules in different disciplines and domains. Even if the development technology and theoretical basis of these components or modules are quite mature, we need to spend much time and cost in developing them. ⇑ Corresponding author. Address: No. 111, First Section, North of Second Ring Road, Chengdu, Sichuan 610031, People’s Republic of China. Tel.: +86 13548110233. E-mail address: [email protected] (Z. Tang). http://dx.doi.org/10.1016/j.advengsoft.2014.06.004 0965-9978/Ó 2014 Elsevier Ltd. All rights reserved.
Directly purchasing commercial software platform can seem a good choice for some enterprises or institutions, but it is unsuited for sector-specific ones. In one hand, in order to satisfy the demands of all kinds of enterprises and research institutes, commercial software platforms are needed to provide many feature-rich functions, but most of them are often useless to sector-specific enterprises or institutions. In the other hand, general commercial software platform cannot solve some sector-specific problems. For example, LMS Virtual.Lab [1] is an integrated suite of 3D FE and multibody simulation software and widely used in auto and aviation industry, but it cannot be used in railway industry for rail vehicle dynamic simulation due to not providing some special force elements, for example, wheel-track force, which is the most important force element for rail vehicle simulation. To solve some sector-specific issues in a professional field, researchers or engineers themselves need to develop some applications that is typically console-based and represent ‘isolated islands of automation’, namely without any supporting for data transfer in usage. These applications called home-made software are often valuable resources for enterprises or institutions and need to be integrated into simulation platform. Integrating home-made software into commercial simulation platform is difficult because they
100
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
are not thoroughly open to the users. With respect to flexibility and reusability of home-made software, solely utilizing commercial software packages for the simulation platform development also limits the capabilities of the implementation. On the contrary, self-developed platform provides the most convenient way for home-made software integration. To date, the open-source community has generated highquality simulation software codes or components, and they are available free of charge. In many cases, we can select best-of-breed codes to reuse in our system without having to reinvent the wheel. Nevertheless, It is obvious that developing and maintaining a simulation platform are a challenging task for scientific institutions or enterprises, especially for those in which there are much more researchers and engineers than software developers. Although open-source community provides us with a fund of reusable fundamental components or modules, including software tools and programming libraries, the complexity of developing and maintaining a simulation platform based on open-source resources including integrating between existing home-made codes and open-source system, codes coupling, and data exchange and interoperability cannot be ignored. In this paper, we propose a holistic framework (TPL.Frame) for engineering simulation platform development gluing open-source and home-made software, which can reduce the development cycle while still maintaining a manageable level of complexity as well as realistic cost goals. A framework is a set of classes, interfaces and patterns to solve a group of problems, which is a popular method to improve the development efficiency and reduce the development cost. In scientific and research community, researchers or developers have proposed many efficient frameworks. In the development of the finite element analysis system TopFEM, a framework is presented to take advantage of the topological data structure together with objectoriented programming concepts to handle a variety of finite element problems, in an efficient, but generic fashion [2]. Modularizing the repetitive functions, data acquisition and transmission frameworks have been established in online applications field, which is extensible and flexible [3]. A Web-based MDO (Multidisciplinary Design Optimization) framework has been developed to assist in the analysis and optimization of highly complex system [4]. A systematic review of 20 designed frameworks and software framework in general was conducted in the biomedical informatics domain in [5]. More examples can be found in [6–9]. Most of them depend on commercial software system and focus on resources and processes integration. A JAVA desktop application framework is proposed for homemade software integration in scientific community, which summarizes the typical user interaction flow in simulation field as IPO (input-process-output) mode and is implemented following a plugin-based architecture, also allows assembling new applications by the reuse of modules from past development projects [10]. The framework has made great progress in home-made software integration, but it is inadequate for highly interactive and real-time simulation platform development due to the IPO model. Furthermore, the JAVA-based framework is inconvenient to integrate Cbased or FORTRAN-based application. Nevertheless, the fact is that FORTRAN, C/C++ and Perl are widely used in scientific community and FORTRAN is the most popular programming language in the field of computational science especially in high performance computing [11]. Component-based framework is widely used for the integration of scientific simulation and visualization software due to its extensibility, reusability and tailorability [12–15]. SALOME [16], a typical distributed component-based model architecture system based on the CORBA [17], is a full-fledged open-source software platform for pre and post processing in numerical simulation. In
the field of industrial simulation, SALOME is widely used as a numerical calculation framework, such as the European nuclear reactor simulation platform (NURESIM) [18] and a simulation tool for grounding systems (TOTBEM) [19]. Salome is mainly used to construct pre and post processing module in numerical simulation system, which cannot provide all the functions required in industry simulation platform development, such as real-time visualization and solver. Moreover, researchers and developers need make adequate interface and implementation method to integrate solver into SALOME. Obviously, it is a better way that a framework can offer a simple programming model while enabling high performance on any kind of resources. Real-time visualization need to use graphics rendering engines. Since 2001, OGRE has grown to become one of the most popular open-source graphics rendering engines in open-source community and has been used in a large number of production projects [20]. IRRLICHT [21] and OSG [22] are another two popular graphics rendering engines. Nevertheless, IRRLICHT is mainly suited for game development and there are hardly any application cases in simulation field. The main advantage of OSG is its clean and intuitive scene management. However, it is not necessary to manage very complex scene in simulation application. OGRE provides easy access to OO interface designed to minimize the effort required to render 3D scenes and it is widely used as a real-time rendering engine in industrial simulation system. More important is that OGRE is most popular among various open-source graphics rendering engines. Therefore, we can obtain strong community support. For such reasons we choose OGRE as real-time rendering engine in our framework. The remainder of this paper is structured as follows. The integration architecture of TPL.Frame platform is presented in Section 2. The key concepts and implementation of home-made numerical codes process into the platform is described in Sections 3 and 4. Section 5 discusses the data exchange and interoperability strategy. Section 6 looks into the usage details and presents a case study in Chinese high-speed train pantograph–catenary simulation. Finally, Section 7 summarizes the main conclusions.
2. Integration framework and software environment TPL.Frame consists of three layers: function layer, tool layer and resource layer. The architecture of TPL.Frame is depicted in Fig. 1. The function layer is the core of the whole framework and provides interfaces to external applications. The interfaces exposed by function layer include geometry modeling, mesh generating, real-time visualizing, post processing and numerical simulation. Geometry modeling interfaces provide basic functionalities, such as creating, importing and correcting CAD models. Mesh generator interfaces are mainly used for meshing the geometric elements, mesh importing/exporting and quality controlling. Post-processing interfaces are for displaying the data in different ways in different views. Real-time visualization interfaces render the 3D scene which is created by geometry modeling and converted into OGRE mesh by converter tool, delivering real-time interactive experiences. Numerical simulation interfaces implement solution problem solving and provide data needed by post-processing or real-time visualization. In tool layer, TPL.Frame mainly utilize SALOME platform to provide pre and post processing functionalities. In order to meet the real-time requirement, OGRE is adopted to realize the 3D scene organizing and real-time rendering. The home-made applications are composed of numerical codes, configuration and rules. Configuration need to be added by user when home-made applications are integrated into the TPL.Frame. Configuration and rule facilitates the implementation of the coupling between computing codes in a
101
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
Fig. 1. TPL.Frame architecture overview.
heterogeneous distributed environment. Home-made applications is the only module need to be developed by user, and the provided features of TPL.Frame include working with mesh, fields, material database, linear and nonlinear PDE (Partial Differential Equation) or ODE (Ordinary Differential Equation) solvers, selection of simulation methods and pre-coded solvers for equations. Resource layer is responsible for storing and managing resource using file system or database. The types of resource involve GUI, parameter XML file, 3D model file, mesh file, configuration xml file and rules xml files.
Kernel 3. An overview of TPL.Frame 3.1. Key concepts of TPL.Frame Component-based architecture is flexible and simple enough to allow an intuitive and straightforward decomposition of a complex coupling code into easy-to-implement components. So it is widely used in the development of scientific computing software, especially for the large-scale engineering simulation platforms, such as multidisciplinary simulations, parallel system and distributed system. Based on component-based architecture models, we define three kinds of major elements (see Fig. 2) in TPL.Frame: Kernel, Components and Gluing components.
component
gluing component
Fig. 2. Three kinds of major elements.
Kernel provides the basic functionalities, such as logging, event reporting, memory checking, exception handling. Components, namely general components, implement real application functionalities, such as meshing, geometry modeling, visualization, simulation. Gluing components define the interaction and interoperability between components. Kernel is the infrastructure of TPL.Frame, which consists of open-source software libraries and need not to be modified by the users at any cases. Components encapsulate useful units of functionality and interact with kernel. At the heart of the TPL.Frame is the concept of gluing components, through which components interact and ‘‘glue’’ with each other. Our aim while designing gluing components is to help alleviate some of the complexity of large-scale simulation platform development and impose minimal requirements for existing home-made software so as to integrate it into TPL.Frame. As shown in Fig. 2, the gluing components need not interact with kernel directly. Gluing components will be explained in more detail in the next section.
3.2. Gluing components implementation The gluing components are the key to integrating existing home-made applications into TPL.Frame. Gluing nodes play an important role in the implementation of gluing components. Considering scalability and flexibility, we design tree kinds of gluing node: adaption gluing nodes, replacement gluing nodes and extension gluing nodes. Adaption nodes are similar to template classes and can be modified by the users directly. Replacement gluing nodes contain another gluing node and are suitable for developing new gluing nodes. Extension gluing nodes can be inherited to develop new functionalities. In order to avoid adding code to existing classes for creating different gluing nodes, abstract factory design pattern is used to create different gluing nodes using a corresponding protocol. Abstract factory design pattern offers the interface for creating a family of gluing nodes, without explicitly specifying their classes the gluing components design model is shown in Fig. 3.
102
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
Fig. 3. Gluing components design model.
By using the abstract factory model, the coupling data and parameters are exchanged at the level of gluing nodes. A gluing input interface (Iinput) represents the signal that is transmitted from the component B to component A. A gluing output interface (Ioutput) is a signal received from component A. The data and functionalities conveyed by input and output interface can be different because these data and functionalities will be processed inside gluing components. 4. Codes coupling The one of most important problems facing large-scale simulation platform is how to integrate existing codes, namely codes coupling, with minimal codes modification. To solve this problem, we provide a library called TPL.Gluing.API contained in TPL.Frame, which is dedicated to establish connection and cooperation among all codes or applications, exposes their interfaces to other modules. At the same time, TPL.Gluing.API also provides C++ or FORTRAN wrappers for connection and integration between SALOME and OGRE. 4.1. Codes coupling between multibody dynamics and finite element method Many complex engineering systems, for example, pantograph– catenary system in high-speed train, require using different-nature computational codes for their sub-systems simulation. How to couple these different disciplines computational codes is one of the main issues to be solved in the development of large-scale engineering simulation platform. MBD (Multibody Dynamics) subsystems and FEM (Finite Element Method) subsystems are two most typical sub-systems in engineering simulation, which often need corporate to simulate the dynamics behavior of mechanical system. A typical multibody model is defined as a collection of rigid or flexible bodies that have their relative motion constrained by kinematic joints and is acted upon by external forces. In general, DAE (differential algebraic equations) or ODE (ordinary differential equation) are used for simulating the dynamic behavior and the equation of motion using DAE like this:
"
M
UTq
# € q
Uq
O
k
¼
g
c
ð1Þ
€ is the accelwhere M is the mass matrix, Uq is the Jacobian matrix, q eration vector, k denotes the vector of the Lagrange multipliers, g is force vectors applying to the system body. c is a vector with the right-hand side of the constraint acceleration equations. Using the finite element method to represent the structure, the equilibrium equations for the structural system are:
€ þ C X_ þ KX ¼ F MX
ð2Þ
where M, C and K are the finite element global mass, damping and stiffness matrices, respectively, x is the vector with the nodal displacements. F is a vector with the forces applied to the system. Obviously, Eq. (1) needs depend on CAD model and corresponding parameter, but Eq. (2) needs to be solved using mesh model, which are entirely different data structure and need in turn use their respective time integration algorithms. For coupling FE and MB codes, J. Ambrósio et al. use memory mapped file to communicate between MB and FE software, which enables simultaneous access of the type of application code or environment [23]. There are many obvious drawbacks on using memory mapped file, including the requirement of a fixed file size and break of program structure. Moreover, the more urgent shortage is that memory mapped file requires all applications or programs to be deployed on the same computer, not to support distributed simulation. We propose gluing component-based strategy to achieve MB and FE codes coupling. The strategy not only supports distributed simulation but also allows any choices for integrators. We use gluing DSC components (dynamic software component) to realize the strategy. Gluing DSC is an extension of SALOME object concept, which conforms to the gluing component design model and adds utility and supply ports to SALOME object. A port is a CORBA interface and each port has its own properties. Supply ports implement the interface, while utility ports are connected to supply ports for using the interface. The strategy is outlined in Fig. 4. First, the existing MB and FE codes are wrapped into components using TPL.Frame.Wrapper API, consisting of a user-defined C++ or FORTRAN interface file and a XML script file. Then, the wrapped MB and FE components are coupled by two gluing components. Finally, the coupled MB and FE components are translated into DSC components (TPL.Frame.FE and TPL.Frame.MB) using IDL interfaces file, which are made independently. So the distributed deployment can be conveniently applied to both codes.
103
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
DSC Component C++ or Fortran Interface Files
MB Component
TPL.Frame.FE DSC
Supply Port IDL I mplemention
IDL Interface
Utility Port MB Gluing Component
Gluing Component TPL.Frame.Wrapper FE
Utility Port
Supply Port
Supply Port
Utility Port
DSC Component TPL.Frame.FE DSC
Codes FE Component
IDL Interface
Supply Port
IDL I mplemention
XML Script Utility Port Dynamic Software Component Model
Fig. 4. Coupling flow between FE and MB in TPL.Frame.
4.2. Coupling between simulation models and solver
5. Data exchange and interoperability
After the home-made codes are wrapped into solver components, we need to integrate them into TPL.Frame framework as a whole. However, the home-made codes which are possible to use internal parallel techniques are generally written by different program languages, such as C++, FORTRAN and C, while simulation models are described by differential, algebraic and discrete equations with time event, state event and step event. How to integrate solver components into TPL.Frame is another problem. Similarly, we use gluing components-based strategy to solve this problem as shown in Fig. 5. First, solver components and gluing components are wrapped again into solver engine, which is actually a SALOME module. Then, the solver engine can be integrated into SALOME platform using provided integration method by SALOME, which can be found in [24]. Since solver components are already integrated into SALOME module, the simulation model created through SALOME GUI (such as Geometry GUI, Mesh GUI, and user-defined GUI) can tightly be linked with solver components. The detail of gluing components used for the integration between simulation models and solver is shown in the right of Fig. 5. Two adaption gluing nodes are used for creating the gluing components. One is for input and the other is for output. The advantage of using two adaption gluing nodes is that users can define data flow or processing flow on demand at any time.
The strategy of data exchange and interoperability is one of the most important aspects for the large-scale simulation platform development. TPL.Frame also needs tight data exchange and interoperability strategy between modules, especially between CAD and CAE modules. Besides data exchange and interoperability between internal modules, it is also necessary to provide data exchange and interoperability strategy with external commercial software because users often need to reuse existing models created by commercial software or use some advanced features provided by commercial software. However, for the reason of competition among commercial software vendors, CAD data exchange between heterogeneous applications is not really supported. Data models are also still exchanged by native file formats. Efforts by standardization organization (STEP, IGES) and software industry, which now delivered Web-based platforms such as CORBA and Java, can also only superficially address the interoperability problem [25,26]. Because the diversity of CAE data and the structure of CAE data are more complex than ones of CAD data, less attention has been paid to systematic research on the exchange and interoperability of CAE data including field data and time series data [27]. To offer the opportunity to seamless communication of CFD (Computational Fluid Dynamics) analysis data between sites, applications and system architectures, NASA and Boeing develop the CGNS, CFD General Notation System [28] which is a general,
Geometry GUI
Mesh GUI
Solver GUI
Gluing Input
Solver Component B
Services
Communication Layer (CORBA) Gluing Nodes
Solver Components Geometry Components
Mesh Components
Gluing Component
Gluing Components Solver Engine
Services Fig. 5. Solver integration into TPL.Frame.
Gluing Output
Solver Component A
104
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
portable, and extensible standard for the storage and retrieval of computational fluid dynamics (CFD) analysis data. Song et al. present a CAE data exchange method for the effective sharing of geometric and analyzing data [29,30]. In TPL.Frame, we combine CGNS and data exchange method presented by Song et al. into SALOME platform. HDF file structure [31] and MED data model [32] are combined to solve storing problem of heterogeneous data source. The data exchange and interoperability processing flow are outlined in Fig. 6. CAD models data exchange with commercial software, such as CATIA, PRO/E, UG, SOLIDWORKS, SOLIDEDGE, mainly utilizes neutral files: IGES and STEP. A plug-in of TPL.Frame, PYTHON script, is used for CAE data exchange with external commercial software, which can be extended and modified by other user on demand. TPL.Frame provides data processing API package, including File Data Server components and Metadata Server components to translate these data for matching the data model template of TPL.Frame. Then, these data can be used by TPL.Frame as internal data. TPL.Frame uses MED to store and recover data associated with numerical meshes and fields. As shown in Fig. 6, a three-level interfaces of MED-FILE, MED-memory and MED-CORBA provide the Interoperability among TPL.Frame modules. With the help of SALOME platform, TPL.Frame provides the functionality of exchange data between codes or solvers in
Commercial CAD Software CATIA
memory. CORBA is used to allow communication of modules on remote servers. TPL.Frame allows users to read mesh from MED files into memory (using MED-memory API), to process mesh coordinates and connectivity, work with groups of mesh (which can be defined in SALOME editor) and seamlessly pass this information to home-made solvers and OGRE engine, which provides some core fields meant to be used in all simulations and visualization modules. Custom fields can be defined as well and the field data structure is based on MED field data type. We provide overloaded access operators for easy access of the items in the framework, as well as support for retrieving data from home-made applications to OGRE and SALOME for real-time visualization and calculation.
6. Case study: the application of TPL.Frame in china railway industry This section will demonstrate how to use TPL.Frame to rapidly develop engineering simulation platform for china railway industry and draw a comparison with traditional development mode. There are two infrastructure mechanical interfaces in railways, one is the wheel/rail contact, and the other is pantograph–catenary interface. Electric power can be transferred from an overhead catenary to the high-speed train via a pantograph that is mounted
Commercial Data Model Neutral Files
Commercial CAE Software ANSYS
CAD Data
CAE Data
PRO/E
ABAQUS
API Call
TPL.Frame Data Model Template UG
SOLIDWORKS
MSC.Marc
Python Script
FLUENT
Reference TPL.Frame Data Processing API Package
SOLIDEDGE
Salome Container
...
LS-DYNA
Metadata Server Components
Salome Container
File Data Server Components
...
Dynamics Component (DSC)
DSC
SALOME/COERBA
C,C++FORTRAN Data Access API
Memory Mapping Memory data MED CORBA MED User Files
TPL.PC Data Engine HDF File Wrapper
MED Server Memory
Salome Container DLL
Combination
Salome Components
Files Mapping
MED Files User Interface HDF Files
HDF File Database
Fig. 6. Data exchange and interoperability processing flow in TPL.Frame.
105
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
on its roof. The dynamic behavior of pantograph–catenary system not only limits the top velocity of high-speed trains but also affects the functions of some mechanical equipment on the train. Therefore, the pantograph–catenary interface plays a vital role in the high-speed train. A large number of works are dedicated to the study of the pantograph–catenary system dynamic behavior by different simulation methods and software tools. SAMCEF, a commercial finite element analysis software, is used to analyze the dynamic catenary–pantograph interaction [33,34]. The finite element software ANSYS is the most popular choice of software for the catenary simulation and modeling [23,35]. Besides ANSYS, SIMPACK commercial multibody code is often also used to simulate the pantograph, i.e., PROSA [36]. Developing simulation software generally need take a long time to do. The code CATMOS developed in the early 1990s is applied to the vibration analysis of pantograph– catenary system [23]. EUROPACAS including EUROPACAS-FE and EUROPACAS-MB allows simulating any type of pantographs and catenaries in three dimensions, and taking into account all kinds of effects such as the action of wind, temperature, switches, road bridges [37]. It is developed by EUROPAC project, which took place from January 2005 to December 2007. In summary, pantograph– catenary system simulation software can be divided into two categories. One is co-simulation or re-development based on commercial software, such as CATMOS, FAMOS, PROSA and DINACAT/ WINCAT. The other is directly using general commercial multibody dynamics software and finite element analysis software, such as SIMPACK, ANSYS, SAMCEF and ABAQUS. But because there are not professional pantograph–catenary solvers in the general commercial software packages, the ease of use is not as good as they are used for other simulation projects. In addition, the process is also tedious when commercial software is used to simulate the pantograph–catenary system. Obviously, the data exchange and interoperability are not really supported between commercial multibody dynamics software and finite analysis software. Therefore, it is very necessary to develop the simulation software for pantograph/catenary system independent of commercial software. To overcome these disadvantages mentioned above, we develop a holistic pantograph–catenary simulation platform named TPL.PC, which is used for pantograph–catenary system simulating, modeling, designing and analyzing. With the help of TPL.Frame, some advanced functions, such as geometry modeling, meshing, solver
and 3D visualization for continuous simulation data, are easily realized in TPL.PC. It also provides interoperability between CAD modeling and CAE simulating, which can achieve data exchange between multibody dynamics and finite analysis. More details about TPL.PC will be described in the next sections. 6.1. FE and MB integration In order to simulate the dynamic behavior of pantograph– catenary system, the Finite Element (FE) method is used to support the modeling of the catenary, and multibody (MB) dynamics method is applied to support the pantograph modeling. Obviously, we need co-simulation of multibody and finite elements. However, the general commercial software cannot meet the special requirement in the same system. With the goal of gluing the multibody and finite elements method, based on the TPL.Frame, TPL.PC gives an example on how to exchange simulation information between FE and MB. The analysis of the pantograph–catenary interaction generally needs to be done by two independent codes. The pantograph code uses a MB formulation, while the catenary code uses FE equation in nature. Each of the two codes contains an internal loop to handle iterations. So the interceding communications need to be performed after each iteration step. Moreover, both codes, which work as stand-alone codes, need to be coupled to simulate the dynamic behavior of pantograph/catenary system. Correspondingly, In TPL.PC, the simulation is done by two independent programs. One is the pantograph program, TPL.PC.MB, which uses multibody dynamics method. The other is catenary program, TPL.PC.FE, that is a finite element program. As shown in Fig. 7, the simulation calculation cycle is divided into two steps. In the first step, TPL.PC.FE is running while the TPL.PC.MB is waiting for the calculation result. In the second step, TPL.MB is running while TPL.FE is waiting for the result generated by TPL.MB. The simulation flow is well supported by TPL.Frame (see Fig. 4.). Moreover, as to pantograph–catenary system parallel simulation computation, two steps need to be implemented. First, a preprocessing application splits the mesh and prepares data model for TPL.PC solver engine. Then, the TPL.PC.FE and TPL.PC.MB are launched in the same memory space for loop computation. For each cycle step, TPL.PC.FE calculates the data for TPL.PC.MB then sends them with corresponding messages, subsequently; the
Notification
Notification
FEM to MB
MB to FEM
TPL.PC.MB
TPL.PC.FE
TPL.PC.MB
TPL.PC.FE
Information Exchange
Information Exchange
Force,Postion
Velocity,Postion
Step 2
Step 1 Dataflow
Processing
Datastream Waiting
Fig. 7. Simulation flow between FE and MB.
106
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
(a) Pantograph model imported from commercial software
(b) 3D catenary model automatically generated by TPL.PC Fig. 8. 3D geometry modeling case with the help of TPL.PC platform.
(a) 1D catenarymesh
(b) 3D pantograph part mesh Fig. 9. Meshing on the TPL.PC.
TPL.PC.MB computes its step and sends its data back to TPL.PC.FE. The computation process is also wrapped as a gluing component. 6.2. 3D geometric modeling Geometric modeling is one of the most fundamental functionalities in engineering simulation platform. Commercial CAD software provides plenty of 3D modeling techniques and methods such as parametric modeling and variable modeling, but TPL.PC needs a built-in 3D modeling technique for pantograph–catenary automatic modeling. SALOME uses the Open CASCADE [38] as built-in 3D modeling modules, TPL.PC can utilize the basic functions of Open CASCADE directly based on TPL.Frame. The results of pantograph imported from external commercial software and the
automatic generating catenary model by TPL.PC are shown in Fig. 8. The existing model data created by external application can be reused on the TPL.PC via importing IGES or STEP neutral files, which can save time and cost for engineers. 6.3. Mesh Meshing is the most important step for finite element analysis. NETGEN [39], an automatic 3D tetrahedral mesh generator, which is integrated into the SALOME platform as an external plug-in, is used to generate 3D pantograph mesh and 1D catenary mesh. NGSolve is integrated into TPL.PC for finite element solving. The mesh results are shown in Fig. 9.
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
107
Fig. 10. Mesh and geometry model are displayed in the same view.
In addition, to satisfy the special demand of catenary simulation, the nodes of meshing can be grouped automatically based on the parameters like the number of span and the distance of spans which reduces verbose user operations. To observe the position of mesh parts in the assembly, TPL.PC can display the mesh and geometry model at the same time, which is shown in Fig. 10. 6.4. Post processing It is crucial for end users of TPL.PC to find efficient and attractive ways to visualize the result files and data. The post-processing capabilities of TPL.PC include rich features, such as 2D chart and
3D visualizations, animations of the results in both 2D and 3D, and experiment control visualization. Upon the successful execution of a TPL.PC solver, a number of computing files and data will be created. Fig. 11 partly shows the post processing function of TPL.PC used for pantograph–catenary simulation. Real-time 3D visualization and stereoscopic display can add visual interest to the users and provide fully immersive interactive environment, TPL.PC uses gluing component to wrapper OGRE engine, which can conveniently realize the real-time visualization and stereoscopic display (see Fig. 12). In addition, parallel visualization of large-scale dataset is supported by TPL.PC based on TPL.Frame.
(a) Animation of mass-spring-damper model
(b) Modal shape of contact line
(c) 2D chart and table of contact force
(d) Simulation stress distribution
Fig. 11. Post processing functions of TPL.PC.
108
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
Fig. 12. Real-time 3D visualization based on OGRE engine.
Table 1 Comparison with traditional development mode. Comparison item
Using TPL.Frame
Independent of any framework
Directly using SALOME
Development cycle Meshing Geometric modeling Real-time 3D visualization
2 months Full Full Supporting
About 20 months Just supporting 1D Just supporting 2D Not supporting
3 months Full Full Not supporting
6.5. Comparison with traditional development mode As mentioned before, it will take a long time to develop largescale engineering simulation software. For example, EUROPAC project had taken 2 years to develop EUROPACAS. In our lab, there are several pantograph–catenary simulation systems developed by different groups with different development mode. In our experiment, using TPL.Frame not only dramatically reduces the development cycle but also provides more rich features. The detailed comparison between TPL.Frame-based mode and traditional development mode is shown in Table 1. By comparison, we find that the development cycle only need 2 months by using TPL.Frame, while directly using SALOME takes about 3 months. Relative to SALOME, TPL.Frame supports real-time 3D visualization because we integrated OGRE into the frame. From the table, it is obvious that developing engineering simulation software independent of any framework will take a long time (20 months) only achieving some basic functions.
7. Conclusions The goal of developing TPL.Frame is to provide a holistic framework including pre-processing, solver and post-processing for engineering simulation platform development based on the open-source and home-made resources. Open-source software offers key advantages for the development of industry simulation platform, especially for sector-specific industry filed. Relative to commercial software, open-source software also has the benefit that engineers can inspect the source code to maintain and make
modifications when necessary. With the help of the TPL.Frame, users can take full advantage of open-source software and do not have to spend much time on the demanding design, development and maintenance of the pre-processor, post-processor, real-time visualization and simulation solver library. Thus, they can concentrate on developing the simulation model and solving algorithm. We put forward the novel gluing components concept for integrating open-source and home-made resources effectively and conveniently. Using gluing components, the components of TPL.Frame can be dynamic replaced, adapted and extended, which provides good extendibility and reusability for developers. Gluing nodes, which is a connector that makes a generic collaboration adapted to a specific application and defines the differences between the generic and the specific, play the vital role in gluing component. In TPL.Frame, we give a solution to solve some important problems in terms of the development of engineering simulation platform. Firstly, integrating home-made codes is a tough task since the target applications, such as TPL.PC.FE and TPL.PC.MB, may prove very different. We present the integration method based on a flexible programming model, which depends on the component paradigm to address this challenge. Secondly, the solver integration is a very important task for all simulation platform development. Based on the component-based application framework, we wrap solver codes as a solver engine that uses parallel containers and parallel DSC component. It is a quick and pervasive integration method and has many advantages such as real-time visualization and interaction. Thirdly, data exchange and interoperability are discussed in detail and process flow chart is presented based on HDF and MED. These methods presented in this paper give an example on how to solve these main problems in term of developing a large-scale engineering simulation platform. In the end, the case study is given to not only verify the effectiveness of the platform framework but also demonstrate the usages of the framework. In our experience, using TPL.Frame framework for large-scale engineering simulation platform development can dramatically save time and cost. Acknowledgement This work was partially funded by the National Natural Science Foundation of China (51075341).
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
References [1] LMS.Virtual.Lab., [accessed 20.5. 2014]. [2] Beghini LL, Pereira A, Espinha R, Menezes IF, Celes W, Paulino GH. An objectoriented framework for finite element analysis based on a compact topological data structure. Adv Eng Softw 2014;68:40–8. [3] Bai W, Wang N, Zhu J, Zhang B. A generic framework for data acquisition and transmission. Adv Eng Softw 2014;68:49–55. [4] Lwin T, Vu NA, Lee J-W, Kim S. A distributed Web-based framework for helicopter rotor blade design. Adv Eng Softw 2012;53:14–22. [5] Al-Bashayreh MG, Hashim NL, Khorma OT. Software frameworks in biomedical informatics: a systematic review and research agenda. J Soft 2013;8:2996–3006. [6] Zhang C, Zhang L. Model of multidisciplinary simulation integration in helicopter rotor blade design process. Int J Comput Integr Manuf 2014;27:229–41. [7] Dang X-P. General frameworks for optimization of plastic injection molding process parameters. Simul Model Pract Theory 2014;41:15–27. [8] Castañé GG, Nunez A, Llopis P, Carretero J. E-mc2: a formal framework for energy modelling in cloud computing. Simul Model Pract Theory 2013;39:56–75. [9] Li Y, Zhao W, Hu L. A process oriented hybrid resource integration framework for product variant design. J Comput Inf Sci Eng 2012;12:041005. [10] Fdez-Riverola F, Glez-Peña D, López-Fernández H, Reboiro-Jato M, Méndez JR. A JAVA application framework for scientific software development. Software: Practi Exp. 2012;42:1015–36. [11] Nguyen-Hoan L, Flint S, Sankaranarayana R. A survey of scientific software development. In: Proceedings of the 2010 ACM-IEEE international symposium on empirical software engineering and measurement: ACM; 2010. p. 12. [12] Bernholdt DE, Allan BA, Armstrong R, Bertrand F, Chiu K, Dahlgren TL, et al. A component architecture for high-performance scientific computing. Int J High Perform Comput Appl 2006;20:163–202. [13] Palmer B, Gurumoorthi V, Tartakovsky A, Scheibe T. A component-based framework for smoothed particle hydrodynamics simulations of reactive fluid flow in porous media. Int J High Perform Comput Appl 2010;24:228–39. [14] Malawski M, Gubała T, Bubak M. Component-based approach for programming and running scientific applications on grids and clouds. Int J High Perform Comput Appl 2012;26:275–95. [15] Benali H, Saoud NBB. Towards a component-based framework for interoperability and composability in Modeling and Simulation. Simulation 2011;87:133–48. [16] SALOME.
[19]
[20] [21] [22] [23]
[24] [25] [26] [27] [28] [29] [30] [31] [32] [33]
[34]
[35] [36]
[37]
[38] [39]
109
scale and multi-physics calculations, sensitivity and uncertainty analysis. Nucl Eng Des 2011;241:3416–26. Colominas I, Parıs J, Fernández D, Navarrina F, Casteleiro M. A numerical simulation tool for multilayer grounding analysis integrated in an open-source CAD interface. Int J Electr Power Energy Syst 2013;45:353–61. OGRE.. Fröbel T, Firmenich B, Koch C. Quality assessment of coupled civil engineering applications. Adv Eng Inform 2011;25:625–39. Vergeest JS, Horváth I. Where interoperability ends. In: Proc of the 2001 computers and information in engineering conference; DETC2001. Cho SW, Kim SW, Park J-P, Yang SW, Choi Y. Engineering collaboration framework with CAE analysis data. Int J Prec Eng Manuf 2011;12:635–41. CFD data standard [accessed 20.5.2014]. Lee J-H, Kim Y-G, Paik J-S, Park T-W. Performance evaluation and design optimization using differential evolutionary algorithm of the pantograph for the high-speed train. J Mech Sci Technol 2012;26:3253–60. Jung SP, Park TW, Kim YG, Paik JS. Estimation of dynamic contact force between a pantograph and catenary using the finite element method. J Comput Nonlinear Dyn 2012;7:041006. AmbrÃg‘ sio J. Multiple pantograph interaction with catenaries in high-speed trains. J Comput Nonlinear Dyn 2012;7:041008. Busch M, Schweizer B. Coupled simulation of multibody and finite element systems: an efficient and robust semi-implicit coupling approach. Arch Appl Mech 2012;82:723–41. Bobillot A, Cléon L, Collina A, Mohamed O, Ghidorzi R. Pantograph–catenary: a high-speed European couple. In: Proceedings of the Eighth World Congress on Railway Research; 2008. CASCADE.
Contents lists available at ScienceDirect
Advances in Engineering Software journal homepage: www.elsevier.com/locate/advengsoft
A holistic framework for engineering simulation platform development gluing open-source and home-made software resources Zhao Tang ⇑, Weihua Zhang, Pingbo Wu State Key Laboratory of Traction Power, Southwest Jiaotong University, Chengdu, People’s Republic of China
a r t i c l e
i n f o
Article history: Received 7 April 2014 Received in revised form 22 May 2014 Accepted 8 June 2014 Available online xxxx Keywords: Simulation platform development Open-source resources Framework Gluing component Codes coupling Data exchange
a b s t r a c t The budgetary pressure of engineering simulation platform development is continuing to increase in industry, especially for those scientific institutions, while simulation platform is becoming increasingly important for the researchers in their daily work. Plenty of basic components provided for free by open-source communities can be used to develop simulation platform; however, using open-source components is much more technically difficult than directly utilizing commercial simulation platform. We propose a novel gluing components to tackle the existing difficulties of engineering simulation platform development by using open-source components and home-made resources. In order to reduce the development cost, a holistic framework named TPL.Frame, whose core is the gluing component, is designed to develop engineering simulation platform that consists of SALOME simulation platform, OGRE engine and some other home-made numerical codes. Unlike general commercial simulation solutions, the framework provides not only the basic functionalities, including CAD (Computer-Aided Design) and CAE (Computer-Aided Engineering), but also advanced features, such as real-time 3D visualization, interoperability between FE (Finite Element) method and MB (Multi-Body) dynamics, distributed simulation modeling and other user-defined features. To compare with traditional development method, several cases studied in railway industry are given to demonstrate how to rapidly develop engineering simulation platform using TPL.Frame, thus to prove the effectiveness of the proposed framework. Ó 2014 Elsevier Ltd. All rights reserved.
1. Introduction In the past few decades, the simulation platform has become more and more important in both research and industry and simulation models have continued to grow more complex and larger. Therefore, the continuing growth of the demand for simulation platform with better performance, wider interoperability, higher reliability, and shorter development cycles, has produced great budgetary pressure in industry and scientific community. In this situation, both researchers and developers have been trying to find a framework of simulation platform development to promote the achievement of arriving at an operational state, on time and with low costs. Engineering simulation platform development needs to use a lot of fundamental software components or modules in different disciplines and domains. Even if the development technology and theoretical basis of these components or modules are quite mature, we need to spend much time and cost in developing them. ⇑ Corresponding author. Address: No. 111, First Section, North of Second Ring Road, Chengdu, Sichuan 610031, People’s Republic of China. Tel.: +86 13548110233. E-mail address: [email protected] (Z. Tang). http://dx.doi.org/10.1016/j.advengsoft.2014.06.004 0965-9978/Ó 2014 Elsevier Ltd. All rights reserved.
Directly purchasing commercial software platform can seem a good choice for some enterprises or institutions, but it is unsuited for sector-specific ones. In one hand, in order to satisfy the demands of all kinds of enterprises and research institutes, commercial software platforms are needed to provide many feature-rich functions, but most of them are often useless to sector-specific enterprises or institutions. In the other hand, general commercial software platform cannot solve some sector-specific problems. For example, LMS Virtual.Lab [1] is an integrated suite of 3D FE and multibody simulation software and widely used in auto and aviation industry, but it cannot be used in railway industry for rail vehicle dynamic simulation due to not providing some special force elements, for example, wheel-track force, which is the most important force element for rail vehicle simulation. To solve some sector-specific issues in a professional field, researchers or engineers themselves need to develop some applications that is typically console-based and represent ‘isolated islands of automation’, namely without any supporting for data transfer in usage. These applications called home-made software are often valuable resources for enterprises or institutions and need to be integrated into simulation platform. Integrating home-made software into commercial simulation platform is difficult because they
100
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
are not thoroughly open to the users. With respect to flexibility and reusability of home-made software, solely utilizing commercial software packages for the simulation platform development also limits the capabilities of the implementation. On the contrary, self-developed platform provides the most convenient way for home-made software integration. To date, the open-source community has generated highquality simulation software codes or components, and they are available free of charge. In many cases, we can select best-of-breed codes to reuse in our system without having to reinvent the wheel. Nevertheless, It is obvious that developing and maintaining a simulation platform are a challenging task for scientific institutions or enterprises, especially for those in which there are much more researchers and engineers than software developers. Although open-source community provides us with a fund of reusable fundamental components or modules, including software tools and programming libraries, the complexity of developing and maintaining a simulation platform based on open-source resources including integrating between existing home-made codes and open-source system, codes coupling, and data exchange and interoperability cannot be ignored. In this paper, we propose a holistic framework (TPL.Frame) for engineering simulation platform development gluing open-source and home-made software, which can reduce the development cycle while still maintaining a manageable level of complexity as well as realistic cost goals. A framework is a set of classes, interfaces and patterns to solve a group of problems, which is a popular method to improve the development efficiency and reduce the development cost. In scientific and research community, researchers or developers have proposed many efficient frameworks. In the development of the finite element analysis system TopFEM, a framework is presented to take advantage of the topological data structure together with objectoriented programming concepts to handle a variety of finite element problems, in an efficient, but generic fashion [2]. Modularizing the repetitive functions, data acquisition and transmission frameworks have been established in online applications field, which is extensible and flexible [3]. A Web-based MDO (Multidisciplinary Design Optimization) framework has been developed to assist in the analysis and optimization of highly complex system [4]. A systematic review of 20 designed frameworks and software framework in general was conducted in the biomedical informatics domain in [5]. More examples can be found in [6–9]. Most of them depend on commercial software system and focus on resources and processes integration. A JAVA desktop application framework is proposed for homemade software integration in scientific community, which summarizes the typical user interaction flow in simulation field as IPO (input-process-output) mode and is implemented following a plugin-based architecture, also allows assembling new applications by the reuse of modules from past development projects [10]. The framework has made great progress in home-made software integration, but it is inadequate for highly interactive and real-time simulation platform development due to the IPO model. Furthermore, the JAVA-based framework is inconvenient to integrate Cbased or FORTRAN-based application. Nevertheless, the fact is that FORTRAN, C/C++ and Perl are widely used in scientific community and FORTRAN is the most popular programming language in the field of computational science especially in high performance computing [11]. Component-based framework is widely used for the integration of scientific simulation and visualization software due to its extensibility, reusability and tailorability [12–15]. SALOME [16], a typical distributed component-based model architecture system based on the CORBA [17], is a full-fledged open-source software platform for pre and post processing in numerical simulation. In
the field of industrial simulation, SALOME is widely used as a numerical calculation framework, such as the European nuclear reactor simulation platform (NURESIM) [18] and a simulation tool for grounding systems (TOTBEM) [19]. Salome is mainly used to construct pre and post processing module in numerical simulation system, which cannot provide all the functions required in industry simulation platform development, such as real-time visualization and solver. Moreover, researchers and developers need make adequate interface and implementation method to integrate solver into SALOME. Obviously, it is a better way that a framework can offer a simple programming model while enabling high performance on any kind of resources. Real-time visualization need to use graphics rendering engines. Since 2001, OGRE has grown to become one of the most popular open-source graphics rendering engines in open-source community and has been used in a large number of production projects [20]. IRRLICHT [21] and OSG [22] are another two popular graphics rendering engines. Nevertheless, IRRLICHT is mainly suited for game development and there are hardly any application cases in simulation field. The main advantage of OSG is its clean and intuitive scene management. However, it is not necessary to manage very complex scene in simulation application. OGRE provides easy access to OO interface designed to minimize the effort required to render 3D scenes and it is widely used as a real-time rendering engine in industrial simulation system. More important is that OGRE is most popular among various open-source graphics rendering engines. Therefore, we can obtain strong community support. For such reasons we choose OGRE as real-time rendering engine in our framework. The remainder of this paper is structured as follows. The integration architecture of TPL.Frame platform is presented in Section 2. The key concepts and implementation of home-made numerical codes process into the platform is described in Sections 3 and 4. Section 5 discusses the data exchange and interoperability strategy. Section 6 looks into the usage details and presents a case study in Chinese high-speed train pantograph–catenary simulation. Finally, Section 7 summarizes the main conclusions.
2. Integration framework and software environment TPL.Frame consists of three layers: function layer, tool layer and resource layer. The architecture of TPL.Frame is depicted in Fig. 1. The function layer is the core of the whole framework and provides interfaces to external applications. The interfaces exposed by function layer include geometry modeling, mesh generating, real-time visualizing, post processing and numerical simulation. Geometry modeling interfaces provide basic functionalities, such as creating, importing and correcting CAD models. Mesh generator interfaces are mainly used for meshing the geometric elements, mesh importing/exporting and quality controlling. Post-processing interfaces are for displaying the data in different ways in different views. Real-time visualization interfaces render the 3D scene which is created by geometry modeling and converted into OGRE mesh by converter tool, delivering real-time interactive experiences. Numerical simulation interfaces implement solution problem solving and provide data needed by post-processing or real-time visualization. In tool layer, TPL.Frame mainly utilize SALOME platform to provide pre and post processing functionalities. In order to meet the real-time requirement, OGRE is adopted to realize the 3D scene organizing and real-time rendering. The home-made applications are composed of numerical codes, configuration and rules. Configuration need to be added by user when home-made applications are integrated into the TPL.Frame. Configuration and rule facilitates the implementation of the coupling between computing codes in a
101
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
Fig. 1. TPL.Frame architecture overview.
heterogeneous distributed environment. Home-made applications is the only module need to be developed by user, and the provided features of TPL.Frame include working with mesh, fields, material database, linear and nonlinear PDE (Partial Differential Equation) or ODE (Ordinary Differential Equation) solvers, selection of simulation methods and pre-coded solvers for equations. Resource layer is responsible for storing and managing resource using file system or database. The types of resource involve GUI, parameter XML file, 3D model file, mesh file, configuration xml file and rules xml files.
Kernel 3. An overview of TPL.Frame 3.1. Key concepts of TPL.Frame Component-based architecture is flexible and simple enough to allow an intuitive and straightforward decomposition of a complex coupling code into easy-to-implement components. So it is widely used in the development of scientific computing software, especially for the large-scale engineering simulation platforms, such as multidisciplinary simulations, parallel system and distributed system. Based on component-based architecture models, we define three kinds of major elements (see Fig. 2) in TPL.Frame: Kernel, Components and Gluing components.
component
gluing component
Fig. 2. Three kinds of major elements.
Kernel provides the basic functionalities, such as logging, event reporting, memory checking, exception handling. Components, namely general components, implement real application functionalities, such as meshing, geometry modeling, visualization, simulation. Gluing components define the interaction and interoperability between components. Kernel is the infrastructure of TPL.Frame, which consists of open-source software libraries and need not to be modified by the users at any cases. Components encapsulate useful units of functionality and interact with kernel. At the heart of the TPL.Frame is the concept of gluing components, through which components interact and ‘‘glue’’ with each other. Our aim while designing gluing components is to help alleviate some of the complexity of large-scale simulation platform development and impose minimal requirements for existing home-made software so as to integrate it into TPL.Frame. As shown in Fig. 2, the gluing components need not interact with kernel directly. Gluing components will be explained in more detail in the next section.
3.2. Gluing components implementation The gluing components are the key to integrating existing home-made applications into TPL.Frame. Gluing nodes play an important role in the implementation of gluing components. Considering scalability and flexibility, we design tree kinds of gluing node: adaption gluing nodes, replacement gluing nodes and extension gluing nodes. Adaption nodes are similar to template classes and can be modified by the users directly. Replacement gluing nodes contain another gluing node and are suitable for developing new gluing nodes. Extension gluing nodes can be inherited to develop new functionalities. In order to avoid adding code to existing classes for creating different gluing nodes, abstract factory design pattern is used to create different gluing nodes using a corresponding protocol. Abstract factory design pattern offers the interface for creating a family of gluing nodes, without explicitly specifying their classes the gluing components design model is shown in Fig. 3.
102
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
Fig. 3. Gluing components design model.
By using the abstract factory model, the coupling data and parameters are exchanged at the level of gluing nodes. A gluing input interface (Iinput) represents the signal that is transmitted from the component B to component A. A gluing output interface (Ioutput) is a signal received from component A. The data and functionalities conveyed by input and output interface can be different because these data and functionalities will be processed inside gluing components. 4. Codes coupling The one of most important problems facing large-scale simulation platform is how to integrate existing codes, namely codes coupling, with minimal codes modification. To solve this problem, we provide a library called TPL.Gluing.API contained in TPL.Frame, which is dedicated to establish connection and cooperation among all codes or applications, exposes their interfaces to other modules. At the same time, TPL.Gluing.API also provides C++ or FORTRAN wrappers for connection and integration between SALOME and OGRE. 4.1. Codes coupling between multibody dynamics and finite element method Many complex engineering systems, for example, pantograph– catenary system in high-speed train, require using different-nature computational codes for their sub-systems simulation. How to couple these different disciplines computational codes is one of the main issues to be solved in the development of large-scale engineering simulation platform. MBD (Multibody Dynamics) subsystems and FEM (Finite Element Method) subsystems are two most typical sub-systems in engineering simulation, which often need corporate to simulate the dynamics behavior of mechanical system. A typical multibody model is defined as a collection of rigid or flexible bodies that have their relative motion constrained by kinematic joints and is acted upon by external forces. In general, DAE (differential algebraic equations) or ODE (ordinary differential equation) are used for simulating the dynamic behavior and the equation of motion using DAE like this:
"
M
UTq
# € q
Uq
O
k
¼
g
c
ð1Þ
€ is the accelwhere M is the mass matrix, Uq is the Jacobian matrix, q eration vector, k denotes the vector of the Lagrange multipliers, g is force vectors applying to the system body. c is a vector with the right-hand side of the constraint acceleration equations. Using the finite element method to represent the structure, the equilibrium equations for the structural system are:
€ þ C X_ þ KX ¼ F MX
ð2Þ
where M, C and K are the finite element global mass, damping and stiffness matrices, respectively, x is the vector with the nodal displacements. F is a vector with the forces applied to the system. Obviously, Eq. (1) needs depend on CAD model and corresponding parameter, but Eq. (2) needs to be solved using mesh model, which are entirely different data structure and need in turn use their respective time integration algorithms. For coupling FE and MB codes, J. Ambrósio et al. use memory mapped file to communicate between MB and FE software, which enables simultaneous access of the type of application code or environment [23]. There are many obvious drawbacks on using memory mapped file, including the requirement of a fixed file size and break of program structure. Moreover, the more urgent shortage is that memory mapped file requires all applications or programs to be deployed on the same computer, not to support distributed simulation. We propose gluing component-based strategy to achieve MB and FE codes coupling. The strategy not only supports distributed simulation but also allows any choices for integrators. We use gluing DSC components (dynamic software component) to realize the strategy. Gluing DSC is an extension of SALOME object concept, which conforms to the gluing component design model and adds utility and supply ports to SALOME object. A port is a CORBA interface and each port has its own properties. Supply ports implement the interface, while utility ports are connected to supply ports for using the interface. The strategy is outlined in Fig. 4. First, the existing MB and FE codes are wrapped into components using TPL.Frame.Wrapper API, consisting of a user-defined C++ or FORTRAN interface file and a XML script file. Then, the wrapped MB and FE components are coupled by two gluing components. Finally, the coupled MB and FE components are translated into DSC components (TPL.Frame.FE and TPL.Frame.MB) using IDL interfaces file, which are made independently. So the distributed deployment can be conveniently applied to both codes.
103
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
DSC Component C++ or Fortran Interface Files
MB Component
TPL.Frame.FE DSC
Supply Port IDL I mplemention
IDL Interface
Utility Port MB Gluing Component
Gluing Component TPL.Frame.Wrapper FE
Utility Port
Supply Port
Supply Port
Utility Port
DSC Component TPL.Frame.FE DSC
Codes FE Component
IDL Interface
Supply Port
IDL I mplemention
XML Script Utility Port Dynamic Software Component Model
Fig. 4. Coupling flow between FE and MB in TPL.Frame.
4.2. Coupling between simulation models and solver
5. Data exchange and interoperability
After the home-made codes are wrapped into solver components, we need to integrate them into TPL.Frame framework as a whole. However, the home-made codes which are possible to use internal parallel techniques are generally written by different program languages, such as C++, FORTRAN and C, while simulation models are described by differential, algebraic and discrete equations with time event, state event and step event. How to integrate solver components into TPL.Frame is another problem. Similarly, we use gluing components-based strategy to solve this problem as shown in Fig. 5. First, solver components and gluing components are wrapped again into solver engine, which is actually a SALOME module. Then, the solver engine can be integrated into SALOME platform using provided integration method by SALOME, which can be found in [24]. Since solver components are already integrated into SALOME module, the simulation model created through SALOME GUI (such as Geometry GUI, Mesh GUI, and user-defined GUI) can tightly be linked with solver components. The detail of gluing components used for the integration between simulation models and solver is shown in the right of Fig. 5. Two adaption gluing nodes are used for creating the gluing components. One is for input and the other is for output. The advantage of using two adaption gluing nodes is that users can define data flow or processing flow on demand at any time.
The strategy of data exchange and interoperability is one of the most important aspects for the large-scale simulation platform development. TPL.Frame also needs tight data exchange and interoperability strategy between modules, especially between CAD and CAE modules. Besides data exchange and interoperability between internal modules, it is also necessary to provide data exchange and interoperability strategy with external commercial software because users often need to reuse existing models created by commercial software or use some advanced features provided by commercial software. However, for the reason of competition among commercial software vendors, CAD data exchange between heterogeneous applications is not really supported. Data models are also still exchanged by native file formats. Efforts by standardization organization (STEP, IGES) and software industry, which now delivered Web-based platforms such as CORBA and Java, can also only superficially address the interoperability problem [25,26]. Because the diversity of CAE data and the structure of CAE data are more complex than ones of CAD data, less attention has been paid to systematic research on the exchange and interoperability of CAE data including field data and time series data [27]. To offer the opportunity to seamless communication of CFD (Computational Fluid Dynamics) analysis data between sites, applications and system architectures, NASA and Boeing develop the CGNS, CFD General Notation System [28] which is a general,
Geometry GUI
Mesh GUI
Solver GUI
Gluing Input
Solver Component B
Services
Communication Layer (CORBA) Gluing Nodes
Solver Components Geometry Components
Mesh Components
Gluing Component
Gluing Components Solver Engine
Services Fig. 5. Solver integration into TPL.Frame.
Gluing Output
Solver Component A
104
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
portable, and extensible standard for the storage and retrieval of computational fluid dynamics (CFD) analysis data. Song et al. present a CAE data exchange method for the effective sharing of geometric and analyzing data [29,30]. In TPL.Frame, we combine CGNS and data exchange method presented by Song et al. into SALOME platform. HDF file structure [31] and MED data model [32] are combined to solve storing problem of heterogeneous data source. The data exchange and interoperability processing flow are outlined in Fig. 6. CAD models data exchange with commercial software, such as CATIA, PRO/E, UG, SOLIDWORKS, SOLIDEDGE, mainly utilizes neutral files: IGES and STEP. A plug-in of TPL.Frame, PYTHON script, is used for CAE data exchange with external commercial software, which can be extended and modified by other user on demand. TPL.Frame provides data processing API package, including File Data Server components and Metadata Server components to translate these data for matching the data model template of TPL.Frame. Then, these data can be used by TPL.Frame as internal data. TPL.Frame uses MED to store and recover data associated with numerical meshes and fields. As shown in Fig. 6, a three-level interfaces of MED-FILE, MED-memory and MED-CORBA provide the Interoperability among TPL.Frame modules. With the help of SALOME platform, TPL.Frame provides the functionality of exchange data between codes or solvers in
Commercial CAD Software CATIA
memory. CORBA is used to allow communication of modules on remote servers. TPL.Frame allows users to read mesh from MED files into memory (using MED-memory API), to process mesh coordinates and connectivity, work with groups of mesh (which can be defined in SALOME editor) and seamlessly pass this information to home-made solvers and OGRE engine, which provides some core fields meant to be used in all simulations and visualization modules. Custom fields can be defined as well and the field data structure is based on MED field data type. We provide overloaded access operators for easy access of the items in the framework, as well as support for retrieving data from home-made applications to OGRE and SALOME for real-time visualization and calculation.
6. Case study: the application of TPL.Frame in china railway industry This section will demonstrate how to use TPL.Frame to rapidly develop engineering simulation platform for china railway industry and draw a comparison with traditional development mode. There are two infrastructure mechanical interfaces in railways, one is the wheel/rail contact, and the other is pantograph–catenary interface. Electric power can be transferred from an overhead catenary to the high-speed train via a pantograph that is mounted
Commercial Data Model Neutral Files
Commercial CAE Software ANSYS
CAD Data
CAE Data
PRO/E
ABAQUS
API Call
TPL.Frame Data Model Template UG
SOLIDWORKS
MSC.Marc
Python Script
FLUENT
Reference TPL.Frame Data Processing API Package
SOLIDEDGE
Salome Container
...
LS-DYNA
Metadata Server Components
Salome Container
File Data Server Components
...
Dynamics Component (DSC)
DSC
SALOME/COERBA
C,C++FORTRAN Data Access API
Memory Mapping Memory data MED CORBA MED User Files
TPL.PC Data Engine HDF File Wrapper
MED Server Memory
Salome Container DLL
Combination
Salome Components
Files Mapping
MED Files User Interface HDF Files
HDF File Database
Fig. 6. Data exchange and interoperability processing flow in TPL.Frame.
105
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
on its roof. The dynamic behavior of pantograph–catenary system not only limits the top velocity of high-speed trains but also affects the functions of some mechanical equipment on the train. Therefore, the pantograph–catenary interface plays a vital role in the high-speed train. A large number of works are dedicated to the study of the pantograph–catenary system dynamic behavior by different simulation methods and software tools. SAMCEF, a commercial finite element analysis software, is used to analyze the dynamic catenary–pantograph interaction [33,34]. The finite element software ANSYS is the most popular choice of software for the catenary simulation and modeling [23,35]. Besides ANSYS, SIMPACK commercial multibody code is often also used to simulate the pantograph, i.e., PROSA [36]. Developing simulation software generally need take a long time to do. The code CATMOS developed in the early 1990s is applied to the vibration analysis of pantograph– catenary system [23]. EUROPACAS including EUROPACAS-FE and EUROPACAS-MB allows simulating any type of pantographs and catenaries in three dimensions, and taking into account all kinds of effects such as the action of wind, temperature, switches, road bridges [37]. It is developed by EUROPAC project, which took place from January 2005 to December 2007. In summary, pantograph– catenary system simulation software can be divided into two categories. One is co-simulation or re-development based on commercial software, such as CATMOS, FAMOS, PROSA and DINACAT/ WINCAT. The other is directly using general commercial multibody dynamics software and finite element analysis software, such as SIMPACK, ANSYS, SAMCEF and ABAQUS. But because there are not professional pantograph–catenary solvers in the general commercial software packages, the ease of use is not as good as they are used for other simulation projects. In addition, the process is also tedious when commercial software is used to simulate the pantograph–catenary system. Obviously, the data exchange and interoperability are not really supported between commercial multibody dynamics software and finite analysis software. Therefore, it is very necessary to develop the simulation software for pantograph/catenary system independent of commercial software. To overcome these disadvantages mentioned above, we develop a holistic pantograph–catenary simulation platform named TPL.PC, which is used for pantograph–catenary system simulating, modeling, designing and analyzing. With the help of TPL.Frame, some advanced functions, such as geometry modeling, meshing, solver
and 3D visualization for continuous simulation data, are easily realized in TPL.PC. It also provides interoperability between CAD modeling and CAE simulating, which can achieve data exchange between multibody dynamics and finite analysis. More details about TPL.PC will be described in the next sections. 6.1. FE and MB integration In order to simulate the dynamic behavior of pantograph– catenary system, the Finite Element (FE) method is used to support the modeling of the catenary, and multibody (MB) dynamics method is applied to support the pantograph modeling. Obviously, we need co-simulation of multibody and finite elements. However, the general commercial software cannot meet the special requirement in the same system. With the goal of gluing the multibody and finite elements method, based on the TPL.Frame, TPL.PC gives an example on how to exchange simulation information between FE and MB. The analysis of the pantograph–catenary interaction generally needs to be done by two independent codes. The pantograph code uses a MB formulation, while the catenary code uses FE equation in nature. Each of the two codes contains an internal loop to handle iterations. So the interceding communications need to be performed after each iteration step. Moreover, both codes, which work as stand-alone codes, need to be coupled to simulate the dynamic behavior of pantograph/catenary system. Correspondingly, In TPL.PC, the simulation is done by two independent programs. One is the pantograph program, TPL.PC.MB, which uses multibody dynamics method. The other is catenary program, TPL.PC.FE, that is a finite element program. As shown in Fig. 7, the simulation calculation cycle is divided into two steps. In the first step, TPL.PC.FE is running while the TPL.PC.MB is waiting for the calculation result. In the second step, TPL.MB is running while TPL.FE is waiting for the result generated by TPL.MB. The simulation flow is well supported by TPL.Frame (see Fig. 4.). Moreover, as to pantograph–catenary system parallel simulation computation, two steps need to be implemented. First, a preprocessing application splits the mesh and prepares data model for TPL.PC solver engine. Then, the TPL.PC.FE and TPL.PC.MB are launched in the same memory space for loop computation. For each cycle step, TPL.PC.FE calculates the data for TPL.PC.MB then sends them with corresponding messages, subsequently; the
Notification
Notification
FEM to MB
MB to FEM
TPL.PC.MB
TPL.PC.FE
TPL.PC.MB
TPL.PC.FE
Information Exchange
Information Exchange
Force,Postion
Velocity,Postion
Step 2
Step 1 Dataflow
Processing
Datastream Waiting
Fig. 7. Simulation flow between FE and MB.
106
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
(a) Pantograph model imported from commercial software
(b) 3D catenary model automatically generated by TPL.PC Fig. 8. 3D geometry modeling case with the help of TPL.PC platform.
(a) 1D catenarymesh
(b) 3D pantograph part mesh Fig. 9. Meshing on the TPL.PC.
TPL.PC.MB computes its step and sends its data back to TPL.PC.FE. The computation process is also wrapped as a gluing component. 6.2. 3D geometric modeling Geometric modeling is one of the most fundamental functionalities in engineering simulation platform. Commercial CAD software provides plenty of 3D modeling techniques and methods such as parametric modeling and variable modeling, but TPL.PC needs a built-in 3D modeling technique for pantograph–catenary automatic modeling. SALOME uses the Open CASCADE [38] as built-in 3D modeling modules, TPL.PC can utilize the basic functions of Open CASCADE directly based on TPL.Frame. The results of pantograph imported from external commercial software and the
automatic generating catenary model by TPL.PC are shown in Fig. 8. The existing model data created by external application can be reused on the TPL.PC via importing IGES or STEP neutral files, which can save time and cost for engineers. 6.3. Mesh Meshing is the most important step for finite element analysis. NETGEN [39], an automatic 3D tetrahedral mesh generator, which is integrated into the SALOME platform as an external plug-in, is used to generate 3D pantograph mesh and 1D catenary mesh. NGSolve is integrated into TPL.PC for finite element solving. The mesh results are shown in Fig. 9.
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
107
Fig. 10. Mesh and geometry model are displayed in the same view.
In addition, to satisfy the special demand of catenary simulation, the nodes of meshing can be grouped automatically based on the parameters like the number of span and the distance of spans which reduces verbose user operations. To observe the position of mesh parts in the assembly, TPL.PC can display the mesh and geometry model at the same time, which is shown in Fig. 10. 6.4. Post processing It is crucial for end users of TPL.PC to find efficient and attractive ways to visualize the result files and data. The post-processing capabilities of TPL.PC include rich features, such as 2D chart and
3D visualizations, animations of the results in both 2D and 3D, and experiment control visualization. Upon the successful execution of a TPL.PC solver, a number of computing files and data will be created. Fig. 11 partly shows the post processing function of TPL.PC used for pantograph–catenary simulation. Real-time 3D visualization and stereoscopic display can add visual interest to the users and provide fully immersive interactive environment, TPL.PC uses gluing component to wrapper OGRE engine, which can conveniently realize the real-time visualization and stereoscopic display (see Fig. 12). In addition, parallel visualization of large-scale dataset is supported by TPL.PC based on TPL.Frame.
(a) Animation of mass-spring-damper model
(b) Modal shape of contact line
(c) 2D chart and table of contact force
(d) Simulation stress distribution
Fig. 11. Post processing functions of TPL.PC.
108
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
Fig. 12. Real-time 3D visualization based on OGRE engine.
Table 1 Comparison with traditional development mode. Comparison item
Using TPL.Frame
Independent of any framework
Directly using SALOME
Development cycle Meshing Geometric modeling Real-time 3D visualization
2 months Full Full Supporting
About 20 months Just supporting 1D Just supporting 2D Not supporting
3 months Full Full Not supporting
6.5. Comparison with traditional development mode As mentioned before, it will take a long time to develop largescale engineering simulation software. For example, EUROPAC project had taken 2 years to develop EUROPACAS. In our lab, there are several pantograph–catenary simulation systems developed by different groups with different development mode. In our experiment, using TPL.Frame not only dramatically reduces the development cycle but also provides more rich features. The detailed comparison between TPL.Frame-based mode and traditional development mode is shown in Table 1. By comparison, we find that the development cycle only need 2 months by using TPL.Frame, while directly using SALOME takes about 3 months. Relative to SALOME, TPL.Frame supports real-time 3D visualization because we integrated OGRE into the frame. From the table, it is obvious that developing engineering simulation software independent of any framework will take a long time (20 months) only achieving some basic functions.
7. Conclusions The goal of developing TPL.Frame is to provide a holistic framework including pre-processing, solver and post-processing for engineering simulation platform development based on the open-source and home-made resources. Open-source software offers key advantages for the development of industry simulation platform, especially for sector-specific industry filed. Relative to commercial software, open-source software also has the benefit that engineers can inspect the source code to maintain and make
modifications when necessary. With the help of the TPL.Frame, users can take full advantage of open-source software and do not have to spend much time on the demanding design, development and maintenance of the pre-processor, post-processor, real-time visualization and simulation solver library. Thus, they can concentrate on developing the simulation model and solving algorithm. We put forward the novel gluing components concept for integrating open-source and home-made resources effectively and conveniently. Using gluing components, the components of TPL.Frame can be dynamic replaced, adapted and extended, which provides good extendibility and reusability for developers. Gluing nodes, which is a connector that makes a generic collaboration adapted to a specific application and defines the differences between the generic and the specific, play the vital role in gluing component. In TPL.Frame, we give a solution to solve some important problems in terms of the development of engineering simulation platform. Firstly, integrating home-made codes is a tough task since the target applications, such as TPL.PC.FE and TPL.PC.MB, may prove very different. We present the integration method based on a flexible programming model, which depends on the component paradigm to address this challenge. Secondly, the solver integration is a very important task for all simulation platform development. Based on the component-based application framework, we wrap solver codes as a solver engine that uses parallel containers and parallel DSC component. It is a quick and pervasive integration method and has many advantages such as real-time visualization and interaction. Thirdly, data exchange and interoperability are discussed in detail and process flow chart is presented based on HDF and MED. These methods presented in this paper give an example on how to solve these main problems in term of developing a large-scale engineering simulation platform. In the end, the case study is given to not only verify the effectiveness of the platform framework but also demonstrate the usages of the framework. In our experience, using TPL.Frame framework for large-scale engineering simulation platform development can dramatically save time and cost. Acknowledgement This work was partially funded by the National Natural Science Foundation of China (51075341).
Z. Tang et al. / Advances in Engineering Software 76 (2014) 99–109
References [1] LMS.Virtual.Lab.
[19]
[20] [21] [22] [23]
[24] [25] [26] [27] [28] [29] [30] [31] [32] [33]
[34]
[35] [36]
[37]
[38] [39]
109
scale and multi-physics calculations, sensitivity and uncertainty analysis. Nucl Eng Des 2011;241:3416–26. Colominas I, Parıs J, Fernández D, Navarrina F, Casteleiro M. A numerical simulation tool for multilayer grounding analysis integrated in an open-source CAD interface. Int J Electr Power Energy Syst 2013;45:353–61. OGRE.