Object-Oriented Finite Elements

Principal Contributors:

Steve Langer Andrew Reid Rhonald Lua

Seung-Ill Haan Edwin Garca Valerie Coffman

Enthusiasts:
Andrew Roosen, NIST/CTCMS

Jim Warren, NIST/CTCMS

Zi-Kui Liu, PSU/MatCASE

Ron Boisvert, NIST/ITL Ed Fuller, NIST/MSEL Craig Carter, MIT

OOF2 on One Page

Why OOF2?

Commercial FEM packages exist, but are

best suited to domains with clean mathematical descriptions.

microstructure affect aggregate properties?

Materials scientists ask, How does Irregular structure is important

microstructural FEM mesh in a commercial code

It's possible but tedious to construct a

Why OOF2?
OOF2 offers: Rapid construction of meshes adapted to irregular microstructural geometries

science terms

Constitutive rules expressed in materialsUser extensibilty of constitutive rules User-friendly GUI, command-line, or remote Convenient parametric variations

operating modes

virtual experiments

OOF1 vs OOF2
OOF1 was the first cut at building an adaptible, exensible, materials-science oriented FEM tool
Proved numerous mesh-adapting tools for Proved large potential scope through customized

triangular meshes

versions constructed by Edwin Garca

Proved trickiness of adaptable software

Diffusion, piezoelectricity, electrochemistry

Present Scope

Flux equals coefficient times field derivatives

Divergence of flux equals source

System

Elasticity Stress Cijkl Displacement Force

Conductivity Heat flux ij Temperature Heating rate

Thermal Electrostatics Polarization ij Voltage Charge

k f

Present Scope
Also includes couplings

Piezoelectricity Thermal Expansion

System

Elasticity Stress Cijkl Displacement Force

Conductivity Heat flux ij Temperature Heating rate

Thermal

Electrostatics Polarization ij Voltage Charge

k f

Future Scope
Near term: Time-dependent problems

Inequality constraints

1st and 2nd order in time

All of solid mechanics

Parallelization for large systems 3D prototype (batch mode) Application-driven development

(creep, plasticity, etc.)

Longer term: New equation classes

Interactive 3D with GUI

Helmoltz, Wave

Future Scope

User-supplied: Library of values for existing properties

Code for new properties New materials Application-driven refinements

Conceptual Organization
Material Image

Collection of properties

Associates colors with pixels

Microstructure Skeleton Mesh

Associates materials with pixels Contains pixel groups, selection, active area

Geometry of mesh Element, segment, node selections, groups

Equations, fields, boundary conditions Interpolation, stiffness matrix construction

Solution data

Conceptual Organization
Materials: Made up of properties Properties: Constitutive rules mapping fields to fluxes (mostly)

User-quantified at run-time

User-extensible

Several different formats

e.g. Elastic stiffness, thermal conductivity, orientation, color

Conceptual Organization
Image: Chronologically first

Originates outside of OOF2

Approximation to microstructure

Basic image task is to segment the image into material regions

Conceptual Organization
Microstructure: Highest level container object

Analog of document in e.g. presentation code Hosts pixel selections and groups

Maps pixels to pixel attributes, including materials Can be displayed using material color

Conceptual Organization
Skeleton: Contains proto-elements, segments, nodes

Has selection state

Nodes only at corners

microstructure

Has numerous tools to adapt it to Maintains history undo capability

For both selections and modifications

Basic skeleton task is to adapt FE geometry to microstructural geometry

Conceptual Organization
Mesh: Hosts the physics of the problem

Equations, fields

Has boundary conditions

Builds the master stiffness matrix Calls properties to compute flux contributions

Basic mesh task is to implement the physics of the problem under study

Conceptual Organization
Solution: Point of the exercise!

Numerous tools for examining OOF data Fields, fluxes Imaging

Pointwise, statistical Contour maps

Solution Operations
Build the linear system: For each element

For each integration point

Determine local mapping from fields to fluxes

Repeat for right-hand-side data

Make incremental contribution to master matrix

Body forces, Neumann boundary conditions

Solution Operations

Dirichlet

Boundary Conditions

Neumann

Force a field to have particular values along a boundary Force a flux's normal component to have particular values along a boundary

Floating

Force

Require a field to have a particular profile, allow profile to relax Apply specified point forces at particular nodes

Future expansion plans include periodic and mean field BCs

Solution Operations
Boundary Conditions

Dirichlet and Float conditions divide up the matrix Neumann and Force conditions contribute to rhs

Independent equations Dependent equations Fixed degrees of freedom

Solution Operations
Symmetrization Symmetric matrices converge faster! Impossible if properties are not symmetric

Possible but not guaranteed if they are

Collect conjugacy data from properties Re-order equations to enforce symmetry Detect this, use symmetric solvers (e.g. CG)

Solution Operations

Plane Flux (e.g. plane stress)

Implemented as a set of auxiliary nodal equations Satisfied on average over a mesh shape function Not satisfied pointwise everywhere on the mesh

Prior knowledge of constitutive rule required for this

Solution Operations
Solve the linear system: Iterative sparse solvers

