Knowledge Driven Preprocessing - Linköping University · Knowledge Driven Preprocessing – Automating mesh generation for static load bearing jet-engine components Abstract Lead

Knowledge Driven Preprocessing - Automating mesh generation for a jet engine

component

Markus Andersson, 2005-06-22

Institution och avdelning Framläggningsdatum

Publiceringsdatum (elektronisk version)

Språk Rapporttyp ISBN:

SvenskaAnnat (ange nedan)

LicentiatavhandlingExamensarbete ISRN:

________________C-uppsatsD-uppsats Serietitel

Övrig rapport

__________________

Serienummer/ISSN

URL för elektronisk version

Titel

Författare

Sammanfattning

Nyckelord

Preface This report is my thesis work at Linköping University, department of Mechanical Engineering – structural mechanics. The thesis work has been done at Volvo Aero in Trollhättan as a part of a project that aims to reduce lead time in the preprocessing process. The project has involved two more thesis students, Ida Bylund and Loganathan Rajagopal. During this thesis work I have received help from a lot of people. I would like to thank the following: The employees of department 9610 for the warm reception and their willingness to help. My fellow students Ida and Loganathan for a close and successful teamwork, especially Ida who has contributed with a large part of the work presented in this report. Our project supervisors Petter Andersson and Patrik Boart who have spent a lot of time providing invaluable help. The project leader and my supervisor at Volvo Aero, Ola Isaksson. My examiner at Linköping University, Bo Torstenfelt.

Knowledge Driven Preprocessing – Automating mesh generation for static load bearing jet-engine components

Abstract Lead time pressure in the development of jet engine components is a driving factor for continuous efforts of improvement. Computer aided engineering tools are intensively used and best practice is continuously evolving. In this report preprocessing in a conceptual phase is investigated. Knowledge Based Engineering is the chosen method for shortening lead time. Knowledge of the design process is collected and implemented as rules in a generic model. Emphasis lies on creating a functional KBE application that automates a selection of routine activities. Main steps in the preprocessing process are:

• Generating an idealized geometry • Meshing the idealized geometry • Creating an input deck for FEM analysis software

Meshing the idealized geometry, which is a midshell representation of an intermediate case, is covered in this report. A standardized approach with rules that governs generation of the mesh is implemented. The KBE application will work with the given specifications. Lead time has been reduced from two days to less than an hour. Iterating different design configurations is a possibility. The 80/20 model applies for implementing new specifications as in being able to reuse 80% of the work.

2


Table of Contents

PREFACE ...............................................................................................................................................1 ABSTRACT ............................................................................................................................................2 NOMENCLATURE ...............................................................................................................................5 1. INTRODUCTION ..............................................................................................................................6

1.1 VOLVO AERO CORPORATION..........................................................................................................7 1.2 THE JET ENGINE ..............................................................................................................................7 1.3 THE INTERMEDIATE CASE ...............................................................................................................7 1.4 PRODUCT DEVELOPMENT OF A JET ENGINE COMPONENT.................................................................8

1.4.1 Engineering design ................................................................................................................9 1.4.2 Conceptual Design of a jet engine component.......................................................................9 1.4.3 Best Practice in conceptual design ......................................................................................10

1.5 KNOWLEDGE MANAGEMENT AND KNOWLEDGE BASED ENGINEERING.........................................11 1.6 THESIS WORK................................................................................................................................12 1.7 BENEFITS OF A KBE-APPLICATION ...............................................................................................13

2. METHODS, GENERAL APPROACH – MOKA..........................................................................13 2.1 IDENTIFY ......................................................................................................................................14

2.1.1 Business Opportunity ...........................................................................................................14 2.1.2 KBE programming ...............................................................................................................15 2.1.3 Means of finding knowledge ................................................................................................15 2.1.4 Platform ...............................................................................................................................16

2.2 JUSTIFY.........................................................................................................................................16 2.3 CAPTURE ......................................................................................................................................16

2.3.1 Geometry..............................................................................................................................16 2.3.2 Variables of the geometry ....................................................................................................17 2.3.4 Preprocessing ......................................................................................................................18 2.3.5 Preprocessing using Knowledge Fusion ..............................................................................19 2.3.6 Requirements on mesh .........................................................................................................19 2.3.7 Reliable mesh generation.....................................................................................................20

2.4 FORMALIZE...................................................................................................................................20 2.5 PACKAGE......................................................................................................................................20 2.6 ACTIVATE.....................................................................................................................................20

3. RESULTS..........................................................................................................................................21 3.1 MESHING APPLICATION ................................................................................................................21

3.1.1 Inputs ...................................................................................................................................22 3.1.2 Subdivide..............................................................................................................................23 3.1.3 Mesh.....................................................................................................................................23 3.1.4 Preprocessing Lead Time.....................................................................................................25 3.1.5 Varying thickness .................................................................................................................26 3.1.6 Managing the code...............................................................................................................26

4. CONCLUSIONS...............................................................................................................................27 4.1 MANAGING THE APPLICATION ......................................................................................................27

5. DISCUSSION....................................................................................................................................28 5.1 QUALITY OF MESH .......................................................................................................................28 5.2 LIMITATIONS ................................................................................................................................28 5.3 LEAD TIME OF THE MESHING APPLICATION .................................................................................28 5.4 FURTHER DEVELOPMENT ..............................................................................................................28 5.5 LESSONS LEARNED .......................................................................................................................29

REFERENCES .....................................................................................................................................30 RELATED LINKS ...............................................................................................................................31

3


APPENDIX A - MESHING USING KF.............................................................................................32 MESH EXAMPLE CLASS .......................................................................................................................32 MESH EXAMPLE SCENARIO CLASS ......................................................................................................33

APPENDIX B – PROGRAMMING NOMENCLATURE................................................................34 APPENDIX C - PROCESS DESCRIPTION .....................................................................................35 APPENDIX D.1 – SHELL_MESH_APPLICATION_CLASS ........................................................36 APPENDIX D.1 – SHELL_MESH_APPLICATION_CLASS ........................................................36 APPENDIX D.2 – MESHING_CLASS..............................................................................................38 APPENDIX D.3 – OUTER_RING_SCENARIO_CLASS ...............................................................41

Table of Figures FIGURE 1: VOLVO AERO PRODUCTS......................................................................................................7 FIGURE 2: CONCEPTUAL JET ENGINE COMPONENT DEVELOPMENT ..................................................10 FIGURE 3: KNOWLEDGE DRIVEN PREPROCESSOR .............................................................................12 FIGURE 4: THE MOKA LIFECYCLE .......................................................................................................14 FIGURE 5: LEAD TIME REDUCTION ......................................................................................................14 FIGURE 6: MODULES OF THE INTERMEDIATE CASE ...........................................................................15 FIGURE 7: THE INTERMEDIATE CASE AND SURROUNDING COMPONENTS .........................................17 FIGURE 8: VARIABLES OF THE IMC ....................................................................................................18 FIGURE 9: INTERSECTION OF A BYPASS STRUT AND THE OUTER RING.............................................19 FIGURE 10: THE MESHING PROCESS ..................................................................................................21 FIGURE 11: OVERVIEW OF THE MESHING APPLICATION ...................................................................22 FIGURE 12: INTERFACES OF THE MESHING APPLICATION.................................................................23 FIGURE 13: PLANES AND LINES USED FOR SUBDIVIDING THE IMC.................................................23 FIGURE 14: CLASS STRUCTURE OF THE MESH PART OF THE MESHING APPLICATION .....................24 FIGURE 15: SORTING EDGES ON THE OUTER RING ...........................................................................24 FIGURE 16: TOTAL LEAD TIME OF THE KBE-APPLICATIONS IN THE PROJECT .................................26

4


Nomenclature Bypass channel the outer channel of airflow of an intermediate case Bypass ratio the ratio between the air flow through the bypass

channel and the core channel Core channel the inner channel of an intermediate case, passes air

from fan to compressor DOF Degree Of Freedom ED Engineering Design FEA Finite Element Analysis FEM Finite Element Method GUI Graphical User Interface IMC Intermediate Case KBE Knowledge Based Engineering KF Knowledge Fusion, KBE-module of UG NX Master Model Approach all changes to the design are made in the master model

in comparison to changing the idealized model or even further downstream whilst iterating.

Parasolids An UGS product, the modeling core for UG NX and other CAD software

PLM Product Lifecycle Management PD Product Development Strut Primarily supports mechanical loads between ring

structures in the intermediate case Thrust The propulsion force of the jet engine UG NX Unigraphics, CAD software Vane Primarily controls aerodynamic flow in the intermediate

case WEM Whole Engine Model, simplified model of the engine

used for FEM-analysis WEMM Whole Engine Mechanical Model, Simplified model of

the engine used for FEM-analysis

5


1. Introduction Lead time pressure in the development of jet engine components is a driving factor for continuous efforts of improvement. Computer aided engineering tools are intensively used and best practice is continuously evolving. This project deals with some of the trends in CAD/CAE software development, [Kasik et al.]1. Initially when design requirements are given and the conceptual work starts, it is usually done more or less from scratch. The availability of engineering knowledge in actual design activities is often dependent on experience among the engineers themselves. Best practice and design manuals exist but these are often paper based and does not directly assist in the CAE environment. Systems support with embedded rules and principles is one way to manage knowledge and make it accessible at the fingertips of engineers. Results and information in the way of rules and procedures from earlier work can be included creating a database of the collected “know how” of the company. Being able to access this information easily gives the possibility to reuse it. The starting point of the conceptual work is now no longer from scratch. Another topic that is touched upon is the connection between CAD (modeling) and CAE (analysis). Translating information reliably to analysis software is sometimes difficult. Success in easy transfer will allow testing in an earlier phase of a project. Faulty designs and flaws can then be found earlier. Multiple designs may also be tested and can be iterated to identify and refine the best alternatives which will ensure a robust design.

1 Ten CAD Challenges Kasik, David R, Buxton, William, Fergusson, David J

6


1.1 Volvo Aero Corporation Volvo Aero is part of the Volvo group and accounts for 3.5 percent of its sales (2004), [Volvo Aero]2. Volvo Aero employs more than 3300 people, mostly in Sweden but also in Norway and the U.S. Development, manufacturing and some maintenance of aircraft engines is done in Trollhättan, (Sweden). There is also development and manufacturing of aerospace components and land and marine gas turbines, Figure 1. To the left is a typical jet engine used on civil passenger aircrafts. For development and manufacturing, Volvo Aero specializes in static, load bearing components such as the intermediate case, here labeled “fan/compressor structures”. To the right the Ariane rocket can be seen where Volvo Aero manufactures the nozzle for the second stage and turbine components for the fuel pump.

