🔬 physics

OpenMP GPU Acceleration and Portability of TRIMEG-C1 for Electromagnetic Gyrokinetic Simulations in Tokamak Plasmas

Este artículo presenta una aceleración por GPU basada en OpenMP portátil del código de la girocinética electromagnética TRIMEG-C1 para arquitecturas NVIDIA y AMD, demostrando una aceleración de nueve veces en las APU AMD MI300A al tiempo que verifica la corrección de la implementación mediante simulaciones del modo de gradiente de temperatura iónica.

Autores originales: Giorgio Daneri, Zhixin Lu, Matthias Hoelzl, Luca Venerando Greco, Edoardo Carrà

Publicado 2026-06-24

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Giorgio Daneri, Zhixin Lu, Matthias Hoelzl, Luca Venerando Greco, Edoardo Carrà

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina un tokamak (un reactor de fusión nuclear en forma de dónut) como una cocina gigante y caótica donde se cocina un plasma supercaliente. Para entender cómo se comporta este plasma sin derretir la olla, los científicos utilizan un complejo programa informático llamado TRIMEG-C1. Este programa simula miles de millones de pequeñas e invisibles "partículas" (como micro-chefs) moviéndose, chocando entre sí y creando ondas de energía.

Durante mucho tiempo, esta simulación se ejecutó en procesadores estándar (CPU). Era precisa, pero también increíblemente lenta: como intentar cocinar un banquete para un millón de personas usando solo una única y muy lenta cuchara.

Este artículo trata sobre cómo darle a esa cuchara una mejora de superpoderes: las Unidades de Procesamiento Gráfico (GPU). Las GPU son los mismos chips que se encuentran en las consolas de videojuegos, pero están diseñadas para realizar miles de cálculos a la vez, lo que las hace perfectas para simular millones de partículas simultáneamente.

Esta es la historia de cómo los investigadores actualizaron el código, los obstáculos que enfrentaron y los resultados que lograron.

1. El desafío: Hablar dos lenguajes a la vez

Los investigadores querían que su código funcionara en dos tipos diferentes de "super-chefs" (GPUs):

NVIDIA: El jugador dominante en el mercado (como una marca de equipo de cocina famosa y costosa).
AMD: Un competidor emergente que es más barato y cada vez más común en las supercomputadoras.

¿El problema? El código estaba escrito en Fortran, un lenguaje antiguo pero potente para la ciencia. La mayoría de las herramientas para hacer que el código Fortran funcione en GPUs fueron diseñadas específicamente para NVIDIA. Si usaban esas herramientas, el código se rompería en las máquinas AMD. Si escribían versiones separadas para cada una, tendrían que mantener dos bases de código distintas, lo cual es una pesadilla para los desarrolladores de software.

La solución: Eligieron una herramienta llamada OpenMP. Piensa en OpenMP como un traductor universal. Permite a los científicos escribir un conjunto de instrucciones que diga: "Realiza este cálculo en la GPU", y la computadora se encarga de entender cómo traducir eso al lenguaje específico de un chip NVIDIA o AMD.

2. Los obstáculos: Caminos accidentados en la autopista

Aunque OpenMP era la elección correcta para la portabilidad, el camino no fue fluido. Los investigadores se encontraron con varios "baches" causados por el hecho de que los compiladores (los programas que traducen el código al lenguaje de máquina) para estas GPUs todavía estaban en su "infancia".

El problema de la "Caja Negra": El código dependía de una librería (una caja de herramientas prefabricada) para realizar cálculos complejos llamados "interpolación de B-spline". Esta librería utilizaba funciones avanzadas que los compiladores de GPU aún no comprendían del todo. Los investigadores tuvieron que reescribir manualmente partes de esta caja de herramientas para hacerla compatible, esencialmente reconstruyendo el motor mientras el coche todavía estaba en movimiento.
La fuga de memoria: En un tipo de GPU (NVIDIA), el código de repente se congelaba después de ejecutarse durante un tiempo. Resultó ser una "condición de carrera" (race condition): imagina a dos chefs intentando agarrar el mismo ingrediente al mismo tiempo, causando un bloqueo. Los investigadores tuvieron que encontrar y solucionar este error invisible.
La cocina "sobrepoblada": Cuando intentaban ejecutar demasiadas simulaciones a la vez en una sola GPU, la memoria se agotaba. Tuvieron que reorganizar la forma en que se almacenaban los datos (aplanando estructuras complejas en listas simples) para que la GPU no se viera abrumada.

