[Insight-developers] Dashboard errors: FEM & Mesh

[Luis Ibanez]

Hi Jim,

 A branch is certainly a good option...

That would make our work much easier,
so far the number of classes involved is about 15

We could take advantage of this for introducing some
MeshTraits reorganization that Brad have designed.

Should we go this way ?

---

About removing some template parameters from the
itk::Mesh here is the rationale:

We found that it is convenient to separate a FEM
problem in several isolated layers:

1) Geometry
2) Topology
3) Physics

For these layer we have now:

Geometry -> itk::PointSet
Topology->itk::Mesh

and the physics is being done byt the FEM classes
which currently do not use the itk::Mesh but import
all their geometrical configuration from an itk::Mesh.

The itk::Mesh is providing now the service of
managing additional data attached to every cell.
This additional data is in fact a representation of the
physical layer where a property is associated with every
cell (e.g. a temperature, a displacement or a color).

For the FEM code it is more convenient to manage
this data by creating itk::FEMElements deriving from
the itk::CellInterface.  The responsibility of managing
the physical values is transferred to the FEMElement.  
This is why we thougth it could be removed from the
itk::Cell.   Currently the itk::Cell is aware of the
CellDataType because it is providing the functionality
of interpolating these values.

For example, a Mesh that stores Temperatures as
Cell data values is capable of answering:

"What is the temperature at the parametric coordinates:
( 0.6, 0.7, 0.2 ) inside the cell  ? ".

This is in fact something that should be done at the
FEMElement level instead of the Cell level. The reason
for the separation is that you may want to have a triangular
cell that uses linear interpolation for representing its own
geometrical shape but uses higher order interpolation for
the Temperatures or you may want to use a Bezier triangular
path for representing the geometrical shape of the cell and
use linear interpolation for the Temperatures.

By moving code from the Cell to the Element we clearly
separate both behaviors. The Cells takes care of shape
and the Element takes care of Physics. We also got
the advantage of using polymorphism by plugging in different
kinds of Elementss and Cells.

The Cell is still responsible for interpolating the geometrical
shape of the mesh and keeping track of neighbors and
boundaries. That is, the itk::Mesh manages  "Topology"
and provide some geometrical services.


That leave us with the following organization:

- Geometry = itk::PointSet
- Topology = itk::Mesh
- Physics = itk::FEMMesh

This is experimental anyways...
                     so, all comments are welcome !

Another option that we are considering is to use the
CellDataContainer for storing the FEMElements.
The disadvantage of this approach is to have to keep
track of the association between FEMElement and its
corresponding Cell.  They have to be inserted in pairs
and removed in pairs. The advantage is that it will require
less modifications of the itk::Mesh related code.


If you have a chance to take a look at the classes in
Examples/FEMMesh we will appreciate any advice on
how to improve the design.


   Thanks

        Luis  



==========================================================

Miller, James V (CRD) wrote:

>Luis,
>
>Should this effort be done on a branch and merged back into the main tree
>once everything is working?
>
>Also, I am suprised that you needed to remove template parameters from Mesh
>in order to support FEM.
>
>
>