Automated Finite Element Analysis in a Knowledge Based...

Automated Finite Element Analysis in a Knowledge Based Engineering Environment

M. Nawijn*, M.J.L. van Tooren† and J.P.T.J. Berends‡

Delft University of Technology, Faculty of Aerospace Engineering, Kluyverweg 1, 2629 HS Delft, The Netherlands, www.dar.lr.tudelft.nl

P.Arendsen§

National Aerospace Laboratory NLR, Voorsterweg 31, 8316 PR Marknesse (The Netherlands), www.nlr.nl

Efficient use of finite element based analysis in a knowledge based automated design environment requires the solution of two problems. First, it must be ensured that for every instantiation of a parametric product model, the geometry is segmented (discretized) in such a way that proper element connectivity can be assured. Second, since changes in product variables (dimensional changes) and changes in product parameters (configuration changes) will lead to changes in the mesh topology, the product attributes (e.g. material and supports) must be linked to the product geometry and not to element meshing. This paper shows that the segmentation process normally carried out by FEM experts manually, can be implemented with Knowledge Based Engineering (KBE). As a result it is guaranteed that the geometry associated to any instantiation of the product model is properly segmented and the connectivity issue is handled in a robust way. This paper shows that the dependency of the FEM model definition on the underlying mesh can be solved by adding information and/or knowledge to the geometric data from the KBE tool. In a traditional CAD based design environment, the knowledge generated in the geometric design stage is inaccessible to the FEM pre-processing process due to the fact that data transfer formats are incapable of capturing this knowledge. It is shown that in a KBE environment information/knowledge stored in the product model can be extracted and made accessible. Finally, it is shown by an elaborate example of a rudder design case that the combination of properly segmented geometry and the knowledge extracted from the product model together with a newly developed, Python based Knowledge Based Engineering Finite Element Analysis tool allows for the flexible incorporation of automated FEM analysis in a multi-disciplinary design environment.

I. Introduction Numerical analysis is widely accepted as a method to verify the performance of a product in a digital

environment. In particular the finite element method (FEM) is used routinely throughout many different parts of the (aircraft) industry for structural analysis. However, the current approach to building FEM models focuses on the individual product instead of on commonality in preparation processes, which is the key to automation of FEM analysis. This focus on products and the intrinsic lack of commonality between products leads to a highly labour intensive, manually based process to handle variation in product variables (e.g dimensional changes) and parameters (changes in configuration). * PhD student, Faculty of Aerospace Engineering, [email protected], AIAA Member † Professor, Faculty of Aerospace Engineering, [email protected], AIAA MDO TC Member ‡ Researcher, Faculty of Aerospace Engineering, [email protected], AIAA Member § Researcher, [email protected]

American Institute of Aeronautics and Astronautics

1

http://www.dar.lr.tudelft.nl/

Currently, there are two difficulties in the automation of a FEM model preparation. The first is the connectivity

requirement. The mathematics behind FEM requires that elements are connected at their nodes only**1. In practice, proper connectivity is often enforced manually by a FEM expert for every product. Therefore changes in the variables (dimensional changes) and, even more, changes in parameters (topological or conceptual changes) of the model are problematic and in essence require the FEM specialist to rebuild the model from scratch. As an example, consider the set of surfaces shown in Fig. 1, schematically representing a wing box consisting of an upper skin segment, a spar segment and a rib segment. As indicated, several connectivity errors occur, which make the set of surfaces unsuitable for automatic meshing.

A FEM specialist will resolve the errors such that a result similar to the one shown in Fig. 1(b) is obtained. By

using Knowledge Based Engineering (KBE) it is possible to capture the human approach to this segmentation process in rules thus enabling elimination human involvement in this part of the FEM pre-processing process.

The second difficulty in building and updating a FEM model is that in the definition of the finite element model,

many features of the model have direct references to element and node numbers. As a result, each time the number of elements and nodes change, all features with a reference to an element or node number have to be redefined. This limits the capability for (re-)analysis with different mesh densities or slight differences in dimensions (variable changes) and the analysis of conceptual or topological changes (parametric variations). Solving these two issues is a necessary requirement for the automation of the generation of FEM models.

After having presented solutions to these two issues, an example will be discussed in which these solutions are

used to implement an automatic design and analysis loop for an aircraft rudder design.

(a) (b)

