Technology
The primary mission
of the Texas office of Altair Engineering is serving as a technology source
for industry and government.
We have developed and maintain PHLEX
kernel, a multipurpose hp-adaptive, vector/parallel finite element
kernel encapsulating the following technologies:
This unique library permits easy application
of our leading edge simulation technology to diverse and complex physical
phenomena, including:
-
Computational Fluid Mechanics
-
Computational Solid Mechanics
-
Computational Models for Contact and Friction
-
Oil Reservoir Simulation
-
Topology Optimization
and others.
hp-Adaptive Finite
Element Theory and Methodology
-
Traditional
implementations of the finite element method, such as NASTRAN, are now
referred to as h-version codes, where h is the characteristic size of the
individual element. If such a code includes some automatic mechanism for
altering h in response to the characteristics of a specific problem, it
is said to be h-adaptive. The act of increasing the number of elements
(reducing the characteristic size) is called refinement.
-
Some newer codes permit an orderly variation
of the polynomial degree of the shape functions within an element. This
variation is now called the p-version of the finite element method. If
such a code includes some automatic mechanism for altering p in response
to the characteristics of a specific problem, it is said to be p-adaptive.
The act of increasing the polynomial degree of the elements is called enrichment.
When both h and p are carefully manipulated
in response to specific problem characteristics, convergence to a solution
with very low numerical error can proceed at an exponential rate. If a
code includes an automatic mechanism for altering both h and p appropriately,
it is said to be hp-adaptive.
The only codes available commercially which
are automatically hp-adaptive are based on the PHLEX
kernel, and were created by Altair engineers in our Austin,
Texas office.
An
Introduction to hp-adaptive Finite Element Method
A paper containing general information about the hp-Finite Element technology.
![[image]](../images/download.gif)
Manual Adaptation (35 K in a separate window)
The manual adaptation editor allows
iterative modifications of the mesh in both h and p and extraction of the
solution. The edge colors represent their order of approximation or P Level.
HP-Adaptive Solution Sequence (166 K in a separate window)
This is the result of an analysis where
the error level request was 5%. PHLEX is the only code which can dynamically
modify the initial mesh in h and p simultaneously to provide an
optimal distribution of degrees of freedom.
Error
Estimation for Computational Mechanics
In
order to systematically reduce the numerical error in a finite element
analysis, some estimate of that error must be made, both globally and locally.
The global estimate should provide some reasonable indication whether the
overall problem solution is numerically valid. The local estimate should
provide reasonable confidence that a design decision based on a particular
resultant, such as first principal stress, will not lead to a prototype
component which will fail in tests.
Computation of such estimates is more
difficult than might be supposed. In order to discuss them clearly, it
is useful to subdivide the mathematical operations commonly used to drive
adaptive processes into two classes: error indicators and error estimators.
Error indicators generally provide
clues as to the location of numerical error, but not to its relative contribution
to the overall integrity of the solution. A number of these are in commercial
use, and are described in the literature. Discontinuity in a stress field
is such an indicator. Unfortunately, such indicators, if they are the only
measure of error employed, can cause, and mask, convergence to an incorrect
solution.
Error estimators provide information
not only about the location of error, but about its relative magnitude
in some norm. They can be shown to be mathematically related to the true
error in a given solution. A common global estimator employed by some p-version
or p-adaptive codes is the relative error in the energy norm. Satisfying
a global norm, however, does not guarantee local convergence.
Residual error estimators, such
as those provided in PHLEX-based codes, are the most rigorous tools for
error identification and sizing. The residual is the amount by which the
particular finite element solution fails to satisfy the governing equations
being modeled. As this residual is systematically reduced, the solution
is mathematically guaranteed to be improving.
Careful combination of computationally
inexpensive error indicators with rigorous, but computationally expensive,
residual error estimators provide PHLEX users with optimal control of solution
quality within a given computational budget or run time constraint.
-
PHLEX not only provides a solution of the
system of PDE's but also a final distribution of the error .
Meshless Methods
The term "meshless methods" encompasses
a class of techniques striving to simplify the preparation of computational
models by eliminating or reducing the effort dedicated to generation of
classical finite element meshes. This includes a variety of methods, such
as Generalized Finite Differences, Element-Free Galerkin, hp-Clouds, Wavelets,
external approximation, R-functions, and others. While virtually
all of these methods require some kind of discretization to solve the problem,
typically generation of such a discretization lends itself to a high level
of automation, allowing the user to perform "meshless" analysis.
Besides simplifying model preparation,
these methods are also advantageous in problems with changing domains,
such as crack propagation, where classical finite element techniques experience
difficulties in following the changing domain.
COMCO and later Altair Engineering, in
cooperation with the University of Texas at Austin, has been on the forefront
of these meshless developments. Some of the techniques developed and implemented
in this area include:
|
Generalized Finite Difference Method
(GFDM),
which extends classical concepts of finite difference to irregular sets
of points, without any need for finite element mesh. Typically this is
accomplished by combining Moving Least Squares (MLS) approximation with
a collocation method for a Partial Differential Equation.
Hp-Cloud Method, which introduces
spherical "Clouds" to construct a Partition of Unity (POU) for the domain.
These Clouds, combined with rather arbitrary approximation functions, are
used to produce a weak statement of the problem similar to the classical
finite element formulation. The Cloud method allows to solve similar problem
classes as finite elements, yet without a need for finite element entities
and shape functions.
Generalized Finite Element Method (GFEM)
also belongs to the Partition of Unity family, yet uses linear finite element
shape functions to build the Partition of Unity. While the method requires
an underlying mesh similar to the classical finite elements, it is much
more tolerant of elements with bad aspect ratios. Moreover, it allows for
application of very general shape functions, such as special solutions
corresponding to specific problem features (holes, spot welds, wells in
oil reservoirs, etc.).
Element Partition Method (EPM)
is an Altair proprietary extension of the Generalized Finite Element Method.
While delivering all the advantages of GFEM, EPM relaxes the requirements
on mesh consistency, working even on mismatched meshes. Moreover, through
some proprietary generalizations, this method delivers performance competitive
or up to order of magnitude faster than the finite element method. Additionally,
EPM supports very advanced handling of crack propagation problems, allowing
the cracks to grow in virtually arbitrary direction without requiring complex
re-meshing.
|
Meshless_EPM
Solver Technology for Structural Mechanics Problems
A technical note presenting Altair's
most advanced meshless technique called Element Partition Method.
Altair
Engineering Meshless Methods Overview (slide presentation
in a separate window)
A brief overview of Altair Engineering
meshless methods, in particular Element Partition Method.
Generalized
Finite Element Method for Three-Dimensional Structural Mechanics
A paper presenting Generalized Finite
Element Method as a version of POU methods
Hp-Meshless
Cloud Method
A paper presenting Altair Engineering
meshless methods, in particular the Generalized Finite Difference Method.
Hp-Meshless
Cloud Method for Dynamic Fracture Propagation
A brief overview of PHLEXcrack
code, and EPM technology for fracture mechanics.
Vector and Parallel
Implementation
Engineers and mathematicians have worked to
vectorize computational algorithms ever since the first vector computers
were created by Seymour Cray. Parallel computation is a younger discipline,
much younger, for instance, than the popular traditional finite element
programs in wide use today.
Existing codes may be vectorized and sometimes
even parallelized; but that does not mean that they are truly vector/parallel.
Vectorizing a code means re-arranging it to place related data into contiguous
memory locations so that a vector machine may access it quickly and conveniently
in long strings. Parallelizing a code means examining it for operations
that may be performed independently of each other, and doling them out
for simultaneous computation on multiple processors.
Most today's workstations do not use traditional
vector architecture, relying instead on RISC architecture of the processor,
with large and fast instruction/data caches, and multiple instruction pipelines.
Optimizing compiler (C/C++ or FORTRAN) translates the source code into
the proper assembly code, and the best results are usually obtained for
the code designed for traditional vector architectures, with short simple
loops and access to consecutive memory locations (which optimizes the use
of pipelining and local data cache).
A vector/parallel code is one that is designed
and constructed for both vector and parallel efficiency, from the beginning.
Altair Engineering application codes are built on a vector/parallel PHLEX
kernel.
-
Post-Processing for
Computational Mechanics
The requirements for the presentation of hp-adapted
results could not be fulfilled by commonly available packages. As a consequence,
we have developed a very sophisticated module for the interactive presentation
of complex three dimensional finite element results. Our postprocessor
and its underlying graphics library are machine independent, use modern
graphics hardware if available, and can display high quality results even
on simple color terminals using standard X-window technology. They provide
novel non-standard functionality needed for interactive volume visualization
on high-performance workstations.
The package is currently tuned for Finite
Element models with mixed element types (fully unstructured meshes consisting
of Hex, Tet, and Prism elements resulting from hp-adaptivity, as well as
traditional Finite Elements: beams, rods, shells, etc.); but due to its
very precise, yet flexible, interface, it can be easily used for Finite
Volume, Finite Difference or other similar applications. Recently it has
been extended to handle results obtained with the meshless techiques. The
graphics
and postprocessing package displays:
-
meshes, with a 3D element cursor allowing
interactive selection of individual elements for inspection,
-
light shaded 3D solids,
-
arbitrary planar slices of the solution components
and derived functions,
-
isosurfaces of the solution (possibly colored
by another component),
-
solutions on the model boundary,
-
vectors of velocity / deflection,
-
particle traces,
-
streamlines,
-
deformed configurations,
-
plots of the solution along arbitrary segments
(XY plot),
-
and plots clipped by front/back clipping planes
or by an arbitrary bounding box.
Database Management
for Computational Mechanics
The fundamental core of any program is its
database. (Without data, we have nothing to compute.) The COMCO PHLEX kernel
relies upon a database organized loosely into an object-based data structure.
Drawing on some of the features of Object Oriented Programming, we treat
data fundamentally as abstract data types (Objects) and operate upon them
in a generic fashion (i.e. as Objects, without regard to their content).
Emphasis is placed on the data of the problem, and the relationships between
that data. In fact, we design the data structures before the algorithms
themselves are considered. Typical Objects include elements, circular queues,
solver groups, etc. And while the data for these Objects is widely different,
they are handled through a common interface. The data handling code consists
of four distinct parts:
-
The Object Data Dependent Code Generator (dsmake);
A mechanism for translating an ASCII text file description of Object specific
data into Object dependent code. This generator, and the code it generates,
are hidden from view to the code developer and provide the concrete, data
specific interface which is necessary for data manipulation.
-
The Object Data Independent Interface; A scheme
for organization and symbolic representation of the data as applied to
the generated code. This interface allows the code developer to manipulate
Objects in a generic, abstract sense. Built-in Object Browser allows fast
debugging and tracing errors in the database. Objects can be grouped in
linked lists, arrays, and logical sets. Extensive Set module allows to
define various membership criteria (e.g. all elements with given material,
or nodes within given bounding box) and create derived sets using Boolean
arithmetic (inside the code or from the GUI form). All resulting sets can
be used in the solution process (e.g. solve the stresses inside the bounding
box), adaptivity (estimate errors and adapt all elements of a given set)
and postprocessing (display temperature and pressure on the boundary of
subset of elements with given rock properties)
-
Input syntax interpreter, which allows easy
introduction of new data Objects (meterial properties, boundary conditions,
loads, etc), which are automatically accessible from the free format input
data files (gridfiles). Components of such Objects can contain references
to arbitrary functions (e.g. viscosity dependent on the temperature, or
pressure load varying in time and/or space). Functions can be defined in
the gridfile as tables or arithmetic expressions.
-
Save/restart functionality with automatic
backward capability. This feature is very important in the adaptive code,
where the database changes dynamically during the solution process. Complete
snapshot of the database can be saved to the disk file (including Objects
containing memory references to other Objects) in binary or text format
and later used to continue the solution process, possibly on different
computer (e.g. solve on CRAY and postprocess on PC). Automatic backward
capability allows to read savefiles generated using previous versions of
the code, accounting for differences of Objects' definitions between releases.
The final product is a database which requires
very little human intervention to generate and maintain, with the minimization
of possible code errors due to some local data modification.
Questions, comments or problems regarding this service? .
Copyright 1998-2002
Altair Engineering Inc.
7800 Shoal Creek Blvd, Suite 200N, Austin TX, 78757-1031 USA.