3. Los resultados: Un demonio de la velocidad

Una vez corregidos los errores y optimizado el código, los resultados fueron impresionantes.

El aumento de velocidad: En una supercomputadora específica de AMD (el clúster "Viper"), la nueva versión de la simulación de partículas por GPU fue 9 veces más rápida que la antigua versión de CPU. En una máquina NVIDIA de alto rendimiento (el clúster "Pitagora"), también fue significativamente más rápida.
La prueba de "Sobresuscripción": Normalmente, quieres que una GPU maneje una sola tarea. Pero en la supercomputación real, los recursos son escasos. Los investigadores probaron qué sucede si obligan a múltiples tareas a compartir una sola GPU. Sorprendentemente, el código resistió bien, demostrando que aún puede ser eficiente incluso cuando la GPU está haciendo malabares con múltiples trabajos.
Verificación de precisión: La velocidad es inútil si los resultados son erróneos. Para demostrar que la versión de GPU era confiable, ejecutaron dos casos de prueba famosos:
1. El Caso del Ciclón: Un modelo simplificado de inestabilidad de plasma. Los resultados de la GPU coincidieron con los de la CPU casi perfectamente (dentro de un margen de error minúsculo, debido principalmente a la naturaleza aleatoria de la simulación).
2. El Caso TCV: Un modelo más realista y complejo de un reactor de fusión del mundo real. Nuevamente, la versión de GPU reprodujo la física correctamente, capturando el crecimiento de las ondas de energía y la forma del plasma.

4. La conclusión

El artículo concluye que construyeron con éxito una versión portable de un código de física complejo. Es como crear un control remoto universal que funciona tanto en televisores Samsung como LG sin necesidad de comprar dos controles diferentes.

Lo que lograron: Hicieron que una simulación lenta basada en CPU corra 9 veces más rápido en GPUs modernas, y funciona tanto en las principales marcas de hardware (NVIDIA y AMD).
Lo que no hicieron: No inventaron nueva física ni resolvieron la crisis energética todavía. Simplemente demostraron que la herramienta utilizada para estudiar la fusión es ahora mucho más rápida y flexible.

En resumen, los investigadores tomaron una simulación científica pesada y lenta, le dieron un turbocompresor (GPUs) y aseguraron que ese turbocompresor funcione en cualquier marca de motor, allanando el camino para estudios más rápidos y detallados sobre cómo podríamos, algún día, aprovechar la energía de las estrellas.

Resumen Técnico: Aceleración por GPU con OpenMP y Portabilidad de TRIMEG-C1 para Simulaciones de Girocinética Electromagnética

Planteamiento del Problema
El código TRIMEG-C1 es un resolvedor de partículas en celda (PIC) de malla triangular basado en la técnica de elementos finitos para simular inestabilidades electromagnéticas en plasmas de tokamaks. Utiliza un método de elementos finitos de orden superior $C^1$ para capturar una física precisa con una resolución de malla menor en comparación con los métodos $C^0$ . Sin embargo, a medida que las supercomputadoras modernas dependen cada vez más de arquitecturas heterogéneas, el código enfrenta el desafío de escalar hacia simulaciones multiescala que involucran escalas electrónicas pequeñas y escalas de tiempo de transporte. Aunque el offloading de GPU ofrece un potencial de aceleración significativo para los códigos PIC debido a su alta paralelización, los enfoques existentes carecen de robustez en términos de portabilidad. OpenACC, utilizado en códigos como GEM y ORB5, cuenta con un buen soporte en arquitecturas NVIDIA, pero carece de un soporte sólido para las GPUs AMD, las cuales son cada vez más prevalentes en los clústeres de Computación de Alto Rendimiento (HPC) (por ejemplo, el clúster Viper de la Instalación de Datos y Computación Max Planck). Por el contrario, CUDA o HIP requieren una reescritura significativa del código o una traducción manual de kernels. El problema principal abordado es lograr una implementación acelerada y portátil de TRIMEG-C1 tanto en arquitecturas de GPU NVIDIA como AMD sin comprometer la estructura existente del código en Fortran ni requerir una duplicación extensiva del código.

