Draft Code de Calcul:

1) Problématique

La difficulté principale rencontrée dans le développement d'un code de calcul utilisé dans un cadre à la fois recherche et industriel résulte du fait que celui-ci doit fournir à la fois une interface simple pour les utilisateurs finaux et des mécanismes permettant à des développeurs et chercheurs d'étudier des schémas numériques de la manière la plus efficiente possible.

Cette flexibilité doit résulter de la modularité suffisante issue d'une décomposition pertinente d'un problème numérique abstrait.
Par la définition d'interfaces entre ces differents modules on introduit ainsi une certaine localité permettant de modifications simples du code sans une connaissance "globale" du code.
Ceci est rarement le cas dans le cadre de code "monolithiques" tels que ISIS où les choix ou absences de design préalable conduisent à une rigidité entrainant un accroissement de complexité du à des stratégies de contournement ("flawed by design").

Par ailleurs, au vu de l'accroissement du nombre de cores processeurs par machine il semble pertinent d'intégrer le parallélisme et le multithreading en tant qu'élément constituant du code de calcul.
Celui-ci doit donc proposer des mécanismes intrinsèques et génériques pour distribuer des "processus" que ce soit par multithreading ou résolution via openmp ou mpi sur plusieurs cores, processeurs, machines.

À l'image des développements effectués dans les domaines des systèmes à micro-noyaux comme le HURD et les systèmes distribués tels qu'Amoeba on peut envisager une structure modulaire bâtie autour d'un kernel donc le rôle se limite aux entrées/sorties, à l'ordonnancement des tâches et à la gestion de processus et la communication inter-serveurs (ISC) .
L'extension du code à un cadre "parallèle" semble pouvoir être effectuée via un système de "tokens".


a) Modularité: Pluggable Components Interface & Inter Servers Communication 

               ---------> Server 1
               |            |
               |          [ ISC ]
               |            |
Kernel <--- [ PCI ] ---> Server 2

b) Scalabilité: Crossinterface Token System
                ___________
OpenMP ------->|           |
               |           |
Multithread -->|    CTS    | ---> "tokenize" ---> Kernel
               |           |
MPI ---------->|___________|

Permet la gestion de processus logiques de manière transparente.

2) Définition d'un problème abstrait:

2.1) Processus de résolution en continu:

   a) Données:
   - domaine \Omega\times(0,T)
   - conditions au limites \partial\Omega
   
   b) Équations

2.2) Processus de résolution en discret:

   a)
   b)

+  c) discretization
   d) solveur   



A) Contraintes et Standards

Code:
- ISO C++ 2003
- POSIX 1.1

Gestion des entrées/sorties:
- XML 1.1 (Xalan/Xercès)
- XHTML 1.1 (Documentation)

Lint automatique:
-