LP Turbine cases

Fan/ Compressor structures

Turbine Structures

Diffuser/ Combuster

cases

Shafts

Compressor Spools

Vanes

Turbine

Nozzle Figure 1: Volvo Aero products

1.2 The jet engine Engines used on most passenger aircrafts are turbo fan engines. They have a high bypass ratio i.e. most of the air passes through the outer (bypass) channel. It is the fan that drives the engine forward by displacing the air moving through the outer channel. The fan is powered by the turbine which in turn is powered by the air going through the core channel. This air is compressed and mixed with fuel in the combustion chamber. The air speed is greatly increased when the mixture is combusted. The air then rotates the turbine blades, for further reading [Rolls-Royce]3.

1.3 The intermediate case The engine is connected to the wing or fuselage via the Fan/Compressor structure and the Turbine structure, see Figure 1. The Fan/Compressor structure is also known as the intermediate case, (IMC). It will transfer loads to engine support beams on the wing or fuselage via engine mounts and thrust lugs. It is also connected to the rest of the engine via different flanges. Thus the main purpose of an intermediate case is to transfer loads and provide structural stiffness to the surrounding parts of the

2 Facts on Volvo Aero Internal Volvo Aero Document 3 The Jet Engine Rolls-Royce

7


engine, [Volvo Aero]4. Examples of IMC models can also be seen in Figures 6, 7 and 8. Another increasingly important feature is to be able to integrate the guide vanes with the struts of the intermediate case. The guide vanes change the air flow from the fan in order to reduce vibrations and noise. The struts will then have a somewhat more complex shape. Also, the typical number of struts is far less than the number of guide vanes. An intermediate case with integrated guide vanes might need 30 bypass struts instead of only ten. Other functions of the IMC are:

• Separate airflow in two channels - core and bypass channel • Transfer oil and air to bearings • Resistance to fire • Divide the engine into fireproof sections

The intermediate case has also been the object of study in [Boart, Jonasson]5 where a similar application was developed.

1.4 Product development of a jet engine component Product development is defined by [Isaksson]6 as: Product development is the company process which takes the business requirements as a start and transforms these into a product. Product development includes aquisition, marketing, financing and all other parts of the product life cycle besides the actual design work. Product development efficiency can be measured by three interrelated performance standards, [Trygg]7: lead time, cost and design quality. Improvement in product development can, because of its complexity, be achieved in a multitude of ways. Product Life-Cycle (PLC) modeling simulates parts of the life cycle. There are different examples of methods; Case-Based Reasoning (CBR), Expert Systems (ES) and Knowledge Based Engineering (KBE). The reason for using these methods is achieving a higher PD efficiency. Which method is most suitable differs with the circumstances, for further reading [Sandberg]8.

4 Design Manual, IMC Internal Volvo Aero document 5 Functional Jet-Engine Component, Modeling using KBE Boart, Patrik. Jonasson, Pierre 6 A generative modeling approach to engineering design Isaksson, Ola 7 Engineering Design- Some Aspects of Product Development Efficiency Trygg, Lars 8 Knowledge enabled engineering design tools for manufacturability evaluation of jet engine components Sandberg, Marcus

8


1.4.1 Engineering design Engineering design is a subset of Product development. Initially in a PD process, customer requirements have to be identified and translated to design requirement specifications. As this is done the Engineering Design (ED) work of the PD process starts. ED is defined by [Isaksson]6 as: Engineering design is the general process of transforming design requirements into verified solutions. From a cost perspective, the conceptual design phase in ED is considered most important, [Kasik et al.]1. Improvement of efficiency here, like shortening lead time, will have a dramatic impact on product cost.

1.4.2 Conceptual Design of a jet engine component At the start of developing a jet engine component is the conceptual phase where the aim is to identify one or more suitable designs. Engineers rely on experience from previous designs that are already proven in real life. New design requirements are given and the designs are adapted according to these. Being able to perform early tests is important in order to discover faults and flaws as soon as possible. The cost of correcting these becomes increasingly more expensive when moving downstream in the PD process. Activities considered here in the conceptual phase can be seen in Figure 2 below. There are usually iterations between each two steps and also in other possible combinations. Performing these steps is often tedious and time-consuming. After post-processing a decision is taken to either accept the design or change one or several variables. Time consumption grows exponentially if system variables, that include several steps in the process, are changed rather than local variables, (to the left in Figure 2). Being able to iterate the geometry definition or even the idealized geometry is difficult. To the right in Figure 2 there is an iteration loop that goes from postprocessing to geometry idealization. The idealized geometry can be a mid-shell representation of the 3D model which is suitable for analysis of stiffness and modal frequencies. Shortening lead times in the preprocessing steps simplifies iterating geometry idealization. The result is an improved possibility to optimize of the model with respect to stiffness and modal frequencies. A full iteration loop that includes all system variables that can be changed directly in the master model is also suggested in Figure 2. Achieving such an iteration loop will greatly increase the design engineer’s possibility to optimize the model with respect to any requirement.

9


Figure 2: Conceptual Jet Engine Component Development

1.4.3 Best Practice in conceptual design In the conceptual design work the aim is to find the most suitable choice of concept for the component. Different configurations are tested using stiffness and modal analysis. Typical variables are for example the amount of struts, choice of material etc., [Normark]9. Often the method for doing concept studies is to create a parametric idealized model directly in the CAE platform. Structures such as intermediate cases, that are to be subjected to stiffness and modal analysis, are idealized into midshell models, for further studies see [Rajagopal]10. There is often rotational repetitiveness in intermediate cases. If that is the case, the different sections are modeled and combined into the complete structure like pieces of a pie. Some variables like thickness and material parameters may be changed easily in such a model. Measurements may also be varied, depending on the parameterization of the model. However, creating the parametric model is time consuming. There is often not enough time to create a second or third parametric model with different variables. It is also obvious that the geometric modeling capability of a CAE platform is limited compared to CAD functionality. For example, modeling topological changes such as changing in the assembly is not possible. When the concept study involves variables that can not be included in one or several parametric models in the CAE platform a midshell representation has to be created in a CAD platform. “Dumb” geometry in the form of parasolids can then be exported to the CAE platform for preprocessing and analysis.

9 Validation and verification of structural analysis Normark, Lars-Ola 10 Load Path Design of a Jet Enginge Component Rajagopal, Loganathan

Geometry Definition

Requirement Specification

Geometry Idealization

Mesh Generation

Analysis Input Definition

Analysis

Post-Processing

Possible Opt. loops: Requirement Specification structural mechanics,

space allocation, manufacturing,

Geometry Definition


Mesh Generation


Analysis

Post- Processing

weight, aero

2D Geometry mods: Mesh features: modules, beams, no struts, elem. size… measurements

Real constants: thickness, mtrl. param, temperature...

Analysis iter. : load cases, boundary conditions…

10


1.5 Knowledge management and Knowledge Based Engineering In a large organization dealing with product development there exists vast quantities of information in the form of experience and “know how” tied to processes or individual co-workers. Being able to capture, make available and reuse this engineering design information and intent becomes increasingly important as the organization grows. [Benson, Terpenny]11. KBE is a subset of Knowledge management. It is a method that manages product and knowledge that can be captured within a CAD/CAE/CAM environment. KBE a suitable method to use for, [Andersson]12:

• Products with a high degree of similarity in-between versions. • Products requiring a large number of design configurations (e.g. Geometry

alternatives, material alternatives or color alternatives). • Products with a large number of design processes (e.g. FEA optimizations).

In capturing such knowledge there is a possibility to automate mundane routine tasks with the benefit of greatly reducing lead times. KBE is defined by [MOKA]13, (Methodology and software tools Oriented to Knowledge based engineering Applications). The use of advanced software techniques to capture and re-use product and process knowledge in an integrated way. This statement simply means that knowledge is integrated as rules in the code of the application. There exist several KBE systems more or less integrated into the major CAD platforms of today14. These KBE systems provide the possibility to automate and incorporate “intelligence” in a process.

11 A Survey of methods and approaches to knowledge Benson, Maria, Terpenny, Janis 12 Strategies for modeling geometry in Knowledge Based Engineering systems Petter Andersson 13 Managing Engineering Knowledge MOKA: Methodology for Knowledge Based Applications 14 KBE platforms: Knowledge Fusion http://www.UGS.com, accessed 2005-05-24 ICAD http://www.ktiworld.com, accessed 2005-05-24 AML http://www.technosoft.com, accessed 2005-05-24 Design++ http://www.dp.com, accessed 2005-05-24

11

http://www.ugs.com/

http://www.ktiworld.com/

http://www.technosoft.com/

http://www.dp.com/


1.6 Thesis work This thesis work has been a part of a project - using the current KBE-platform of Volvo Aero - to create an application that deals with preprocessing of an IMC. The first objective is to work out how to support the preprocessing work with systems support. The second objective is to make the systems support as general as possible in the sense of handling different geometries. The project has been divided into three parts, one for each preprocessing step.

1. Generate a geometry defined by user input. 2. Prepare the geometry for meshing. Mesh the geometry and add basic features

to the mesh (thickness, material properties). 3. Add loads and boundary conditions. Generate an input deck for Ansys.

Knowledge DrivenPreprocessor

Geometry IdealizationMesh GenerationAnalysis Input Definition

Geometry Definition

Requirement Specification


Mesh Generation


Analysis

Results Evaluation

Figure 3: Knowledge Driven Preprocessor

This report will focus on the second step in this process, i.e. Mesh Generation, Figure 2, whereas others have studied the first and third step. [Rajagopal]10, [Bylund]15.

15 Knowledge driven pre-processing, analysis input definition Bylund, Ida

12


1.7 Benefits of a KBE-application There are several reasons for creating a KBE-application, [Rondeau et al.]16, most important is to shorten lead times. The goal with the Knowledge Driven Preprocessor-application is to deliver an input deck to Ansys in less than an hour. All time consuming, tedious and repetitive work is automated. In comparison this process would normally take several days for an engineer. In complement to shortened lead times there are some other benefits to be seen with this application such as:

