%
%     This file is part of the Code_Saturne Preprocessor, element of the
%     Code_Saturne CFD tool.
%
%     Copyright (C) 1998-2007 EDF S.A., France
%
%     contact: saturne-support@edf.fr
%
%     The Code_Saturne Preprocessor is free software; you can redistribute it
%     and/or modify it under the terms of the GNU General Public License
%     as published by the Free Software Foundation; either version 2 of
%     the License, or (at your option) any later version.
%
%     The Code_Saturne Preprocessor is distributed in the hope that it will be
%     useful, but WITHOUT ANY WARRANTY; without even the implied warranty
%     of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
%     GNU General Public License for more details.
%
%     You should have received a copy of the GNU General Public License
%     along with the Code_Saturne Preprocessor; if not, write to the
%     Free Software Foundation, Inc.,
%     51 Franklin St, Fifth Floor,
%     Boston, MA  02110-1301  USA
%


\section{Définition des concepts clés\label{cha:definition}}


Ce chapitre définit les principaux concepts qui sont utilisés par le \pcs
et auxquels on fera constamment référence dans la suite du rapport.

Ces définitions n'ont pas une valeur générale et s'appliquent
uniquement dans le cadre du module \pcs.

On note que ces notions ne correspondent pas pour la plupart à une classe,
mais sont représentées sous forme de \champs. Parmi les notions décrites
ci-dessous, seuls le \maillage, l'\entite, et le \champ sont actuellement
représentés par des classes.

Il est important de bien noter que les notions définies ci-dessous correspondent
à une analyse du problème à traiter, et que le choix de représenter telle
ou telle entité sous forme de classe ou non ne vient qu'après.

\subsection{Maillage\label{sec:def.maillage}}


On appelle \elem, un \som, une \fac ou une \cel~:

\begin{liste}
\item \elem de dimension 0 :
  un \som est défini par ses coordonnées~;
\item \elem de dimension 2 :
  une \fac est une surface fermée, pleine, définie
  par au moins 3 \soms (non alignés)~;
\item \elem de dimension 3 :
  une \cel est un volume fermé, plein, définie :
  \begin{liste}
  \item soit par au moins 4 \facs (non coplanaires)~;
  \item soit par au moins 4 \soms (non coplanaires).
  \end{liste}
\end{liste}

Un \maillage est un ensemble d'\elems, dont chaque {\elem}~:
\begin{liste}
\item est défini en fonction d'\elems de dimension inférieure~;
\item possède ou non des \props.
\end{liste}

\subsubsection{Connectivité\label{sec:def.connect}}

La relation permettant de définir des \elems en fonction
d'\elems de dimension inférieure est appelée \connect.

On distingue 2 types de \connect~:
\begin{liste}
\item la \connectnod, dans laquelle tous les \elems (de dimension supérieure ou égale
  à 1) sont définis en fonction des \soms~;
\item la \connectdes, dans laquelle tous les \elems (de dimension supérieure ou égale
  à 1) sont définis en fonction des \elems de dimension immédiatement inférieure
  (encore appelés \sselems).

  Le tableau ci-dessous donne pour chaque type d'\elem, le type de \sselem
qui participe à sa définition dans la \connectdes.

\begin{center}
  \begin{tabular}{|l|l|}
    \hline
    \elem & \sselem \\
    \hline
    \cel & \fac \\
    \fac & \som \\
    \hline
  \end{tabular}
\end{center}

\end{liste}


\subsubsection{Type géométrique\label{sec:def.typgeo}}

On peut déterminer au besoin un \typgeo pour chaque \elem en connectivité
nodale en fonction de son type et du nombre de ses sommets.

On donne dans le tableau ci-dessous la liste des \typgeos définis dans le \pcs.

\begin{center}
  \begin{tabular}{|l|l|}
    \hline
    \hline
    \elem & \typgeo \\
    \hline
    \hline
    \som & \som \\
    \hline
    \fac & triangle   \\
         & quadrangle \\
         & polygone   \\
    \hline
    \cel & tétraèdre \\
         & pyramide  \\
         & prisme (ou pentaèdre) \\
         & hexaèdre  \\
         & polyèdre  \\
    \hline
    \hline
  \end{tabular}
\end{center}


\subsubsection{Propriété\label{sec:def.prop}}

Un \elem peut avoir plusieurs \props, de 2 types différents~:
\begin{liste}
\item il peut posséder une ou plusieurs \couleurs\footnote{%
Les mailleurs ne donnent en général la possibilité d'attribuer
qu'une seule \couleur à un \ele. Le \pcs intègre une notion plus large de la
\couleur, afin notamment de ne pas perdre d'information sur la \couleur
des éléments en cas de recollement de maillages dont les bords en vis-à-vis
sont de \couleurs différentes.}~; 
\item il peut appartenir à un ou plusieurs \groupes, définis par un nom.
\end{liste}