Figure 1, Example of the correction (b) of the errors in geometric connectivity (a)

II. The connectivity issue The solution proposed and implemented for the connectivity issue, relies on the application of KBE. KBE is an

engineering technology based on the combination of object oriented programming, artificial intelligence (rule based reasoning) and a parametric CAD engine. Currently several KBE platforms are available to capture and reuse product and process knowledge, in order to automate repetitive engineering tasks2. A product model represents the core of every KBE application. It is an object oriented representation of the product family for which the application has been created. In essence, a product model can contain all the knowledge on the physical representation as well as the processes used to design, analyze and manufacture it.

** It is possible to connect incompatible meshes by the Lagrange multiplier method. Some commercial finite element software packages have this approach implemented. However, this is not common practice for ordinary finite element analysis and therefore, this option is not considered as a generally accepted approach.


2

In contrast to the CAD based approach, KBE supports selective extraction of product geometry and aspects through the use of user defined rule bases. This allows the generation of discipline specific views on the product. These views can be used as input for the different multi-disciplinary expertise domains. This principle is used in the so-called Design and Engineering Engine, represented in Fig.2, to create a Multi-Model Generator.

The multi-model-generator (MMG) uses a (parametric) product model build up from High-Level Primitives (HLPs). These HLPs are object oriented building blocks like wing trunks, fuselage trunks, connection elements and engine parts representing basic aircraft parts, Fig. 3. For a particular instantiation of the product model, different views (supplied in report files) are generated. These views are the inputs for each of the discipline tools, e.g. FEM and CFD, that are involved in the design analysis and optimization process. For the FEM analysis discipline at least a geometric view is essential. For this geometric view a segmentation routine is required. This segmentation process is captured in rules.

Figure 2, The multi-model-generator (MMG) that is part of a design and engineering enviroment (DEE) embeds the product model. Different views on this model can be extracted in the form of reports.


3

Figure 3, High-level primitives are object oriented building blocks that are used in the design of aircraft concepts. They represent generic structural components like a wing-trunk, fuselage trunk, connection elements and an engine part.

Fig. 4(a) shows an example of a vertical tail generated by the instantiation of a composition of wing-trunk HLPs.

The FEM mesh in Fig. 4(b) is automatically generated and all elements are properly connected.

For automated FEM analysis, a geometric view is not sufficient and additional information addressing material

properties, thicknesses and functional information like hinge positions needs to be added to the view. This will be discussed in the next section.

(a) (b)

Figure 4, Automatically segmented geometry (a) and finite element mesh (b)of a vertical tail plane.


4

III. The issue of element independent product attributes To be able to set-up a FE analysis more product information is required than just geometry. Normally this information is supplied to the FE-tool by assigning properties to elements. In an automated environment the element properties must be derived from product information supplied by the KBE-tool. The main issue is to re-establish the relation that was available in the KBE product model between geometry and attributes in the FE-tool and transform data back into information.

A. Data, information and knowledge The distinction between data, information and knowledge is important because it helps to appreciate a problem

often found in engineering environments where information or knowledge in one process is reduced to data before being transferred to the next process. The fact that data and not information or knowledge is often transferred between processes is related to the available data formats. Often these formats are unsuitable for transferring context and structure and therefore are not able to transfer information and knowledge. For example, the initial graphics exchange specification (IGES) is very well suited for the transfer of geometrical data, but it is not suited to transfer the context in which this data was generated (information). As a result often a drop in the knowledge accessibility level is observed when transferring from one process to another. This is schematically represented in Fig. 5.

During the geometry definition process, the knowledge of the product is growing with time. However, the data

formats used to transfer from the geometric design process to the FEM pre-processing process are incapable of capturing anything else but the physical geometric description, therefore reducing the knowledge accessibility level to a much lower level, often the plain data level.

The inability of the data transfer formats to preserve product information and knowledge is undermining the

advantages of KBE for product modelling. If a better transfer protocol would be available, ideally, the knowledge gained in one process could be available in any of the other follow-up processes leading to a situation illustrated in

Figure 5, Drop in knowledge accessibility level due to the incapability of the data formats ,used to transfer from one process to another, to capture information and knowledge.