• Alternative configurations The capability to both design and evaluate a large variety of alternative configurations in a limited time-frame.

• Quality The procedure will always be the same, ensuring quality in the analysis. A “Volvo Aero-standard” can be implemented in the application.

• Availability All “intelligence” such as rules, methods, “know how” is programmed into the application and will be available at the fingertips to the user.

2. Methods, general approach – MOKA [MOKA] 13 is a methodology for developing KBE applications. This has been the basis of approach throughout the project. In Figure 4 below the steps in the MOKA methodology is described. The capture and formalize steps are important. The aim for capture is to gather knowledge and structure it into an informal model. In the formalize step the informal model is transferred to a formal model - a neutral format. This is an intermediate step between raw knowledge and the programming code of the application. The guidelines for performing these steps are quite detailed. Special forms may be used to help structure knowledge into the informal and formal model. During this project all such guidelines have been omitted. All gathered knowledge has been stored in ordinary documents and tables. The main reason for this being lack of time. This project might instead be considered rapid prototyping which iterates the capture – formalize – package steps, [MOKA]11. It is a first attempt of creating a working application that can be used by engineers at Volvo Aero. One of the reasons for using the current KBE-software of Volvo Aero is to evaluate its preprocessing functionality (as is stated below under Identify-Platform). In this sense, some of the knowledge that is to be collected lies in the package step, i.e. what should the code look like, what methods can be used, what workarounds are needed? Also, it should be noted that MOKA was developed for support in large projects and some of the guidelines might be considered somewhat “formal” in a relatively small project such as this.

16 Generative design and optimisation of the primary structure for a commercial transport aircraft wing. Rondeau, D L, Peck, E A, Williams, A F, Allwright, S E, Shields, L D

13


KBE life-cycle

Identify

Capture

Justify

Formalize

Package

Activate

KBE life-cycle

Identify

Capture

Justify

Package

Activate

Formalize

KBE life-cycle

Identify

Capture

Justify

Formalize

Package

Activate

KBE life-cycle

Identify

CaptureCapture

JustifyJustify

PackagePackage

ActivateActivate

FormalizeFormalize

Figure 4: the MOKA lifecycle

2.1 Identify The identify step aims to identify, among other things, the driving factors of the project. The background, scope, objectives and reasons has already been stated in the introduction. Below, some more aspects are given.

2.1.1 Business Opportunity The business opportunity for the application lies mainly in the conceptual phase of a project since only the idealized geometry may be analyzed. Need for such analysis results are still increasingly important for supporting decisions at an early stage. The application will shorten the time needed to less than an hour. This can be compared to a traditional approach that might take several days, Figure 5. Thus information in the form of analysis results will be accessible to base a decision on. Proposals and offers can be made on a more accurate technical basis. Product models (concepts) can actually be defined and analyzed as a part of the offering process.

AnalysisPreprocessing Postprocessing

GeometryIdealization

Analysis Postprocessing

Lead Time

AnalysisPreprocessing Postprocessing

GeometryIdealization

Analysis Postprocessing

Lead Time Figure 5: Lead time reduction

14


2.1.2 KBE programming There are some special features in a KBE programming language. Object oriented programming means that the object is represented as an assembly of subparts where rules govern properties of the assembly and each subpart15. An intermediate case may for example be an assembly of subparts according to Figure 6. An object oriented programming language grows even more powerful when it is demand driven; i.e. only requested parameters are evaluated. There is great reduction in computational time when compared to a sequential programming language where operations on each line are performed in sequential order and all variables are evaluated.

1. Outer ring

2. Bypass Strut

3. Splitter Box

4. Core Strut

5. Support Structure

IMC

Figure 6: Modules of the Intermediate Case

2.1.3 Means of finding knowledge The reason for creating the application is to collect and gather knowledge that can be implemented. There are several ways of finding relevant information: interviews, informal meetings, software documentation, literature and articles, code from earlier KBE applications, trial and error etc. Preprocessing has not been done much in UG NX. Other software is used for this at Volvo Aero. Thus the basic approach has to be tried out first. What steps are necessary to create a mesh? This knowledge can be found in reference documentation of UG NX and trough experience of working interactively. Second, how to perform the preprocessing steps through the KBE platform? This has to be found out with help of software documentation, code from earlier KBE applications, discussions with Volvo Aero engineers and if nothing else helps - trial and error. Besides this there are requirements on what the mesh should look like and what functionality should be included in the application. There is literature that gives basic knowledge on meshing, for example [Cook et al.]17. Another source is reports from earlier project work at Volvo Aero. Interviews with Volvo Aero-personnel performing these tasks will also give relevant information.

17 Concepts and applications of finite element analysis Cook, Robert D, Malkus, David S, Plesha, Michael E, Witt, Robert J

15


2.1.4 Platform UG NX2 has been used as a CAD platform. The KBE tool is Knowledge Fusion, (KF). It is fully integrated into UG NX. All functionality in UG NX is available in KF (although some functionality is yet to be implemented). This is beneficial when generating the geometry since a parameterized model, including the possibility for topological changes, can be created. The application could be programmed to accept changes to any variable through an input deck. Continuing the preprocessing within the UG NX-environment means that all variables of the model will be accessible – there is no need to translate the geometry including its rules and parameterization to a new platform. Another tool that is available is UG Open where UG NX functionality is accessed with C programming. Because of the similarities with the UG NX core more functionality has been implemented in UG Open. The recommended way to develop a KBE application by UGS is to use KF and call on UG Open when necessary. There are many pros and cons when using each tool but the one deciding factor is that the KF programming language is based on Intent! This is a true KBE programming language which it is both object oriented and demand driven. Implemented KF programming can be seen in APPENDICE A and D.

2.2 Justify This step aims to motivate and ensure the relevance of the project. Sub steps involve estimation of resource requirements and costs, estimate risk and develop a project plan. The Knowledge Driven Preprocessor can be considered a pilot project. The most important aim is to reduce lead-time in preprocessing and the way to do it is KBE. The pilot in itself is needed to justify the capability to implement project support at Volvo Aero using KF to support preprocessing.

2.3 Capture The capture step aims to collect all knowledge related to the application that is to be created. The knowledge is sorted and structured into an informal model. In MOKA a detailed approach on how to sort and structure the informal model in tables is suggested. This method has not been followed in this report. Instead, the gathered information is simply presented straightforward.

2.3.1 Geometry The geometry that is to be generated is an intermediate case. It is a ring – strut – ring structure as can be seen in Figure 6, 7 and 8. All intermediate cases have the same basic features thus making it suitable for a KBE application. Selected design variables can be controlled through a graphical user interface, (GUI). Modular modeling allows for reuse for other jet engine components, especially since there are similar ring – strut – ring components.

16


Bypass outer ring

Bypass channel

Splitter Box

Core channel

Support structure

Accessories Bypass Outer ring

Bypass strut

Core strut

Splitter box

Support structure

Engine Mount

Fan outlet guide vane

LPC Stator support structure

High Pressure Compressor inlet guide vane

Low Pressure Compressor outlet guide

vane

Fan Case

HPC case

Inner Bypass duct faring

Outer Bypass duct

faring

Gear Box

Core Channel

Bypass Channel

Figure 7: the intermediate case and surrounding components

The geometry generated in the first step of the process is idealised in a matter suitable for meshing. Only geometry that is important for representing structural properties of the IMC is included. Small details like holes for weight optimising are omitted. Sheet bodies of the IMC are created in such a way that there are no unnecessary complex surfaces. No accessories such as engine mounts, bosses, stiffening ribs or gearbox attachments exist. However, such features can be added later on.

2.3.2 Variables of the geometry The generated geometry can be modeled with nearly any shape on any surface. In addition to this there are variables and interrelationships that are important to note, see also Figure 8.

• Number of bypass struts • Sweep angle - front bypass strut edges • Sweep angle - rear bypass strut edges • Lean angle - bypass struts • Swirl angle – bypass struts • Splitter box torsion-walls will follow the front and rear edges of both the

bypass and core struts (giving a sound load path) • Angle of splitter box torsion-walls? • Number of core struts • Sweep angle - front core strut edges • Sweep angle - rear core strut edges • Support structure torsion-walls will follow the front and rear edges of the core

struts All meshing functionality has to be independent of these variables. There are some features constant with the model: sheet bodies are named according to a certain nomenclature when created. Also, the geometry is built up of modules, see Figure 6. The assembly and sub-assemblies of the IMC varies with the combination of modules.

17


Each module contains certain sheet bodies that are known beforehand. For example, there can be different splitter box modules. One module may consist of simply four sheet bodies: outer ring, inner ring, front torsion wall and rear torsion wall. Another module may also include an inner support structure etc. Other information such as number of struts and specifics of the configuration (that affects the mesh generation) can be inherited from the mesh generating classes or given as user input in an interface.

sweep angle

lean angle

front swirl angle

Splitter box front torsion wall

sweep angle

lean angle

front swirl angle

Splitter box front torsion wall

Figure 8: Variables of the IMC

2.3.4 Preprocessing Preprocessing in UG NX is done in a sub-module called “Structures”. A new scenario is created with an extracted copy of the master model. The preprocessing can be done to suit different environments such as Ansys, Nastran, Abaqus and Structures PE, the latter being the solver integrated into UG NX. Input decks can be created for the first three environments. Shell structures in UG NX are modeled as “sheet bodies”. Each sheet body consists of at least one face and can be subdivided into as many as needed. A shell mesh can be created from any combination of sheet bodies and additional faces. When meshing shells there is a possibility to attempt mapping of the mesh. However, from experience it is known that the quality of the resulting mesh often varies when the complexity of the geometry increases. It is important that intersecting sheet bodies are connected in order for the mesh that is generated to be intact, i.e. for the meshes on each sheet body to be properly connected to each other. This can be done by subdividing both sheet bodies to create intersecting edges on both surfaces, see Figure 9. A “connect” function may then be used. Another approach is to make sure that the nodes created on the interfacing edges intersect. Nodes within a certain tolerance, “node uniqueness tolerance” will merge creating an intact mesh. Some solvers, such as Ansys in this case, will be able to

18


handle connecting two independent meshes. This may be done by merging nodes in a similar manner. It can also be done with contact elements that have the possibility to simulate different contact conditions. A shell mesh can be given a thickness and material properties. The material is selected from a library that can be edited. Nodes, elements and properties of the mesh, as well as added loads and boundary conditions will then be included in the input deck.

