NAME
Indicators - on/off indicators for a set of items (nodes/ele
ments)
INCLUDE
include "Indicators.h"
SYNTAX
class Indicators : public HandleId
{
friend class GridFE;
friend class GridLattice;
private:
MatSimple(char) indicators; // preliminary storage management
VecSimple(String) names; // names of indicators
int nind; // number of indicators
int nitems; // no of objects that have an indicator
bool valid (int ind) const; // checks indicator: 1 <= ind <= nind
public:
Indicators ();
Indicators (int nitems_, int nind_) { redim(nitems_, nind_); }
Indicators (const Indicators& b);
~Indicators () {}
bool ok () const;
bool redim (int nitems, int nind);
void grow (int no_of_additional_inds);
void copyNames (const Indicators& b);
void operator= (const Indicators& b);
String getName (int ind) const;
void putName (const String& name, int ind);
void print (Os os) const;
int getNoInds () const { return nind; }
void set (int item, int ind);
void clear (int item, int ind);
void setCode (int item, long int code);
long int getCode (int item) const;
static long int intersectionCode (long int code1, long int code2);
bool on (int item, int ind) const;
void fill (bool onoff)
{ onoff == OFF ? indicators.fill('0') : indicators.fill('1'); }
void redefine (Is is);
MatSimple(char)& indicatorAccess() { return indicators; }
static void splitDigits (long int number, VecSimple(int)& digits);
};
KEYWORDS
indicators, boundary, boundary indicators, finite element, mark
boundary nodes, mark elements, subdomains, material properties
DESCRIPTION
The class enables on/off marking of the entries (items) in a set.
The most popular use in Diffpack is for marking boundary nodes in
finite element meshes. Each boundary node can then be marked with
user chosen indicators. Usually, these indicators are used for
setting boundary conditions or marking certain parts of the
boundary for plotting. The Indicators class can also be used for
marking elements, e.g., defining subregions of a grid in domain
decomposition methods. We use item as a term in the documenta
tion of this class, and item can be a node or an element (or
other quantities).
The user can define (in terms Indicators) a set of indicators and
give names to these.
Class Indicators is often usually used from GridFE objects. In
that case there is no need for a programmer to operate on Indica
tors objects directly. However, if one wants to have several
sets of boundary conditions (indicators) for a single GridFE
object, e.g. when systems of PDEs are solved, one can have a vec
tor of Indicators objects and set the indicators in the Indica
tors entries of this vector. Each entry can be attached to the
GridFE object.
CONSTRUCTORS AND INITIALIZATION
There is one constructor without arguments. If this is used, the
redim function must later be called. The other constructor is
simply a call to the redim function. After the internal data
structure is redimensioned, it must be filled with proper values.
The functions set and clear, redefine, or operator= can be used
for this purpose. Note that a boundary indicator at a node (or
more generally for an item) is either ON or OFF (true or false).
All the boundary names should also be given string values using
the function putName.
MEMBER FUNCTIONS
set - sets the indicator for an item to ON value (true).
clear - sets the indicator for an item to OFF value (false).
on - returns the state (ON/OFF, true or false) of an indicator
for an item.
fill - initializes all items and indicators with an ON or OFF
value.
grow - add new indicators to this object. They are set OFF as
default and they get the default names boindX, where X is the
indicator number.
putName - assigns a name to an indicator.
getName - returns the string containing the name of an indicator.
copyNames - for an already redimensioned Indicators object, this
function initializes the names of the indicators by the names in
another Indicators object.
setCode, getCode - these functions allow the information about
indicators for a given item (node/element) to be condensed in a
long int according to a particular code. If there are m indica
tors the code reads 2x1...xm, where x1 to xm are 0 or 1 according
to whether an indicator is off or on. For example, 200101 means
that there are 5 indicators and for this item the first two are
off, the third and fifth are on, and the fourth is off. Some
preprocessors require input files where it is difficult to assign
separate numbers reflecting the indicators for each boundary node
and then the condensed code can be useful.
redefine - makes it possible to redefine the indicators, that is,
define a mapping between old and new indicators. Assume that we
have three boundary indicators and that we want to map these
three indicators over to a new set of four indicators. The new
indicator 1 consists of nodes subjected to old indicator 1 or 3,
the new indicator 2 should be empty, the new indicator three is
identical to old indicator three, while the new indicator four
should consist of all the old indicators. Let the names of the
new indicators be "green, blue, red and black. The mapping is
defined by the following string which can be sent as argument to
redefine.
nbind=4, names= green blue red black 1=(1 3) 2=() 3=(3) 4=(1
2 3)
The names must be surrounded by blanks, only the two first equal
ity signs and the parenthesis are significant in the scan process
(thus the commands nbind, names, 1, 2 and 3 are never checked).
Old indicator numbers must be inside parenthesis and separated by
blanks. A equivalent string is
=4 =green blue red black (1 3)()(3)(1 2 3)
but less readable.
intersectionCode - determines the intersection of two set of
boundary indicators, represented as 2001001-type of codes (see
setCode, getCode). The function is typically used when assigning
boundary indicators to points along a segment, where only the
boundary indicators at the end points are known. Each point on
the segment should have the indicators that are ON at both end
points (i.e. it equals the intersection of the two codes).
splitDigits - given an integer number, the routine extracts each
digit from this integer and stores them in an int vector digits.
This is a static general purpose function that can be used in
many other contexts.
EXAMPLES
Suppose you solve the Laplace equation and have homogeneous Neu
mann conditions at part 1 of the boundary and prescribed Dirich
let conditions at part 2. You can then introduce two boundary
indicators, with names Dirichlet (1) and Neumann (2), go through
all boundary nodes and mark each node with one of the indicators.
Indicator 1 then corresponds to the Dirichlet condition. In this
example, nitems equals the number of nodes and nind equals 2.
Alternatively, since homogeneous Neumann conditions are trivially
implemented in a standard finite element method for the Laplace
equation, one can skip indicator 2 above and work with one indi
cator only. However, when plotting the boundary (for example
using the drawgrid program) it is advantageous to have marked all
nodes on the boundary with some indicator. If not, the complete
boundary cannot be plotted. You can of course introduce more
indicators than used for the numerical computations. For plotting
purposes it is often convenient to have some additional indica
tors for marking parts of the boundary that are particularly rel
evant when the boundary is plotted.
Here is an unconventional application of class Indicators. Sup
pose you solve a Stefan problem coupled with fluid flow problem,
for example, the energy equation (with phase transition) coupled
with the incompressible Navier-Stokes equations. Parts of the
flow domain will then freeze and at all nodes where the tempera
ture is below the freezing point the fluid velocity should be
zero. This can be conveniently implemented by introducing a spe
cial boundary indicator frozen and mark all nodes whose tempera
ture is below the freezing point. If the frozen indicator is used
for prescribing essential boundary conditions in the Navier-
Stokes solver, it is trivial to force the no velocity constraint
at these nodes.
SEE ALSO
class GridFE, class GridFEInfo
DEVELOPED BY
SINTEF Applied Mathematics, Oslo, Norway, and University of Oslo,
Dept. of Mathematics, Norway
AUTHOR
Hans Petter Langtangen, SINTEF/UiO