Many different definitions and interpretations exist for data, information and knowledge. To avoid any confusion, these terms as used in this paper are defined below3. Data is understood as discrete, atomistic, tiny packets that have no inherent structure or necessary relationship between them. In contrast to data, information is data that is structured and put into context, so that it is transferable, but the immediate value of information depends on the potential of the user to sort, interpret and integrate it with their own experience. Knowledge goes one step further and implies the combination of information with the user's own experiences to create a capacity for action


5

Fig. 6. All information available at the end of the geometry definition process is transferred to the FEM pre-processing process. This further enables automation of the FEM analysis process, since no human interaction is necessary to rebuild information lost in the transfer. Implementation of this concept requires solving the issue of element based specification of product attributes in the FE context. This will be discussed in the next section.

Figure 6, Preservation of knowledge by improved transfer protocols.

B. Addressing the issue of element independent product attributes Every assignment of FEM properties like element properties, loads and boundary conditions, based on the

product attributes must be done indirectly through the relation with the geometric entity where the element or node belongs to. This method has been developed in a KBE environment and is the concept denominated as FEM-tables. The FEM-table is part of the view that is generated by the MMG (see section II) used by the FEM-tool.

A FEM-table can store all the above mentioned information from the KBE product tree required by the FEM-

tool. Association with the geometry is the key factor that allows transferring information from the product model to the FEM-modelling process. The solution implemented is to rebuild the association using the vertex coordinates of the geometric entities (Fig. 7). By using this vertex co-ordinates, which are unique for each geometric entity in both the KBE and FEA world, a 1-to-1 relation can be made. Via this unique association, the properties stored in the FEM-tables can be channelled to the FEM-tool.

In previous projects4,5, FEM-tables were stored as fixed format ASCII files. A better solution is to use the

extensible mark-up language (XML). The two main benefits for using XML are that XML is a standard and a wide variety of parsers for easy implementation in programming languages is available.

The process responsible for the re-association of geometry and attributes is called PYCOCO (Fig. 7) and will be

discussed further in the next section.


6

Figure 7, Automation of the finite element analysis process by using PYCOCO as the key to create an approach to automated FEM analysis.

Knowledge Based Finite Element Analysis

KBE MMG

Element Surface

PYCOCO Interface

FEA Tool

Pr

Pr

Att

Att

IV. Automated FEM analysis The approach to the automation of the finite element model preparation process follows the paradigm of

Knowledge Based Engineering. In this case, however, the combination does not combine the object oriented programming and rule base with a parametric CAD engine but with a combination of an FE pre-processor and solver. We will call this from now on Knowledge Based Finite Element Analysis (KBFEA). Again the structure in process and product are captured in the object-oriented environment. The rules for the pre-processing are captured using the program language instructions and the execution of FE-commands is done by the FE-tool. The FE-tool functions as a parametric model builder and solver, similar to the parametric CAD engine.

The main functions of the tool by which automated FEM analysis is achieved are listed below. • Create and Import geometry function • Create Finite Element Mesh topology function • Application of Loads and Boundary Conditions function • Application of Materials and Properties to the elements function • Configure FE analysis function

These functions have been implemented in a tool called PYCOCO, Fig.7, with main features:

• A client-server model, where the FE-tool is the server and the PYCOCO process the client. The client-

server model is implemented through the use of a pseudo-socket, which resembles an operating system socket, but uses only one-directional communication from the client to the server. The pseudo-socket allows the client and server to be on different physical machines connected by a (inter)network.

• Python as programming language. A library handles the translation between the Python commands and the FE-specific command language, in this case PCL for Patran.


7

• XML encoded data, information and knowledge files. • Synchronisation of the FE-tool model database with an external XML database. To allow the Python

process to use information generated during the FE process. • A set of generic algorithms to efficiently query the information in the XML database. • Full access to all Python features in the standard distribution.

C. Implementation details The four main components of PYCOCO are the PCL generator, the pseudo-socket, the core library and the XML

database. A typical PYCOCO session has two active operating system processes. The first is the Patran process, that is waiting for commands and the second is the Python process (either interactively or in batch) that controls Patran execution. The core library provides functions and class methods that generate PCL code on the fly. This PCL code is compiled into a library and loaded into the active Patran session. The pseudo-socket is than used to instruct Patran to execute the function just compiled into the library.

PCL code generation. Each PCL function prototype has a corresponding string template associated to it. Each parameter in the function prototype is parameterised, with default values where appropriate. After compilation, the templates become regular Python objects with some special methods and attributes. The constructor of these objects takes as one of its arguments a searchList that is used to lookup the function template parameters.