Figure 9: Intersection of a bypass strut and the outer ring

2.3.5 Preprocessing using Knowledge Fusion Creating a shell mesh with KF is done in the same manner as in “Structures”. A scenario needs to be created and to this the geometry is extracted, (see APPENDIX A). In the new scenario the extracted geometry can be referenced, for example edges may be given a certain edge density. The geometry, as well as most functionality available for a shell mesh in “Structures”, can then be given as input to ug_cae_shell_mesh class.

2.3.6 Requirements on mesh Shell mesh is suitable for stiffness and modal analysis which imposes certain requirements on the mesh. Quadrilateral elements (four nodes) will give more reliable analysis results than triangular elements, especially when mapped. Triangular elements are especially bad when it comes to representing stiffness, [Cook et al.] 17. For stiffness and modal analysis there is often no significant difference in results between using elements with linear or quadratic form functions, [Normark]9. From tradition elements with linear form functions are often used for conceptual studies at Volvo Aero. Free-meshing with triangular elements will often result in a good mesh. Trying to create a mapped mesh (quadrilateral elements) in UG NX will give varying results, often with poor quality. A mapped mesh will ensure repetitiveness. If rules are imposed on the mesh generation the resulting mesh will look the same each new time it is generated, see Figure 10.

19


Certain edges will have special requirements on the mesh. Flanges may connect to other geometry in a whole engine model, (WEM). A specified number of equal-length elements should then be placed along those edges. Another example of edges which requires specified edge densities is interfacing sheet bodies, (see Preprocessing using Knowledge Fusion above). These edges can be identified and given proper edge densities with help of rules. When using shell elements local discontinuities may occur. Such have not been accounted for. Examples of such discontinuities could be: What is the best way to model a 90 degree-connection between surfaces, [Normark].17 How load-transferring flanges are best represented? Is there need for stiffening rims? (Integrating beam elements are a possible solution in the last two cases.)

2.3.7 Reliable mesh generation From experience of meshing in UG NX a reliable method of mesh generation that meets the requirements and is possible to implement in KF have been found.

1. Subdivide Shell-bodies – create ”square” faces 2. Set number of elements (Edge Density) along all edges 3. Use auto-mesh function

It can be seen that 1. and 2. are “extra” steps. However, it is a method that ensures a good quality of the mesh and repetitiveness. This is especially important since the method is to be implemented in an application. Small anomalies can not be corrected by hand as in interactive meshing. The tasks of subdividing and setting edge densities are mundane and time consuming but when automated this does no longer apply.

2.4 Formalize To strictly follow MOKA, a formal model should be created as knowledge is structured. The reason for doing this is to prepare the knowledge for implementation in a standardized form. The formal model should be independent of which KBE-platform that is to be used. As stated above, the procedure has been different in this project. Based on the knowledge gathered, a process description on what the application should look like is created as a complement to the knowledge gathered [Isaksson].6 The class structure and what tasks should be done in each class is described in the process description, APPENDIX C shows an example of a strut scenario class.

2.5 Package This step in the process refers to implementing the formal model into KBE-platform of choice, i.e. programming. This has, by far, been the most time consuming part of the project. A simplified example of meshing a shell can be found in APPENDIX A.

2.6 Activate The activate step is the process of populating the finished application. However, the object of this project was to pilot an application, not to activate it. The model has been instantiated with specifications for an ongoing IMC development project at Volvo Aero. Models have been presented and used in this project.

20


3. Results The results of the complete project are three separate applications that will in turn, generate the geometry, mesh it and create an input deck for Ansys. The generated code in itself may also be considered a result. The way to implement rules in KF in order to perform preprocessing is the topic of interest for this project.

3.1 Meshing Application The meshing application that was the main objective of this thesis work has been created. It is “general” in the sense that it can combine the use of modules to mesh different designs. Presently it is limited to the geometry modules defined in this project, i.e. a rather simplified representation of an IMC. As more geometry modules are created, more meshing modules (as well as input deck modules) can be added. For this cause, most of the generated code can be reused which will reduce development time dramatically. The results of the meshing application can be seen in Figure 10. The starting point is a “clean” geometry and the output is a mesh of the model. The intermediate step shown in Figure 10 shows how the model is subdivided. The output is a rule based mesh. Parameters that can be varied are: Material properties, thickness of each module and certain edge densities. Besides this the mesh can be created on any geometry configuration generated in the first step.

Figure 10: The meshing process

A simplified process of the meshing application can be seen in Figure 11. The meshing application consists of two independent parts with their respective interfaces. The subdivide part will result in the subdivided model, fig 9. The input needs to be the geometry generated in the first step of the project. The mesh part will give the final result and needs the subdivided model as input.

21


Mesh Application

Subdivide1) Create intersections

2a) Create planes

2b) Find intersections

3a) Create lines

3b) Project lines

4) Subdivide

Mesh1) Create scenario

2) Sort edges

3) Set ED

4) Sort Faces

5) Mesh Faces/Sheetbodies

Mesh Application

Subdivide1) Create intersections

2a) Create planes

2b) Find intersections

3a) Create lines

3b) Project lines

4) Subdivide

Mesh1) Create scenario

2) Sort edges

3) Set ED

4) Sort Faces

5) Mesh Faces/Sheetbodies

Figure 11: Overview of the Meshing application

3.1.1 Inputs The geometry generated in the first step is a necessary input for the meshing application. The reason for this is that the geometry is known and defined in a certain way. All sheet bodies and some faces are named according to a nomenclature, see APPENDIX B. Also, how to sort edges and faces are based on geometric locations as well as their numbers. The amount of edges varies when the amount of struts change, this has been taken account for. However, should the outer ring contain one additional edge, that will disturb the sorting of edges. The result would likely be at least one edge having the wrong edge density. There are also user defined inputs that are given in interfaces. Each input is a parameter defined in the top class. The parameter is then sent down to all necessary module classes. Figure 12 show the independent interfaces of the subdivide and mesh part of the meshing application. As can be seen the application will not recognize the geometry by it self, (no information is not sent from the geometry generation step). Instead features such as amount of struts and what modules to mesh are user defined inputs. (The reason for this approach is because of stability issues.) Other variables can be given as well, for example number of elements along the outer ring flanges etc.

22


Figure 12: Interfaces of the Meshing application

3.1.2 Subdivide The subdivide part of the meshing application aims to divide all surfaces into square faces. This is done first, by creating intersecting lines between all struts and rings. These lines are then used to create faces and edges on the rings corresponding to the intersecting struts, see Figure 13. Second, planes are defined based on the geometry. Intersection lines between the planes and the geometry are used to subdivide the sheet bodies. Third, lines are created based on the geometry. These lines are then projected onto the geometry and used for the final subdividing of sheet bodies. The tasks that are automated here can be considered repetitive and extremely tedious. Using a KBE-application this will take about two minutes to perform.

Figure 13: Planes and lines used for subdividing the IMC

3.1.3 Mesh The mesh part aims to create a mesh with given inputs like specific edge densities, thicknesses and material properties on the subdivided model. The class structure of the meshing application can be seen in Figure 14. Also, the tasks of each class are

23


listed. A simplified example of meshing in KF can be seen in APPENDIX A, for the complete code of some of the classes of the meshing application see APPENDIX D.

Mesh

shell_mesh_application_class

1) Accept indata

2) Number struts

3) Start meshing_class

meshing_class

1) Start the correct moduleclasses

Support_structure_Scenario_class1a) Sort edges1b) Set edge density2) Sort faces3) Mesh sheetbodies/faces

Core_Strut_Scenario_class1a) Sort edges1b) Set edge density2) Sort faces3) Mesh sheetbodies/faces

Splitter_Box_Scenario_class1a) Sort edges1b) Set edge density2) Sort faces3) Mesh sheetbodies/faces

Bypass_Strut_Scenario_class1a) Sort edges1b) Set edge density2) Sort faces3) Mesh sheetbodies/faces

Outer_Ring_Scenario_class

1a) Sort edges

1b) Set edge density

2) Sort faces

3) Mesh sheetbodies/faces

Mesh

shell_mesh_application_class

1) Accept indata

2) Number struts

3) Start meshing_class

meshing_class

1) Start the correct moduleclasses

Support_structure_Scenario_class1a) Sort edges1b) Set edge density2) Sort faces3) Mesh sheetbodies/faces

Core_Strut_Scenario_class1a) Sort edges1b) Set edge density2) Sort faces3) Mesh sheetbodies/faces

Splitter_Box_Scenario_class1a) Sort edges1b) Set edge density2) Sort faces3) Mesh sheetbodies/faces

Bypass_Strut_Scenario_class1a) Sort edges1b) Set edge density2) Sort faces3) Mesh sheetbodies/faces

Outer_Ring_Scenario_class

1a) Sort edges

1b) Set edge density

2) Sort faces

3) Mesh sheetbodies/faces

Figure 14: Class structure of the mesh part of the Meshing application

Most challenging is to properly sort all edges of the geometry. This is done separately in each module class. The approach is listed below:

• Find all edges/boundary edges on Sheet Bodies/Faces by reference to names • Sort out edges that fulfil certain conditions,

ex: constant cylindrical coordinates • Remove edges from initial list • Further sorting by length, distance to points etc.

As an example of this, the sorting process of all edges in the outer ring (32 bypass struts) is showed in Figure 15. The flange edges are found easily since they are boundary edges of the sheet body, (which is the complete outer ring). The constant radius edges are all edges whose start and endpoint describes equal length vectors towards the axial axis. From those the amount of long/short edges is known (based on the amount of struts). The “problem edges” are those that do not fulfil the previous criteria. They can be sorted according to various other criteria. In this case it is enough to differentiate them from their position along the axial axis.

Outer Ring 1312 edges

128 flangeedges

672 constantradius edges

576 long edges

96 short edges

384 Interface edges

128 Intermediate edges

512 ”problem edges”


128 flangeedges


576 long edges

96 short edges

384 Interface edges




128 flangeedges


576 long edges

96 short edges

384 Interface edges



Figure 15: Sorting edges on the outer ring

24


3.1.4 Preprocessing Lead Time The complete procedure, going from scratch to an input deck, can be performed in an hour which was the stated goal. In Table 1 below the time needed to perform each task in the project is listed in comparison to an estimation of the same task done interactively using current software at Volvo Aero, (estimated with help from engineers at Volvo Aero). KBE-application interactively

