Accelerating the Particle-In-Cell code ECsim with OpenACC

Este trabajo presenta la aceleración del código de partículas en celda ECsim mediante OpenACC para arquitecturas exaescala, logrando en el sistema Leonardo un aumento de velocidad de 5 veces, una reducción del consumo energético de 3 veces y una eficiencia de escalado del 70% al 78% en múltiples GPUs.

Lo esencial

¡Hola! Vamos a desglosar este artículo científico de una manera divertida y sencilla. Imagina que el código ECsim es como un chef extremadamente meticuloso que cocina un plato llamado "Plasma".

¿Qué es el "Plasma" y por qué es difícil de cocinar?

El plasma es ese estado de la materia donde los átomos se rompen y los electrones bailan libremente (como en un rayo o en el sol). Para entender cómo se mueven, los científicos usan un método llamado PIC (Partículas en Celda).

Imagina que tienes una cancha de fútbol llena de miles de jugadores (las partículas) y una cuadrícula invisible dibujada en el césped (la red o "grid").

1. El problema: Los jugadores corren muy rápido y chocan entre sí. Para predecir dónde estarán en el siguiente segundo, el chef debe calcular:
   • Dónde están los jugadores.
   • Qué fuerzas eléctricas y magnéticas sienten.
   • Cómo esas fuerzas empujan a los jugadores.
   • Y luego, cómo los jugadores cambian esas fuerzas en la cuadrícula.

Hacer esto para millones de partículas es como intentar calcular el movimiento de cada gota de lluvia en una tormenta usando una calculadora de bolsillo. ¡Tardaría años!

El Gran Cambio: De la "Cocina de leña" a la "Cocina de Alta Velocidad"

Antes, este chef (el código ECsim) trabajaba solo con CPU (el cerebro tradicional de la computadora). Era como si tuviera 32 manos trabajando muy rápido, pero seguía siendo un proceso lineal y lento.

Los autores de este paper decidieron darle al chef aceleradores GPU (tarjetas gráficas). Piensa en las GPU no como un cerebro, sino como un ejército de miles de robots pequeños que pueden hacer tareas simples en paralelo.

El truco mágico (OpenACC):
Normalmente, cambiar una receta para que la hagan robots requiere reescribir todo el libro de cocina de cero. Pero los autores usaron un método llamado OpenACC.

• La analogía: Imagina que tienes un libro de instrucciones antiguo. En lugar de reescribir todo, simplemente pegas etiquetas adhesivas (llamadas "pragmas") en ciertas páginas que dicen: "¡Oye, robots! Haced esto vosotros ahora".
• Esto permitió acelerar el código sin tener que destruir la estructura original. ¡Fue como darle un turbo al coche sin cambiar el motor!

Los Resultados: ¡Velocidad y Ahorro de Energía!

En la supercomputadora Leonardo (una bestia italiana), probaron este nuevo sistema:

1. Velocidad (El "5x"):
   El código acelerado por los robots (GPU) fue 5 veces más rápido que el chef humano (CPU).

   • Analogía: Si antes tardabas 5 horas en hacer la cena, ahora tardas solo 1 hora.

2. Energía (El "3x"):
   No solo fue más rápido, sino que consumió 3 veces menos electricidad.

   • Analogía: Es como cambiar de conducir un camión gigante (CPU) a una moto eléctrica súper eficiente (GPU) para el mismo viaje. Los robots hacen el trabajo pesado de forma más eficiente.

¿Por qué funciona tan bien?

El artículo explica que el código tiene tres partes principales:

1. Recopilar datos (Moment Gathering): Contar cuántos jugadores hay en cada zona de la cancha.
2. Resolver las fuerzas (Field Solver): Calcular cómo se empujan los jugadores.
3. Mover a los jugadores (Particle Mover): Actualizar sus posiciones.

Los científicos descubrieron que la parte de "Recopilar datos" era el cuello de botella (el 76% del tiempo). Al ponerle los robots (GPU) a esa tarea específica, el tiempo se desplomó.