The template parameters necessary for the construction are obtained from this searchList and substituted into the template. The resulting PCL fragment is embedded in a generic function call and send to the PCL compiler for compilation. The PCL compiler than compiles the PCL code into a library. At this stage, the Python process instructs Patran to reload this library and execute the newly added function.

Every string template has a one to one correspondence with a PCL function. This makes it easy for the user to

add more string templates to the library (currently about 15 percent of the documented PCL calls have a corresponding string template).

The pseudo-socket.

The pseudo-socket is used for the communication between the Python and the Patran process. In essence it is an ordinary file opened simultaneously by two processes. Currently a few very simple commands are implemented that control the Patran process. The most important one is the update command. The update command controls when Patran reloads the compiled PCL code into memory and executes the most recent function. The Patran process can be stopped manually by calling the quit method on the current session (which is a class object). The Patran process is automatically stopped when the destructor of the current session is invoked.

The core library. The core library is a higher level library that uses the Python template objects that generate PCL code. The purpose of the library is providing the user with a flexible set of tools for the automatic generation of FEM models. In essence, the core library is the only thing that users are aware of in programming. The ability to connect to and manipulate Patran is accomplished just by loading a single Python module.

A powerful component of the core library are the generic algorithms6. Generic algorithms are algorithms that can

be applied to a variety of data structures as long as these data structure satisfy some requirements. An example of a generic algorithm is find_if. This algorithm can be used to find entities that fulfil a specific requirement. The prototype (in Python) of the algorithm is

find_if(iterator, function_object) The iterator represents an iterable structure in the sense that you can start at the beginning and by incrementally

proceeding to the next element in the structure, you finally reach the end. The function object parameter is used to specify which condition should be passed by all the elements in the iterable structure. By definition a function object is a programming construct that can be called using normal function calling syntax and that returns either true or false. In the case of Python the two most obvious candidates for function objects are normal functions and classes


8

that implement the special __call__ class method. An example of the definition of a function object and its use are presented below:

class surface_aspect_ratio(object): def __init__(self, threshold): self.threshold = threshold def __call__(self, c): if c.tag == 'surface' and c.aspect_ratio < threshold: return True else: return False # Configure the proper surface aspect ration sar = surface_aspect_ratio(7.0) # Loop over all entries in the XML database and find all surfaces # that have a aspect ratio smaller than the threshold find_if( db.getiterator(), sar) At the moment, three generic algorithms are implemented, find_if, find and, for_each. In the future, more

will be added.

XML database During the creation of the FEM model, it is possible to extract some of the contents of the Patran database to an XML database. This is useful for two reasons. First, often during the construction of the FEM model information regarding the model is needed for subsequent steps. For example, if distributed loads need to be applied to the edges of a stiffened panel, it is necessary to know where the edges are located and which curves or surface edges in the model correspond to those edges. The location of the edges should be part of the structural view generated from a particular instantiation of the product model. Based on this information, the current database can be searched for geometric entities that correspond to those edges. In PYCOCO immediately after importing the geometry, all geometric information available is extracted from the Patran database and stored in an XML database. With the generic algorithms in the core library, it is simple to search for the proper geometric entities. The second reason for generating an XML database is information accessibility. In a multi-disciplinary design environment it is useful and often necessary to be able to use data generated by other disciplines. The problem arises when those disciplines need information from source that needs licensed software to access. If the information generated during a process is stored as much as possible in XML, anyone interested in this information can access it.

V. Example In this section the automatic generation of a FEM model of an elevator of a horizontal tail plane is described.

From the product model in the KBE tool, different elevator configurations can be generated. Fig. 8 shows two examples. One of the main difficulties associated with the automatic generation of the FEM model in this example is the coupling of the elevator at the proper location along the hinge-line of the horizontal tail plane.

Figure 8, Examples of elevator configurations


9

Fig. 9 schematically shows how the elevator is connected to a point located on the hinge line of the horizontal tail plane. The problem is to find the connection points on the front spar and the location of the point on the hinge line for every possible configuration. The information necessary to solve this problem is stored in the product model and is delivered in the form of a FEM-table to the FEM pre-processor environment.

How the proper connection points are found is explained in Fig. 10. The FEM-table holds information on the