Geometry: < 1 minute 0.5 – 5 hours Subdivide: 2 – 3 minutes over 2 – 20 hours Mesh: 8 – 45 minutes 1 – 10 hours Analysis file: 1 – 2 minutes similar (using macro) Total: < 1 hour 3.5 – 35 hours

Table 1: Time consumption

It can be seen that there is quite a dramatic reduction in lead time. Especially since 3.5 hours is a rather optimistic result. Also, using the KBE-applications one engineer can do all steps on the same computer. It is likely that several engineers using several computers will be involved in performing the same process interactively. Translating instructions and data between engineers and computers will then take additional time as well as resources. It can be seen in Table 1 that the time needed to complete meshing on a geometry that is already subdivided is relatively long. This takes up to an hour whilst subdividing of the geometry is a matter of minutes. Generating and updating the geometry takes even less time. There may be two reasons for this. First - the procedure of meshing is time-consuming. Second - how the code is built up in the meshing part. Presently, all edges have to be found, sorted correctly and given an edge density. This calls for a lot of loops since there may be more than 3000 edges in a subdivided IMC model. In KF the source code is compiled during the process. In comparison, UG Open uses C which is precompiled. The difference in time consumption between the two is especially obvious when it comes to loops. Thus, when large loops can not be avoided they should be performed by calling an UG Open function. Computing time might be reduced somewhat if the present code is refined according to this guideline. In fig the time consumption for running through the complete process (geometry generation to input deck) is plotted with respect to number of bypass struts. It can be seen that the relationship is almost linear. What is interesting to note is that all things are constant except for the amount of edges that also increase linearly. This further supports the reasoning above that the loops in the sorting procedure are the most time consuming part.

25


Time to run the application

05

101520253035404550

8 16 24 32

Number of struts

Tim

e [m

inut

es]

Figure 16: Total lead time of the KBE-applications in the project

3.1.5 Varying thickness Thickness may be given as in data to ug_cae_shell_mesh_class which is a predefined KF class. Varying thickness on a sheet body means setting different thickness to faces on the sheet body. Sorting of faces on the outer ring was done so that thickness could be varied in sectors - one sector for each bypass strut. This presented some difficulties, though. Giving neighboring faces as in data to different calls on the UG meshing class is not possible in the KF version used. This has been reported as a bug to UGS and has resulted in a fix in UG NX3 and later versions.

3.1.6 Managing the code An approach for managing the code is to create new subdivide and meshing modules for each new geometry module that is created. Also - as soon as present geometry modules are changed - its correlating meshing module needs to be updated as well. This could seem a strenuous task and in some ways it is. There is a need to fully understand the code before any editing is done. However, when that understanding is achieved it will take an experienced engineer only a few hours to implement code for a complete new geometry. Most of the code can be reused. The 80/20 model is applicable, [Isaksson]6. If entire subdividing and meshing modules can be can be used for new geometry the time needed is even less.

26


4. Conclusions Is it possible to use KF for generative preprocessing and reduce lead time? Present meshing in Ansys, Nastran or Unigraphics is time consuming. Knowledge driven preprocessing is a possible alternative that will reduce lead time. It will also capture and reuse knowledge, enable iterations of multiple design solutions and automate tedious routine tasks. The drawback with KBE is the initial effort that is needed before the application is ready to use.

4.1 Managing the application Managing the application means keeping the code of the application up to date. It also means adding new geometry- and subdivide-/meshing- modules to a “library”. With time this library can grow to include more geometry such as intermediate compressor cases and turbine exhaust cases etc. Methods and procedures might need revision as new software functionality becomes available. In addition - from a knowledge management perspective - documentation of what is implemented needs to be kept: which modules of geometry-generation/subdividing/meshing are included, what are the procedures and rules that are included in them etc. A conclusion is that the time needed for managing this kind of application is considerable. It is only when needed geometry is fully implemented that the application becomes truly powerful. Note that implementing this geometry may be done before specifications for a new project are given and time is limited. Future demands can be predicted and code to meet those demands created. This will reduce risk of “bottle necks”.

27


5. Discussion Does the meshing application fulfill the stated objectives? It is actually possible to generate a meshed model in less than an hour. When it comes to being general in the sense of geometry it will only work with the implemented modules. When new specifications are given, new modules need to be implemented. It is this initial work that is the cost of reducing the lead time. Preprocessing according to best practice will not have an initial time cost. Lead times are longer, (see Table 1) but can perhaps be shortened with updated and improved preprocessing software.

5.1 Quality of Mesh Creating a mapped mesh can in some cases be considered unnecessary effort. However the procedure that is implemented is gives reliable results with present functionality. Also, since the mesh generation is automated the time loss of creating a mapped mesh is minimal. Instead, a mesh this closely controlled will ensure quality in repeated analyses, especially when results of different configurations need to be compared.

5.2 Limitations As a consequence of the meshing approach, the code has to be carefully managed and updated in order to stay functional. When geometry is changed the rules used to subdivide and mesh this geometry may no longer apply. Small changes in the geometry can lead to need of dramatic changes in the code. On the other hand, as long as the sheet bodies and the number of edges are the same there is only need for minor changes. Tolerances in the sorting process may need adjustment in order to find all edges. Also, some edge densities may need to be changed.

5.3 Lead Time of the Meshing Application The time consumption for running through the complete application is less than an hour depending on the amount of edges in the model. Handling and sorting large amount of edges of the model is time consuming. Refining the code and using UG Open for sorting can reduce lead time. A cut in lead time will be also achieved if the implemented method can be changed so that only a few edges need to be sorted and given edge density. However this is related to the complexity of the geometry and the functionality of the preprocessing software.

5.4 Further development For further development of the meshing application an intermediate step can be added. This would be to sort and name the edges outside the scenario. In the scenario classes the edges may then be found by their names and given a proper edge density. This would give a possibility to edit named edges interactively. The scenario classes could then be called upon to give edge densities and mesh the geometry. The Meshing Application also needs further testing and refinement to resolve stability issues and improve performance. Implementing the possibility to include connection to solid 3D mesh and beams will increase accuracy when modelling interfaces and stiffeners.

28


5.5 Lessons learned Some of the things that I have learned through the work in this project:

• Implementing new, never before tried functionality is time-consuming. Knowledge and experience of the programming language is important in this situation, especially when “work-arounds” are needed. Implementing functionality similar to such previously used is fast. “Copy-Paste” can be used with great success. But also here is it important to know the programming language in order to reuse code correctly.

• Working closely together in a small group is dynamic and efficient. Cooperating with difficult tasks saves time. Sharing information in a small group is easily done on an informal level. Documenting the information is still necessary, especially in a rapid prototyping project where different versions of the application are continuously developed.

• When an application is created it will take some effort to maintain it. Both functionality and documentation of the implemented knowledge needs to be kept up to date. Otherwise there is a risk that the application turns in to a “black box”. The input is given and output is received but no one besides the author of the code knows what is happening in between.

• Keeping a positive “it can be done” attitude in the group is important. During the course of the project there is bound to be setbacks and some of the work done will prove unnecessary. A positive attitude and support from co workers makes it easier to find “work-arounds” to problems that might seem impossible to overcome.

29


References 1 Ten CAD Challenges Kasik, David R, Buxton, William, Fergusson, David J 2005 | IEEE Computer Graphics and Applications, March/April 2005 2 Facts on Volvo Aero 2005 | Internal Volvo Aero Document 3 The Jet Engine 1996 | Rolls-Royce plc 1986, fifth edition ISBN 0 902121 2 35 4 Design Manual, IMC 1997 | Internal Volvo Aero document 5 Functional Jet-Engine Component, Modeling using KBE Boart, Patrik. Jonasson, Pierre 2002 | Luleå University of Technology Department of Physics and Mechanical Engineering Division of Computer Aided Design ISSN 1402-1617 : 2002:207 6 A generative modeling approach to engineering design Isaksson, Ola 2003 | INTERNATIONAL CONFERENCE ON ENGINEERING DESIGN ICED 03 STOCKHOLM, AUGUST 19-21, 2003 7 Engineering Design- Some Aspects of Product Development Efficiency Trygg, Lars 1991 | Chalmers University of Technology, Department of Industrial Management and Economics ISBN 91-7032-548-0 8 Knowledge enabled engineering design tools for manufacturability evaluation of jet engine components Sandberg, Marcus 2002 | Luleå University of Technology Department of Physics and Mechanical Engineering Division of Computer Aided Design ISSN 1402-1757 : 2005:16 9 Validation and verification of structural analysis Normark, Lars-Ola 2003 | Luleå University of Technology Department of Physics and Mechanical Engineering ISSN 1402-1617 : 2003:016 10 Load Path Design of a Jet Engine Component Rajagopal, Loganathan Still to be Published by: Blekinge Institute of Technology 11 A Survey of methods and approaches to knowledge Benson, Maria, Terpenny, Janis 2001 | Proceedings of DETC’01 Asme 2001 Design Engineering Technical Conference and Computers and Information in Engineering Conference Pittsburg, PA, September 9-12, 2001

30


12 Strategies for modeling geometry in Knowledge Based Engineering systems Petter Andersson 2001 | Luleå University of Technology Department of Physics and Mechanical Engineering Division of Computer Aided Design ISSN 1402-1617 : 2001:178 13 Managing Engineering Knowledge MOKA: Methodology for Knowledge Based Applications Edited by Melody Stokes on behalf of the MOKA consortium 2001 | Professional Engineering Publishing Limited ISBN 1 86058 295 8 14 KBE platforms: Knowledge Fusion http://www.UGS.com, accessed 2005-05-24 ICAD http://www.ktiworld.com, accessed 2005-05-24 AML http://www.technosoft.com, accessed 2005-05-24 Design++ http://www.dp.com, accessed 2005-05-24 15 Knowledge driven pre-processing, analysis input definition Bylund, Ida Still to be published by: Luleå University of Technology 16 Generative design and optimisation of the primary structure for a commercial transport aircraft wing. Rondeau, D L, Peck, E A, Williams, A F, Allwright, S E, Shields, L D (British Aerospace, PLC, Woodford, United Kingdom) 1996 | AIAA-1996-4135 NASA, and ISSMO, Symposium on Multidisciplinary Analysis and Optimization, 6th, Bellevue, WA, Sept. 4-6, 1996, Technical Papers. Pt. 2 (A96-38701 10-31) 17 Concepts and applications of finite element analysis Cook, Robert D, Malkus, David S, Plesha, Michael E, Witt, Robert J 2001 | fourth edition John Wiley & Sons, INC ISBN 0-471-35605-0

