A principios de agosto se publicó un trabajo científico con la participación de Cristian Giuppone, Dr. en Astronomía de la UNC y usuario del CCAD.
Mario Sucerquia, Jaime A. Alvarado-Montes, Jorge I. Zuluaga, Nicolás Cuello, Cristian Giuppone, Ploonets: formation, evolution, and detectability of tidally detached exomoons, Monthly Notices of the Royal Astronomical Society, , stz2110, https://doi.org/10.1093/mnras/stz2110
Parte de este trabajo involucró el uso de los recursos del CCAD, en particular de Mulatona. Aprovechando que el trabajo recibió mucha divulgación por parte de los medios (Comunicación OAC, Clarín, Canal U, Canal 12), entrevistamos a Cristian para que nos cuente el costado HPC del paper.
CCAD: ¿El software ya estaba hecho, vos lo adaptaste o es propio?
Cristian Giuppone: Es un soft que voy customizando de acuerdo a lo que quiera estudiar. Es básicamente un integrador n-cuerpos al que se le pueden agregar fuerzas adicionales para modelar procesos físicos y pedirle distintos tipos de salidas variando planos de referencia y orígenes de coordenadas. La versión original del código es desarrollada y mantenida por el fundador del grupo, el Dr. Cristian Beaugé, y es utilizada por todo el Grupo de Sistemas Planetarios del OAC, así como otros investigadores que han estado en contacto o colaborando con nosotros. Es el mismo código que utilizo en mi máquina personal, por lo cual puedo hacer infinitas pruebas y una vez que está ajustado/optimizado utilizo los clusters disponibles. Está escrito en Fortran, tiene unas 4000 líneas y no posee dependencias externas. He utilizado otros códigos reconocidos a nivel mundial como REBOUND o Mercury, pero me siento más a gusto modificando o acondicionando el propio.
CCAD: ¿Cómo se compara el software que usás con el resto en términos de desempeño, precisión y tipo de simulaciones que podés hacer?
CG: En términos de desempeño, para simulaciones individuales se comporta de la misma manera. Existen módulos que no son libres de REBOUND o Mercury que trabajan más eficientemente efectos de marea, o evolución estelar (es decir acoplan parámetros físicos). Tenemos un Proyecto SECyT-UNC que apunta en esa dirección para mejorar el código y tenemos una implementación de efectos de mareas con un modelo autoconsistente que aún está en desarrollo (Cristian Beaugé). En términos de paralelización nos hemos encontrado con dificultades mayores que requieren alto conocimiento de lenguaje de alto nivel y MPI que requieren dedicación exclusiva al problema computacional. De hecho, hace unos años incursionamos con otros códigos que calculan n-cuerpos para millones de partículas, con el objeto de estudiar la dinámica en los anillos de Saturno. No obstante nunca llegamos a hacer pruebas definitivas en ninguno de los clusters del CCAD. Actualmente la alumna de Doctorado, Lic. Mondino decidió emigrar a la Universidad de Oulu (Finlandia), cambiando el enfoque de su tesis para modificar acordemente el código REBOUND tal que reproduzca efectos físicos conocidos.
CCAD: ¿De qué manera paralelizaron?
CG: La paralelización la desarrollé cuando estuve realizando mi postdoc durante 2011, en la Universidad de Aveiro (Portugal). Había recursos disponibles en la universidad, pero el software hasta esa época no funcionaba en paralelo. Dada mi formación, me costó bastante, pero lo tomé como un desafío personal. En dicho posdoc utilicé unos ejemplos que me pasaron de códigos en MPI, para utilizar las prestaciones del código en paralelo y también incluí indicadores de estructuras de resonancias como variaciones de acciones y ángulos.
Generalmente construyo mapas dinámicos para analizar estructuras de resonancias en sistemas de n-cuerpos por lo cual, cada punto en mi mapa dinámico es una corrida independiente del código. En los problemas que generalmente estudiamos, el número de cuerpos es reducido (3 a 7) y nos interesa mucho la posición exacta de cada órbita sin suavizar los potenciales durante cientos de miles de períodos del sistema. En la Universidad de Aveiro el sistema de distribución de tareas era muy interesante: cada facultad aportante de dinero para el cluster tenía asignado un proporcional de nodos a su disposición siempre; si los nodos estaban ociosos eran liberados para todos los usuarios. En el caso de que todos los nodos de un grupo estuvieran siendo utilizados por otro grupo y se necesitaba hacer uso, se recibía un email del administrador que solicitaba anular los trabajos y uno tenía una ventana de tiempo para hacerlo. De esta forma el usuario no debía esperar más de unas pocas horas para utilizar el cluster. También con esta forma de trabajo aprendí a ser solidario con el uso de los recursos y no acapararlos todos para mí, cuando sé que hay otras personas esperando para sus simulaciones.
CCAD: ¿Cuál es la Eficiencia Paralela?
CG: El nivel de eficiencia es lineal con la cantidad de nodos (parallel efficiency = 1), porque cada nodo corre su propia versión del programa. Si utilizo 56 nodos, ¡la tarea es 56 veces más rápida! Hay que tener mucho cuidado de meterle presión al filesystem, porque podemos escribir demasiados archivos o abrir demasiados archivos a la vez y de esa forma saturar el ancho de banda de discos o incluso llenarlos afectando a todos los otros usuarios del cluster. Este tipo de problemas es recurrente en usuarios que no prestan demasiada atención a esos detalles.
CCAD: ¿Qué compilador y opciones de optimización usás?
CG: A ver, he encontrado muy buenas prestaciones compilando con
mpif90 -o -O3 ejecutable simulacion.f
es decir el wrapper MPI del compilador GNU Fortran. En un principio utilizaba mpifortran de Intel pero luego me mudé porque no conseguía una versión para correr en mis computadoras personales. Una mejora en prestaciones de una 10 veces para integradores con paso adaptativo (tanto BS como RK7/8) es cuantificable con la opción -O3. La integración de órbitas que poseen mucho caos no tienen los mismos resultados con -O3 que sin esa opción, pero como estudio espacios de parámetros y dinámica global del sistema, es algo que incluso cambiando de servidor o de computadora, arrojará resultados diferentes.
CCAD: ¿Cuál fue aproximadamente la cantidad de horas/core de cálculo en total?
CG: Normalmente mis tareas corren unas 8 a 12 hs en unos 24 a 56 nodos. La labor de investigación requiere estudiar distintos planos representativos, muchas veces sólo una reducida parte de los cálculos se ve reflejada en los resultados obtenidos.
Durante el último año y medio he corrido 250000 horas/core en los clusters Mulatona y Clemente (cluster interno del IATE), de los cuales un 20% son del paper de Ploonets y hay un alto porcentaje de otros papers que salieron este último tiempo como órbitas polares alrededor de binarias o estudio de la evolución de los satélites de Saturno.
CCAD: ¿Mucha RAM o poca RAM?
CG: La cantidad de memoria RAM es de unos 2 GiB a la hora de compilar. La compilación dura unos 30 segundos. Luego el uso de RAM en la simulación es despreciable.
CCAD: ¿Usaron bibliotecas? ¿Cuáles?
CG: Algunas subrutinas del Numerical Recipes son utilizadas, pero no bibliotecas.
CCAD: ¿Cómo te sentís corriendo en CCAD y cómo se compara con otras experiencias de uso de recursos de HPC?
CG: Tengo muy buena relación con Darío Graña que me ha ayudado muchas veces con los inconvenientes y otra gente de IATE que tiene mucho mejor conocimiento en paralelización (Dante Paz, Marcelo Lares, Federico Stasyszyn). En otros clusters suelen tener ejemplos de programas para que los usuarios indaguen un poco y ejemplos de los scripts para ejecutar tal cual están subidos. De hecho muchas veces me ha pasado que actualizan los sistemas, nos dejan sin alguna biblioteca que anda y renegamos un tiempo hasta que descubrimos como solucionarlo. Pero siempre he encontrado buena disposición del equipo de CCAD y aprecio el trabajo que hace todo el equipo.
Creo que falta información para los usuarios de que es efectivo y que no, corriendo en un cluster del tamaño de los que tenemos. Obvio que me gustaría hacer una simulación de la evolución del universo o de la dinámica de partículas en anillos de Saturno por largo tiempo, pero soy consciente de las limitaciones propias. A veces una computadora personal con buenas prestaciones puede realizar el trabajo. A veces el sistema es tan complejo que la capacidad de CCAD no alcanza, y sería bueno buscar convenios internacionales que permitan utilizar computadoras más potentes.
CCAD: Muchas gracias Cristian por la predisposición para divulgar el uso del HPC y nuestros equipos.
CG: Gracias a ustedes y les dejo una breve explicación de que objetos simulamos y que buscamos.
Análisis de algunas de las simulaciones de Ploonets
Pensemos en un sistema con marco de referencia en el planeta como Neptuno, ubicado a 0.5 unidades astronómicas de su estrella el Sol. Para cada uno de estos sistemas generaremos condiciones iniciales con una lunita alrededor de la masa de Titán a distintas distancias de su planeta (eje x) y distintas orientaciones respecto a la posición de la estrella (eje y). El esquema básico de nuestro estudio sería
La imagen que continúa representa cada una de las condiciones iniciales que exploramos
Esta distribución de condiciones iniciales implica que nuestro programa se ejecutará 14600 veces. Cada integración demora unos 40 segundos en ejecutarse para monitorear el comportamiento de cada sistema por unas 100000 veces el período orbital del sistema. Para obtener todo el mapa dinámico necesitamos unas 162 horas. Si ejecutamos en 48 nodos, sólo esperaremos 3.4 horas para completar las corridas.
En cada integración se analiza la variación de la órbita de la lunita, su configuración final y muchos otros cuantificadores de órbita. Es así que se construyen los mapas dinámicos de las figuras siguientes:
La primera usa como escala de color la variación de la excentricidad de la luna durante la integración. Aquellas órbitas más regulares son las que tienen ese indicador menor a 1. En el caso de la segunda imagen, se usan las mismas integraciones, pero la escala de color corresponde al tipo de configuración que se obtuvo: el color 19 indica órbitas estables alrededor del planeta, el color celeste indica aquellas lunas que escaparon del sistema y el color rojo es una mezcla de 2 tipos de configuraciones: aquellas que alternativamente orbitan al planeta o a la estrella y aquellas que se convierten en ploonets.
Refrencias
Paper ploonets: [pago] [libre]
Paper orbitas polares: [pago] [libre]