coordinates of the hinge-point and the connection points. The PYCOCO environment reads both XML files and associates each of the points in the hinge definition to a corresponding geometrical point in the FEM model. If all the points can be associated to a geometrical point, enough information is available for creating the connection in the FEM model.

Connection point

Hinge line

Figure 9, The connection between the elevator and the horizontal tail plane is defined by 4 connection points and the point on the hinge-line

<hinge id="1"><point type="hinge-point"> <vertex>60242.746 367.77258 3000.</vertex> </point> <point type="connection-point"> <vertex>58975. 0. 3000.</vertex> </point> <point type=" connection-point "> <vertex>58975. 0. 2900.</vertex></point> <point type=" connection-point "> <vertex>60242.746 367.77258 2900.</vertex> </point> <point type=" connection-point "> <vertex>60242.746 367.77258 2900.</vertex> </point> </hinge>

PYCOCO

FEM table information <points group="front-spar"><point id="1"> <vertex>60242.746 122.0 2000.</vertex> </point> <point id="2"> <vertex>58975. 0. 3000.</vertex> </point> <point id="3"> <vertex>58975. 0. 2400.</vertex> </point> …..

XML FEM database

Figure 10, The PYCOCO environment finds the proper geometrical points by comparing the vertex coordinates


10

Fig. 11 shows the result of the automatic generation of hing connections for one configuration of an elevator.

Hinge connections

The loadscomb Fig. mesh

Figure 11 Fully defined finite element model including the automatically generated hingeconnections

procedure followed for the automatic generation of the hinge connections is similar for properties like applying . Each time, the information is read from the XML FEM-table and the corresponding geometric entities are ined with entries in the XML FEM database.

12 demonstrates the independency of the FEM model definition from the underlying mesh. The two different es were generated by only changing the global element size and the element topology label.

(a) Coarse mesh,

triangular elements

(b) Dense mesh,

quadrilateral elements

Figure 12 Examples of changing mesh density and element type


11

Finally, Fig. 13 shows the result of a linear stress analysis of the elevator. The stress distribution shown is the Von Mises stress resulting from an applied aerodynamic load.

Figure 13 Stress response of elevator due to aerodynamic loading

VI. Conclusion Ensuring proper element connectivity and independency of the model definition (e.g. loads and boundary

conditions, material and property definition) from the underlying mesh limit the applicability of FEM analysis in a multi-disciplinary automated design environment. The results in this paper show that capturing and implementing the geometry segmentation process inside a knowledge based engineering (KBE) environment eliminates any manual correction of the geometry in the FEM pre-processor. To remove the dependency of the model definition from the underlying mesh it is essential that the product information/knowledge obtained in the geometric design phase is available for use in the FEM pre-processing stage. The standards used to transfer data from the geometric design stage to the FEM pre-processor stage are incapable of capturing information and knowledge. This paper shows that in the KBE environment, information can be extracted from the product model. Combined with the geometric data and the guarantee that the geometric data is properly segmented this allows for the flexible incorporation of FEM analysis in the multi-disciplinary design environment.

Acknowledgements The author would like to acknowledge Stichting Technische Wetenschappen STW for their financial support of

the research project.

References 1Hughes T.J.R., “The Finite Element Method. Linear Static and Dynamic Finite Element Analysis”, Dover Publications Inc.,

2000 2La Rocca G., “Knowledge Based Engineering Techniques to Support Aircraft Design and Multidisciplinary Analysis and

Optimisation”, Dissertation, Delft University of Technology, 2006 (To be published) 3DeLong D.W., “Knowledge: Confronting the threat of an aging workforce”, Oxford University Press, 2004. 4Cerulli C., P.B. Meijer, and M.J.L. van Tooren, “Parametric modelling of aircraft families for load calculation support.”,

45th AIAA/ASME/ASCE/ AHS/ASC Structures, Structural Dynamics and Materials Conference, Palm Springs, April 2004. 5Morris, A.J. “MOB, A European Distributed Multi-disciplinary Design and Optimisation Project”, Proceedings of the 9th

AIAA/ISSMO Symposium on MDO, Atlanta, Georgia, USA, 2002 6Austern M.H., “Generic programming and the STL”, Addison-Wesley, 1998


12

Automated Finite Element Analysis in a Knowledge Based...

Documents

Transcript of Automated Finite Element Analysis in a Knowledge Based...