Metodología
Los autores seleccionaron el marco de trabajo de offloading de OpenMP como la estrategia de aceleración. Esta elección fue impulsada por su capacidad para soportar GPUs NVIDIA y AMD dentro de un código Fortran unificado, minimizando los cambios estructurales y la divergencia del código. El proceso de portabilidad se centró en los componentes computacionalmente más intensivos: el kernel del empujador de partículas (particle pusher) y las operaciones de rejilla a partícula (G2P) (incluyendo el tratamiento de pullback, el cálculo de densidad y la interpolación de la función de distribución).

Los pasos metodológicos clave incluyeron:

Adaptación de Kernels: El empujador de partículas, que evoluciona partículas de marcador de forma independiente, fue envuelto en una única región grande de target de OpenMP para maximizar el paralelismo. Esto requirió refactorizar el código para asegurar que todas las funciones llamadas, incluyendo aquellas de una biblioteca externa de interpolación de B-spline, fueran invocables desde el dispositivo (device-callable).
Soluciones de Trabajo para Limitaciones del Compilador: Se dedicó un esfuerzo significativo a superar las limitaciones de los compiladores amdflang y nvfortran respecto al offloading de OpenMP. Los desafíos específicos incluyeron:
- Polimorfismo y Procedimientos Vinculados a Tipos: Ningún compilador soporta plenamente estas características en código de dispositivo. Los autores modificaron el código para utilizar declaraciones de type no polimórficas en lugar de class donde fue necesario, y evitaron las vinculaciones de procedimientos de tipos en la biblioteca de B-spline.
- Gestión de Memoria: Para manejar arreglos dinámicos que imitan el std::vector de C++, los autores aplanaron los diseños de datos de Estructura de Arreglos (AoS) en arreglos unidimensionales para evitar problemas complejos de mapeo de punteros en tiempo de ejecución y errores de Fuera de Memoria (OOM) en las APUs AMD MI300A.
- Condiciones de Carrera: Una condición de carrera en el uso de arreglos temporales compartidos de la biblioteca B-spline se resolvió cambiando a arreglos automáticos declarados localmente.
- Optimización del Rendimiento: En las GPUs NVIDIA, el kernel sufrió inicialmente una degradación del rendimiento debido a la asignación de arreglos temporales en tiempo de ejecución. Esto se mitigó cambiando a arreglos de tamaño fijo en tiempo de compilación para funciones específicas, un cambio aplicado condicionalmente según la arquitectura objetivo.
Paralelización Híbrida: El estudio evaluó una estrategia de paralelización híbrida MPI-OpenMP, evaluando el rendimiento bajo sobre suscripción de recursos (ejecutando múltiples procesos MPI por GPU) para determinar la viabilidad en simulaciones a gran escala donde la asignación de nodos es limitada.

Contribuciones Clave

Implementación de GPU Portátil: El artículo presenta la primera portabilidad exitosa del código TRIMEG-C1 a arquitectas de GPU tanto NVIDIA como AMD utilizando OpenMP, permitiendo la ejecución en diversos sistemas de HPC (por ejemplo, Viper, Raven, Pitagora).
Resolución de Desafíos Específicos del Compilador: El trabajo detalla diversas soluciones de trabajo para las limitaciones de los compiladores Fortran en el offloading de OpenMP, particularmente en lo que respecta al polimorfismo, la asignación dinámica de memoria y la integración de bibliotecas externas.
Evaluación de Rendimiento: Se realizaron evaluaciones de rendimiento exhaustivas en múltiples clústeres (AMD MI300A, NVIDIA A100, NVIDIA H100) y tamaños de problema, analizando tanto las aceleraciones de kernels individuales como la escalabilidad fuerte.
Validación: La corrección de la implementación de GPU fue verificada rigurosamente contra los resultados de CPU utilizando casos de prueba estándar, asegurando que el proceso de portabilidad no introdujera inexactitudes físicas.

