\documentclass[11pt,a4paper]{article}
% allow both latex and PDFlatex compatibility  (from pdfTeX FAQ)
\usepackage{hyperlatex}

\usepackage{pifont}
\usepackage{amsmath}
\usepackage{amssymb}
%\usepackage{psfig}
\usepackage{array}
\usepackage{supertabular}
%\usepackage{fancyheadings}
\usepackage{float}
\usepackage{eepic,epic}
%\usepackage{pslatex} % devrait corriger le pb de fontes dans les pdfs mais le fichier produit n'est pas beau
\usepackage[english]{babel}
\usepackage{alltt}
\usepackage[english]{babel}
% \usepackage{textcomp]


\texonly{\newcommand{\tilda}{{$_{\widetilde{\ }}$}}}
\texonly{\newcommand{\tild}{{$_{\widetilde{\ }}$}}}
%\texonly{\newcommand{\tilda}{{\~{}}}}
\htmlonly{\newcommand{\tilda}{\verb+~+}}

\texonly{\usepackage{graphicx}
\usepackage{makeidx}
\usepackage[pdftex,pageanchor=true,hyperindex=true,pagebackref=true,pdfhighlight=/O,pdfauthor={Yves Renard}]{hyperref}%pour le pdf
\usepackage{xspace} % insere un espace si necessaire 
\usepackage{underscore}

\oddsidemargin -0.9cm
\evensidemargin -0.9cm
\topmargin -2.5cm
\textheight 24cm
\textwidth 17.6cm
\headheight 1.0cm
}
\makeindex


