Index

NAME

HandleElmDefs - a class that replaces Handle(ElmDef)


INCLUDE

include "HandleElmDefs.h"

SYNTAX

 class HandleElmDefs : public Handle(ElmDef)
 {
 protected:
   String      elm_tp;
   ElementType et_enum;
   int         nsd;

   Handle(ElmDef_prm) elm_prm;

 public:

   HandleElmDefs () { detach(); elm_prm = ElmDef_prm::construct(); }
  ~HandleElmDefs () {}

   void detach ()
     { rebind(NULL); elm_tp="dummy"; et_enum = NO_ELEMENT; nsd = 0; }

   bool refill (const String& elm_tp, int nsd);
   bool refill (const String& elm_tp);
   bool refill (const ElementType et_enum, int nsd); // more efficient
   bool refill (const ElementType et_enum);          // more efficient

   void operator= (const HandleElmDefs& h)
     { classptr=h.classptr; nsd=h.nsd; et_enum=h.et_enum; elm_tp=h.elm_tp; }
 };



KEYWORDS

finite element, specialized handle



DESCRIPTION

Declaration  and application of a finite element object (from the
ElmDef hierarchy) are handled by the HandleElmDefs  class.   This
class  is a subclass of Handle(ElmDef) and contains, in addition,
information about the current element being  handled,  such  that
creation  of a new identical element can be avoided.  One can say
that HandleElmDefs is a combination of a  Handle(ElmDef)  and  an
ElmDef_prm  class (with an understanding of handles and parameter
classes in Diffpack, this information should  explain  the  basic
purpose of class HandleElmDefs).

Having  a  HandleElmDefs object, one just calls the refill object
to create a new element (and if the element  is  already  created
and  therefore  can  be  reused,  refill  is smart enough to take
advantage of this knowledge).


CONSTRUCTORS AND INITIALIZATION

Only an empty constructor is provided. To initialize the  pointer
in  this handle, the refill member functions should be called. Do
not call the base class Handle(ElmDef)::rebind  function,  refill
will  administrate  all  such calls in the proper way. Of course,
the functions ok, operator() and operator->  that  are  inherited
from  class  Handle(ElmDef) can be used, only rebind and the Han­
dle(ElmDef) constructors should be avoided.



MEMBER FUNCTIONS

refill - on basis of the element type (and the  number  of  space
dimensions  if  the element is of tensor product type and defined
in an arbitrary number of space dimensions) the function  ensures
that the pointer in this handle points to an element of the spec­
ified type. The refill which use the enum variable ElementType as
argument  is  more  efficient then the corresponding refill which
use a String.


EXTENDING THE ELEMENT LIBRARY

To extend the element library, follow these points. (The  ElmDef*
type of files we refer to below are located in $DPS/dpK/fem.)

1.  Study the files ElmDefs.h and  ElmDefs.cpp to find an element
that is quite similar to the one you want to define. If possible,
derive  your new element from an existing element to enable reuse
of functionality (e.g. mixed triangular element can benefit  from
being derived from a standard triangular element).

2. Implement your new element in separate .h and .cpp files.

3. Copy the ElmDef_prm.h and ElmDef_prm.cpp files to the applica­
tion directory and (a) extend the list of enum names in  Element­
Type  in  "ElmDef_prm.h,  (b) extend the list of element names in
the ElmDef_prm constructor, (c) extend the  ElmDef::create  func­
tion with your new element.

NOTICE:  Usually new classes are added to Diffpack hierarchies by
deriving a subclass of the original parameter class. This is  not
possible with the ElmDef_prm class, because efficiency considera­
tions has forced us to use an enum table for the  element  names,
which  must  be replaced by a new hardcoded table if the contents
change.

4. Copy the files HandleElmDefs.h and HandleElmDefs.cpp  to  your
local application directory.

5.  Compile  the  application (all parts of the element hierarchy
that need to be updated  are  now  included  in  the  application
directory).



SEE ALSO

createElmDef



DEVELOPED BY

SINTEF Applied Mathematics, Oslo, Norway, and University of Oslo,
Dept. of Mathematics, Norway


AUTHOR

Hans  Petter  Langtangen,  SINTEF/UiO,  modifications   by   Klas
Samuelsson UiO