Simulación distribuida y cosimulación: hay margen (y necesidad) de mejora

Una de las tareas de la ciencia y la ingeniería, y ciertamente una tarea importante, es la construcción de modelos matemáticos que representen las relaciones cuantitativas del mundo real, lo que nos permite entender, analizar y predecir los fenómenos implicados. La comparación entre los cálculos realizados con ellos y los datos experimentales valida, o no, las teorías. Cuando estos modelos son sencillos (F=ma, E=mc2), así lo son los cálculos y podemos interpretar con facilidad las relaciones entre las distintas variables, simplemente viendo la fórmula. Cuando el modelo crece en el número de ecuaciones o aumenta su no linealidad, el cerebro humano no tarda mucho en perder esa capacidad y debemos recurrir a la simulación, esto es, a la solución numérica de estos modelos, para con ella intentar deducir la interpretación.

A partir de cierta extensión, el problema es la capacidad de cálculo: hace tiempo que la velocidad de un único procesador se encuentra limitada, por lo que recurrimos al aumento del número de procesadores, que pueden ser muchos en la computación de altas prestaciones: más de once millones de núcleos en El Capitán, el mayor superordenador (declarado) existente ahora mismo. Cuando comparten la misma memoria, por ejemplo, en los habituales procesadores multinúcleo (compuestos de varios procesadores independientes), hablamos de cálculo paralelo. Si cada procesador tiene una memoria asociada que no comparte con los demás, como en ordenadores independientes conectados, lo llamamos computación distribuida, aunque las posibles combinaciones hacen que las fronteras no sean nítidas. Por otro lado, lo que es grande o pequeño lo debemos valorar en función de la hipotética ganancia en prestaciones del reparto en varios procesadores, teniendo en cuenta que lleva siempre asociado un coste por la comunicación entre ellos.

En algunos casos, la distribución no viene, o no únicamente, de la necesidad de aumentar la capacidad de computación, sino de que distintas partes del modelo no se simulan o ejecutan (como elementos físicos en el caso de Hardware-In-the-Loop, HIL) en el mismo programa, o que son interactivas, porque participan personas (Human-In-the-Loop, HITL). Ello se puede deber a motivos funcionales, a que se han desarrollado las partes de forma independiente o a la existencia de componentes propietarios cuyo detalle no se quiere compartir. Cuando la distribución depende de esta heterogeneidad y de unir componentes más que de la mejora computacional, se suele hablar de cosimulación, pero nos referiremos a cualquiera de los casos cuando digamos simulación distribuida (o paralela), frente a la simulación monolítica ejecutada en un único programa y procesador.

En muchos dominios técnicos, como en la especialidad del que esto escribe, la simulación de procesos en ingeniería química, los modelos más habituales son continuos, bien de ecuaciones algebraicas no lineales (para régimen estacionario) o bien de sistemas de ecuaciones diferenciales y algebraicas (SEDAs, para régimen transitorio). Es normal que esos sistemas de ecuaciones sean dispersos, esto es, que en cada ecuación aparezca solo una fracción pequeña de las variables del sistema. Esta característica permite que frecuentemente las ecuaciones se puedan reducir (en grupos de ecuaciones y variables de menor dimensión que se resuelven siguiendo una secuencia) o descomponer (si esos grupos se resuelven de forma independiente). Es en este último caso cuando se pueden distribuir o paralelizar los cálculos de forma natural. Si su naturaleza es predominantemente secuencial, y tiende a serlo, las ventajas de la distribución disminuyen o incluso desaparecen, pues deberemos recurrir a procedimientos iterativos que incrementan el coste computacional, y aceptar un cierto nivel de error. Para el régimen transitorio, también cabe la paralelización en el tiempo (que es intrínsecamente secuencial...), repartiendo no grupos de ecuaciones, sino la integración de intervalos temporales entre los núcleos.

¿Es fácil implementar una simulación distribuida? ¿Se dispone de herramientas que nos ayuden a hacerlo? La respuesta simple es: existen herramientas, pero no es sencillo, el usuario debe invertir un esfuerzo importante. Intentaremos explicar por qué, analizando dos esquemas populares para simulación distribuida y cosimulación.

La especificación más conocida para simulación distribuida es probablemente HLA (High Level Architecture), evolución de un estándar nacido en el sector de la defensa, donde es ampliamente utilizado, con el objetivo de facilitar el intercambio de datos y la interoperabilidad entre simulaciones y posiblemente otras aplicaciones, incluyendo la interactividad con humanos. En esta arquitectura los distintos componentes (fundamentalmente simulaciones, llamados aquí "federados" en una simulación distribuida que es una "federación") intercambian datos y eventos a través de un RTI (Run Time Infrastructure, de los que hay abiertos y propietarios) un software intermediador con un patrón de publicación/suscripción que también gestiona la sincronización temporal. Si bien HLA ha demostrado su efectividad en simulaciones de grandes dimensiones, hay dos aspectos que hay que tener en cuenta para un usuario medio: el coste de implementar esta arquitectura puede ser proporcionalmente alto si el problema no es suficientemente grande o no se adapta al esquema que favorece, y que está pensando para simulación de eventos discretos, no para continuos.