Además, probaron el código en diferentes generaciones de tarjetas gráficas (desde la V100 hasta la nueva GH200).

• La GH200 es especial porque tiene una memoria unificada.
• Analogía: Imagina que el chef (CPU) y los robots (GPU) antes tenían que pasarle los ingredientes por una puerta lenta (PCIe). En la GH200, ¡se sientan a la misma mesa! Ya no hay que pasar los ingredientes, los tienen todos juntos. Esto hizo que el código fuera aún más rápido.

Escalabilidad: ¿Funciona si somos más?

Hicieron pruebas con muchas computadoras a la vez (hasta 1024 GPUs).

• Escalado Fuerte: Si tienes un problema fijo (una receta fija), ¿cuánto más rápido es si tienes más cocineros? Sí, funciona muy bien hasta cierto punto.
• Escalado Débil: Si tienes más cocineros, ¿puedes cocinar una cena más grande en el mismo tiempo? ¡Sí! El código mantiene su eficiencia incluso con miles de robots trabajando juntos.

Conclusión

Este trabajo es como un puente. Muestra que no necesitas ser un programador experto en robótica para usar supercomputadoras modernas. Con unas pocas "etiquetas" (OpenACC), puedes tomar un código antiguo y hacerlo volar en las máquinas más potentes del mundo, ahorrando tiempo y energía.

En resumen: Transformaron un código de cocina lento en una operación de alta velocidad usando robots, sin tener que reescribir todo el libro de recetas, logrando que la ciencia del plasma avance mucho más rápido hacia el futuro.

Resumen técnico

Resumen Técnico: Aceleración del código PIC ECsim con OpenACC

1. El Problema

El método Particle-In-Cell (PIC) es fundamental en la física de plasmas para modelar efectos cinéticos y interacciones complejas. Sin embargo, los algoritmos PIC tradicionales enfrentan desafíos significativos:

• Restricciones de estabilidad: Los esquemas explícitos requieren pasos de tiempo y espaciales muy pequeños para resolver las escalas más pequeñas, lo que incrementa drásticamente el costo computacional en escenarios multiescala.
• Costo de los esquemas implícitos: Los enfoques totalmente implícitos, aunque más estables, requieren resolver sistemas de ecuaciones no lineales acopladas, lo que eleva el costo computacional y puede generar problemas de convergencia.
• Limitaciones de los esquemas semi-implícitos existentes: Aunque los esquemas semi-implícitos (como el método de momentos implícitos) ofrecen un compromiso, a menudo sufren de "enfriamiento numérico" artificial, obligando a usar pasos de tiempo aún más pequeños para mantener la precisión.
• Desafío de la arquitectura Exascale: Preparar códigos científicos como ECsim (que utiliza un esquema semi-implícito que conserva la energía hasta la precisión de la máquina) para arquitecturas heterogéneas de exascale (con aceleradores GPU) requiere estrategias que no comprometan la estructura del código ni su corrección numérica.

2. Metodología

Los autores implementaron una estrategia de aceleración basada en directivas (OpenACC) para portar el código ECsim a GPUs NVIDIA, minimizando la reestructuración del código base original (escrito en C/C++ con MPI).

• Estrategia de Aceleración:
  • Se identificaron los tres bloques principales del código: recolección de momentos (moment gathering), solucionador de campos y movimiento de partículas (particle mover).
  • Se aplicaron directivas #pragma acc parallel loop para paralelizar los bucles sobre las partículas.
  • Optimizaciones de Memoria: Se aplanaron arrays multidimensionales para mejorar la localidad de datos. Se utilizaron variables escalares en lugar de arrays bidimensionales para matrices de rotación.
  • Gestión de Concurrencia: Se empleó #pragma acc atomic update para evitar condiciones de carrera al acumular contribuciones de partículas a la red (corrientes y matrices de masa), ya que las reducciones basadas en arrays presentaban limitaciones con el compilador.
  • Gestión de Memoria: Se utilizó memoria gestionada (managed memory) combinada con cudaMemPrefetchAsync para optimizar la migración de datos entre CPU y GPU, evitando copias profundas costosas y reduciendo fallos de página.
  • Validación: Se compararon los resultados de energía de campos eléctricos y magnéticos contra la versión de referencia en CPU, confirmando una coincidencia numérica perfecta.

