2.1.2 penct . . . 38 2.1.2.1 Parallélisation . . . 38 2.1.2.2 Autres personnalisations de penct . . . 41 2.2 Modélisation . . . . 42 2.2.1 Modélisation de la source . . . 42 2.2.2 Modélisation de la ligne médicale . . . 43 2.2.3 Mesure de la position de la source virtuelle . . . 44 2.3 Organisation du calcul . . . . 45 2.3.1 Simulation indépendante du patient . . . 45 2.3.2 Simulation dépendante du patient en géométrie analytique . . . 46 2.3.3 Simulation dans le modèle voxélisé du patient . . . 48 2.4 Grilles de calcul et représentation des doses . . . . 49 2.4.1 Géométries et grilles de calcul de dose . . . 49 2.4.2 Représentation des doses . . . 51 2.5 Résultats des calculs . . . . 51 2.5.1 Impact du modèle de source . . . 51 2.5.2 Impact du processus de simulation . . . 53 2.5.3 Polarisation des photons . . . 54 2.5.4 Calculs dans le matériau RW3 . . . 58 2.5.5 Calculs dans le fantôme tête humaine . . . 58 2.5.5.1 penmainet penct . . . 59 2.5.5.2 Parallélisation de penct . . . 61 2.5.5.3 Option de non suivi des électrons . . . 61 2.5.6 Comparaison avec MCNPX . . . 62 2.5.6.1 Milieu homogène . . . 62 2.5.6.2 Fantôme tête humaine . . . 63 2.5.7 Splitting du PSF . . . 64 2.5.7.1 Splittingclassique sur le PSF2 . . . 65 2.5.7.2 Particularité du Splitting sur le PSF1 . . . 66 2.6 Conclusion . . . . 67
2.1 Codes de calcul
Les deux codes PENELOPE utilisés dans cette thèse sont basés sur penmain et penct. Malgré le grand nombre de modifications apportées sur ces deux codes par rapport aux versions distribuées par les développeurs de PENELOPE, nous continuerons à les appeler par ces deux noms.
2.1.1 penmain
Le code général penmain est distribué avec le système PENELOPE pour la simulation dans les géométries décrites par des fonctions analytiques (des surfaces quadriques, dans un format nommé PENGEOM). Il est ici utilisé pour la simulation dans la géométrie hors du patient. Il a été parallélisé avec l’interface MPI (Message Passing Interface), de façon à pouvoir répartir le calcul sur un grand nombre d’ordinateurs ou coeurs de calcul, pour son inclusion dans le TPS ISOgray. D’autres options, non détaillées ici, ont été incorporées par les acteurs du projet TELEDOS [Habib 2009], puis par DOSIsoft, notamment l’écriture et la lecture des fichiers d’espace des phases (PSFs) dans un format compréssé (format binaire, orienté objet, basé sur une librairie C++ développée au CERN appelée ROOT[Brun & Rademakers 1997]).
La validation de ce code a été présentée dans la thèse de B. Habib (2009), qui démontre que les résultats en termes de doses calculées et de spectre des particules des PSFs générés sont identiques à ceux de la version standard. La scalabilité a également été démontrée, i.e. que la vitesse du calcul est bien proportionnelle au nombre de processeurs utilisés pour calculer en parallèle.
Pour ce travail de thèse, quelques options spécifiques ont dû être ajoutées par rapport au code développé pour la version standard d’ISOgray. Dans le cas d’une simulation depuis une source décrite explicitement (i.e. pas un PSF) :
• possibilité d’utiliser une source de forme elliptique
• affectation d’une polarisation aux particules primaires, et prise en compte de la polarisation au cours de leur simulation (code provenant de PENELOPE-2008).
Dans le cas d’une simulation depuis un PSF :
• ajout d’un paramètre facultatif PSFSWP au fichier d’entrée .in, permettant le décalage ver-tical des particules du PSF avant leur simulation. Le décalage est d’une distance choisie aléatoirement (indépendamment pour chaque particule) entre -PSFSWP/2 et +PSFSWP/2. Ceci est nécessaire pour la prise en compte du balayage à vitesse constante de la chaise de positionnement du patient devant le faisceau (expliqué section 1.5.1.1).
• possibilité d’activer l’option de prise en compte de la polarisation. Cependant les photons provenant du PSF sont toujours supposés non polarisés, l’enregistrement de l’état de polari-sation dans le PSF n’est pas disponible à ce jour.
2.1.2 penct
2.1.2.1 Parallélisation
Un code de simulation dans des géométries voxélisées a été développé par les créateurs de la bibliothèque de simulation PENELOPE. Ce code, nommé penct, requiert un modèle voxélisé de la
2.1 Codes de calcul
géométrie de calcul, dans lequel à chaque voxel est attribué un matériau et une masse volumique. penctcalcule la dose déposée dans chaque voxel au cours de la simulation. Dans cette thèse ce-pendant, penct désigne un programme que nous avons développé spécifiquement pour la SSRT. Il est basé sur le penct fourni dans PENELOPE, mais a été modifié pour offrir des fonctionnalités supplémentaires, et permettre le calcul parallèle, grâce à l’utilisation de la bibliothèque MPI
(Mes-sage Passing Interface). Une représentation schématique de cette parallélisation est proposée figure 2.1.
FIGURE2.1 – Organisation du programme penct parallélisé.
Le principe de cette parallélisation est similaire à celui utilisé pour penmain. Un lancement simultané deN copies du programme penct est fait sur différents processeurs (au sein d’un même ordinateur ou distribués sur une grille de calcul). Les copies travaillent indépendamment, mais peuvent communiquer entre elles grâce à des routines fournies par la bibliothèque MPI. Un des processus est désigné maître (celui dont le rang est 1), lesN − 1 autres sont désignés esclaves. Chacun effectue la lecture des fichiers d’entrée (paramètres de simulation, fichiers décrivant les matériaux et sections efficaces). Les particules à simuler sont réparties entre les esclaves (si la source est un PSF, chaque esclave utilise une particule surN − 1 du PSF, si la source est décrite explicitement, chaque esclave simule 1/(N − 1) du nombre total de particules demandées par l’utilisateur). En fin de simulation, chaque esclave envoie ses résultats au maître, qui les rassemble et écrit les fichiers de sortie.
Une autre modification importante est que le programme principal penct est désormais écrit en C++. Ce programme principal appelle une fonction simu_penct_mpi écrite en Fortran. simu_penct_mpireprend en grande partie le contenu du penct basique (décrit au chapitre 1, no-tamment figure 1.7). La couche en C++ située à un niveau au dessus du Fortran est nécessaire pour disposer dans le code Fortran de fonctions de lecture et écriture de PSF au format ROOT. Cela est nécessaire pour être compatible avec penmain au niveau du format de PSF. Cette organisation permet également de disposer dans la fonction de simulation en FORTRAN des fonctions de gestion du générateur de nombres aléatoires, qui sont elles codées en C.
En informatique, on nomme scalabilité la capacité d’un programme à augmenter la quantité totale de taches réalisées (en un temps donné) quand les ressources qui lui sont attribuées sont augmentées. Dans ce cas, on s’intéresse à la capacité du programme parallélisé à simuler d’autant plus de particules que le nombre de coeurs de calcul qui lui sont attribués est augmenté. La vitesse de calcul (en primary/s) est tracée figure 2.2, pour des simulations effectuées par penct dans les conditions d’utilisation clinique du TPS en SSRT. 108particules sont simulées dans une géométrie de patient de 94× 77 × 105 voxels, pour un volume total de 22.40 × 19.25 × 25.02 cm3, sur un PC fonctionnant sur deux processeurs quadri-coeurs Intel Xeon à 2.66 GHz (soit au plus 8 coeurs de calcul disponibles). Cette vitesse de calcul est tracée en fonction du nombre nesc = ntot− 1 de coeurs alloués aux processus esclaves (chacun des coeurs étant entièrement disponible pour penct). On a également tracé la droite de scalabilité parfaite,v(n) = v(1) × n.
FIGURE2.2 – Vitesse de calcul pour des simulations effectuées par penct paral-lélisé, en fonction du nombre de coeurs alloués aux processus esclaves. On in-dique la vitesse calculée en considé-rant le temps complet d’exécution du programme, et celle en ne considérant que le temps de simulation (i.e. sans l’initialisation). Les droites de scalabi-lité parfaite (v(n) = v(1) × n) sont éga-lement tracées (en traits plein et poin-tillé). 0 1 2 3 4 5 6 7 8 9 10 0 0.5 1 1.5 2 2.5x 10 5
Nombre de coeurs de calcul alloués aux processus esclaves
Vitesse (particules/s)
Temps complet Temps simu. seule
Temps complet si scalabilité parfaite Temps simu. seule si scalabilité parfaite
En passant de nesc = 1 à 7, le temps de calcul passe de 59.68 à 11.26 minutes, soit une augmentation d’un facteur 5.3. Dans ce cas clinique, le temps d’initialisation du calcul est long (100 secondes, il y a de nombreux matériaux à charger, à cause des tissus avec des concentrations d’iode variées), et ne dépend pas du nombre de coeurs utilisés, chaque processus devant réaliser la même initialisation. Si l’on considère le temps de simulation seul (en enlevant initialisation puis rassemblement final des résultats) le facteur d’augmentation est 6.05. L’accélération n’atteint donc pas 7, mais est tout de même très intéressante, et permet pour le calcul de dose d’un faisceau de passer d’une heure à un peu plus de 10 minutes de calcul.
2.1 Codes de calcul
parfaite (1.97, 2.89 et 3.89 au lieu de 2, 3 et 4). On s’est ici arrêté ànesc= 8, car au delà il n’est plus possible d’attribuer entièrement un des 8 coeurs à chaque esclave, et la vitesse n’augmente pas. Notons d’ailleurs dans ce dernier cas (nesc= 8) que lors de l’initialisation, il y antot= nesc + 1 = 9 processus en cours (le processus maître devant également réaliser cette initialisation). Il y a donc perte de temps à l’initialisation, car deux processus doivent se partager un seul coeur de calcul. Ainsi au pointnesc= 8, la scalabilité est bonne sur le temps de simulation seule (point rouge), mais sur le temps total (point bleu), il n’y pas d’amélioration par rapport au casnesc= 7.
La comparaison des résultats de calcul de dose entre le code parallélisé et le code standard sera présentée plus loin (section 2.5.5.2).
2.1.2.2 Autres personnalisations de penct
D’autres options ont été ajoutées par rapport au code développé pour la version standard d’ISO-gray. Dans le cas d’une simulation depuis une source décrite explicitement :
• possibilité d’utiliser une source de forme elliptique.
• affectation d’une polarisation aux photons primaires, et prise en compte de la polarisation au cours de leur simulation. Il s’agit de code source provenant de PENELOPE-2008, l’ini-tialisation de la polarisation est faite dans le programme principal. Sa prise en compte est réalisée dans la sous-routine KNOCK qui simule l’effet des interactions, grâce à la routine dédiée DIRPOL, qui est appelée en cas de diffusion Rayleigh ou Compton du photon (comme discuté plus loin, la polarisation à une influence sur la direction de diffusion).
Dans le cas d’une simulation depuis un PSF :
• possibilité d’activer l’option de prise en compte de la polarisation. L’enregistrement de l’état de polarisation dans les PSF n’est pas ajouté à ce jour, mais la polarisation des photons provenant du PSF peut être forcée à un état donné (état ayant été fourni dans le fichier d’entrée à penct).
Dans tous les cas :
• possibilité d’arrêter la simulation de l’extérieur en créant un fichier d’arrêt nommé out_merge_stop.okdans le répertoire d’où la simulation est lancée (en pratique cela permet l’arrêt volontaire de la simulation depuis le TPS, qui crée ce fichier).
• possibilité, dans la routine KNOCK gérant les collisions « dures », de ne jamais générer d’trons lors de l’interaction d’un photon. Rappelons en effet que le parcours moyen des élec-trons de notre gamme d’énergie dans les tissus est très faible. Dans les simulations Monte Carlo (en utilisant le programme shower de PENELOPE par exemple), on n’observe jamais un parcours de plus de 0.2 mm1. Les électrons déposent toujours leur dose très localement, dans le voxel même où l’interaction du photon a lieu. L’erreur faite en considérant les électrons comme absorbés immédiatement est donc très minime, ceci sera présenté plus loin.
1. La base de donnée du NIST (National Institute of Standards and Technology, http://physics.nist.gov/PhysRefData/Star/Text/ESTAR.html), donne pour les électrons de 80 keV dans l’eau un parcours déplié moyen de 97.7µm. Dans l’air, il est de 9.25 cm.