Une \couleur est représentée par un numéro~; avec tous les mailleurs
utilisés jusqu'ici (\ideas, \simail, \icemhexa, et \igghexa), la couleur est
un entier positif (ou construite à partir d'un entier positif indiquant
un groupe ou une surface CAO pour \icemhexa et \igghexa, qui ne possèdent
pas directement la notion de couleur). Par convention, une couleur de valeur
zéro est considérée dans le \pcs comme équivalente à aucune couleur (ce
qui est proche de l'interprétation des couleurs, ou {\it références} sous
\simail). Un \groupe est représenté par un nom.


\subsubsection{Filiation\label{sec:def.filia}}

Une \filia indique une relation de type \og héritage \fg entre
l'\elem portant un attribut \filia et un \elem du même type d'\entite
(mais pas forcément du même \maillage).
On induit une relation de type \filia lorsqu'on construit
un maillage par extraction d'un maillage parent.

\subsubsection{Connectivité faces\label{sec:def.filia}}

Une \connect entre faces indique une relation de type \og faces en vis-à-vis \fg
pour des faces non conformes d'un même \maillage.
La présence de ce type de relation induit un recollement conforme automatique.

\subsection{Entité de maillage\label{sec:def.ent}}


On appelle \entite, un ensemble d'\elems de même dimension.\\

Par définition, il y a 3 \entites principales,contenant chacune tous les
\elems de même dimension d'un maillage~:
\begin{liste}
\item l'\entsom~;
\item l'\entfac~;
\item l'\entcel.
\end{liste}

\subsection{Champ\label{sec:def.champ}}


Un \champ associe à chaque \elem d'une même \entite,
soit une valeur qui caractérise cet \ele dans la définition du \maillage,
soit une valeur (de nature et utilité quelconque) attachée à cet \ele.

Il s'agit en fait d'une des notions les plus importantes du \pcs,
car presque toutes les données sont représentées en fin de compte sous forme
de \champs.

Les différents types de \champ sont les suivants~:
\begin{liste}
\item la définition des \elems en terme de \connect~;
\item les \couleurs et les \groupes~;
\end{liste}


\subsection{Famille\label{sec:def.fam}}


Une \famille est une classe d'équivalence~:
deux \eles dont toutes les \props (\couleurs, appartenances à un \groupe)
sont les mêmes, appartiennent à la même \famille, alors que dès qu'une \prop
est différente, les \eles appartiennent à une
\famille différente~\cite{specifenv}.

Une \famille est identifiée par un numéro et est décrite par les \props
qui la définissent (\couleurs, appartenances à un \groupe).
Chaque \ele a un numéro de \famille associé.

La notion de \famille est bien adaptée à un stockage compact des diverses
propriétés des éléments, mais pas à certaines opérations. Ainsi, si
l'utilisation de familles peut être pratique pour une opération de type
extraction ou découpage (où il suffit que les éléments issus de l'opération
héritent d'un simple numéro de famille pour connaître leurs propriétés),
cette utilisation s'avère beaucoup plus problématique pour des opérations
de type fusion, où des éléments héritent des propriétés de leurs deux
parents, et les classes d'équivalence sont donc à reconstruire.

On notera que le modèle \med définit les propriétés via des \familles,
en construisant un groupe de familles sur les propriétés des n\oe{}uds
(l'équivalent des \soms dans le \pcs), et un autre groupe sur les propriétés
de l'ensemble des autres \entites. Ce découpage semble naturel pour des
codes aux éléments finis, mais semblerait arbitraire si on l'appliquait
au \pcs, qui sépare clairement les éléments de dimension différente.

De la même fa\c{c}on, si l'on veut fournir des propriétés au noyau sous
forme de \familles, il semble préférable de construire les \familles sur
l'ensemble des entités, afin de réduire le risque de confusion entre
les descriptions de \familles sur les \soms et sur les autres entités.

On choisit donc de représenter dans le \pcs les propriétés des divers éléments
sous forme de \champs de \couleurs et de \groupes, et de n'utiliser les
\familles que de manière transitoire, en fonction d'une logique locale.

Ainsi, les \familles lues ou écrites dans des fichiers au format \med
respectent la logique du modèle associé (i.e. un ensemble de familles
de numéros négatifs sur les \soms, et un autre ensemble de numéros
positifs incluant les \facs et les \cels), alors que les
\familles fournies au noyau regroupent les \atts de toutes les \entites,
et les classes d'équivalence obtenues sont donc différentes.


\passepage