Related Links Volvo Aero homepage http://www.volvo.com/volvoaero/global/en-gb/ accessed 2005-05-24 Libris, National computerized Library system http://www.libris.kb.se/sok/sok.jsp accessed 2005-05-24 The international Institute of Concurrent Engineering http://www.ceteam.com/communitiesTrack/knowledgebase.asp accessed 2005-05-24 The International Meshing Roundtable http://www.imr.sandia.gov/ accessed 2005-05-24 PLM World newsletter (Product Lifecycle Management, UGS) http://newsletter.plmworld.org/ accessed 2005-05-24

31

http://www.ugs.com/

http://www.ktiworld.com/

http://www.technosoft.com/

http://www.dp.com/

http://www.volvo.com/volvoaero/global/en-gb/

http://www.libris.kb.se/sok/sok.jsp

http://www.ceteam.com/communitiesTrack/knowledgebase.asp

http://www.imr.sandia.gov/

http://newsletter.plmworld.org/


Appendix A - Meshing using KF

Mesh example class # These are definitions of necessary parameters (string parameter) part_name: ug_askCurrentWorkPart(); (string parameter modifiable) scenario_name: "scenario_1"; (string parameter modifiable) scenario_name_str: scenario_name: + ".prt" ; # This parameter creates the scenario in which ug_cae_mesh_shell is fired (boolean parameter modifiable) structures_scen: ug_createNewScenario(scenario_name_str:); ###### Child Rules ####################### (child) Mesh: {

class; ug_child_in_scenario; Target_File_Name; scenario_name_str:; Parameters; { class; mesh_example_scenario_class; master_name; part_name:; }; DemandOrder; {structures_scen:};

};

32


Mesh example scenario class (string parameter) master_name: ; #These parameters will decide if the children creating the meshes will run or not. (boolean parameter) toggle_mesh_1: true; (boolean parameter) toggle_mesh_2: true # So far this is the only way found to find the hostpointer to the sheet body. (list) h_pointer_Mesh_Sheet_Body:

{ref(mesh1_wave_feature:, makename("MESH_SHEET_BODY"))}; #This will find the hostpointers to the two faces in the sheet body. (list parameter) List_of_all_faces: ug_body_askFaces(first(h_pointer_Mesh_Sheet_Body:)); (list parameter) mesh_tag_1: {first(List_of_all_faces:)}; #hostpointer to first face (list parameter) mesh_tag_2: {second(List_of_all_faces:)}; #hostpointer to second face

###### Child Rules ####################### # Wave copying the master link geometry into the scenario (child) mesh1_wave_feature: {

class; ug_extract_body; File_Name; master_name:; Object_Name; "MESH_SHEET_BODY";

}; # This child will attempt to mesh a face on the sheet body. (child) mesh1:{

class; If toggle_mesh_1: = True then ug_cae_mesh_shell else Nulldesign; geometry_tags; mesh_tag_1:; elem_type; quad4; split_quads; true; thickness; 0.3; element_size; 100.0; Material_name; "Aluminum_2014"; DemandOrder; {mesh1_wave_feature:};

}; # This child will attempt to mesh the other face on the sheet body. (child) mesh2:{

class; If toggle_mesh_2: = True then ug_cae_mesh_shell else Nulldesign; geometry_tags; mesh_tag_2:; elem_type; quad4; split_quads; true; thickness; 1.0; element_size; 100.0; Material_name; "Aluminum_2014"; DemandOrder; {mesh1:};

};

33


Appendix B – Programming Nomenclature These sheet bodies and faces in the geometry need to be given these names if it is to be used as input to the Meshing application. Outer Ring Outer ring sheet body OR_B Outer ring middle face OR_M_F Bypass strut Bypass strut Sheet body STR_BY_B Splitter box Splitter box bypass ring sheet body SPLB_BY_B Splitter box bypass ring middle face SPLB_BY_MI_F Splitter box core sheet body SPLB_CO_B Splitter box front torsion ring sheet body SPLB_FR_B Splitter box rear torsion ring sheet body SPLB_RE_B Core strut Core strut sheet body STR_CO_B Support structure Support structure core ring sheet body SUPS_CO_B Support structure cone ring sheet body SUPS_CON_B Support structure front torsion ring sheet body SUPS_FR_FL_F Support structure rear torsion ring sheet body SUPS_RE_FL_F

34


Appendix C - Process description

empty

Set edge density on short & long edges

Find edges with acertain kength

empty

Sort out ”long””circumferential” edges

By reference to sheetbody name

Original list – sortededges

Sort out edges that runsaxially

Compare stert- andenp-point coordinates

empty Set edge density on”axial” edges empty

7

8

9

10

empty

empty

empry

empty

Original list – sortededges Sort ”problem” edges By various position vactors

11empty

empty Set edge density on”problem” edges empty

12empty

empty

Set edge density on short & long edges

Find edges with acertain kength

empty

Sort out ”long””circumferential” edges

By reference to sheetbody name

Original list – sortededges

Sort out edges that runsaxially

Compare stert- andenp-point coordinates

empty Set edge density on”axial” edges empty

7

8

9

10

empty

empty

empry

empty

Original list – sortededges Sort ”problem” edges By various position vactors

11empty

empty Set edge density on”problem” edges empty

12empty

Geometry, conf., edgedensities, mtrl. thicknessprm.

Generate lists ofmeshing parameters

empty

Sheet body name Find all edges in geometry By reference to sheetbody name

empty Sort flange edges Find boundary edges

empty Set edge density onboundary edges empty

Activity MethodIndata1

2

3

4

empty

empty

empry

empty

Outer Ring Scenario Class

Original list – sortededges Sort ”circular” edges Find edges with constant

radius to start and end points5

empty

empty Compare start- andend-point coordinates

empty

Sort out edges thatruns axially

6

Geometry, conf., edgedensities, mtrl. thicknessprm.

Generate lists ofmeshing parameters

empty

Sheet body name Find all edges in geometry By reference to sheetbody name

empty Sort flange edges Find boundary edges

empty Set edge density onboundary edges empty

Activity MethodIndata1

2

3

4

empty

empty

empry

empty

Outer Ring Scenario Class

Original list – sortededges Sort ”circular” edges Find edges with constant

radius to start and end points5

empty

empty Compare start- andend-point coordinates

empty

Sort out edges thatruns axially

6

Sheet body name Reference to sheet body

nameMesh Oter ring sheet body13

empty

Sheet body name Ref

empty

erence to sheet bodynameMesh Oter ring sheet body

13

35


Appendix D.1 – Shell_Mesh_Application_CLASS ####### Public Properties ################ # NOTE 1: All Public defined properties are output. # NOTE 2: property-definitions being parameters are Input. ################## Interface Inputs ######################## (boolean parameter modifiable) Toggle_create_input_deck: false; (boolean parameter modifiable) Toggle_SUPS: false; (boolean parameter modifiable) Toggle_CO: false; (boolean parameter modifiable) Toggle_SPLB: true; (boolean parameter modifiable) Toggle_BY: false; (boolean parameter modifiable) Toggle_OR: false; (list parameter modifiable) Toggle_Present_Modules: {Toggle_SUPS: ,Toggle_SPLB: ,Toggle_OR: ,Toggle_CO: ,Toggle_BY:}; ################################################################# (integer parameter modifiable) type_of_outer_ring: 0; # 1 = Line, else Spline (integer parameter modifiable) no_co_struts: 10; (integer parameter modifiable) no_by_struts: 10; (integer parameter modifiable) ED_co_edges: 2; (integer parameter modifiable) ED_by_edges: 10; (integer parameter modifiable) ED_long_co_intf_edges: 2; (integer parameter modifiable) ED_short_co_intf_edges: 1; (integer parameter modifiable) ED_long_by_intf_edges: 2; (integer parameter modifiable) ED_short_by_intf_edges: 1; (list parameter modifiable) Meshing_Parameters: {type_of_outer_ring: ,no_co_struts: ,no_by_struts: ,ED_co_edges: ,ED_by_edges: ,ED_long_co_intf_edges: ,ED_short_co_intf_edges: ,ED_long_by_intf_edges: ,ED_short_by_intf_edges:}; ################################################################## (integer parameter modifiable) no_SUPS_circumf_elem: 64; (integer parameter modifiable) no_SPLB_circumf_elem: 96; (integer parameter modifiable) no_OR_circumf_elem: 128; (list parameter modifiable) no_circumf_elem: {no_SUPS_circumf_elem: ,no_SPLB_circumf_elem: ,no_OR_circumf_elem:}; ################################################################## (integer parameter modifiable) no_subdivisions: 3; ################################################################## (number parameter modifiable) SUPS_thickness: 2.1; (number parameter modifiable) STR_CO_thickness: 2.1; (number parameter modifiable) SPLB_thickness: 2.1; (number parameter modifiable) STR_BY_thickness: 2.1; (number parameter modifiable) OR_thickness: 2.1; (list parameter modifiable) Thickness_Parameters: {SUPS_thickness:

36


,STR_CO_thickness: ,SPLB_thickness: ,STR_BY_thickness:

###### ###########

l:

PRE><FONT SIZE=-1>

t these properties from external users

Toggle_Present_Modules; Toggle_Present_Modules:;

Parameters:; meters:;

core_bypass_strut; 0;


class; meshing_class;

rs:;

,OR_thickness:};

#################################################

#för interfacet bara. (string parameter modifiable) Overall_material: Aluminium; (integer parameter modifiable) SUPS_material: 2;

; (integer parameter modifiable) STR_CO_material: 2 (integer parameter modifiable) SPLB_material: 2;

; (integer parameter modifiable) STR_BY_material: 2 (integer parameter modifiable) OR_material: 2; (list parameter modifiable) Material_Parameters: {SUPS_material:

,STR_CO_material: ,SPLB_material: ,STR_BY_materia ,OR_material:};

#</PRE></TD></TR></TABLE><BR><BR><H2>Internal procedure</H2>< ####### Private Properties ###############

only be used internally. # NOTE 1: All Internal defined properties should # NOTE 2: The Intent! language does not protec ###### Child Rules ####################### # (Child) subdivide: {

