OOF2: The Manual

Chapter 8. Writing OOF2 Extensions

[Warning] Warning

This chapter has not yet been updated for OOF2 version 2.1. A partial discussion of the differences between the 2.0 and 2.1 extension APIs may be found at http://www.ctcms.nist.gov/oof/oof2/property_api_21.html.

This chapter describes the contents of the source files for OOF2 extensions. Chapter 7 describes how to assemble the source files into a loadable extension module.

8.1. Adding New Fields, Fluxes, and Equations

New Fields, Fluxes, and Equations can be added with just a few lines of Python code. The OOF2 Field, Flux, and Equation classes represent global objects — there is only one instance of the Temperature field, for example, although the field may be defined on more than one Mesh, or on none at all. Creating a Field, Flux, or Equation object makes it available for use in a Mesh, and records some information about it, such as its name and dimension.

To create a Field, Flux, or Equation, simply create an object by calling its (Python) constructor,[47] and pass the object to the function problem.advertise. problem is a module in oof2.engine. For example:

from oof2.engine import problem
from oof2.SWIG.engine import field
problem.advertise(field.ScalarField("Temperature")) 

OOF2 predefines some Fields, Fluxes, and Equations in SRC/engine/problem.py. Refer to that file for examples.

The Field subclasses defined in oof2.SWIG.engine.field are:

These classes actually define CompoundFields, which represent the in-plane part of a Field. All of the Field class methods, when applied directly to a CompoundField, act on the in-plane part (which is why the vector field is called TwoVectorField. The out-of-plane part, which is also a Field object, is accessible through the CompoundField's out_of_plane method.

The Python function getCompoundField(name) in the oof2.SWIG.engine.field module returns the CompoundField with the given name. After

tfield = problem.advertise(field.ScalarField("Temperature")) 

the function call field.getCompoundField('Temperature') returns an object identical to tfield.

The Flux subclasses defined in oof2.SWIG.engine.flux are:

The Equation subclasses defined in oof2.SWIG.engine.equation are:

The Equation constructors each take a name, a Flux, and a dimension. The name allows Equations to be retrieved via the Python function getEquation(name) from oof2.SWIG.engine.equation. The Flux is the Flux that the Equation operates on, and the dimension is an integer specifying how many components the equation has. (The divergence of a vector Flux has one component, and the divergence of a tensor flux has three components. A PlaneFluxEquation has as many components as there are out-of-plane components of the associated Flux.)

The Python form of the DivergenceEquation constructor also can take optional arguments specifying whether or not the Equation contains first-order (kinetic) or second-order (dynamic) time derivatives. This facility is still under development, and so the documentation is incomplett.

As an example, the following code fully defines the quantities necessary to solve the static heat conductivity problem (except for the thermal conductivity Material Property, which is discussed later).

from oof2.engine.problem import advertise
from oof2.SWIG.engine.field import ScalarField
from oof2.SWIG.engine.flux import VectorFlux
from oof2.SWIG.engine.equation import DivergenceEquation, PlaneFluxEquation

Temperature = advertise(ScalarField('Temperature'))
Heat_Flux = advertise(VectorFlux('Heat_Flux'))
HeatBalanceEqn = advertise(DivergenceEquation('Heat_Eqn', Heat_Flux, 1))
HeatOutOfPlane = advertise(PlaneFluxEquation('Plane_Heat_Flux', Heat_Flux, 1))
      



[47] Fields, Fluxes, and Equations are C++ classes, but they should be instantiated by calling their swigged Python constructors.