%
%     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{Rôle du \pcs dans le \CS\label{cha:role}}


Ce chapitre replace le \pcs dans le contexte du \CS dont
elle est une des composantes.

Pour de plus amples informations sur le rôle initialement joué par
le \pcs au sein du \CS, on se reportera utilement à la
référence~\cite{specifenv}.


\subsection{\CS\label{sec:saturne}}

Initialement, un premier module, appelé \noy, regroupait les aspects
physico-numériques du \CS, tandis que le second gérait les communications
et les échanges de données entre le \noy et l'extérieur du système et
jouait ainsi le rôle d'\env vis-à-vis du \noy.
Ces modules étaient bien distincts, au point de constituer deux exécutables
différents.

Aujourd'hui, ce rôle anciennement dévolu à l'\env est assuré
principalement via la librairie \fvm (qui peut être vue comme un
successeur à terme de l'\env), qui est directement appellée par le \noy.
L'\env assure donc principalement le rôle de \pcs, et a été renomée dans
ce sens.

La description géométrique intermédiaire du \maillage, à fournir
en entrée du \noy, fait abstraction des \typgeos des \elems.
La géométrie du \maillage, à fournir en entrée du \noy,
se limite en général à la donnée~:

\begin{liste}
\item de la connectivité \og faces $\rightarrow$ cellules \fg~;
\item de la connectivité \og faces $\rightarrow$ sommets \fg~;
\item des coordonnées des sommets~;
\item de familles\footnote{Description compactée des couleurs et groupes}
      des faces et des cellules.
\end{liste}

Ce type de représentation géométrique du \maillage n'est pas celle
que fournissent les mailleurs~: ils donnent en général une description
en connectivité nodale du \maillage.

Une première fonctionnalité du \pcs consiste donc à transformer
la description géométrique du \maillage issue d'un mailleur
dans la représentation lisible par le \noy.

Le \pcs pourra lire plusieurs \maillages éventuellement non conformes et
réaliser leur recollement conforme (par découpage de faces non conformes
en sous-faces conformes).

Le \pcs doit se charger aussi de la production de données associées
à la vérification des maillages qui soient visualisables avec des
outils externes de post-traitement.


\subsection{Échanges avec le \pcs\label{sec:echange}}

On énumère ici les différents échanges possibles avec le \pcs~:
\begin{liste}
\item échange avec les mailleurs~: le \pcs lit les \maillages
  dans les formats spécifiques aux mailleurs~;
\item échange avec le \noy~: le \pcs transmet au \noy les données
  du \maillage dans la représentation spécifique du \noy~;
\item échange avec les outils de post-traitement~: le \pcs peut transcrire
  ces mêmes données dans les formats lisibles par les outils de
  post-traitement (à des fins de vérification)~;
  
\end{liste}

Le \pcs n'est pas lié {\it a priori} à un ensemble figé de systèmes externes
(mailleurs et outils de post-traitement).
Il doit donc être en mesure d'intégrer de nouveaux formats d'échange
de données avec d'autres systèmes externes.

\passepage