Por otro lado, con un origen en la industria del automóvil y en el entorno del lenguaje Modelica, el estándar FMI (Functional Mock-Up Interface) tiene entre sus casos de uso la cosimulación, habiendo ganado relevancia en los últimos años en los que se han publicado 3 versiones. FMI define básicamente un interfaz para conectar diferentes modelos que se empaquetan en un fichero ZIP, llamado FMU (Functional Mock-Up Unit) como APIs de C (DLLs en Windows). En cosimulación, estas bibliotecas compartidas no sólo tienen el modelo sino también el simulador, pues deben resolverlo de forma independiente. Para ejecutar la simulación distribuida se necesita un programa importador, en el que se cargan las FMUs y que ordena su ejecución con un modelo amo/esclavo. Los modelos en este entorno son dinámicos y la función fundamental de las FMUs que se ejecuta en el bucle de simulación es DoStep, que hace que se integre en ella el modelo durante el intervalo indicado. FMI no considera la distribución en varias máquinas de sus componentes, pero dentro de la misma Modelica Association que lo auspicia hay otra norma para cosimulación distribuida que, sin ser exclusiva para FMI, ha sido diseñada para que se use con sus modelos: DCP (Distributed Co-simulation Protocol). Sin embargo, no parece haber estado nunca muy activa. Otra opción es el uso de HLA para la distribución de procesos con federados que son FMUs (encapsuladas).

Aunque hay muchas herramientas de simulación que pueden generar e importar FMUs (no siempre las específicas para un campo concreto), FMI se queda en la interfaz, dejando a otros la responsabilidad del importador. Y esas herramientas no la suelen asumir, salvo de la manera más simple: asimilándolo a una simulación de eventos discretos. Aquí nos volvemos a encontrar con el problema que citábamos para HLA: cada componente de la simulación se ejecuta (integra) de forma independiente, durante las llamadas de sincronización de HLA o los macropasos (los intervalos entre los que el importador llama al DoStep de cada componente) de FMI, desconociendo durante ese tiempo la evolución en otros componentes de variables que contiene. Esto produce errores o inestabilidad si se ignora, o incrementa el coste computacional si se recurre a simplemente reducir el tamaño de los macropasos de intercomunicación (sin probablemente saber qué error se comete). Son ciertamente planteamientos optimistas, que pueden salir bien o no. Por si fuera poco, cuando tratamos con SEDAs, hay problemas matemáticos adicionales.

¿Qué facilitaría la realización de simulaciones distribuidas en los casos que consideramos? Los estándares para comunicar procesos o para definir las interfaces entre componentes ya existen, y no sólo los citados. Si estamos dispuestos a trabajar en capas más bajas disponemos de diversas formas para comunicar componentes distribuidos, siendo quizá la más destacable la de MPI (Message Passing Interface). En ese nivel también hay algoritmos para solución de ecuaciones en paralelo, aunque esto es realmente la responsabilidad de las herramientas de simulación, al igual que la optimización del uso de CPUs/GPUs o cálculo híbrido en la nube. Siendo así, quizá la principal necesidad en los niveles superiores es disponer de un mejor marco teórico, con herramientas de análisis que determinen cómo distribuir los subsistemas del modelo principal o cómo se conectan los componentes individuales, y de herramientas de solución con los algoritmos y medios que garanticen el error de la misma forma que en la simulación monolítica, sin que esto suponga una intervención gravosa para el usuario.

Se nos anuncia un futuro donde los gemelos digitales, aplicados de forma generalizada, van a requerir un uso y desarrollo sin precedentes de la simulación. Algunas voces ya han advertido de la necesidad de distinguir lo que es una aspiración de lo que es real y que faltan décadas para alcanzar los objetivos propuestos. De lo que no hay dudas es de que esas simulaciones serán en gran parte distribuidas y de que es necesario desarrollar más su tecnología. En el grupo temático de Modelado, Simulación y Optimización de CEA (https://www.ceautomatica.es/es) trabajamos en distintos aspectos relacionados con estas herramientas, como la comunicación entre simuladores y su aplicación a casos de estudio como la esterilización de alimentos, la simulación de componentes eléctricos, o el estudio de la suspensión de vehículos.

Santos Galán Casado

Ingeniería de Simulación y Sistemas de Proceso (PS2E)

Departamento de Ingeniería Química Industrial y del Medio Ambiente.

E.T.S. de Ingenieros Industriales

Universidad Politécnica de Madrid

----

Este artículo aparece publicado en el nº 569 de Automática e Instrumentación págs 22 y 23.