Choice of preconditioners

Conjugate Gradient, GMRES, ... ILU, IC, ...

Place solution field values in mesh object Iterate forward (time-dependent case)

Repeat high-level iteration (nonlinear case)

Solution Operations

Solvers: Currently using SparseLib++ solver set

Hard part of parallelization

Promising results with PETSc parallel solvers

Good experience with preconditioners, solvers

Solution Operations
Analysis Several built-in analytical tools

Choice of domains

Point-wise data output

Element sets, rectangles, cross-sectional cuts Scalars (e.g. stress invariants)

Statistical output

Aggregates (e.g. all stress components) Average, standard deviation

Solution Operations
Analysis
E.g. 2nd tensor invariant of shear along vertical cross section

Uses element-aware sampling, discontinuties clear

Architecture

Written in a combination of Python and C++ Does not use NumPy, SciPy Python and C++: Free, multiplatform

Object-oriented Mostly stable

Python: Flexible

Dynamic (duck typing) Many available libraries

SWIG

C++: Many standard tools

Fast executables

Even more libraries

Architecture
Size:
%date %WedAug1611:51:40PDT2006 %cdSRC %find.name'*.py'|xargswc|tail1 996093386453812236total % %find.name'*.C'oname'*.h'|xargswc|tail1 613592186361875088total % %find.name'*.swg'|xargswc|tail1 883927754239741total %_

Raw line-count includes duplicate disclaimers, import lines, comments, etc. Source tree traversal omits testing code, worked examples, prototypes, etc.

Architecture
Dependent packages/libraries: SparseLib++ (integrated into source)

Distutils (included with Python) SWIG (build-time only) PyGTK

GnomeCanvas ImageMagick Blas/lapack Docbook MPI/PETSc

GTK2

Not required for current release

Architecture
SWIG and Shadow Classes
Reprise of classfile.h

classfile.h

classfile.swg
from SWIG import classfile cobj = classfile.Object() cobj.operate(argument) ...

classfile.C classfilecmodule.C classfile.py

SWIG-generated shadow classes provide access to C++ objects

Architecture
All consequential operations are expressed in terms of commands from a hierarchical menu
Root of the menu tree

OOF.Command.Subcommand(arg1=value1,...)
Path to specific menu item Arguments for menuitem callback

This command locates the menuitem in the tree, and argument, appending the specified keyword arguments invokes its callback with the item itself as the first

Architecture
The menuitem tree is extensible at runtime. Some objects, when created, create their own submenus
Menuitems: Have parameter objects

Typed containers with default data One per expected argument Specified or inherited Threadability, hiddenness, etc. Operate on lower-level objects

Have options

Have callbacks

Architecture
Operating Modes:

GUI Mode:

GUI objects register to receive switchboard signals Button callbacks build argument objects, invoke menuitems Menuitem callbacks do work, indicate object state changes by sending switchboard signals

Command-line mode:

User builds arguments, types menu commands Menuitem callbacks as before This design makes the GUI separable

Possible to run without it Simplifies replacing it with another widget set

Architecture
Parameter objects: Typed container objects

Subclass of Parameter for contained type May contain more than one type, e.g. int or None

Have default values

Know how to make widgets for themselves

make_widget method added by GUI import builds a ParameterWidget subclass

GUI callbacks know menuitem parameters, can fill them by interrogating the widget, calling getvalue when OK is pressed...

Architecture
Parameters are too simple for some complex objects Registered Class Objects: Objects specified by a class and several parameters

Too big/stateful to keep instances around

Store parameters in Registration subclass object Resembles Factory pattern

List of all registered subclasses known

registry list is class data in Registration subclass

Architecture
Registered Class Factory: Widget for building RegisteredClass subclass objects

Has top-level widget which selects subclass Capable of convertibility

Fills in table of widgets for registration parameters Object may have different representations

e.g. RGB vs. HSV vs. Grayscale for colors

Parameters and Registered Classes support a high level of extensibility through automatic generation of widgets by assembling low-level make_widget objects

Architecture
Python/C++ boundary One advantage of our approach is that we can place the language boundary in different places according to flexibility or performance requirements

GUI in Python (PyGTK linkage, user-time, flexibility)

Exception: GnomeCanvas (absence of wrappers, speed)

Menu tree in Python (user-time, dynamic option assignments) FE geometry represenation in Python (flexibility)

Possible peformance problem, may be changed

FE physics represenation in C++ (maturity, speed) FE matrix construction in C++ (SparseLib++ linkage, speed)

OOF2 Summary

Modular open-source tool for materials modeling

Friendly to complex microstructural geometries User extensibilty of constitutive rules

Users explore structure-property relationships

Constitutive rules expressed in materials-science terms User-friendly GUI, command-line, or remote operating modes Python scriptability loops and conditionals

virtual experiments

DANSE connection(?)

For DANSE:

Microstructrure modeling capability for DANSE engineering diffraction subproject Already modular

For OOF:

Easy to fit into Pyre?

Materials/properties input Contributed code? Increased user base, exposure

Good second-order effects