Abstract class Dof represents Degree Of Freedom in finite element mesh.
DOFs are possesed by DofManagers (i.e, nodes, element sides or whatever) and
one Dof instance belongs to only one DofManager instance.
Dof maintain its physical meaning and reference to
related DofManager (reference to DofManager which possess particular DOF).
To describe physical meaning of particular Dof, special enum type "DofId" has
been introduced (see cltypes.h). This type is more descriptive than
UnknownType, which determines physical meaning for unknowns generally
(displacement or temperature). DofId type has to distinguish between
DOFs representing displacement, but in different directions, since
only some of those may be required by particular elements.
Dof can be subjected to boundary (BC) or initial (IC) condition. Method for
obtaining corresponding DOF unknown value is provided. If no IC condition
has been given, zero value IC is assumed otherwise when needed.
Dof class generally supports changes of static system during computation.
This feature generally leads to equation renumbering. Then because equation number
associated to dof may change, it may become extremly complicated to ask EngngModel
for unknown from previous time step (because equation number may have been changed).
To overcome this problem, derived class will implement so called uknown dictionary,
which is updated after finishing each time step and where unknowns for particular
dof are stored. Dof then uses this dictionary for requests for unknowns instead of
asking EngngModel for unknowns. Unknowns in dof dictionary are updated by EngngModel
automatically (if EngngModel supports changes of static system) after finishing time
The base class Dof declares many services necessary for DOF
handling. Some of them are abstract, they have to be implemented by
derived classes representing ``specialised'' DOF types.
This basic DOF interface includes the following services
- Services for requesting corresponding unknowns (giveUnknown)
and the prescribed boundary values (giveBcValue).
- Methods for requesting associated equation number
- Services for requesting DOF properties (hasBc,
hasIc, giveDofID, giveDofIDName,
- Services for dof output (printOutputAt, printStaticOutputAt,
printDynamicOutputAt), update after new equlibrium is reached
(updateYourself, updateUnknownsDictionary) and
services for storing/restoring context (saveContext, restoreContext).
The derived classes should implement specific types of DOFs. The
most common types are provided with OOFEMlim. Supported are so-called
MasterDofs, representing true DOFs with their own equation number,
Slave DOFs, representing single DOF linked to onother single DOF, Rigid Arm Dofs
allowing to model rigid arms (single dof linked to one or more other DOFs).
Their brief description follows:
- MasterDof - class representing "master" degree of freedom.
Master is degree of freedom, which has its related unknown and
corresponding equation number. It maintain its equation number.
- SlaveDof - class representing "slave" degree of freedom.
Slave dof is linked to some master dof (link slave-slave is not
allowed). Slaves can be used to implement duplicated joints (by
specifying some dof in node as masters and some as slaves linked to
dofs in other node (with same or possibly different
coordinates). Slave dof share the same equation number with
master. Almost all operation as request for BC or IC or equation
number are simply forwarded to master. Other functions (which change
internal state) like updateYourself, updateUnknownsDictionary,
askNewEquationNumber or context storing/restoring functions are empty
functions, relying on fact that same funtion will be called also for
master. From this point of wiev, one can see slave dof as link to
- RigidArmSlaveDof - class representing "rigid arm slave" degree
of freedom. This DOF is linked to some master DOFs by linear
combination (link slave-slave is
not allowed) using rigid arm. Implemented using nodal
transformation. The Rigid Arm Slave dof represent DOF, which is
directly related to one or more master DOFs. Therefore the rigid arm slave's
equation number is undefined. Similarly, rigid arm slave cannot have
own boundary or initial conditions - these are entirely detrmined
using master boundary or initial conditions.
The transformation for DOFs and load is not ortogonal - the inverse
transformation can not be constructed by transposition. Because of
time consuming inversion, methods can generally compute both
transformations for dofs as well as loads. It is important to ensure
(on input) that both slave dofManager and master dofManager are using
the same local coordinate system. In future releases, this can be
checked using checkConsistency function, where this check could be