Embed Size (px)
Citation preview
AALTO UNIVERSITY
SCHOOL OF ENGINEERING
DEPARTMENT OF ENGINEERING DESIGN AND PRODUCTION
Petri Seppänen
Application Independent Finite Element Analysis in Digital Design
Thesis submitted in partial fulfillment of the requirements for the degree of
Master of Science in Technology
Espoo, January 23, 2012
Supervisor: Professor (pro tem) Jari Juhanko
Instructor: Petri Makkonen, Ph.D. (Tech.)
Preface
This thesis is conducted as a part of a larger research project “Silicom” in the Aalto University
School of Engineering. The project is sponsored by Tekes (the Finnish Funding Agency for
Technology and Innovation), as the part of the Tekes Digital product process program and
industrial partners.
Great thanks to Janne “the XP coach” Ojala. He has guided me to understand extreme
programming and software development. He taught directly, rolled up his sleeves and taught
by doing, suggested changes in how a practice is implemented, offered ideas to solve a thorny
technical problem, and served as an intermediary between the team and other management.
Thanks also to Jari Juhanko, Petri Makkonen, Kaur Jaakma, Antti Valkonen and Andrea Buda.
Special thanks to Tero, Mikko, Mika, Timo and Kirsi. I am grateful to Pekka, who gave me an
opportunity to work at Aalto University (formerly the Helsinki University of Technology). I also
thank Hanna and Tero for checking the spelling. Thanks also to CSC from software support and
offering CAE programs for this thesis.
The master thesis is dedicated to my mom Mervi and to my departed dad Pekka.
“Programming CAE program to recognize model geometry is like teaching a blind one to paint
the Mona Lisa”
Espoo 23.1.2012
Petri Seppänen
AALTO UNIVERSITY
PO Box 1100, FI-0076 AALTO
http://www.aalto.fi
ABSTRACT OF MASTER´S THESIS
Author: Petri Seppänen
Title: Application Independent Finite Element Analysis in Digital Design
School: School of Engineering
Department: Department of Engineering Design and Production
Professorship: Machine Design Code:Kon-41
Supervisor: Professor (pro tem) Jari Juhanko
Instructor: Petri Makkonen, Ph.D.(Tech.)
This thesis is one part of the Tekes funded Silicom project. Growing demands from customers, tightening legislation and trend for better productivity are setting demand for designers and experts to use better simulation tools (CAE) to re-use simulation data and to integrate different CAE programs work together. The better usability of the simulation data management tools is also researched in the project. The main idea of the project is to research how Finnish industry could better answer these challenges in a digital design of the future.
The thesis focuses how finite element method can be integrated application independently into a digital design. The finite element method is a numerical technique for solving partial differential equations. The finite element method is used for example in structural and durability analysis and thermal calculations in the mechanical engineering field. Digital design means that a product is designed and tested in a digital environment by using simulation programs.
The software vendors are limiting the better usability of the simulation tools, because vendors are offering products which are working well only with products from the same vendor. The main idea of the application independent finite element method is to automate with all possible finite element programs and the integration between different programs is not limited to programs from the same vendor.
The results of this thesis can be used in the automation of the finite element method and in the integration of finite element tool into digital design. Benefits are that the designer can use simulation tools without having a great experience from the simulation tools. Other benefits are that old simulations can be re-used. The main results of the thesis can be summarized as: workflow for FEA integration, Cube development and test environment and application integration framework.
Date: 23.1.2012 Language: English Pages: 72+3
Key words: Agile, automation, FEA, Extreme Programming, Application integration
AALTO-YLIOPISTO
PL 11000, 00076 AALTO
http://www.aalto.fi
DIPLOMITYÖN TIIVISTELMÄ
Tekijä: Petri Seppänen
Työn nimi: Sovellusriippumaton elementtimenetelmä digitaalisessa suunnittelussa
Korkeakoulu: Insinööritieteiden korkeakoulu
Laitos: Koneenrakennustekniikan laitos
Professuuri: Koneensuunnitteluoppi Koodi: Kon-41
Työn valvoja: Ma. professori Jari Juhanko
Työn ohjaaja: Teknologie doktor Petri Makkonen
Tämä diplomityö on tehty osana Tekesin rahoittamaa Silicom-projektia. Kasvavat asiakasvaatimukset, tiukentuva lainsäädäntö sekä trendi vaatia parempaa tuottavuutta ovat asettaneet suunnittelijoille ja asiantuntijoille uusia vaatimuksia, joiden perusteella simulaatiotyökaluja tulisi hyödyntää tehokkaammin. Näitä vaatimuksia ovat esimerkiksi simulaatiodatan uudelleenkäyttö sekä simulaatiotyökalujen integrointi. Projektissa tutkitaan myös simulaatiodatahallintatyökalujen (SDM) tehokkaampaa käyttöä.
Diplomityössä tutkitaan kuinka elementtimenetelmä (FEM) voidaan sovelluksesta riippumatta integroida osaksi digitaalista suunnittelua. Elementtimenetelmä (FEA) on numeraalinen tekniikka osittaisdifferentiaaliyhtälöiden ratkaisemiseen, jota käytetään fysikaalisten ongelmien ja tilanteiden mallintamiseen. Koneenrakennuksessa elementtimenetelmää käytetään esimerkiksi rakenteiden kestävyyden ja luotettavuuden mitoittamisessa. Digitaalisella suunnittelulla tarkoitetaan tuotteen mallintamista ja testausta virtuaalisesti.
Simulaation tehokkaamman hyödyntämisen ongelmaksi on muodostumassa se, että ohjelmistotoimittajat tarjoavat simulaatiotuotteita, jotka toimivat hyvin vain saman tuoteperheen sisällä. Sovellusriippumaton elementtimenetelmällä (FEM) halutaan päästä siihen, että simulaatio voidaan automatisoida kaikilla mahdollisilla elementtimenetelmäohjelmistoilla, jolloin integraatio sekä automatisointi eivät rajoitu vain yhden ohjelmiston tai yhden ohjelmistovalmistajan tuotteisiin.
Diplomityön tuloksia voidaan hyödyntää elementtimenetelmän (FEM) automatisoinnissa ja sen integroinnissa osaksi digitaalista suunnitteluvuota. Tällöin suunnittelija voi hyödyntää simulaatiotyökaluja suunnittelussa ilman suurempaa tietotaitoa niiden käytöstä. Diplomityön tärkeimpiä tuloksia ovat työkaavio elementtimenetelmän integrointiin, Cube kehitys- ja testausympäristö ja sovellusintegroinnin ohjelmistokehys.
Päivämäärä: 23.1.2012 Kieli: englanti Sivumäärä: 72+3
Avainsanat: Agile, automaatio, FEA, Extreme Programming, ohjelmisto integraatio
Table of contest
Preface
List of symbols and abbreviations
Symbols
Abbreviations
1 Introduction .......................................................................................................................... 1
1.1 Background ................................................................................................................... 1
1.2 Research problem ......................................................................................................... 4
1.3 Aims ............................................................................................................................... 4
1.4 Scope of the Research ................................................................................................... 5
1.5 Research methods ......................................................................................................... 5
2 State of the Art Review ......................................................................................................... 6
2.1 Neutral Formats ............................................................................................................ 6
2.2 Application integration framework methods ............................................................... 8
2.2.1 Commercial application integrations .................................................................. 11
2.3 Extensible markup language ....................................................................................... 15
2.3.1 Material properties ............................................................................................. 16
2.3.2 Finite element models ........................................................................................ 17
2.3.3 Result visualization .............................................................................................. 18
2.4 Substructuring ............................................................................................................. 19
2.5 The structure of the Modal neutral file ...................................................................... 24
2.6 Meshing elements ....................................................................................................... 25
2.7 Scripting in Computer Aided Engineering ................................................................... 26
2.7.1 Python ................................................................................................................. 27
2.7.2 Agile ..................................................................................................................... 28
3 Methods .............................................................................................................................. 30
3.1 Development software ............................................................................................... 30
3.1.1 Abaqus FEA .......................................................................................................... 30
3.1.2 Abaqus Python integrated development environment ...................................... 32
3.1.3 Eclipse integrated development environment ................................................... 32
3.2 Development language ............................................................................................... 33
3.3 Development methods ............................................................................................... 33
3.3.1 Framework development method ...................................................................... 33
3.3.2 Agile software development ............................................................................... 34
3.3.3 Test driven development .................................................................................... 36
3.4 Digital design user case ............................................................................................... 37
3.4.1 Component mode generation ............................................................................. 39
3.4.2 Automated structural analysis ............................................................................ 41
3.5 MNF file verification .................................................................................................... 43
3.5.1 Paired t-test ......................................................................................................... 43
4 Results ................................................................................................................................. 45
4.1 User stories for developing FEA integration for digital design ................................... 45
4.2 Cube development and test environment .................................................................. 46
4.3 Workflows for FEA integration .................................................................................... 47
4.3.1 Architecture for FEA integration framework ...................................................... 50
4.3.2 XML vocabulary ................................................................................................... 51
4.4 Digital design user case ............................................................................................... 53
4.4.1 Natural frequencies of modal neutral files ......................................................... 53
4.4.2 Structural analysis ............................................................................................... 56
4.5 Application integration framework ............................................................................. 58
5 Discussion ............................................................................................................................ 62
5.1 User stories for developing FEA integration for digital design ................................... 62
5.2 Cube development and test environment .................................................................. 62
5.3 Workflow for FEA integration ..................................................................................... 62
5.4 Digital design user case ............................................................................................... 63
5.5 Application integration framework ............................................................................. 63
6 Bibliography ........................................................................................................................ 65
Appendix I Example of the unit test. ......................................................................................... 1
Appendix II To-do-list from user stories. ................................................................................... 2
Appendix III Extend vocabulary for FEA XML. ........................................................................... 3
List of symbols and abbreviations
Symbols
σ Stress
u Displacement
Linear transformation between the retained degrees of freedom of the
substructure and the component of displacement under consideration.
Linear transformation between the retained degrees of freedom of the
substructure and the component of stress under consideration.
External load vector
Internal force
Reduced mass matrix
Reduced damping matrix
Reduced stiffness matrix
Virtual work
Nodal force
Natural modes
Statistical dispersion
Expected value
Variance
Arithmetic mean
n Count of the observation
Sample variance
Mass matrix
Eigenvector
Angular frequency
Abbreviations
API Application Programming Interface; A set routines, protocols, and tools that
makes it easier to develop a software application.
CAA V5 Component Application Architecture; An open middleware for product life cycle
management from Dassault Systèmes.
CAD Computer Aided Design; The use of software or other tools to create 2D/3D
geometries.
CAE Computer Aided Engineering; The use of computers accomplishing a broad
range of engineering tasks including design, simulation and analysis.
CAM Computer Aided Manufacturing; A computer software to control machine tools
and related machinery in the manufacturing of workpieces. CAM also refers to
the use of a computer to assistant in all operations of a manufacturing plant,
including planning, management, transportation and storage.
CAx Computer Aided technologies; Referrer Computer Aided applications like CAD,
CAE and CAM.
CFD Computational Fluid Dynamics; A branch of fluid mechanics that uses numerical
methods and algorithms to solve and analyze problems that involve fluid .
CSV Comma-separated values; The simple file format stores tabular data (numbers
and text) in plain-text form.
DOF Degrees Of Freedom; A number of parameters that define the configuration of a
mechanical system.
DOM Document Object Model; A cross platform and language independent
convention for representing and interacting with objects in HTML, XHTML and
XML documents.
DTD Document Type Definition; A set of markup declarations that define a document
type for SGML-family markup languages (SGML, XML, HTML). DTDs were
precursor to XML schema and have a similar function, although different
capabilities.
DSDM Dynamic System Development Method; An Agile project delivery framework,
primarily used as a software development method.
EssUP Essential Unified Process; An improvement for the Rational Unified Process.
FDD Feature Driven Development; An iterative and incremental software
development process.
FEA Finite Element Analysis; Modeling a problem as a partial differential equation or
integral equation and analyzing its numerical solution using finite elements.
FEMML Finite Element Modeling Markup Language; A solution to data interpretation
and application interoperability in the Finite Element Modeling domain.
FMBS Flexible Multi Body Simulation; A multibody system with flexible bodies. Gives
more accurate results from displacement and forces than MBS.
GUI Graphical User Interface; An interface between the user and the program.
IDE Integrated Development Environment; A software application that provides
comprehensive facilities to computer programmers for software development.
IGES Initial Graphics Exchange Specification; A file format which defines a vendor
neutral data format that allows the digital exchange of information among
Computer-aided design systems.
JACAX Just Another Computer Aided X; A Backend solution for automatically execute
CAE processes.
JAMA Japan Automobile Manufacturers Association; A platform for the automakers of
Japan to share technological developments and management practices
LAN Local Area Network; A computer network that interconnects computers in a
limited area such as a home, school or office building.
MATML Materials Markup Languge; MATML is an XML standard intended primarily for
the exchange of materials property information.
MBS Multi Body Simulation; MBS is used to model the dynamic behavior of
interconnected rigids each of which may undergo large translational and
rotational displacements.
MNF Modal Neutral File; A file which contains flexibility information for parts from
FEA code. The flexibility information is used in a dynamic analysis for example in
MSC.ADAMS.
MBSO Manifold Solid B-rep Objects; An solid IGES entity 186.
OOP Object-Oriented Programming; A programming paradigm. It uses objects as data
structures consisting of data fields and methods together with their
interactions.
OpenUP Open Unified Process; A part of the Eclipse Process Framework and an open
source process framework develop within the Eclipse Foundation.
SAX Simple API for XML; An event based sequential access parser API developed by
the XML-DEV mailing list for XML documents.
SBD Simulation Based Design; The Simulation Based can be realized through
implementation and integration of new computer technologies and tools.
Components of SBD are: modeling methods and computational tools, virtual
reality environment, an infrastructure for collaborative engineering and
integration technologies and tools.
SDM Simulation Data Management; The management of simulation data and the
various relationships to related data, including product data and different
design variants.
SGML The Standard Generalized Markup Language (ISO 8879:1986 SGML); is an ISO-
standard technology for defining generalized markup languages for documents.
SPARC Scalable Processor Architecture; A RISC instruction set architecture developed
by Sun Microsystem and introduced in 1987.
STEP Standard for the Exchange of Product model data; An ISO standard (IS0 10303)
for the computer-interpretable representation and exchange of product design
and manufacturing information.
TDD Test-driven development; A software development technique in Extreme
programming.
UML Unified Modeling Language; A standardized general-purpose modeling language
in the field of object-oriented software engineering.
VBA Visual Basic for Application; An implementation of Microsoft’s event-driven
programming language Visual Basic 6 and its associated Integrated
Development Environment, which are built into most Microsoft Office
application.
VBS Visual Basic Scripting; An active scripting language developed by Microsoft that
is modeled on Visual Basic
VDA-FS Verband der Automobilindustrie – Flächenschnittstelle; A CAD data exchange
format for the transfer of surface models from one CAD system to another.
VRML Virtual Reality Modeling Language; A standard file format for representing 3D
dimensional interactive vector graphics, designed particularly with the World
Wide Web.
XP Extreme Programming; The software development methodology which is
intended to improve software quality and responsiveness to changing customer
requirements. It belongs to Agile software development.
XML Extensible Markup Language; A set of rules for encoding document in machine-
readable form. It is defined in the XML 1.0 Specification produced by the W3C.
1
1 Introduction
1.1 Background
The use of engineering simulation techniques to understand and predict the real world
behavior of physical phenomena is widespread across a number of diverse industries. This is
true for simulations involving product performance attributes, manufacturing processes or
fundamental research. These techniques, when used effectively, provide a distinct business
advantage to product manufactures. Techniques replace costly, time-consuming physical
prototyping and testing. While simulation technology is constantly evolving to meet the
demands of designers and engineers, there remains a wide difference in the effectiveness of
simulations to impact product design decisions. [1]
Increasing demands from customers, tightening legislation for better products and demand for
better productivity are creating pressure for experts and designers to automate simulation
tasks, to integrate different Computer Aided Engineering (CAE) programs and to make CAE
simulations more re-usable.
At present engineering products are often developed by geographically and temporally
distributed design teams using heterogeneous CAE software. In this situation, the ability to
share engineering information and simulation re-usability become a key factor for productivity.
[2, p. 1]
Designers, engineers and CAE experts still spend most of their time and effort on manual, labor
intensive tasks [3; 4; 5]:
manually translating data between different programs,
fxing CAD data,
meshing
reworking models,
visualizing, and
storing simulation data to simulation data management (SDM).
An expert usually needs to collect all necessary inputs from different sources in order to
perform his/her task. Thus, simple translators from application A to B (Figure 1) are not
enough to fulfill new requirements for CAE simulation processes. Neutral geometry formats,
for example IGES and STEP, are great formats to transfer a model shape in the term of its
geometry and topology [6;7]. However, these formats are not suited to transfer information
and knowledge, because there is a drop in metadata accessibility level as a result from the
transfer [6; 7].
2
Figure 1: Traditional integration to transfer information between different applications. Neutral and
native geometry formats are used to transfer geometry between programs.
To answer above-mentioned problems, Computer Aided Engineering (CAE) is becoming multi-
disciplinary, as once-separated analysis disciplines and activities begin to merge. Different
solutions with dissimilar philosophies have come to the market from CAE vendors and from
universities. For example, the following are current state of the art solutions (Table 1).
Table 1: Applications to integrate different CAx programs. All the solutions are application integrators
at some level and are used to integrate different CAE processes or CAE programs and to move data
between those programs and on some level, to provide a Graphical User Interface (GUI). The table in
the alphabetical order. [8;3;9;10;11;4;12;13;14;15;5;16]
Program Main purpose
Abaqus Multiphysics
Altair HyperWorks CAE framework
Ansys Workbench CAE framework
CATIA V5 and V6 CAD
Comet Solution Workspace CAE framework
Isight CAE framework
LMS Virtual.Lab CAE framework
modeFrontier CAE framework
Pro/Engineer CAD
SimXpert CAD
SolidWorks CAD
The Silicom project is interested in application integration solutions, whose philosophical idea
is to integrate different CAE programs together and from those programs that are able to build
and manage simulation processes.
Commercial solutions are offering answers to new requirements. However, these application
integration solutions force experts and companies to use specific CAE programs. These CAE
programs are usually from the same vendor, for example SimXpert from MSC.Software
3
supports mainly CAE applications from MSC.Software [17]. The application integrations
programs which fulfill the initial needs of the Silicom project are:
Altair HyperWorks,
Ansys Workbench,
Comet Solution Workspace,
ModeFrontier, and
SimXpert.
The main idea of these solutions is that, the user is able to build simulation process
automation and design optimization solutions more easily, and the manual process of entering
the required data is reduced. These solutions offer ways to create simulation process flows in
order to automate the exploration of design alternatives and to identify optimal performance
parameters [3; 5; 9; 12].
JACAX (Just Another Computer Aided X) application framework arose from the need to have an
application and vendor independent environment to run a digital design user case: a diesel
engine with wanted CAE/CAD applications. The used Applications were Pro/Engineer for the
Computer Aided Design (CAD), Abaqus for the Finite Element analysis (FEA) and ADAMS for the
Multi Body Simulation (MBS). The available integration solutions from CAE vendors would have
restricted the usability of the available CAE applications.
JACAX is a method for application integration and a back end for building CAE processes.
JACAX originates from the Aalto University School of Engineering, Department of Engineering
Design and Production, CAE-group. The main idea of JACAX is to make it possible to run an
automated simulation loop with multi-vendor CAE-programs. It is also possible to integrate
JACAX with Simulation Lifecycle Management (SLM) and Simulation Data Management (SDM)
applications.
The philosophy of JACAX framework is to use neutral standard formats, which are supported in
CAE applications, for example, native and neutral geometry formats to move the model
geometry from CAD to CAE applications. If it is not possible to transfer some data with
standardized formats, this data is transferred by a “sidecar” (Figure 2).
Figure 2: JACAX way to application integration [18, p. 15].
The format of the sidecar is a human and computer readable Extensible Markup Language
(XML). The JACAX´s way to transfer data differs from the traditional integration.
4
The Silicom project is about simulation life cycle management and how simulation processes
are improved. The project had three fields of research, which are Simulation Data
Management (SDM), application integration and production simulation.
The digital design user case was developed as a test bed for SDM and application integration.
The user case is a realistic study environment for developing application integration and to
produce realistic simulation data for SDM. The user case is presented in Figure 3.
Figure 3: The process of the design user case. Excel calculates parameter for the diesel engine.
Pro/Engineering generates geometry and XML for Adams and Abaqus. Abaqus generates MNF files for
Adams and calculated structural analysis from load from Adams.
1.2 Research problem
Different CAE program vendors offer solutions to integrate FEA into the digital design and
automate it (for example SimXpert), but available framework solutions at the market supports
only some programs of the commercial and academic FEA applications [5; 9]. Experts also have
different best practices and procedures to do the same simulation and this limits the usability
of the available solutions, because ready-made applications do not have support to automate
all experts’ best practices.
The Silicom project had a requirement to have an application, a procedure and a vendor
independent solution to automate FEA. The research problem of this thesis is to find a good
way to integrate and automate FEA application independently.
1.3 Aims
This thesis investigates ways to integrate finite element analysis (FEA) application into the
digital design and automate FEA application. The main object of this thesis is to integrate and
automate finite element analysis application independently. To accomplish the main object
and avoiding data losses during the translation from CAD to FEA, XML vocabulary for the
sidecar is needed. This vocabulary is meant for the finite element analysis purposes. The digital
design user case is used for research, demonstration and validation purposes.
5
1.4 Scope of the Research
The research for the application independent FEA and the demonstration is restricted to one
FEA application and one software version, which is Abaqus 6.10. Different FEA applications are
using different programming languages and a time period which is reserved for the master
thesis is too short to research all high end FEA applications and automate them. The same
developed principles and methodologies can be used for other FEA applications as well. The
automation research is restricted to two different tasks from the digital design user case.
These tasks are:
Modal Neutral File (MNF) generation for MSC.Adams.
Import FEA loads from MSC.Adams to Abaqus 6.10 and calculate structural analysis for parts of diesel engine.
1.5 Research methods
The research in this thesis is done as a practical case study by using the Test-Driven
Development. The TDD is a software development technique in the Extreme Programming (XP)
[19, p. 225; 20; 21, p.85]. This method supports fast code prototyping without having heavy
documentation and heavy requirements.
A literature study is done to find a solution to solve the data loses of the neutral formats. This
problem occurs during the translation of data from one CAE program to another. The problem
is solved by using XML and for this the literature study is also done to develop the XML
vocabulary for the sidecar, which is represented as the solution of the data loses.
The developing of the scripts for the automated FEA is started by gathering user stories from
the members of the project. User stories are short descriptions of features the customers
would like to see in the software.
The test environment is developed for testing and validating scripts and processes. XP from
Agile method and the digital design user case are used to develop scripts to automate FEA. The
scripts are tested and validated by using automated unit testing. Unit tests are small, method-
level tests developers write every time they make a change to software to prove the changes
work as expected. [19, p. 206; 20, p. 90]
The literature study is done also to find a solution to the problem of a CAD user. The problem
is about how the CAD user should mark surfaces, points etc. in a way the finite element
analysis application is able to find them and use them. This literature study was done only with
the Abaqus application programming interface.
6
2 State of the Art Review
2.1 Neutral formats
Engineering products are often developed by geographically and temporally distributed design
team using heterogeneous CAx software. The main problems associated with all
computationally assisted data exchange and integration activities can be approached from
multiple points of view depending on the need at hand. Data interpretation varies from a data
source to a data source and this destroys the robustness of interoperability between
applications and data receptacles in general. Integration of CAx system is a major issue for
industry. [22, p. 1; 23, p. 1]. Neutral formats are presented as a solution to reduce
interoperability problems. CAD applications have neutral formats for transferring geometry,
but CAE applications don’t have a similar neutral format [2]. Examples of neutral formats are
IGES, STEP, VDA-FS, STL and ACIS, and examples of native CAD formats are CATIA V5 (.CATpart,
.CATproduct), Parasolid (.x_t, .x_b, .xmt), I-DEAS and PRO/ENGINEER. The complex nature of
engineering data may hinder the vertical integration of engineering applications. The major
problems that prevent the effective integration of CAx systems are [22, p. 3]:
Current CAx systems have been designed for input and output data rather than information.
Current CAx systems tools operate on different levels of abstraction of the mechanical
product.
Many standards such as Standard for the Exchange of Product model data (STEP), the Initial
Graphics Exchange Specification (IGES) and Parasolid have been successful in the transfer of
model shape in terms of its geometry and topology. They are advantageous in geometry data
transformation. Nevertheless these standards are not suited to transfer the context in which it
was generated (information and knowledge). As a result there is a drop in the metadata
(knowledge) accessibility level, even the information level, when transferring from CAD to FEA
(Figure 4). The successful integration cannot be achieved since human interaction is necessary
to rebuild information/knowledge lost in the transfer. [6,7]
Figure 4: Drop in knowledge accessibility level due to the incapability of the data formats, used to
transfer from one process to another, to capture information and knowledge [6].
7
According to [6, 7] data is understood as discrete; data items no inherent structure of
necessary relationship between them. In contrast to data, information is data that is
structured and put into context, so that it is transferable. The immediate value of information
depends on the potential of the user to sort, interpret and integrate it with their experience.
Knowledge goes one step further and implies the combination of information with the user’s
own experiences to create to a capacity for action.
Initial graphics exchange specification (IGES) is a typical example of this standard mainly for 2D
drawing layouts, and supports only data level exchange. The format is the oldest and most
widely used standard for exchanging geometric data [6]. The solid or shell geometry is
presented in an IGES file by a series of surfaces [24, p. 25]. IGES have different appropriate
tailored formats or flavors. Those flavors are [25]:
Standard,
MSBO (Manifold Solid B-rep Objects),
AutoCAD,
SolidWorks, and
JAMA (Japanese Automotive Manufacturer´s Association).
Standard for the exchange of the product model data (STEP, ISO 10303-1 1994) is a standard
for the computer-interpretable representation and an exchange of product data, and is
successful in the transfer of product shape in terms of its geometry and topology [7]. However,
ISO 10303 focuses on the translation of terminologies from one CAD system to another. It does
not attempt to translate the meaning associated with the design from one context to another
[7].
The STEP is a complex standard with huge-sized documents, and was developed as if it was a
database itself, adopting the scalable processor architecture (SPARC) architecture for database
systems. The standard is comprehensive and is made out from very extensive but well-
structured document series. [22, p. 3]
The massive specifications, custom and proprietary related tool availability are its two greatest
disadvantages [22, p. 4]. The portion of ISO 10303 that is used to present three-dimensional
product data are known as AP203 and AP214. These use a boundary representation to
represent a solid, as well other data such as parts and assemblies information [24, p. 27]. Step
is a complete framework for the standard development and implementation. STEP is
composed by a series of standards, called parts, grouped in three main categories [2, p. 7].
Description methods (ISO 10303-10 series) provide a mechanism for defining data models. Part
11 describes an object-oriented data modeling language called EXPRESS. Implementation
methods (ISO 10303-20 series) provide standard implementation techniques for the data
models defined using STEP.
Part 21 describes the STEP file exchange structure, and parts 22 to 29 specify several language
interfaces (C, C++, IDL, JAVA, etc…) to read, write and manipulate data. A few STEP
development tools are available in the market. They can transform EXPRESS data models into a
variety of useful forms, such as C++ code able to read, write, validate and manipulate EXPRESS-
8
defined data stored in Part 21 text files. Data specifications are the data models defined by
STEP, called application protocols. STEP provides data models for different engineering
application: CAD, FEA and CNC. Currently, 25 applications are under development and 13 of
them have reached the status of ISO standard. AP203 “Configuration controlled design”,
dedicated to model CAD data, is widely available in commercial tools. [2, p. 7]
2.2 Application integration framework methods
Application integration framework is an architectural model and an integrated group of
products that provide access and integration of the most existing and new critical corporate
applications [26; 27].
The demand for application integration is driven by the move to process orientation in many
companies. Presently, there is also a trend toward increased inter-organizational cooperation,
exemplified by virtual enterprises and extended supply chain (Figure 5). [27, p.3]
Figure 5: A supply chains that integrates the vendors and customers of a company. [27]
Supporting cross-functional and inter-organized processes put new requirements on the IT-
system. Traditionally, IT-systems have been built up around departments or functions in the
companies. The result has been a “stovepipe like” relation between the functions and the IT-
system (Figure 6).
Every function in the company is supported by its own system or application. When an
increasing number of companies have begun to transform their organization towards a
horizontal and process-oriented way of working, an integration of the IT-system becomes
essential (Figure 6). [27, p.3]
Figure 6: The traditional functional oriented structure with the stovepipe like relation between the
business function ant the IT-systems (left). The process oriented organization also requires integration
of the IT-system (right). [26; 27]
9
Companies that react quickly according to the constantly changing demands of the customers
will have an advantage in the hardening competition. It is essential the IT-systems support
such changes. This means that IT-systems not only have to be integrated, they also need to be
flexible. The integration of distinct IT-systems gives rise to more complex systems. If a system
also has to be flexible, complexity increases even more. Thus, there is a need for methods,
technologies and tools that can handle the complexity. [27]
The main problem here is to make a complex IT-system understandable for different
categories of stakeholders, such as business managers, technical designers, business
operators, and other users. The efficiency and effectiveness of simulation within a workgroup
or enterprise is driven by several factors, including [1]:
Competency of the simulation and the people utilizing it.
Integration, adaption, and acceptance of simulation within standard business processes.
Capture, management, and reuse of the intellectual property resulting from simulation.
The application integration framework is an architectural model and an integrated group that
provide access and integration. The idea of the application integration is to integrate and
automate different CAE applications and make simulation data more re-usable. To handle this
integration of applications in an efficient way, technologies, tools and methodologies are
required.
Integration of application can be supported by different architectures. One architecture for
integration application is a point-to-point where every application is directly connected with
every other application [27, p.4]. The point-to-point is based on the traditional way to transfer
information and geometry (Figure 8). This means that for avoiding data losses, it is necessary
to find a way to transfer also metadata between different programs; CSV-file between
Pro/Engineer and Abaqus for example (Figure 7).
Figure 7: The point- to-point strategy to integrate applications. [26;27]
This application solution could work for a small number of applications, but as the number of
applications increases, the number of connections quickly becomes overwhelming. If the
applications, for example, differ in data formats and communication protocols, the translation
10
and transformation of the messages between the applications will be very complex. The
maintenance problem becomes hard if any of the application changes its format. [27, p.4]
Figure 8: Traditional way to transfer information between different applications. [18]
The main idea of the message broker (Figure 9) is to reduce the number of interfaces by
introducing a central message broker and thereby make it easier to support the interfaces. If
one of the applications changes format, only one connection has to be changed. The message
broker also makes the coordination between different applications easier compared to
forward a message from one application to another. Furthermore, the message broker can
decide what application a message should be sent depending on the content of the message.
The message broker lacks a central mechanism to handle and visualize the whole flow of
processes. For that reason, it is also difficult to automate the processes and change them
swiftly. [26, p. 3; 27, p. 5]
Figure 9: The message broker strategy to integrate applications. [26, p. 3; 27, p. 5]
The process broker (Figure 10) is an extension of the message broker. In addition to handling
the format conversion, the process broker also encapsulates the process logic for connecting
applications. When all process logic resides in one place, it becomes possible to study, analyze,
and change the processes using a graphical interface. This visualization reduces the complexity
and enables different categories of CAx programs to be used in the process. Traditionally the
process logic is spread and embedded in different application, but by separating process and
application logic and collecting all logic in a process broker, all process logic can reside in one
single place. This separation of concerns will provide easier maintenance and greater
flexibility. It will be possible to modify the processes in an easy and dynamic way that is to
change the order of contact between the different applications or to add new application to
the processes. [26, p.4; 27, p.6]
11
Figure 10: The Process broker strategy to integrate applications. [26, p.4; 27, p.6]
The different methods have different benefits and disadvantages and they are suited for
different situations. Red Oak Software Company has identified requirements for application
integration and those are [28]:
ubiquitous access to application data,
non-intrusive access to data,
adaptability to changing requirements,
easily maintained and updated,
works with existing applications, and
works with existing integration systems.
Ubiquitous access to application data means that data resides on many different platforms.
With data currently residing in host-based applications, client-server applications, PC-based
application, Linux-based applications, and web-based applications, integration needs to run
across all of these platforms. In addition, on each of these platforms, the application being
integrated can be an off-the-shelf application, in-house application, or a combination that falls
somewhere in between. Integration efforts need to take all of these into account. In many
cases, there is no easy way to tap directly into the data or logic of the application. There are
many reasons that application may require a non-intrusive access. In some cases, the
technology does not exist or may not be easily available to easily access the underlying logic of
the application. In other cases, advanced resources required to access the underlying logic or
data may not be available or may be too complex or expensive to implement. [28]
2.2.1 Commercial application integrations
There are different application integration solutions with different philosophies from program
vendors. These solutions integrated part modeling and different simulations. Also CAD
programs are offering FEA, MBS and CAM tools. These programs are normally used for
geometry modeling. The commercial application integrations are presented in Table 2.
12
Table 2: Applications to integrate different CAE programs. All the solution are application integrators
at some level and are used to integrate different CAE processes or CAE programs and to move data
between those programs and on some level, to provide a Graphical User Interface (GUI). The available
tools depend on version of the program. The basic version of CATIA provides only CAD.
[8,3,9,10,11,4,13,14,17,16].
Program Main Purpose Tools
Abaqus FEA/Multiphysics CAD, FEA,MBS,CFD,
Visualization
Altair HyperWorks CAE framework
FEA, MBS ,Visualization,
optimization, data
management, process builder
Ansys Workbench CAE framework
FEA,MBS, CFD, Visualization,
optimization, data
management, process builder
CATIA V5 and CATIA V6 CAD CAD, PDM, MBS, FEA,
rendering
Comet Solution Workspace CAE framework Process builder
LMS Virtual.Lab CAE framework CAD,FEA,MBS, optimization
modelFrontier CAE framework process builder
Pro/Engineer CAD CAD,FEA,MBS
SimXpert CAE framework FEA, MBS, Visualization,
process builder
SolidWorks CAD FEA, CAM, MBS, render
The team of the Silicom project is interested in more from application integrations whose
philosophical idea is integrated different programs together and from programs that are able
to build processes and manage those.
These applications are:
Altair HyperWorks,
Ansys Workbench,
Comet Solution Workspace,
modeFrontier, and
SimXpert.
The research in this thesis carried out using the programs, which the author had used and
researched during this thesis. Those programs are:
Ansys Workbench platform, and
LMS Virtual.Lab.
13
The Ansys Workbench Platform is a commercial example from the application integration
framework for an engineering simulation. The disadvantage of this solution is that the platform
supports only products from Ansys. The platform supports integration between Computational
Fluid Dynamics (CFD) and FEM.
The main idea of this solution is a schematic view of the project, which ties together the entire
simulation processes. Projects are represented graphically as connected system in a flow-like
diagram. The advantages of this is that a user can easily understand engineering intent, data
relationships and the state of the simulation [29]. In Figure 11, there is an example of Ansys
Workbench.
Figure 11: Ansys Workbench and project schematic view. [9]
The idea is simple; the user just drags the wanted simulation into the project schematic and
connects wanted simulations to together. The entire process is persistent, changes can be
made to any portion of the analysis and the workbench will manage the execution of the
required applications to update the project automatically [9;29].
Ansys Workbench scripting is based on Python scripting language and it is also integrated with
the .NET Framework, which provides for example Microsoft Excel to access workbench
parameters [29]. Ansys workbench offers the ability to record the actions that the user
performs via the GUI.
From the Project Schematic, the user can interact with applications that are native to Ansys
Workbench, and the user can launch applications that are data-integrated. Data-integrated
applications are created independently of the Ansys workbench framework but have been
extended so they can be driven by the Project Schematic and share key data and parameters
with Ansys Workbench and Ansys Workbench-enabled applications. Data integrated
applications do not fully support ANSYS Workbench scripting, most of those have their own
native scripting language which is accessible through the Ansys Workbench scripting interface
(Table 3).
14
Table 3: Ansys scripting supports for data-integrated application. [29]
Data-integrated Application Native Scripting Language
Mechanical APDL APDL
Mechanical Jscript
CFX CCL
Fluent Scheme
AQWA Jscript
AUTODYN Not Available
CFD-Post CCL
Fe Modeler Jscript
DesignModeler Jscript
Meshing Jscript
POLYFLOW Not Available
IcePak Not Available
SimXpert is a similar product like Ansys Workbench platform; it also integrates CAD programs
CATIA and Pro/Engineer [17]. Another application integration program is LMS Virtual.Lab. The
LMS Virtual.Lab is an integrated suite of 3D FE and multibody modeling software which
simulates and optimizes the performance of mechanical systems for structural integrity, noise
and vibration, system dynamics and durability [13]. It is based on Component Application
Architecture (CAA V5), the open middleware for product life cycle management from Dassault
Systèmes. [30]
The LMS Virtual.Lab program offers modeling environment, which integrate all the required
model creation, meshing and multidisciplinary simulation capabilities. This solution offers
interfaces with CAD programs and makes it possible to exchange models, data and results
between different simulation and testing disciplines. It also eliminates unnecessary data
transfer and file translation. LMS Virtual.Lab removes the barrier between CAD, CAE and real-
life testing. The example of the GUI of the LMS Virtual.Lab is presented in Figure 12. LMS
Virtual.Lab has automation and customization capabilities, such as: journaling, macros and
scripting. [30]
15
Figure 12: LMS Virtual.Lab. The program is simulating combustion loads, hydrodynamic bearings and
Flexible engine block is modeled in this simulation. [31]
2.3 Extensible markup language
Extensible Markup Language (XML) is used in the FEM domain in many ways, as an input and
an output file, to define material properties and as a method for exchanging data between
different FEM programs. The Abaqus interface for Moldflow for example uses XML to move
results data from Moldflow to Abaqus [32].
XML is a modern system for annotating a text in a way that is syntactically distinguishable from
that text, for example structural markers such as XML tags. XML was developed by the Word
Wide Web Consortium and this consortium has recommended that XML is used as a
representation of the electronic information [33]. Several schema languages are available to
define the structure of XML files. The most used are document type definition (DTD) and XML
schema. XML standards are presented at the Table 4.
Table 4: XML standards and technologies. [2, p. 8]
Purpose Standard or technology
Authoring, structuring and validating DTDs,XML schema, Relax, Schematron
Transforming XSLT
Formatting and publishing CSS,DSSSL, XSL-FO, XHTML
Searching XPath, XPointer, XQuery
Including and linking Xlnclude, XLink, XBase
Programming SAX, DOM
Associating RDF,XTM
Nowadays many application programming interfaces (APIs) have been developed to process
XML data and several schema systems exist to aid the definition of XML-based languages [34].
The main purpose of XML was to simplify Standard Generalized Markup Language (SGML) by
focusing on documents on the internet. XML is based on SGML-language, but it is still simpler
16
and have stricter rules. XML remains a meta-language like SGML, allowing users to create any
tags needed (hence "extensible" and then describing those tags and their permitted uses). [33]
XML is designed to make it easy to interchange data over the Internet Local Area Networks
(LAN). The current XML specification is 36 pages long of which 26 pages are important, others
include the list of contributors. [22, p. 7]. XML has many advantages [35, p. 7; 36, p. 7-8, 52-
53]:
universal standard format for data interchange and exchange,
simultaneous semantic and syntactic encapsulation,
human and machine readable,
easy to parse,
possible to validate,
extensible,
hierarchical structure,
bring multiple files together to form compound documents,
flexible enough to be able to describe any logical text structure, whether it be a form, memo, letter, report, book, encyclopedia, dictionary or database,
as a database format, XML is self-describing (the markup describes the data), it is portable, and it can describe data in tree or graph structures,
for XML exist many free writers and readers, like Document Object Model (DOM) and Simple Api for XML (SAX),
easy implementation for programming languages, and
XML standard (ISO) is available for free.
The basic rules of XML are easily defined. A logical document component either begins with a
start tag and ends with a matching end tag or consists of only of an empty element tag. The
characters between the start and the end tags, if any, are the element's content, and may
contain markup, including other elements, which are called child elements. An example of an
element is:
<Greeting> Hello, world. </Greeting> <Greeting/> (empty element)
A markup construct consisting of a name/value pair that exists within a start tag or an empty
element tag. The attribute is a key value which clarifies the element. An example of an
attribute is:
<JACAX version=”0.0”></JACAX>
XML documents may begin by declaring some information about themselves, as in the
following example:
<?xml version=”1.0” encoding=”utf-8” standalone=”yes”?>
2.3.1 Material properties
The XML is very useful when material properties are moved from internet databases to finite
element applications. The reasons for that are [37]:
17
Material models and material databases are very complex, this means that there is a need for to easily expand or decrease the file of the materials.
Easily human readable. The simplicity is based on the finite sets of tags, whose names are common material terminology.
XML enables communities, such as material scientists and engineers, to define domain-specific tags (FEM, MBS, CFD) and document structure easily.
Materials can be represented independent of definitions of different domains and applications, therefore every program has a different way how material data is represented and how the program uses it.
The Matweb online databases for example provides and supports material data on the XML
format. At this point, the officially supported programs are [38, 39, 40, 41]:
SpaceClaim,
Autodesk´s simulation,
ETBX, and
Ansys.
An XML-language is available for transferring material data to finite element programs. This
language is MatML. The current version of MatML is 3.0. The most important attribute of the
MatML development effort was the inclusion of a broad range of input from the materials
community. These individuals and groups represented private industry, and government
laboratories. [42, 43]
Many material database applications are using MatML language to move material data from
database to the FEM program for example from Matweb to Ansys. Commercial Ansys is one of
the major programs in FEM-domain which uses MatML. There are many applications that use
MatML to deliver material information, for example [42]:
ACI Application to MatWeb Material Information Downloads,
Granta Design Application of MatML,
Granta Design Application of MatML for NIST MSEL,
Laboratory Test Equipment Application of MatML, and
ASM/MSC Application for Publication Development.
2.3.2 Finite element models
The Finite Element Modeling Language (femML) effort is addressing the problems of data
interpretation and application interoperability in the finite element modeling domain. This is
achieved through the development of an extensible markup language (XML) for finite element
model data that will permit the storage, transmission, and processing of finite element
modeling data distributed via the World-Wide Web and related infrastructure technologies .
[22, p. 1]
The femML is developed by members of the Composite Materials and Structures group at the
Naval Research Laboratory and the International Science and Technology Outreach Society in
the year 2000. There are two version available (1.02 and version 2.99b. [44]
18
The main aspects of the finite element definition have been used as archetypes for defining
the XML element taxonomy definitions. Namely, the geometry, the material, and the loading
aspects of a structural component specification are used to define the first level elements of
the associated Document Type Definition (DTD). The element list has been amended with a
behavior element specification that represents the solution data to be exchanged or visualized
[22, p. 16]. The Unified Modeling Language (UML) of the femML is presented in Figure 13.
Figure 13: UML representation of the two levels of femML DTD structure. [22, p.16]
The header element ensures the transport mechanism of the meta-data. The material element
is responsible for the material properties. The nodeset is the element that carries the nodal
geometry information of the model and the elementset carries the elemental information of
the model from the 3D geometrical point of view. The loadcase element carries the loads and
boundary conditions on a nodal basis. The resultcase includes results data (i.e. displacement,
stresses, strain, energies and other scalar, vector or tensor component quantities associated
with the nodes) [22, p. 16].
2.3.3 Result visualization
XML is very suitable for the visualization of results, the reasons are:
file sizes are smaller than in normal results file formats, and
it is possible to open the results almost everywhere and they can be used in common business applications, such as email messages, web pages, word processing documents, and presentations.
In a commercial FEM program Abaqus, it is possible to export a model of an Abaqus/CAE
session to 3D XML file (for example). Two well-known XML-based lightweight representation
formats are X3D and 3D XML [45, p. 2-3].
X3D is developed by the Web3D Consortium as a major upgrade from VRML (the Virtual
Reality Modeling Language). The basic of the X3D run-time environment is a scene graph. The
scene graph consists of several nodes in a hierarchical structure, with shape nodes
representing the objects themselves, and transforms nodes describing the spatial positions of
the objects. The nodes in X3D are represented using XML so as to take the full advantages of
19
the potential of XML on the internet. X3D has become a free, ISO-ratified format to provide
long-term stability for Web3D content and application. [45, p.2]
3D XML is a lightweight and standard XML-based format developed by Dassault Systèmes for
encoding three-dimensional images and data. The format is open and extendable, allowing
three-dimensional graphics to be easily shared and integrated into existing applications and
processes. 3D XML files can be many times smaller than typical model database files. The 3D
XML Player from Dassault Systèmes is required to view 3D XML files or to integrate them into
other business applications. [46, p.3, 45]
3D XML uses open XML schematics to commutate the product geometry, the product
structure, and graphical display properties. Thus, it can be read, written and enriched by
standard tools. 3D XML Player extends 3D XML beyond traditional Product Lifecycle
Management applications, offering integration with Microsoft Office applications and the
internet Explorer browser, or working as a standalone application. [46, p.3]
2.4 Substructuring
In order to provide a concrete example of the application integration strategy proposed in this
thesis; a substructuring script has been implemented and used as example for the exchange of
data between CAD, FEA and MBS domain.
ADAMS uses Modal Neutral Files (MNF) for the Flexible Multibody Simulation (FMBS) and one
part of the MNF file generation process is substructure generation. In this processes Abaqus
models are created for flexible components of the MSC.ADAMS model, and each component is
modeled as an Abaqus substructures [47, p. 11, 48].
Substructuring is a method to divide the geometry to a partitioned block, where the master
features represent the interface nodes. The slave nodes inside partition can be as linear
presentation of the master modes behavior. By this the system can be reduced. This means
that for example connecting rod is implemented as a flexible body that can interact with the
rest of the model via the interface nodes (Figure 14).[47, p.5; 48, 49, p.8]
20
Figure 14: Example of interface nodes and inner nodes of the connection rod. Interface nodes are
coupled to inner nodes.
In the Finite Element literature substructures are also referred to as superelements and both
terms are used interchangeably [48]. Substructures have many advantages [47, p. 9; 48; 49, p.
12-24]:
System matrices (stiffness, mass) are small as a result of substructuring. Subsequent to the creation of the substructure, only the retained degrees of freedom and the associated reduced stiffness (and mass) matrix are used in the analysis until it is necessary to recover the solution internal to the substructure.
Efficiency is improved when the same substructure is used multiple times. The stiffness calculation and substructure reduction are done only once; however, the substructure itself can be used many times, resulting in a significant savings in computational effort.
Substructuring can isolate possible changes outside substructures to save time during reanalysis. During the design process large portions of the structure will often remain unchanged; these portions can be isolated in a substructure to save the computational effort involved in forming the stiffness of that part of the structure.
In a problem with local nonlinearities, such as a model that includes interfaces with a possible separation or a contact, the iterations to resolve these local nonlinearities can be made on a very much reduced number of degrees of freedom if the substructure capability is used to condense the model down to just those degrees of freedom involved in the local nonlinearity.
Substructuring provides a systematic approach to complex analyses. The design process often begins with independent analyses of naturally occurring substructures. Therefore, it is efficient to perform the final design analysis with the use of substructure data obtained during these independent analyses.
21
Substructure libraries allow analysts to share substructures. In large design projects large groups of engineers must often conduct analyses using the same structures. Substructure libraries provide a clean and simple way of sharing structural information
Many practical structures are so large and complex that a finite element model of the complete structure places excessive demands on available computational resources. Such a large linear problem can be solved by building the model, substructure by substructure, and stacking these level by level until the whole structure is complete and then recovering the displacements and stresses locally, as required.
The theory of the substructuring analysis in this thesis is based on Abaqus 6.11 Theory Manual
chapter 2.14.1 Substructuring and substructure analysis. [50]
In Abaqus/Standard the response within a substructure, once it has been reduced to a
substructure, is considered a linear perturbation about the state of the substructure at the
time it is made into a substructure. The substructure is in equilibrium with stresses ,
displacements , and other state variables . The total value of displacement or stress
components in within the substructure is presented in equations.
[ ]{ }, and [1]
[ ]{ }, [2]
where and
are linear transformations between the retained degrees of freedom of the
substructure and the component of displacement or stress under consideration. The
substructure must be in a self-equilibrating state when it is made into a substructure. Since the
purpose of the substructuring technique is to have the substructure contributes terms only to
the retained degrees of freedom. Thus, is external load vector formed from the nonzero
substructure load cases and internal force as a sum of linear translations of the retained
variables and their velocities and accelerations (equations). is the reduced mass matrix for
the substructure, is its reduced damping matrix and is its reduced stiffness. These
matrices connect the retained degrees of freedom only
{ } [ ]{ } [ ]{ } [ ]{ }. [3]
The reduced stiffness matrix is easily derived when only static response is considered. Since
the response of a substructure is entirely linear, its contribution to the virtual work equation
for the model of which it is a part is presented
[ ] {
} [
] {
} , [4]
where and are consistent nodal forces applied to the substructure during its loading
as a substructure and its K tangent stiffness matrix
[ ] [
] [5]
22
Since the internal degrees of freedom in the substructure
, appear only within the substructure, the equilibrium equations conjugate to in the
contribution to the virtual work equation
{ } [ ]{ } [ ]{ } . [6]
These equations can be rewritten to define as in
{ } [ ] { } [ ]{ } . [7]
The substructure’s contribution to the static equilibrium equations is presented as
[ ] { } [ ][ ] { } [ ] [ ][ ] [ ] { } [8]
Thus, for static analysis the substructure’s reduced stiffness is presented at equation 9.
[ ] [ ] [ ][ ] [ ] [9]
and the contribution of the substructure load cases applied to the substructure is the load
vector
{ } { } [ ][ ] { } . [10]
The static modes defined in an equation may not be sufficient to define the dynamic response
of the substructure accurately. To substructure is augmented some generalized degree of
freedom, associated with natural modes of the substructure. The simplest such approach is
to extract some natural modes from the substructure with all retained degrees of freedom
constrained, so that equation is augmented in equation 11.
The basic idea of the dynamic mode addition is that substructures eigenmode amplitudes
become additional degrees of freedom at the usage level. Dynamic modes retained in the
substructures can be calculated in the frequency extraction procedure with any reasonable
boundary conditions. The used method is Craig-Bampton method (fixed-interface eigenmodes)
[48, p. 72]. In the fixed-interface eigenmodes dynamic modes are generated with all retained
degrees of freedom constrained. The Craig-Bampton method is also known as the component
mode synthesis method [50, p. 1].
{ } [ ] { } [ ]{ } { } [11]
with the variation
{ } [ ] [ ]{ } { } [12]
and the time derivatives
{ } [ ] [ ]{ } { } [13]
{ } [ ] [ ]{ } { } . [14]
23
The eigenmodes of the substructure of are { } , obtained with all retained degrees of
freedom constrained, and are the generalized displacements.The contribution of the
substructure to the virtual work equation for the dynamic case is
{ } {
} [
] {
} [
] {
} [
] {
} [15]
Where M is the substructure´s matrix
[ ] [
] , [16]
C is damping matrix
[ ] [
] , and [17]
P is the nodal force vector in the substructure
{ } {
} . [18]
With the assumed dynamic response within the substructure, the internal degrees of freedom
in this contribution ( and its time derivatives) can be transformed to the retained degrees
of freedom and the normal mode amplitudes, reducing to the system to equation 19.
[ ] [ ] { } [ ] [ ][ ] {
} [ ] [ ][ ] {
} [ ] [ ][ ] {
} [19]
where T is
[ ] [[ ] [ ]
[ ] [ ] [ ]] . [20]
In the equation is the matrix of eigenvectors, is the vector of generalized of freedom is
a unit matrix, and 0 is a null matrix.
Models are modeled as Abaqus substructure at Abaqus and converted to the MNF file for
ADAMS by using the Abaqus Interface for MSC.ADAMS. The raw Craig-Bampton modal basis
has certain deficiencies that make it unsuitable for direct use in dynamic system simulation.
[51] These are:
Embedded in the Craig-Bampton constraing modes are six rigig degrees of freedom
(DOF) which must be eliminated before the Adams analysis because used multibody-
simulation program Adams provides its own large-motion rigid body DOF
The Craig-Bampton constrain modes are the results of the static condensation; these
modes do not advertise the dynamic frequency content.
24
Craig-Bampton constraint modes cannot be disabled because it would be equivalent to
applying a constrain on the system.
Natural frequency extraction is needed for MNF file generation. The frequency
extraction performs an eigenvalue extraction to calculate the natural frequencies and
the corresponding mode shapes of a system. The eigenvalue problem for the natural
frequencies of an undamped finite element model (Equation 21) [52]. Where is
the mass matrix, is the stiffness matrix and is the eigenvector (the mode of
vibration).M and N are degrees of freedom. When is positive definite, all
eigenvalues are positive. Rigid body modes and instabilities cause to be
indefinite. Rigid body modes produce zero eigenvalues.
[21]
2.5 The structure of the Modal neutral file
The Abaqus interface for MSC.ADAMS translates data from one or more Abaqus results (.fil)
files and generates a modal neutral file (MNF). Depending on the context of the results file and
the translation parameters, the Abaqus interface for MSC.ADAMS creates a modal file
containing the data block show in Table 5. [48].
Table 5: Modal neutral file contest. [48]
Block Number Contest
1 Version code
2 Header
3 Content summary
4 Nodal coordinates
5 <Not used>
6 Global mass properties
7 Eigenvalues
8 Mode shapes
9 Nodal masses
10 Nodal inertias
11 Units
12 Generalized stiffness matrix
13 Generalized mass matrix
14 Element faces
15 Generalized damping
16 Mode shape transformation
17 interface nodes
18 Modal stress
19 to 26 Inertia invariants
27 Modal preload
28 modal loads
29 Modal strain
25
ADAMS program requires that the user define the units used in the component model, while
Abaqus does not. Therefore, during the creation of the modal neutral file the user must
declare explicitly the units used in the model. The default units system is mks. The valid units
system for the units option are in Table 6 [48].
Table 6: Valid units systems. [ 47]
Units Systen Length Units Mass Units Force Units Time Units
mks meters kilograms newtons seconds
mmks millimeters kilograms newtons seconds
cgs centimeters grams dyne seconds
ips inches pound-mass pound-force seconds
2.6 Meshing elements
In finite element analysis, models (CAD models) have to be represented as finite element
meshes. Most authors agree that the most time consuming part of undertaking a finite
element analysis is the creation of the analysis model, which is still based mostly on the user’s
experience [53 p. 1]. Otherwise, the generated numerical model might be unreasonable and
FEA would produce big inaccuracy, possible giving incorrect results.
There are two approaches to create mesh. The bottom-up approach is a traditional approach is
to construct mesh to create geometry; other approach is top-down; where mesh is done
directly on the geometry. Bottom-up meshing is a manual, incremental meshing process that
allows you to build a hexahedral mesh in any solid region.[24]
The used meshing methodology is top-down. Top-down meshing generates mesh by working
down from the geometry of the part or region to the individual mesh nodes and elements. The
resulting mesh exactly conforms to the original geometry. The rigid conformance to geometry
makes top-down meshing predominantly an automated process. In some cases top-down
methods may not allow you to mesh portions of a complex part with the desired type of
elements. [24]
The degrees of freedom (DOF) are the fundamental variables calculated during the analysis.
Displacements of other degrees of freedom are calculated at the nodes of the element. At any
other point in the element, the displacements are obtained by interpolating from the nodal
displacements. Usually, the interpolation order is determined by the number of nodes used in
the element. The available element shape for one-dimensional geometry is presented In Figure
15 [54].
26
Figure 15: Elements that have nodes only at their corners, such as the left line, use linear interpolation
in each direction and are often called linear element or first-oder elements. [54]
One-dimensional elements are used in structural analysis for example. These elements can be
used in two- or three-dimensional space to transmit loads or fluxes along the length of the
element. Two-dimensional elements are used for example in structural analysis (Figure 16).
[54]
Figure 16: Two-dimensional elements; Elements with midside nodes, such as the right triangle or
quadrilateral, use quadratic interpolation and are often called quadratic elements or second-order
elements. [54, 55]
The element shapes for three-dimensional elements are defined in the global X, Y, and Z space.
These elements are used when the geometry and/or the applied loading are too complex for
any other element type with fewer spatial dimensions. The three-dimensional elements are
used in this thesis (Figure 17). [54]
Figure 17: Three-dimensional elements. [54, 56]
2.7 Scripting in Computer Aided Engineering
One of the key elements of the proposed approach for solving application integration consists
in using the native scripting language of the CAE software in order to export the necessary
information.
27
2.7.1 Python
Python is an open source, general-purpose and high-level programming language (scripting
language). The reference implementation of Python (CPython) is free and open source
software and has a community-based development model, as do all or nearly all of its
alternative implementations. CPython is managed by the non-profit Python Software
Foundation. The mainstream Python implementation, known as CPython, is written in C. [57]
The high-level programming language means a programming language with strong abstraction
from the details of the computer. Scripting languages are designed for the effective integration
of components written in other computer languages. A scripting language is a high level
language that executes more operations per language statement that a language such as C++.
A scripting language does not require compilation leading to fast prototyping. Differences
between a scripting language and a programming language are compared in the table 7. [58, p.
24-25]
Table 7: A Comparison of different computer languages. [58, p.25 ]
Scripting Language Programming language
High Level Low Level
Weakly Typed Strongly Typed
Rapid Development Rapid Run-Time
Easy to Reuse Code Difficult to Reuse Code
The high-level programming language means a programming language with strong abstraction
from the details of the computer. High-level programming languages use natural language
elements, are easier to use and are more portable across platforms. Different computer
languages are compared in Figure 18.
Figure 18: A Comparison of different computer languages . [58, p.25 ]
28
2.7.2 Agile
Agile software development is a group of software development methodologies based on
iterative and incremental development. There are many specific agile methods, which are [59]:
Agile modeling,
Agile Unified Process (AUP),
Dynamic Systems Development Method (DSDM),
Essential Unified Process (EssUP),
Extreme Programming (XP),
Feature Driven Development (FDD),
Open Unified Process (OpenUP),
Scrum, and
Velocity tracking.
The Agile manifesto introduced the term in 2001.
Extreme Programming (XP) is a software development methodology which is intended to
improve software quality. The methodology takes its name from the idea that the beneficial
elements of traditional software engineering practices are taken to “extreme” levels, on the
theory that some is good, more is better [60]. As a type of agile software development, it
advocates frequent workable releases in short development cycles. Other essential parts of
the XP are [61; 62]:
programming in pairs,
doing extensive code review,
unit test of all code,
avoiding programming of features until they are actually needed, and
simplicity and clarity in code.
The XP is explained as a software development discipline that organizes people to produce
higher quality software more productively, it attempts to reduce the cost of changes in
requirements by having multiple short development cycles, rather than one longs. XP
describes four basic activities are that are performed within the software development process
[62]:
coding,
testing,
listening, and
designing.
The XP argue that the only truly important of the good system development process is
workable code, without the code there is no working product (Figure 19). Coding can also be
used to figure the most suitable solution. The code is used as a way to transfer information
and solution to the problems between programmers.
29
Figure 19: Extreme programming project flow chart. User Stories defines requirements and
requirements for the acceptance test. After required is a release plan released. After this starts coding
and iteration for the better code. When the code is ready, is have to pass the acceptance test, this
means the code get a customer approval and the customer starts to use the code. [62]
The XP approach to testing is that a little testing can eliminate a few flaws; a lot of testing can
eliminate many more flaws. A unit test determines whether a given feature works as intended.
A programmer writes as many automated tests as they can think of that might “break” the
code. If all test run successfully,the coding is complete. Every piece of code that is written is
tested before moving on to the next feature. Acceptance test verifies that the requirements as
understood by the programmers satisfy the customer´s actual requirements. Acceptance test
are run often and the results are published.
XP has been described as having 12 practices, grouped into five areas [63] shown in Table 8 :
Fine scale
feedback
Continuous
process
Shared
understanding Coding Testing
Pair
programming
Continuous
integration
Coding
standards
The customer is
always available
All code have
Unit test
Planning game Refactoring Collective code
ownership
Code the unit
test first
All code must
past all Unit test
Test driven
development Small releases Simple design
Only one pair
integrates code
at a time
System
metaphor
Leave
optimization till
last
No overtime
30
3 Methods
3.1 Development software
Abaqus FEA was chosen for the development software in this thesis. The chosen development
software defines used programming language, which is Python. The other programs use
different programming languages (Table 9).
Table 8: Programming or scripting languages for FEA applications.
Finite Element program Language
Abaqus CPython, C, C++, FORTRAN
Ansys IronPython, APDL, Jscript, CCL, Scheme
LMS Virtual.Lab VBA, VBS
Nastran/Patran PCL
3.1.1 Abaqus FEA
Abaqus is a suite of engineering simulation programs based on the finite element method.
Abaqus consist of three main analysis products: Abaqus/Standard, Abaqus/Explicit, and
Abaqus/CFD. Several add-on analysis options are available for example the Abaqus Interface
for MSC.ADAMS. The software also includes translators that convert geometry from third-
party CAD systems, convert entities from third-party preprocessors to input for Abaqus
analyses, and convert output from Abaqus analyses to entities for third-party postprocessors.
The relationship between these products is shown in Figure 20. [57]
Figure 20 Abaqus products. [58]
Abaqus/CAE (Complete Abaqus Environment) is a graphical environment for Abaqus. It allows
models to be created quickly and easily by producing or importing the geometry of the
structure to be analyzed and decomposing the geometry into meshable regions. Physical and
material properties can be assigned to the geometry, together with load and boundary
conditions. Once the model is complete, Abaqus/CAE can submit, monitor, and control the
31
analysis jobs. Abaqus/Viewer is a subset of Abaqus/CAE that contains the postprocessing
capabilities of the Visualization module. [57]
The Abaqus/CAE, Abaqus interface for MSC.ADAMS and Abaqus/Viewer are the automated
products in this thesis. When a model is created by the user in the Abaqus/CAE graphical user
interface (GUI), commands are issued internally by Abaqus/CAE after every operation. GUI
generates commands in an object-oriented programming language called Python. The
commands issued by the GUI are sent to the Abaqus/CAE kernel. The kernel is the brains
behind Abaqus/CAE. The GUI is the interface between the user and the kernel (Figure 21). [57]
The Abaqus Scripting Interface allows the user to bypass the Abaqus/CAE GUI and
communicate directly with the kernel. A file containing Abaqus Scripting Interface commands
is called a script.
Figure 21: Abaqus architecture. Abaqus has three processes kernel, GUI, and analysis. The GUI and
command line interpreter execute commands in different namespaces of the kernel interpreter. This
avoids a user overwriting a variable required the application. Messages from the Abaqus analysis are
processed using the Job Monitoring API. The Abaqus GUI uses an internal Python interpreter. This is
not exposed to the user but can be used for GUI customization. [57]
The Abaqus Scripting Interface (ASI) is an Application Programming Interface (API) to the
models and data used by Abaqus and it is an extension of the Python object-oriented
programming language. The ASI can access the Abaqus/CAE and Abaqus/Viewer and it can be
used to [57]:
create and modify the components of an Abaqus model, such as part, material, loads and steps,
create, modify, and submit Abaqus analysis jobs,
read from and write to an Abaqus output database,
view the results of an analysis,.
customize Abaqus environment via the Version 6 environment file (abaqus_v6.env),
perform parameter studies, and
create Abaqus Plug-ins.
32
3.1.2 Abaqus Python integrated development environment
Abaqus PDE is a built-in Python integrated development environment (IDE) in Figure 22. PDE
provides an alternative to using a shell command line and a text editor for developing and/or
running code. PDE also provides text editing (syntax coloring), debugger and more IDE tools.
Abaqus PDE is accessible from within Abaqus/CAE or start the program independently.
Figure 22: The Graphical User Interface of the Abaqus PDE.
The Abaqus PDE is used as the main integrated development environment, because Abaqus
PDE can only IDE which is capable to run Abaqus scripts and debug those when Abaqus is
running.
3.1.3 Eclipse integrated development environment
Eclipse (Figure 23) is used as a supporting IDE because Abaqus IDE does not have an
automated debugger. The automated debugger increases scripting speed, which helps to
ensure the quality of the code. Eclipse is a multi-language software development environment
comprising an integrated development environment (IDE) and an extensible plug-in system.
33
Figure 23: The Graphical User interface of The Eclipse.
3.2 Development language
Python is chosen for the development language because Abaqus uses it is scripting language.
Abaqus also uses FORTRAN, C and C++ for customizing. The code is written by using an Object-
Oriented Programming (OOP) paradigm in this thesis. In OOP data structures consist of data
fields and methods together with their interactions. The programming techniques may include
features such as data abstraction, encapsulation, messaging, modularity, polymorphism and
inheritance. A Cube development and test environment is developed to test code and for
continuous refactoring.
3.3 Development methods
The chosen methods support fast prototype development and do not demand heavy
requirement documentation. It is very difficult to gather all the requirements at the beginning
of a project, and whatever requirements are gathered, are guaranteed to change, at least in
details. It is vital to deliver some workable every week. The deliverables should be as mature
as possible. This requires testing, lots of it, early and regularly. Tests should be automated to
reduce effort and to promote repeatability.
3.3.1 Framework development method
JACAX framework is also a development method to write code for CAD and CAE applications
and it has a simple philosophy. Basically, the philosophy direct to write as little code as
possible, reuse as much as possible what already exists and make things as simple as possible,
but not simpler.
In practice this means that the developer should write clean and good code. Only those
features that the customer really need should be included. According to [19] 64 % of the
features are seldom or never used as shown in Figure 24 [19, p. 142]. Unused features are a
34
waste of money and away from the quality of the code. Unused features make the
development time longer than necessary.
Figure 24: Research of how much Microsoft Word functionality is used. [19, p. 142]
JACAX framework philosophy is based on the manifesto for Agile software development. The
idea of JACAX is to use standardized format (for example neutral geometry formats) as much
as possible and XML-sidecar as a middleware to reduce data losses and remove manual
repairing of the model (Figure 25). When the sidecar is used, there is no drop in data during
translation between different programs.
Figure 25: All information that is available at the end of the geometry definition process is transferred
to CAE processes. This further enables automation of the simulation, since no human interaction is
necessary to rebuild the information that is lost in the transfer. [6, p. 6]
3.3.2 Agile software development
XP is the used Agile method in this thesis. The basic of Agile methods is to break a program
development project into smaller task. For example the automated MNF generation task is
divided into five smaller tasks (Figure 26).
16%
7%
13%
19%
45% 64%
Sometimes
Always
Often
Rarely
Never used
35
Figure 26: Break big task down into smaller ones. Days are presenting estimated time for coding. [19,
p. 17]
These tasks include small steps with minimal planning, and do not directly involve long-term
planning. Iterations are short time frames which typically last from one to four weeks. Each
iteration involves a full software development cycle. Stakeholders produce documentation as
required. An iteration may not add enough functionality to warrant a market release, but the
goal is to have an available release with minimal errors at the end of each iteration. Multiple
iterations may be required to release a product or new features. The engine for getting stuff
done in agile project is the iteration. A one to two week period where you take your
customers’ most important stories and transform them into running, tested software. [19]
In Agile, the master story list is the projects to-do list. It contains all the high-level features
(user stories), what the customer will want to see in their software. Heavy documentation as a
means of capturing requirements has seldom really worked for software projects. Customers
seldom get what they want. Agile user stories are short descriptions of features what
customers like see in their software [19, p. 20].
A user story is one or more sentences in the everyday language of the end user. Each user
story is limited, and it should fit on a small paper note to ensure that it does not grow too
large. The user stories should be written by or for the customers for a software project and are
their main instrument to influence the development of the software. User stories could also be
written by developers to express non-functional requirements. [19, p. 98-113]
User stories are used to capture what the user wants to achieve and what kind of basis
features can be implemented. User stories are a quick way of handling customer requirements
without having to create formalized requirement documents and without performing
administrative tasks related to maintaining them. The intention of the user story is to be able
to respond faster and with less overhead to rapidly changing real-world requirements. [19, p.
98-113]. Advantages of the user stories:
Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
Allowing a developer and the client representative to discuss requirements throughout the project lifetime,
Needing very little maintenance.
Only being considered at the time of use.
Maintaining a close customer contact.
Allowing projects to be broken into small increments.
36
Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
Making it easier to estimate development effort.
3.3.3 Test driven development
Test-driven development (TDD) is a software development technique in XP. The goal of the XP
is that the code works as it should. Write a test that fails. Write code to pass the test and check
that the test passes and automate the tests.
The XP uses really short development cycles to incrementally design you software. Unit test
are written before the eventual code is written. Unit test are automated test that test the
functionality of pieces of the code. This approach is intended to stimulate the programmer to
think about conditions in which the code could fail. This means that the programmer is
finished with a certain piece of code when the code cannot fail any situations. [19, p. 225-235;
21]
Tests are supposed to fail; there’s no code to make them pass. A good test framework helps
TDD cycle; the less time and work it takes to run the test and interpret the results, the quicker
the test-driven cycle. The idea is explained in Figure 27.
Figure 27: In first the phase (red) a failing unit test is written to show what the new code would do. In
the second phase (green) the prototype of the code is written and to phase. In the final phase (blue)
the code is refactored, that means that the code is cleaned from for example duplication and the code
is lean and as clear as possible. [19, p. 226]
Unit tests are small, method-level tests that developers write and run. A unit test is updated
every time changes are made to the software to prove the changes they made work as
expected. The unit tests are invaluable because once developers automated and made them
easy to run, we can run them every time we make a change to our software and know
instantly whether we broke something. Typically agile projects will have hundreds if not
thousands of unit tests. The benefits of writing lots of these against your code base are many
[64]:
they give instant feedback,
they dramatically lower the cost of regression testing,
they greatly reduce debugging time,
supports refactoring, and
37
supports collective ownership, as a test serves as both documentation and a safety net for future development.
Tests fall into two categories. A unit test explores the behavior of individual pieces of code and
check implementations. Acceptance test (or customer test) verify that the requested features
match the business requirements and expectations of the customer. For every request, work
with the customer to write automated acceptance test to prove that the request has been
implemented successfully. When all of the acceptance tests pass, the work is complete [65].
The example of the unit test is presented in Appendix I
3.4 Digital design user case
The Simulation Based Design (SBD) concept refers to the simulation of the entire life cycle of
the product, from concept development to the detailed design, prototyping and testing.
Computer aided engineering tools provided simulation and validation before prototyping
allowing newly developed product to be optimized and virtually build. Benefits of the
simulation based design [66 67, 68, 69,70]:
Decrease of the number of expensive and time-consuming prototypes and physical
test.
Shorter lead-time in the design process.
Better solution due to the more comprehensive exploration of the solution space
Quality standard of products rise.
Identification of design errors earlier in the product life cycle.
The designer is provided with immediate feedback on design decision.
Higher quality and performance of final design.
Change making virtual prototypes is easy, quick and cheap.
Reduce manufacturing cost and increased communication and collaboration inside
company.
More product knowledge can be gained by using computer support by manipulating a
model describing the product.
A digital design user case is developed to simulate industry needs in a SBD. In this thesis a
diesel engine is chosen for a virtually developed product. Diesel engines are complex multi-
physical designs and, therefore, numerous parameters are linked to each other [71]. A realistic
simulation of a diesel engine needs multidisciplinary knowledge and use of different CAE
programs. This makes the user case an ideal test bench for SDM and application integration.
The use of multiple multidisciplinary programs makes it challenging to transfer data between
different programs and store it. The digital user case is represented in Figure 28.
38
Figure 28: The process diagram of the digital design case.
Excel is used to start the digital user case. Excel does the optimization of numerous linked
parameters. It tries to find the key engine calculation parameters and logical calculation
processes that can be used for engine design optimization [72]. Excel is also used to
preliminary check of engine functionality (Figure 29).
Figure 29: The GUI of the Digital design in Excel. The process design is launched using the spreadsheet
calculator.
Results of Excel calculation are used in CAD, where a CAD program (Pro Engineer) reads values
from a spreadsheet. The CAD program (Pro Engineer) generates 3D geometry from the
calculated parameters and saves the modeled geometry to IGES format. Because neutral
formats are mainly designed for geometry transfer and to avoid a drop at metadata level, Pro
Engineer also produce XML sidecar for FEA and MBS (Abaqus and ADAMS). IGES and XML are
transferred to ADAMS and Abaqus. Pro Engineers uses its external analysis feature for reading
the parameters from Excel spreadsheet.
Abaqus and Adams generate models from IGES and XML sidecar. The XML sidecar contains
information such as:
the coordinates of the interface nodes,
material information,
path for part,
the name of the part,
units,
39
the coordinates of the inner nodes,
the type of the entities,
the coordinates of the entities,
joint type, and
the coordinates of the joint.
Abaqus generates modal neutral files which are needed in the flexible multibody simulation.
Adams imports MNF-files and finalizes the model. Adams exports the loads and the forces into
the Abaqus input-file. Abaqus merges the Adams input file with its input-file and calculates
stress and strain for the part of the diesel engine. Abaqus creates report from simulation and
exports the results to the XML-sidecar.
3.4.1 Component mode generation
A flexible body in a multibody system is described only by the position of the nodes in the
inertial frame. In the formulation of flexible multibody system the time-consuming part of the
simulation is the inversion of the mass matrix, since in most formulation the mass matrix is not
constant and, therefore, has to be inverted in every time step of the integration routine. [73,
p. 1-2]
In this user case study Abaqus generates MNF files for Adams. As shown in Figure 30.
Figure 30: Flexible parts of the diesel engine; a piston, connectin grod and a crankshaft.
MNF file generation process consists of:
model definition,
perturbation step generation (for each retained nodal DOF) to generate the
constrained modes,
eigengfrequency analysis to generate the normal modes (the retained nodal DOFS are
fixed),
generation of an Abaqus substructure (A flexible body is a substructure. It is generated
using the component mode synthesis and saved in a library file so that it can be
attached to the other parts of a FE model via the retained nodal DOFs ),
run the Abaqus analysis, and
40
MNF file generation with modal stress and modal strain or without modal stress and
modal stress by using the Abaqus Interface for MSC.ADAMS. The interface reads the
Abaqus results files to create the modal neutral file.
Abaqus/CAE uses ACIS as kernel for geometry [24, p. 24]. The solid geometry of the diesel
engine´s part is represented in an IGES file by a series of surfaces and Abaqus/CAE has to stitch
these surfaces into a solid (Figure 31). Abaqus/CAE checks that the geometry is valid; the valid
geometry means that the geometry has no gaps between edges etc. Imported geometry is
generally made valid during import.
Figure 31: To stich gaps between intersecting edges, Abaqus/CAE adjusts the underlying surfaces until
A1 = A2. [24, p. 25]
Thus, IGES tolerance limit is bigger than the tolerance limit in Abaqus/CAE (The ACIS tolerance
is 1e-6 [24, p. 30]) and that for the imported geometry is imprecise (Figure 32). The imprecise
geometry might cause that quad or hex meshing using a medial axis algorithm might fail. It
might also be that algorithm is not able to produce good mesh. A good mesh is very important
in order to minimize the errors in the solvers leading to numerical diffusion and incorrect or
inaccurate results.
Figure 32: An imported connecting rod at IGES-format. As a result from the tolarence of IGES, the part
is imprecise.
To successfully import a solid defined by trimmed surfaced or B-reps, the tolerance of the
original file and the tolerance of Abaqus/CAE must match within an acceptable limit. After the
user imported a part into Abaqus/CAE, the healing process is designed to improve the part’s
41
accuracy. The Abaqus/CAE provides the following additional options when IGES is imported.
Those processes are:
convert to analytical representation, and
stitch gaps.
Abaqus/CAE tries to change the neighboring entities so that their geometry matches exactly.
After geometry repairing Abaqus assigns material to the geometry of the part. This is essential
part for the simulation. After that Abaqus searches surfaces and points by using information
from the XML sidecar. These points and surfaces are used to define interface and inner nodes.
The nodes coupled each other’s by using Abaqus coupling method. Abaqus also reads
information for the boundary conditions and the retained dofs from the sidecar.
A frequency simulation is needed to calculate the fixed-interface normal modes. Element mass
matrices and eigenvectors are written in a results file [48]. For each element the mass at a
node is computed by summing all terms in the row of the element mass matrix corresponding
to the first degree of freedom at that node. A displacement written in the results file will be
used to update the nodal coordinates written is the modal neutral file. After that there is a
substructure is generated. Abaqus generates mesh for the part and starts solving the
simulation. When the simulation is finished, Abaqus starts the Abaqus interface for
MSC.ADAMS to generate the MNF files.
3.4.2 Automated structural analysis
An automated structural analysis is the second part of the digital design user case which is
made by using FEM. Adams/View (output) calculates inertia loads in addition to external loads.
The Inertia loads include linear acceleration and angular velocity of the flexible body [74].
Reaction load includes applied reaction forces acting on the body. For flexible body
Adams/View assumes that its FEA origin is the same as it was when the flexible body was
defined. The Adams/View calculates loads at interface nodes. [74] The Adams/View export
those using FEA loads export. The loads in Abaqus input-file format (Figure 33).
42
Figure 33: FEA loads from Adams. Every time increment in Adams presented as steps in Abaqus input-
file.
Abaqus uses the same procedures which are presented in the previous chapter, but there are
some exceptions, Abaqus does not define boundary conditions, frequency and substructure
generation steps. In this script, Abaqus defines:
mesh,
material properties,
the first structural analysis step,
couplings between “interface nodes” and surfaces. In this case those are normal nodes where loads are affecting, and
solver parameters.
The boundary condition and loads are still missing and these are needed to solve the structural
analysis. The input file from Adams contains only loads for parts. To avoid negative eigenvalues
and that the result is converging, there is a need to define boundary conditions at the
simulation. These boundary conditions are defined by the CAD user by using XM sidecar or
Abaqus searches three/four the farthest points from the gravity center of the part. These
points are used for boundary conditions. When the boundary conditions are defined Abaqus
solves the simulation. The script reads the results from the simulation and writes the results in
the sidecar.
43
3.5 MNF file verification
When the modal neutral file is generated, there are usually two questions about the MNF file.
The first question is, was the translation process of the FEA model successful? The second
question is how many modes must be included in the flexible multibody simulation? With
fixed-interface modes it can be difficult to determine how many modes are needed to provide
a sufficiently accurate solution; the constrained model can have higher natural frequencies
than the target global model [74].
To answer these questions, the natural frequencies of the flexible bodies are recorded in
Adams/Linear and compared with those that the FEA program Abaqus predicted for the same
set of constraints. Unless the FEA translation process failed in some way (for example, units
were misrepresented) or there is an inadequate number of modes, the natural frequencies
should match [53]. Other possible reasons to that the frequencies are not the same:
boundary conditions and retained nodal DOFS (degrees of freedom) are set wrongly in Abaqus,
interface node is coupled with wrong inner nodes in Abaqus, and
interface node located at wrong place in Abaqus.
3.5.1 Paired t-test
For comparing natural frequencies, a paired t-test is used. The paired t-test is a statistical
hypothesis test, which the test statistics follows a Student’s t distribution. The correct testing
method is following. [75]
The general hypothesis is presented at equation 22 and 23.
[22]
[23]
The null hypothesis is presented at equation 24 and alternative hypothesizes is presented at
equation 25, 26 and 27.
[24]
[25]
[26]
[27]
is an arithmetic mean. The Arithmetic mean is presented in equation 28 and n is the count
of the observation.
∑ [28]
44
sample variance is defined by equation
∑ [29]
The paired t-test is defined by
√ [30]
Null hypothesis is
[31]
If the null hypothesis is true, the paired t-test follows the Students’t distribution by
. The natural frequencies of Abaqus and Adams are compared at Chapter
4.4.1.
[32]]
45
4 Results The results chapter consists of five parts:
user stories,
Cube development and test environment,
workflows for FEA integration,
architecture for FEA integration framework, and
digital design user case.
4.1 User stories for developing FEA integration for digital design
A master story list contains all the high-level features (user stories). Gathered user stories for
this thesis are showed in Figure 34.
Figure 34: Gathered user stories.
Heavy documentation never works in software projects because customers seldom get what
they want. Gathering heavy requirements is vast amounts of time and energy, instead of doing
what needs to be done. Agile user stories are short descriptions of features what customers
would like to like to see in their software [19, p. 20]. From the user stories are built a heavier
to-do-list to fulfill the user stories (See appendix II). This to-do-list is used to research principles
FEA integration into digital design and coding scripts for Abaqus.
46
The result to Excel user story is used to generate technical requirements and more user stories
for example. Generated requirements and user stories are:
technical requirements for FEA
automated postprocessing.
technical requirements only for Abaqus
visualize the results
user stories
find the maximum stress, and
write to XML.
From these user stories and requirements is generated the heavier to-do-list for the coding.
4.2 Cube development and test environment
The cube development and test environment was developed to study principles of the FEA.
The key issue is that how a CAD user should mark surfaces, joints, vertex etc. These methods
are founded during this thesis:
mark entities by using colors,
mark entities by using its ID number,
mark using Abaqus findAt(…) command for entities, and
search entities by using search areas and coordinates.
Abaqus is able to search entities by using the codes of the color, but that means the geometry
is modeled at Abaqus or it is transferred by using ACIS format. The CAD user specifies wanted
entities by a color. This method is not useful because it supports only one file format.
The second method is to search entities by its ID number. This number is defined in a CAD of a
FEM program, but this method is not reliable because the ID of the entities can change during
translation between different programs, during geometry repair or when new feature is added
or old one is deleted.
The third method is to search entities by using search areas and coordinates. The CAD user for
example wants to define the inner surfaces of the connecting rod; the user gives the
coordinates of the center, radius for ends and length which is in this case the length of the
bearing. Other similar search methods are also available in Abaqus [76; 77]:
CellArray.getByBoundingShere(center, origin ,radius)
CellArray. getByBoundingCylinder(center1,centrer2, radius)
EdgeArray.getByBoundingShere(center, origin ,radius)
EdgeArray.getClosest(coordinates)
EdgeArray.getByBoundingCylinder(center1,centrer2, radius)
FaceArray.getByBoundingShere(center, origin ,radius)
FaceArray.getClosest(coordinates)
FaceArray.getByBoundingCylinder(center1,centrer2, radius)
VertexArray.getByBoundingShere(center, origin ,radius)
VertexArray.getClosest(coordinates)
VertexArray.getByBoundingCylinder(center1,centrer2, radius)
47
The chosen method uses Abaqus findAt(..) command. This is not the general method for all
finite element programs but for the digital design user case this is the most general and the
easiest for the CAD user. The script search entities by using coordinates, in the first phase
Abaqus searches entities and returns the ID of the entities. This ID is used for generating a set
and this set is used for either region coupling, boundary condition or load. Now this ID is
reliable because we point to Abaqus data structure of the imported geometry and this phase is
done after importing the geometry and the geometry repair. The script is presented at Figure
35.
Figure 35: The example of search script. This script also generates a set from wanted entities.
The test bench is also useful for continuous iterations. This supports developing the code,
finding key factors which are needed for automated finite element analysis and research of
different ways to tag entities and find the tagged entities.
4.3 Workflows for FEA integration
To automate and integrate FEA correctly into the digital design a correct methods have to be
selected and processed. The tasks can be divided into different groups:
48
Table 9: Grouped workflows for FEA integration.
Group Task
A geometry import
B geometry repair
C Mesh generation
D boundary condition and load generation
E material import
F simulation automation
The geometry import group A is the most essential for integration, because this group enable
the transfer geometry, from CAD to FEM program or from finite element pre-processor to FEA
( for example Altair HyperMesh).The Part geometry can be defined in three ways in finite
element domain and that why the task of this group A are:
automated geometry import
native CAD geometry, and
neutral formats.
capability import orphan mesh
input or output database file, and
from pre-processor or from other Finite Element program
automated geometry build
geometry is built directly in Finite Element program
Group B, the Imported geometry usually requires some repairing or defeaturing to obtain high
quality mesh. Small edges and faces (holes, chamfers, fillets, and slivers) limit the user´s ability
to generate mesh successfully on both solid and shell geometries. An unwanted detail
removing is essential because excessive details will influence the mesh and dominate the time
taken to perform the analysis. According [78; 79] Abaqus and Ansys are able to perform
automated virtual topology. The tasks of the group B are:
automated geometry repair
convert geometry to precise, and
repair invalid parts.
automated virtual topology
combining a small face with and adjacent face,
combining a small edge with and adjacent edge, and
simplifying geometry,
The Mesh generating group C is also essential for automation for FEA automation and
integration. Mesh affects the accuracy and reliability of results of FEA. Principles of this group
are:
49
automated top down meshing, and
automated verify tool for native mesh.
The accuracy and reliability of the results depend heavily on the quality of the decision made
during the analysis process and the quality of the mesh. Good mesh is important in order to
minimize the errors in the solvers leading to numerical diffusion and incorrect or inaccurate
results. Good mesh has three components:
good resolution
appropriate mesh distribution, and
good mesh quality.
To fulfill the demands of the good mesh a script was to it linearly iterates suitable mesh for the
part and trying to find good mesh for it. The workflow of this script is presented in Figure 37.
First, the script iterates linearly the best suitable element shape for the geometry and the
order for this is:
hexahedron
hexahedron dominated, and
tetrahedron.
When the script founds the suitable element shape according to predicted criteria, it starts
refining the global seed size of the geometry until it fulfills the requirements for mesh (Figure
36).
Figure 36: The workflow for automated mesh generation.
The group D is essential for automation because finite element program is able to read the
boundary conditions and the loads from CAD. Which are defined in XML sidecar. The tasks are:
automated boundary condition import and generation, and
automated load import and generation.
The group E is essential for material properties. The Finite Element program has able to import
also material properties from material databanks or from the CAD and that why the tasks are:
50
automated material import, and
automated properties assign tools.
The last group F of the key factors is the simulation automation. This group affects the solver
and the results. The tasks are:
possibility to configure automated task easily and configure solver parameters,
automated visualization tool and automated result analyzer, and
automated “unit test” for simulation phases.
This group is useful if there are a lot of parameters and different models which have to be
checked and compared. If these are used well, there is no need for human check the results of
the simulation. An example of the unit test for the simulation is presented in Figure 37. The
user can check only the results and don`t have to spend time analyzing the results. The
automated unit test is adopted from the coding tools. In computer programming, the goal of
unit testing is to isolate each part of the program and the show that individual part.
Figure 37: An example of unit test for simulation. Where are eigenvalues from Abaqus and Adams are
tested to be the same. If they are the same the mnf-file is passed to Adams and if not Abaqus is
launched again and changes mesh parameters.
4.3.1 Architecture for FEA integration framework
The main ideas of the presented architecture are to keep the maintenance of the FEA
integration framework as easy as it can be. This is done by dividing the framework into
different partitions. The partitions have different tasks. The framework is presented in Figure
38.
The front end is responsible for collecting input data in various forms from the user and
processing the data to conform the specifications set by the back. The front end is program
type dependent.
A front adaptor is to protect other parts from the changes in the front end. The adaptor also
enables to code the front end for different stakeholders’ needs. The reader reads XML or
another used file format and uses the read information to fulfill task variants. The expert
knowledge is a store for a task. The tasks are automated FEA processes or simulations defined
and written by experts depending on the stakeholders’ needs. The tasks are FEA application
but if the FEA application changes indepedent, some tasks need a middleware between the
task and the expert application interface. The main idea of a task is to enable the change of the
used FEA application.
51
Figure 38 The architecture of the FEA integration framework
The expert application interface task is to protect from version changes of the FEA application
and changes the API changes of the FEA application. The FEA application and the expert
application interface are application dependent.
4.3.2 XML vocabulary
As a result of the literature study it was noticed that existing XML languages for FEA are not
suitable to fulfill the demands of the JACAX. In this thesis XML vocabulary for integration and
automation is presented. The vocabulary is a by-product from fulfilling the automation tasks of
FEA. An example of a sidecar XML-file for Abaqus is presented in Figure 39.
52
Figure 39: An example of the sidecar. The XML contains information from the parts and it generates
the boundary conditions for the simulation.
Because the needed vocabulary for fulfilling the needs of the automation task is minor for the
structural analysis, the vocabulary is extended. This extended vocabulary is presented in
Appendix III and it contains tags for a normal structural analysis. In Figure 40 is presented the
example from Figure 39 as a tree structure.
53
Figure 40: The XML-file presented as tree structure.
4.4 Digital design user case
The digital design user case contains two different parts for Abaqus. In the first part Abaqus
generates MNF-files for flexible multibody simulation and in the second part Abaqus calculates
structural analysis for wanted part by using FEA loads from Adams.
4.4.1 Natural frequencies of modal neutral files
When the modal file is generated the user should verify the file by checking mass, inertias and
natural frequencies the same in Abaqus and Adams. The frequencies are very essential
because natural frequencies are presenting the deformation of the part. The first natural
frequency of the connecting rod is presented in Figure 41.
Figure 41: The first natural frequencies of the connecting rod.
For every flexible component of the diesel engine18 modes are calculated, only frequencies
under 10 000 Hz are taken into account. The natural frequencies are exported from both
Abaqus and Adams.
54
The idea of this comparison is to check it the MNF file is transferred correctly, and to check
that eigenvalues are exactly right. The comparison of the natural frequencies of the connection
rod is presented in Figure 42.
Figure 42: The comparison between interpolated frequencies from connecting rod from Abaqus and
Adams.
The comparison is done by using a paired t-test. The test is safe to use when the number of
observation is bigger than 15. The comparison is done with frequencies under 10 000Hz and
frequencies are interpolated until 10 000 Hz is reached; this is done because the number of
observations is too low with original modes. The connecting rod has four orginal modes under
10 00 HZ and The natural frequencies of the connecting rod (0 - 10 000Hz) are split into four
areas:
1227,6 – 4203,8 Hz
4203,8 – 4277,1 Hz
4277,1 – 9164,8 Hz
9164,8 – 9607,2 Hz
By using Microsoft Excel trendline tool is possible to get equation to interpolate natural
frequencies and grow up the count of observations (Figure 43).
55
Figure 43: Natural frequencies are growing up linearly in area 1227, 6 – 4203, 8 Hz. By using the
trendline we get equation to interpolate frequencies.
By interpolating the count of observation of the connecting rod is raised from 4 to 35. The
crankshaft does not need interpolation because it has 18 modes under 10 000 Hz. The
comparison of the natural frequencies of the piston is not done because the first natural
frequency exceeds the limit.
Is natural frequency from Abaqus and i is mode number (equation 30)
[30]
Is natural frequency from MSC.Adams and I is the mode number (equation 31).
[31]
D is arithmetic mean. The difference of natural frequencies.
[32]
Null hypothesis is used for null hypothesis.
[33]
The test equation is gives a value.
∑ [34]
For sample variance is
(∑
) [35]
Using equations [34] and [35] the paired t-test is defined using equation.
√ [36]
56
. [82]. Using the significance level of 1 %.
[37]
Critical values of the significance level now are presented equations 38 and 39 for the
connecting rod.
[38]
[39]
The calculated result is not in rejection area meaning the null hypothesis is valid and all
frequencies are the same in Abaqus and Adams. This is presented in Equation 40. The
calculated result is compared value from Ilkka Mellin`s statistical tables [80].
2,724 [40]
The rejection principle is presented in Figure 44.
Figure 44: The rejection area. [83, p. 4]
4.4.2 Structural analysis
To avoid numerical singularities and that the simulation is converging, there is a need to define
boundary conditions for the simulation. These numerical singularities are caused from rigid
body movement and because the solver is not able to calculate the deformation of the part
(Figure 45).
The boundary conditions are defined by the CAD user (The XML sidecar) or by using a script.
This script searches the center of gravity of the part and searches three or four of the farthest
points. To the farthest point, the script sets boundary conditions. Boundary conditions are
given in Abaqus/CAE as zero values for displacements at boundary condition nodes.
57
Figure 45: Results from the Abaqus result file. In this case the numerical singularity is by from the rigid
body movement.
These boundary conditions might cause inaccurate results. Thus, the elements are connected
to the farthest points are removed from the result. The comparison of the result is presented
in Figure 46.
Figure 46: The comparison between cleaned and uncleaned results. On the left is the result where all
elements which are connected to the boundary condition node are removed. On the right is the result
where all elements are kept. The maximum stress of the uncleaned results over two times bigger
than the cleaned result.
The scripts search the maximum stress and strain from the steps and write the results to the
XML-sidecar (Figure 47). These results are transferred to Excel.
58
Figure 47: An example of the results at an XML-format.
4.5 Application integration framework
JACAX is a one for application integration. This framework is used to integrate different CAE
programs from different vendors. It´s architecture was initially designed in the Silicom project.
JACAX is an abbreviation from “just another computer aided X”. This solution leverages on:
neutral geometry formats,
XML-based sidecar file format, and
native geometry formats (if a plug-in reader is available).
The main idea of JACAX is the integration of the programs’ data systems. In the CAx, the CAD is
the corner stone because the simulations are mainly based on the model geometry. For
manufacturing simulation and finite element simulation variations of CAD geometry are
generated. Because the data systems are presented as feature trees in a CA system, it possible
to say, that JACAX aims to integrate different programs’ feature trees. JACAX extends a feature
tree of a CAD by integrating other programs into it.
This integration is realized by using standardized supported formats, for example neutral
formats STEP and IGES and native geometry formats. However, these formats are not able to
transfer all needed information for the simulation. Therefore, a sidecar is used to eliminate a
drop of metadata and the information level. The sidecar is based on extensible markup
language (XML). The user defines the content of the sidecar. In Figure 48 the idea is presented,
how should be the information transferred between different programs.
Figure 48: The JACAX is a software solution to solve the information transfer from CAE software A to
CAE software B. [18]
JACAX gives freedom the user to selected arrange information to transfer that way which suits
the best to the user. JACAX don’t define any grammar and vocabulary for the XML, it only gives
examples and guidelines to write XML.
59
The JACAX uses a hybrid method to handle application integration. It is a combination of a
point-to-point strategy and a process broker. JACAX uses the point-to-point method when it
transfers geometry by using neutral geometry formats. In the digital design user case (Figure
49) the information is moved directly from Excel to Pro Engineer by Excel’s own file format and
directly from Pro Engineer to Abaqus and Adams by IGES-format. However, this arrangement
has problems. Data is lost at metadata level, the process logic is spread and embedded in
different applications, and the maintenance and the extension of the process is not easily
arranged.
Figure 49: A point-to-point strategy is the base layer in a hybrid method. Pro/Engineer provides only
geometry for Abaqus and Adams at this point (left). In the hybrid method the XML-based sidecar
works as a process broker and handles the process and embeds the results. Pro/Engineer provides
XML-file which contains metadata information for Abaqus and Adams (right).
To solve problems the point-to-point combined is with the process broker (Figure 51). In the
process broker the process logic is encapsulated in one place. In the JACAX´s case, the process
logic is encapsulated in the XML-based sidecar. The batch scripts are used to launch the
simulation and Pro Engineer is used to generate the sidecar.
This combination is called a “lightweight hybrid broker”. The solution is lightweight because it
uses neutral and native geometry formats and the sidecar encapsulates only needed logic and
it does not try to work with all existing CAE applications. The JACAX fulfills the requirements of
the application integration. These requirements for the application integration are defined by
Red Oak software company [28]. Those requirements are:
ubiquitous access to application data,
non-intrusive access to data,
adaptability to changing requirements,
easily maintained and updated,
works with existing applications,
works with existing integration systems, and
designed for production systems.
JACAX differs from studied commercial application because it does not enforce to use specific
CAE programs in the digital design process.
60
The functionalities of the JACAX and its levels are presented in Figure 50. A meta level can be
called knowledge level, because it consists of the knowledge of the enterprise or the expert.
Figure 50: Different process levels in the JACAX. [81;82]
During the process model and data are transformed, but also metadata e.g. information about
CAD and simulation model, product specification, and simulation results, are transformed and
transferred. Therefore in the digital design it is necessary to manage not only the data
transformations but also the flow of the metadata. Experts and designers are interested in the
history of a data. Metadata in the digital design can be divided into five categories [83;8 ]:
structural metadata,
workflow metadata,
descriptive metadata,
lineage metadata and
technical metadata.
Structural metadata is classified into the description of tool and domain specific data models,
description of the structures of local data as well as integration information. The information
can be distinguished into different levels [83]:
Description of the local data model in every domain using a common notation.
Description of the structure of local data and model of every domain using the local data models.
For example, the data model is a CAD data model consisting of parts, assemblies, and features.
The structural metadata describes the structure of actual models. Such as a class parameter or
the assembly hierarchy of a CAD model with part names and parameter values [83].
Integration metadata represents the correspondences between different domains and a model
which describe semantic dependencies between structural elements, the material parameter
of a CAD model for example [83].
Workflow metadata allows the explicit definition of activities comprising a digital design. In the
context of the digital design, workflows are used to track the data and its transformations
61
made by different systems and one individual or a small group of individuals. Parts of
workflows can be reused and recombined.
Descriptive metadata helps users and system to find, to document, and to connect resources.
The metadata is defined as free text of term of a pre-defined ontology. Typically, metadata is
either stored in a metadata repository or as annotation together with the data [83].
Data lineage metadata comprises all information about a process that was used to develop a
product (Figure 51). Data lineage information explains and documents the history of design
decision based on the collected metadata about transformation and data.
Figure 51: The data lineage metadata.
The metadata from the metadata level is used to populate a process level and script level. The
processes level contains enterprises’, experts’ or CAE applications procedures, for example
MNF file generation. This level consists of the different simulation processes.
Script level is supporting the processes level. It contains scripts or macros, which are meant to
do desired processes. The scripts or macros are written at the API of CAE applications. This
level contains also writers and readers which are needed to convert the XML sidecar metadata
for the scripts or macros. The application level contains CAE applications.
62
5 Discussion The main results of the thesis can be summarized as:
user stories for developing FEA integration for digital design,
Cube development and test environment,
workflow for FEA integration,
digital design user case, and,
application integration framework.
5.1 User stories for developing FEA integration for digital design
Heavy documentation seldom works for requirements in software projects because customers
usually don`t what they want. It is impossible to gather all requirements at the beginning of
the project and whatever requirements you gather are guaranteed to change. The heavy
documentation don´t work also for the documentation of the code and for the application
programming interface (API) because it makes the documentation difficult to read and hard to
assimilate new information.
The user cases, unit tests, the to-do-list and the code work as documentation. There is no need
for heavy documentation which describes every small detail in such a way that every member
at the development team member understands the document. That is usually a waste of time.
The documentation is meant for finite element experts and for coders and this makes it easier
to expand the code, because a new member has “API” for the automation and examples from
the script.
5.2 Cube development and test environment
The Cube development and test environment was developed to study principles of the finite
element analysis. It is also used to study how a CAD user should mark entities. How good those
methods are depend on the used finite element program and the used simulation type. All
found methods are not fully workable with all programs. The chosen method for the marking
entities is Abaqus findAt(..) command is the most generic but evidently only for Abaqus. This
method is not perhaps the best method for other programs and that is why this area need
more research by using different finite element programs.
The chosen method enables a CAD user to mark entities in the CAD and move information
from entities to FEA. The chosen method does not need so much coding from the CAD user
when it is compared with the other found methods.
5.3 Workflow for FEA integration
how the contacts are defined automatically and how contacts are realized to give accurate
results. This research area is suitable for e.g. post-graduate studies.
Initially, some small structural analysis tasks for different finite element programs were
planned to be developed in the beginning, but this excluded because of refocusing the topic.
The vocabulary could be even better if the research and scripting would have been done with
many programs, for example with Abaqus, Ansys and Patran. However, in the future
63
integration and automation needs to be done for other for other programs also. What is done
at this point is a good base for further steps and other automated Finite Element tasks,
because the scripting is done well and it is easily extended. Also data losses of the translation
are avoided by using the developed XML-sidecar.
The Architecture for FEA integration framework makes it possible to keep the maintenance of
the framework as easy as possible and to make the extension of the framework easy to
expand. This has been proven during this thesis and in the Silicom project. The framework
makes it easier to code different programs and different simulations. This is what users and
experts want from the programs. The easy usability of the programs is more import than
having lots of features.
5.4 Digital design user case
During the researching, it has been noticed that it is difficult to integrated different programs.
Our integration is not working in a Windows 64-bit platform, because the Abaqus interface for
MSC.ADAMS has a serious bug:
SIR-111299: MNF files created on Windows 64-bit platform may have incorrect eigenvalues. These incorrect values are obvious as the eigenvalues are extremely large (of orders of magnitude 10^100) and the model itself is unseen in Adams/View. The workaround is to use Windows 32-bit platform for translation. [84]
This bug means the Abaqus interface for MSC.ADAMS at the Windows 64-bit platform was not
used. The Workability for scripts is proven by running the script at CSC in a Linux platform. The
part of Abaqus works as it was planned.
The paired T-pair test results show that the natural frequencies of the connecting rod and
crankshaft were in good accordance. The used limit frequency (10 000 Hz) was too high
because in the real world natural frequencies of the diesel engine are under 1 000 Hz. The
unrealistic limits were used because calculated natural frequencies start above the realistic
limit and the real number of observations of the parts of the diesel engine is too for use the T-
pair test. The test is not done for the piston because the first frequency is presented at 9829
Hz. This means that boundary conditions might be faulty at Abaqus. The automated boundary
condition might cause inaccurate results and even cleaned results are not exactly right. This
area needs more research in the future. Nevertheless, these are not major shortcome because
the digital user case in this study is mainly used for producing data for SDM and research
automation and integration, not to design a real diesel engine.
5.5 Application integration framework
The JACAX framework is developed during this thesis. JACAX should be as light as possible and
there should be unused features. By gathering heavy documents and requirements from CAD,
FEA and MBS because it is impossible to do in such a way it works 100 %. This thesis proved
that JACAX works. JACAX provides a meaningful representation of the product model that will
facilitate seamless interoperability between CAD and FEA, and between CAD and MBS. JACAX
will also allow the computer system to understand digital design models expanded to
engineering and not only geometry.
64
Most of the objects of this thesis are fulfilled. Now we are able to integrate and automate FEA
as a part of bigger simulation loop in the digital design. This is proven by fulfilling the tasks of
the digital design user case and by solving tricky problems, such as; how the CAD should point
the surfaces and how to automate time-consuming tasks like the automated boundary
conditions for the structural analysis, for instance.
.
65
6 Bibliography 1. Simulia, a Dassault Systemes Brand. The Case for Simulation Lifecycle Management. [PDF]. 2011.
[cited 2011 11 27]. Available from: http://www.simulia.com/download/pdf/SIMULIA_SLM_WhitePaper_Complete.pdf .
2. Gonzalez M, Gonzales F, Luaces A, Cuadrado J. Interoperability and neutral data format in multibody system simulation. Multibody System Dynamics. 2007.[Journal]. Volume 18. 2007. [cited 2012 01 01]. Available from: http://dx.doi.org/10.1007/s11044-007-9060-8.
3. Altair Engineering. HyperWorks A Platform for Innnovation. [PDF]. 2011. [cited 2011 211 22]. Available from: http://www.altairhyperworks.com/Solutions,1,23,HyperWorks%20Enterprise.aspx .
4. Comet Solution. The Comet Workspace. [PDF]. 2011. [cited 2011 11 22]. Available from: http://cometsolutions.com/products/workspace/ .
5. MSC.Software. SimXpert for Integrate Simulation Environment. [PDF]. 2011. [cited 2011 11 22]. Available from: http://www.mscsoftware.com/Products/CAE-Tools/SimXpert.aspx .
6. Nawijn M, van Tooren M, Berend J. Automated Finite Element Analysis in a Knowledge Based Engineering Environment. [PDF]. [cited 2011 11 21]. Available from: http://academics.ewi.tudelft.nl/live/binaries/f1030549-cee5-4197-a4b0-2197fe671949/doc/Mesh-Papers-v2.pdf .
7. Sun W, Ma Q, Cheng S. A Framework for automated finite element analysis with an ontology-based approach. Journal of Mechanical Science and Technology. [Journal] Volume 23. 2009.[cited 2011 11 27]. Available from: http://dx.doi.org/10.1007/s12206-009-1005-0.
8. Simulia, a Dassault Systemes Brand. Abaqus Multiphysics. [Webpage]. 2011. [cited 2011 12 20]. Available from: http://www.simulia.com/products/abaqus_multiphysics.html .
9. Ansys. Ansys Workbench Platform. [Webpage]; 2011. [cited 2011 11 22]. Available from: http://www.altairhyperworks.com/HWTemp1.aspx?top_nav_name=HyperWorks Overview&item_name=About .
10. Dassault Systemes. CATIA V5R21 drives higher Design excellence. [Webpage]. 2011. [cited 2011 12 3]. Available from: http://www.3ds.com/products/catia/portfolio/catia-v5/all-products/domain/Analysis/?cHash=ce1ba86eb5d34c3b86ce1bbef9839952 .
11. Dassault Systemes. CATIA V6R2011 strengthens Virtual Design on the collaborative platform. [Wepage]. 2011 [cited 2011 12 3]. Available from: http://www.3ds.com/products/catia/portfolio/catia-v6/v6-portfolio/d/virtual-design/s/mechanical/p/mechanism-simulation/?cHash=74e864052b04ce3c23811cdc5ec0a3fe .
12. Simulia, a Dassault Systemes Brand. Isight. [Webpage]. 2011 [cited 2011 11 22]. Available from: http://www.simulia.com/products/isight2.html .
13. LMS. LMS Virtual.Lab. [Webpage]. 2011. [cited 2011 12 3]. Available from: http://www.lmsintl.com/virtuallab .
66
14. Esteco. Process integration. [WebPage]. 2011. [cited 2011 12 3]. http://www.esteco.com/home/mode_frontier/Integration.html .
15. PTC. Creao Parametric. [Webpage]. 2011. [cited 2011 12 3]. Available from: http://www.ptc.com/product/pro-engineer .
16. Solidworks. Solidworks-tuotteet. [Webpage]. 2011. [cited 2011 12 3]. Available from: http://www.solidworks.fi/sw/6449_SVF_HTML.htm .
17. MSC.Software. SimXpert Integrated Multidiscipline Enterprise Simulation Solution for the CAE Analyst. [Webpage]. 2011. [cited 2011 11 22]. Available from: http://www.mscsoftware.com/Submitted-Content/Resources//ds_simxpert_a4_w.pdf .
18. Buda A. Silicom Project Summary-Simulation Lifecycle Management SLM. [Powerpoint]. 2011. [cited 2012 01 01].
19. Rasmusson J. The Agile Samurai. Pragmatic Bookshelf. 2010.ISBN-10: 1-934356-58-1.
20. Janzen D, Saiedian H. Test-Driven development concepts, taxonomy, and future direction. Computer.[PDF]. Volume 38. 2005. [cited 2012 01 01] . Available from: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1510569
21. Chromatic. Extreme Programming Pocket Guide (Ebook). O’Reilly Media. 2009. ISBN-10: 0-596-55622-5
22. Michopoulos J, Mast P, Chwastyk T, Gause L, Badaliance R. FemML for Data Exchange between FEA Codes. [PDF]. [cited 2012 02 01]. Available from: http://femml.sourceforge.net/download/femMLPaperScr12.pdf.
23. Michopoulos J. Development of the Finite Element Modeling Markup Languge. [PDF]. 2002. [cited 2012 01. 01.]. Available from: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.196.2067&rep=rep1&type=pdf .
24. Simulia, a Dassault Systemes Brand. Abaqus/CAE:Geometry Import and Meshing. [Training material].
25. Simulia, a Dassault Systemes Brand .Abaqus/CAE User´s Manual. 10.4.4 Exporting to an IGES file. 2011.
26. Johannnesson P, Perjons E. Design Principles for Application Integration. Advanced Information Systems Engineering. [PDF]. 2000 .[cited 2012 02 01]. Available from: http://dx.doi.org/10.1007/3-540-45140-4_15
27. Kungliska Tekniska Högskolan,Viewlocity. A Process Broker Architecture for System Integration. [PDF]. [cited 2012 02 01]. Available from: http://people.dsv.su.se/~perjons/whitepaper.pdf
28. Red Oak Sofware. Red Oak Softeware´s Application Integration Framework FAQ. [Webpage]. 2011 [cited 2011 11 27]. Available from: http://www.redoaksw.com/whitepapers/appframefaq.html
67
29. Ansys. ANSYS Workbench Platform. [PDF].2011.[cited 2011 12 26]. Available from: http://www.ansys.com/staticassets/ANSYS/staticassets/resourcelibrary/brochure/workbench-platform-12.1.pdf .
30. LMS. Virtual.Lab online help. Main Concepts and Features.[Online material]. 2011.
31. LMS. Powertrain simulation. [Webpage]. 2011. [cited 2011 12 26]. Available from: http://www.lmsintl.com/simulation/powertrain-motion .
32. Simulia, a Dassault Systemes Brand. Abaqus 6.11, Abaqus Interface for Moldflow User´s Manual. [Online material]. 2011.
33. School of Science and Technology,Department of Media Technology. Luento 1: Johdanto merkintäkieliin,T-75.1110 XML-kuvauskieltenperusteet.[Course material]. 2011. [cited 2011 12 21].
34. Wikipedia. XML. [Webpage]. 2011. [cited 2011 12 21]. Available from: http://en.wikipedia.org/wiki/XML .
35. Schneider P, Huck E, Reitz S, Parodat S, Schneider A, Schwarz P. A modular approach for simulation-based optimization of MEMS. Design, Modeling, and Simulation in Microelectronics.[PDF]. 2000. [cited 2012 01 01]. Available from: http://www.sciencedirect.com/science/article/pii/S002626920100101X
36. Brown M. XML processing with Perl, Python, and PHP. Sybex. 2002. ISBN: 0-7821-4021-1
37. MatML. A Data Interchange Markup Language.[PDF]. [cited 2012 12 21]. Available from: http://www.matml.org/downloads/matml_03.pdf
38. MatWeb. ANSYS Data Downloads. [Webpage].2011 [cited 2011 12 21]. Available from: http://www.matweb.com/help/ansys_intro.aspx .
39. MathWeb. SpaceClaim Data Downloads. [Webpage]. 2011 [cited 2011 12 21]. Available from: http://www.matweb.com/help/spaceclaim_intro.aspx .
40. MatWeb. ETBX Data Downloads. [Webpage].2011. [cited 2011 12 21]. Available from: http://www.matweb.com/help/etbx_intro.aspx .
41. MatWeb. Data Downloads.[ Webpage].2011.[cited 2011 12 21]. Available from: http://www.matweb.com/help/Algor_intro.aspx .
42. MatMl. MatML A Data Interchange Markup Language. [PDF]. [cited 2011 12 21]. Available from: http://www.matml.org/downloads/matml_03.pdf .
43. MatML. About MatML. [Webpage]. [cited 2011 12 21]. Available from: http://www.matml.org/overview.htm .
44. FemML. FemMl about. [Webpage]. [cited 2011 12 21]. Available from: http://femml.sourceforge.net/about.htm .
68
45. Ding L, Ball A, Matthews J, McMahon C, Patel M. Product Representation in Lightweight Formarts for Product Lifecycle Management (PLM).[PDF].2007. [cited 2011 12 21]. Available from: http://opus.bath.ac.uk/12768/
46. Dassault Systemes. Download the 3D XML Player.[Webpage]. 2011. [cited 2011 12 219]. Available from: http://www.3ds.com/products/3dvia/3d-xml/1/ .
47. Dannbauer, Meindi, Steinbat. Fatigue Analysis of Dynamically Loaded Structures with ABAQUS,ADAMS and FEMFAT.[PDF].2004. [cited 2011 12 21].Available from: http://www.femfat.com/Papers.3632.0.html?&showUID=415
48. Simulia, a Dassault Systemes Brand. Abaqus 6.11.,Abaqus Interface for MSC.ADAMS User´s Manual.
49. Simulia, a Dassault Systemes Brand. Substructures and Submodeling With Abaqus.[Training Material]. 2010.
50. Simulia, a Dassault Systemes Brand. Abaqus 6.11, Theory Manual Chapter 2.14.1 Substructuring and substructure analysis.
51. Msc.Software. MD Adams 2011, Building Flex Body Model. Verifying Flexible Bodies. [Online Material]. 2011.
52. Simulia, a Dassault Systemes Brand. Abaqus 6.11 Theory Manual, 2.5.1 Eigenvalue extraction. [Online Material]. 2011.
53. Pinfold M, Chapman C. The application of KBE technigues to the FE model creation of an automotive body structure. Computers in Industry.[PDF]. 2001. Available from: http://www.sciencedirect.com/science/article/pii/S0166361500000798
53. Msc.Software. Building Flex Body Model, Verifying Flexible Bodies, Using Adams/Linear to verify Flexible Bodies. [Online Material]. 2011.
54. Simulia, a Dassault Systemes Brand. Abaqus 6.11. Analysis User´s Manual, Volume IV: Elements. Element Library.[Online Material]. 2011
55. Ansys. Introduction to Ansys Meshing. Meshing Methods for 2D Geometry.[Online Material]. 2011.
56. Ansys. Introduction to Ansys Meshing. Meshing Methods for 3D Geometry.[Online Material]. 2011.
57. Simulia, a Dassault Systemes Brand. Abaqus 6.11 Getting started with Abaqus: The Abaqus products. [Online Material].2011
58. Simulia, a Dassault Systemes Brand. [Introduction to Python and Scripting in Abaqus, Abaqus Architechture.[Training Material]. 2011.
59. Wikipedia. Agile software development. [Webpage]. [cited 2011 12 26]. Available from: http://en.wikipedia.org/wiki/Agile_software_development .
69
60. Extreme Programming, A gentle introduction. [Webpage]. [cited 2011 12 27]. Available from: http://www.extremeprogramming.org/ .
61. Extreme Programming, What we have learned About Extreme programming. [Webpage]. [cited 2011 12 27]. Available from: http://www.extremeprogramming.org/lessons.html .
62. Extreme programming, The values of Extreme programming. [Webpage]. [cited 2011 12 27]. Available from:http://www.extremeprogramming.org/values.html .
63. Extreme programmin, The Rules of Extreme Programming. [Webpage]. [cited 2012 12 27]. Available from: http://www.extremeprogramming.org/rules.html .
64. Extreme Programming, Unit Test. [Webpage]. [cited 2012 12 27]. Available from: http://www.extremeprogramming.org/rules/unittests.html .
65. Extreme Programming, Acceptance Test. [Webpage]. [cited 2012 12 27]. Available from: http://www.extremeprogramming.org/rules/functionaltests.html .
66. Bylund N. Simulation Driven Product Development Applied to Car Body Design,Doctoral Thesis.[PDF].2004. [cited 2012 01 02]. Available from: http://epubl.ltu.se/1402-1544/2004/33/LTU-DT-0433-SE.pdf
67. Lehtonen M. Simulation-Based Design Process of Smart Machines: VTT Research.[PDF] 2006. [cited 2012 01 02]. Available from: http://www.vtt.fi/inf/pdf/tiedotteet/2006/T2349.pdf
68. Sinha R,Paredis C,Liang V,Khosla P. Modeling and simulation methods for design of engineering systems. Journal of Computing and Information Science in Engineering. [PDF]. 2001.[cited 2012 01 02]. Available from: http://dl.acm.org/citation.cfm?id=381736
69. Murphy C, Perera T. The Definition of Simulation and its Role within an Aerospace Company.[PDF]. 2002. [cited 2012 01 02]. Available from: http://www.sciencedirect.com/science/article/pii/S0928486901000453
70. Jenkins B. Best Practices for Implementing Digital Simulation and Analysis: Five Lessons from Savvy Automotive Powertrain Program Managers.[PDF]. 2005.[cited 2012 01 02]. Available from: http://www.plm.automation.siemens.com/en_in/Images/best_practice_automotive_2_tcm641-24342.pdf
71. Heywood J. Internal Combustion Engine Fundamentals. McGraw-Hill. 1988. ISBN-10: 007028637X
72. Valkonen A. Diesel engine early computational design.[Project report draft]. 2010. Aalto University
73. Cardona A. Superelements Modelling in Flexible Multibody Dynamics. Multibody System Dynamics.Volume 4. 2000. [cited 2012 01 02]. Available from: http://dx.doi.org/10.1023/A:1009875930232
74. Msc.Software. MD adams 2011,Export. FEA Loads. [Online Material]. 2011. [cited 2011 12 27].
70
75. Mellin I. Mat-1.2620 Sovellettu todennäköisyyslaskenta B. [Course material].
76. Simulia, a Dassault Systemes Brand. Abaqus 6.11 Scripting Reference Manual. [Online Material]. 2011.
77. Simulia, a Dassault Systemes Brand. Abaqus 6.11, Scripting User´s Manual. [Online Material 2011.
78. Simulia, a Dassault Systemes Brand.Abaqus Data sheet.[PDF].2011.[cited 2012 01 01]. Available: http://www.simulia.com/download/datasheet/Abaqus-CAE-6-11.pdf
79. Ansys. Ansys Meshing Solution. [PDF].2011.[cited 2012 01 01]. Available: http://www.ansys.com/staticassets/ANSYS/staticassets/resourcelibrary/brochure/ansys-meshing-brochure.pdf
80. Mellin I. Statistical Tables. [Course material].
81. Makkonen P. JACAX: Silicom Engine Demo Model WP 3.2 Concept Verification .[Project report draft].2011.
82. Aalto University. Silicom, Simulation Lifecycle Management SLM Leading Group Meeting nr. 6.[Powerpoint].2011.
83. Geist I, Vornholt S. Metadata Repositories for Virtual Engineering.[PDF].2008.[cited 2012 01 01]. Available: http://wwwiti.cs.uni-magdeburg.de/~geist/publications/iff_wita2008.pdf
84. Lindgren R. Abaqus Interface for Msc.Adams bug [Email].
Appendix I Example of the unit test.
Appendix II To-do-list from user stories.
Appendix III Extend vocabulary for FEA XML.