Resultados

Aceleración (Speedup): Para un tamaño de problema realista de $32 \times 10^6$ partículas de marcador en un nodo completo, el kernel del empujador de partículas logró una aceleración de aproximadamente 9x tanto en la AMD MI300A (Viper) como en la NVIDIA H100 (Pitagora) comparado con la implementación más rápida de solo CPU (AMD EPYC 9754).
Sobresuscripción: El estudio encontró que, si bien la sobresuscripción de recursos de GPU (aumentar los procesos MPI por nodo) reduce la aceleración de los kernels individuales debido a la serialización y el cambio de contexto, el enfoque híbrido sigue siendo viable. Sin embargo, la aceleración general del código depende fuertmente del tamaño de la carga de trabajo; para cargas de trabajo pequeñas ( $10^6$ partículas), la ventaja disminuye significativamente al comparar contra un nodo de solo CPU debido a la sobrecarga de transferencia de datos y la limitada intensidad aritmética.
Escalabilidad: El análisis de escalabilidad fuerte demostró que el código acelerado por GPU escala bien a través de múltiples nodos, aunque la ganancia de rendimiento general es marginal cuando la fase de partícula-a-rejilla (P2G) domina, ya que esta fase se beneficia significativamente del alto conteo de núcleos de los nodos de solo CPU.
Corrección: Las comparaciones de las simulaciones del modo de Gradiente de Temperatura de Iones (ITG) tanto para el caso base de Ciclo como para el caso TCV-X21 mostraron una buena concordancia entre las versiones de CPU y GPU. Las tasas de crecimiento de energía difirieron en menos del 3% para el caso de Ciclo y generalmente por debajo del 10% para el caso TCV-X21 (con mayores desviaciones en números de modo toroidal más altos). Las estructuras de modo bidimensionales también se preservaron.
Perfilado (Profiling): El perfilado en las GPUs AMD reveló una alta presión de registros que limita las Unidades de Cómputo (CU) activas y una baja utilización de la Memoria de Datos Local (LDS), atribuido a la incapacidad de la API de OpenMP para gestionar explícitamente la memoria compartida.

Significación y Reivindicaciones
El artículo afirma que la portabilidad exitosa de TRIMEG-C1 a arquitecturas de GPU utilizando OpenMP proporciona una base computacional portátil para futuros estudios de física a gran escala. Los autores enfatizan que, si bien la implementación requirió una reestructuración significativa del código para navegar las limitaciones de los compiladores, el código resultante permite la simulación de inestabilidades electromagnéticas en diversas plataformas de hardware sin necesidad de mantener bases de código separadas para diferentes proveedores.

El trabajo establece que el empujador de partículas es el candidato principal para la aceleración por GPU, produciendo aceleraciones sustanciales para conteos grandes de partículas. Sin embargo, los autores señalan modestamente que el rendimiento general del código está actualmente limitado por otras fases (como la resolución de ecuaciones de campo y las operaciones P2G) que son menos propensas a la aceleración por GPU o que se benefician más del paralelismo de CPU. Por consiguiente, el pleno potencial de la aceleración por GPU se alcanza en simulaciones con grandes cantidades de partículas donde el empujador domina el tiempo de ejecución.

El trabajo futuro, tal como lo describen los autores, incluye la integración de resolvedores habilitados para GPU vía PETSc, la exploración de un port a C++ de TRIMEG para mejorar la eficiencia del offloading y reducir el esfuerzo de portabilidad, y la implementación del offloading de GPU para las operaciones de partícula-a-rejilla. El actual TRIMEG-C1 acelerado por GPU se posiciona como un paso intermedio hacia estudios de turbulencia multiescala e investigaciones de la transportación de plasma en configuraciones de tokamak divertidos realistas.

1. El desafío: Hablar dos lenguajes a la vez

2. Los obstáculos: Caminos accidentados en la autopista

3. Los resultados: Un demonio de la velocidad

4. La conclusión

Más como este