class; MAIN_subdivide_IMC_mid_shell_CLASS; ### List_of_Meshing_Parameters; Meshing_Parameters:;

m:; # List_of_no_circumf_elem; no_circumf_ele# List_of_no_subdivisions; no_subdivisions:;# List_of_Thickness_Parameters; Thickness_# List_of_Material_Parameters; Material_Para# }; (Child) num_core: { class; Number_struts_CLASS; No_of_Struts; no_co_struts:;

# DemandOrder; {subdivide:}; };

(Child) num_bypass: { class; Number_struts_CLASS; No_of_Struts; no_by_struts:;

# DemandOrder; {subdivide:}; }; (Child) mesh: {

Toggle_input_deck; Toggle_create_input_deck:; Toggle_Present_Modules; Toggle_Present_Modules:;

List_of_Meshing_Parameters; Meshing_Paramete List_of_no_circumf_elem; no_circumf_elem:;

List_of_no_subdivisions; no_subdivisions:; List_of_Thickness_Parameters; Thickness_Parameters:;

List_of_Material_Parameters; Material_Parameters:; DemandOrder; {num_core,num_bypass:}; }; # </FONT></PRE></Body></HTML>

37


Appendix D.2 – Meshing_CLASS ####### Public Properties ################

ers are Input.

(string parameter modifiable) scenario_name: "scenario_1"; nario_name: + ".prt" ; reateNewScenario(scenario_name_str:);

################## Interface Inputs ########################

odules: {true,true,true,false,false};

#################################################################

,10 ,1

,1};

List_of_Meshing_Parameters:); # 1 = Line, else Spline ist_of_Meshing_Parameters:);

List_of_Meshing_Parameters:); of_Meshing_Parameters:);

nth(5,List_of_Meshing_Parameters:); 6,List_of_Meshing_Parameters:);

nth(7,List_of_Meshing_Parameters:); ger parameter modifiable) ED_long_by_intf_edges: nth(8,List_of_Meshing_Parameters:);

(integer parameter modifiable) ED_short_by_intf_edges: nth(9,List_of_Meshing_Parameters:);

################################

f_no_circumf_elem: {40 ,60

,80};

SUPS_circumf_elem: first(List_of_no_circumf_elem:); circumf_elem: second(List_of_no_circumf_elem:);

iable) no_OR_circumf_elem: third(List_of_no_circumf_elem:);

##################################################################

able) List_of_no_subdivisions: 5;

####################

rameters: {0.1

(number parameter modifiable) SUPS_thickness: nth(1,List_of_Thickness_Parameters:); CO_thickness: nth(2,List_of_Thickness_Parameters:);

(number parameter modifiable) SPLB_thickness: nth(3,List_of_Thickness_Parameters:); (number parameter modifiable) STR_BY_thickness: nth(4,List_of_Thickness_Parameters:); (number parameter modifiable) OR_thickness: nth(5,List_of_Thickness_Parameters:);

# NOTE 1: All Public defined properties are output. # NOTE 2: property-definitions being paramet (string parameter) part_name: ug_askCurrentWorkPart(); (string parameter modifiable) scenario_name_str: sce (boolean parameter modifiable) structures_scen: ug_c (string parameter modifiable canonical) master_name: ; (boolean parameter modifiable) Toggle_input_deck: false; (list parameter modifiable) Toggle_Present_M (list parameter modifiable) List_of_Meshing_Parameters: {1 ,10 ,10 ,2 ,1 ,1 (integer parameter modifiable) type_of_outer_ring: nth(1, (integer parameter modifiable) no_co_struts: nth(2,L (integer parameter modifiable) no_by_struts: nth(3, (integer parameter modifiable) ED_co_edges: nth(4,List_ (integer parameter modifiable) ED_by_edges: (integer parameter modifiable) ED_long_co_intf_edges: nth( (integer parameter modifiable) ED_short_co_intf_edges: (inte ################################## (list parameter modifiable) List_o (integer parameter modifiable) no_ (integer parameter modifiable) no_SPLB_ (integer parameter modif (integer parameter modifi ############################################## (list parameter modifiable) List_of_Thickness_Pa ,0.1 ,0.1 ,0.1 ,0.1}; (number parameter modifiable) STR_

38


#########

,0.1

_of_Material_Parameters:); of_Material_Parameters:);

ters:);

(integer parameter modifiable) OR_material: nth(5,List_of_Material_Parameters:);

#</PRE></TD></TR></TABLE><BR><BR><H2>Internal procedure</H2><PRE><FONT SIZE=-1>

# NOTE 1: All Internal defined properties should only be used internally. ese properties from external users

(list parameter) List_of_a_SB_in_All_Modules: {"SUPS_FR_B"

,"SPLB_FR_B"

loop

ngth(Toggle_Present_Modules:); :) = true

_Modules:)}; };

###### Child Rules #######################

class; Number_struts_CLASS;


Target_File_Name; scenario_name_str:;

rio_data_CLASS;

core: ,num_bypass:}; };

#########################################################

(list parameter modifiable) List_of_Material_Parameters: {0.1 ,0.1 ,0.1 ,0.1}; (integer parameter modifiable) SUPS_material: nth(1,List (integer parameter modifiable) STR_CO_material: nth(2,List_ (integer parameter modifiable) SPLB_material: nth(3,List_of_Material_Parame (integer parameter modifiable) STR_BY_material: nth(4,List_of_Material_Parameters:); ####### Private Properties ############### # NOTE 2: The Intent! language does not protect th ,"STR_CO_B_1" ,"STR_BY_B_1" ,"OR_B"}; (list parameter) Present_Sheet_Bodies: { for $idx from 1 to le if nth($idx,Toggle_Present_Modules append {nth($idx,List_of_a_SB_in_All (list parameter) List_of_Meshing_Classes: {Vital_ISS_scenario_CLASS ,Vital_Splitter_Box_scenario_CLASS ,Vital_Outer_Ring_scenario_CLASS ,Vital_Core_Strut_scenario_CLASS ,Vital_Bypass_Strut_scenario_CLASS}; (Child) num_core: { No_of_Struts; no_co_struts:; core_bypass_strut; 0; }; (Child) num_bypass: { class; Number_struts_CLASS;

No_of_Struts; no_by_struts:; };

(child) Scenario_data: { class; ug_child_in_scenario; Parameters; { class; Scena }; DemandOrder; {structures_scen:, num_ #+ ug_child_in_scenario creating the structures model See example file example_scenario.dfa for more detail. #-

39


(child list) Meshing_modules: {

Target_File_Name; scenario_name_str:;

resent_Modules:) = True eshing_Classes:)

master_name; part_name:;

}; Quantity; length(List_of_a_SB_in_All_Modules:); #Make sure that the scenario is created and

};

;

class; If Toggle_input_deck: = True then Ansys_Input_deck_CLASS

Dem ndOrder

</FONT></PRE></Body></HTML>

class; ug_child_in_scenario; Parameters; { class; If nth(Child:Index:,Toggle_P then nth(Child:Index:,List_of_M else Nulldesign; Meshing_Param; List_Of_Meshing_Parameters:; no_circumf_elem; List_of_no_circumf_elem:; no_divisions; no_subdivisions:; Thickness_Param; List_Of_Thickness_Parameters:; Material_Param; List_of_Material_Parameters:; #the the geometry exists in the master model DemandOrder; {Scenario_data:}; (child) Ansys_input_deck: { class; ug_child_in_scenario; Target_File_Name; scenario_name_str: Parameters; { else Nulldesign; }; a ; {Meshing_modules:}; }; #

40


Appendix D.3 – Outer_Ring_Scenario_CLASS

being parameters are Input.

##########

#######################

meter modifiable) meshing_param: {1 ,10 ,10

,2 ,1

r_ring: nth(1,meshing_param:); # 1 = Line, else Spline e) no_co_struts: nth(2,meshing_param:);

nth(3,meshing_param:); ges: nth(4,meshing_param:);

eger parameter modifiable) ED_by_edges: nth(5,meshing_param:); (integer parameter modifiable) ED_long_co_intf_edges: nth(6,meshing_param:); (integer parameter modifiable) ED_short_co_intf_edges: nth(7,meshing_param:);

ng_by_intf_edges: nth(8,meshing_param:); (integer parameter modifiable) ED_short_by_intf_edges: nth(9,meshing_param:); ################################################################## (list parameter modifiable) no_circumf_elem: {40 ,60 ,80}; (integer parameter modifiable) no_SUPS_circumf_elem: first(no_circumf_elem:); (integer parameter modifiable) no_SPLB_circumf_elem: second(no_circumf_elem:); (integer parameter modifiable) no_OR_circumf_elem: third(no_circumf_elem:); ################################################################## (integer parameter modifiable) no_divisions: 5; (integer parameter modifiable) no_edges: if type_of_outer_ring: = 1 then no_divisions:+8 else no_divisions:+6; ################################################################## (list parameter modifiable) thickness_param: {0.1 ,0.1 ,0.1 ,0.1 ,0.1}; (number parameter modifiable) SUPS_thickness: nth(1,thickness_param:); (number parameter modifiable) STR_CO_thickness: nth(2,thickness_param:); (number parameter modifiable) SPLB_thickness: nth(3,thickness_param:); (number parameter modifiable) STR_BY_thickness: nth(4,thickness_param:); (number parameter modifiable) OR_thickness: nth(5,thickness_param:); ##################################################################

####### Public Properties ################ # NOTE 1: All Public defined properties are output. # NOTE 2: property-definitions (boolean parameter) toggle_mesh_1: true; (boolean parameter) toggle_mesh_2: false; ################## Interface Inputs ############## (string parameter modifiable canonical) master_name: ; ########################################## (list para ,2 ,10 ,2 ,1 }; (integer parameter modifiable) type_of_oute (integer parameter modifiabl (integer parameter modifiable) no_by_struts: (integer parameter modifiable) ED_co_ed (int (integer parameter modifiable) ED_lo

41


(list parameter modifiable) Material_Param: {"TITANIUM_ALLOY"

,"TITANIUM_ALLOY"};

rial_Param:); ram:);

(integer parameter modifiable) SPLB_material: nth(3,Material_Param:); terial: nth(4,Material_Param:);

(integer parameter modifiable) OR_material: nth(5,Material_Param:);

Internal procedure</H2><PRE><FONT SIZE=-1>

# NOTE 2: The Intent! language does not protect these properties from external users

###################################################### All Edges in Outer Ring #########################

#######################################################

f(mesh1_wave_feature:, makename("OR_B"))};

