OOF2: The Manual

CompoundField
	Field Classes and Functions

Name

CompoundField — A Field with both in- and out-of-plane parts.

Synopses

Only those methods useful for extending OOF2 are listed here. Base class functions are described in the Field documentation.

C++ Synopsis

#include "engine/field.h"

class CompoundField: , public virtual Field {
  Field* time_derivative() const;
  Field* out_of_plane() const;
  Field* out_of_plane_time_derivative() const;
  bool in_plane(const FEMesh* mesh) const;
  bool in_plane(const CSubProblem* mesh) const;
}

Python Synopsis

from ooflib.SWIG.engine.field import CompoundField

class CompoundField(Field):
  def time_derivative(self)
  def out_of_plane(self)
  def out_of_plane_time_derivative(self)
  def in_plane(self, mesh)

Subclasses

Description

Most Fields that the user encounters in OOF2 are instances of CompoundField subclasses. A CompoundField is a Field that has been augmented with its out-of-plane parts and the time derivatives of its in- and out-of-plane parts. These auxiliary parts are Fields themselves, but they are not CompoundFields. See Section 2.5.5 for the details.

When a CompoundField is created, its out-of-plane and time derivative parts are created automatically. Their names are the name of the original CompoundField with a suffix appended: “_z” for the out-of-plane field, “_t” for the time derivative, and “_tz” for the time derivative of the out-of-plane field.

Because Field objects are accessible by name in the main OOF2 Python namespace, Creating a new CompoundField will create four new variables with names given by the names of the CompoundField and its auxiliary Fields.

All operations on a CompoundField operate on the in-plane part, unless specifically noted otherwise. That is, a CompoundField acts just like a regular Field, unless the auxiliary Fields are explicitly requested.

The C++ class hierarchies for CompoundField subclasses are actually moderately complicated, and are simplified somewhat in the documentation. An alert reader will notice that the out-of-plane part of a ScalarField can't be another ScalarField, because ScalarField is derived from CompoundField, but the out-of-plane part isn't compounded. However, for purposes of writing OOF2 extensions, such complications are just distracting. Readers who are interested in the details can consult SRC/engine/field.h.

A Possible Source of Confusion

	A Possible Source of Confusion
Iterating over the out-of-plane components of a `Field` is different than iterating over the components of the out-of-plane part of a `CompoundField`. Consider `Displacement`, which is a TwoVectorField with x and y components only. As such, it has no out-of-plane components — it has a z component that is implicitly zero: >>> list(Displacement.components()) [VectorFieldIndex(0), VectorFieldIndex(1)] >>> list(Displacment.components(OUT_OF_PLANE)) [] As explained in Section 2.5.5, the out-of-plane part of a `CompoundField` is the z derivative of all of its components (including its z components). For `Displacement`, that's a 3-vector: >>> list(Displacement.out_ouf_plane().components()) [VectorFieldIndex(0), VectorFieldIndex(1), VectorFieldIndex(2)] There is one out-of-plane component of the out-of-plane `Field`: >>> list(Displacement.out_of_plane().components(OUT_OF_PLANE)) [VectorFieldIndex(2)]

Iterating over the out-of-plane components of a Field is different than iterating over the components of the out-of-plane part of a CompoundField. Consider Displacement, which is a TwoVectorField with x and y components only. As such, it has no out-of-plane components — it has a z component that is implicitly zero:

>>> list(Displacement.components())
[VectorFieldIndex(0), VectorFieldIndex(1)]
>>> list(Displacment.components(OUT_OF_PLANE))
[]

As explained in Section 2.5.5, the out-of-plane part of a CompoundField is the z derivative of all of its components (including its z components). For Displacement, that's a 3-vector:

>>> list(Displacement.out_ouf_plane().components())
[VectorFieldIndex(0), VectorFieldIndex(1), VectorFieldIndex(2)]

There is one out-of-plane component of the out-of-plane Field:

>>> list(Displacement.out_of_plane().components(OUT_OF_PLANE))
[VectorFieldIndex(2)]

Methods

`Field *time_derivative() const`

time_derivative returns the Field containing the time derivative of the in-plane parts of a CompoundField.

`Field *out_of_plane() const`

out_of_plane returns the Field that contains the out-of-plane part (i.e, the z-derivatives) of a CompoundField.

`Field *out_of_plane_time_derivative() const`

out_of_plane_time_derivative returns the Field that contains the time derivative of the out-of-plane part of a CompoundField.

`bool in_plane(...) const`

in_plane indicates whether or not the CompoundField is constrained to be in-plane. In C++, the argument can be a pointer to either an FEMesh or a CSubProblem. In Python, the argument must be an FEMesh.

	Note
	The out-of-plane `Field` object belonging to a `CompoundField` is always created when the `CompoundField` is created. Whether or not the `CompoundField` is in-plane is determined by whether or not values for its out-of-plane field are stored in a mesh and allowed to be non-zero.


Field		ScalarField