\T \newcommand{\Reel}{{\rm I\hspace{-0.15em}R}}
\W \newcommand{\Reel}{\htmlsym{real}}
\T \newcommand{\ds}{\displaystyle}
\W \newcommand{\ds}{}
\newcommand{\Frac}[2]{{\ds \frac{\ds #1}{\ds #2}}}

\T \newcommand{\icgraphic}[3] { \includegraphics[width=#1]{#2.pdf} }
\W \newcommand{\icgraphic}[3] { \htmlimg{#2.png}{#3} }

\T \newcommand{\equat}[1] { \begin{equation*} #1 \end{equation*} }
\W \newcommand{\equat}[1] { \begin{center} $ #1 $ \end{center} }


% \W .. is equivalent to \htmlonly{..}
\W \newcommand{\HlxIcons}{./}
%\W \usepackage{frames} % navigation panel
\W \htmldirectory{getfem_project}
\W \htmlname{getfem_project}
\W \setcounter{htmldepth}{2}
\W \setcounter{htmlautomenu}{2}
\W \renewcommand{\HlxMeta}{\xml{META description="getfem++ user manual"}}
\htmlonly{%
  \htmlpanelfield{Index}{getfem_project}
  \htmlcss{docstyle.css}
  \newcommand{\text}[1]{\mathrm{#1}}
  \newcommand{\WEB}[2]{\xlink{#2}{#1}}
  \newcommand{\nabla}{\htmlsym{nabla}} % renamed \xmlent by lastest version of hyperlatex
  \newcommand{\ell}{\htmlsym{tau}}
  \newcommand{\lambda}{\htmlsym{lambda}}
  \newcommand{\varepsilon}{\htmlsym{epsilon}}
  \newcommand{\phi}{\htmlsym{phi}}
  \newcommand{\varphi}{\htmlsym{phi}}
  \newcommand{\psi}{\htmlsym{psi}}
  \newcommand{\sigma}{\htmlsym{sigma}}
  \newcommand{\nu}{\htmlsym{nu}}
  \newcommand{\beta}{\htmlsym{beta}}
  \newcommand{\gamma}{\htmlsym{gamma}}
  \newcommand{\alpha}{\htmlsym{alpha}}
  \newcommand{\Gamma}{\htmlsym{Gamma}}
  \newcommand{\Delta}{\htmlsym{Delta}}
  \newcommand{\delta}{\htmlsym{delta}}
  \newcommand{\Omega}{\htmlsym{Omega}}
  \newcommand{\omega}{\htmlsym{omega}}
  \newcommand{\otimes}{\htmlsym{otimes}}
  \newcommand{\prod}{\htmlsym{Pi}}
  \newcommand{\tau}{\htmlsym{tau}}
  \newcommand{\partial}{\htmlsym{part}}
  \newcommand{\sum}{\htmlsym{sum}}
  \newcommand{\subset}{\htmlsym{sub}}
  \newcommand{\int}{{\Large\htmlsym{int}}}
  \newcommand{\tild}{~}
}
\texonly{
  \newcommand{\WEB}[2]{\href{#1}{#2}}
}
\T \newcommand{\Div}{\textrm{div}}
\W \newcommand{\Div}{div}
\T \newcommand{\Grad}{\textrm{grad}}
\W \newcommand{\Grad}{grad}
\T \newcommand{\Rot}{\textrm{curl}}
\W \newcommand{\Rot}{curl}

\W \newcommand{\gf}{Getfem\mbox{++}\hspace{0.01em}}
\T \newcommand{\gf}{{\sc Getfem++}\xspace}
\W \newcommand{\gmm}{Gmm\mbox{++}\hspace{0.01em}}
\T \newcommand{\gmm}{{\sc Gmm++}\xspace}

\W \newcommand{\newpage}{}
\W \newcommand{\hspace}[1]{ }
\W \newcommand{\left}{} % pour les left\(i\right) 
\W \newcommand{\right}{}
\W \newenvironment{alltt}{\begin{example}}{\end{example}}
\T \newenvironment{cppcode}{\begin{alltt}}{\end{alltt}}
\W \newenvironment{cppcode}{\begin{rawxml}<div class="cppcode">\end{rawxml}\begin{example}}{\end{example}\begin{rawxml}</div>\end{rawxml}}

\T \newcommand{\cpp}[1]{\texttt{#1}}
\T \newcommand{\filename}[1]{\texttt{#1}}

%doxfilename and doxref : used by doxygenlinks.tex
\T \newcommand{\doxfilename}[2]{\texttt{#1}}
\T \newcommand{\doxref}[2]{\cpp{#1}}

\W \newcommand{\cpp}[1]{\xmlattributes*{tt}{class="inlinecppcode"}\texttt{#1}}
\W \newcommand{\filename}[1]{\xmlattributes*{tt}{style="color:red"}\texttt{#1}}
\W \newcommand{\doxfilename}[2]{\xmlattributes*{tt}{class="inlinecppcode"}\texttt{\WEB{../getfem_reference/#2.html}{#1}}\xspace}
\W \newcommand{\doxref}[2]{\xmlattributes*{tt}{class="inlinecppcode"}\texttt{\WEB{../getfem_reference/#2.html}{#1}}\xspace}

\T \newenvironment{ctableau}[2]{\begin{center}\begin{supertabular}{#1}}{\end{supertabular}\end{center}}
\W \newenvironment{ctableau}[2]{\xmlattributes*{table}{border=1 align="center"}\begin{tabular}{#2}}{\end{tabular}}

\newcommand{\WEBB}[1]{\WEB{#1}{#1}}

\texonly{
  \newcommand{\femtab}[9]{
    \begin{center}
      \begin{tabular}{m{17cm}}
      \begin{tabular}{|m{16.109cm}|} \hline
        {\bf #1}\\
        {\tt #2} 
      \end{tabular} \\ \vspace{-0.12em} 
      \begin{tabular}{|m{2cm}|m{2cm}|m{2.5cm}|m{1.5cm}|m{1.5cm}|m{2cm}|m{2cm}|} \hline 
        Degree & dimension & d.o.f. number & class & vectorial & \mbox{$\tau$-equivalent} & Polynomial \\ \hline
        #3 & #4 & #5 & #6 & #7 & #8 & #9 \\ \hline
      \end{tabular}
    \end{tabular}
  \end{center}
  }
}

\htmlonly{
  \newcommand{\femtab}[9]{
    ~\\~\\
    \begin{center}
      \begin{ctableau}{|m{16.109cm}|}{c} \hline
        {\bf #1}\\
        {\tt #2} 
      \end{ctableau}
      \begin{ctableau}{|m{2cm}|m{2cm}|m{2.5cm}|m{1.5cm}|m{1.5cm}|m{2cm}|m{2cm}|}{lllllll} \hline 
        Degree & dimension & d.o.f. number & class & vectorial & \mbox{$\tau$-equivalent} & Polynomial \\ \hline
         #3 & #4 & #5 & #6 & #7 & #8 & #9
      \end{ctableau}
      ~\\
    \end{center}
  }
}

% macros for linking filenames and classnames to the doxygen doc of getfem
% (i.e. \getfemmeshh \dalbitvector etc.) 
% edit updatedoxlinks.py to add new types/files
\input{doxygenlinks.tex}



\begin{document}
\htmltitle{Getfem Project}
\htmlpanel{0}%disable navigation panel

\begin{center}
\texonly{
  \includegraphics[width=10cm,angle=0]{logogetfemwhitebg}\\[0.2cm]
  a Generic Finite Element library in C++ \\[0.5cm]
  {\LARGE Documentation, part \Huge 1} \\[0.5cm]
  \fbox{\Huge \sc Description of the project} \\[0.5cm]
  { \large Yves {\sc Renard}, Julien {\sc Pommier} \footnote{ \it ICJ - CNRS UMR 5208, INSA de Lyon, 20, rue Albert Einstein, 69621 Villeurbanne Cedex, FRANCE, Yves.Renard@insa-lyon.fr } } \\[1.0cm]
  \today \\[2cm]
}
\htmlonly{
  \xlink{\htmlimg{logogetfem.png}{The Getfem++ logo}}{http://home.gna.org/getfem/}\\[2cm]
  a Generic Finite Element library in C++ \par\par
  {\LARGE Documentation, part \Huge 1} \\ \par\par
  {\Huge Description of the project } \\ \par
  { \large \xlink{Yves Renard}{mailto:Yves.Renard@insa-lyon.fr}, \xlink{Julien Pommier}{mailto:Julien.Pommier@insa-toulouse.fr}}\\
  {\it ICJ - CNRS UMR 5208, INSA de Lyon, 20, rue Albert Einstein, 69621 Villeurbanne Cedex, FRANCE.}\\
  \today \par\par
}
\end{center}

% \begin{abstract}
% Basic user documentation for \gf .
% \end{abstract}
\htmlonly{\\\\\\}
\texonly{~\\[4cm]}
\begin{quote}
\input{../license.tex}
\end{quote}

\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%          INTRODUCTION                                                 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Introduction}

The \gf project focuses on the development of a generic finite element library.
The goal is to provide a finite element framework which allows to easily build  numerical code for the modelisation of system described by partial differential equations (p.d.e.). A special attention is paid to the flexibility of the use of the library in the sense that the switch from a method offered by the library to another is made as easy as possible.

The major point allowing this, compared to traditional finite element codes, is the complete separation between the description of p.d.e. models and finite element methods. Moreover, a separation is made between integration methods (exact or approximated), geometric transformations (linear or not) and finite element methods of arbitrary degrees described on a reference element. \gf can be used to build very general finite elements codes, where the finite elements, integration methods, dimension of the meshes, are just some parameters that can be changed very easily, thus allowing a large spectrum of experimentations. Numerous examples are available in the \filename{tests} directory of the distribution.

The goal is also to make the addition of new finite element method as simple as possible. For standard method, a description of the finite element shape functions and the type of connection of degrees of freedom on the reference element is sufficient. Extensions are provided for Hermite elements, piecewise polynomial, non-polynomial, vectorial elements and XFem. Examples of predefined available methods are Pk on simplices in arbitrary degrees and dimensions, Qk on parallelepipeds, P1, P2 with bubble functions, Hermite elements, elements with hierarchic basis (for multigrid methods for instance), discontinuous Pk or Qk, XFem, Argyris, HCT, Raviart-Thomas.

The library also includes the usual tools for finite elements such as assembly procedures for classical PDEs, interpolation methods, computation of norms, mesh operations, boundary conditions, post-processing tools such as extraction of slices from a mesh ...

\gf has no meshing capabilities (apart regular meshes, and a not exploitable attempt), hence, in many situations, it is necessary to import meshes. Imports formats currently known by getfem are GiD , GmSH and emc2 mesh files. However, given a mesh, it is possible to refine it automatically.

The aim of the \gf project is not to provide a ready to use finite element code allowing for instance structural mechanics computations with a graphic interface. It is basically a library allowing the build of C++ finite element codes. However, the matlab and python interfaces allows to easily build application coupling the definition of the problem, the finite element methods selection and the graphical post-processing.

The future of the project is to continue to develop the finite element framework, focusing on the following points.
\begin{itemize}
  \item Background consolidation of the existing modules (with a reflection on the optimal representation of meshes, degrees of freedom, finite element methods ...).
  \item Developpement of innovating methods.
  \item Reflection on the optimal way to represent complex p.d.e. models with the maximum of flexibility and reusability. The brick system is a first step in this direction.
\end{itemize}

The vocation of \gf is to remain a free open source project. The advantage given by the fact to be an open source project is that by proposing a free use, one profits from the experiments of the users who by their tests and the difficulties or bug which they meet make progress the robustness of the algorithms. One also profits from the possible contributions of the users who can find interest to develop new functinalities within the proposed framework. That allows constructive exchanges which clarify the weak points and the strong points of the project.


\newpage
\tableofcontents
\newpage

\section{Diagram of the library}

This section describes the diagram of the different modules of the \gf library.
The current state and perspective for each module is described in section \ref{sec:descmod}.


\begin{figure}[H]
  \begin{center}
    \icgraphic{0.9\linewidth}{diagram}{Diagram of \gf}
  \end{center}
  \caption{ \it Diagram of \gf}
  \label{fig:elemf}
\end{figure}

\newpage



\section{Introduction to the fem description in \gf}

The aim of this section is to briefly introduce the fem description in \gf mainly in order to fix the notation used in the rest of the document (definition of element, reference element, geometric transformation, gradient of the geometric transformation ...).


\subsection{Convex structures}

Finite element methods are defined on small convex domains called elements. The simplest element on which a finite element method can be defined is a segment (simplex of dimension 1), other possibilities are triangles, tetrahedrons (simplices of dimension 2 and 3), prisms, parallelepiped ...
In \gf, a type of element (for us, a convex) is described by the object \cpp{bgeot::convex\_structure} defined in the file \cpp{bgeot\_convex\_structure.h}.\\[0.5cm]
It describes only the structure of the convex not the coordinates of the vertices.
This structure is not to be manipulated by itself, because it is not necessary that more than one structure of this type describe the same type of convex. What will be manipulated is a pointer on such a descriptor which has to be declared with the type \cpp{bgeot::pconvex\_structure} \\ \\

The following functions give a pointer onto the descriptor of the usual type of elements:

\begin{center} \begin{ctableau}{|m{0.45\linewidth}|m{0.5\linewidth}|}{ll} \hline
 \cpp{bgeot::simplex\_structure(dim\_type d)} & description of a simplex of dimension \cpp{d}. \\ \hline
 \cpp{bgeot::parallelepiped\_structure(dim\_type\;d)} &  description of a parallelepiped of dimension \cpp{d}. \\ \hline
 \cpp{bgeot::convex\_product\_structure( bgeot::pconvex\_structure p1, bgeot::pconvex\_structure p2) } & description of the direct product of \cpp{p1} and \cpp{p2}.\\ \hline
 \cpp{bgeot::prism\_structure(dim\_type d)}  & description of a prism of dimension \cpp{d}  \texonly{\\ \hline}
\end{ctableau} \end{center}

For instance if one needs the description of a square, one can call equivalently\\
\cpp{p = bgeot::parallelepiped\_structure(2); }
or\\
\cpp{p = bgeot::convex\_product\_structure(bgeot::simplex\_structure(1),\\        ~ \hspace{18.5em} bgeot::simplex\_structure(1)); }\\

The descriptor contains in particular  the number of faces (\cpp{p->nb\_faces()}), the dimension of the convex (\cpp{p->dim()}), for the number of vertices (\cpp{p->nb\_points()}). Other information is the number of vertices of each face, the description of a face and the eventual reference to a more basic description (used for the description of geometric transformations).

\htmlonly{\label{fig:elem}}
\begin{figure}[H]
  \begin{center}
    \icgraphic{10cm}{getfemelemelem}{usual elements}
  \end{center}
  \caption{ \it Usual elements. }
  \texonly{\label{fig:elem}}
\end{figure}


\subsection{Convexes of reference}

A convex of reference is a particular real element, i.e. a structure of convex with a list of vertices. It describes the particular element from which a finite element method is defined. In the file \cpp{bgeot\_convex\_ref.h} the object\\[0.5cm]
\cpp{bgeot::convex\_of\_reference }\\[0.5cm]
makes this description. The library keeps only one  description for each type of convex. So what will be manipulated is a pointer of type \cpp{bgeot::pconvex\_ref } on the descriptor\\[0.5cm]

The following functions build the descriptions:

\begin{center} \begin{ctableau}{|m{0.55\linewidth}|m{0.4\linewidth}|}{ll} \hline
\cpp{bgeot::simplex\_of\_reference(dim\_type d)} & description of the simplex of reference of dimension \cpp{d} \\ \hline
  
  \cpp{bgeot::simplex\_of\_reference(dim\_type d, short\_type k)} & description of the simplex of reference of dimension \cpp{d} with degree \cpp{k} Lagrange grid. \\ \hline

  \cpp{bgeot::convex\_ref\_product(pconvex\_ref a, pconvex\_ref b)} & description of the direct product of two convexes of reference.\\ \hline
  
  \cpp{bgeot::parallelepiped\_of\_reference(dim\_type\;d)} & description of the parallelepiped of reference of dimension \cpp{d}   \texonly{\\ \hline}
\end{ctableau} \end{center}

The vertices correspond to the classical vertices for such reference element. For instance the vertices for the triangle are $(0, 0), (1, 0)$ and $(0, 1)$. It corresponds to the configuration shown in Figure \ref{fig:elem}

If \cpp{p} is of type \cpp{bgeot::pconvex\_ref } then \cpp{p->structure()} is the corresponding convex structure. Thus for instance \cpp{p->structure()->nb\_points()} gives the number of vertices. The function \cpp{p->points()} give the array of vertices and \cpp{p->points()[0]} is the first vertex. The function \cpp{p->is\_in(const base\_node \&pt)} return a real which is negative if the point \cpp{pt} is in the element. The function \cpp{p->is\_in\_face(short\_type f, const base\_node \&pt)} return a real which is null if the point \cpp{pt} is in the face \cpp{k} of the element. Other functions can be found in \cpp{bgeot\_convex\_ref.h} and \cpp{bgeot\_convex.h}.

\subsection{Shape function type}

Most of the time the shape functions of finite element methods are polynomials, at least on the convex of reference. But, the possibility is given to have other types of elements. It is possible to define other kind of base functions such as piecewise polynomials, interpolant wavelets ...\\
To be used by the finite element description, a shape function type must be able to be evaluated on a point (\cpp{a = F.eval(pt)}, where \cpp{pt} is a \cpp{base\_node}) and must have a method to compute the derivtive with respect to the ith variable (\cpp{F.derivative(i)}).

For the moment, only polynomials and piecewise polynomials are defined in the files \cpp{bgeot\_poly.h} and \cpp{bgeot\_poly\_composite.h}


\subsection{Geometric transformations}

\begin{figure}[htb]
  \begin{center}
    \icgraphic{10cm}{getfemelemtrans}{usual elements}
  \end{center}
  \caption{ \it Geometric transformation }
  \label{fig:transgeo}
\end{figure}

A geometric transformation is a polynomial application\\
\equat{\tau : T' \subset \Reel^P \longrightarrow T \subset\Reel^N,}
which maps the reference element $T'$ to the real element $T$.
The geometric nodes are denoted
\equat{g^i, \ \ i = 0 .. n_g - 1.}
The geometric transformation is described thanks to a $n_g$ components polynomial vector (In fact, as an extention, non polynomial geometric transformation can also be supported by Getfem++, but this is very rarely used).
\equat{{\cal N}(x'),}
such that
\equat{\ds \tau(x') = \sum_{i = 0}^{n_g - 1} {\cal N}_i(x') g^i.}
Denoting
\equat{G = (g^0; g^1; ...; g^{n_g - 1}),}
the $N \times n_g$ matrix containing of all the geometric nodes, one has
\begin{center} $ \texonly{\fbox}{$\hspace{1em}\tau(x') = G {\cal N}(x').\hspace{1em}$} $ \end{center}
The derivative of $\tau$ is then
\begin{center} $ \texonly{\fbox}{$\hspace{1em} K(x') := \nabla \tau(x') = G \nabla {\cal N}(x'),\hspace{1em}$} $ \end{center}
where $K(x') = \nabla \tau(x')$ is a $N \times P$ matrix and $\nabla {\cal N}(x')$ a $n_g \times P$ matrix.
The (transposed) pseudo-inverse of $\nabla\tau(x')$ is a $N\times P$ matrix denoted $B(x')$:
\begin{center} \texonly{$\fbox}{$\hspace{1em} B(x') := K(x')(K(x')^T K(x'))^{-1},\hspace{1em}$} \texonly{$} \end{center}
Of course, when $P=N$, one has $B(x')=K(x')^{-T}$.

Pointers on a descriptor of a geometric transformation can be obtained by the following function defined in the file \cpp{bgeot\_geometric\_trans.h}:\\[0.5cm]
\cpp{bgeot::pgeometric\_trans pgt = bgeot::geometric\_trans\_descriptor("name of trans"); }\\[0.5cm]
where \cpp{"name of trans"} can be chosen among the following list.
\begin{center} \begin{ctableau}{|m{0.3\linewidth}|m{0.65\linewidth}|}{ll} \hline
\cpp{"GT\_PK(n,k)"} & Description of the simplex transformation of dimension \cpp{n} and degree \cpp{k} (Most of the time, the degree 1 is used).\\ \hline
\cpp{"GT\_QK(n,k)"} & Description of the parallelepiped transformation of dimension \cpp{n} and degree \cpp{k}.\\ \hline
\cpp{"GT\_PRISM(n,k)"} & Description of the prism transformation of dimension \cpp{n} and degree \cpp{k}. \\ \hline
\cpp{"GT\_PRODUCT(a,b)"} & Description of the direct product of the two transformations \cpp{a} and \cpp{b}.\\ \hline
\cpp{"GT\_LINEAR\_PRODUCT(a,b)"} & Description of the direct product of the two transformations \cpp{a} and \cpp{b} keeping a linear transformation (this is a restriction of he previous function). This allows, for instance, to use exact integrations on regular meshes with parallelograms. \texonly{\\ \hline}
\end{ctableau} \end{center}

\subsection{Finite element methods description}

A finite element method is defined on a reference element $T' \subset \Reel^P$ by a set of $n_d$ nodes $a^i$ and corresponding base functions 
\equat{(\varphi')^i : T' \subset \Reel^P \longrightarrow \Reel^Q,}
Denoting
\equat{\psi^i(x) = (\varphi')^i(x') = (\varphi')^i(\tau^{-1}(x)),}
a supplementary linear transformation is allowed for the real base function
\equat{\varphi^i(x) = \sum_{j = 0}^{n_d - 1} M_{ij} \psi^j(x),}
where $M$ is a $n_d \times n_d$ matrix possibly depending on the geometric transformation (i.e. on the real element). For basic elements as Lagrange elements this matrix is the identity matrix (it is simply ignored). In this case, we will say that the element is $\tau$-equivalent. This approach allows to define hermite elements (Argyris for instance) in a generic way, even with non linear transformations (i.e. mainly for curved boundaries).
We denote $[\varphi'(x')]$ the $n_d \times Q$ matrix whose ith line is $(\varphi')^i(x')$. Whis this notation, for a function is defined by 
\begin{center}$ f(x) = \sum_{i = 0}^{n_d - 1} \alpha_i \varphi^i(x), $\end{center}
one has
\begin{center} \texonly{$ \fbox}{$\hspace{1em} f(\tau(x')) = \alpha^T M [\varphi'(x')],\hspace{1em}$} \texonly{$}\end{center}
where $\alpha$ is the vector whose ith component is $\alpha_i$.

A certain number of description of classical finite element method are defined in the file \cpp{getfem\_fem.h}. See Appendix A of the user documentation for an exhaustive list of available finite element methods.\\

A pointer to the finite element descriptor of a method is obtained using the function\\[0.5cm]
\cpp{ getfem::pfem pfe = getfem::fem\_descriptor("name of method"); }\\[0.5cm]
We refer to the file \cpp{getfem\_fem.C} for how to define a new finite element method.



\section{Description of the different parts of the library} \label{sec:descmod}

\subsection{\gmm library}

\subsubsection{Description}

 \gmm is a linear algebra library which was originally designed to make an interface between the need in linear algebra procedures of \gf and existing free linear algebra libraries (MTL, Superlu, Blas, Lapack originally). It rapidly evolves to an independent self-consistent library with its own vector and matrix types. It is now used as a base linear algebra library by several other projects (projet KDE, \WEBB{http://websvn.kde.org/trunk/kdesupport/gmm} for instance).

However, it preserves the characteristic to be a potential interface for more specific packages. Any vector or matrix type having the minimum of compatibility can be used by generic algorithms of \gmm writing a \cpp{linalg\_traits} structure.

A \gmm standalone version is distributed since release 1.5 of \gf. It is however developed inside the \gf project even though since release 3.0 it is completely independent of any \gf file.

In addition to the linear algebra procedures, it furnishes also the following utilities to \gf.
\begin{itemize}
   \item Fix some eventual compatibility problems in \cpp{gmm\_std.h}.
   \item Error, warning and trace management in \cpp{gmm\_except.h}.
   \item Some extended math definitions in \cpp{gmm\_def.h}.
\end{itemize}

\subsubsection{State}

For the moment, \gmm cover the needs of \gf concerning the basic linear algebra procedures.

\subsubsection{Perspectives}

There is potentatialy several points to be improved in \gmm (partial introduction of expression template for some base types of matrix and vectors, reflection on the way to represent in a more coherent manner sparse sub-vectors and sub-matrices, introduction of C++ concepts ...). However, since \gmm globally cover the needs of \gf and since there exists some other project like Glas  (\WEBB{http://glas.sourceforge.net/}) to build a reference C++ library for linear algebra, a global reflection seems not necessary for the moment. This part is considered to be stabilized.

The current vocation of \gmm is to continue to collect generic algorithms and interfaces to some other packages in order to cover new needs of the whole project. The library is now frequently used as a separate package and has also the vocation to collect the contribution of any person who propose some improvements, new algorithms or new interfaces.

\subsection{Mesh module}

\subsubsection{Description}


This part of the library has the role to store and manage the meshes, i.e. a collection of elements (real elements) connected to each other by some of their faces. For that, it develops concepts of elements, elements of reference, structure of meshes, collection of nodes, geometric transformations, subpart of the boundary or subzone of the mesh.

There is no really effective meshing capabilities  available for the moment in \gf. The meshes of complex objects must be imported from existing meshers such as gmsh or GiD. Some importing functions of meshes have been written and can be easily extended for other formats.

The object which represents a mesh declared in the file \cpp{getfem\_mesh.h} and which is used as a basis for handling of the mehses in \gf manages also the possibility for the structures depending on a mesh (see MESHFEM and MESHIM modules) to react to the evolution of the mesh (addition or removal of elements ...).

\subsubsection{State}

The main C++ header files are
\begin{ctableau}{|m{0.3\linewidth}|m{0.6\linewidth}|}{ll} 
\hline \cpp{bgeot\_convex\_structure.h} & Describes the structure of an element disregarding the coordinates of its vertices.\\
\hline \cpp{bgeot\_mesh\_structure.h} & Describes the structure of a mesh disregarding the coordinates of the nodes.\\
\hline \cpp{bgeot\_node\_tab.h} & A node container allowing the fast search of a node.\\
\hline \cpp{bgeot\_convex.h} & Describes an element with its vertices.\\
\hline \cpp{bgeot\_convex\_ref.h} & Describe reference elements.\\
\hline \cpp{bgeot\_mesh.h} & Describes a mesh with the collection of node (but without the description of geometric transformations).\\
\hline \cpp{bgeot\_geometric\_trans.h} & Describes geometric transformations.\\
\hline \cpp{bgeot\_geotrans\_inv.h} & A tool to invert geometric transformations.\\
\hline \cpp{getfem\_mesh.h} & Fully describes a mesh (with the geometric transformations, subparts of the mesh, support for parallelization). Includes the Bank algorithm to refine a mesh.\\
\hline \cpp{getfem\_mesher.h} & An attempt to develop a mesher. To be use with care.
\texonly{\\ \hline}
\end{ctableau}

A prototype of mesher is in the files \cpp{getfem\_mesher.h} and \cpp{getfem\_mesher.cc} which makes it possible to mesh geometries defined by some level sets. However, the continuation of the development of this mesher is not planned for the moment because the project \gf has vocation to focus on the finite element methods themselves.

\subsubsection{Perspectives}

For the moment, the module is split into two parts which lie into two different namespaces.
Of course, It would be more coherent to gather the module in only one namespace (\cpp{getfem}).

(Note: The file \cpp{bgeot\_mesh.h} could be renamed \cpp{getfem\_basic\_mesh.h}).

A possible work to do on this part would be to examine the manner of storing the meshes and possibly to make a bibliographical study on the manner of storing a mesh (for instance see \cite{remacle2002}). It would be necessary to supplement documentation and to examine also the management of the events and the way in which the structures which depend on the mesh react to these events.

\subsection{FEM module}

\subsubsection{Description}

The FEM module is the part of \gf which describes the finite elements at the element level and the degrees of freedom. Finite element methods can be of different types. They could be scalar or vectorial, polynomial, piecewise polynomial or non-polynomial, equivalent via the geometric transformation or not. Moreover, the description of the degrees of freedom have to be such that it is possible to gather the compatible degrees of freedom between two neighbor elements in a generic way (for instance connecting a Lagrange 2D element to another Lagrange 1D element).

\subsubsection{State}

The main files of the module are
\begin{ctableau}{|m{0.3\linewidth}|m{0.6\linewidth}|}{ll} 
\hline \cpp{getfem\_fem.h} & Abstract definition of a finite element and a degree of freedom. Interface for the exported functions of \cpp{getfem\_fem.cc} and \cpp{getfem\_fem\_composite.cc}. \\
\hline \cpp{getfem\_fem.cc} & Definition of the polynomial finite elements and interface to get the descriptor on these elements (function \cpp{pfem fem\_descriptor(std::string name)}).\\
\hline \cpp{getfem\_fem\_composite.cc} & Definition of the piecewise polynomial finite elements.
\texonly{\\ \hline}
\end{ctableau}

The two files \cpp{getfem\_fem.cc} and \cpp{getfem\_fem\_composite.cc} mainly contains all the finite element description for basic elements. A exhaustive list of the defined finite elements is given in Appendix A of the user documentation.

Some other files define some specific finite element such as
\cpp{getfem\_fem\_level\_set.h} which is a complex construction which
allows to ``cut'' a existing element by one or several level sets (see
the LEVELSET module).

The manner to describe the degrees of freedom globally satisfies the
needing (connecting dof from an element to another in a generic way)
but is a little bit obscure and too much complicated.

Conversely, the way to represent non-equivalent elements with the
supplementary matrix \cpp{M} has proven its efficiency on several
elements (Hermites elements, Argyris ...).

\subsubsection{Perspectives}

the principal dissatisfaction of this module is that description of
the degrees of freedom is not completely satisfactory. It is the
principal reason why one documentation on how to build an element from
A to Z was not made for the moment because description of the degrees
of freedom was conceived to be temporary. An effort of design is thus
to be provided to completely stabilize this module mainly thus with
regard to the description of degrees of freedom but also perhaps the
description of finite elements which could be partially externalized in
a similar way to the cubature methods , at least for the simplest
finite elements (equivalent and polynomial finite elements).


\subsection{CUBATURE module}

\subsubsection{Description}

The CUBATURE module gives access to the numerical integration methods
on reference elements. In fact it does not only contain some cubature
formulas because it also give access to some exact integration
methods. However, the exact integration methods are only usable for
polynomial element and affine geometric transformations. This explain
why exact integration methods are not widely used. The description of
cubature formulas is done either directly in the file
\cpp{getfem\_integration.h} or via a description file in the directory
\cpp{cubature} of \gf. The addition of new cubature formulas in then
very simple, it suffices to reference the element on which it is
defined and the list of Gauss points in a file and add it to this
directory. Additionally, In order to integrate terms defined on a
boundary of a domain, the description should also contains the
reference to a method of same order on each face of the element.

\subsubsection{State}

This module meets the present needs for the project and is considered
as stabilized.  The list of available cubature formulas is given in
Appendix B of the user documentation.


\subsubsection{Perspectives}

No change needed for the moment. An effort could be done on the
documentation to describe completely how to add a new cubature formula
(format off descritption files).


\subsection{MESHFEM module}

to be done

\subsubsection{Description}
\subsubsection{State}
\subsubsection{Perspectives}

Parallelisation of dof numbering to be done. An optimal (an simple) algorithm exits.


\subsection{LEVELSET module}

to be done

\subsubsection{Description}
\subsubsection{State}
\subsubsection{Perspectives}


\subsection{MESHIM module}

to be done

\subsubsection{Description}
\subsubsection{State}
\subsubsection{Perspectives}


\subsection{INTEGELEM module}

to be done

\subsubsection{Description}
\subsubsection{State}
\subsubsection{Perspectives}


\subsection{ASSEMBLE module}

to be done

\subsubsection{Description}
\subsubsection{State}
\subsubsection{Perspectives}


\subsection{BRICK module}

to be done

\subsubsection{Description}
\subsubsection{State}
\subsubsection{Perspectives}

\subsection{Events management}

\subsubsection{Description}
The \cpp{mesh}, \cpp{mesh_fem}, \cpp{mesh_im} and model description are linkedtogether in the sense that there is some dependencies between them. For instance, when an element is suppressed to a mesh, the mesh_fem object has to react.  
\subsubsection{State}
The main tool to deal with simple dependence of object is in \cpp{getfem_context.h}. An object \cpp{context_dependencies} is defined there. In order to deal with the dependencies of an object, the object \cpp{context_dependencies} needs to be a parent class of this object. It adds the following methods to the object :
\begin{ctableau}{|m{0.3\linewidth}|m{0.6\linewidth}|}{ll} 
  \hline \cpp{add_dependency(ct)} & add an object (which has to have \cpp{context_dependencies} as a parent class) to the list of objects from which the current object depend.\\
  \hline \cpp{touch()} & indicates to the dependent objects that
  something has change in the object. \\
  \hline \cpp{context_check()} & check if the object has to be
  updated. if it is the case it makes first a check to the dependency
  list and call the update function of the object.  (the update
  function of the dependencies are called
  before the update function of the current object).\\
  \hline \cpp{context_valid()} & says if the object has still a valid context, i.e. if the object in the dependency list still exist.\\
\hline 
\end{ctableau}
Moreover, the object has to define a method\\
\cpp{void update_from_context(void) const}\\
which is called after a \cpp{context_check()} if the context has changed.


An additional system is present in the object \cpp{mesh}. Each individual element has a version number in order for the objects \cpp{mesh_fem} and \cpp{mesh_im} to detect which element has changed between two calls.

\subsubsection{Perspectives}

Some object do not manage satisfactorily events. This is the case for instance of \cpp{mesh_level_set}, \cpp{mesh_fem_level_set}, \cpp{partial_mesh_fem} ... 

This is clear that the event management still have to be tested and improved to have a fully reactive system.

\subsection{Matlab and Python interfaces}

A simplified interface of getfem++ is provided, so that it is possible to use getfem in other languages.

\subsubsection{Description}
 
All sources are located in the \texttt{interface/src} directory. The interface is composed of one large library \texttt{getfemint} (which stands for getfem interaction), which is acts as a layer above the getfem++ library, and is used by both the python and matlab interfaces.\\

This interface is not something that is generated automatically from c++ sources (as that could be the case with tools such as swig). It is something that has been designed as a simplified and consistent interface to getfem. Adding a new language should be quite easy (assuming the language provides some structures for dense arrays manipulations).

\subsubsection{State}

Here is a list of the various files, with a short description:
\begin{itemize}
\item \cpp{getfem_interface.cc}. This is the bridge between the script language and the getfem interface. The function getfem_interface_main is exported as an \cpp{extern "C"} function, so this is a sort of c++ barrier between the script language and the getfem interface (exporting only a C interface avoids many compilation problems).
\item \cpp{matlab/gfm_mex.c}. The matlab interface. The only thing it knows about getfem is in \cpp{getfem_interface.h}.
\item \cpp{python/getfem_python.c}. The python interface. The only thing it knows about getfem is in \cpp{getfem_interface.h}.

\item \cpp{gfi_array.h, gfi_array.c}. Both gfm_mex.c and getfem_python.c need a simple convention on how to send and receive arrays, and object handles, from \cpp{getfem_interface_main()}. This file provide such functionnality.

\item \cpp{getfemint_object.h}. Not all getfem objects are exported, only a selected subset, mostly mesh, mesh_im, mesh_fem, slice, bricks, etc. They are all wrapped in a common interface, which is \cpp{getfemint::getfem_object}. 

\item \cpp{getfemint_mesh.h, getfemint_mesh_fem.h, ...}. All the wrapped getfem++ objects. Some of them are quite complicated (getfemint_gsparse which export some kind of mutable sparse matrix that can switch between different storage types, and real of complex elements).

\item \cpp{gf_workspace.cc, gf_delete.cc}. Memory management for getfem objects. There is a layer in getfemint::getfem_object which handles the dependency between for example a \cpp{getfemint_mesh} and a \cpp{getfemint_mesh_fem}. It makes sure that no object will be destroyed while there is still another getfem_object using it. The goal is to make sure that under no circumstances the user is able to crash getfem (and the host program, matlab or python) by passing incorrect argument to the getfem interface. 

It also provides a kind of workspace stack, which was designed to simplify handling and cleaning of many getfem objects in matlab (since matlab does not have 'object destructors').

\item \cpp{getfemint.h, getfemint.cc}. Define the \cpp{mexarg_in}, \cpp{mexarg_out} classes, which are used to parse the list of input and output arguments to the getfem interface functions. The name is not adequate anymore since any reference to ``mex'' has been moved into \cpp{gfm_mex.c}.

\item \cpp{gf_mesh.cc, gf_mesh_get.cc, gf_mesh_set.cc, gf_fem.cc, ...}. All the functions exported be the getfem interfaces, sorted by object type (\cpp{gf_mesh*}, \cpp{gf_mesh_fem*}, \cpp{gf_fem*}), and then organized as one for the object construction (\cpp{gf_mesh}), one for the object modification (\cpp{gf_mesh_set}), and one for the object inquiry (\cpp{gf_mesh_get}). Each of these files contain one main function, that receives a \cpp{mexargs_in} and \cpp{mexargs_out} stack of arguments. It parses then, and usually interprets the first argument as the name of a subfunction (\cpp{gf_mesh_get('nbpts')} in matlab,  or \cpp{Mesh.nbpts()} in python).

\item \cpp{matlab/gfm_rpx_mexint.c}. An alternative to \cpp{gfm_mex.c} which is used when the ``\cpp{--enable-matlab-rpc}'' is passed to the \cpp{./configure} script. The main use for that is debugging the interface, since in that case, the matlab interface communicates via sockets with a ``getfem_server'' program, so it is possible to debug that server program, and identify memory leaks or anything else without having to mess with matlab (it is pain to debug).

\item \cpp{python/getfem.base.py}. The python interface is available as a '\cpp{getfem.py}' file which is built during compilation. Its source file is \cpp{getfem.base.py}, it contains just the list of classes, and for each class the names of the member functions.

\end{itemize}

\subsubsection{Adding a new function to the getfem interface}

If one want to add a new function \cpp{gf_mesh_get(m, ``foobar'', ...)}, then the main file to modify is \cpp{gf_mesh_get.cc}. Remember to check every argument passed to the function in order to make sure that the user cannot crash matlab or python when using that function.\\
Do not forget to add documentation for that function: in \cpp{gf_mesh_get.cc}, this is the documentation that appears in the matlab help files (that is when on type '\cpp{help gf_mesh_get}' at the matlab prompt), and in the getfem_python autogenerated documentation. In order to have ``foobar'' as a member function of the python Mesh class, it is necessary to add it in the \cpp{getfem.base.py} file. It is also necessary to add documentation in the \cpp{interface/doc/getfemmatlab.tex}, which was at the beginning the only documentation available. It is still very matlab oriented, and a little bit redundant with the documentation embedded in \cpp{gf_mesh_get.cc}.

Adding a new class to the getfem interface

\subsubsection{Perspectives}

\section{Global perspectives of structuration, consolidation and growth}

intro to the main modifications to be done ...

Modifications to be done are of three kind.

\begin{itemize}
  \item Background consolidation of the existing modules (with a reflection on the optimal representation of meshes, degrees of freedom, finite element methods ...).
  \item Developpement of innovating methods.
  \item Reflection on the optimal way to represent complex p.d.e. models with the maximum of flexibility and reusability. The brick system is a first step in this direction. It should be replaced soon by a more elaborated system.
\end{itemize}

\subsection{Namespace changes}

After the elimination of the small namespaces \cpp{linkmsg} and \cpp{ftool} in release 3.0, it remains now four namespaces in the \gf project.
\begin{itemize}
 \item gmm (Generic Matrix Methods) : for the linear algebra procedures.
 \item dal (Dynamic Array Library) : some basic algorithms including the definition of some containers (\cpp{dal::dynamic_array, dal::dynamic_tas, dal::tree_sorted_array, dal::bit_vector}).
 \item bgeot (Basic GEOmetric Tool) : some basic algorithms including the definition of geometric objects (convex structure, convex, convex of reference, basic mesh).
 \item getfem : the main namespace of \gf.
\end{itemize}

It is clear that the separation into these remaining four namespaces is mainly historical. The separate gmm namespace for \gmm is clearly justified. The contour of nemaspaces \cpp{dal} and \cpp{bgeot} is more vague. Historically, those two namespaces had their own justifications.

In the very begining of \gf (the first files was written in 1995) the S.T.L. was not available and the containers defined in the \cpp{dal} namespace was used everywhere. Now, in \gf, the S.T.L. containers are mainly used. The remaining uses of \cpp{dal} containers are eather historical or due to the specificities of these containers. It is however clear that this is not the aim of the \gf project to developp new container concept. So, the use of the \cpp{dal} containers has to be as much as possible reduced.

Now, concerning \cpp{bgeot}, it was containing some other geometrical object at the begining and was originally designed to be a self-consistent library of geometric concepts. It slowly derived to be like it is now, a collection of algorithms and object definition more or less related to geometry (rtree, kdtree, ftool, polynomials ...).

The conclusion of this is that \cpp{dal} and \cpp{bgeot} namespaces can be advantageously merged to the \cpp{getfem} namespace, reducing to the minimum the use of the \cpp{dal} containers. This should be done preserving the backward compatibility. An intermediary study would be to see if the \cpp{dal} cannot be directly derived from S.T.L. containers preserving the used specificities.


\subsection{Basic types used}

Basic type of integer, real ... used. to be done.


\newpage

\section{Appendix A. Some basic computations between reference and real elements}
\subsection{Volume integral}
One has
\equat{\int_T f(x) dx = \int_{T'} f'(x') |\text{vol}\left(\Frac{\partial \tau(x')}{\partial x'_0} ;\Frac{\partial \tau(x')}{\partial x'_1}; ...; \Frac{\partial \tau(x')}{\partial x'_{P-1} }\right)| dx'.}
Denoting $J_{\tau}(x')$ the jacobian
\begin{center} \texonly{$ \fbox}{$\hspace{1em} J_{\tau}(x') := |\text{vol}\left(\Frac{\partial \tau(x')}{\partial x'_0} ;\Frac{\partial \tau(x')}{\partial x'_1}; ...; \Frac{\partial \tau(x')}{\partial x'_{P-1} }\right)| = (\mbox{det}(K(x')^T K(x')))^{1/2},\hspace{1em}$} \texonly{$}\end{center}
one finally has
\begin{center} \texonly{$ \fbox}{$\hspace{1em} \ds \int_T f(x) dx = \int_{T'} f'(x')  J_{\tau}(x')dx'.\hspace{1em}$} \texonly{$} \end{center}
When $P = N$, the expression of the jacobian reduces to $J_{\tau}(x') = |\mbox{det}(K(x'))|$.

\subsection{Surface integral}
With $\Gamma$ a part of the boundary of $T$ a real element and $\Gamma'$ the corresponding boundary on the reference element $T'$, one has
\begin{center} \texonly{$ \fbox}{$\hspace{1em} \ds \int_{\Gamma} f(x) d\sigma = \int_{\Gamma'} f'(x') \|B(x'){\mathbf n'}\| J_{\tau}(x') d\sigma',\hspace{1em}$} \texonly{$} \end{center}
where ${\mathbf n}'$ is the unit normal to $T'$ on $\Gamma'$. In a same way
\begin{center} \texonly{$ \fbox}{$\hspace{1em} \ds \int_{\Gamma} F(x).{\mathbf n} d\sigma = \int_{\Gamma'} F'(x').(B(x'){\mathbf n}') J_{\tau}(x') d\sigma'.\hspace{1em}$} \texonly{$} \end{center}

\subsection{Derivative computation}
One has
\equat{\nabla f(x) = B(x') \nabla'\,f'(x').}
\subsection{Second derivative computation}
Denoting 
\equat{\nabla^2 f = ({\Frac{\partial^2 f}{\partial x_i \partial x_j}})_{ij},}
the $N \times N$ matrix and
\equat{X'(x') = \sum_{k = 0}^{N-1} \nabla'^2 \tau_k(x') \Frac{\partial f}{\partial x_k}(x) = \sum_{k = 0}^{N-1} \sum_{i = 0}^{P-1} \nabla'^2 \tau_k(x') B_{ki} \Frac{\partial f'}{\partial x'_i}(x'),}
the $P \times P$ matrix, then
\equat{\nabla'^2 f'(x') = X'(x') + K(x')^T \nabla^2 f(x) K(x'),}
and thus
\equat{\nabla^2 f(x) = B(x') (\nabla'^2 f'(x') - X'(x')) B(x')^T.}

In order to have uniform methods for the computation of elementary matrices, the Hessian is computed as a column vector $H f$ whose components are $\Frac{\partial^2 f}{\partial x^2_0}, {\Frac{\partial^2 f}{\partial x_1 \partial x_0}}, ... {\Frac{\partial^2 f}{\partial x^2_{N-1}}}$.
Then, with $B_2$ the $P^2 \times P$ matrix defined as
\equat{(B_2(x'))_{ij} = \sum_{k = 0}^{N-1} \Frac{\partial^2 \tau_k(x')}{\partial x'_{i / P} \partial x'_{i \mbox{ mod } P} } B_{kj}(x'),}
and $B_3$ the $N^2 \times P^2$ matrix defined as
\equat{(B_3(x'))_{ij} = B_{i / N, j / P}(x') B_{i \mbox{ mod } N, j \mbox{ mod } P}(x'),}
one has
\begin{center} \texonly{$ \fbox}{ $H f(x) = B_3(x') \left(H'\,f'(x') - B_2(x')\nabla'\,f'(x')\right). $} \texonly{$} \end{center}

\subsection{Example of elementary matrix} \label{elmminst}

Assume one needs to compute the elementary ``matrix'':
\equat{t(i_0, i_1, ..., i_7) = \int_{T} \varphi_{i_1}^{i_0}\; \partial_{i_4} \varphi_{i_3}^{i_2}\; \partial^2_{i_7 / P, i_7 \mbox{ mod } P} \varphi_{i_6}^{i_5} dx,}
The computations to be made on the reference elements are
\equat{ t'_0(i_0, i_1, ..., i_7) = \int_{T'} (\varphi')_{i_1}^{i_0}\; \partial_{i_4} (\varphi')_{i_3}^{i_2}\; \partial^2_{i_7 / P, i_7 \mbox{ mod } P} (\varphi')_{i_6}^{i_5}  J(x') dx',}
and
\equat{t'_1(i_0, i_1, ..., i_7) = \int_{T'} (\varphi')_{i_1}^{i_0}\; \partial_{i_4} (\varphi')_{i_3}^{i_2}\; \partial_{i_7} (\varphi')_{i_6}^{i_5}  J(x') dx',}
Those two tensor can be computed once on the whole reference element if the geometric transformation is linear (because $J(x')$ is constant). If the geometric transformation is non-linear, what has to be stored is the value on each integration point. To compute the integral on the real element a certain number of reductions have to be made:
\begin{itemize}
    \item Concerning the first term ($\varphi_{i_1}^{i_0}$) nothing.
    \item Concerning the second term ($\partial_{i_4} \varphi_{i_3}^{i_2}$) a reduction with respect to $i_4$ with the matrix $B$.
    \item Concerning the third term ($\partial^2_{i_7 / P, i_7 \mbox{ mod } P} \varphi_{i_6}^{i_5}$) a reduction of $t'_0$ with respect to $i_7$ with the matrix $B_3$ and a reduction of $t'_1$ with respect also to $i_7$ with the matrix $B_3B_2$
 \end{itemize}
 The reductions are to be made on each integration point if the geometric transformation is non-linear. Once those reductions are done, an addition of all the tensor resulting of those reductions is made (with a factor equal to the load of each integration point if the geometric transformation is non-linear).

 If the finite element is non-$\tau$-equivalent, a supplementary reduction of the resulting tensor with the matrix $M$ has to be made.



\begin{thebibliography}{99}
% \bibliographystyle{apalike}
% \bibliographystyle{plain}
% \bibliography{all}

\bibitem{bank1983}
  R.E. Bank, A.H. Sherman, A. Weiser
  {\it Refinement algorithms and data structures for regular local mesh refinement},
  in Scientific Computing IMACS, Amsterdam, North-Holland, pp 3-17, (1983).

\bibitem{ciarlet1978}
  P.G.. Ciarlet,
  {\it The finite element method for elliptic problems}, Studies in Mathematics and its Applications vol. 4 (1978), North-Holland.

\bibitem{dh-to1984} 
  G. Dhatt, and  G. Touzot
  {\it The Finite Element Method Displayed}, 
  J. Wiley \& Sons,  New York, (1984).

\bibitem{EncyclopCubature}
  R. Cools
  {\it An Encyclopaedia of Cubature Formulas}, J. Complexity, \WEB{http://www.cs.kuleuven.ac.be/\tild ines/research/ecf/ecf.html}{http://www.cs.kuleuven.ac.be/\tilda ines/research/ecf/ecf.html}
  
\bibitem{Xfem}
  N. Moës, J. Dolbow and T. Belytschko
  {\it A finite element method for crack growth without remeshing },
  Int. J. Num. Meth. Engng. 46 (1999), 131-150.  

\bibitem{nedelec1991}
  J.-C. Nedelec,
  {\it Notions sur les techniques d'{\'e}l{\'e}ments finis}, Ellipses, SMAI, Math{\'e}matiques \& Applications n$^o7$, (1991).

\bibitem{remacle2002}
  J-F. Remacle, M. Shephard,
  {\it An algorithm oriented database}
  Int. J. Num. Meth. Engng. 58 (2003), 349-374.  


\bibitem{so-se-do2004}
  P. Solin, K. Segeth, I. Dolezel,
  {\it Higher-Order Finite Element Methods}, Chapman and Hall/CRC, Studies in advanced mathematics, 2004.

\end{thebibliography}

% \W \section*{Index}
% \texorhtml{\printindex}{\label{gfmindex}\htmlprintindex}

\end{document}
