optimización de algoritmos de resolución de la...
TRANSCRIPT
PROYECTO INTEGRADOR DE LA CARRERA DE
INGENIERIA NUCLEAR
OPTIMIZACION DE ALGORITMOS DE RESOLUCIONDE LA ECUACION DE TRANSPORTE CONORIENTACION A SU PARALELIZACION
Manuel GarcıaAlumno
Dr. Eduardo VillarinoDirector
Miembros del JuradoIng. Alexis Weir (Instituto Balseiro)
Ing. Lourdes Torres (Instituto Balseiro)
Junio de 2015
Division de Ingenierıa Nuclear – INVAP S.E.
Instituto BalseiroUniversidad Nacional de Cuyo
Comision Nacional de Energıa AtomicaArgentina
A Alma,
Indice de contenidos
Indice de contenidos v
Indice de figuras ix
Resumen xiii
Abstract xv
1. Introduccion 1
1.1. Transporte de neutrones . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1. Tratamiento de las variables en la ecuacion de transporte . . . . 3
1.2. Etapas de calculo y algoritmos estudiados . . . . . . . . . . . . . . . . 4
1.2.1. Calculos de celda . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Calculos de nucleo . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Optimizacion mediante procesamiento en paralelo . . . . . . . . . . . . 6
1.4. Objetivos del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Procesamiento en paralelo y modelo de memoria compartida 9
2.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Leyes de Amdahl y de Gustafson y overhead . . . . . . . . . . . . . . . 11
2.3. Arquitecturas y modelos de programacion en paralelo . . . . . . . . . . 12
2.3.1. Memoria compartida . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. Memoria distribuida . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3. Arquitectura hıbrida . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.4. Comparacion de los modelos . . . . . . . . . . . . . . . . . . . . 14
2.4. Modelo de memoria compartida . . . . . . . . . . . . . . . . . . . . . . 16
2.5. Memoria compartida con OpenMP . . . . . . . . . . . . . . . . . . . . 19
3. Calculos de celda: flujos de respuesta 21
3.1. Tratamiento geometrico . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.1. Trazado de cuerdas . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.2. Paralelizacion del trazado de cuerdas . . . . . . . . . . . . . . . 23
v
vi Indice de contenidos
3.2. Calculo de probabilidades de colision . . . . . . . . . . . . . . . . . . . 25
3.2.1. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2. Integracion numerica . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Calculo de flujos de respuesta . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Calculo de probabilidades de colision y flujos de respuesta en paralelo . 29
3.4.1. Paralelizacion por grupos . . . . . . . . . . . . . . . . . . . . . . 30
3.4.2. Paralelizacion por nodos . . . . . . . . . . . . . . . . . . . . . . 34
3.5. Resultados numericos en CONDOR . . . . . . . . . . . . . . . . . . . . 35
3.5.1. Metodo de respuesta heterogenea . . . . . . . . . . . . . . . . . 35
3.5.2. Metodo de probabilidad de colision . . . . . . . . . . . . . . . . 38
4. Calculos de celda: esquema multigrupo 41
4.1. Esquema iterativo del metodo multigrupo . . . . . . . . . . . . . . . . 41
4.2. Esquema multigrupo en paralelo . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1. Paralelizacion por grupos de las iteraciones exteriores . . . . . . 44
4.2.2. Paralelizacion por grupos de las iteraciones termicas . . . . . . . 47
4.2.3. Paralelizacion de las operaciones matriciales . . . . . . . . . . . 51
4.3. Discusion del algoritmo paralelo optimo . . . . . . . . . . . . . . . . . . 53
5. Calculos de celda: quemado 55
5.1. Cadenas de quemado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.1. Resolucion numerica . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2. Calculo de ritmos de reaccion en paralelo . . . . . . . . . . . . . . . . . 58
5.3. Resolucion de las cadenas de quemado en paralelo . . . . . . . . . . . . 59
5.4. Resultados numericos en CONDOR . . . . . . . . . . . . . . . . . . . . 60
6. Metodo de difusion 63
6.1. Teorıa de difusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.1.1. Ecuaciones multigrupo . . . . . . . . . . . . . . . . . . . . . . . 64
6.1.2. Formulacion en diferencias finitas . . . . . . . . . . . . . . . . . 65
6.1.3. Resolucion numerica . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2. Paralelizacion de la ecuacion de difusion monoenergetica . . . . . . . . 69
6.2.1. Metodo de Jacobi . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2.2. Metodo de Gauss-Seidel . . . . . . . . . . . . . . . . . . . . . . 71
6.3. Implementacion en CITATION-CITVAP . . . . . . . . . . . . . . . . . 74
6.3.1. Metodo de Gauss-Seidel . . . . . . . . . . . . . . . . . . . . . . 74
6.3.2. Metodo de Jacobi . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.4. Discusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Indice de contenidos vii
7. Modelo de memoria distribuida y modelo hıbrido 81
7.1. Modelo de memoria distribuida . . . . . . . . . . . . . . . . . . . . . . 81
7.2. Modelo hıbrido de memoria compartida y distribuida . . . . . . . . . . 82
7.3. Mensajerıa y modelo hıbrido con MPI . . . . . . . . . . . . . . . . . . . 84
7.4. Calculo de flujos de respuesta utilizando MPI-OpenMP . . . . . . . . . 85
7.4.1. Resultados numericos en CONDOR . . . . . . . . . . . . . . . . 86
7.4.2. Discusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8. Analisis de los programas optimizados 89
8.1. Desempeno y analisis del codigo CONDOR . . . . . . . . . . . . . . . . 89
8.1.1. Resultados para HRM . . . . . . . . . . . . . . . . . . . . . . . 90
8.1.2. Resultados para probabilidades de colision . . . . . . . . . . . . 91
8.1.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.2. Desempeno y analisis del codigo CITVAP . . . . . . . . . . . . . . . . . 93
8.2.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.2.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9. Conclusiones 95
9.1. Calculos de celda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
9.2. Calculos de nucleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Agradecimientos 101
Indice de figuras
2.1. Ley de Amdahl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Arquitecturas de memoria compartida, UMA y NUMA. . . . . . . . . . 13
2.3. Arquitectura de memoria distribuida. . . . . . . . . . . . . . . . . . . . 14
2.4. Arquitectura de memoria hıbrida (compartida-distribuida). . . . . . . . 15
2.5. Jerarquıa de memoria en una arquitectura de tres niveles de cache. . . 17
2.6. False sharing entre dos procesadores. . . . . . . . . . . . . . . . . . . . 18
2.7. Modelo de ejecucion de OpenMP, fork-join. . . . . . . . . . . . . . . . . 20
3.1. Trazado de cuerdas de integracion en un sistema arbitrario rotado en un
angulo αp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Nodo generico para un calculo con HRM. . . . . . . . . . . . . . . . . . 26
3.3. Caminos opticos utilizados para el calculo probabilidades de colision con
dependencia angular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Speedup para distintos algoritmos de paralelizacion por grupos del calcu-
lo de flujos de respuesta en HRM. . . . . . . . . . . . . . . . . . . . . . 36
3.5. Escalabilidad para el calculo en paralelo por grupos de los flujos de
respuesta en HRM, con paralelismo de tasks . . . . . . . . . . . . . . . 37
3.6. Speedup para la paralelizacion por celdas del calculo de flujos de res-
puesta en HRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7. Escalabilidad para la paralelizacion por celdas sin sincronizacion en el
metodo de respuesta heterogenea . . . . . . . . . . . . . . . . . . . . . 38
3.8. Comparacion del speedup para la paralelizacion por grupos y por celdas
del calculo de flujos de respuesta en HRM. . . . . . . . . . . . . . . . . 39
3.9. Speedup para el calculo de flujos de respuesta en paralelo por grupos
para el metodo de probabilidades de colision. . . . . . . . . . . . . . . . 39
3.10. Escalabilidad de la paralelizacion por grupos con asignacion dinamica
de iteraciones en el metodo de probabilidades de colision. . . . . . . . . 40
4.1. Numero de iteraciones totales en funcion del numero de procesadores
para cuatro implementaciones distintas de la paralelizacion por grupos
de las iteraciones exteriores en el metodo multigrupo. . . . . . . . . . . 48
ix
x Indice de figuras
4.2. Speedup obtenido para el metodo multigrupo paralelizando las iteracio-
nes exteriores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3. Iteraciones totales (exteriores y termicas) hasta la convergencia en fun-
cion del numero de procesadores para la paralelizacion de los dos niveles
de iteraciones termicas del esquema multigrupo de CONDOR. . . . . . 50
4.4. Speedup para la paralelizacion de las iteraciones termicas en el metodo
multigrupo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5. Escalabilidad para la paralelizacion de las iteraciones termicas. . . . . . 51
4.6. Speedup obtenido paralelizando los calculos de transporte y de fuentes
en el esquema multigrupo. . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7. Speedup para los dos algoritmos finales para el metodo multigrupo . . . 54
5.1. Cadenas de quemado tıpicas de metales pesados. . . . . . . . . . . . . . 56
5.2. Cadenas de quemado para productos de fision. . . . . . . . . . . . . . . 56
5.3. Ejemplo de una cadena generica linealizada. . . . . . . . . . . . . . . . 58
5.4. Speedup para la paralelizacion del calculo de ritmos de reaccion. . . . . 60
5.5. Resultados para la resolucion de las cadenas de quemado en paralelo. . 61
5.6. Resultados para los calculos de quemado en paralelo. . . . . . . . . . . 61
6.1. Discretizacion de 7 puntos utilizada en el esquema de diferencias finitas
para el metodo de difusion. . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2. Grilla con puntos pares e impares para la paralelizacion del metodo de
Gauss-Seidel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3. Grilla coloreada por filas y por planos para la paralelizacion del metodo
de Gauss-Seidel con relajacion de lınea . . . . . . . . . . . . . . . . . . 73
6.4. Interfase entre los subdominios de dos procesadores para la paraleliza-
cion del metodo de Gauss-Seidel por descomposicion del dominio por
planos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.5. Iteraciones exteriores hasta la convergencia con tres paralelizaciones del
metodo de Gauss-Seidel para el metodo de difusion. . . . . . . . . . . . 76
6.6. Speedup en funcion del numero de procesadores para las tres variantes
del metodo de Gauss-Seidel implementadas en xyz. . . . . . . . . . . . 77
6.7. Tiempos de calculo obtenidos para los algoritmos paralelos del metodo
de Gauss-Seidel en geometrıa xyz. . . . . . . . . . . . . . . . . . . . . . 77
6.8. Speedup para los metodos rojo-negro en geometrıa triangular-z. . . . . 77
6.9. Tiempos de calculo obtenidos en geometrıa triangular-z. . . . . . . . . 78
6.10. Comparacion del speedup obtenido con el metodo de Jacobi y el de
Gauss-Seidel rojo-negro, ambos paralelizados por filas. . . . . . . . . . 78
6.11. Tiempo de calculo para los metodos de Jacobi y Gauss-Seidel. . . . . . 79
Indice de figuras xi
7.1. Esquema de un nodo ccNUMA compuesto por dos placas SMP, cada
una con cuatro CPUs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2. Modelo de ejecucion hıbrido MPI-OpenMP. . . . . . . . . . . . . . . . 85
7.3. Tiempos de calculo de flujos de respuesta con el modelo hıbrido MPI-
OpenMP, con y sin afinidad de tasks y threads con procesadores. . . . . 87
8.1. Speedup del codigo CONDOR paralelizado, en funcion del numero de
procesadores, para HRM. . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.2. Eficiencia para la paralelizacion de CONDOR en HRM. . . . . . . . . . 91
8.3. Speedup para la paralelizacion de CONDOR, en el metodo de probabi-
lidades de colision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.4. Eficiencia de la version de CONDOR paralelizada, para el metodo de
probabilidades de colision. . . . . . . . . . . . . . . . . . . . . . . . . . 92
8.5. Speedup para la version de CITVAP paralelizada, para dos sistemas de
distinto tamano. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Resumen
La fısica de reactores esta basada en la resolucion de la ecuacion de transporte de
neutrones, para la cual existen diversos esquemas numericos y codigos de calculo que
los implementan. La programacion en paralelo permite aumentar la velocidad de estos
codigos mediante la utilizacion de multiples unidades de procesamiento, mejorando
la capacidad de modelado. En este trabajo se estudio la paralelizacion de distintos
algoritmos asociados a la ecuacion de transporte.
Para la etapa de celda se consideraron los metodos de probabilidades de colision y
de respuesta heterogenea (HRM). El calculo de flujos de respuesta en el primer metodo
fue paralelizado por grupos de energıa, y en el segundo por grupos y elementos. Para el
metodo multigrupo correspondiente a HRM se desarrollo un algoritmo de paralelizacion
de las iteraciones termicas y de las operaciones matriciales asociadas al esquema ite-
rativo. Tambien se obtuvieron algoritmos paralelos para los calculos de quemado. Los
metodos paralelizados en esta etapa fueron implementados en el codigo CONDOR,
desarrollado en INVAP.
El metodo de difusion en diferencias finitas fue analizado para los calculos de nucleo.
La paralelizacion se realizo sobre el metodo de Gauss-Seidel, con un esquema rojo-negro
por filas. Este algoritmo fue implementado en el codigo CITVAP, basado en CITATION
2.0 de Oak Ridge.
La programacion de los algoritmos desarrollados se realizo en OpenMP, una herra-
mienta de procesamiento en paralelo en el modelo de memoria compartida. Tambien
se considero un modelo hıbrido MPI-OpenMP para el calculo de flujos de respuesta en
HRM.
Palabras clave: METODOS DE TRANSPORTE, PROCESAMIENTO EN PARA-
LELO, PROBABILIDADES DE COLISION, METODO DE RESPUESTA HETE-
ROGENEA
xiii
Abstract
Nuclear reactor physics deals with the solution of the neutron transport equation,
for which several numerical methods and resulting calculation codes exist. Using par-
allel programming to multiply the resources available to these codes, it is possible to
increase their computational power, thus improving their modelling capabilities. This
work focuses on the optimization of neutron transport algorithms by means of parallel
programming techniques.
For cell calculations, the collision probabilities and heterogeneous response (HRM)
methods are considered. In both methods, response fluxes are computed in parallel
by groups, and in HRM also by elements. For the multigroup method in HRM, paral-
lelization of thermal iterations by groups is combined with that of matrix operations
needed in the iteration scheme. Parallel methods are also developed for fuel burnup
evaluations. This algorithms are implemented in INVAP’s cell calculation code, CON-
DOR.
The diffusion method in a finite difference formulation, used for core calculations, is
optimized as well. In this case only the monoenergetic problem is considered. A parallel
Gauss-Seidel method with a red-black colouring of rows is developed. This parallel
algorithm is implemented in CITVAP, a code based on CITATION 2.0, developed in
Oak Ridge National Laboratory.
The majority of the parallel methods obtained are implemented in OpenMP, an ap-
plication for parallel programming in shared memory computers. Hybrid MPI-OpenMP
computing is also considered for the calculation of response fluxes in HRM.
Keywords: NEUTRON TRANSPORTMETHODS, PARALLEL COMPUTING, COL-
LISION PROBABILITIES METHOD, HETEROGENEOUS RESPONSE METHOD
xv
Capıtulo 1
Introduccion
“-Dr. Lecter: Okey-dokey. Here we go.”
— Hannibal, 2001.
El objetivo fundamental del calculo neutronico es conocer la distribucion espacial,
el espectro energetico y la evolucion temporal del flujo de neutrones en el nucleo de un
reactor. Conociendo estas variables, pueden calcularse los parametros de interes para
la fısica de reactores, como la reactividad, la distribucion de potencia y los coeficientes
de realimentacion de reactividad, entre otros.
El proceso de calculo de un reactor se compone de tres etapas principales. En
primer lugar deben generarse bibliotecas de datos nucleares multigrupo a partir de
datos continuos. Utilizando estas bibliotecas se realizan calculos de celda, que consisten
en obtener secciones eficaces homogeneas y a pocos grupos para las distintas zonas del
nucleo. Por ultimo se procede a la evaluacion de la distribucion de flujo en el reactor
y de parametros que la caracterizan, en la etapa de calculos de nucleo. Cada etapa se
realiza utilizando distintos niveles de aproximacion para la ecuacion de transporte de
neutrones, asociados a esquemas numericos diferentes.
En la practica, los metodos numericos utilizados en el calculo de reactores con-
ducen a programas concretos, cuya eficiencia para resolver un problema depende del
algoritmo utilizado y de la implementacion particular en terminos de programacion.
La complejidad de los sistemas que pueden ser calculados mediante estos programas
esta limitada por la capacidad de procesamiento de la que dispongan.
Aumentar la capacidad de calculo permite desarrollar programas basados en meto-
dos numericos mas precisos y analizar sistemas mas detallados o de mayor tamano.
Por otro lado, el desarrollo de aplicaciones de multifısica, incluyendo neutronica, ter-
mohidraulica y termomecanica, por ejemplo, es posible en la medida en que los recursos
utilizados por el programa lo permitan.
Ahora bien, utilizar una sola unidad de procesamiento para resolver un problema
limita significativamente la capacidad de calculo, ya que el aumento de la velocidad de
1
2 Introduccion
los procesadores fabricados es relativamente lento. Como consecuencia, para aumentar
la capacidad de un programa es necesario que este pueda utilizar mas de una unidad
de procesamiento.
Para que esto sea eficiente, se requiere modificar el algoritmo original de forma tal
de que existan tareas que puedan ser ejecutadas simultaneamente y maximizando el uso
de los recursos disponibles. La optimizacion de programas de esta forma se denomina
procesamiento en paralelo.
El objetivo de este trabajo es analizar algunos de los algoritmos de resolucion de
la ecuacion de transporte existentes y determinar la forma en la que estos pueden
ser optimizados al ser implementados en paralelo. Se estudian los problemas primero
desde un punto de vista conceptual, y luego de forma orientada a su implementacion
en programas reales.
1.1. Transporte de neutrones
Las tres etapas del calculo de reactores mencionadas se basan en el estudio de la
interaccion de los neutrones con la materia, que esta caracterizada por secciones eficaces
y por datos de ingenierıa (temperatura, densidad, etc...). En un sistema compuesto
por material fısil y por otros materiales que reaccionan con neutrones, el flujo angular
ψ(r, E, Ω, t) esta dado por la ecuacion de transporte de Boltzmann para el caso de los
neutrones, segun la cual
[1
v(E)
∂
∂t+ Ω ·∇+ Σ(r, E, t)
]ψ(r, E, Ω, t) =
=χp(E)
4π
∫
4π
∫ ∞
0
νp(E′)Σf (r, E
′, t)ψ(r, E ′, Ω′, t)dE ′dΩ′ +N∑
i=1
χdi(E)
4πλiCi(r, t)+
+
∫
4π
∫ ∞
0
Σs(r, E′ → E, Ω′ → Ω, t)ψ(r, E ′, Ω′, t)dE ′dΩ′ + S(r, E, Ω, t) . (1.1)
En la Ecuacion 1.1 las variables independientes son la posicion r, la energıa E
(v es la velocidad), la direccion angular Ω y el tiempo t. Las secciones eficaces se
denotan como Σ, y el subındice corresponde al tipo de reaccion (f para fision y s para
scattering, por ejemplo), siendo Σ sin subındice la seccion eficaz total. Por otro lado,
χ es el espectro de emision, tanto para los neutrones de fision instantaneos (νp es la
cantidad de neutrones liberados por cada fision) como para los neutrones retardados
(N es el numero de precursores o grupos de precursores, cuya concentracion es C y
su constante de decaimiento es λ). Finalmente, S es la fuente externa, es decir que no
depende del flujo.
La definicion formal de las variables de la Ecuacion 1.1, ası como una derivacion de
1.1 Transporte de neutrones 3
la misma, pueden encontrarse en cualquier libro de fısica de reactores, en particular en
[1] o en [2].
En el diseno de un reactor en general la variable de interes es el flujo escalar, definido
como
ϕ(r, E, t) =
∫
4π
ψ(r, E, Ω, t)dΩ . (1.2)
Para obtener el flujo escalar en el caso general del nucleo de un reactor, la ecuacion 1.1
es resuelta numericamente. Los metodos numericos utilizados estan determinados por
la forma en la que se tratan las cuatro variables independientes mencionadas.
1.1.1. Tratamiento de las variables en la ecuacion de trans-
porte
En la mayorıa de los metodos numericos para la Ecuacion 1.1, la variable espacial
r es discretizada en el sistema. Las regiones resultantes se caracterizan por secciones
eficaces uniformes y por datos de ingenierıa. Las variables de interes, en particular el
flujo, se aproximan dentro de cada region con algun criterio, por ejemplo con un perfil
uniforme, lineal o de orden superior.
La forma mas frecuente de tratar el comportamiento energetico es mediante el
metodo multigrupo. En esta formulacion, la variable energetica E es discretizada en
grupos, que son intervalos finitos de energıa, y se obtiene un espectro para el flujo
correspondiente a la estructura de grupos elegida. Para ello, se necesita generar una
biblioteca de datos nucleares multigrupo antes de los calculos de celda y de nucleo. Esta
etapa previa no fue analizada en este trabajo, que se centra en los calculos posteriores.
En cuanto a la variable angular Ω, existe una gran variedad de enfoques significati-
vamente diferentes. Es el tratamiento de esta variable el que define fundamentalmente
los distintos metodos numericos utilizados para resolver la ecuacion 1.1, en particular
los estudiados en el presente trabajo.
Por ultimo, la consideracion de la variable temporal t define tres tipos de calculos
notablemente distintos. En primer lugar, se tienen calculos estacionarios, en los que
la evolucion temporal no es analizada y se calculan estados en los cuales todos los
parametros del sistema son constantes. Por otro lado se tienen calculos de quemado o
de dinamica del reactor, que estudian la evolucion del nucleo a mediano y largo plazo,
usualmente utilizando un conjunto de calculos estaticos. En tercer lugar, los cambios
a corto plazo dados por variaciones relativamente rapidas de reactividad, como las
producidas por movimiento de barras de control o en casos accidentales, son estudiados
en la cinetica del nucleo.
4 Introduccion
1.2. Etapas de calculo y algoritmos estudiados
En este trabajo se analizan las etapas de calculos de celda y de nucleo. Se consideran
calculos estaticos y dinamicos (quemado), en los cuales la variable temporal no es
tratada explıcitamente. Ademas, el tratamiento energetico considerado es el metodo
multigrupo.
Los metodos numericos de transporte analizados para la etapa de celda son el de
probabilidades de colision y el de respuesta heterogenea, tratados en el Capıtulo 3. En
el Capıtulo 4 se estudia el esquema multigrupo para el caso particular de estos dos
metodos. Por ultimo, se analizan los calculos de quemado en el Capıtulo 5.
Para los calculos de nucleo, se considera el metodo de difusion en la aproximacion
de diferencias finitas, que se trata en el Capıtulo 6. Se analiza fundamentalmente la
resolucion de la ecuacion monoenergetica, ya que el esquema multigrupo es similar al
utilizado en los calculos de celda.
1.2.1. Calculos de celda
Los metodos utilizados en calculos de celda en general se basan en aproximacio-
nes relativamente precisas de la ecuacion de transporte. El tratamiento energetico y
geometrico es detallado, ya que el objetivo es generar secciones eficaces a partir de
espectros y distribuciones espaciales realistas. Ademas de la aproximacion de probabi-
lidades de colision, algunos metodos adecuados para estos calculos son el metodo de
caracterısticas (MOC) y el de ordenadas discretas (Sn).
El metodo de probabilidades de colision se basa en la forma integral de la ecuacion
de transporte, que puede escribirse como
ψ(r, E, Ω, t) =
∫ ∞
0
e−∫ s′0 Σ(r−s′′Ω,E)ds′′Q
(r − s′Ω, E, Ω, t− s′
v(E)
)ds′ , (1.3)
siendo s la distancia en la direccion Ω y Q la fuente total, dependiente del flujo. La
derivacion de la Ecuacion 1.3 tambien se encuentra en [1]. En el metodo multigrupo se
resuelve la ecuacion monoenergetica para cada grupo g, que en el caso estacionario es
ψg(r, Ω) =
∫ ∞
0
e−∫ s′0 Σg(r−s′′Ω)ds′′Qg
(r − s′Ω, Ω
)ds′ . (1.4)
Para obtener el esquema numerico del metodo de probabilidades de colision se
discretiza el sistema en volumenes de dimension finita y secciones eficaces uniformes,
donde los flujos y fuentes son tomados constantes. La descripcion de la geometrıa es
detallada, ya que el objetivo de estos calculos es obtener una distribucion espacial de
flujo relativamente precisa. Adicionalmente, se utiliza la aproximacion de scattering
1.2 Etapas de calculo y algoritmos estudiados 5
isotropico, es decir Σs independiente de Ω. Integrando analıticamente la variable angu-
lar, la Ecuacion 1.4 queda expresada en terminos de probabilidades de colision, que son
definidas y analizadas en el Capıtulo 3. La deduccion de este metodo puede encontrarse
en [1] o en [2].
El metodo de respuesta heterogenea (Heterogeneous Response Method, HRM) es
una variacion del de probabilidades de colision. En este caso el sistema es dividido en
nodos, tambien llamados celdas o elementos, que se calculan por separado utilizan-
do probabilidades de colision. Para resolver el flujo en todo el sistema, las celdas son
acopladas mediante las corrientes entre ellas. Las interfases entre celdas son discretiza-
das espacial y angularmente, lo que define probabilidades de colision con dependencia
angular. Este metodo se presenta en [3] y las probabilidades de colision utilizadas en
[4].
Tanto el metodo de probabilidad de colision como el de respuesta heterogenea se uti-
lizan para resolver la ecuacion de transporte monoenergetica. Sin embargo, el termino
de fuente de esta ecuacion para cada energıa depende del flujo en todas las energıas.
Para acoplar los calculos monoenergeticos se utiliza el metodo multigrupo, que rela-
ciona las ecuaciones 1.4 para cada grupo a traves de Qg. En [2] se describe el esquema
iterativo multigrupo, compuesto por iteraciones interiores, exteriores y termicas.
Finalmente, para estimar la evolucion de los distintos materiales presentes en el
nucleo se utiliza una sucesion de calculos estaticos, llamados pasos de quemado. Los
cambios en las densidades de los isotopos de interes entre pasos son evaluados utilizando
los flujos calculados, a partir de las relaciones entre isotopos dadas por las cadenas de
quemado. Los metodos numericos particulares para calculos de quemado pueden ser
hallados en [2].
El objetivo de los calculos de celda es generar bibliotecas de secciones eficaces utiles
para los calculos de nucleo. Para ello, se realiza el calculo a muchos grupos (tıpicamente
desde 50 a algunos miles) y se los condensa a unos pocos (en general menos de 10).
Ademas, la distribucion espacial detallada para cada grupo es utilizada para obtener
secciones eficaces homogeneas en una geometrıa con menos detalle. Se generan datos
nucleares no solo en funcion del quemado, si no tambien en funcion de otros parametros
de operacion, como temperaturas, fraccion de vacıo y densidades, entre otros.
El codigo de celda estudiado y optimizado en este trabajo es el CONDOR, desarro-
llado en INVAP S.E. Este programa utiliza el metodo de probabilidades de colision en
geometrıa unidimensional plana o cilındrica, y en cilındrica general (2D). El metodo
de respuesta heterogenea es utilizado en geometrıa bidimensional arbitraria. En ambos
casos los flujos son calculados mediante el metodo multigrupo. Los detalles de la im-
plementacion del codigo CONDOR se encuentran en [5] para el programa en general,
y en [3] se describe el metodo HRM utilizado.
6 Introduccion
1.2.2. Calculos de nucleo
A partir de las secciones eficaces condensadas y homogeneizadas, calculadas para
cada region del nucleo mediante los metodos descriptos, se prosigue a la resolucion del
perfil de flujo en el reactor. Ademas, se calculan parametros de interes del nucleo, como
coeficientes de reactividad, margenes de apagado y factores de pico.
Dado que el detalle espacial requerido en esta etapa es menor que para los calculos
de celda, se recurre a aproximaciones mas crudas de la ecuacion de transporte. De esta
forma se obtienen metodos menos costosos computacionalmente y con la capacidad
de ser utilizados para calcular el nucleo entero. Ejemplos de estos metodos son los de
difusion y B1, y los metodos nodales.
En este trabajo se analiza el metodo de difusion, en el cual el tratamiento de la
variable angular corresponde a una expansion en armonicos esfericos de dos terminos,
de forma analoga al metodo P1. Este metodo incluye aproximaciones adicionales al
metodo P1, entre ellas la Ley de Fick, segun la cual la corriente depende linealmente
del gradiente del flujo.
El metodo numerico mas utilizado en teorıa de difusion es el de diferencias finitas,
que consiste en la discretizacion de la variable espacial y en la aproximacion de las
derivadas mediante expresiones algebraicas.
El programa utilizado en este trabajo para los calculos de nucleo es CITVAP, tam-
bien desarrollado por INVAP, que se basa en el metodo de difusion en diferencias
finitas, en geometrıa tridimensional. El motor de calculo de este codigo es CITATION
2.0, creado en el Laboratorio Nacional de Oak Ridge, en Estados Unidos. Las especi-
ficaciones de este programa se presentan en [9], donde tambien se describe el esquema
de diferencias finitas utilizado.
1.3. Optimizacion mediante procesamiento en pa-
ralelo
Los metodos numericos presentados son adecuados para la etapa de calculo corres-
pondiente a cada uno. Sin embargo, la complejidad o el tamano de los sistemas resueltos
esta limitada siempre por la capacidad de procesamiento, ya que eventualmente el au-
mento del tiempo de calculo hace que la resolucion deje de ser factible.
En el caso de los calculos de celda existe una tendencia a calcular sistemas de
mayor tamano que las celdas tradicionales (cuartos de nucleo o nucleos enteros) y a
aumentar el numero de grupos. Para los calculos de nucleo aumenta el numero de
estados de operacion a calcular y el tamano de los sistemas, en particular en geometrıa
tridimensional.
Ademas, cuando se considera el acople del comportamiento neutronico del nucleo
1.4 Objetivos del trabajo 7
con fenomenos de flujo de refrigerante, transferencia de calor, transporte de especies o
reacciones quımicas, por ejemplo, es necesaria una velocidad de calculo significativa-
mente mayor que para el calculo neutronico individual.
Para que estos calculos sean realizables en un tiempo razonable, necesariamente
debe aumentar la capacidad de calculo destinado a resolver un mismo problema. Esto
implica adaptar el algoritmo y el programa a un esquema con multiples procesadores,
utilizando programacion en paralelo.
Existen diversos modelos de procesamiento en paralelo, cada uno con caracterısticas
particulares, ventajas y desventajas. Estos modelos son introducidos en el Capıtulo 2.
Allı se concluye que la opcion mas factible para programar los algoritmos desarrollados
en CONDOR y CITVAP es el modelo de memoria compartida, y en particular la
aplicacion OpenMP. Esta herramienta es utilizada para implementar los algoritmos
desarrollados en los capıtulos 3 a 6. Sin embargo, esta eleccion es revisada en el Capıtulo
7, donde se presenta el modelo de memoria distribuida en MPI y su combinacion con
OpenMP.
1.4. Objetivos del trabajo
El presente trabajo tiene dos ejes tematicos fundamentales, que se desarrollan en
conjunto durante los capıtulos siguientes. Por un lado estan los metodos numericos
asociados a la ecuacion de transporte, que son presentados en orden logico siguiendo
las etapas de calculo comentadas al inicio de este capıtulo. Por otro lado se tienen las
herramientas de procesamiento en paralelo, que son analizadas en detalle y utilizadas
para optimizar las distintas etapas del calculo neutronico.
El primer objetivo de este trabajo es entender y presentar los algoritmos de resolu-
cion de la ecuacion de transporte elegidos. Esta etapa incluye la familiarizacion con los
codigos CONDOR y CITVAP, que constituyen las aplicaciones concretas de los algorit-
mos estudiados. Por otro lado, se busca comparar distintos modelos de programacion
en paralelo y sus implementaciones concretas, para elegir la herramienta mas apta para
los problemas considerados.
En segundo lugar se busca identificar en cada metodo numerico formas de opti-
mizacion orientadas a su programacion en paralelo. Esta etapa se realiza de manera
conceptual, es decir que en principio es aplicable a cualquier programa que utilice estos
metodos. Ademas, se intenta hacer el analisis de forma independiente de la progra-
macion concreta, para que este sea valido para distintos modelos de paralelizacion.
Sin embargo, se tiene en cuenta la herramienta de programacion utilizada para ciertas
consideraciones puntuales, por ejemplo sobre el manejo de memoria, y para algunos
ejemplos.
El tercer objetivo consiste en implementar los algoritmos desarrollados en CONDOR
8 Introduccion
(calculos de celda) y CITVAP (calculos de nucleo). De esta manera, es posible comparar
el desempeno de algoritmos en casos en los que a priori no puede asegurarse que uno sea
mejor que los otros. Ademas, esto permite explorar las herramientas disponibles para
programar en paralelo en codigos de la vida real, teniendo en cuenta que CONDOR y
CITVAP constituyen la base de la lınea de calculo de la Division de Ingenierıa Nuclear
de INVAP S.E.
Capıtulo 2
Procesamiento en paralelo y
modelo de memoria compartida
“For what are we born if not to aid one another?”
— Ernest Hemingway, For whom the bell tolls, 1940.
En este capıtulo se presentan en primer lugar conceptos generales necesarios para
entender el procesamiento en paralelo, ası como definiciones y leyes que tienen que ver
con el desempeno de un programa paralelo. Luego se introducen las diversas arqui-
tecturas de procesamiento en paralelo y los modelos de programacion en los que estas
devienen.
A continuacion, se describe el modelo de memoria compartida y las razones para su
utilizacion en este trabajo, ası como las herramientas particulares para su implemen-
tacion. Finalmente, se presenta OpenMP, la aplicacion elegida para programar la gran
mayorıa de los algoritmos estudiados.
2.1. Generalidades
El procesamiento en paralelo consiste en identificar dentro de un algoritmo ope-
raciones que pueden ser realizadas simultaneamente, y emplear multiples unidades de
computo para efectuar estas operaciones de manera concurrente, mediante algun me-
canismo de coordinacion. Un programa en paralelo puede ser implementado en una
computadora con multiples procesadores/nucleos (CPUs o GPUs) o en un cluster de
un numero arbitrario de computadoras (nodos) conectadas por una red.
Tanto en algoritmos conceptuales como en sus implementaciones concretas en pro-
gramas se pueden identificar diversos esquemas de procesamiento. Estos patrones de-
terminan aspectos fundamentales del programa, como el manejo de memoria, el flujo
de datos y la logica de ejecucion. La taxonomıa de Flynn los clasifica como:
9
10 Procesamiento en paralelo y modelo de memoria compartida
Single-Instruction Single-Data (SISD): en un instante dado se trabaja en una
instruccion sobre un solo dato (programacion secuencial).
Single-Instruction Multiple-Data (SIMD): todas las unidades de procesamiento
realizan la misma instruccion en un dado instante, pero cada una sobre un dato
diferente (operaciones en paralelo sobre vectores o matrices).
Multiple-Instruction Single-Data (MISD): un mismo conjunto de datos es proce-
sado por varias unidades de ejecucion al mismo tiempo, que efectuan instrucciones
distintas.
Multiple-Instruction Multiple-Data (MIMD): en un dado instante cada proce-
sador puede estar realizando operaciones diferentes sobre datos distintos. Es el
esquema mas general y el mas utilizado, y su implementacion suele denominarse
SPMD (Single-Program Multiple-Data).
A su vez, los modos de programacion en paralelo mas usuales son:
Task parallel : se identifican tareas (tasks) dentro de un programa que pueden ser
realizadas en paralelo y se las implementa en diferentes procesadores.
Data parallel : se realiza la misma tarea en paralelo sobre distintos elementos o
grupos de elementos dentro de un dominio (SIMD, MIMD).
Independientemente de la forma en la que se implemente un algoritmo en paralelo,
los hilos de ejecucion en general deben comunicarse entre sı, dado que se dedican a
resolver el mismo problema. Este intercambio de informacion puede ser explıcito me-
diante intercambio de mensajes, o a traves de variables comunes a todos los procesos,
dependiendo de la implementacion, como se explica mas adelante. La comunicacion
entre tareas define la granularidad del algoritmo: gruesa si entre intercambios de infor-
macion se realiza un numero grande de calculos y fina si las tareas deben comunicarse
entre intervalos pequenos de calculo.
Ademas, debe existir cierto grado de sincronizacion entre las tareas realizadas en
paralelo para que el resultado del programa sea satisfactorio. Sin embargo, en general
es conveniente plantear el algoritmo de forma tal que requiera el menor grado se sin-
cronizacion posible, dado que esta suele implicar que algunas tareas deban esperar a
que otras terminen para proseguir el trabajo util, aumentando el tiempo ocioso de las
unidades de procesamiento.
El objetivo fundamental de la programacion en paralelo dentro de la computacion
de alto rendimiento (HPC) es desarrollar programas que obtengan los resultados desea-
dos mas rapidamente que los programas secuenciales. Para medir el desempeno de un
programa paralelizado respecto de su version secuencial se introducen las definiciones
siguientes:
2.2 Leyes de Amdahl y de Gustafson y overhead 11
ts: tiempo de calculo para el algoritmo en serie.
tp: tiempo de calculo para el algoritmo en paralelo, en una arquitectura dada,
con p procesadores.
Speedup (aceleracion): S = tstp, en general menor o igual a p.
Work (trabajo): W = ptp, tiempo total real de uso de procesadores.
Eficiencia: ϵ = tsptp
, en general menor que la unidad.
2.2. Leyes de Amdahl y de Gustafson y overhead
Dado que el computo en paralelo implica necesariamente mas recursos que el caso
secuencial, debe ser al menos tp < ts para que tenga sentido paralelizar un algoritmo.
Sin embargo, existen restricciones respecto del numero de unidades de procesamiento
conveniente para un dado programa. Una limitacion en este sentido esta dada por la
Ley de Amdahl (ver Figura 2.1), que establece que
S =1
f + 1−fp
, (2.1)
si f es la fraccion del codigo que es estrictamente serial, suponiendo que la eficiencia
es del 100% en la parte en paralelo y que el tamano del problema esta fijo. Esta ley
establece que el speedup tiende a 1fpara infinitos procesadores, con lo cual se llega
a un punto mas alla del cual, al agregar nucleos, se deja de acelerar el programa (la
eficiencia de la paralelizacion tiende a cero). Conceptualmente, al agregar procesadores
se acelera la parte del codigo paralelizada, que se ejecuta instantaneamente en el lımite
p → ∞, pero la parte secuencial no se acelera en absoluto, con lo cual el tiempo de
ejecucion total termina siendo el de la fraccion secuencial. Solo en el caso teorico en el
que f = 0 se tiene S = p (eficiencia del 100% en todo el algoritmo). La capacidad de un
algoritmo de ser acelerado mediante la adicion de procesadores se llama escalabilidad
fuerte.
La Ley de Amdahl resulta bastante pesimista respecto de la utilidad del procesa-
miento en paralelo, ya que establece lımites relativamente bajos para la utilizacion de
multiples procesadores. Sin embargo, esta ley no tiene en cuenta que al crecer el poder
de calculo suele aumentar tambien el tamano del problema a resolver. Ademas, la va-
riable fija en general es el tiempo de ejecucion, ya que es el usuario el que determina
cuanto esta dispuesto a esperar por un calculo. Bajo estas hipotesis (tamano variable
y tiempo de ejecucion fijo) se tiene la Ley de Gustafson, segun la cual
S = p− f(p− 1) , (2.2)
12 Procesamiento en paralelo y modelo de memoria compartida
1 10 100 1000
Número de procesadores
0
5
10
15
20
Sp
eed
up
f = 5%f = 10%f = 25%f = 50%
Figura 2.1: Ley de Amdahl.
es decir que el speedup aumenta linealmente con el numero de procesadores, con lo
cual es mucho mas optimista que la Ley de Amdahl, y en general describe mejor las
aplicaciones reales. La Ley de Gustafson mide la escalabilidad debil, que es la aceleracion
de un algoritmo al aumentar el tamano del problema, dejando fijo el trabajo de cada
procesador.
Las leyes presentadas corresponden a casos teoricos, en los que no se tienen en cuenta
las demoras e ineficiencias que existen en una aplicacion real. En todos los programas en
paralelo se tienen en mayor o menor medida comunicaciones (intercambio de mensajes
o accesos de distintos procesadores a memoria compartida), sincronizacion, desbalance
de carga entre procesadores y costos administrativos asociados a crear, coordinar y
destruir hilos de ejecucion. La perdida de eficiencia debido a estos factores puede ser
cuantificada mediante el overhead
foh =ptp − ts
ts. (2.3)
En general, para reducir el overhead se deben realizar las comunicaciones de una
manera eficiente y maximizando la relacion computo-comunicacion. Tambien se tiene
que evitar la sincronizacion excesiva y balancear lo mas posible las cargas sobre los
distintos procesadores.
2.3. Arquitecturas y modelos de programacion en
paralelo
Existen diferentes arquitecturas de computadoras paralelas, que se diferencian fun-
damentalmente en el modo en el que esta organizada la memoria respecto de los proce-
2.3 Arquitecturas y modelos de programacion en paralelo 13
Figura 2.2: Arquitecturas de memoria compartida, a la izquierda NUMA y a la derecha UMA(Fuente: [10]).
sadores. Estas arquitecturas llevan a modelos de programacion diferentes, plasmados en
implementaciones que explotan las caracterısticas de cada modelo. La memoria puede
ser compartida entre procesadores o distribuida por procesador, o una forma intermedia
entre estas dos.
2.3.1. Memoria compartida
En la arquitectura de memoria compartida (shared memory), todos los procesadores
son capaces de acceder a toda la memoria disponible para el programa, y los cambios
que un procesador realiza sobre la misma son visibles por todos los procesadores. En
este esquema los procesos se comunican compartiendo y modificando variables comunes,
por lo que la comunicacion en general es simple y rapida, dada la proximidad entre la
memoria y los nucleos.
Dependiendo de los tiempos de acceso a la memoria por los procesadores, este
modelo se subdivide en UMA (Uniform Memory Access, todos los nucleos acceden a
la memoria con igual velocidad; en general implementado como SMP, Symetric Multi-
Processor) y NUMA (Non-Uniform Memory Access, existen velocidades distintas de
acceso a la memoria; en general implementado como nodos SMP interconectados). Estas
dos variantes del modelo de memoria compartida se esquematizan en la Figura 2.2. La
forma mas usual de arquitectura NUMA es ccNUMA (cache coherent NUMA), en la
cual las caches asociadas a todas las particiones de la memoria mantienen coherencia.
2.3.2. Memoria distribuida
La arquitectura de memoria distribuida (distributed memory) se caracteriza por
el hecho de que cada procesador tiene su propia memoria, que se encuentra separada
del resto fısica o logicamente. Esta memoria no puede ser accedida por el resto de
los procesos, y la comunicacion se efectua mediante mensajes a traves de una red que
interconecta los procesadores. Si un proceso requiere datos que se encuentran en la
memoria de otro, estos deben ser transmitidos explıcitamente.
En este esquema, al aumentar el numero de procesadores dedicados a resolver el
14 Procesamiento en paralelo y modelo de memoria compartida
Figura 2.3: Arquitectura de memoria distribuida (Fuente: [10]).
problema necesariamente aumenta la memoria disponible. Ademas, el acceso de cada
procesador a su memoria privada es muy rapido, y no existe overhead asociado a
mantener coherencia entre memorias de distintos nucleos. Sin embargo, el costo de
enviar y recibir datos en general puede ser alto, dependiendo de como sea implementada
la comunicacion, con lo cual es necesario minimizar la relacion comunicacion-computo
y realizar los intercambios de informacion de manera eficiente.
Un esquema de este modelo de memoria se muestra en la Figura 2.3.
2.3.3. Arquitectura hıbrida
En este caso existen nodos de varios procesadores con memoria compartida que se
interconectan mediante una red similar al modelo de memoria distribuida (ver Figura
2.4), con lo cual se tienen caracterısticas de los dos modelos anteriores. Adicionalmente,
el sistema puede incluir aceleradores de calculo, por ejemplo GPUs. Este es el modelo
implementado en los clusters de calculo.
Los modelos que explotan este tipo de paralelismo se pueden aplicar a nodos de
memoria compartida distribuidos fısicamente (nodos ccNUMA en un cluster). Sin em-
bargo, tambien se los utiliza en espacios de memoria compartida separados logicamente
con algun criterio en subespacios de memoria distribuida (modelo de memoria compar-
tida en CPUs (sockets) o en nodos SMP, con interconexion de memoria distribuida). La
eleccion de la implementacion depende fundamentalmente de los tiempos asociados al
intercambio de mensajes comparados al overhead asociado al mecanismo de memoria
compartida entre particiones de memoria remotas.
2.3.4. Comparacion de los modelos
Los tres modelos presentados poseen ventajas y desventajas, que determinan su
conveniencia para implementar algoritmos determinados.
En sistemas distribuidos la memoria disponible es proporcional al numero de pro-
cesadores, mientras que cuando la memoria es compartida su tamano es en principio
2.3 Arquitecturas y modelos de programacion en paralelo 15
Figura 2.4: Arquitectura de memoria hıbrida (Fuente: [10]).
constante. En algunas aplicaciones este es un factor preponderante que lleva a optar
por el primer modelo. Sin embargo, los problemas estudiados en este trabajo en general
no son intensivos en terminos de memoria, por lo que este aspecto no es fundamental.
En cuanto a la interaccion entre procesos, en la mayorıa de los casos es mas eficiente
el modelo de memoria compartida, siempre que no se tenga exceso de sincronizacion
o fenomenos puntuales asociados al acceso a memoria. Sin embargo, al aumentar el
numero de procesadores aumenta el costo de mantener la coherencia de las caches de
todos los nucleos, y se pueden generar cuellos de botella debidos a la saturacion del bus
de acceso a la memoria. Estos factores tienen un efecto significativamente mayor en
las aplicaciones de memoria compartida, generando un detrimento en la escalabilidad
mayor que para el modelo de memoria distribuida.
Por otro lado, el modo de ejecucion de las aplicaciones de memoria compartida
suele ser notablemente mas flexible que el de las de memoria distribuida. En el primer
caso se pueden ejecutar ciertas regiones de codigo en paralelo y otras secuencialmente,
y los hilos de ejecucion pueden ser creados y destruidos en tiempo de corrida. En el
segundo caso la cantidad de procesos suele quedar fija desde el inicio del programa, y
en las regiones secuenciales un solo proceso es ocupado y el resto permanece ocioso.
La arquitectura hıbrida, al combinar caracterısticas de ambos modelos, posee algu-
nas de sus ventajas y sirve para mitigar problemas que suelen surgir en los modelos
puros.
En los capıtulos siguientes se utiliza el modelo de memoria compartida, principal-
mente por la flexibilidad que este ofrece si se quieren modificar partes de un programa
y dejar otras en la forma original. Ademas, este modelo es conveniente en terminos de
velocidad, aunque puede no ser optimo al aumentar el numero de procesadores mas
alla de cierto lımite, como ya se menciono. La discusion de las arquitecturas de memoria
distribuida e hıbrida, para los lımites en los cuales el modelo anterior deja de ser ideal,
se deja para el Capıtulo 7. Allı se discuten con mayor detalle las caracterısticas de estos
modelos y se explica la implementacion del calculo de flujos de respuesta utilizando
estas herramientas.
16 Procesamiento en paralelo y modelo de memoria compartida
2.4. Modelo de memoria compartida
Este modelo puede ser implementado mediante dos tipos de unidades de ejecucion
en paralelo: tasks o threads.
Un task (tarea) es un proceso independiente que es ejecutado por un procesador
seleccionado por el sistema operativo, en el momento en el que este ultimo decida
ejecutarlo. Cada task es creado por un programa y almacenado en una cola de ejecucion
del sistema, donde permanece hasta ser llevado a cabo por un procesador.
Un thread (hilo de ejecucion) es la mınima secuencia de instrucciones que puede
ser coordinada por el sistema operativo. Cada thread existe dentro de un proceso, y
comparte sus instrucciones, sus recursos y su contexto, es decir que no es independiente
del programa por el que fue creado. En un programa en paralelo basado en este modelo,
existen simultaneamente varios threads que realizan tareas simultanea y concurrente-
mente. En general puede existir un numero arbitrario de threads en un programa en
un momento dado, pero solo pueden ejecutarse simultaneamente tantos threads como
nucleos (hardware threads) existan, con lo cual un proceso con mas threads que pro-
cesadores disponibles vera degradado su desempeno, y el caso optimo es, en principio,
igual numero de threads que de procesadores.
La creacion de un task implica replicar las instrucciones y los recursos del programa
original, mientras que un thread existe dentro del contexto en el que fue creado, con
lo cual el overhead de crear un thread es significativamente menor que el de crear y
administrar un task.
Por otro lado, en una computadora moderna existe una jerarquıa de memoria,
compuesta por una memoria RAM principal (DRAM, dinamica) y varios niveles de
memoria estatica (SRAM), llamada cache. La velocidad de los niveles de cache es mas
alta cuanto mas cerca de los nucleos se encuentran, y la finalidad de este sistema es
acelerar el acceso de los procesadores a los datos. Un ejemplo de esta jerarquıa se
muestra en la Figura 2.5.
En un sistema de varios procesadores, cada nucleo posee uno o mas niveles de
cache privados, luego algunos compartidos y finalmente la memoria DRAM. En una
arquitectura UMA la memoria principal es unica, pero en una NUMA esta se encuentra
subdividida en distintas unidades, una para cada nodo (ver Figura 2.2).
Ahora bien, en un esquema de procesamiento en paralelo con memoria compartida,
un procesador accede a la memoria comun a traves de su cache. La modificacion de
una variable se efectua en la memoria cache y luego es transferida a DRAM, y las
lecturas de variables en cache deben ser primero obtenidas de la memoria principal.
Como consecuencia, las lecturas (reads) y escrituras (writes) de variables compartidas
pueden ser percibidas en ordenes distintos por diferentes procesadores. Entonces, se
deben establecer las reglas precisas que determinan el comportamiento de variables
2.4 Modelo de memoria compartida 17
Figura 2.5: Jerarquıa de memoria en una arquitectura de tres niveles de cache: L1d (datos) yL1i (instrucciones), L2 y L3.(Fuente: [11]).
compartidas cuando estas son leıdas y modificadas por diferentes procesadores.
Estas reglas constituyen el modelo de consistencia de memoria de la implementa-
cion. El modelo mas intuitivo es el de consistencia secuencial, en el cual los accesos a
la memoria son percibidos en el mismo orden por todos los procesadores. Sin embargo,
este concepto lleva a perdidas significativas de velocidad e impide optimizaciones lle-
vadas a cabo por el compilador. La gran mayorıa de las aplicaciones reales relajan la
consistencia de la memoria, llevando a modelos de consistencia debil, como se vera mas
adelante en el caso de OpenMP.
Ademas, el sistema de cache presentado implica que en un momento dado pueden
coexistir en distintos niveles de memoria copias de la misma variable, potencialmente
con diferentes valores. Para que el resultado de un programa sea correcto, tambien
hay que establecer reglas que determinen cual sera el valor de cada variable para los
diferentes procesadores en estos casos. Ası, cada implementacion asegura un cierto
grado de coherencia de las caches, que por razones de performance tambien en general
se relaja respecto de un sistema en el cual todas las copias de una variable coinciden.
La coherencia de las caches tiene un overhead asociado, pero incluso ası, en general
el intercambio de informacion compartiendo variables es mas rapido que mediante
el intercambio de mensajes. Sin embargo, existe un fenomeno llamado false sharing,
relacionado con el mecanismo de coherencia, que puede llevar a perdidas de eficiencia
muy significativas.
18 Procesamiento en paralelo y modelo de memoria compartida
Figura 2.6: False sharing entre dos procesadores (Fuente: Intel Developer Zone).
Para entender este problema, hay que tener en cuenta que el mecanismo de cache
no administra direcciones de memoria individuales, si no cache lines de tamano fijo,
tıpicamente 64 o 128 bytes. Ademas, la coherencia de las caches en general se mantiene
invalidando copias obsoletas de una variable cuando esta haya sido modificada por
alguno de los procesadores.
Ahora bien, el patron de false sharing se da cuando dos procesadores acceden a
variables distintas que se encuentran en la misma cache line, como muestra la Figura
2.6, y al menos uno de ellos las modifica. Cuando un procesador modifica una de las
variables, el mecanismo de coherencia invalida la cache line entera en el otro procesador,
que debe acceder a la memoria principal, mucho mas lenta, para conseguir la copia
modificada de esa cache line, por mas que la variable requerida no haya cambiado. De
esta forma, se genera un overhead mayor cuanto mas frecuente sea el acceso a variables
contiguas. Este fenomeno es una de las causas mas comunes de perdida de eficiencia
en aplicaciones de memoria compartida. El false sharing es facilmente detectable en
vectores o matrices, pero en otros casos puede ser muy difıcil de detectar, por ejemplo
cuando se da en variables privadas a cada thread.
Por ultimo, cuando varios procesadores acceden a las mismas variables en gene-
ral es necesario sincronizar las lecturas (reads) y escrituras (writes), para no generar
comportamientos indeterminados, como data races o race conditions. Data race se re-
fiere a una situacion en la que dos o mas procesadores acceden a la misma direccion
de memoria sin sincronizacion, y al menos uno de ellos modifica su valor, con lo cual
2.5 Memoria compartida con OpenMP 19
no se puede asegurar el resultado. Cuando el resultado de un programa con multiples
procesos depende del orden en el cual estos se ejecutan se tiene race condition.
En la practica, las implementaciones mas difundidas del modelo de memoria com-
partida son POSIX Threads y OpenMP, que explotan esencialmente los mismos niveles
de paralelismo. En este trabajo se opto por utilizar OpenMP para el desarrollo de codi-
gos en el modelo de memoria compartida, dado que mediante esta implementacion es
mas directo el paso de un programa secuencial a uno en paralelo, ya que la paraleliza-
cion se realiza mediante directivas para el compilador, y el codigo conserva una lectura
secuencial. Ademas, OpenMP ofrece una mayor portabilidad (capacidad para ejecutar
el programa en diferentes plataformas) y esta disponible en Fortran, que es el lenguaje
utilizado en este trabajo (POSIX Threads es exclusivo de C).
2.5. Memoria compartida con OpenMP
OpenMP (Open Multi-Processing) es una interfaz de programacion de aplicaciones
(API) que utiliza el modelo de memoria compartida para implementar paralelismo a
nivel de threads y tasks. Existen distintas versiones e implementaciones de la API; en
este trabajo se utilizo la version 3.1 implementada en el paquete de compiladores gcc.
La especificacion completa de OpenMP 3.1 se encuentra en [13].
El modelo de ejecucion de OpenMP es una forma de SPMD denominada fork-join,
que se esquematiza en la Figura 2.7. El codigo no tiene por que ser ıntegramente pa-
ralelo, si no que se identifican ciertas regiones que lo son, se determina el modo de
ejecutarlas, y el resto de las instrucciones pueden ser llevadas a cabo secuencialmente.
Las regiones secuenciales son ejecutadas por un master thread, que crea threads adicio-
nales al llegar a una parte en paralelo (fork). Una vez concluido el trabajo en paralelo
los threads creados son suspendidos (join) y continua la ejecucion secuencial por el
master thread. Las regiones en paralelo pueden ser ejecutadas mediante un numero
distinto y arbitrario de threads.
Adicionalmente, el modelo fork-join se puede componer de varios niveles anidados.
En este caso, cada thread creado en un fork puede crear threads adicionales y convertirse
en el master de ese grupo.
Esta flexibilidad en la ejecucion de un programa es otra de las razones por las que
se eligio OpenMP para este trabajo, ya que en los codigos CONDOR y CITVAP se pa-
ralelizaron modulos especıficos, dejando el resto del programa en su version secuencial.
OpenMP se compone de directivas para el compilador, de una librerıa de rutinas
para el control de la ejecucion y de variables de entorno.
Las directivas al compilador especifican que regiones del codigo deben ser ejecutadas
en paralelo, fijan diversos aspectos de la ejecucion, como numero de threads y alcance
de las variables (compartidas o privadas). Tambien determinan el modo de paralelismo
20 Procesamiento en paralelo y modelo de memoria compartida
Figura 2.7: Modelo de ejecucion de OpenMP, fork-join (Fuente: [10]).
(threads o tasks) y la forma de distribuir el trabajo en paralelo (loops, sections, single,
etc...). Otra funcion fundamental de las directivas es la de sincronizar los threads en
partes del codigo que de otra forma puedan conducir a race conditions o a data races.
Las rutinas de control se utilizan para modificar variables de entorno, obtener in-
formacion sobre los distintos threads durante la ejecucion del programa, establecer
sincronizacion a traves de locks sobre variables y medir tiempos de corrida, entre otras
cosas.
Finalmente, las variables de entorno determinan parametros de la ejecucion, como
numero de threads, tamano del stack (memoria privada de cada thread) o afinidad entre
threads y procesadores fısicos.
En cuanto al manejo de memoria, OpenMP implementa un modelo de consistencia
relajada (relaxed-consistency model), con lo cual el orden de reads y writes visto por
diferentes threads puede ser diferente. Tambien se relaja la coherencia de las caches,
es decir que cada thread posee una version temporal de la memoria que puede diferir
respecto de la memoria principal.
La consistencia y coherencia solo se asegura en puntos especıficos del programa
mediante la directiva flush. Todos los reads y writes situados antes que el flush son
ejecutados antes que la directiva, que ademas impone que la vision de la memoria del
thread que lo lleva a cabo sea coherente con la memoria principal. Sin embargo, el
flush es una operacion costosa, ya que implica copiar los registros a DRAM y volver a
cargar las variables necesarias, e impide optimizaciones del mecanismo de cache. Para
minimizar este overhead, esta directiva puede ser llevada a cabo para todas las variables
utilizadas por un thread o solo para un subconjunto.
Algunos de los algoritmos presentados en este trabajo fueron implementados con
funciones basicas de OpenMP, como loops paralelos o tasks sin sincronizacion. En otros
casos fueron necesarias estrategias mas complejas, con sincronizacion de bajo nivel y
flushes.
Capıtulo 3
Calculos de celda: flujos de
respuesta
“You could tell by the way that he talked, though, that he
had gone to school a long time. That was probably what was
wrong with him. George had been wise enough to get out of
school as soon as possible. He didn’t want to end up like that
guy.”
— John Kennedy Toole, A Confederacy of Dunces, 1980.
En este capıtulo se estudia la evaluacion de los flujos de respuesta que caracterizan
en la aproximacion de probabilidades de colision al sistema que se quiere calcular.
Estas magnitudes son utilizadas luego en el esquema multigrupo, que se presenta en el
Capıtulo 4, para resolver la ecuacion de transporte monoenergetica para cada grupo y
calcular los flujos en el sistema.
En primer lugar se analiza el tratamiento geometrico del sistema, que consiste en
almacenar la geometrıa en forma de cuerdas de integracion, necesarias para evaluar las
probabilidades de colision. Se estudian diversas formas en las que esta etapa puede ser
realizada en paralelo, aunque en este trabajo no fueron implementadas.
A continuacion, se definen las probabilidades de colision y flujos de respuesta uti-
lizados en el metodo de respuesta heterogenea (HRM) y en el de probabilidades de
colision tradicional. Partiendo de la forma de calculo secuencial de estas cantidades,
se analizan diversas estrategias de resolucion en paralelo. Finalmente, se explica la
implementacion de estos algoritmos en el codigo CONDOR utilizando OpenMP, y se
presentan los resultados obtenidos.
21
22 Calculos de celda: flujos de respuesta
3.1. Tratamiento geometrico
La primera etapa de la ejecucion de un codigo de celda corresponde a la lectura del
archivo de input del usuario y a su traduccion a variables utilizadas por el programa.
Esta etapa no fue analizada en este trabajo, dado que no es costosa computacionalmente
ni esta directamente relacionada con los calculos de transporte.
A continuacion, el programa debe almacenar la geometrıa del sistema de una forma
util y eficiente para los calculos posteriores, en particular para la integracion numerica
de las probabilidades de colision.
Con este objetivo, se utiliza un metodo de trazado de cuerdas de integracion (ray
tracing), que consiste en definir al sistema mediante un conjunto de trayectorias rectas
que pueden recorrer los neutrones, caracterizadas por distancias y secciones eficaces.
Estas cuerdas deben ser elegidas de forma tal que se alcance una dada precision en la
integracion numerica de las probabilidades de colision con la menor cantidad de cuerdas
posibles.
En el metodo HRM el sistema se encuentra dividido en nodos (celdas, elementos), y
el ray tracing se realiza para cada nodo por separado. Para el metodo de probabilidades
de colision tradicional el tratamiento geometrico se realiza para el sistema entero. En
el codigo CONDOR, las condiciones de borde (en vacıo o especular) son aplicadas en
esta etapa.
En caso de tener condiciones de borde especulares el sistema debe ser rotado cada
vez que una cuerda encuentra la frontera, hasta que se alcanza el numero maximo de
reflexiones fijado para el problema. Un metodo alternativo, en general menos eficiente,
es dejar la geometrıa fija y rotar el sistema de referencia de las cuerdas, cada vez que
sea necesario.
En esta etapa se guarda una gran cantidad de datos, ya que toda la informacion
geometrica del sistema queda almacenada en forma de cuerdas. Por otro lado, como
solo se guarda la geometrıa del sistema, que no varıa durante la ejecucion del pro-
grama, el ray tracing se realiza una sola vez por corrida. Luego, si bien es costoso
computacionalmente, representa una pequena fraccion del tiempo de calculo total.
Por ultimo, el ray tracing es independiente de la estructura de grupos utilizada, ya
que solo se tiene en cuenta la geometrıa del sistema.
3.1.1. Trazado de cuerdas
En la Figura 3.1 se muestra un elemento generico a resolver, que puede ser un
nodo en HRM o el sistema entero en probabilidades de colision. El algoritmo de ray
tracing implementado en CONDOR consiste en trazar lıneas rectas con y = yq cons-
tante y guardar la distancia recorrida dentro de cada material, asociado a una seccion
3.1 Tratamiento geometrico 23
Figura 3.1: Trazado de cuerdas en un sistema arbitrario rotado en un angulo αp (Fuente: [7]).
eficaz. Este procedimiento se repite para el sistema rotado en un numero de angulos
αp determinados, dejando el sistema de referencia fijo.
Utilizando la informacion de las cuerdas, una integral sobre el sistema puede apro-
ximarse como ∫
y
∫
α
f(y,α)dydα =∑
p
∑
q
ωpωqpf(yqp,αp) , (3.1)
donde ωp y ωqp son los pesos asignados a cada angulo y a cada cuerda en ese angulo. En
[4] se realiza un analisis detallado de la determinacion de estos pesos para maximizar
la estabilidad numerica, y de la optimizacion de la posicion de las cuerdas y de los
angulos de integracion. Para el caso de las posiciones yq se establecen macrobandas,
que delimitan zonas con cuerdas que atraviesan las mismas regiones.
Dado que el ray tracing optimo para la integracion de probabilidades de colision
entre volumenes es distinto al optimo para el resto de las probabilidades, que requieren
mayor detalle angular, se utilizan conjuntos de cuerdas distintas para la integracion de
volumenes y de superficies, que tambien se analizan en [4].
3.1.2. Paralelizacion del trazado de cuerdas
Teniendo en cuenta que cada cuerda de integracion es en principio independiente
del resto, el ray tracing puede ser paralelizado a diversos niveles:
1. A nivel de cuerdas: para cada angulo se pueden calcular las cuerdas en paralelo.
Esta opcion es mas eficiente cuanto mas grande sea el sistema, dado que si hay
pocas cuerdas el peso de cada tarea realizada en paralelo no justifica el costo
de administracion. Ademas, se puede generar un desbalance importante entre las
cargas sobre cada procesador, dado que la longitud de las cuerdas varıa significa-
tivamente para un dado angulo, sobre todo en casos con condicion de contorno
de vacıo.
24 Calculos de celda: flujos de respuesta
En el caso de tener condicion de borde especular, se necesita rotar el sistema
constantemente, con lo cual aumenta el trabajo por angulo, mejorando la eficien-
cia. Sin embargo, en este caso cada procesador deberıa contar con una copia del
sistema para poder rotarla libremente sin influir en el resto, lo que multiplica el
requerimiento de memoria por el numero de procesadores.
Por otro lado, se puede realizar la paralelizacion a nivel de macrobandas, es decir
por grupos de cuerdas. De esta forma disminuye la granularidad del algoritmo,
aumentando el costo de cada tarea, lo que puede aumentar la eficiencia.
2. A nivel de angulos: si se dispone de N procesadores, se puede copiar el sistema
N veces y calcular las cuerdas de integracion para N angulos αp diferentes en
paralelo. De esta forma tambien se multiplica la memoria utilizada por N , pero
es de esperar que la carga computacional sobre cada procesador sea suficiente
para compensar el overhead de la paralelizacion.
Esta opcion presenta varias ventajas. La carga sobre cada proceso es muy simi-
lar, ya que se trata del mismo sistema rotado, y la granularidad es menor, con
lo cual es de esperar que la perdida de eficiencia por cuestiones de acceso a me-
moria sea menor. Ademas, esta opcion supone cambios mınimos al metodo ya
implementado, ya que para un angulo dado el algoritmo es identico.
3. A nivel de nodos: dado que el ray tracing de cada nodo es realizado por separado,
estos calculos pueden ser efectuados en paralelo. Obviamente, esto solo tiene
sentido en los calculos con HRM.
En este caso la memoria necesaria no varıa respecto del calculo secuencial, ya
que cada procesador calcula sobre una celda que no es utilizada por ningun otro
nucleo. Ademas, es la opcion que asigna mayor cantidad de trabajo por vez a
cada procesador y requiere menos cambios para implementarla.
Sin embargo, existen dos desventajas importantes. En primer lugar, el sistema
a calcular puede estar dividido en nodos de tamanos muy diferentes, con lo que
puede generarse un desbalance muy importante entre los procesos, que puede ser
imposible de corregir. En segundo lugar, el numero de procesadores utilizados
esta limitado por el numero de nodos, con lo cual si se tienen pocos nodos se
podran usar pocos procesadores. Luego, esta opcion es factible para sistemas con
muchas celdas diferentes, y en lo posible de tamanos similares.
Las opciones presentadas no son excluyentes, si no que pueden ser combinadas. Por
ejemplo, se pueden calcular los nodos en paralelo, y dentro de cada nodo paralelizar
a nivel de angulos o a nivel de cuerdas. En este ultimo caso se puede implementar el
segundo nivel de paralelismo en un acelerador, por ejemplo una GPU.
3.2 Calculo de probabilidades de colision 25
3.2. Calculo de probabilidades de colision
Una vez trazadas las cuerdas de integracion, deben obtenerse las secciones eficaces
macroscopicas multigrupo necesarias, a partir de secciones eficaces microscopicas y
densidades numericas. Este calculo es sencillo y no se trata en este trabajo.
Para las secciones eficaces resonantes en HRM el codigo CONDOR utiliza el metodo
de subgrupos, que requiere una aproximacion inicial para los flujos. En este caso, se
realiza un calculo de transporte simplificado y a pocos grupos y luego el calculo de
transporte completo con las secciones eficaces resonantes bien calculadas. Para calculos
de probabilidad de colision estandar las secciones eficaces resonantes son dato.
A continuacion, se calculan las probabilidades de colision correspondientes a cada
metodo a partir de las cuerdas de integracion y las secciones eficaces. Estas deben ser
calculadas para cada grupo, ya que las secciones eficaces dependen del grupo energetico
que se considere.
3.2.1. Definiciones
En el caso del metodo HRM, se tienen probabilidades de colision con dependencia
angular (ver [4]). Para el nodo generico que se muestra en la Figura 3.2, se tienen las
siguientes probabilidades de colision:
pj,i = probabilidad de que un neutron nacido isotropica y uniformemente en la
region i tenga su primera colision en la region j.
psk,i = probabilidad de que un neutron nacido isotropica y uniformemente en la
region i escape del sistema por el sector k del segmento de frontera s sin colisionar.
pi,sk = probabilidad de que un neutron que entra al sistema uniformemente por el
segmento s y con flujo angular isotropico en el sector k (jk(φ, θ) = ϕk senφ cos θ)
tenga su primera colision en la region i.
ptl,sk = probabilidad de que un neutron que entra al sistema uniformemente por
el segmento s y con flujo angular isotropico en el sector k escape sin colisionar
por el sector t del segmento l.
Para el metodo de probabilidades de colision tradicional la variable angular es
integrada en forma explıcita, ya que las fronteras del sistema no son discretizadas
angularmente. Ademas, existe un unico segmento exterior. En este caso, se tienen pj,i,
ps,i, pi,s y pt,s, con los ındices k y l suprimidos de las definiciones anteriores, y la frontera
s es unica.
26 Calculos de celda: flujos de respuesta
Figura 3.2: Nodo generico para un calculo con HRM (Fuente: [7]). Se muestra la notacionutilizada.
3.2.2. Integracion numerica
Las probabilidades de colision definidas para HRM pueden calcularse, segun [4],
como
pj,i =
∫ 2π
0
∫ ymax
ymin[Ki3(τij)−Ki3(τij + τi)−Ki3(τij + τj) +Ki3(τij + τi + τj)]dydα
2πΣiVi
,
(3.2)
pi,i = 1−∫ 2π
0
∫ ymax
ymin[Ki3(0)−Ki3(τi)]dydα
2πΣiVi
, (3.3)
psk,i =
∫ α(ϕm+1)
α(ϕm)
∫ ymax
ymin[∆ki3(τi0, θn, θn+1)−∆ki3(τi0 + τi, θn, θn+1)]dydα
2πΣiVi
, (3.4)
pi,sk =2∫ ϕm+1
ϕm
∫ Assinϕ
0[∆ki3(τi0, θn, θn+1)−∆ki3(τi0 + τi, θn, θn+1)]dydϕ
πAsk
, (3.5)
psk,tl =2∫ ϕ∗
m+1
ϕ∗m
∫ Atsinϕ
0[ki3(τ0, θ
∗n+1)− ki3(τ0, θ
∗n)]dydϕ
πAtl
. (3.6)
En estas expresiones ymin e ymax corresponden al intervalo de cuerdas que para un
angulo αp dado atraviesan las regiones y superficies en cuestion, contribuyendo a la
probabilidad de colision, y τ es la distancia en caminos libres medios calculada con la
seccion eficaz total Σi para cada material, cuya notacion de subındices se muestra en
la Figura 3.3. El volumen de la region i es Vi y Ask el area del sector angular k del
segmento s, definida como Ask = Ask1(ϕm,ϕm+1)k2(θn, θn+1). Ademas, los subındices
m y n corresponden a las discretizaciones azimutal y polar de los sectores angulares, y
ϕm = max(ϕm,tl,ϕm,sk) y θn = max(θn,tl, θn,sk).
3.3 Calculo de flujos de respuesta 27
Figura 3.3: Caminos opticos utilizados para el calculo de cada probabilidad de colision condependencia angular (Fuente: [4]).
Las funciones de Bickley parciales se definen segun
kin(τ, θ) =
∫ θ
0
e−τcos−1θcosn−1θdθ , (3.7)
con lo cual kin(τ, π/2) = Kin(τ), que es la funcion de Bickley estandar.
Una vez calculadas las probabilidades de colision, en el codigo CONDOR estas son
normalizadas a partir de las ecuaciones de balance, que pueden verse en [4].
Para el metodo de probabilidades de colision las ecuaciones anteriores se reducen
al caso con un solo sector angular k, es decir sin dependencia angular. En este caso, las
probabilidades de colision quedan expresadas en terminos de las funciones de Bickley
totales. En el codigo CONDOR se integran numericamente las probabilidades pj,i, y el
resto de las probabilidades se calculan mediante relaciones de balance.
Para ambos metodos, las expresiones para las probabilidades de colision son in-
tegradas numericamente mediante la Ecuacion 3.1, esto es utilizando las cuerdas de
integracion para evaluar sobre ellas las funciones de Bickley y sumando sobre todas las
cuerdas. Las funciones de Bickley son evaluadas numericamente mediante una expan-
sion en polinomios de Chebyshev optimizada.
3.3. Calculo de flujos de respuesta
Habiendose calculado las probabilidades de colision necesarias, los flujos en el sis-
tema pueden calcularse mediante la ecuacion de transporte monoenergetica correspon-
diente a esta formulacion
ΣiViϕi =∑
j
pi,jVj[Qj + Σtrs,jϕj] +
∑
s,k
pi,skJ−sk , (3.8)
donde se asume ϕi uniforme en Vi, siendo ϕi = ϕ(Vi). Σtrs,j es la seccion eficaz de
scattering con correccion de transporte y J−sk la corriente entrante en la superficie Ask.
La fuente de acople entre grupos, compuesta por las fuentes de in-scattering y de fision,
28 Calculos de celda: flujos de respuesta
esta dada por
Qi,g =∑
g′ =g
Σtrs,i,g′→gϕi,g′ +
χg
k
∑
g′
νΣf,i,g′ϕi,g′ , (3.9)
para el reactor asociado en k (el factor de multiplicacion), siendo Σtrs,i,g′→g la seccion
eficaz de scattering desde el grupo g′ al g, con correccion de transporte, νΣf,i,g′ la
cantidad de neutrones por fision multiplicada por la seccion eficaz de fision del grupo
g′ y χg el espectro de fision para el grupo g.
Ahora bien, la resolucion de los flujos en el metodo multigrupo a partir de la Ecua-
cion 3.8 implica iteraciones interiores costosas dentro de cada grupo. Teniendo en cuenta
que estas iteraciones deben realizarse para cada iteracion exterior, es conveniente re-
solver la ecuacion monoenergetica mediante otro enfoque. Para ello, se introducen los
flujos de respuesta y las probabilidades de multiples colisiones.
El flujo de respuesta a fuentes Xi,j se define como el flujo integrado en Vi producido
por una fuente unitaria en la region j. Luego, para calcularlo se anulan las corrientes
externas y las fuentes en todos los volumenes menos en la region j, y se calcula el
flujo en i mediante la Ecuacion 3.8. Por otro lado, el flujo de respuesta a corrientes
entrantes Yi,sk es el flujo integrado en Vi debido a una corriente unitaria en el sector
k del segmento s, y se calcula anulando las fuentes y todas las corrientes menos la del
sector sk, donde se aplica una corriente unitaria. Este proceso puede ser expresado en
forma matricial como
X = M−1P , (3.10)
Y = M−1γ , (3.11)
con [P ]i,j = pi,j , [γ]i,sk = pi,sk y [M ]i,j = δi,jΣi − Σs,ipi,j , siendo X e Y las matrices de
flujos de respuesta.
Una vez conocidos los flujos de respuesta, el flujo en cada grupo puede ser calculado
como
ϕ = XQ+ Y J− , (3.12)
donde ϕ, Q y J− son los vectores de flujos, fuentes y corrientes entrantes, respectiva-
mente. La Ecuacion 3.12 se utiliza en el esquema multigrupo para resolver los flujos en
cada grupo a partir de la fuente de acople dependiente del resto de los grupos.
En el metodo de probabilidades de colision la Ecuacion 3.12 basta para calcular los
flujos en el sistema para cada energıa. Las condiciones de borde de vacıo o de reflexion
especular son tenidas en cuenta en el calculo de las probabilidades de colision, como ya
se menciono. Para condiciones de borde con albedo, la corriente entrante J− se calcula
a partir de la probabilidad de escape de multiples colisiones y del albedo del sistema.
En el metodo HRM, por el contrario, primero deben calcularse las corrientes de
acople entre nodos. Para esto se necesitan las probabilidades de escape E y las trans-
3.4 Calculo de probabilidades de colision y flujos de respuesta en paralelo 29
misiones T de multiples colisiones, que se pueden expresar matricialmente como
E = e+KX , (3.13)
T = t+KY , (3.14)
con [e]sk,i = psk,i, [t]sk,tl = psk,tl y [K]sk,j = Σs,jpsk,j . Con estas matrices pueden calcu-
larse iterativamente las corrientes entrantes mediante
J+ = T J− + EQ , (3.15)
si las corrientes salientes J+ estan relacionadas geometricamente con las entrantes
segun J+ = HJ−. De esta forma, una vez conocida la fuente de fision y scattering para
el grupo g se pueden calcular las corrientes entrantes a cada nodo iterando sobre la
Ecuacion 3.15 y los flujos mediante la Ecuacion 3.12.
En resumen, el calculo de los flujos de respuestaX e Y , y de E y T en HRM, consiste
fundamentalmente en operaciones matriciales a partir de las probabilidades de colision
integradas sobre las cuerdas. Estas matrices deben ser calculadas independientemente
para cada grupo, ya que caracterizan a la ecuacion de transporte monoenergetica.
Para concluir, es importante mencionar que en los calculos de quemado se pueden
evaluar los flujos de respuesta mediante metodos variacionales. Si la variacion de las
secciones eficaces de transporte y de self-scattering entre pasos de quemado, para un
dado grupo, es menor que una cierta tolerancia, entonces X e Y pueden ser estimados
(ver [5]) como
Xn = [I+Xn−1(δΣ− δΣs)]−1Xn−1 , (3.16)
Yn = [I+Xn−1(δΣ− δΣs)]−1Yn−1 , (3.17)
si δΣ = Σn−Σn−1, δΣs = Σn,s−Σn−1,s, I es la matriz identidad y n el paso de quemado.
Esta forma de evaluar los flujos de respuesta es significativamente menos costosa que
mediante el metodo usual, ya que no se necesita evaluar las probabilidades de colision,
y el calculo de X e Y es mas simple. En la version del codigo CONDOR optimizada en
este trabajo, esta aproximacion se utiliza en el metodo de probabilidades de colision,
pero tambien puede ser implementada para HRM.
3.4. Calculo de probabilidades de colision y flujos
de respuesta en paralelo
En esta seccion se analizan las diversas formas en las que el calculo de las probabi-
lidades de colision y de los flujos de respuesta puede ser paralelizado. Se presentan los
30 Calculos de celda: flujos de respuesta
algoritmos, con sus ventajas y desventajas, de forma conceptual. Ademas, se muestran
algunos ejemplos concretos de la implementacion en OpenMP. Los resultados de estos
metodos se comentan en la seccion siguiente.
3.4.1. Paralelizacion por grupos
Las matrices X, Y , E y T (solo X e Y en probabilidad de colision) deben ser
calculadas para todos los grupos de energıa individualmente, ya que cada grupo tiene
secciones eficaces, y por lo tanto probabilidades de colision, diferentes. Entonces, el
calculo se puede realizar en paralelo en este sentido.
Se proponen dos algoritmos diferentes. Por un lado, se pueden calcular las proba-
bilidades de colision y los flujos de respuesta de cada grupo en un mismo procesador,
con lo cual no es necesaria la interaccion entre procesadores. Por otro lado, se pueden
realizar estos calculos por separado, pero se necesita la interaccion entre procesadores
para poder utilizar las probabilidades de colision para calcular los flujos de respuesta
correspondientes.
3.4.1.1. Algoritmo sin sincronizacion
Para calcular las probabilidades de colision y flujos de respuesta de diferentes grupos
en paralelo, basta con dividir el loop sobre los grupos entre los procesadores disponibles.
Para esto, se puede utilizar paralelismo de tasks, generando un task por grupo, o
paralelismo de loop, simplemente asignando los grupos a distintos procesos.
Esta estrategia lleva a un algoritmo de granularidad gruesa, ya que se genera una
tarea relativamente costosa por cada grupo, compuesta por la integracion de las proba-
bilidades de colision y el calculo de X, Y , E y T . Ademas, la programacion es directa,
ya que no se necesita interaccion ni sincronizacion entre procesos. Sin embargo, este
esquema presenta algunas limitaciones.
Por un lado, el numero de procesadores que es posible utilizar esta limitado al
numero de grupos, con lo cual si se cuenta con mas nucleos que grupos quedan recursos
sin usar. Sin embargo, es mas importante el desbalance de cargas entre procesadores
producida por el hecho de que en general el numero de grupos no es multiplo del numero
de nucleos disponibles.
Si, por ejemplo, se utiliza una biblioteca de datos nucleares de 69 grupos (valor
tıpico) y se tienen 16 procesadores, la eficiencia maxima alcanzable es del 86,25%.
Para 64 nucleos la eficiencia maxima disminuye al 54%, y el tiempo de calculo con 64
procesadores sera el mismo que con 35. Luego, la paralelizacion por grupo ofrece una
escalabilidad fuerte (con numero de grupos constante) relativamente pobre.
La escalabilidad debil, considerando el aumento del numero de grupos y del tamano
del sistema, tambien es muy limitada para este metodo. Esto se debe a que la tendencia
3.4 Calculo de probabilidades de colision y flujos de respuesta en paralelo 31
Algoritmo 3.1 Paralelizacion por grupos sin sincronizacion para el metodo de proba-bilidades de colision.!$OMP parallel shared(X, Y, ...) private(...)!$OMP do schedule(...)for g = 1 to G do
RT, XS(g) ⇒ PC(g)PC(g) ⇒ X(g), Y (g)
end for!$OMP end do!$OMP end parallel
mas comun es aumentar el tamano del sistema a calcular dejando el numero de grupos
constante.
Otro factor que contribuye al desbalance de cargas proviene del truncamiento del
camino optico de los neutrones en el calculo de las probabilidades de colision. Al in-
tegrar numericamente las probabilidades de colision sobre las cuerdas de integracion
se considera que los neutrones no pueden viajar mas alla de un cierto numero de ca-
minos libres medios τ , a partir del cual el valor de la funcion de Bickley se considera
despreciable. Ahora bien, el camino libre medio en los grupos rapidos es mas grande
que en los grupos termicos, ya que las secciones eficaces son menores, con lo cual se
debe integrar sobre cuerdas mas largas. Para un combustible MTR con agua liviana en
HRM, por ejemplo, el calculo de las probabilidades de colision en el grupo de mas alta
energıa es aproximadamente un 10% mas costoso que en el grupo menos energetico.
Por otro lado, cuando se usa el metodo variacional para calcular los flujos de res-
puesta (en el caso del CONDOR en el metodo de probabilidades de colision) tambien
puede ser difıcil generar cargas similares para todos los procesadores. Esto se debe a
que entre pasos de quemado las secciones eficaces se modifican de forma muy diferente
para los distintos grupos. Luego, el metodo variacional en general es utilizado en una
cierta fraccion de los grupos, dependiendo de los parametros del sistema. En este caso,
la mejor opcion es el paralelismo mediante tasks o la asignacion dinamica de iteraciones
del loop sobre los grupos, ya que de esta forma el algoritmo se adapta mas facilmente
a diferencias en los costos de calcular cada grupo.
Por ultimo, la paralelizacion por grupo multiplica la memoria necesaria por el nume-
ro de procesadores utilizados. Esto se debe a que en el caso secuencial se calculan las
matrices X, Y , E y T para un grupo determinado y despues pueden ser guardadas
en el disco para ser utilizadas luego en el calculo multigrupo. En el calculo en parale-
lo existen en memoria al mismo tiempo tantos juegos de matrices como procesadores
esten siendo utilizados.
La implementacion en OpenMP para el caso del metodo de probabilidades de coli-
sion y utilizando paralelismo de loop corresponde al Algoritmo 3.1. Las instrucciones
32 Calculos de celda: flujos de respuesta
marcadas con !$OMP representan directivas de OpenMP. En primer lugar, el master
thread crea un grupo de threads con la directiva parallel (etapa de fork), donde se
especifican las variables que deben ser compartidas por los threads y las que deben
ser privadas. A continuacion, la directiva do significa que las iteraciones del loop so-
bre los G grupos seran distribuidas entre los threads creados de la forma indicada por
la clausula schedule. Una vez que todas las iteraciones han sido llevadas a cabo, la
directiva end parallel determina la desaparicion de todos los threads creados (join).
Cada iteracion realizada en paralelo comienza con en el calculo de las probabilidades
de colision para el grupo g, a partir del ray tracing (RT ) y las secciones eficaces
multigrupo (XS ). A continuacion, se obtienen los flujos de respuesta X e Y del sistema,
a partir de las probabilidades de colision. Para el metodo HRM deben calcularse ademas
la transmision y la probabilidad de escape de multiples colisiones.
3.4.1.2. Algoritmo con sincronizacion
Una alternativa a este algoritmo consiste en calcular las probabilidades de colision
y los flujos de respuesta por separado, esto es en distintos procesadores. Obviamente,
para calcular los flujos de respuesta y las probabilidades de multiple colision en un
grupo dado se necesitan sus probabilidades de colision, con lo cual es necesaria la
sincronizacion e interaccion de los procesadores.
Una posible implementacion de este esquema en OpenMP utilizando paralelismo
de tasks, para el metodo HRM, es el Algoritmo 3.2. En primer lugar el master thread
crea un grupo de threads. El codigo es ejecutado por uno de los threads (single), que
crea tasks que pueden ser llevados a cabo por cualquier thread del grupo. Luego de que
todos los tasks hayan sido completados, los threads adicionales desaparecen.
Cada task generado en el primer loop sobre los grupos consiste en el calculo de las
probabilidades de colision en los N nodos para un grupo g, a partir del ray tracing
para cada nodo n y las secciones eficaces del grupo g. Una vez que un thread calcula
las probabilidades de colision para un grupo, la directiva flush hace que su cache sea
coherente con la memoria principal, para que estas sean visibles por los otros threads.
A continuacion, se actualiza la componente g de flags de forma atomica, es decir que
si otro thread esta tratando de leer esta variable vera el resultado nuevo o el viejo,
pero no podra obtener una copia incompleta de la actualizacion. Por ultimo, el valor
actualizado de flags(g) es copiado a DRAM para que sea visible por el resto del grupo.
El segundo loop sobre los grupos genera tasks que se componen del calculo de
las matrices X, Y , E y T para cada grupo g, para todos los elementos del sistema.
Ahora bien, para cada grupo se necesitan las probabilidades de colision, que pueden ser
calculadas por un thread diferente al que calcula los flujos de respuesta o pueden estar
siendo calculadas al momento de ejecutar el task. Para ello, el while loop inicial solo se
3.4 Calculo de probabilidades de colision y flujos de respuesta en paralelo 33
Algoritmo 3.2 Paralelizacion por grupos con sincronizacion para el metodo HRM.
!$OMP parallel shared(PC,X, Y,E, T, flags, ...) private(n, flag, ...)!$OMP singlefor g = 1 to G do
!$OMP taskfor n = 1 to N do
RT (n), XS(g) ⇒ PC(n, g)end for!$OMP flush(PC)!$OMP atomic writeflags(g) = true!$OMP flush(flags)!$OMP end task
end forfor g = 1 to G do
!$OMP task untiedwhile () do
!$OMP flush(flags)!$OMP atomic readflag = flags(g)if flag = true then
breakend if!$OMP taskyield
end while!$OMP flush(PC)for n = 1 to N do
PC(n, g) ⇒ X(n, g), Y (n, g), E(n, g), T (n, g)end for!$OMP end task
end for!$OMP end single!$OMP end parallel
interrumpe una vez que se obtiene un valor verdadero para flags(g) (leıdo atomicamente
de la memoria principal). Cuando esto sucede, se obtienen de DRAM las probabilidades
de colision para el grupo g y se calculan las matrices X, Y , E y T .
Un detalle de los tasks generados en el segundo loop consiste en la clausula untied en
la creacion de cada task y en la directiva taskyield. Esta ultima instruccion determina
que en ese punto la tarea puede ser suspendida en favor de otro task. Esto es importante
para que un thread no permanezca un tiempo excesivo en el loop de sincronizacion si las
probabilidades de colision del grupo g no estan disponibles. De esta forma, un thread
puede rotar entre tasks hasta encontrar uno que pueda ser completado. La clausula
untied determina que si el task es suspendido, puede ser reanudado por un thread
diferente al que lo inicio la primera vez.
34 Calculos de celda: flujos de respuesta
De esta forma, se obtiene un algoritmo con el doble de tareas a ejecutar en paralelo,
lo que puede mejorar el balance de cargas. Sin embargo, el overhead de administra-
cion es claramente mayor, debido a la sincronizacion y a los flushes. Entonces, esta
opcion sera viable si el problema es suficientemente grande, de forma que la relacion
computo-sincronizacion compense estas perdidas de eficiencia. Ademas, si bien el algo-
ritmo presentado corresponde al metodo HRM, para el metodo de probabilidades de
colision el codigo es el mismo, pero al no existir nodos el loop sobre n desaparece, y las
matrices E y T no son calculadas.
Por otro lado, si el codigo es ejecutado secuencialmente, no se generan tasks, si
no que las instrucciones son ejecutadas directamente por el unico thread presente. La
sincronizacion es consistente en este caso, ya que todas las probabilidades de colision
son calculadas antes de comenzar a calcular los flujos de respuesta.
Finalmente, en caso de utilizarse el metodo variacional, la comparacion de las sec-
ciones eficaces entre los dos pasos de quemado se puede realizar para cada grupo en el
primer loop, y con un vector de control similar a flags se puede identificar a los grupos
que deben ser calculados de forma variacional. Para estos grupos, las probabilidades de
colision no necesitan ser calculadas, y los flujos de respuesta se calculan directamente
en el segundo loop.
3.4.2. Paralelizacion por nodos
Una caracterıstica del metodo HRM es que los flujos de respuesta para cada nodo se
calculan independientemente, y el sistema entero se acopla en un paso posterior, cuando
se calculan las corrientes entre celdas. Luego, para un grupo dado se pueden calcular las
probabilidades de colision y luego las matrices X, Y , E y T para cada nodo en paralelo,
obteniendose un algoritmo con granularidad mas fina que para la paralelizacion por
grupo. Obviamente, esto no tiene sentido en el metodo de probabilidades de colision,
en el que el sistema no se encuentra subdividido.
Suponiendo que el calculo se realiza secuencialmente por grupos, al paralelizar por
nodos tambien se pueden producir desbalances grandes entre los procesadores, ya que
el tamano (numero de mallas) de los nodos puede ser muy dispar. Ademas, teniendo en
cuenta que el numero de celdas diferentes definidos inicialmente suele ser pequeno (tıpi-
camente alrededor de 10) esta opcion parece muy limitada en cuanto a escalabilidad.
Sin embargo, si se realiza un calculo de quemado cada nodo se quema independiente-
mente, con lo cual se diferencia del resto de los nodos inicialmente identicos. Entonces,
el problema puede ser paralelizado en mas procesadores que en el estado inicial, y la
asignacion de celdas a nucleos puede ser mas eficiente.
De todas formas, paralelizar solo por celdas no parece la forma mas conveniente,
ya que no se aprovecha el paralelismo natural por grupos. Entonces, los dos metodos
3.5 Resultados numericos en CONDOR 35
Algoritmo 3.3 Paralelizacion por grupos y nodos sin sincronizacion (HRM).
!$OMP parallel shared(X, Y,E, T, ...) private(...)!$OMP do schedule(...) collapse(2)for g = 1 to G do
for n = 1 to N doRT (n), XS(g) ⇒ PC(n, g)PC(n, g) ⇒ X(n, g), Y (n, g), E(n, g), T (n, g)
end forend for!$OMP end do!$OMP end parallel
pueden ser combinados para calcular grupos y celdas en paralelo. En este caso, si por
ejemplo se calcula a 69 grupos un sistema de 10 nodos se tienen 690 tareas que pueden
ser ejecutadas en paralelo. Con 64 procesadores se tiene una eficiencia maxima del
98% debido al balance de cargas, si el tamano de los nodos es uniforme, mejorando
significativamente la paralelizacion por grupos.
En primer lugar, se pueden calcular probabilidades de colision y flujos de respues-
ta en la misma tarea, de forma tal de no necesitar interaccion entre procesadores ni
sincronizacion. Utilizando paralelismo de loop, este esquema puede ser implementado
como se muestra en el Algoritmo 3.3. En este caso se distribuyen las iteraciones de los
loops sobre g y n entre los threads. La clausula collapse determina cuantos niveles de
loops deben ser colapsados en un mismo espacio de iteracion paralelizado.
Como segunda opcion, se pueden realizar los calculos de probabilidades de colision
y flujos de respuesta por separado, por ejemplo generando dos tasks por nodo para
cada grupo, uno para el calculo de probabilidades de colision y el otro para el de flujos
de respuesta. En este caso la sincronizacion es similar a la utilizada en el algoritmo por
grupos, pero con el vector flags por grupos y nodos.
3.5. Resultados numericos en CONDOR
En esta seccion se muestran los resultados obtenidos para la paralelizacion del
calculo de flujos de respuesta mediante los distintos algoritmos presentados. Para el
metodo de respuesta heterogenea se probaron paralelizaciones por grupos y por celdas,
y para el de probabilidades de colision solo por grupos.
3.5.1. Metodo de respuesta heterogenea
Para el metodo HRM se implementaron diversas variantes de las paralelizaciones
por grupos y por celdas.
36 Calculos de celda: flujos de respuesta
2 4 6 8 10 12
Número de procesadores
0
2
4
6
8
10
12
Speedup
Sin sinc. (loop)Con sinc. (loop)Con sinc. (tasks)
Figura 3.4: Speedup obtenido con las tres variantes de paralelizacion por grupos, en funciondel numero de procesadores, para el metodo HRM.
3.5.1.1. Paralelizacion por grupos
Se implementaron tres metodos diferentes para la paralelizacion por grupos. Por un
lado se utilizo el calculo de las probabilidades de colision y flujos de respuesta juntos
dado por el Algoritmo 3.1, con paralelismo de loop y sin sincronizacion. Por otro lado se
implementaron dos variantes del metodo con sincronizacion: con tasks (Algoritmo 3.2)
y con el loop sobre g en paralelo. Los resultados obtenidos con estas tres opciones para
un elemento combustible MTR de placas planas se muestran en la Figura 3.4. Como se
ve, el speedup para todos los casos es esencialmente el mismo y la escalabilidad fuerte
es similar.
Para analizar la escalabilidad debil, se calcularon combustibles MTR de distintos
tamanos y cantidad de celdas. Los resultados para el caso de la paralelizacion por
grupos utilizando tasks y sincronizacion se muestran en la Figura 3.5. Para los otros
dos metodos la escalabilidad es similar.
Como consecuencia de estos resultados, se concluyo que realizar el calculo de pro-
babilidades de colision y flujos de respuesta por separado no trae ninguna ventaja
en cuanto a speedup. Luego, teniendo en cuenta que el algoritmo con sincronizacion
es significativamente mas complejo, el metodo simple con paralelismo de loop es mas
conveniente.
3.5.1.2. Paralelizacion por grupos y nodos
La paralelizacion por nodos se implemento con las mismas tres variantes utilizadas
en el metodo por grupos. Para compararlas, se calculo el mismo elemento combustible
MTR que en el caso anterior, obteniendose el speedup de la Figura 3.6.
En este caso sı se observa una diferencia notable en la velocidad de los tres metodos.
En particular el algoritmo con paralelismo de loop y sin sincronizacion tiene un speedup
3.5 Resultados numericos en CONDOR 37
2 4 6 8 10 12
Número de procesadores
0
2
4
6
8
10
12Speedup
Nr
=312 / N =9
Nr
=1824 / N =13
Nr
=3600 / N =17
Figura 3.5: Speedup para distintas cantidades de regiones Nreg y de celdas Ncel, para elalgoritmo por grupos con tasks y sincronizacion.
2 4 6 8 10 12
Número de procesadores
0
2
4
6
8
10
12
Speedup
Sin sinc. (loop)Con sinc. (loop)Con sinc. (tasks)
Figura 3.6: Resultados para las tres variantes de paralelizacion por celdas para HRM.
38 Calculos de celda: flujos de respuesta
2 4 6 8 10 12
Número de procesadores
0
2
4
6
8
10
12
Speedup
Nr
=312 / N =9
Nr
=1824 / N =13
Nr
=3600 / N =17
Figura 3.7: Escalabilidad debil para la paralelizacion por nodos sin sincronizacion.
en funcion del numero de procesadores muy cercano al ideal (S = p). Los resultados de
este metodo para combustibles MTR de diferentes tamanos se muestran en la Figura
3.7, donde se ve que la escalabilidad es mejor cuanto mas grande sea el sistema, como
era esperable.
Teniendo en cuenta los resultados obtenidos, la paralelizacion por nodos resulta
mas eficiente sin sincronizacion. Esto probablemente se debe a que el overhead de las
otras dos opciones, asociado a la sincronizacion y al manejo de tasks en la ultima, tiene
un impacto negativo en el rendimiento.
3.5.1.3. Comparacion de las dos opciones
Para establecer el algoritmo optimo de paralelizacion del calculo de los flujos de res-
puesta se compararon los resultados obtenidos paralelizando por grupos y por celdas.
Para esto se utilizo la mejor opcion en cada caso: tasks con sincronizacion y para-
lelismo de loop sin sincronizacion, respectivamente. Como se ve en la Figura 3.8, la
paralelizacion por celdas es claramente mas eficiente, incluso para pocos procesadores.
Entonces, se determino que el mejor algoritmo de paralelizacion de los flujos de
respuesta en HRM es el metodo por celdas, sin sincronizacion. Esta opcion posee gra-
nularidad mas fina que el metodo por grupos, con lo cual las cargas por procesador
estan mejor balanceadas, sobre todo al aumentar el numero de nucleos. Ademas, el
overhead de esta implementacion es despreciable, obteniendose un speedup cercano a
S = p.
3.5.2. Metodo de probabilidad de colision
Para el metodo de probabilidades de colision se paralelizo el calculo de flujos de res-
puesta por grupos. Teniendo en cuenta los resultados para HRM, no se implementaron
3.5 Resultados numericos en CONDOR 39
2 4 6 8 10 12
Número de procesadores
0
2
4
6
8
10
12
Speedup
Por grupos (tasks con sinc.)Por celdas (loop sin sinc.)
Figura 3.8: Comparacion del speedup para la paralelizacion por grupos y por celdas del calculode flujos de respuesta en HRM.
2 4 6 8 10 12
Número de procesadores
0
2
4
6
8
10
Speedup
Loop dinámicoLoop estático
Figura 3.9: Speedup para la paralelizacion por grupos del calculo de flujos de respuesta en elmetodo de probabilidad de colision.
algoritmos con sincronizacion. Se utilizo paralelismo de loop con dos opciones: asigna-
cion estatica de iteraciones, es decir segun un patron definido en tiempo de compilacion,
y asignacion dinamica, en tiempo de ejecucion.
Los resultados para ambas opciones se muestran en la Figura 3.9, para un problema
en geometrıa unidimensional. Como puede observarse, el speedup para la implementa-
cion con asignacion dinamica de iteraciones del loop sobre los grupos presenta una
escalabilidad mayor.
Esto se debe a que cuando se utiliza el metodo variacional para calcular los flujos
de respuesta el calculo es significativamente mas rapido. Sin embargo, este metodo se
utiliza solo en una fraccion de los grupos. Entonces, si los grupos son mapeados a los
procesadores de una forma predeterminada se generan desbalances importantes, porque
no hay forma de predecir en que grupos se utilizara el metodo variacional. Entonces,
40 Calculos de celda: flujos de respuesta
2 4 6 8 10 12
Número de procesadores
0
2
4
6
8
10
Speedup
N = 200N = 400N = 600
Figura 3.10: Escalabilidad de la paralelizacion por grupos con asignacion dinamica de itera-ciones en el metodo de probabilidades de colision.
asignar grupos a threads a medida que estos estan disponibles es mas conveniente. Esta
opcion genera un overhead mayor, porque el costo administrativo es mas importante,
pero los resultados son mejores, como se ve en la Figura 3.9.
Para el algoritmo con asignacion dinamica de loops se tiene la escalabilidad debil
que se observa en la Figura 3.10.
Capıtulo 4
Calculos de celda: esquema
multigrupo
“- Es de Dios de quien depende todo, - decıa la vieja Es-
tefanıa, para apaciguarlo. - Dios ve claro en ello. Hay que
someterse, mi pobre Diomka.
-Pero entonces, ¡mayor razon, si todo procede de Dios, si
Dios es el unico que ve claro! ¿Por que agobiar siempre a los
mismos? Preciso es que haya un poco de orden, ¿no?”
— Aleksandr Solzhenitsyn, Pabellon de cancerosos, 1968.
Este capıtulo se centra en el calculo de la distribucion espacial del flujo en el sistema
para todas las energıas. Se analiza en detalle la fuente de acople entre grupos, compuesta
por contribuciones de fision y scattering. La solucion de la ecuacion de transporte
monoenergetica en la formulacion de probabilidades de colision esta caracterizada por
los flujos de respuesta, cuyo calculo fue estudiado en el Capıtulo 3.
En primer lugar se presenta el esquema iterativo multigrupo, compuesto por itera-
ciones exteriores, interiores y termicas. Luego, se discute la paralelizacion del mismo,
analizando diversas estrategias, y las formas de combinarlas, para los metodos de pro-
babilidad de colision y HRM. Finalmente, se analiza la implementacion desarrollada
en CONDOR para el calculo multigrupo en HRM, ası como los resultados obtenidos.
4.1. Esquema iterativo del metodo multigrupo
Mediante el esquema multigrupo se acoplan los flujos resueltos a partir de la ecua-
cion de transporte monoenergetica, a traves de la fuente de fision y scattering de la
ecuacion 3.9. La fuente de fision tiene en principio contribuciones de todos los grupos,
ya que las fisiones se producen en todo el rango de energıas. La fuente de scattering, por
41
42 Calculos de celda: esquema multigrupo
otro lado, tiene una componente de down-scattering presente en todos los grupos, que
representa la moderacion de los neutrones, y una componente de up-scattering presente
solo en los grupos termicos, que tiene que ver con su termalizacion.
Es importante notar que la fuente de fision contiene el factor de multiplicacion,
que debe ser calculado en esta etapa. Ası, se define un problema de autovalores (k) y
autovectores (los flujos ϕ).
El metodo multigrupo se compone de iteraciones exteriores e interiores. Las itera-
ciones exteriores corresponden al barrido de todos los grupos en el sentido de perdida
de energıa de los neutrones, para resolver las distribuciones espaciales de flujo a par-
tir de la fuente de acople. Las interiores se llevan a cabo para resolver la ecuacion
monoenergetica dentro de cada grupo, de ser esto necesario.
En el metodo de probabilidades de colision no se tienen iteraciones interiores, ya que
los flujos se resuelven mediante la Ecuacion 3.12. Para el metodo HRM las iteraciones
interiores se dan sobre las corrientes, segun la Ecuacion 3.15. En caso de calcularse
los flujos mediante la Ecuacion 3.8, esto es sin utilizar flujos de respuesta, se tienen
iteraciones interiores costosas que deben ser llevadas a cabo en cada barrido de los
grupos. Mediante los flujos de respuesta se evitan estas iteraciones.
El proceso iterativo comienza suponiendo un perfil de flujo en el sistema (usualmente
uniforme) para cada grupo. Si se realizan calculos de quemado, esto solo es necesario
para el primero paso, ya para los siguientes se tienen los flujos del paso anterior como
aproximacion inicial.
Al comenzar cada iteracion exterior t, se evalua la fuente de fision en cada region
como
F(t)i =
1
k(t−1)
∑
g′
νΣf,i,g′ϕ(t−1)i,g′ , (4.1)
que queda fija durante la iteracion exterior. Para cada calculo monoenergetico, la fuente
de scattering esta dada por
S(t)i,g =
∑
g′<g
Σtrs,i,g′→gϕ
(t)i,g′ +
∑
g′>g
Σtrs,i,g′→gϕ
(t−1)i,g′ , (4.2)
donde se aprovecha el sentido de moderacion (perdida de energıa) de los neutrones,
utilizando los flujos actualizados de los grupos mas rapidos. La fuente de fision depende
del espectro de fision para el grupo g, y esta dada por
F(t)i,g = χgF
(t)i . (4.3)
A partir de estas fuentes se calcula la distribucion de flujo en cada grupo.
Si la distribucion inicial de flujo es tal que representa un neutron en todo el sistema,
la Ecuacion 4.1 garantiza que la fuente de fision para la iteracion t corresponde a un
4.1 Esquema iterativo del metodo multigrupo 43
neutron en la t − 1 (normalizacion). De esta forma, el factor de multiplicacion en la
iteracion t esta dado por
k(t) =∑
i
Vi
∑
g
νΣf,i,gϕ(t)i,g , (4.4)
dado que este se define como el cociente de la poblacion de neutrones de dos ge-
neraciones sucesivas, y en la generacion (t-1)-esima existe un neutron, debido a la
normalizacion.
Este proceso se repite hasta que los valores de k y ϕ convergen. Para esto, hay
que definir un error para los flujos y uno para el factor de multiplicacion, en general
utilizando una norma del residuo entre iteraciones. Conceptualmente, las iteraciones
exteriores corresponden al metodo iterativo de Gauss-Seidel, ya que la fuente de scat-
tering se actualiza a medida que se van calculando los flujos por grupo.
Ahora bien, el esquema planteado es eficiente para los grupos rapidos y epitermicos,
ya que al no haber up-scattering las iteraciones van en el sentido de la moderacion de los
neutrones, y la distribucion espacial de la fuente de fision converge en pocas iteraciones
exteriores. Sin embargo, para los grupos termicos, donde el up-scattering es importan-
te, se requiere un numero significativamente mayor de iteraciones para que los flujos
converjan, porque una parte de la fuente de scattering va en contra del sentido de las
iteraciones. Luego, implementando solo iteraciones exteriores se estarıa desperdiciando
tiempo de computo recalculando los flujos rapidos y epitermicos convergidos.
Una solucion mas economica consiste en realizar iteraciones adicionales solo para
los grupos donde el up-scattering es importante. Ası, por cada iteracion exterior se
efectua un cierto numero de iteraciones termicas, es decir sobre la fraccion de los
grupos que conforman el espectro termico. La tolerancia en el error en los flujos para
estas iteraciones en general es alta comparada con la de las exteriores, ya que no
tiene sentido converger los flujos termicos si los flujos rapidos varıan entre iteraciones
exteriores. Luego de cada iteracion termica se normalizan los flujos calculados a partir
del modo fundamental de rebalance (ver [2]).
En el caso particular del codigo CONDOR se implementan dos niveles de iteraciones
termicas. Para fijar los lımites de cada nivel, se compara la fuente de up-scattering con la
fuente total. El primer nivel se realiza para los grupos con mas del 1% de contribucion
de up-scattering. Los grupos para el segundo nivel son aquellos para los cuales esta
contribucion es superior al 10% en HRM y al 25% en probabilidades de colision.
Los aspectos fundamentales del esquema multigrupo se presentan en el Algoritmo
4.1 para el metodo HRM. Para evaluar la convergencia se definen los errores ϵk y ϵϕ para
k y ϕ, que son comparados con una tolerancia. Las iteraciones exteriores comienzan
desde g0 = 1, que es el grupo mas rapido. Para las termicas g0 sera el primer grupo
con up-scattering (en el caso de CONDOR segun los lımites mencionados para los
44 Calculos de celda: esquema multigrupo
Algoritmo 4.1 Esquema iterativo multigrupo para el metodo HRM.
while ϵk < ϵmaxk and ϵϕ < ϵmax
ϕ doif g0 = 1 then
ϕ(t−1)(1 : G) ⇒ F (t)(1 : G)end iffor g = g0 to G do
ϕ(t)(1 : g − 1), ϕ(t−1)(g + 1 : G) ⇒ S(t)(g)
F (t)(g), S(t)(g), E(g), T (g), H ⇒ J−(g)
F (t)(g), S(t)(g), J−(g), X(g), Y (g) ⇒ ϕ(t)(g)end forϕ(t) ⇒ k(t)
k(t−1), k(t), ϕ(t−1), ϕ(t) ⇒ g0, ϵk, ϵϕend while
dos niveles). Antes de realizar la iteracion exterior t se calcula la fuente de fision F (t),
mientras que la fuente de scattering S(t)(g) se calcula para cada grupo antes del calculo
monoenergetico, como ya se explico. A continuacion, se calculan las corrientes de acople
entre nodos de forma iterativa a partir de la Ecuacion 3.15 (iteraciones interiores) y
luego los flujos en cada grupo a partir de la 3.12. Para el metodo de probabilidades
de colision el algoritmo es el mismo, pero en este caso no se tiene la iteracion sobre
las corrientes, ya que el sistema no esta dividido en nodos. Por ultimo, se evaluan los
errores ϵk y ϵϕ y se determina g0 para la proxima iteracion.
4.2. Esquema multigrupo en paralelo
Se analizan tres formas en las que el calculo multigrupo puede ser paralelizado.
Por un lado, modificando la fuente de acople pueden calcularse los flujos en distintos
grupos en paralelo, tanto para las iteraciones exteriores como para las termicas. Por
otro lado, puede conservarse el esquema iterativo y realizar las operaciones matriciales
que componen cada calculo monoenergetico en paralelo.
Si bien el analisis de los algoritmos es valido tanto para el metodo de probabilida-
des de colision como para HRM, las implementaciones en CONDOR corresponden al
metodo HRM.
4.2.1. Paralelizacion por grupos de las iteraciones exteriores
Dado que los grupos estan acoplados solo por las fuentes, cada uno puede ser cal-
culado individualmente para una fuente dada. Luego, las iteraciones exteriores pueden
ser paralelizadas por grupos, aunque la fuente de acople debe ser modificada.
4.2 Esquema multigrupo en paralelo 45
4.2.1.1. Analisis del algoritmo
Si se calculan los grupos en paralelo para cada iteracion exterior, la fuente de fision
no cambia respecto del caso secuencial, ya que esta es evaluada antes de cada iteracion
exterior y no cambia durante la misma. La fuente de scattering a una dada energıa, por
el contrario, se evalua con los flujos actualizados en la nueva iteracion para energıas
mas altas. En consecuencia, si se quieren calcular los grupos en paralelo la fuente de
scattering necesariamente va a tener que diferir respecto del esquema secuencial, ya que
cuando se va a calcular un grupo, los flujos de los grupos mas rapidos que este pueden
no estar calculados, en cuyo caso deben usarse los flujos de la iteracion anterior.
Teniendo en cuenta que el sentido fısico de las iteraciones exteriores (la moderacion)
es inherentemente secuencial, es de esperar que al pasar a un esquema en paralelo se
tenga una penalizacion significativa en la cantidad de iteraciones exteriores necesarias
para alcanzar la convergencia. Para que este aumento no sea excesivo, es conveniente
realizar la paralelizacion de forma tal de acercarse lo mas posible a la fuente de scat-
tering del calculo en serie. Por otro lado, si las iteraciones exteriores en paralelo son
factibles, es de esperar que las termicas tambien lo sean, porque su acople en direccion
contraria a la de moderacion es mayor.
Si se utilizan menos procesadores que grupos, se debera establecer un criterio para
asignar determinados grupos a cada procesador. En este caso, para los grupos que se
calculan en un mismo procesador sı se puede ir actualizando la fuente de scattering a
medida que se calculan los flujos, ya que se puede asegurar el orden en el que estos
son calculados. Conceptualmente, el esquema de Gauss-Seidel que se tiene en el caso
secuencial tiende al metodo de Jacobi al agregar procesadores. Para este algoritmo se
asume que no existe intercambio de informacion entre los procesadores.
Sin embargo, una vez que un procesador calcula los flujos para un grupo, estos
pueden ser utilizados por cualquier otro para calcular las fuentes de scattering en
otros grupos. De esta forma se requiere sincronizacion y mas intercambio de datos
entre procesos, lo que genera mas overhead, pero es esperable que se necesiten menos
iteraciones exteriores, es decir menos tiempo de calculo. Una implementacion de este
metodo en OpenMP se muestra en el Algoritmo 4.2.
El tipo de iteraciones que son paralelizadas esta dado por gp. En este caso se
tendra gp = 1, con lo cual seran realizadas en paralelo tanto las iteraciones exteriores
como las termicas de ambos niveles, con paralelismo de loop. Para calcular la fuente
de scattering de cada grupo g se utilizan los flujos de otros grupos g′ que hayan sido
actualizados por cualquier procesador, o los flujos de la iteracion anterior. Esta eleccion
depende del valor de flags(g′), que es leıdo atomicamente de DRAM. El conjunto de
flujos utilizados para calcular esta fuente esta representado por el puntero ϕpointer, que
es privado a cada thread.
46 Calculos de celda: esquema multigrupo
Algoritmo 4.2 Paralelizacion de las iteraciones exteriores y termicas del esquemamultigrupo en HRM.
while ϵk < ϵmaxk and ϵϕ < ϵmax
ϕ doif g0 = 1 then
ϕ(t−1)(1 : G) ⇒ F (t)(1 : G)end if!$OMP parallel if(g0 ≥ gp) shared(ϕ
(t−1), ϕ(t), f lags, ...) private(flag, ϕpointer, ...)!$OMP do schedule(...)for g = g0 to G do
!$OMP flush(flags)for g′ = 1 to G do
!$OMP atomic readflag = flags(g′)if flag = true then
ϕpointer(g′) → ϕ(t)(g′)
elseϕpointer(g
′) → ϕ(t−1)(g′)end if
end for!$OMP flush(ϕ(t))
ϕpointer ⇒ S(t)(g)
F (t)(g), S(t)(g), E(g), T (g), H ⇒ J−(g)
F (t)(g), S(t)(g), J−(g), X(g), Y (g) ⇒ ϕ(t)(g)
!$OMP flush(ϕ(t))!$OMP atomic writeflags(g) = true!$OMP flush(flags)
end for!$OMP end do!$OMP end parallelϕ(t) ⇒ k(t)
k(t−1), k(t), ϕ(t−1), ϕ(t) ⇒ g0, ϵk, ϵϕend while
Una vez que el flujo para un grupo es calculado, se utiliza la directiva flush para
que estos sean visibles por resto de los threads. Por ultimo, se actualiza atomicamente
la variable flags para comunicar al equipo de threads que los flujos de la iteracion t
estan disponibles para ese grupo.
En cuanto a la eficiencia de cada iteracion exterior, si se tiene un numero de proce-
sadores y un numero de grupos tal que se pueden distribuir igual cantidad de grupos
para cada procesador la aceleracion serıa optima. Sin embargo, en general este no es el
caso, con lo cual se podrıa perder mucha eficiencia si una fraccion de los procesadores
reciben menos grupos.
Por ultimo, en el lımite de usar un procesador por grupo es posible que las iteracio-
nes termicas ya no sean necesarias, porque al no aprovechar el sentido de moderacion
4.2 Esquema multigrupo en paralelo 47
de los neutrones es probable que todos los flujos requieran un numero similar de itera-
ciones para converger.
4.2.1.2. Resultados en CONDOR
Para la paralelizacion por grupos de las iteraciones exteriores en el codigo CONDOR
se consideraron cuatro opciones diferentes. Por un lado, se implemento el calculo en
paralelo de bloques de grupos contiguos en energıa, aprovechando la moderacion de
los neutrones en cada procesador. Por otro lado, se utilizo un calculo en paralelo por
grupos en una distribucion cıclica tipo Round-Robin (similar a la forma en la que
se reparte la baraja en un juego de cartas), sin seguir el slowing-down. Ambos casos
fueron implementados con y sin comunicacion entre procesadores, es decir utilizando
en el calculo de la fuente de scattering los flujos actualizados por cualquier procesador
o solo por un mismo procesador. En este caso las iteraciones termicas tambien son
realizadas en paralelo.
Para analizar el desempeno de estas cuatro opciones se considero el calculo de celda
de un elemento combustible estandar de un reactor MTR de placas paralelas generico.
Se obtuvo el numero total de iteraciones (exteriores y termicas) necesarias para alcanzar
la convergencia, en funcion del numero de procesadores utilizados.
Como puede verse en la Figura 4.1, el numero de iteraciones aumenta abruptamente
al paralelizar las iteraciones exteriores. En todos los casos se tiene una velocidad de
convergencia de menos del 25% del calculo secuencial a partir de 3 o 4 procesadores.
Para el caso lımite en el que se calculan todas las fuentes de scattering con flujos sin
actualizar la velocidad de convergencia disminuye al 16%.
Para igualar el tiempo de calculo del esquema secuencial se necesitan aproxima-
damente 8 procesadores, como se ve en la Figura 4.2. A partir de ese punto se tiene
speedup mayor que la unidad, pero la eficiencia de la paralelizacion es muy pobre.
Por otro lado, se realizaron pruebas sin iteraciones termicas, es decir con cada
iteracion sobre la totalidad de los grupos. El numero de iteraciones en este caso fue
del mismo orden que en las implementaciones anteriores. Luego, teniendo en cuenta
que las iteraciones exteriores son mas costosas que las termicas, se concluyo que este
metodo no es conveniente.
A partir de estos resultados, se determino que la paralelizacion de las iteraciones
exteriores no es factible. Esto se debe a que acelerando cada iteracion exterior en ningun
caso se pudo compensar el aumento del numero total de iteraciones.
4.2.2. Paralelizacion por grupos de las iteraciones termicas
Teniendo en cuenta que calcular los grupos en paralelo en las iteraciones exteriores
lleva a una perdida de velocidad de convergencia que vuelve inviable al algoritmo, se
48 Calculos de celda: esquema multigrupo
2 4 6 8 10 12
Número de procesadores
0
20
40
60
80
100
120
140It
era
ciones
tota
les
Round-Robin, sin sincronizaciónEn bloques, sin sincronizaciónRound-Robin, con sincronizaciónEn bloques, con sincronización
Figura 4.1: Numero de iteraciones totales hasta la convergencia en funcion del numero deprocesadores para las cuatro implementaciones de la paralelizacion por grupos de las iteracionesexteriores.
2 4 6 8 10 12
Número de procesadores
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
Speedup
Round-Robin, sin sincronizaciónEn bloques, sin sincronizaciónRound-Robin, con sincronizaciónEn bloques, con sincronización
Figura 4.2: Speedup obtenido para el metodo multigrupo paralelizando las iteraciones exterio-res.
4.2 Esquema multigrupo en paralelo 49
pueden paralelizar solo las iteraciones termicas, en las cuales el acople de up-scattering
es mayor.
4.2.2.1. Analisis del algoritmo
En el caso de las iteraciones termicas la fuente de up-scattering es igual o mas
importante que la de fision, ya que no se tiene moderacion, si no que se conforma el
espectro termico de los neutrones. Esto hace que las razones fısicas para realizar las
iteraciones en el sentido de moderacion sean menos evidentes. Entonces, es de esperar
que al modificar la fuente de scattering paralelizando por grupo el aumento del numero
de iteraciones sea menor que en el caso anterior.
En consecuencia, dado que la opcion anterior resulta poco eficiente y hasta contra-
producente, se puede optar por realizar en paralelo solo las iteraciones termicas. En
CONDOR ademas se tiene la opcion de paralelizar las iteraciones con 1% y 10% de
up-scattering, o solo las de 10%, en las cuales el acople termico es mayor.
La implementacion de este metodo es esencialmente igual a la paralelizacion de las
iteraciones exteriores (Algoritmo 4.2). Sin embargo, en este caso se tendra solo una
parte del numero total de grupos, ya que el valor de gp sera el grupo de corte para las
iteraciones termicas del nivel establecido para paralelizar.
Por otro lado, hay que tener en cuenta que las iteraciones termicas constituyen una
fraccion de las iteraciones totales (externas y termicas). Luego, de esta forma se parale-
liza solo una porcion del algoritmo, con lo cual segun la ley de Amdahl la eficiencia de
la paralelizacion puede saturar con pocos procesadores, generando un speedup limitado.
Como consecuencia, puede ser necesario que esta opcion sea combinada con algun otro
metodo de paralelizacion alternativo, para generar un algoritmo con mayor porcion en
paralelo.
Este aspecto depende del tipo de reactor que se calcule. En reactores MTR o PWR,
por ejemplo, la fraccion optima de iteraciones termicas es menor que para reactores
PHWR, en los cuales el acople termico es mas fuerte. En este ultimo caso, esta forma
de paralelizar puede alcanzar para tener un algoritmo con una fraccion en paralelo
suficientemente alta para ofrecer una buena escalabilidad, sin necesidad de combinarse
con otro metodo. En un reactor rapido, por el contrario, las iteraciones termicas no
tienen sentido, con lo cual este metodo es inaplicable.
4.2.2.2. Resultados en CONDOR
Se implemento la paralelizacion por grupo en los dos niveles de iteraciones termi-
cas. Para el primer nivel (1%) tambien se realizan las iteraciones del segundo nivel
(10%) en paralelo. En ambos casos se utilizo el calculo de la fuente de scattering con
sincronizacion.
50 Calculos de celda: esquema multigrupo
2 4 6 8 10 12
Número de procesadores
16
18
20
22
24
26
28
30
Itera
ciones
tota
les
Niveles 1% y 10%Nivel 10%
Figura 4.3: Iteraciones totales (exteriores y termicas) hasta la convergencia en funcion delnumero de procesadores para la paralelizacion de los dos niveles de iteraciones termicas delesquema multigrupo de CONDOR.
2 4 6 8 10 12
Número de procesadores
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
1,8
2
Speedup
Niveles 1% y 10%Nivel 10%
Figura 4.4: Speedup para la paralelizacion de las iteraciones termicas en el metodo multigrupo.
Para evaluar cada algoritmo se utilizo el mismo calculo de MTR que para las itera-
ciones exteriores. El numero de iteraciones hasta la convergencia en funcion del numero
de grupos se muestra en la Figura 4.3. En ambos casos el hecho de calcular la fuente
de scattering con algunos flujos sin actualizar no genera un impacto significativo sobre
el numero de iteraciones. Como consecuencia, la paralelizacion del algoritmo de esta
forma en principio es factible para los dos niveles.
Sin embargo, paralelizando ambos niveles de iteraciones termicas en este ejemplo
se obtiene aproximadamente un 60% del calculo en paralelo, mientras que si solo se
realizan en paralelo las iteraciones del segundo nivel la fraccion en paralelo es del 20%.
Como consecuencia, el speedup obtenido en el primer caso es mayor que en el segundo,
como puede verse en la Figura 4.4. Entonces, es mas conveniente optar por el primer
metodo.
Al aumentar el tamano del sistema la porcion del codigo ejecutada en paralelo no
4.2 Esquema multigrupo en paralelo 51
2 4 6 8 10 12
Número de procesadores
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
1,8
2
2,2
Speedup
N = 312N = 1824N = 3600
Figura 4.5: Escalabilidad para la paralelizacion de las iteraciones termicas.
cambia, porque esta depende de la fraccion de las iteraciones totales que se hace sobre
los grupos termicos. Luego, este algoritmo no posee escalabilidad debil, es decir que la
escalabilidad no depende del tamano del sistema, como se muestra en la Figura 4.5.
Es importante notar que los resultados obtenidos con este esquema de calculo di-
fieren de los del metodo original, ya que los calculos monoenergeticos se realizan con
fuentes diferentes. Mas aun, la ejecucion no es determinista, y los valores obtenidos
varıan entre corridas. Conceptualmente el algoritmo posee race conditions, porque la
velocidad relativa de los procesadores modifica el resultado del programa. Sin embargo,
el acceso a los datos, en particular a los flujos ϕ(t)(g) esta protegido y sincronizado,
con lo cual no hay posibilidad de que esta condicion genere corrupcion de datos o re-
sultados erroneos. El factor de multiplicacion y los flujos calculados coinciden con los
del metodo original dentro de los errores de convergencia.
4.2.3. Paralelizacion de las operaciones matriciales
La paralelizacion de las iteraciones termicas es conveniente y genera un speedup
apreciable. Sin embargo, la fraccion del algoritmo que se ejecuta en paralelo es baja,
ya que las iteraciones exteriores se realizan secuencialmente. Un enfoque alternativo
consiste en paralelizar las operaciones necesarias para resolver los flujos en cada grupo
y los calculos asociados al esquema iterativo.
4.2.3.1. Analisis del algoritmo
Para calcular los flujos en el sistema para un dado grupo de energıa se utiliza la
Ecuacion 3.12, si el calculo se realiza mediante el metodo de probabilidades de colision,
o se itera sobre la Ecuacion 3.15 para las corrientes, si se utiliza HRM, para despues
utilizar la 3.12. Entonces, se tienen sumas y productos de matrices que pueden ser
52 Calculos de celda: esquema multigrupo
realizados en paralelo. Ademas, la evaluacion de la fuente de fision y la normalizacion
de los flujos, entre otros calculos, pueden ser paralelizados.
Utilizando paralelismo de loop, por ejemplo, basta con calcular distintas partes de
las matrices por separado, distribuyendo las iteraciones sobre sus elementos en distintos
procesadores. Las fuentes de fision y scattering, al igual que las contribuciones al factor
de multiplicacion de diferentes regiones, tambien pueden ser calculadas en paralelo,
simplemente en funcion del ındice i de las ecuaciones 4.1, 4.2 y 4.4.
Esta opcion ofrece varias ventajas respecto de las anteriores. En primer lugar, da-
do un numero de procesadores es facil balancear las cargas sobre cada uno, ya que
no aparecen operaciones de duraciones difıciles de predecir, como en otros casos. En
segundo lugar, la forma de las iteraciones exteriores en principio no se modifica, con lo
cual se mantiene el sentido del slowing-down en el calculo de los grupos, y el numero
de iteraciones exteriores no aumenta.
Sin embargo, la granularidad de este algoritmo es fina, lo que puede generar perdidas
de eficiencia por manejo de memoria, en particular por false sharing. Ademas, el calculo
de los flujos para cada grupo esta compuesto por una serie de operaciones poco costosas
(calculo de fuente de scattering, de corrientes, de flujos, etc...) entre las cuales se necesita
sincronizacion entre procesos. Luego, el overhead de la paralelizacion puede ser muy
significativo.
Finalmente, este metodo tiene escalabilidad debil con el tamano del sistema, ya que
al aumentar el numero de mallas aumenta la relacion computo-sincronizacion para los
procesos, lo que mejora la eficiencia.
4.2.3.2. Resultados en CONDOR
Se implemento la paralelizacion de las operaciones matriciales y demas calculos
asociados a la evaluacion de los flujos. Para todas las subrutinas se utilizo paralelismo
de loop y sincronizacion sencilla mediante directivas de OpenMP.
Para evaluar el desempeno de esta opcion se la utilizo en primer lugar sin combinarla
con la paralelizacion de las iteraciones termicas. Para el mismo problema mostrado en
la Figura 4.5, se obtuvo el speedup mostrado en la 4.6.
El algoritmo implementado esta fuertemente limitado por el manejo de memoria,
con lo cual al agregar procesadores eventualmente el overhead aumenta significativa-
mente. Como se ve en la Figura 4.6, el speedup obtenido alcanza un maximo y luego
decae, alcanzando valores menores que la unidad.
Como consecuencia, este algoritmo es factible, pero debe limitarse la cantidad de
procesadores. Idealmente, debe utilizarse el numero optimo de procesadores, es decir
el que lleva al maximo speedup. Sin embargo, este optimo depende del problema, con
lo cual debe ser calculado en tiempo de ejecucion. Para esto debe desarrollarse algun
4.3 Discusion del algoritmo paralelo optimo 53
1 2 3 4 5 6 7 8
Número de procesadores
0
0,5
1
1,5
2
Speedup
N = 312N = 1824N = 3600
Figura 4.6: Speedup obtenido paralelizando los calculos de transporte y de fuentes.
criterio, que no necesariamente es facil de definir.
4.3. Discusion del algoritmo paralelo optimo
Los resultados obtenidos para la paralelizacion de las iteraciones termicas y de los
calculos dentro de cada grupo son positivos, pero ambos metodos poseen limitaciones
importantes. El primero no posee un overhead importante, pero la fraccion paraleli-
zada es pequena, y por lo tanto el speedup alcanza rapidamente un valor constante.
El segundo metodo es mas eficiente que el primero para pocos procesadores, pero el
overhead asociado al manejo de memoria hace que al aumentar el numero de nucleos
la eficiencia disminuya significativamente.
Entonces, el algoritmo optimo puede resultar de una combinacion de ambos enfo-
ques, que permita aprovechar los recursos disponibles de la mejor manera. Con este
fin, se consideraron dos algoritmos diferentes.
En primer lugar, se implemento un algoritmo con dos niveles de paralelismo. Por
un lado se utiliza la paralelizacion de las operaciones matriciales en todos los calculos
de transporte, tanto para las iteraciones exteriores como para las termicas. Para evitar
la perdida de eficiencia por manejo de memoria, el numero maximo de procesadores
utilizados en este nivel se determina a partir de un ajuste lineal del numero optimo
en funcion de la cantidad de regiones (este criterio es, por supuesto, discutible). Con
los procesadores sobrantes se paralelizan las iteraciones termicas, en el segundo nivel
de paralelismo. Ası, los dos niveles se encuentran anidados, es decir que las iteraciones
termicas se realizan en paralelo y dentro de cada grupo se calculan los flujos tambien
en paralelo.
Como ejemplo, se puede considerar un problema en el que el numero optimo de
procesadores para las operaciones matriciales es 4. Si se cuenta con 8 procesadores, los
54 Calculos de celda: esquema multigrupo
2 4 6 8 10 12
Número de procesadores
0
0,5
1
1,5
2
2,5
Speedup
Paralelismo anidadoNiveles separados
Figura 4.7: Speedup para los dos algoritmos finales para el metodo multigrupo
grupos para las iteraciones termicas se dividen en dos paquetes, que son calculados en
paralelo. Para los calculos asociados a cada grupo se utilizan 4 procesadores. Entonces,
las iteraciones termicas se realizan con 8 procesadores en total, y las exteriores con 4,
solo para paralelizar las operaciones matriciales.
El segundo algoritmo consiste en paralelizar las operaciones matriciales solo para
las iteraciones exteriores, y realizar las iteraciones termicas en paralelo por grupos. De
esta forma, se combinan los dos niveles del algoritmo anterior, pero no anidados. Este
metodo mejora la paralelizacion de las iteraciones termicas agregando paralelismo en
las iteraciones exteriores. Como consecuencia, aumenta la fraccion en paralelo, y por
lo tanto el speedup maximo.
Para comparar los dos algoritmos planteados se calculo el mismo elemento com-
bustible MTR que para las pruebas anteriores. Como se muestra en la Figura 4.7, el
speedup obtenido con el segundo metodo es mayor que con el primero. Ademas, la
aceleracion maxima alcanzada es mayor que con los algoritmos de paralelizacion de las
iteraciones termicas y de las operaciones matriciales por separado.
Teniendo en cuenta estos resultados, se concluyo que el metodo optimo para para-
lelizar el esquema multigrupo es el segundo.
Capıtulo 5
Calculos de celda: quemado
“That is the greatest fallacy, the wisdom of old men. They
do not grow wise. They grow careful.”
— Ernest Hemingway, A Farewell to Arms, 1929.
Un objetivo fundamental de los calculos de celda es evaluar la evolucion de la
composicion de los distintos materiales del nucleo en funcion del tiempo de operacion
del reactor. Esta es la funcion de los calculos de quemado, cuya paralelizacion es el
tema del presente capıtulo.
En primer lugar se definen las cadenas de quemado y se explica su resolucion numeri-
ca. A continuacion, se analizan algoritmos para paralelizar tanto el calculo de las cade-
nas como el de los ritmos de reaccion necesarios. Finalmente se presentan los resultados
de la implementacion en CONDOR.
5.1. Cadenas de quemado
Durante la operacion de un reactor nuclear se producen permanentes cambios en
la composicion de sus combustibles, y en general en la de cualquier material que se
encuentre en el nucleo e interactue con los neutrones. Por un lado, la fision y captura
radiativa de los materiales combustibles hace que sus densidades disminuyan con el
tiempo, y la absorcion de neutrones en isotopos fertiles puede generar nuevos isotopos
fısiles, lo que determina el balance de combustible del nucleo. Por otro lado, se gene-
ran constantemente productos de fision, algunos de los cuales son absorbentes fuertes
o pueden decaer en isotopos que lo sean, afectando la reactividad del nucleo. Final-
mente, la evolucion de absorbentes neutronicos de control, como venenos quemables y
elementos de control, es fundamental en el diseno de la estrategia de recambio y de
control de reactividad.
Para describir la evolucion de los distintos materiales de interes en el reactor se
55
56 Calculos de celda: quemado
Figura 5.1: Cadenas de quemado tıpicas de metales pesados (Fuente: [2]).
Figura 5.2: Cadenas de quemado para productos de fision (Fuente: [2]).
tienen cadenas de quemado, que representan la produccion y la desaparicion de isotopos
por diversas vıas. La Figura 5.1 muestra dos cadenas tıpicas para material combustible,
correspondientes a captura radiativa en 235U y a absorcion y breeding en 238U, y la
5.2 para algunos productos de fision. Como puede verse, las cadenas pueden consistir
simplemente en uno o dos isotopos, o pueden tener decenas de elementos y varias
ramificaciones. Las reacciones de interes son las de fision (flechas inclinadas), captura
neutronica (horizontales) y decaimiento β− (verticales).
Segun [2], la evolucion de la densidad numerica N del isotopo i dentro de una
cadena de quemado, en funcion del tiempo t en el reactor, esta dada por la ecuacion
de balance
dNi(t)
ϕdt= Yi(t) + σ∗
i−1Ni−1(t) + λkNk(t)− (σi + λi)Ni(t) , (5.1)
si σ∗ y σ son respectivamente las secciones eficaces de captura y de absorcion, y λ = λϕ,
siendo λ la constante de decaimiento. El yield acumulativo de fision Y por unidad de
flujo esta dado por
Yi(t) =
nfis∑
j=1
yj→iσf,jNj(t) , (5.2)
donde nfis es el numero de isotopos fısiles j, yj→i es el yield de fision de cada uno de
ellos para el isotopo i y σf,j es su seccion eficaz de fision. De esta forma, se define un
sistema de ecuaciones lineales con tantas ecuaciones como isotopos existan.
Ahora bien, las secciones eficaces que aparecen en las ecuaciones 5.1 y 5.2 deben
ser condensadas con el espectro crıtico de fuga. Este espectro se calcula en general
mediante el metodo B1 o el de difusion, a partir del sistema homogeneizado con los
5.1 Cadenas de quemado 57
flujos de medio infinito, y a menos grupos que el calculo de celda. Los detalles de esta
etapa se presentan en [2] y en [5] para el codigo CONDOR.
Cada paso de quemado es calculado con un espectro energetico y una distribucion
espacial de flujo independiente del tiempo. Sin embargo, estos varıan con el quemado,
con lo cual se debe debe utilizar alguna aproximacion para suponerlos constantes. En
primer lugar, es posible utilizar el flujo inicial y realizar el paso de quemado con su
espectro y perfil espacial, en lo que se denomina metodo directo. En segundo lugar,
puede utilizarse el metodo predictor-corrector, descripto en [2]. Este metodo consiste
en realizar cada paso de quemado una primera vez para calcular el nuevo flujo (paso
predictor), y luego corregir el espectro para recalcular la evolucion de las densidades
numericas (paso corrector).
Por otro lado, el nivel de flujo ϕ de la Ecuacion 5.1 corresponde a la potencia a la que
opera el reactor. Sin embargo, al evolucionar el quemado del combustible, la seccion
eficaz total de fision varıa y la potencia se mantiene constante. Luego, teniendo en
cuenta que P ∝ Σfϕ, el valor de ϕ depende del tiempo. Para obtener el flujo promedio
entre dos pasos de quemado que genera la energıa de fision especificada en ese intervalo
de tiempo se tiene un proceso iterativo. Cada iteracion consiste en quemar las cadenas
de metal pesado para obtener la energıa liberada, dependiente de los ritmos de fision,
y corregir los ritmos de reaccion a partir de la diferencia entre la energıa producida
y la requerida. Una vez que el nivel de flujo promedio converge, se queman todas las
cadenas con este valor.
5.1.1. Resolucion numerica
La evaluacion de las cadenas de quemado se compone fundamentalmente de dos
etapas. En primer lugar deben calcularse los ritmos de reaccion neutronicos, ya que
los cambios en los materiales del reactor son producidos por su interaccion con los
neutrones. Por un lado se necesitan los ritmos de absorcion y fision en el material
fısil, para evaluar la desaparicion de combustible, el breeding de isotopos fısiles y la
aparicion de productos de fision. Por otro lado deben calcularse los ritmos de absorcion
en venenos absorbentes.
Estos ritmos de reaccion son utilizados en la segunda etapa, que comienza con la
evaluacion de los coeficientes de perdidas y de produccion de la ecuacion 5.1. Finalmente
se obtienen las variaciones en las densidades numericas de los isotopos de interes a partir
de la resolucion de las cadenas de quemado.
Para resolver las cadenas dadas por la ecuacion 5.1 para cada isotopo se puede re-
currir a metodos iterativos. Sin embargo, dado que se trata de un sistema de ecuaciones
lineales con poco acople, suele ser mas eficiente resolver el sistema de forma exacta. La
resolucion mediante el metodo de transformadas de Laplace, que es el utilizado en el
58 Calculos de celda: quemado
Figura 5.3: Ejemplo de una cadena generica linealizada (Fuente: [2]).
codigo CONDOR, se explica en [2].
Para utilizar el metodo de Laplace primero se deben linealizar las cadenas, de la
forma que se muestra en la Figura 5.3. En este ejemplo, la produccion del isotopo A a
partir del B se calcula una sola vez, y las contribuciones de B y C a E se suman.
5.2. Calculo de ritmos de reaccion en paralelo
En un codigo de celda, y en particular en CONDOR, se definen distintos materiales
que componen al sistema (combustible, vaina, moderador o zonas con venenos quema-
bles, por ejemplo). Cada material esta compuesto por un cierto numero de isotopos,
que pueden estar presentes en la celda original o aparecer al quemarse el combustible.
Luego, los ritmos de reaccion de captura neutronica y de fision deben ser calculados
para todos los isotopos de cada material.
Por otro lado, los ritmos de reaccion tienen contribuciones de todos los grupos de
energıa. Estas contribuciones se evaluan a partir del espectro crıtico y de las secciones
eficaces condensadas segun este espectro.
La paralelizacion de estos calculos puede ser realizada de tres formas distintas: por
grupo, por isotopo o por material.
Calcular las contribuciones de cada grupo en paralelo tiene varias desventajas. Por
un lado, en algun momento es necesario sumar todas las contribuciones para obtener
los ritmos de reaccion totales, para cada isotopo y cada material. En consecuencia,
se necesita sincronizacion entre los procesadores para evitar data races, lo cual genera
un overhead que en las otras opciones no se tiene, como se explica a continuacion.
Por otro lado, a menos que se implemente un metodo con sincronizacion excesiva, el
requerimiento de memoria se multiplica por el numero de procesadores, ya que los
ritmos de reaccion parciales deben ser privados a cada proceso. Ademas, esta opcion
no es optima en cuanto a los accesos a la memoria, ya que todos los procesadores
acceden a las mismas direcciones, con lo cual existen overheads asociados al manejo de
memoria. En consecuencia, este metodo fue descartado.
Como segunda opcion, se puede paralelizar el calculo de ritmos de reaccion por
isotopo. De esta forma se obtiene un algoritmo de granularidad fina, lo que ofrece ven-
tajas en cuanto al balance de cargas. Sin embargo, el calculo de los ritmos de reaccion
para un isotopo es poco costoso, con lo cual la relacion computo-administracion es
baja. Ademas, los ritmos para los distintos isotopos suelen estar guardados en direc-
5.3 Resolucion de las cadenas de quemado en paralelo 59
ciones de memoria cercanas; este es el caso de CONDOR. Luego, el acceso de distintos
procesadores a ritmos de reaccion de isotopos cercanos en memoria puede conducir a
perdidas de eficiencia por false sharing, ya que la frecuencia de estos accesos es muy
alta. Por estas razones tampoco se considero factible a esta opcion.
Por ultimo, los ritmos de reaccion para los distintos materiales pueden ser calcula-
dos en paralelo. El algoritmo resultante tiene granularidad mas gruesa que el anterior,
entonces la relacion computo-administracion es mayor. Ademas, en CONDOR los isoto-
pos para cada material son almacenados en direcciones contiguas, con lo cual la perdida
de eficiencia por false sharing es menor. En cuanto a la memoria necesaria, este metodo
conserva el requerimiento del calculo secuencial, ya que no se necesitan copias auxiliares
de los ritmos de reaccion, porque cada ritmo es calculado en un procesador diferente.
Debido a estas ventajas, este fue el algoritmo implementado en CONDOR.
5.3. Resolucion de las cadenas de quemado en pa-
ralelo
Teniendo en cuenta que cada cadena linealizada puede ser resuelta individualmente,
se puede paralelizar el algoritmo mapeando las cadenas a distintos procesadores. Otra
opcion consiste en calcular todas las cadenas necesarias para cada material en paralelo,
ya que el quemado de cada material tampoco depende del resto.
La primera opcion presenta dos desventajas fundamentales. Primero, existen de-
pendencias entre las cadenas lineales provenientes de la misma cadena original, debido
a que los caminos comunes a varias cadenas (A → B en la Figura 5.3) son calculados
una sola vez. Esto puede solucionarse de dos formas, ninguna de las cuales es optima.
Por un lado, pueden calcularse los caminos comunes tantas veces como cadenas deri-
vadas existan, independizando las cadenas pero aumentando levemente el tiempo de
calculo. Por otro lado, se puede utilizar sincronizacion para que varios procesadores
puedan utilizar un camino comun que ya haya sido calculado, aunque de esta forma se
generan overheads y tiempo ocioso que no son convenientes, y la implementacion no es
trivial.
La segunda desventaja de la paralelizacion por cadenas proviene de la suma de
contribuciones de varias cadenas al mismo isotopo. Esto tambien requiere sincronizacion
entre procesos para evitar data races. Ademas, el acceso de distintos procesadores
a los mismos isotopos, o a isotopos cercanos en una cadena, genera overheads por
administracion de memoria y probablemente por false sharing.
En consecuencia, de descarto la paralelizacion por cadenas y se opto por la parale-
lizacion por materiales. Esta opcion genera un algoritmo de granularidad mas gruesa,
mejorando la relacion computo-administracion, y sin sincronizacion, ya que cada ma-
60 Calculos de celda: quemado
1 2 3 4 5 6 7 8
Número de procesadores
0
0,5
1
1,5
2
2,5
3
Speedup
M = 50M = 200M = 450
Figura 5.4: Speedup para la paralelizacion del calculo de ritmos de reaccion.
terial es totalmente independiente del resto. Ademas, los isotopos calculados en cada
material se encuentran contiguos en memoria, con lo cual la perdida de eficiencia por
false sharing deberıa ser despreciable.
Sin embargo, se tiene que calcular la energıa total generada por fision en el paso de
quemado para obtener iterativamente el flujo promedio ϕ. Para ello, cada procesador
evalua la energıa generada en los materiales calculados localmente, y la unica inter-
accion entre procesos en este algoritmo consiste en sumar todas las contribuciones a
la energıa total. La sincronizacion para realizar esta reduccion es sencilla, pero fuerza
a los threads a esperar a que todas las contribuciones hayan sido calculadas, lo que
aumenta su tiempo ocioso.
5.4. Resultados numericos en CONDOR
Para la paralelizacion por materiales del calculo de los ritmos de reaccion se ob-
tuvieron los resultados que se muestran en la Figura 5.4, donde M es el numero de
materiales del problema. Como era esperable, la escalabilidad aumenta con la cantidad
de materiales del sistema. Sin embargo, el speedup alcanza un maximo y luego decae,
probablemente debido al manejo de memoria asociado a las variables compartidas (las
matrices de ritmos de reaccion).
En cuanto a las cadenas de quemado, el speedup obtenido con la paralelizacion por
materiales puede verse en la Figura 5.5. En este caso tambien existe una tendencia al
aumento de la escalabilidad con el numero de materiales, aunque no es tan evidente.
Ademas, el speedup satura con pocos procesadores, debido a que la fraccion paralela del
algoritmo es relativamente baja. Esto se debe a que el proceso iterativo para obtener el
nivel de flujo promedio fuerza la sincronizacion de los threads, ya que se debe evaluar
para cada iteracion la energıa de fision liberada.
5.4 Resultados numericos en CONDOR 61
1 2 3 4 5 6 7 8
Número de procesadores
0,8
1
1,2
1,4
1,6
1,8
2
2,2
Speedup
M = 50M = 200M = 450
Figura 5.5: Resultados para la resolucion de las cadenas de quemado en paralelo.
1 2 3 4 5 6 7 8
Número de procesadores
0,6
0,8
1
1,2
1,4
1,6
1,8
2
2,2
Speedup
M = 50M = 200M = 450
Figura 5.6: Resultados para los calculos de quemado en paralelo.
Para el calculo de quemado completo, compuesto por la evaluacion de los ritmos de
reaccion y de las cadenas de quemado, se tiene el speedup presentado en la Figura 5.6.
El tiempo de calculo de las dos etapas en general es similar, y por lo tanto el resultado
global esta determinado por las dos partes por igual.
Capıtulo 6
Metodo de difusion
“And now that you don’t have to be perfect, you can be good.”
— John Steinbeck, East of Eden, 1952.
Tanto el metodo de probabilidades de colision analizado en este trabajo como otros
metodos utilizados para realizar calculos de celda, como Sn o MOC, se basan en un
tratamiento detallado de la distribucion espacial del flujo. Estos metodos utilizan apro-
ximaciones relativamente precisas de la ecuacion de transporte, en particular sobre la
variable angular. Como consecuencia, la resolucion de problemas a partir de ellos es
muy intensiva computacionalmente.
En un gran numero de aplicaciones es necesario un enfoque mas crudo y menos
costoso para aproximar la ecuacion de transporte, ya sea porque el sistema a calcular
es demasiado grande, o porque no se necesita una descripcion espacial detallada. Este
es el caso de los calculos de gestion de nucleo, los estudios parametricos de nucleo en
la etapa de diseno y los analisis de seguridad, por ejemplo. En estos casos, el metodo
mas utilizado es la aproximacion de difusion.
En este capıtulo se considera el metodo de difusion en su formulacion en diferencias
finitas. Se estudian diversas formas en las cuales este metodo puede ser paralelizado,
utilizando esquemas de Jacobi y de Gauss-Seidel. Por ultimo, se muestran los resultados
obtenidos en la implementacion de los algoritmos propuestos en el programa CITVAP,
basado en el codigo CITATION 2.0.
6.1. Teorıa de difusion
A continuacion se presentan las ecuaciones del metodo de difusion, primero en su
forma multigrupo y luego en la aproximacion de diferencias finitas. Luego se describen
los esquemas numericos utilizados para resolver esta forma de la ecuacion de difusion,
ası como los metodos de aceleracion mas comunes.
63
64 Metodo de difusion
6.1.1. Ecuaciones multigrupo
Una formulacion usual de la ecuacion de transporte es la aproximacion Pl, en la
que esta se expresa en la forma de armonicos esfericos. En el caso l = 1 se tiene la
aproximacion P1, que se compone de ecuaciones para el flujo escalar ϕ y la corriente J .
Bajo ciertas hipotesis (ver [2]), estas ecuaciones se reducen a las del metodo de difusion,
que, en ausencia de fuentes externas, son la ley de Fick
J(r, E, t) = −D(r, E)∇ϕ(r, E, t) , (6.1)
y la ecuacion para el flujo
1
v
∂ϕ(r, E, t)
∂t− ∇.D(r, E)∇ϕ(r, E, t) + Σ(r, E)ϕ(r, E, t) =
=
∫ ∞
0
Σs(r, E′ → E)ϕ(r, E ′, t)dE ′ + χ(r, E)
∫ ∞
0
νΣf (r, E′)ϕ(r, E ′, t)dE ′ , (6.2)
si D es el coeficiente de difusion, dado por
D(r, E) =1
3[Σ(r, E)− µ0(r, E)Σs(r, E)]−1 = [3Σtr(r, E)]−1 , (6.3)
donde Σtr es la seccion eficaz de transporte.
El estado estacionario corresponde al reactor crıtico asociado en k, lo que define el
problema de autovalores
− ∇.D(r, E)∇ϕ(r, E) + Σ(r, E)ϕ(r, E) =
=
∫ ∞
0
Σs(r, E′ → E)ϕ(r, E ′)dE ′ +
χ(r, E)
k
∫ ∞
0
νΣf (r, E′)ϕ(r, E ′)dE ′ . (6.4)
En la aproximacion multigrupo, estas ecuaciones pueden expresarse como
− ∇.Dg(r)∇ϕg(r) + Σr,g(r)ϕg(r) =
=∑
g′ =g
Σs0,g′→g(r)ϕg′(r) +χg(r)
k
∑
g′
νΣf,g′(r)ϕg′(r) , (6.5)
Jg(r) = −Dg(r)∇ϕg(r) , (6.6)
−Dg(r) =1
3[Σg(r)− µ0,g(r)Σs,g(r)]
−1 = [3Σtr,g(r)]−1 , (6.7)
donde ϕg, Jg y χg son valores integrales en el grupo correspondiente. Las secciones
eficaces son promedios, pesados en general con el flujo, dentro de cada grupo, con
correcciones provenientes de las aproximaciones realizadas dentro del formalismo de
difusion, entre ellas la correccion de transporte.
6.1 Teorıa de difusion 65
Las condiciones de borde mas utilizadas para la ecuacion de difusion son: vacıo,
periodicidad (sistemas infinitos), reflexion, fronteras con albedos y continuidad en las
interfaces. Cada tipo de condicion de contorno conduce a condiciones matematicas
diferentes sobre la solucion del flujo.
Al igual que en el metodo de probabilidad de colision, en el esquema multigrupo
se resuelve la ecuacion monoenergetica para cada grupo. El acople entre energıas se
establece a traves de la fuente Qg de cada grupo, es decir el lado derecho de la ecuacion
6.5. Para un grupo dado, se tiene la fuente de fision, que en principio depende del flujo
a todas las energıas, y la fuente de scattering, que proviene de la moderacion de los
neutrones y del up-scattering en los grupos termicos.
6.1.2. Formulacion en diferencias finitas
La forma mas usual de resolver numericamente la ecuacion de difusion es mediante
el metodo de diferencias finitas en 1, 2 o 3 dimensiones. Para aplicar este esquema,
el sistema debe ser dividido en regiones (segmentos en geometrıa 1D, areas en 2D
y volumenes en 3D) de dimensiones finitas (mallas). En lo que sigue se considera la
formulacion en tres dimensiones y coordenadas cartesianas, teniendo en cuenta que el
metodo es aplicable en cualquier sistema de coordenadas. Ademas, se trabaja con la
forma monoenergetica de la ecuacion de difusion, recordando que los grupos quedan
acoplados por la fuente Qg, y se omite el subındice g.
Cada malla n esta caracterizada por un volumen ∆Vn, superficies de contacto con
otras mallas ∆Snm y secciones eficaces, correspondientes al material dentro de la malla.
Para evaluar las magnitudes de interes, como flujos y fuentes, dentro de cada malla,
debe elegirse un punto caracterıstico dentro de la misma. En principio este punto es
arbitrario, pero en general se lo hace coincidir con el centroide de ∆Vn.
Integrando la ecuacion 6.5 en ∆Vn y evaluando los flujos y las fuentes en el punto
caracterıstico de la malla se obtiene, segun [2], la expresion
∑
m
Jnm∆Snm + Σr,nϕn∆Vn = Qn∆Vn , (6.8)
si se considera ϕ(Vn) = ϕn y Q(Vn) = Qn. La sumatoria sobre m representa las mallas
adyacentes a la malla n, de donde provienen las corrientes Jnm. Para la malla n = ijk
se tendran contribuciones de las m = (i± 1)jk, i(j ± 1)k, ij(k ± 1).
Para obtener la ecuacion para el flujo basta con incluir la ley de Fick en la aproxi-
macion de diferencias finitas
Jnm = dnm[ϕn − ϕm] , (6.9)
66 Metodo de difusion
Figura 6.1: Discretizacion de 7 puntos utilizada en el esquema de diferencias finitas para elmetodo de difusion.
si dnm = 2dndmdn+dm
, con dn(w) =Dn
∆w, siendo w una direccion determinada (x, y o z) y ∆w
la longitud de la malla en esa direccion. Esta expresion incluye la continuidad del flujo
en la interfase entre mallas.
De esta forma se obtiene la ecuacion para los flujos
∑
m
∆Snmdnm[ϕn − ϕm] + Σr,nϕn∆Vn = Qn∆Vn , (6.10)
sujeta a las mismas condiciones de borde que la ecuacion 6.5, expresadas en diferencias
finitas. Segun la ecuacion 6.10, cada nodo queda acoplado con sus 6 primeros vecinos,
de la forma que se muestra en la Figura 6.1.
Finalmente, definiendo los vectores ϕ y Q, que contienen los flujos y fuentes para
todas las mallas, el problema puede expresarse en forma matricial como
Aϕ = Q , (6.11)
donde A es el operador de transporte y perdidas y Q la fuente total, compuesta por el
kernel de scattering y por la fuente de fision (normalizada con el factor de multiplicacion
k), ambos dependientes del flujo.
6.1.3. Resolucion numerica
La ecuacion 6.11 puede ser resuelta analıticamente invirtiendo la matriz A, para
obtener los flujos ϕ. Sin embargo, es mas eficiente resolverla numericamente mediante
algun metodo iterativo, obteniendo la solucion mas rapidamente. Ademas, hay que
6.1 Teorıa de difusion 67
tener en cuenta que la mayorıa de los elementos de la matriz A son ceros, ya que
cada malla esta acoplada con, a lo sumo, seis mallas adyacentes, mientras que A−1
puede tener gran cantidad de elementos no nulos. Luego, la resolucion iterativa es mas
conveniente que la analıtica en terminos de memoria necesaria.
Por otro lado, cuando se resuelve la ecuacion 6.11 en el esquema multigrupo en
general la fuente Q varıa entre iteraciones exteriores, antes de converger a su valor final.
Luego, no tiene sentido hallar la solucion analıtica para una dada iteracion exterior, si
la fuente con la cual se calcula la misma no ha convergido. Los metodos iterativos, al
fijar una tolerancia para la solucion, son mas adecuados tambien en este sentido.
Para resolver el problema de forma iterativa, es conveniente expresar la ecuacion
6.11 como
ϕ = [L+ U ]ϕ+ Q , (6.12)
donde L y U son matrices triangulares estrictamente inferior y superior, respectiva-
mente. Es importante notar que, si bien la fuente Q depende en principio del flujo, su
valor durante las iteraciones sobre la ecuacion 6.12 (iteraciones interiores) se mantiene
constante, ya que la fuente de fision se calcula al principio de cada iteracion exterior y
la fuente de scattering antes de comenzar las iteraciones interiores para cada grupo.
El metodo mas simple para resolver iterativamente la ecuacion 6.12 es el metodo
de Jacobi, que se puede expresar como
ϕ(t) = [L+ U ]ϕ(t−1) + Q , (6.13)
si t es el ındice de las iteraciones, partiendo de un valor inicial ϕ(0). Este metodo
aproxima la solucion para el paso t utilizando la solucion completa para el paso t− 1.
Un segundo esquema es el de Gauss-Seidel, dado por
ϕ(t) = Lϕ(t) + U ϕ(t−1) + Q . (6.14)
En este caso, cada flujo ϕ(t)ijk se calcula a partir de los elementos de ϕ(t) que ya hayan
sido calculados y se usa ϕ(t−1) para el resto. De esta forma, la solucion converge mas
rapidamente que para el metodo de Jacobi. Ademas, este algoritmo es mas conveniente
en terminos de memoria, ya que solo se necesita un vector de flujos, que es actualizado
a medida que avanza cada iteracion, mientras que en el metodo de Jacobi es necesario
conservar ϕ(t) y ϕ(t−1).
Tanto para el metodo de Jacobi como para el de Gauss-Seidel, es necesario establecer
un criterio de convergencia para determinar cuando la solucion alcanzada es aceptable
y no es necesario continuar las iteraciones. Para esto en general se utiliza la norma
euclıdea o la norma infinito (o variantes de esta) del residuo r = Aϕ − Q, y se la
compara con una tolerancia.
68 Metodo de difusion
Por otro lado, existen metodos de aceleracion que aumentan la velocidad de conver-
gencia de los esquemas iterativos anteriores. En la aproximacion de difusion algunos de
los metodos utilizados son los de sobrerrelajacion y relajacion por lınea, y el metodo
de extrapolacion.
Los metodos de sobrerrelajacion puntuales pueden expresarse como
ϕ(t)ijk = ϕ
(t−1)ijk + ω[ϕ
∗(t)ijk − ϕ
(t−1)ijk ] , (6.15)
si ϕ∗(t)ijk es el flujo en la iteracion t calculado con el metodo sin acelerar y ω > 1 es
el factor de sobrerrelajacion (si 0 < ω < 1 el metodo es de subrelajacion). Si bien
el valor optimo para el factor ω es ωopt =2
1+√
1−µ2, siendo µ el radio espectral de la
matriz L + U , en general su valor se calcula durante la ejecucion del programa, con
diversos metodos empıricos. Con esta aceleracion, se obtienen los metodos de Jacobi so-
brerrelajado (Jacobi Over-Relaxation, JOR) y de sobrerrelajacion sucesiva (Successive
Over-Relaxation, SOR).
Los metodos de relajacion por lınea consisten en calcular los flujos a lo largo de una
fila o columna dejando fijos los coeficientes de acople de la ecuacion de difusion para
esa lınea. De esta forma, se obtiene un sistema de ecuaciones tridiagonal que puede ser
resuelto eficientemente mediante un metodo directo (no iterativo) en O(n) operaciones,
si n es el tamano de la lınea. El metodo mas utilizado en este caso es el metodo de
Thomas (TDMA), que consiste en un paso de eliminacion y un paso de sustitucion hacia
atras, similar a la eliminacion de Gauss. Si los coeficientes de acople en la iteracion t
se calculan a partir de flujos de la t− 1 se tiene el metodo de Jacobi con relajacion de
lınea (Jacobi Line Relaxation, JLR). Si las lıneas se calculan en un orden determinado
y se utilizan los flujos actualizados para calcular los coeficientes de acople, el metodo
es Gauss-Seidel con relajacion de lınea (Gauss-Seidel Line Relaxation, GSLR).
Por ultimo, el metodo de extrapolacion consiste en tratar de acercarse al valor
asintotico de la solucion a partir de la evolucion del proceso iterativo, teniendo en
cuenta que el mismo converge monotonamente. La extrapolacion para cada malla y en
cada grupo se realiza segun
ϕ(∞)ijk,g = ϕ
(t)ijk,g + zt[ϕ
(t)ijk,g − ϕ
(t−1)ijk,g ] , (6.16)
donde zt =µt
1−µtes el factor de extrapolacion, con µt dado por
µt =ϕ(t)ijk,g − ϕ
(t−1)ijk,g
ϕ(t−1)ijk,g − ϕ
(t−2)ijk,g
. (6.17)
En este caso tambien se estima el valor de zt durante el calculo, pudiendose usar
valores promedio en una cierta region o valores en puntos de referencia. Ademas, la
6.2 Paralelizacion de la ecuacion de difusion monoenergetica 69
extrapolacion debe realizarse cuando la convergencia del proceso iterativo sigue apro-
ximadamente el comportamiento teorico, tıpicamente cuando el valor de zt se mantiene
dentro de un determinado rango entre iteraciones.
El codigo CITATION 2.0, que constituye el motor de calculo del programa CITVAP
y en el cual fueron implementados los algoritmos que se proponen a continuacion,
utiliza el metodo de Gauss-Seidel con relajacion de lınea, combinado con los metodos
de sobrerrelajacion y extrapolacion.
6.2. Paralelizacion de la ecuacion de difusion mo-
noenergetica
En esta seccion se presentan diversos esquemas de paralelizacion de los metodos
iterativos utilizados para la aproximacion de difusion, teniendo en cuenta los metodos
de aceleracion comentados.
6.2.1. Metodo de Jacobi
Dado que al momento de calcular ϕ(t) se conoce el valor de todas las componentes
de ϕ(t−1) y que no existe dependencia entre los calculos de distintos ϕ(t)ijk, el metodo de
Jacobi es directamente paralelizable. En este caso, basta con descomponer el dominio
de calculo en subdominios, y asignar a cada procesador el computo de los flujos de un
subdominio.
En el Algoritmo 6.1 se muestra la implementacion de una iteracion interior del meto-
do de Jacobi con paralelismo de loop en OpenMP. Los loops sobre los ındices k, j e i son
tales que barren solo la parte del dominio Dp = [k0(p), kf (p)]x[j0(p), jf (p)]x[i0(p), if (p)]
asignado al procesador p. Cada procesador debe calcular el error ϵp correspondiente al
dominio Dp, para la iteracion t. Luego, estos deben ser condensados en el error global
ϵ segun la norma que se elija para evaluar la convergencia.
La eficiencia de la paralelizacion sera mas alta cuanto mas uniforme sea la cantidad
de mallas por procesador, es decir el tamano de Dp. Esto depende fundamentalmente
de la forma en que se mapee el dominio en los procesadores.
La descomposicion de dominio mas sencilla de implementar es en funcion del ındice
exterior, en este caso k, que corresponde a n = 1 en el Algoritmo 6.1. De esta for-
ma, si se tiene un sistema grande en relacion al numero de procesadores P , esto es
kmax >> P , en principio es facil generar cargas similares sobre los procesadores. Sin
embargo, al disminuir kmax
Pel desbalance entre procesos se torna importante, afectando
significativamente la escalabilidad fuerte (con kmax fijo).
Luego, para mejorar la escalabilidad fuerte del algoritmo es conveniente descom-
70 Metodo de difusion
Algoritmo 6.1 Paralelizacion del metodo de Jacobi.
!$OMP parallel shared(ϕ(t), ϕ(t−1), ϵ, ...) private(ϵp, ...)!$OMP do schedule(...) collapse(n)for k = 1 to kmax do
for j = 1 to jmax dofor i = 1 to imax do
Jacobi(ϕ(t−1)) ⇒ ϕ(t)(i, j, k)end for
end forend fornorm(ϕ(t) − ϕ(t−1))|Dp ⇒ ϵp!$OMP end doreduction(ϵp) ⇒ ϵ!$OMP end parallel
Algoritmo 6.2 Paralelizacion del metodo de Jacobi con relajacion de lınea.
!$OMP parallel shared(ϕ(t), ϕ(t−1), ϵ, ...) private(ϵp, ...)!$OMP do schedule(...) collapse(2)for k = 1 to kmax do
for j = 1 to jmax doTDMA(ϕ(t−1)) ⇒ ϕ(t)(1 : imax, j, k)
end forend fornorm(ϕ(t) − ϕ(t−1))|Dp ⇒ ϵp!$OMP end doreduction(ϵp) ⇒ ϵ!$OMP end parallel
poner el dominio en funcion de al menos dos de los ındices, esto es n = 2, 3. Sin
embargo, agregar el tercer ındice puede no ser conveniente, ya que se podrıa tener una
disminucion de la eficiencia por false sharing.
Ademas, si se quiere implementar este metodo con relajacion de lınea (JLR) no es
posible descomponer el dominio segun el ındice i, ya que todos los flujos sobre una
lınea son calculados simultaneamente. En este caso, se tendra un algoritmo de la forma
del 6.2.
En cuanto a la escalabilidad debil, es de esperar que la descomposicion del dominio
en funcion de k sea suficiente para alcanzar eficiencias aceptables, si kmax >> P .
Como ultimo comentario, hay que mencionar que el metodo de Jacobi paralelizado
de estas dos maneras se puede combinar directamente con los metodos de sobrerrela-
jacion y de extrapolacion, de la misma forma que el algoritmo serial. Esto se debe a
que estos metodos introducen correcciones para cada flujo individualmente, por lo que
no se generan dependencias adicionales.
6.2 Paralelizacion de la ecuacion de difusion monoenergetica 71
Figura 6.2: Grilla con puntos pares (rojos) e impares (negros).
6.2.2. Metodo de Gauss-Seidel
En los programas secuenciales en general se prefiere el metodo de Gauss-Seidel fren-
te al de Jacobi, por poseer mayor velocidad de convergencia y menor requerimiento de
memoria. Sin embargo, para implementaciones en paralelo este metodo presenta algu-
nas limitaciones, debidas principalmente a su naturaleza inherentemente secuencial.
Dado que para calcular ϕ(t)(i, j, k) se necesitan ϕ(t)(i − 1, j, k), ϕ(t)(i, j − 1, k) y
ϕ(t)(i, j, k − 1), que en principio pueden ser calculados por procesadores distintos, se
tiene una fuerte dependencia de datos. Luego, es necesario hallar una forma de mapear
el dominio que sea factible de paralelizar, es decir que minimice estas dependencias.
Una primera opcion que suele proponerse es barrer el dominio en forma de un frente
de onda compuesto por puntos cuyo calculo no depende del de otros puntos dentro del
frente. Si se recorre la grilla (i, j, k) segun planos dados por i+ j + k = m,m ∈ N, porejemplo, para calcular ϕ(t)(i, j, k) perteneciente al plano m se utilizan los puntos del
plano m−1 ya calculados y los del plano m+1 de la iteracion anterior. De esta forma,
los puntos del plano m pueden calcularse en paralelo. Aun ası, este algoritmo requiere
sincronizacion entre planos, y ademas es difıcil balancear la carga de los procesadores,
ya que cada plano tiene un numero distinto de elementos, con lo cual la eficiencia
obtenida en general es muy baja.
La estrategia mas utilizada consiste en ordenar los puntos de la grilla segun tengan
ındice m = i+ j + k par o impar (puntos rojos o negros). De esta forma, se obtiene un
patron como el que se muestra en la Figura 6.2, similar a un tablero de ajedrez, con
los colores alternados entre planos. Dada la formulacion en diferencias finitas utilizada,
para calcular un punto de un color en la iteracion t solo se necesitan puntos del otro
color, de la iteracion t o t− 1.
Teniendo esto en cuenta, puede realizarse cada iteracion sobre todo el dominio en
dos etapas. En primer lugar pueden calcularse todos los puntos rojos, por ejemplo, en
72 Metodo de difusion
Algoritmo 6.3 Paralelizacion del metodo de Gauss-Seidel en un esquema rojo-negro.
!$OMP parallel shared(ϕ(t), ϕ(t−1), ϵ, ...) private(ϵ1,p, ϵ2,p, ...)!$OMP do schedule(...) collapse(n)for i, j, k ∈ Dp / i+ j + k = 2m,m ∈ N do
Jacobi(ϕ(t−1)) ⇒ ϕ(t)(i, j, k)end fornorm(ϕ(t) − ϕ(t−1))|Dp,2m ⇒ ϵ1,p!$OMP end do!$OMP do schedule(...) collapse(n)for i, j, k ∈ Dp / i+ j + k = 2m+ 1, m ∈ N do
Gauss-Seidel(ϕ(t)) ⇒ ϕ(t)(i, j, k)end fornorm(ϕ(t) − ϕ(t−1))|Dp,2m+1 ⇒ ϵ2,p!$OMP end doreduction(ϵ1,p, ϵ2,p) ⇒ ϵ!$OMP end parallel
paralelo y en un orden arbitrario para la iteracion t, ya que solo se necesitan los valores
de los puntos negros en t− 1. Este primer calculo es equivalente al metodo de Jacobi.
A continuacion, se calculan en paralelo los puntos negros, en este caso, esta vez con los
valores de los puntos rojos de la iteracion t, de acuerdo con el metodo de Gauss-Seidel.
El Algoritmo 6.3 muestra una posible implementacion de este metodo.
De esta forma, se tiene una iteracion 50% Jacobi y 50% Gauss-Seidel, con un alto
grado de paralelismo. La velocidad de convergencia de este esquema ejecutado en un
solo procesador en general se encuentra entre la del metodo de Jacobi y la del de
Gauss-Seidel estandar.
El metodo SOR puede ser paralelizado de la misma manera, ya que para calcular
ϕ(t)(i, j, k) se utilizan los mismos puntos que en el metodo de Gauss-Seidel, mas el valor
de ϕ(t−1)(i, j, k), con lo cual no se generan dependencias adicionales entre mallas. Lo
mismo ocurre si se quiere acelerar el algoritmo mediante extrapolacion.
El metodo de relajacion por lınea, sin embargo, no se puede aplicar con el mallado
separado en puntos pares e impares, ya que no se tienen filas ni columnas de elementos
contiguos del mismo color. En este caso, se puede colorear el sistema segun la paridad
de los planos, es decir del ındice k, o de las filas, segun j + k = m, como se muestra en
la Figura 6.3. En el primer caso, se barren primero los planos rojos, por ejemplo, en
un esquema JLR en paralelo, y a continuacion se aplica el metodo GSLR en los planos
negros. En el segundo caso tambien se hace un barrido JLR y otro GSLR, ambos en
paralelo, pero esta vez por filas. En los dos casos se obtiene, al igual que en el esquema
rojo-negro tradicional, un algoritmo 50% Jacobi y 50% Gauss-Seidel, con relajacion
de lınea.
Como tercera propuesta, es posible descomponer el dominio de calculo y asignar
6.2 Paralelizacion de la ecuacion de difusion monoenergetica 73
Figura 6.3: Grilla coloreada segun filas (izquierda) y planos (derecha).
Figura 6.4: Interfase entre los subdominios de los procesadores p y p+ 1.
a cada procesador el calculo de un subdominio, de forma analoga a la paralelizacion
del metodo de Jacobi. En este caso, sin embargo, se tendra dependencia entre los
procesadores en las interfases de los subdominios.
Para ejemplificar el problema de las interfases, en la Figura 6.4 se muestra el calculo
de un flujo ubicado en el plano k = kf (p), suponiendo que el dominio se encuentra
subdividido por procesadores en funcion del ındice k. Los flujos pertenecientes al plano
kf (p) necesarios para calcular ϕ(t)(i, j, k), esto es ϕ(t)(i± 1, j, k) y ϕ(t)(i, j ± 1, k), y el
flujo ϕ(t−1)(i, j, k−1), corresponden a la region asignada al procesador p, con lo cual se
puede asegurar su valor al momento de realizar el calculo. Sin embargo, ϕ(t)(i, j, k+1),
perteneciente al plano k0(p + 1), es calculado por el procesador p + 1, con lo cual al
momento de calcular ϕ(t)(i, j, k) su valor puede corresponder a la iteracion t o a la t−1,
o puede estar siendo actualizado en ese momento.
Luego, a menos que se proteja el acceso a los flujos en las interfases, se tienen data
races en los planos k0 y kf de todos los procesadores. En OpenMP el comportamiento
en caso de data races esta indeterminado, con lo cual se pueden generar resultados
incorrectos.
74 Metodo de difusion
Para solucionar este problema, pueden calcularse los flujos de la iteracion t en la
frontera deDp usando valores de la t−1 para los flujos fuera deDp, de manera similar al
metodo de Jacobi. Ası, se evitan los errores por data races, ya que los flujos modificados
por un procesador no son accedidos por otros.
Sin embargo, de esta forma no se aprovechan flujos ya calculados que podrıan ser
utilizados. Mas aun, en el caso de subdividir el dominio segun el ındice k, en general
al momento de calcular los flujos en el plano kf (p) (el ultimo para el procesador p) ya
habran sido calculados los flujos en el k0(p+ 1) (el primero para el procesador p+ 1).
En consecuencia, es conveniente sincronizar el acceso a los flujos de las interfases, para
que los procesadores puedan leer en forma segura los valores actualizados una vez que
hayan sido calculados. En este caso tambien es necesario asegurar la consistencia de
la memoria del procesador que calcula los flujos y del que los utiliza, aumentando el
costo de la administracion y sincronizacion de threads.
Una iteracion interior con este metodo, en un esquema Gauss-Seidel con relajacion
de lınea, puede implementarse como se muestra en el Algoritmo 6.4.
De esta forma, se obtiene un esquema de Gauss-Seidel en la mayorıa del sistema,
y la eficiencia estara determinada principalmente por la descomposicion del dominio
utilizada y por la implementacion particular de la sincronizacion en las interfases.
Ademas, el metodo implementado de esta forma es compatible con todos los metodos
de aceleracion considerados, en particular con el de relajacion de lınea.
6.3. Implementacion en CITATION-CITVAP
Se analizaron algoritmos paralelizados para el metodo de Gauss-Seidel y para el de
Jacobi. Para el primer metodo se utilizaron esquemas rojo-negro por filas y por planos,
y la descomposicion del dominio por planos con sincronizacion en las interfases entre
procesos. Para el segundo se implemento la descomposicion del dominio por planos y
por filas.
Los resultados presentados para el codigo CITVAP corresponden exclusivamente a
los calculos monoenergeticos.
6.3.1. Metodo de Gauss-Seidel
Habiendose descartado la paralelizacion por frente de onda, se implementaron es-
quemas rojo-negro por filas y por planos, para geometrıas xyz y triangular-z. Dado
que estos algoritmos no requieren sincronizacion entre procesadores, su programacion
es directa. Ademas, es posible utilizarlos con relajacion de lınea, que es uno de los
metodos de aceleracion utilizados en CITVAP.
Es importante notar que en este caso la ejecucion es determinista, es decir que
6.3 Implementacion en CITATION-CITVAP 75
Algoritmo 6.4 Paralelizacion del metodo de Gauss-Seidel utilizando sincronizacion.
!$OMP parallel shared(ϕ(t), ϕ(t−1), f lags, ...) private(flag, ϕpointer, ...)
ϕpointer(1 : kmax) → ϕ(t)(1 : kmax)!$OMP do schedule(...)for k = 1 to kmax do
if k = k0(p) [kf (p)] then!$OMP flush(flags)!$OMP atomic readflag = flags(kf (p− 1)) [flags(k0(p+ 1))]if flag = true then
!$OMP flush(ϕ(t))
ϕpointer(k) → ϕ(t)(kf (p− 1)) [ϕ(t)(k0(p+ 1))]else
ϕpointer(k) → ϕ(t−1)(kf (p− 1)) [ϕ(t−1)(k0(p+ 1))]end if
end iffor j = 1 to jmax do
TDMA(ϕpointer) ⇒ ϕ(t)(1 : imax, j, k)end forif k = k0(p) or k = kf (p) then
!$OMP flush(ϕ(t))!$OMP atomic writeflags(k) = true!$OMP flush(flags)
end ifend for!$OMP end do!$OMP end parallel
siempre se obtiene exactamente el mismo resultado, ya que el orden en el cual se
calculan los flujos de cada color es irrelevante. Sin embargo, los resultados son distintos
respecto del esquema Gauss-Seidel secuencial, aunque obviamente coinciden dentro del
error de convergencia establecido. Ademas, la velocidad de convergencia, esto es el
numero de iteraciones exteriores, no depende del numero de procesadores.
Por otro lado, se implemento el algoritmo con descomposicion del dominio por
planos. Se realizo la sincronizacion de forma tal de que, si al momento de calcular
un plano perteneciente a la frontera de Dp los flujos necesarios calculados por otro
procesador estan disponibles, estos son utilizados. En el caso contrario se utilizan flujos
de la iteracion anterior.
Como consecuencia, la ejecucion no es determinista, si no que se pueden tener dife-
rentes resultados en distintas corridas, todos dentro del error de convergencia. Ademas,
el numero de iteraciones exteriores varıa entre calculos de un mismo sistema, y tam-
bien al cambiar el numero de procesadores, ya que cambia el numero de interfases. Este
76 Metodo de difusion
4 8 12 16 20 24
Número de procesadores
0
100
200
300
400
500
600
700
800
Núm
ero
de ite
raci
ones
exte
riore
s
DD + sincronizaciónRojo-negro por planosRojo-negro por filas
Figura 6.5: Iteraciones exteriores hasta la convergencia para las tres implementaciones delmetodo de Gauss-Seidel.
esquema solo fue implementado en geometrıa xyz.
6.3.1.1. Resultados en geometrıa xyz
Las tres variantes del metodo de Gauss-Seidel en geometrıa xyz fueron utilizadas
en el calculo de un nucleo tipo MTR, discretizado en 120x100x120 mallas.
Para comparar estas tres opciones, en primer lugar se analizo el numero de iteracio-
nes exteriores necesario para alcanzar la convergencia. Los resultados se muestran en la
Figura 6.5. Como puede verse, la velocidad de convergencia es mayor para el algoritmo
rojo-negro por filas, y para los otros dos es similar.
El speedup obtenido con los tres metodos puede verse en la Figura 6.6. El algoritmo
con sincronizacion presenta el mejor speedup entre las tres opciones, y esta fuertemente
influenciado por la cantidad de iteraciones. Los dos esquemas rojo-negro tienen speedups
menos ruidosos, ya que el numero de iteraciones es constante, pero su eficiencia es mas
baja. La paralelizacion por filas lleva al speedup mas bajo entre las tres opciones.
El tiempo de calculo para estas tres variantes esta determinado tanto por el speedup
como por el numero de iteraciones. Como se ve en la Figura 6.7, si bien el speedup de la
paralelizacion rojo-negro por filas es el peor, el tiempo de calculo requerido es menor,
ya que la velocidad de convergencia es significativamente mayor.
6.3.1.2. Resultados en geometrıa triangular-z
Para comparar los esquemas rojo-negro por filas y planos en geometrıa triangular-
z se calculo un reactor de agua liviana con mallado de 48x72x180. Se obtuvieron el
speedup y el tiempo de calculo que se muestran en las Figuras 6.8 y 6.9. El speedup
obtenido con ambas variantes es similar, pero el numero de iteraciones, y por lo tanto
el tiempo de calculo, es menor para la paralelizacion por filas.
6.3 Implementacion en CITATION-CITVAP 77
4 8 12 16 20 24
Número de procesadores
0
2
4
6
8
10
12
14
Speedup
Rojo-negro por planosRojo-negro por lasDD + sincronización
Figura 6.6: Speedup en funcion del numero de procesadores para las tres variantes del metodode Gauss-Seidel implementadas en xyz.
4 8 12 16 20 24
Número de procesadores
0
10
20
30
40
50
60
70
80
Tiem
po d
e c
álc
ulo
(s)
Rojo-negro por planosRojo-negro por lasDD + sincronización
Figura 6.7: Tiempos de calculo en geometrıa xyz.
2 4 6 8 10 12
Número de procesadores
0
1
2
3
4
5
6
7
Speedup
Rojo-negro por planosRojo-negro por filas
Figura 6.8: Speedup para los metodos rojo-negro en geometrıa triangular-z.
78 Metodo de difusion
2 4 6 8 10 12
Número de procesadores
0
10
20
30
40
Tiem
po d
e c
álc
ulo
(s)
Rojo-negro por planosRojo-negro por filas
Figura 6.9: Tiempos de calculo obtenidos en geometrıa triangular-z.
4 8 12 16 20 24
Número de procesadores
0
2
4
6
8
10
Speedup
JacobiGauss-Seidel
Figura 6.10: Comparacion del speedup obtenido con el metodo de Jacobi y el de Gauss-Seidelrojo-negro, ambos paralelizados por filas.
6.3.2. Metodo de Jacobi
En este caso se implementaron dos variantes de descomposicion del dominio: por
planos y por filas. Dada la insensibilidad del algoritmo a la paralelizacion, el numero de
iteraciones exteriores para alcanzar la convergencia no varıa entre estas dos variantes.
Ademas, los flujos calculados no cambian entre corridas ni al aumentar el numero de
procesadores.
Para el metodo de Jacobi, el speedup obtenido es mayor para la paralelizacion por
filas. Sin embargo, no se observo una mejora del speedup respecto de los esquemas
de Gauss-Seidel presentados. Para un problema en geometrıa xyz de 64x64x64 mallas
se obtuvieron los resultados que se muestran en la Figura 6.10, donde se compara el
metodo de Jacobi paralelizado por filas con el de Gauss-Seidel rojo-negro tambien por
filas.
Como se ve en la Figura 6.10, el speedup alcanzado con el metodo de Jacobi es
6.4 Discusion 79
4 8 12 16 20 24
Número de procesadores
0
10
20
30
40
50
Tiem
po d
e c
álc
ulo
(s)
JacobiGauss-Seidel
Figura 6.11: Tiempo de calculo para los metodos de Jacobi y Gauss-Seidel.
muy cercano al del metodo de Gauss-Seidel. Sin embargo, el tiempo de calculo es
significativamente mayor que para el metodo de Gauss-Seidel, como puede verse en
la Figura 6.11. Esto se debe a que el numero de iteraciones hasta la convergencia es
notablemente mayor en el primer caso que en el segundo. Para el problema estudiado
los flujos convergen en 804 iteraciones para el metodo de Jacobi y en 204 para Gauss-
Seidel.
6.4. Discusion
En primer lugar, se concluyo que el metodo de Jacobi no es factible de implementar
eficientemente, al menos con los metodos de aceleracion utilizados en CITATION. Exis-
ten metodos de aceleracion adicionales para este esquema, en particular el de relajacion
programada (Scheduled Jacobi Relaxation, SJR), que pueden reducir significativamente
el numero de iteraciones exteriores, pero que no fueron estudiados en este trabajo.
Para el metodo de Gauss-Seidel se obtuvo mejor speedup con el algoritmo con des-
composicion directa del dominio y sincronizacion. Sin embargo, para la paralelizacion
rojo-negro por filas el numero de iteraciones necesarias para alcanzar la convergencia
es menor que para los otros dos metodos propuestos.
Dado que la variable que determina la eleccion de un algoritmo sobre los otros es el
tiempo de calculo, se concluyo que la mejor paralelizacion del metodo de Gauss-Seidel
es el esquema rojo-negro por filas.
Capıtulo 7
Modelo de memoria distribuida y
modelo hıbrido
“- Cypher: I know what you’re thinking, ’cause right now I’m
thinking the same thing. Actually, I’ve been thinking it ever
since I got here: Why oh why didn’t I take the blue pill?”
— The Matrix, 1999.
En los capıtulos anteriores fueron presentados algoritmos utilizados para resolver
distintos aspectos y aproximaciones de la ecuacion de transporte, y su optimizacion
mediante el procesamiento en paralelo. Los algoritmos paralelizados fueron implemen-
tados en su totalidad en OpenMP, que se basa en el modelo de memoria compartida.
En este capıtulo se presenta el modelo de memoria distribuida como una alternativa
para optimizar las implementaciones realizadas. Ademas, se estudian las formas de
combinar los modelos de memoria compartida y distribuida para explotar arquitecturas
mas diversas.
Para la programacion de este modelo hıbrido se utilizo el estandar MPI, basado
en mensajerıa entre procesos, combinado con OpenMP. Como ejemplo de aplicacion
se implemento el calculo de probabilidades de colision y flujos de respuesta con este
esquema.
7.1. Modelo de memoria distribuida
Como se explico en el Capıtulo 2, en el modelo de memoria distribuida cada proce-
sador tiene su propia memoria, a la cual el resto de los procesadores no pueden acceder.
La memoria puede estar distribuida fısicamente de esta manera, por ejemplo en un clus-
ter de computadoras de un solo procesador. Sin embargo, en general se tienen nodos
SMP con mas de un procesador, y la memoria esta distribuida a nivel de software, es
81
82 Modelo de memoria distribuida y modelo hıbrido
decir que cada nucleo tiene un espacio de memoria virtual privado, que fısicamente es
parte de la memoria utilizada por el resto de los procesadores.
Como consecuencia, el modelo de memoria distribuida puede implementarse esen-
cialmente en cualquier arquitectura paralela. En este esquema, la comunicacion entre
procesos es explıcita, y en general se realiza mediante mensajerıa.
Dado que cada procesador posee su propia memoria, muchos de los factores que
contribuyen al overhead en el modelo de memoria compartida en este caso no existen,
y el acceso de cada procesador a su memoria privada es muy rapido. Los conceptos de
consistencia de memoria y coherencia de caches no son aplicables, y por lo tanto no
se tienen conflictos relacionados con el acceso a memoria, en particular false sharing y
asimetrıas entre nodos NUMA. Como contrapartida, se debe optimizar el intercambio
de mensajes, teniendo en cuenta que existen demoras, cuellos de botella asociados
a la red que interconecta los procesadores y diferentes tiempos de transmision entre
distintos pares de nodos en una dada arquitectura.
Por otro lado, en este modelo la memoria disponible para el programa es proporcio-
nal al numero de procesadores, ya que al agregar un procesador se suma su memoria
asociada. Este hecho constituye una ventaja importante del esquema de memoria com-
partida. En problemas muy intensivos en terminos de memoria se suele elegir este
modelo por esta razon.
A lo largo de los anos han existido diversas implementaciones bastante diferentes
del modelo de memoria compartida, entre ellas Parallel Virtual Machine (PVM). En la
actualidad, virtualmente todas las aplicaciones son desarrolladas con Message Passing
Interface (MPI), que es la herramienta utilizada en este trabajo para este modelo.
7.2. Modelo hıbrido de memoria compartida y dis-
tribuida
Las grandes computadoras modernas (clusters) se componen de varios nodos inter-
conectados por una red, que conforman un sistema de memoria distribuida fısicamente.
Cada nodo representa un espacio de memoria compartida, donde los procesadores pue-
den acceder a la memoria de forma uniforme (UMA) o no uniforme (NUMA), siendo
este ultimo el caso mas usual. Un nodo NUMA (ccNUMA) en general esta compuesto
por varias placas SMP (por una sola si el nodo es UMA), dentro de las cuales distintos
CPUs (sockets) acceden a la memoria de forma uniforme. Por ultimo, cada CPU puede
contener varios nucleos (procesadores) y sus caches. En la Figura 7.1 se esquematiza
un nodo ccNUMA de dos placas SMP de cuatro CPUs cada una (cada CPU puede
contener varios procesadores).
Ahora bien, con el modelo de memoria distribuida, y en particular con MPI, pueden
7.2 Modelo hıbrido de memoria compartida y distribuida 83
Figura 7.1: Esquema de un nodo ccNUMA compuesto por dos placas SMP, cada una concuatro CPUs.
utilizarse en principio todos los procesadores disponibles, utilizando comunicacion a
traves de mensajerıa. De esta forma se transmiten mensajes entre procesadores lejanos,
por ejemplo ubicados en nodos distintos, pero tambien entre nucleos que comparten
memoria. En este ultimo caso, el uso de mensajes puede no ser la forma mas eficiente
de comunicacion.
Por otro lado, existen algunos pocos sistemas de memoria fısicamente distribuida en
nodos que utilizan un espacio de memoria virtual comun, conformando un sistema de
memoria logicamente compartida. En estos casos, la necesidad de mantener coherencia
entre caches, el costo de administrar un espacio de memoria comun y los cuellos de bo-
tella asociados a la red interconectora, entre otros factores, lleva a eficiencias realmente
bajas en el uso de los recursos.
Entonces, teniendo en cuenta que un sistema de las caracterısticas presentadas es
una combinacion de arquitecturas de memoria compartida y distribuida, es razonable
pensar que la forma optima de utilizarlo puede resultar de una combinacion de ambos
enfoques. El modelo hıbrido se compone de regiones dentro de las cuales se utiliza
memoria compartida, comunicadas entre sı por un modelo de memoria distribuida.
Aquı, las regiones pueden ser nodos ccNUMA, con memorias fısicamente separadas,
pero tambien pueden ser placas SMP (dominios NUMA) o incluso CPUs. En el primer
caso no serıa posible aprovechar todos los procesadores con un modelo de memoria
compartida, con lo cual si se quiere aprovechar la memoria compartida dentro de cada
nodo necesariamente se debe utilizar el esquema hıbrido. En el segundo caso, se tiene
en cuenta que el acceso a la memoria compartida es rapido para memoria local, pero
para acceder a memoria remota (ver Figura 7.1) existe un overhead mayor, con lo
cual puede ser mas eficiente utilizar mensajerıa entre dominios NUMA. Una de las
principales optimizaciones de un programa en este esquema consiste en encontrar la
mejor forma de mapear los dos niveles de paralelismo a la arquitectura en la cual se
84 Modelo de memoria distribuida y modelo hıbrido
ejecuta.
Este modelo de programacion tiene importantes ventajas respecto de los dos mo-
delos de los que se compone, que compensan la complejidad adicional del codigo resul-
tante. En primer lugar, el modo de ejecucion de un programa escrito de esta forma es
sumamente flexible, y puede adaptarse a practicamente cualquier arquitectura parale-
la. En segundo lugar, se suele mejorar la escalabilidad respecto de un programa basado
solamente en el modelo de memoria compartida.
Para entender esto ultimo, hay que tener en cuenta que si un programa utiliza
nucleos dentro de un nodo SMP el acceso a la memoria es rapido y la coherencia de
caches eficiente. Sin embargo, al aumentar el numero de procesadores eventualmente
se necesita utilizar mas de un nodo SMP, y aparecen accesos de memoria mas lentos
entre dominios NUMA y cuellos de botella por ancho de banda, y la coherencia de
caches se vuelve mas costosa. Los overheads generados conducen a perdidas de eficien-
cia significativos, con lo cual el modelo de memoria compartida exclusivo deja de ser
conveniente.
En cuanto a las implementaciones de este modelo, en principio puede ser combinada
cualquier herramienta de memoria compartida con cualquiera de mensajerıa. En este
trabajo se utilizo OpenMP con MPI, que es la combinacion mas usual.
7.3. Mensajerıa y modelo hıbrido con MPI
Message Passing Interface (MPI) es una especificacion que define una biblioteca de
intercambio de mensajes para aplicaciones de memoria distribuida. En ella se definen
formas de enviar y recibir mensajes entre procesos, rutinas de comunicacion colectivas
y funciones para el control de los procesos. Existen diversas implementaciones de la
especificacion, siendo OpenMPI la elegida para este trabajo.
Si bien MPI no es un estandar formal, es considerado el estandar de facto para
aplicaciones de memoria distribuida, ya que ha reemplazado virtualmente a todas las
otras herramientas previas. Ademas, es portable entre plataformas y arquitecturas, y
los programas que utilizan MPI presentan una gran flexibilidad y eficiencia al adaptarse
a diversos tipos de hardware.
El modelo de ejecucion de MPI es SPMD. En primer lugar, se crea un numero deter-
minado de procesos (tasks), que queda fijo durante la corrida. Todos los tasks tienen la
misma jerarquıa, y son identificados con un numero dentro del grupo. A continuacion,
todos los procesos ejecutan el mismo codigo, generalmente teniendo su numero de iden-
tificacion como parametro para diferenciar ciertas secciones del programa o trabajar
sobre una porcion de un conjunto de datos. En calculos de transporte, por ejemplo, se
puede asignar a cada proceso un subdominio de la geometrıa o una parte de los grupos
en un esquema multigrupo, entre otras opciones. Durante la ejecucion, la memoria de
7.4 Calculo de flujos de respuesta utilizando MPI-OpenMP 85
Figura 7.2: Modelo de ejecucion hıbrido MPI-OpenMP.
un procesador es inaccesible al resto, y cualquier comunicacion necesaria se lleva a cabo
mediante el intercambio de mensajes.
Para pasar al esquema hıbrido con OpenMP, en primer lugar hay que determinar el
nivel de soporte de threads de la implementacion de MPI. El estandar especifica cuatro
niveles de soporte: single (sin threads), funneled (solo el master thread puede enviar y
recibir mensajes), serialized (dentro de un proceso, todos los threads pueden intercam-
biar mensajes, pero no a la misma vez) y multiple (sin restricciones). La comunicacion
entre procesos con multi-threading debera ser efectuada segun el nivel de soporte de
threads de la biblioteca utilizada. En particular, OpenMPI posee soporte serialized.
El modelo de ejecucion de una aplicacion MPI-OpenMP se muestra en la Figura
7.2. Se crea un cierto numero de procesos de MPI, que ejecutan el mismo programa
(SPMD) y se comunican con mensajerıa. Cada task es ademas el master thread de un
ambiente de OpenMP, con lo cual crea y destruye grupos de threads segun el modelo de
ejecucion de OpenMP. En resumen, se tiene el modelo fork-join de OpenMP anidado
dentro del modelo SPMD de MPI. Entonces, para usar todos los procesadores en un
momento dado, el producto de la cantidad de procesos de MPI por la de threads de
OpenMP debe coincidir con el numero de procesadores.
7.4. Calculo de flujos de respuesta utilizando MPI-
OpenMP
Para estudiar este modelo en un caso particular, se implemento el calculo de flujos
de respuesta en CONDOR en un esquema MPI-OpenMP con dos niveles de paralelismo.
El primer nivel consiste en distribuir los grupos en distintos procesos de MPI, cada uno
de los cuales posee la informacion geometrica del sistema y las secciones eficaces solo
para los grupos que le son asignados. En el segundo nivel, las celdas son calculadas en
paralelo en diferentes threads de OpenMP, creados en el contexto de cada proceso de
86 Modelo de memoria distribuida y modelo hıbrido
MPI.
La ventaja principal de esta implementacion es la flexibilidad que ofrece su ejecu-
cion, ya que el numero de tasks de MPI y de threads de OpenMP por task es arbitrario.
Entonces, dado un numero de procesadores, debe determinarse la combinacion optima
de tasks y threads para una arquitectura dada. La velocidad del programa dependera de
la forma en la que se mapeen las unidades de ejecucion a los recursos de hardware.
En los casos en los que se tenga una arquitectura de memoria distribuida fısicamen-
te, necesariamente debe existir al menos un proceso de MPI por nodo para que todos
los procesadores puedan ser utilizados. Sin embargo, dentro de cada nodo de memoria
compartida se pueden utilizar tasks de MPI y threads de OpenMP combinados, para
explotar la distribucion de memoria especıfica.
Ademas, el modelo de ejecucion optimo depende del problema particular que se
quiera resolver. Si el problema es intensivo en terminos de memoria, por ejemplo,
puede resultar conveniente utilizar un numero grande de nodos, por mas que no se
utilicen todos los procesadores de cada nodo, para que la memoria disponible para el
programa sea mayor. En un problema que no requiera mas memoria que la de un nodo,
la eleccion depende exclusivamente de la velocidad de ejecucion.
7.4.1. Resultados numericos en CONDOR
El principal aspecto a determinar en este esquema de calculo es la forma de mapear
los procesos y threads a la arquitectura en la que se calcula. No solo se debe elegir
la relacion tasks-threads, si no tambien la afinidad de estas unidades de ejecucion con
los recursos disponibles. Por afinidad se entiende la asignacion de tasks y threads a
procesadores o conjuntos de procesadores especıficos.
OpenMPI v1.5.x permite asignar procesos a unidades de hardware, que pueden
ser nodos, sockets, dominios NUMA, CPUs, procesadores o nucleos, por ejemplo. Por
otro lado, OpenMP v3.1 ofrece capacidades relativamente limitadas para establecer la
afinidad de threads con nucleos determinados.
Para estudiar la dependencia del algoritmo implementado a la forma de mapear el
programa, se calculo un elemento combustible MTR de placas planas. En primer lugar
se probaron distintas combinaciones de tasks de MPI y threads de OpenMP, utilizando
en total 24 procesadores. En segundo lugar, se comparo la velocidad obtenida utilizando
afinidad de procesos y threads con procesadores con la alcanzada usando unidades de
ejecucion sin afinidad con recursos de hardware.
Las pruebas fueron realizadas en un nodo ccNUMA de 24 procesadores, con dos
dominios NUMA de 12 procesadores. Para el caso con afinidad se ejecutaron igual
cantidad de procesos de MPI para cada dominio NUMA, es decir que dentro de cada
dominio NUMA no existe afinidad, pero sı entre dominios.
7.4 Calculo de flujos de respuesta utilizando MPI-OpenMP 87
1 / 24 2 / 12 4 / 6 6 / 4 12 / 2 24 / 1
Tasks MPI / Threads OpenMP
15
20
25
30
Tiem
po d
e c
álc
ulo
(s)
Con a nidadSin a nidad
Figura 7.3: Tiempos de calculo de flujos de respuesta con el modelo hıbrido MPI-OpenMP,con y sin afinidad de tasks y threads con procesadores.
Como puede verse en la Figura 7.3, el tiempo de calculo es superior cuando no se
utiliza afinidad y los hilos de ejecucion utilizan recursos de forma arbitraria. La maxima
diferencia observada respecto al caso con afinidad es del 9% en tiempo de calculo.
Por otro lado, para la ejecucion utilizando afinidad el mınimo tiempo de calculo
se obtuvo para 12 tasks de MPI y 2 threads de OpenMP por task. Sin embargo, en
este caso la diferencia entre distintas relaciones tasks-threads no es significativa, con
excepcion del caso en el que se utilizan solo procesos de MPI, en el que el tiempo de
ejecucion aumenta en un 10% respecto a las otras corridas con afinidad.
7.4.2. Discusion
Como puede verse en la Figura 7.3, la diferencia en performance del modelo hıbri-
do con afinidad respecto de la implementacion con OpenMP puro no es significativa.
Mas alla de posibles ineficiencias en la implementacion, esto se debe en parte a que
las capacidades de afinidad de las versiones de OpenMPI y OpenMP utilizadas son
limitadas.
Para la version de OpenMPI utilizada la afinidad se establecio con las opciones
-bind-to-socket, -bysocket y -cpus-per-proc, que determinan el modo de ejecucion. Sin
embargo, estas opciones estan en proceso de desarrollo y al dıa de realizacion de las
pruebas no son confiables.
En cuanto a OpenMP 3.1, la afinidad se determino mediante variables de entorno,
que tambien ofrecen una funcionalidad limitada. En OpenMP 4.0 se introducen varia-
bles de entorno adicionales para controlar la afinidad, pero esta version no esta dispo-
nible aun en gcc.
Mas alla de futuras mejoras de las funcionalidades de afinidad de OpenMP y
OpenMPI, existen herramientas especıficas que pueden utilizarse para mapear uni-
88 Modelo de memoria distribuida y modelo hıbrido
dades de ejecucion a recursos especıficos, por ejemplo numactl.
No obstante, el esquema MPI-OpenMP implementado ofrece ventajas adicionales a
la capacidad de controlar el modo de ejecucion dentro de un nodo de memoria compar-
tida. En particular con esta opcion es posible explotar todos los recursos en un cluster
de calculo, lo cual no es posible utilizando solo OpenMP.
Capıtulo 8
Analisis de los programas
optimizados
“A naides tengas envidia,
Es muy triste el envidiar,
Cuando veas a otro ganar
A estorbarlo no te metas,
Cada lechon en su teta
Es el modo de mamar.”
— Martın Fierro, Jose Hernandez, 1872.
En los capıtulos anteriores se presentaron optimizaciones para aspectos puntuales
de los calculos de celda y de nucleo, y los resultados obtenidos fueron analizados por
separado para los distintos modulos. En este capıtulo se estudia el desempeno de las
versiones de los codigos CONDOR y CITVAP desarrolladas.
Desde el punto de vista de la optimizacion de estos programas, este analisis es
importante para determinar la eficiencia del codigo desarrollado y para detectar posibles
mejoras a futuro. En cuanto a los usuarios, los resultados obtenidos deben ser tenidos
en cuenta para utilizar los programas de forma adecuada, en particular en cuanto al
numero de procesadores usados.
8.1. Desempeno y analisis del codigo CONDOR
La version optimizada del codigo CONDOR en OpenMP contiene tres etapas pa-
ralelizadas: el calculo de flujos de respuesta en probabilidades de colision y en HRM,
el esquema multigrupo en HRM y los calculos de quemado en ambos metodos.
En la mayorıa de los casos resueltos en la etapa de diseno, los modulos de mayor
costo computacional son el de calculo de flujo de respuestas y el multigrupo. El peso
89
90 Analisis de los programas optimizados
4 8 12 16 20 24
Número de procesadores
0
2
4
6
8
10
Sp
eed
up
Nr
=312 / N =9
Nr
=1824 / N =13
Nr
=3600 / N =17
Figura 8.1: Speedup del codigo CONDOR paralelizado, en funcion del numero de procesadores,para HRM.
relativo de estos dos modulos depende del modelado del problema. En HRM, por ejem-
plo, aumentar el numero de celdas hace que el costo de calcular los flujos de respuesta
sea menor, y aumenta el tiempo necesario en el modulo multigrupo para converger las
corrientes de acople.
Por otro lado, en problemas pequenos con geometrıas simples el peso de los calculos
de quemado en el tiempo total puede ser apreciable. En geometrıas complejas, sin
embargo, estos calculos ocupan una fraccion del tiempo despreciable.
En consecuencia, en la mayorıa de los problemas se tiene una fraccion del progra-
ma relativamente alta que se ejecuta en paralelo. Esto impacta positivamente en la
eficiencia del codigo, teniendo en cuenta la Ley de Amdahl.
Sin embargo, al existir modulos secuenciales el speedup del programa necesariamente
sera menor que el de los modulos paralelizados, en mayor o menor medida dependien-
do del problema. En calculos de transporte sin quemado, por ejemplo, el peso del
tratamiento geometrico puede ser significativo. En problemas con quemado este peso
disminuye, ya que el ray tracing se realiza una sola vez al inicio de la corrida.
El calculo de las secciones eficaces macroscopicas y resonantes, la obtencion del
espectro crıtico y el input y output del programa, entre otros aspectos, contribuyen a
disminuir la fraccion paralela. El efecto de estos factores sera mas importante cuanto
mayor sea el numero de procesadores utilizados, tambien debido a la Ley de Amdahl.
8.1.1. Resultados para HRM
Para el metodo de respuesta heterogenea se obtuvo el speedup que se muestra en
la Figura 8.1. Los resultados corresponden a combustibles estandar MTR de placas
planas, de distintos tamanos y cantidades de celdas. Para los mismos problemas, la
eficiencia de la paralelizacion se muestra en la Figura 8.2.
8.1 Desempeno y analisis del codigo CONDOR 91
4 8 12 16 20 24
Número de procesadores
0
20
40
60
80
100
Eci
enci
a (
%)
Nr
=312 / N =9
Nr
=1824 / N =13
Nr
=3600 / N =17
Figura 8.2: Eficiencia para la paralelizacion de CONDOR en HRM.
Estos resultados deben ser tenidos en cuenta a la hora de elegir el numero de
procesadores para calcular un caso, ya que agregar recursos mas alla de un lımite hace
que el speedup comience a disminuir, con lo cual se desperdicia capacidad de calculo.
Esto es particularmente importante en el caso de un cluster de calculo, donde en
general se cuenta con un numero grande de procesadores. En este caso existe una ten-
dencia a calcular problemas con mas procesadores que los que en realidad se necesitan
para un speedup optimo. Luego, teniendo en cuenta que en un cluster los recursos son
compartidos por todos los usuarios, es conveniente utilizar el programa con criterio
para administrar la capacidad de calculo de la mejor forma.
8.1.2. Resultados para probabilidades de colision
El speedup obtenido para el metodo de probabilidades de colision se muestra en la
Figura 8.3. En este caso los resultados corresponden a un problema unidimensional en
geometrıa slab, con distintas discretizaciones. La eficiencia correspondiente puede verse
en la Figura 8.4.
8.1.3. Trabajo futuro
Los resultados obtenidos para la paralelizacion del codigo CONDOR son satisfacto-
rios dentro de los objetivos del presente trabajo. Sin embargo, existen diversos aspectos
en los cuales el programa puede seguir siendo optimizado utilizando procesamiento en
paralelo.
En primer lugar, la fraccion paralela del programa puede ser aumentada paraleli-
zando modulos adicionales, por mas que estos constituyan una pequena porcion del
calculo total en el caso secuencial. Esto es mas importante cuanto mayor sea el numero
de procesadores que se quieran utilizar, ya que, al acelerar las porciones de codigo pa-
92 Analisis de los programas optimizados
4 8 12 16 20 24
Número de procesadores
0
2
4
6
8
10S
peed
up
N = 200N = 400N = 600
Figura 8.3: Speedup para la paralelizacion de CONDOR, en el metodo de probabilidades decolision.
4 8 12 16 20 24
Número de procesadores
0
20
40
60
80
100
120
Eci
enci
a (
%)
N = 200N = 400N = 600
Figura 8.4: Eficiencia de la version de CONDOR paralelizada, para el metodo de probabilidadesde colision.
8.2 Desempeno y analisis del codigo CITVAP 93
ralelizadas, las porciones secuenciales constituyen el cuello de botella para el speedup.
El tratamiento geometrico, por ejemplo, ofrece posibilidades claras de paralelizacion,
como se analizo en el Capıtulo 3.
En segundo lugar, el modelo hıbrido MPI-OpenMP puede ser adoptado en otras
etapas del programa ademas del calculo de flujos de respuesta en HRM, permitiendo
aprovechar los recursos de arquitecturas mas diversas. Sin embargo, la implementacion
de este modelo en modulos con paralelismo menos evidente no es sencilla. Para el
esquema multigrupo, por ejemplo, se tiene interaccion constante entre los procesadores,
con lo cual el uso de mensajerıa puede ser excesivamente costoso.
Por otro lado, una tecnologıa que puede resultar util en algunos de los calculos de
CONDOR es la de las unidades de procesamiento graficas (Graphics Processing Unit,
GPU). Las GPUs son dispositivos masivamente paralelos, tıpicamente compuestos por
miles de hardware threads, con la capacidad de acelerar notablemente operaciones ma-
triciales y vectoriales. En la actualidad la utilizacion de esta tecnologıa para propositos
generales (GPGPU) esta en proceso de desarrollo, y por el momento presenta algunas
cuestiones operativas difıciles de resolver, en particular en cuanto al manejo de memoria
y a la portabilidad. Las aplicaciones para GPGPU mas maduras son CUDA, OpenCL
y OpenACC, y la version 4.0 de OpenMP.
Finalmente, cualquier desarrollo de software requiere de una etapa de realimenta-
cion a partir de su utilizacion en diferentes problemas. Esta fase de prueba es impor-
tante para optimizar el desempeno del codigo en terminos de velocidad y para detectar
errores de programacion. Durante la paralelizacion de CONDOR se calcularon distin-
tos casos para solucionar errores y para mejorar la performance, pero obviamente las
modificaciones implementadas deben ser puestas a prueba antes de que la version sea
estable.
8.2. Desempeno y analisis del codigo CITVAP
Para el codigo CITVAP solo se paralelizaron en este trabajo los calculos mono-
energeticos. A partir del analisis realizado en el Capıtulo 6, se concluyo que el metodo
iterativo optimo entre los analizados es el de Gauss-Seidel con paralelizacion por filas
en un esquema rojo-negro.
Este programa tambien realiza en paralelo el calculo de la fuente de scattering y
fision por malla y el del error en los flujos para evaluar la convergencia. Sin embargo, el
resto de los calculos asociados al esquema multigrupo, entre ellos la evaluacion del factor
de multiplicacion y la estimacion de los factores de extrapolacion y de sobrerrelajacion,
son ejecutados en forma secuencial.
94 Analisis de los programas optimizados
4 8 12 16 20 24
Número de procesadores
0
0,5
1
1,5
2
2,5
3
3,5
Sp
eed
up
120x100x12064x64x64
Figura 8.5: Speedup para la version de CITVAP paralelizada, para dos sistemas de distintotamano.
8.2.1. Resultados
El speedup obtenido para la version de CITVAP paralelizada se muestra en la Figura
8.5. Como puede verse, los resultados corresponden a una fraccion paralela significati-
vamente menor que para CONDOR.
8.2.2. Trabajo futuro
Al igual que para CONDOR, para CITVAP tambien es conveniente aumentar la
fraccion paralela para que el speedup alcanzable sea mayor. Uno de los aspectos a
analizar es la paralelizacion de las iteraciones exteriores por grupo, como se hizo en el
caso de CONDOR. En este ultimo caso esta opcion no resulto factible, pero es posible
que en CITVAP sı lo sea.
Por otro lado, en los calculos monoenergeticos tambien puede considerarse la im-
plementacion en GPU. Para los metodos utilizados, y en particular para el de Gauss-
Seidel, existen algoritmos orientados a su implementacion en GPU con muy buenos
resultados.
Capıtulo 9
Conclusiones
“All boundaries are conventions, waiting to be transcended.”
— Cloud Atlas, 2012.
A lo largo del presente trabajo se estudio la paralelizacion de distintos metodos
numericos asociados a la resolucion de la ecuacion de transporte de neutrones, en el
marco de la fısica de reactores.
De acuerdo con los objetivos planteados al inicio del trabajo, en primer lugar se
estudiaron algoritmos relacionados a los calculos de transporte.
Para la etapa de calculos de celda se decidio optimizar los metodos de probabilida-
des de colision y de respuesta heterogenea, ası como el esquema multigrupo asociado,
y metodos de evaluacion de quemado. Esta eleccion se debe a la amplia utilizacion
de estos metodos en programas orientados al diseno de reactores, y en particular en
CONDOR.
En cuanto a los calculos de nucleo, se decidio estudiar el metodo de difusion en
la aproximacion de diferencias finitas, y su resolucion numerica mediante esquemas
iterativos y metodos de aceleracion.
Esta fase incluyo la familiarizacion con los codigos CONDOR y CITVAP, primero
desde el punto de vista de su utilizacion en casos practicos y luego con orientacion a
su programacion.
Con el objetivo de tomar una decision acertada en cuanto a la forma de imple-
mentar los algoritmos optimizados, en la etapa inicial tambien se compararon distintas
herramientas de programacion en paralelo. Se decidio utilizar OpenMP, basicamente
por la flexibilidad de su modelo de ejecucion y por su eficiencia en arquitecturas de
memoria compartida. Esta decision fue retomada al final del trabajo, para estudiar el
modelo hıbrido MPI-OpenMP.
A continuacion, se analizaron los algoritmos elegidos para las etapas de celda y
de nucleo con vistas a su implementacion en paralelo. Para ello se consideraron las
ecuaciones y metodos iterativos concretos, para descomponer los algoritmos en tareas
95
96 Conclusiones
que puedan ser paralelizadas. Esta etapa se realizo primero de forma conceptual, y
luego teniendo en cuenta las herramientas particulares de programacion en paralelo,
en particular OpenMP.
Finalmente, se implementaron los algoritmos desarrollados en CONDOR y CIT-
VAP. De esta forma se compararon los desempenos de distintos metodos de paraleliza-
cion de cada etapa, y se identificaron los de mejores resultados. Por ultimo, se midio la
aceleracion de las versiones optimizadas de los codigos.
9.1. Calculos de celda
En primer lugar se estudio el calculo de flujos de respuesta, tanto en el metodo
de probabilidades de colision como en el de respuesta heterogenea. En el primer caso
implemento la paralelizacion por grupos y se concluyo que es necesaria la asignacion
dinamica de grupos, dado que de otra forma el metodo variacional utilizado produce
una perdida de eficiencia.
Para HRM los mejores resultados obtenidos corresponden al calculo en paralelo
por celdas y sin sincronizacion. En este caso se implemento tambien un algoritmo
combinando MPI y OpenMP, con paralelismo por grupos en MPI y por celdas en
OpenMP. Este modelo hıbrido aumenta la flexibilidad del programa para adaptarse a
diferentes arquitecturas, aunque no se observaron ventajas significativas respecto del
modelo con OpenMP en un nodo de memoria compartida.
En segundo lugar se estudio el esquema multigrupo para estos dos metodos de
transporte. Las consideraciones teoricas fueron realizadas para ambos, pero los algorit-
mos solo fueron implementados en CONDOR para HRM. Se considero la paralelizacion
por grupos tanto en las iteraciones exteriores como en las termicas, descartandose la
primera opcion por observarse un aumento excesivo de las iteraciones necesarias para
alcanzar la convergencia. Tambien se implemento la paralelizacion de las operaciones
matriciales asociadas a los calculos de transporte, y el algoritmo optimo se obtuvo
combinando esta opcion con la paralelizacion de las iteraciones termicas.
Por ultimo, se analizaron conceptualmente distintas formas de paralelizar el calculo
de ritmos de reaccion y la resolucion de las cadenas de quemado. En este caso se
implemento la opcion mas factible en cada caso.
Se obtuvieron resultados satisfactorios para la paralelizacion de CONDOR con
OpenMP, disminuyendo significativamente el tiempo de calculo. Para el caso anali-
zado en la Figura 8.1 para HRM, por ejemplo, se alcanzo un tiempo de calculo 8,5
veces menor que para el programa secuencial, en el caso mas costoso. Para el metodo
de probabilidad de colision tambien se obtuvo una reduccion a menos de 19del tiempo
de calculo secuencial, como puede verse en la Figura 8.3.
Ademas, se observo que la disminucion del tiempo de calculo es mayor cuanto mayor
9.2 Calculos de nucleo 97
sea el tamano del problema. Este resultado es positivo, ya que uno de los objetivos de la
programacion en paralelo es poder aumentar la complejidad de los sistemas que pueden
ser calculados en un tiempo factible para el usuario.
Estos resultados deben ser tenidos en cuenta por los usuarios de CONDOR, ya que
el numero de procesadores optimo para un problema dado dependera principalmente
de su tamano. En base a las Figuras 8.1 y 8.3, y a la experiencia que desarrollen a partir
del uso del programa, los usuarios pueden estimar esta cantidad optima de procesadores
para los modelos que utilicen.
9.2. Calculos de nucleo
Del analisis de las diversas formas de paralelizar el esquema iterativo de resolucion
de los flujos mediante el metodo de difusion en diferencias finitas, se determino que el
mas conveniente es el de paralelizacion rojo-negro por filas del metodo de Gauss-Seidel.
Mediante este algoritmo de paralelizacion se obtuvo una reduccion apreciable del
tiempo de calculo, como muestra la Figura 8.5. Para el caso mas costoso entre los
calculados se obtuvo una reduccion del tiempo de calculo a 13respecto del programa
secuencial. Para CITVAP tambien se observo que la disminucion del tiempo de calculo
es mayor cuanto mas grande sea el sistema.
Bibliografıa
[1] George I. Bell, Samuel Glasstone, Nuclear Reactor Theory, 1970. 3, 4, 5
[2] R.J.J. Stamm’ler and M.J. Abbate, Methods of Steady-state Reactor Physics in
Nuclear Design. 3, 5, 43, 56, 57, 58, 64, 65
[3] E.A. Villarino, CONDOR Calculation Package, PHYSOR, 2002. 5
[4] E.A. Villarino, R.J.J. Stamm’ler and A.A. Ferri, HELIOS: Angularly Dependent
Collision Probabilities, Nuclear Science and Engineering, Vol. 112, 1984. 5, 23,
25, 26, 27
[5] E.A. Villarino, Codigo de calculo neutronico CONDOR para la resolucion de ele-
mentos combustibles nucleares, Tesis de doctorado en ingenierıa nuclear, 1992. 5,
29, 57
[6] E.A. Villarino and R.J.J. Stamm’ler, The Heterogeneous Response Method in Slab
Geometry, Annals of nuclear energy, Vol.11, 1992.
[7] E.A. Villarino, Calculo de probabilidades de colision con dependencia angular. 23,
26
[8] E.A. Villarino, Improvement to the Calculation of Angular Dependent Collision
Probabilities.
[9] Oak Ridge National Laboratory, RSICC Computer Code Collection, CITATION-
LDI 2, Oak Ridge, Tennessee, 1999. 6
[10] Lawrence Livermore National Laboratory, High Performance Computing Training,
https://computing.llnl.gov/. 13, 14, 15, 20
[11] Ulrich Drepper, What Every Programmer Should Know About Memory, Red Hat,
Inc., 2007. 17
[12] Daniel J. Sorin, Mark D. Hill, David A. Wood, A Primer on Memory Consistency
and Cache Coherence, Synthesis Lectures on Computer Architecture.
99
100 Bibliografıa
[13] OpenMP Application Program Interface, OpenMP Architecture Review Board,
2011. 19
[14] Rolf Rabenseifner, Georg Hager, Gabriele Jost, Hybrid MPI and OpenMP Parallel
Programming Tutorial, SC13, 2013.
[15] Pavel Tvrdik, Solving Systems of Linear Equations in Parallel, Topics in Parallel
Computing, CS1221, 1999.
[16] Rudnei Dias da Cunha, Tim Hopkins, Parallel Overrelaxation Algorithms for Sys-
tems of Linear Equations.
[17] Zhenying Liu, Barbara Chapman, Tien-HsiungWeng, Oscar Hernandez, Improving
the Performance of OpenMP by Array Privatization, Department of Computer
Science, University of Houston.
[18] Jorn Hofhaus, Eric E. Van de Velde, Alternating-Direction Line-Relaxation Met-
hods on Multicomputers.
Agradecimientos
En primer lugar quiero agradecer a toda mi familia por el apoyo incondicional
y el amor que me brindan. A Almita por ser mi mas grande motivacion, y a Nati
por compartir sus dıas conmigo y aguantarse mis horas de trabajo. A mis papas por
acompanarme siempre, y a mis mejores amigos, mis hermanos Oti y Lu. Tambien a mis
abuelos, los mejores que alguien podrıa tener, y a todos mis tıos, en especial a Adriana
y a Horacio, que me recibieron con mucho carino cuando llegue a Bariloche.
Este trabajo es el cierre de una formacion que comenzo en el Jardın Misia Pepa
y termino en el Instituto Balseiro, pasando por el Instituto Austral y por el Instituto
Tecnologico de Buenos Aires. Por lo tanto, quiero agradecer a todas las personas que
me formaron desde chiquito. A mis senos del jardın y a mis maestras de la escuela, no
solo por la excelente educacion que me brindaron, si no tambien por los valores que
me inculcaron. Por ultimo a mis profesores en el Instituto Balseiro, por su compromiso
constante con la docencia, y a mi director, el Men, por las horas dedicadas a ayudarme
con este trabajo.
Para terminar, agradezco a cualquiera que se tome el tiempo de leer este trabajo,
ya sea porque le interese o porque elija trabajar en esta tematica. Es un poco mas largo
de lo que hubiera querido, pero espero que a alguien le sea de utilidad.
101