3. Contribuciones Clave

• Portabilidad y Eficiencia: Demostraron que OpenACC permite acelerar un código científico complejo con modificaciones mínimas, manteniendo la estructura original y logrando un alto rendimiento.
• Validación Rigurosa: Se verificó la corrección numérica del código acelerado frente a casos de prueba estándar (inestabilidad de dos corrientes y filamentación de corriente).
• Análisis de Energía y Tiempo: Se realizó una evaluación exhaustiva no solo del time-to-solution, sino también del energy-to-solution, midiendo el consumo energético real de CPU y GPU.
• Comparativa de Arquitecturas: Se evaluó el rendimiento en cuatro generaciones de GPUs NVIDIA (V100, A100, H100 y GH200), destacando el impacto de la memoria unificada.

4. Resultados

Las pruebas se realizaron en el sistema pre-exascale Leonardo (CINECA, Italia) y otras plataformas con GPUs NVIDIA.

• Rendimiento (Speedup):

  • En una comparación nodo a nodo (32 núcleos CPU vs. 4 GPUs A100), el código acelerado logró un speedup de 5× en el tiempo total de solución.
  • El bloque de "recolección de momentos" (que consumía el 76% del tiempo en CPU) se aceleró 15×, reduciendo su contribución al tiempo total al 23%.
  • El solucionador de campos y las operaciones de I/O se aceleraron aproximadamente 2×.

• Eficiencia Energética:

  • Se observó una reducción del 3× en el consumo de energía total (de ~1295 kJ en CPU a ~415 kJ en CPU+GPU).
  • Esto se debe a la combinación de una menor duración de la simulación y la mayor eficiencia energética de las GPUs para estos kernels específicos.

• Escalabilidad:

  • Escalado Fuerte: Se alcanzó una eficiencia del 70% hasta 64 GPUs (16 nodos). Para mantener eficiencias superiores al 70% en escalas mayores (hasta 1024 GPUs), fue necesario aumentar el tamaño de la malla (problema), logrando un 83% de eficiencia en 1024 GPUs con una malla de 6720×6720.
  • Escalado Débil: El código mantuvo una eficiencia del 78% hasta 1024 GPUs (256 nodos), demostrando que los sobrecostos de comunicación y acceso a memoria crecen moderadamente.

• Impacto de la Arquitectura (GH200):

  • Las pruebas en la arquitectura GH200 (con memoria unificada CPU-GPU vía NVLink-C2C) mostraron mejoras significativas, especialmente en el kernel de movimiento de partículas (2× más rápido que V100) y en la recolección de momentos (12.79× más rápido que V100). La memoria unificada eliminó los costos de transferencia PCIe, reduciendo la latencia.

5. Significado e Impacto

Este trabajo es un paso crucial hacia la simulación de plasmas multiescala en arquitecturas de exascale.

• Viabilidad de OpenACC: Confirma que las directivas de aceleración son una vía práctica y madura para preparar códigos legacy para GPUs sin la necesidad de una reescritura completa en CUDA o SYCL, lo cual sería intrusivo y costoso en tiempo de desarrollo.
• Eficiencia Operativa: La reducción del 3× en el consumo energético es vital para la sostenibilidad de los centros de supercomputación y para permitir simulaciones más largas o complejas dentro de los mismos presupuestos energéticos.
• Futuro: El código ECsim acelerado está listo para aprovechar los recursos de los futuros superordenadores europeos (como Jupiter), y los autores planean desarrollar una implementación nativa en CUDA para comparar y refinar aún más el rendimiento, así como explorar el uso de autómatas celulares para optimizaciones adicionales.

En resumen, el artículo demuestra que es posible modernizar exitosamente un código de física de plasmas de alta fidelidad para la era exascale, logrando ganancias masivas en velocidad y eficiencia energética mediante un enfoque de aceleración pragmático y minimamente intrusivo.