OR:));

####################### ##############

######################

for $startpoint is ug_curve_askStartpoint(nth($idx,Edges:)); for $endpoint is ug_curve_askEndpoint(nth($idx,Edges:));

(list parameter) FLANGE_EDGES: loop

for $endpoint is ug_curve_askEndpoint(nth($idx,Sort_Circumf_edges:)); for $startp_angle is if localy($startpoint) = 0

else atan(localz($startpoint)/localy($startpoint));

then 90

};

(list parameter) Circumf_edges: setDifference(Sort_Circumf_edges:,FLANGE_EDGES:);

_long_circumf_edges: no_edges:*no_by_struts:*2;

o_short_circumf_edges: 2*no_divisions:*no_by_struts:;

GES: @{

};

,"TITANIUM_ALLOY" ,"TITANIUM_ALLOY"

,"TITANIUM_ALLOY" (integer parameter modifiable) SUPS_material: nth(1,Mate (integer parameter modifiable) STR_CO_material: nth(2,Material_Pa (integer parameter modifiable) STR_BY_ma #</PRE></TD></TR></TABLE><BR><BR><H2>

####### Private Properties ############### # NOTE 1: All Internal defined properties should only be used internally. ######################### ######################### ######################## (list) h_pointer_OR: {re (list parameter) Edges: ug_body_askEdges(first(h_pointer_ ############################################################## ######################### Constant x Edges (x = axial axis) ####### ############################################################### (list parameter) Sort_Circumf_edges: loop { for $idx from 1 to length(Edges:); for $tangent is $endpoint - $startpoint;

if abs(localx($tangent)) < 0.03 append {nth($idx,Edges:)}; }; { for $idx from 1 to length(Sort_Circumf_edges:); for $startpoint is ug_curve_askStartpoint(nth($idx,Sort_Circumf_edges:)); then 90 for $endp_angle is if localy($endpoint) = 0 else atan(localz($endpoint)/localy($endpoint)); if abs($endp_angle-$startp_angle) < 0.03 append {nth($idx,Sort_Circumf_edges:)}; (integer parameter modifiable) no # (integer parameter modifiable) n

(list parameter) LONG_CIRCUMF_ED $sorted_list << vac_sort_curves_by_length(Circumf_edges:); $long_intf_edges << loop { for $idx from 1 to no_long_circumf_edges:; append {nth($idx,$sorted_list)}; };

42


(list parameter) SHORT_CIRCUMF_EDGES: setDifference(Circumf_edges:,long_circumf_edges:);

circumf_elem:/no_by_struts:)+1; es: floor(no_SPLB_circumf_elem:/no_by_struts:);

##########

for $idx from 1 to length(FLANGE_EDGES:); collect vac_setEdgeDensity(nth($idx,FLANGE_EDGES:),1,1,20); };

{

ges:,20); };

for $idx from 1 to length(short_circumf_edges:); collect vac_setEdgeDensity(nth($idx,short_circumf_edges:),1,1,20); };

####################################################################################### ######################### Vital "straight" + intf edges ########################

#

(list parameter) dummy_list: setDifference(Edges:,Sort_Circumf_edges:);

ve_by_distance_to_point(dummy_list:, point(-99999,0,0));

h(sorted_edges:)+1-$idx),sorted_edges:)};

ameter) dummy_intf_edges: setDifference(sorted_edges:,INTERM_EDGES:);

p

x),dummy_intf_edges:)};

ES: loop

d binormal unless the curve is straight where an empty list is returned. ;

:);

###

{

,20);

r $idx from 1 to length(dummy_intf_edges:); collect vac_setEdgeDensity(nth($idx,dummy_intf_edges:),1,ED_long_by_intf_edges:,20);

};

(integer parameter) ED_long_by_circumf_edges: floor(no_SPLB_# (integer parameter) ED_medium_by_circumf_edg ######################### Set Edge Density ################### (list parameter) set_edges_1: loop { (list parameter) set_edges_2: loop for $idx from 1 to length(LONG_CIRCUMF_EDGES:); collect vac_setEdgeDensity(nth($idx,LONG_CIRCUMF_EDGES:),1,ED_long_by_circumf_ed (list parameter) set_edges_3: loop { ###################################################################################### (list parameter) sorted_edges: vac_sort_cur (list parameter) INTERM_EDGES: loop { for $idx from 1 to no_by_struts:*2; append {nth($idx,sorted_edges:),nth((lengt }; (list par # (list parameter) INTERM_EDGES_2: loo# { # for $idx from 1 to no_by_struts:*2; # append {nth($idx,dummy_intf_edges:),nth((length(dummy_intf_edges:)+1-$id# }; (list parameter) INTF_EDG { for $idx from 1 to length(dummy_intf_edges:); #returns a list of normal an for $dummy is ug_curve_askNormalBinormal (nth($idx,dummy_intf_edges:),0) if Empty?($dummy) #returns false (?) if empty append {nth($idx,dummy_intf_edges:)}; }; (list parameter) IN_BETWEEN_EDGES: setDifference(dummy_intf_edges:,INTF_EDGES ######################### Set Edge Density ########################## (list parameter) set_edges_4: loop for $idx from 1 to length(INTERM_EDGES:); collect vac_setEdgeDensity(nth($idx,INTERM_EDGES:),1,2 }; (list parameter) set_edges_5: loop { fo

43


# (list parameter) set_edges_5: loop # {

};

(list parameter) set_edges_6: loop

for $idx from 1 to length(IN_BETWEEN_EDGES:); ($idx,INTERM_EDGES_2:),1,ED_long_by_intf_edges:,20);

;

########################################################## ######################### Make sure Edge densities are set ########################

########################################

(integer parameter) run: @{

_edges_1:

edges_4: ,set_edges_5: ,set_edges_6:

1;

####################################################################################### #

#######################################################################################

parameter) List_of_all_faces: ug_body_askFaces(first(h_pointer_OR:));

for $idx from 1 to length(List_of_all_faces:);

for $normal is unitize($midpoint - point(localx($midpoint),0,0));

z is localz($normal);

then 90 else 180

then atan($z/$y)

(integer parameter) no_ring_faces: no_strut_faces:+6;

t_list_of_angles << flatten(List_of_sorted_angles:);

pend {$el};

# for $idx from 1 to length(INTF_EDGES:); # collect vac_setEdgeDensity(nth($idx,INTF_EDGES:),1,ED_long_by_intf_edges:,20); # ## { ## collect vac_setEdgeDensity(nth# } ############################# ############################################### { set ,set_edges_2: ,set_edges_3: ,set_ # }; }; ######################### Create sectors for Meshing ####################### (list (list parameter) List_of_angles: loop { for $midpoint is vac_mid_point_on_face(nth($idx,List_of_all_faces:)); for $y is localy($normal); for $ for $angle is if $y = 0 then if $z > 0 else if (($y > 0) & ($z > 0)) else if (($y > 0) & ($z <= 0)) then 360 + atan($z/$y) else 180 + atan($z/$y); collect {nth($idx,List_of_all_faces:),$angle}; }; (list parameter) List_of_sorted_angles: vac_sort_list_of_angles(List_of_angles:); (integer parameter) no_strut_faces: (no_divisions:+1); (list parameter) List_of_mesh_tags: @{ $fla $only_hostpointers << loop { for $el in $flat_list_of_angles; if typeCheck($el, HostPointer) ap

44


}; $sorted_sector_1 << loop { for $idx from 1 to no_ring_faces:;

append {nth($idx,$only_hostpointers),nth((length($only_hostpointers)+1-$idx),$only_hostpointers)};

rted_sector_1);

or_1 << $sorted_sector_1 + loop { for $idx2 from 1 to no_strut_faces:; append {nth((length($sorted_list_1)+1-$idx2),$sorted_list_1)}; };

$other_sectors << loop {

_struts:-1); for $sector_list is loop

from 1 to (2*no_ring_faces:+no_strut_faces:); th((($idx3-1)*(2*no_ring_faces:+no_strut_faces:)+$idx4),$sorted_list_2)};

r_list;

l_sectors << {$sector_1}+$other_sectors;

(list parameter) List_of_mesh_tags_flattened: flatten(List_of_mesh_tags:);

(list parameter modifiable) OR_sector_thickness:

{

for $sector is loop

tags_1: loop

ts: by 2; ;

for $idx from 2 to no_by_struts: by 2; append {nth($idx,List_of_mesh_tags:)};

####################################################################################### Child Rules ################################################

#######################################################################################

nk geometry into the scenario

me; master_name:;

}; $sorted_list_1 << setDifference($only_hostpointers,$so $sect $sorted_list_2 << setDifference($only_hostpointers,$sector_1); for $idx3 from 1 to (no_by { for $idx4 append {n }; collect $secto }; $al }; { 0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,0.11,0.12,0.13,0.14,0.15,0.16,0.17,0.18 ,0.19,0.21,0.22,0.23,0.24,0.25,0.26,0.27,0.28,0.29,0.31,0.32,0.33,0.34,0.35}; (list parameter modifiable) Thickness_tags: loop for $idx from 1 to no_by_struts:; { for $idx2 from 1 to (2*no_ring_faces:+no_strut_faces:); append {nth($idx,OR_sector_thickness:)}; }; append $sector; }; (list parameter) mesh_ { for $idx from 1 to no_by_stru append {nth($idx,List_of_mesh_tags:)} }; (list parameter) mesh_tags_2: loop { }; ########################## # Wave copying the master li (child) mesh1_wave_feature: { class; ug_extract_body; File_Na

45


Object_Name; "OR_B"; };

Feature; {mesh1_wave_feature:}; };

(child) Point: {

Position; Point(run:,0,0); feature:};

# Creating a shell mesh

class; ug_cae_mesh_shell;

; split_quads; true;

Material_name; "Aluminum_2014"; DemandOrder; {Point:};

# (child) mesh1_wave_body: { # class; ug_body; # # class; ug_point; DemandOrder; {mesh1_wave_ }; (child) mesh1:{ geometry_tags; h_pointer_OR:; elem_type; quad4 thickness; OR_thickness:; element_size; 50.0; }; # </FONT></PRE></Body></HTML>

46

Documents

Knowledge Driven Preprocessing - Linköping University · Knowledge Driven Preprocessing – Automating mesh generation for static load bearing jet-engine components Abstract Lead