- Correction (compte-rendu) en postscript ou PDF.
- L'énoncé, en postscript ou PDF.
- Les sources en ligne au format tgz ou directement (et avec les Makefiles respectifs adéquats) sur les machines des salles libre-service ainsi que sur gdsdmi dans le répertoire /home/eagullo/teach/AlgoPar/dm-src.
- Documentation
- Cluster gdsdmi : vue générale, organisation, exemple d'utilisation, vue de l'état de la machine avec monika et de la disponibilité des ressources avec DrawOARGantt.
- Gestionnaire de ressources OAR et son manuel.
- MPI : les standards, des implatations libres de la norme MPI 1 MPICH et LAM, de la norme MPI 2 MPICH 2 et Open MPI, et un tutoriel.
- Bibliothèques d'algèbre linéaire dense : BLAS (Basic Linear Algebra Subprograms) et son API C, LAPACK et son API C. La bibliothèque ATLAS (Automatically Tuned Linear Algebra Software) propose une très bonne implantation libre et portable des BLAS ainsi que des fonctionnalités principales de LAPACK et offre une interface C.
- Méthode de Jacobi sur Wikipedia et pour aller plus loin l'excellent ouvrage "Matrix Computations" de Golub et Van Loan disponible à la bibliothèque (référence G.1.3 GOLU).
- FAQ : je publierai ici la liste de vos questions et commentaires.
- NB 16/11/2006 : une douzaine d'exemplaires imprimés du code jacseq.c sont déposés devant le bureau de Simone pour ceux qui l'ont demandé.
- Apparemment, vous êtes plusieurs à vouloir rendre le DM ce WE.
La deadline est donc dimanche 24 décembre minuit.
- L'exécution avec des problèmes de grande taille
(typiquement M>=3000) semble bloquée ...
Réponse : Avez-vous
vérifié que vous ne swappez pas ? Regardez la mémoire physique
associée à votre processus et estimez les besoins mémoire de votre
approche.
NB : C'est une question intéressante : passer des problèmes les
plus gros possibles, notamment avec jacpar_distentries, est une
validation expérimentale importante ; identifier clairement les
limites et proposer/implanter des solutions pour les repousser
également.
En particulier, attention aux débordements d'entiers
qui peuvent devenir le facteur limitant (en taille de problème)
de votre méthode. Que faire alors ?
-
J'ai l'erreur suivante :
"p1_6498: p4_error: interrupt SIGSEGV: 11
rm_l_1_6523: (0.063325) net_send: could not write to fd=5, errno = 32
p1_6498: (0.099744) net_send: could not write to fd=5, errno = 32
Réponse :
Vous avez une erreur de segmentation sur un processus ; un autre processus
qui essaie de communiquer avec lui dit alors qu'il est bien embêté ...
Il faut débugger (ça fait aussi partie du jeu). Deux écoles pour identifier
la source du problème :
- mettre des traces (écrire sur la sortie standard et la flusher) ;
- utiliser un outil de débuggage ; p. ex. gdb ... (mais ça demande évidemment
davantage d'énergie en parallèle).
- La fonction clapack_dgetrs, sensée résoudre un système linéaire,
met des NaN dans mon vecteur Y. Savez vous d'ou ca pourrait venir ?
Réponse : clapack_dgetrs résoud un système *factorisé*, avez-vous
appelé (comme dans le code séquentiel) le clapack_dgetrf d'abord ?
Donnez-vous en argument à clapack_dgetrs le système factorisée ?
Si c'est le cas, il faut vérifier les arguments (taille de matrice,
ordre des arguments, ...) et également les valeurs numériques
associés à la matrice factorisée et au second membre (pour vérifier
que le problème n'est pas en amont).
- Je ne m'en sors toujours pas ...
Donnez-moi un accès en lecture
à vos sources en me précisant la machine et leur emplacement et bien
sûr en mettant les droits adéquats sur les sources et leur arborescence
ascendante (man chmod) : je peux en dernier ressort *essayer* de fixer
vos problèmes ... mais je ne peux rien vous promettre.
|