Atlas - Mathématiques - Université de Poitiers

Le projet «Atlas» et le logiciel atlas
Marc van Leeuwen
Laboratoire de Mathématiques et Applications
Université de Poitiers
25 juin 2007 / Séminaire Groupes Algèbres et Géométrie, Poitiers
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
1 / 19
Plan
1
Le projet Atlas
Débuts
Le «cas» E8
2
Le calcul des polynômes de KLV pour le grand bloc de E8
Modifications au logiciel
Chronologie des calculs
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
2 / 19
Plan
1
Le projet Atlas
Débuts
Le «cas» E8
2
Le calcul des polynômes de KLV pour le grand bloc de E8
Modifications au logiciel
Chronologie des calculs
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
3 / 19
Membres du projet Atlas
Jiu-Kang Yu
Wai-Ling Yee
Alfred Noel
Siddhartha Sahi
Annegret Paul
Patrick Polo
Jeffrey Adams
Fokko du Cloux
Peter Trapa
David Vogan
Marc van Leeuwen (Poitiers)
Scott Crofts
Tatiana Howard
Birne Binegar
Marc van Leeuwen
Alessandra Pantano
Dan Barbasch
Bill Casselman
Dan Ciubotaru
Susana Salamanca
John Stembridge
atlas
Séminaire GAG
4 / 19
Quelques dates
2002. Le projet ‘Atlas of Lie groups and Representations’ formé.
2003. Premier des «Atlas workshop»s annuels à Palo Alto.
2004. Fokko du Cloux termine la partie “structure” d’atlas.
novembre 2005. Fokko termine la partie “polynômes de KLV”.
10 novembre 2006. Décès Fokko.
8 janvier 2007. Polynômes de KLV pour E8 (R) calculés.
19 mars 2007. Annonce du résultat.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
5 / 19
Un logiciel multi-couches
Systèmes de racines
Données radicielles
Classes intérieures
Sous-algèbres de Cartan réelles
Groupe de Weyl
Involutions tordues
Formes réelles faibles
Fibres
Formes réelles fortes
Groupe de Tits
Paramètres unilatéraux : K \G/B
Paramètres bilatéraux : blocs
Polynômes de Kazhdan-Lusztig-Vogan
W -cellules
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
6 / 19
Calcul des polynômes KLV
Construction du «bloc»
Ensemble fini
Ordre partiel, gradué
Relations de transition entre éléments du bloc
Une matrice triangulaire sur Z[q] à calculer
Lignes et colonnes indicées par éléments du bloc
Polynômes Px,y déterminés par des relations de récurrence
Pour `(x) < `(y ) on aura deg Px,y ≤
`(y )−`(x)−1
2
Les relations de récurrence sont additives, avec parfois l’utilisation
0
0
d’un scalaire µ(x 0 , y 0 ) = coef(q `(y )−`(x )−1 , Px 0 ,y 0 )
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
7 / 19
Calcul des polynômes KLV
Construction du «bloc»
Ensemble fini
Ordre partiel, gradué
Relations de transition entre éléments du bloc
Une matrice triangulaire sur Z[q] à calculer
Lignes et colonnes indicées par éléments du bloc
Polynômes Px,y déterminés par des relations de récurrence
Pour `(x) < `(y ) on aura deg Px,y ≤
`(y )−`(x)−1
2
Les relations de récurrence sont additives, avec parfois l’utilisation
0
0
d’un scalaire µ(x 0 , y 0 ) = coef(q `(y )−`(x )−1 , Px 0 ,y 0 )
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
7 / 19
Calcul des polynômes KLV
Construction du «bloc»
Ensemble fini
Ordre partiel, gradué
Relations de transition entre éléments du bloc
Une matrice triangulaire sur Z[q] à calculer
Lignes et colonnes indicées par éléments du bloc
Polynômes Px,y déterminés par des relations de récurrence
Pour `(x) < `(y ) on aura deg Px,y ≤
`(y )−`(x)−1
2
Les relations de récurrence sont additives, avec parfois l’utilisation
0
0
d’un scalaire µ(x 0 , y 0 ) = coef(q `(y )−`(x )−1 , Px 0 ,y 0 )
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
7 / 19
Caractéristiques du calcul des polynômes KLV
On peut constater que
le nombre de polynômes à calculer est proportionnel au carré
de la taille du bloc,
les relations de récurrence ne sont pas «locales»,
beaucoup de polynômes seront identiques.
Par conséquent :
les polynômes doivent être calculés tous ensemble ;
le calcul peut être limité aux entrées «essentielles» ;
facteur principal : le temps nécessaire pour retrouver Px 0 ,y 0 ;
les polynômes doivent donc rester en mémoire vive.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
8 / 19
Caractéristiques du calcul des polynômes KLV
On peut constater que
le nombre de polynômes à calculer est proportionnel au carré
de la taille du bloc,
les relations de récurrence ne sont pas «locales»,
beaucoup de polynômes seront identiques.
Par conséquent :
les polynômes doivent être calculés tous ensemble ;
le calcul peut être limité aux entrées «essentielles» ;
facteur principal : le temps nécessaire pour retrouver Px 0 ,y 0 ;
les polynômes doivent donc rester en mémoire vive.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
8 / 19
Plan
1
Le projet Atlas
Débuts
Le «cas» E8
2
Le calcul des polynômes de KLV pour le grand bloc de E8
Modifications au logiciel
Chronologie des calculs
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
9 / 19
Pourquoi E8 ?
Qu’est-ce qui est spécial de E8 ?
C’est le plus grand group simple exceptionnel.
La forme réelle E8 (R) a des blocs de tailles 1, 71654, et 453060 ;
ce dernier est le plus grand bloc qui existe en rang 8.
Les blocs sont beaucoup plus compliqués
que des blocs «classiques» de taille comparable.
Par exemple pour A10 , bloc sl(11, R), su(6, 5), taille 173712
41.395.956 entrées non nulles (soit 8%) à calculer
60.228 polynômes distincts
394.415 coefficients, dont le maximum est 150
0, 5 Go de mémoire utilisés
Pour E8 , bloc e8 (e7 .su(2)), e8 (R), taille 71654
63.343.253 entrées non nulles (soit 49%) à calculer
10.147.581 polynômes distincts
101.229.186 coefficients, dont le maximum est 2545
1, 5 Go de mémoire utilisés
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
10 / 19
Pourquoi E8 ?
Qu’est-ce qui est spécial de E8 ?
C’est le plus grand group simple exceptionnel.
La forme réelle E8 (R) a des blocs de tailles 1, 71654, et 453060 ;
ce dernier est le plus grand bloc qui existe en rang 8.
Les blocs sont beaucoup plus compliqués
que des blocs «classiques» de taille comparable.
Par exemple pour A10 , bloc sl(11, R), su(6, 5), taille 173712
41.395.956 entrées non nulles (soit 8%) à calculer
60.228 polynômes distincts
394.415 coefficients, dont le maximum est 150
0, 5 Go de mémoire utilisés
Pour E8 , bloc e8 (e7 .su(2)), e8 (R), taille 71654
63.343.253 entrées non nulles (soit 49%) à calculer
10.147.581 polynômes distincts
101.229.186 coefficients, dont le maximum est 2545
1, 5 Go de mémoire utilisés
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
10 / 19
Pourquoi E8 ?
Qu’est-ce qui est spécial de E8 ?
C’est le plus grand group simple exceptionnel.
La forme réelle E8 (R) a des blocs de tailles 1, 71654, et 453060 ;
ce dernier est le plus grand bloc qui existe en rang 8.
Les blocs sont beaucoup plus compliqués
que des blocs «classiques» de taille comparable.
Par exemple pour A10 , bloc sl(11, R), su(6, 5), taille 173712
41.395.956 entrées non nulles (soit 8%) à calculer
60.228 polynômes distincts
394.415 coefficients, dont le maximum est 150
0, 5 Go de mémoire utilisés
Pour E8 , bloc e8 (e7 .su(2)), e8 (R), taille 71654
63.343.253 entrées non nulles (soit 49%) à calculer
10.147.581 polynômes distincts
101.229.186 coefficients, dont le maximum est 2545
1, 5 Go de mémoire utilisés
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
10 / 19
Pourquoi E8 ?
Qu’est-ce qui est spécial de E8 ?
C’est le plus grand group simple exceptionnel.
La forme réelle E8 (R) a des blocs de tailles 1, 71654, et 453060 ;
ce dernier est le plus grand bloc qui existe en rang 8.
Les blocs sont beaucoup plus compliqués
que des blocs «classiques» de taille comparable.
Par exemple pour A10 , bloc sl(11, R), su(6, 5), taille 173712
41.395.956 entrées non nulles (soit 8%) à calculer
60.228 polynômes distincts
394.415 coefficients, dont le maximum est 150
0, 5 Go de mémoire utilisés
Pour E8 , bloc e8 (e7 .su(2)), e8 (R), taille 71654
63.343.253 entrées non nulles (soit 49%) à calculer
10.147.581 polynômes distincts
101.229.186 coefficients, dont le maximum est 2545
1, 5 Go de mémoire utilisés
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
10 / 19
Pourquoi E8 ?
Qu’est-ce qui est spécial de E8 ?
C’est le plus grand group simple exceptionnel.
La forme réelle E8 (R) a des blocs de tailles 1, 71654, et 453060 ;
ce dernier est le plus grand bloc qui existe en rang 8.
Les blocs sont beaucoup plus compliqués
que des blocs «classiques» de taille comparable.
Par exemple pour A10 , bloc sl(11, R), su(6, 5), taille 173712
41.395.956 entrées non nulles (soit 8%) à calculer
60.228 polynômes distincts
394.415 coefficients, dont le maximum est 150
0, 5 Go de mémoire utilisés
Pour E8 , bloc e8 (e7 .su(2)), e8 (R), taille 71654
63.343.253 entrées non nulles (soit 49%) à calculer
10.147.581 polynômes distincts
101.229.186 coefficients, dont le maximum est 2545
1, 5 Go de mémoire utilisés
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
10 / 19
Le grand bloc de E8 (R)
Sans faire le calcul pour le grand bloc, on avait ces estimations :
Il y aura 6.083.625.251 entrées à calculer.
Si environ 50% sont non nulles, cela fait 3 milliards polynômes.
Avec 12 octets par entrée, donc 36 Go pour localiser les
polynômes.
Chaque polynôme possède au plus 32 coefficients,
mais souvent beaucoup moins.
Le plus grand coefficient ne loge pas dans 2 octets (max 65535).
Le stockage des coefficients nécessitera environ 50–100 octets
par polynôme en moyenne.
Selon les estimations pour le nombre de polynômes distincts
(100 million – 1 milliard), le stockage des coefficients peut
nécessiter 5 Go – 100 Go.
Le format de stockage interne entraîne des coûts supplémentaires
importants en termes d’utilisation de mémoire.
En plus, le format textuel externe utilisé par atlas n’est pas du tout
adapté à des résultats de cette taille.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
11 / 19
Le grand bloc de E8 (R)
Sans faire le calcul pour le grand bloc, on avait ces estimations :
Il y aura 6.083.625.251 entrées à calculer.
Si environ 50% sont non nulles, cela fait 3 milliards polynômes.
Avec 12 octets par entrée, donc 36 Go pour localiser les
polynômes.
Chaque polynôme possède au plus 32 coefficients,
mais souvent beaucoup moins.
Le plus grand coefficient ne loge pas dans 2 octets (max 65535).
Le stockage des coefficients nécessitera environ 50–100 octets
par polynôme en moyenne.
Selon les estimations pour le nombre de polynômes distincts
(100 million – 1 milliard), le stockage des coefficients peut
nécessiter 5 Go – 100 Go.
Le format de stockage interne entraîne des coûts supplémentaires
importants en termes d’utilisation de mémoire.
En plus, le format textuel externe utilisé par atlas n’est pas du tout
adapté à des résultats de cette taille.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
11 / 19
Le grand bloc de E8 (R)
Sans faire le calcul pour le grand bloc, on avait ces estimations :
Il y aura 6.083.625.251 entrées à calculer.
Si environ 50% sont non nulles, cela fait 3 milliards polynômes.
Avec 12 octets par entrée, donc 36 Go pour localiser les
polynômes.
Chaque polynôme possède au plus 32 coefficients,
mais souvent beaucoup moins.
Le plus grand coefficient ne loge pas dans 2 octets (max 65535).
Le stockage des coefficients nécessitera environ 50–100 octets
par polynôme en moyenne.
Selon les estimations pour le nombre de polynômes distincts
(100 million – 1 milliard), le stockage des coefficients peut
nécessiter 5 Go – 100 Go.
Le format de stockage interne entraîne des coûts supplémentaires
importants en termes d’utilisation de mémoire.
En plus, le format textuel externe utilisé par atlas n’est pas du tout
adapté à des résultats de cette taille.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
11 / 19
Le grand bloc de E8 (R)
Sans faire le calcul pour le grand bloc, on avait ces estimations :
Il y aura 6.083.625.251 entrées à calculer.
Si environ 50% sont non nulles, cela fait 3 milliards polynômes.
Avec 12 octets par entrée, donc 36 Go pour localiser les
polynômes.
Chaque polynôme possède au plus 32 coefficients,
mais souvent beaucoup moins.
Le plus grand coefficient ne loge pas dans 2 octets (max 65535).
Le stockage des coefficients nécessitera environ 50–100 octets
par polynôme en moyenne.
Selon les estimations pour le nombre de polynômes distincts
(100 million – 1 milliard), le stockage des coefficients peut
nécessiter 5 Go – 100 Go.
Le format de stockage interne entraîne des coûts supplémentaires
importants en termes d’utilisation de mémoire.
En plus, le format textuel externe utilisé par atlas n’est pas du tout
adapté à des résultats de cette taille.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
11 / 19
La réalité
L’ordinateur avec la plus grande quantité de mémoire dont on pouvait
disposer était sage, University of Washington (Seattle) :
64 Go de RAM
Merci William Stein !
Mais les chiffres pour E8 ne donnent pas raison aux optimistes :
3.393.819.896 entrées non nulles (soit 56%) à calculer
1.181.642.979 polynômes distincts
13.721.641.221 coefficients
coefficient maximal 11.808.808
En prenant en compte les coûts réels en mémoire, on aurait besoin
d’un ordinateur avec environ 160 Go de mémoire vive :
40 Go pour la matrice,
55 Go pour les coefficients des polynômes,
et 65 Go pour diverses structures internes (utilisées en grande
partie pour la représentation des polynômes).
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
12 / 19
La réalité
L’ordinateur avec la plus grande quantité de mémoire dont on pouvait
disposer était sage, University of Washington (Seattle) :
Merci William Stein !
64 Go de RAM
Mais les chiffres pour E8 ne donnent pas raison aux optimistes :
3.393.819.896 entrées non nulles (soit 56%) à calculer
1.181.642.979 polynômes distincts
13.721.641.221 coefficients
coefficient maximal 11.808.808
En prenant en compte les coûts réels en mémoire, on aurait besoin
d’un ordinateur avec environ 160 Go de mémoire vive :
40 Go pour la matrice,
55 Go pour les coefficients des polynômes,
et 65 Go pour diverses structures internes (utilisées en grande
partie pour la représentation des polynômes).
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
12 / 19
La réalité
L’ordinateur avec la plus grande quantité de mémoire dont on pouvait
disposer était sage, University of Washington (Seattle) :
Merci William Stein !
64 Go de RAM
Mais les chiffres pour E8 ne donnent pas raison aux optimistes :
3.393.819.896 entrées non nulles (soit 56%) à calculer
1.181.642.979 polynômes distincts
13.721.641.221 coefficients
coefficient maximal 11.808.808
En prenant en compte les coûts réels en mémoire, on aurait besoin
d’un ordinateur avec environ 160 Go de mémoire vive :
40 Go pour la matrice,
55 Go pour les coefficients des polynômes,
et 65 Go pour diverses structures internes (utilisées en grande
partie pour la représentation des polynômes).
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
12 / 19
La réalité
L’ordinateur avec la plus grande quantité de mémoire dont on pouvait
disposer était sage, University of Washington (Seattle) :
Merci William Stein !
64 Go de RAM
Mais les chiffres pour E8 ne donnent pas raison aux optimistes :
3.393.819.896 entrées non nulles (soit 56%) à calculer
1.181.642.979 polynômes distincts
13.721.641.221 coefficients
coefficient maximal 11.808.808
En prenant en compte les coûts réels en mémoire, on aurait besoin
d’un ordinateur avec environ 160 Go de mémoire vive :
40 Go pour la matrice,
55 Go pour les coefficients des polynômes,
et 65 Go pour diverses structures internes (utilisées en grande
partie pour la représentation des polynômes).
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
12 / 19
Plan
1
Le projet Atlas
Débuts
Le «cas» E8
2
Le calcul des polynômes de KLV pour le grand bloc de E8
Modifications au logiciel
Chronologie des calculs
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
13 / 19
Une idée réductrice
Si on calcule les polynômes dans (Z/n)[q] au lieu de Z[q], avec les
mêmes relations de récurrence, on obtiendra les mêmes polynômes,
mais réduits modulo n.
Ceci repose sur le fait que le coefficient µ(x, y ) est celui d’un
degré fixe de Px,y (a savoir `(y )−`(x)−1
).
2
S’il est non nul, il est bien le coefficient dominant de Px,y , mais si
deg Px,y < `(y )−`(x)−1
on a µ(x, y ) = 0.
2
Il est donc possible d’effectuer plusieurs calculs avec coefficients
modulaires, pour lesquels on aura besoin que d’un seul octet par
coefficient. Le théorème chinois permettra de reconstruire les
polynômes dans (Z/m)[q], pour m aussi grand qu’on voudra
(le p.p.c.m ; des différents n utitlisés).
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
14 / 19
Une idée réductrice
Si on calcule les polynômes dans (Z/n)[q] au lieu de Z[q], avec les
mêmes relations de récurrence, on obtiendra les mêmes polynômes,
mais réduits modulo n.
Ceci repose sur le fait que le coefficient µ(x, y ) est celui d’un
degré fixe de Px,y (a savoir `(y )−`(x)−1
).
2
S’il est non nul, il est bien le coefficient dominant de Px,y , mais si
deg Px,y < `(y )−`(x)−1
on a µ(x, y ) = 0.
2
Il est donc possible d’effectuer plusieurs calculs avec coefficients
modulaires, pour lesquels on aura besoin que d’un seul octet par
coefficient. Le théorème chinois permettra de reconstruire les
polynômes dans (Z/m)[q], pour m aussi grand qu’on voudra
(le p.p.c.m ; des différents n utitlisés).
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
14 / 19
Une idée réductrice
Si on calcule les polynômes dans (Z/n)[q] au lieu de Z[q], avec les
mêmes relations de récurrence, on obtiendra les mêmes polynômes,
mais réduits modulo n.
Ceci repose sur le fait que le coefficient µ(x, y ) est celui d’un
degré fixe de Px,y (a savoir `(y )−`(x)−1
).
2
S’il est non nul, il est bien le coefficient dominant de Px,y , mais si
deg Px,y < `(y )−`(x)−1
on a µ(x, y ) = 0.
2
Il est donc possible d’effectuer plusieurs calculs avec coefficients
modulaires, pour lesquels on aura besoin que d’un seul octet par
coefficient. Le théorème chinois permettra de reconstruire les
polynômes dans (Z/m)[q], pour m aussi grand qu’on voudra
(le p.p.c.m ; des différents n utitlisés).
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
14 / 19
Modifications pour un calcul modulaire
Deux faits ont rendu l’adaptation du logiciel atlas au calcul modulaire
très simple :
Le langage C++ permet de redéfinir les opérations +, −, × pour
une nouveau type
atlas utilisait déjà un type symbolique KLcoef
Il suffisait de définir un nouveau type avec un taille de 1 octet, redéfinir
les opérations arithmétiques de façon modulaire, et l’utiliser pour
définir KLcoef.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
15 / 19
Autre modifications du logiciel
La séparation en plusieurs calculs modulaires n’économise pas encore
assez de mémoire.
Des mesures supplémentaires ont été prises :
remplacement d’un arbre de recherche par une table de hashage,
pour l’identification de polynômes identiques,
replacement dans la matrice de pointeurs (8 octets) vers des
polynômes par des indices (4 octets)
replacement du stockage séparé des polynômes par un seul
tableau avec tous les coefficients,
adaptation pour l’utilisation de multiples «fils» parallèles,
pour mieux occuper les multiples processeurs disponibles
(16 sur sage).
En plus, les routines de sortie vers des fichiers texte ont du être
remplacées par routines binaires
Des petits programmes séparés ont aussi été écrits pour relire les
fichiers binaires, et combiner les coefficients modulaires
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
16 / 19
Autre modifications du logiciel
La séparation en plusieurs calculs modulaires n’économise pas encore
assez de mémoire.
Des mesures supplémentaires ont été prises :
remplacement d’un arbre de recherche par une table de hashage,
pour l’identification de polynômes identiques,
replacement dans la matrice de pointeurs (8 octets) vers des
polynômes par des indices (4 octets)
replacement du stockage séparé des polynômes par un seul
tableau avec tous les coefficients,
adaptation pour l’utilisation de multiples «fils» parallèles,
pour mieux occuper les multiples processeurs disponibles
(16 sur sage).
En plus, les routines de sortie vers des fichiers texte ont du être
remplacées par routines binaires
Des petits programmes séparés ont aussi été écrits pour relire les
fichiers binaires, et combiner les coefficients modulaires
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
16 / 19
Autre modifications du logiciel
La séparation en plusieurs calculs modulaires n’économise pas encore
assez de mémoire.
Des mesures supplémentaires ont été prises :
remplacement d’un arbre de recherche par une table de hashage,
pour l’identification de polynômes identiques,
replacement dans la matrice de pointeurs (8 octets) vers des
polynômes par des indices (4 octets)
replacement du stockage séparé des polynômes par un seul
tableau avec tous les coefficients,
adaptation pour l’utilisation de multiples «fils» parallèles,
pour mieux occuper les multiples processeurs disponibles
(16 sur sage).
En plus, les routines de sortie vers des fichiers texte ont du être
remplacées par routines binaires
Des petits programmes séparés ont aussi été écrits pour relire les
fichiers binaires, et combiner les coefficients modulaires
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
16 / 19
Autre modifications du logiciel
La séparation en plusieurs calculs modulaires n’économise pas encore
assez de mémoire.
Des mesures supplémentaires ont été prises :
remplacement d’un arbre de recherche par une table de hashage,
pour l’identification de polynômes identiques,
replacement dans la matrice de pointeurs (8 octets) vers des
polynômes par des indices (4 octets)
replacement du stockage séparé des polynômes par un seul
tableau avec tous les coefficients,
adaptation pour l’utilisation de multiples «fils» parallèles,
pour mieux occuper les multiples processeurs disponibles
(16 sur sage).
En plus, les routines de sortie vers des fichiers texte ont du être
remplacées par routines binaires
Des petits programmes séparés ont aussi été écrits pour relire les
fichiers binaires, et combiner les coefficients modulaires
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
16 / 19
Autre modifications du logiciel
La séparation en plusieurs calculs modulaires n’économise pas encore
assez de mémoire.
Des mesures supplémentaires ont été prises :
remplacement d’un arbre de recherche par une table de hashage,
pour l’identification de polynômes identiques,
replacement dans la matrice de pointeurs (8 octets) vers des
polynômes par des indices (4 octets)
replacement du stockage séparé des polynômes par un seul
tableau avec tous les coefficients,
adaptation pour l’utilisation de multiples «fils» parallèles,
pour mieux occuper les multiples processeurs disponibles
(16 sur sage).
En plus, les routines de sortie vers des fichiers texte ont du être
remplacées par routines binaires
Des petits programmes séparés ont aussi été écrits pour relire les
fichiers binaires, et combiner les coefficients modulaires
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
16 / 19
Plan
1
Le projet Atlas
Débuts
Le «cas» E8
2
Le calcul des polynômes de KLV pour le grand bloc de E8
Modifications au logiciel
Chronologie des calculs
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
17 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
Une course d’obstacles
mardi 19 décembre 2006. Premier calcul mod 251 (en 17 heures).
mercredi 20. L’écriture des fichiers binaires est très lente.
jeudi 21. David Vogan trouve (et répare) une faille et une
inefficacité dans les routines de sortie.
vendredi 22. David lance calcul mod 256. Plantage à y = 452274.
Outils de recombinaison sont prêts. Relance du calcul mod 256.
samedi 23. Calcul mod 256 termine avec succès !
Calcul mod 255 lancé ; plantage.
mercredi 27. Nouveau calcul mod 255 termine.
Calcul mod 253 lancé ; plantage à y = 398305.
mercredi 3 janvier 2007. Calcul mod 253 relancé.
jeudi 4. Calcul mod 253 termine. matrix-merge lancé ;
il termine (en 9 heures). coef-merge et calcul mod 251 lancés.
vendredi 5, au soir. Plantage. William Stein remplace disque par
un «backup» (fait sur modular) avec données mod 256,255,253.
Relance de coef-merge pour ces moduli.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
18 / 19
La conclusion
samedi 6, matin. Mise à jour mineure de coef-merge
(depuis les Pays-Bas).
après-midi. David (en route vers Memphis) signale
que le fichier est devenu trop grand de 28Go.
Entre temps, il rajoute les données mod 251 du disque original,
et relance matrix-merge pour ordonner ses polynômes.
soir. Je relis le programme coef-merge, sans trouver une erreur.
Relance d’une version munie de tests supplémentaires, devant
analyser le problème dès qu’il se reproduira pendant la nuit.
dimanche 7, au petit matin. Aucune erreur n’est signalée,
le (dernier) code est correct !
midi. David relance de coef-merge pour 4 moduli.
lundi 8 janvier 2007, 14h57. coef-merge termine après 27
heures de calcul.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
19 / 19
La conclusion
samedi 6, matin. Mise à jour mineure de coef-merge
(depuis les Pays-Bas).
après-midi. David (en route vers Memphis) signale
que le fichier est devenu trop grand de 28Go.
Entre temps, il rajoute les données mod 251 du disque original,
et relance matrix-merge pour ordonner ses polynômes.
soir. Je relis le programme coef-merge, sans trouver une erreur.
Relance d’une version munie de tests supplémentaires, devant
analyser le problème dès qu’il se reproduira pendant la nuit.
dimanche 7, au petit matin. Aucune erreur n’est signalée,
le (dernier) code est correct !
midi. David relance de coef-merge pour 4 moduli.
lundi 8 janvier 2007, 14h57. coef-merge termine après 27
heures de calcul.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
19 / 19
La conclusion
samedi 6, matin. Mise à jour mineure de coef-merge
(depuis les Pays-Bas).
après-midi. David (en route vers Memphis) signale
que le fichier est devenu trop grand de 28Go.
Entre temps, il rajoute les données mod 251 du disque original,
et relance matrix-merge pour ordonner ses polynômes.
soir. Je relis le programme coef-merge, sans trouver une erreur.
Relance d’une version munie de tests supplémentaires, devant
analyser le problème dès qu’il se reproduira pendant la nuit.
dimanche 7, au petit matin. Aucune erreur n’est signalée,
le (dernier) code est correct !
midi. David relance de coef-merge pour 4 moduli.
lundi 8 janvier 2007, 14h57. coef-merge termine après 27
heures de calcul.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
19 / 19
La conclusion
samedi 6, matin. Mise à jour mineure de coef-merge
(depuis les Pays-Bas).
après-midi. David (en route vers Memphis) signale
que le fichier est devenu trop grand de 28Go.
Entre temps, il rajoute les données mod 251 du disque original,
et relance matrix-merge pour ordonner ses polynômes.
soir. Je relis le programme coef-merge, sans trouver une erreur.
Relance d’une version munie de tests supplémentaires, devant
analyser le problème dès qu’il se reproduira pendant la nuit.
dimanche 7, au petit matin. Aucune erreur n’est signalée,
le (dernier) code est correct !
midi. David relance de coef-merge pour 4 moduli.
lundi 8 janvier 2007, 14h57. coef-merge termine après 27
heures de calcul.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
19 / 19
La conclusion
samedi 6, matin. Mise à jour mineure de coef-merge
(depuis les Pays-Bas).
après-midi. David (en route vers Memphis) signale
que le fichier est devenu trop grand de 28Go.
Entre temps, il rajoute les données mod 251 du disque original,
et relance matrix-merge pour ordonner ses polynômes.
soir. Je relis le programme coef-merge, sans trouver une erreur.
Relance d’une version munie de tests supplémentaires, devant
analyser le problème dès qu’il se reproduira pendant la nuit.
dimanche 7, au petit matin. Aucune erreur n’est signalée,
le (dernier) code est correct !
midi. David relance de coef-merge pour 4 moduli.
lundi 8 janvier 2007, 14h57. coef-merge termine après 27
heures de calcul.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
19 / 19
La conclusion
samedi 6, matin. Mise à jour mineure de coef-merge
(depuis les Pays-Bas).
après-midi. David (en route vers Memphis) signale
que le fichier est devenu trop grand de 28Go.
Entre temps, il rajoute les données mod 251 du disque original,
et relance matrix-merge pour ordonner ses polynômes.
soir. Je relis le programme coef-merge, sans trouver une erreur.
Relance d’une version munie de tests supplémentaires, devant
analyser le problème dès qu’il se reproduira pendant la nuit.
dimanche 7, au petit matin. Aucune erreur n’est signalée,
le (dernier) code est correct !
midi. David relance de coef-merge pour 4 moduli.
lundi 8 janvier 2007, 14h57. coef-merge termine après 27
heures de calcul.
Marc van Leeuwen (Poitiers)
atlas
Séminaire GAG
19 / 19