Cas particulier (MATR_DISTRIBUEE)
=================================


1.  Lorsqu’on effectue un calcul distribué avec le solveur MUMPS , si on active l’option MATR_DISTRIBUEE , les bouts de MATR_ASSE propres à chaque processeur sont retaillés de manière à ne pas stocker de zéros inutiles ( REFA(11) est alors taggé en MATR_DISTR) . Mais du coup la manipulation de ces matrices assemblées distribuées “amaigries” est plus complexe. Lors de certains traitements globaux (produit matrice-vecteur), on ne les complète pas et on s’arrête en ERREUR_FATALE . Il faudra enrichir le périmètre d’utilisation de cette fonctionnalité au coup par coup.

*Remarques :*

*Pour distinguer les données associées à chaque sous-domaine, chacun comporte une* *SD_SOLVEUR* *, un* *NUME_DDL* *, une* *MATR_ASSE* *et des* *CHAM_NO* *s adaptés à ses dimensions. D’autre part, chaque processeur est responsable d’une* *SD_SOLVEUR* *, d’un* *NUME_DDL* *, d’une* *MATR_ASSE* *et de* *CHAM_NOs* *maîtres qui vont être quasi-vides et dont la seule fonction est de pointer vers les* *SD* *esclaves des sous-domaines dont le processeur à la gestion. C’est une autre forme de* *SD* *distribuées qui implique donc cette récursivité à deux niveaux.*




Règle à respecter lors de la programmation d'un flot de données/traitements parallèles
--------------------------------------------------------------------------------------

En fin d’opérateur Aster ,toutes les bases globales des processeurs doivent être identiques car on ne sait pas si l’opérateur qui suit dans le fichier de commande a prévu un flot de données d’entrée incomplet. Il faut donc organiser, par exemple, les complétudes de champs ad hoc dans les routines d’archivage (en essayant de sa baser sur des MPI_ALLREDUCEplus simples et plus efficaces à mettre en œuvre). Pour offrir un parallélisme plus efficace il faudra un jour faire sauter ce verrou. Mais d’ici là !