por Walter Frei 

Una de las cuestiones más típicas que se hacen los usuarios de COMSOL es: ¿Cuál es el tamaño más grande de modelo que puede resolver COMSOL Multiphysics? Pues resulta que es bastante complicado responder a esta pregunta de una manera determinante, así que en este artículo del Blog de COMSOL, Walter Frei nos hablará sobre los requisitos de memoria, el tamaño del modelo y de cómo se puede predecir la cantidad de memoria que se necesitará para resolver problemas de elementos finitos 3D grandes.

Veamos unos cuantos datos

El gráfico de abajo muestra la cantidad de memoria necesaria para resolver varios problemas de elementos finitos 3D diferentes en términos del número de grados de libertad (DOF) en el modelo.

Requisitos de memoria (con un ajuste de curva polinomial de segundo orden) respecto a los grados de libertad de varios casos representativos.

Se presentan cinco tipos diferentes de casos:

• Caso 1: Un problema de transferencia de calor de una cáscara esférica. Existe transferencia de calor radiativa entre todas las superficies. El modelo se resuelve con el resolvedor iterativo por defecto.
• Caso 2: Un problema de mecánica de estructuras de una viga en voladizo, resuelta con el resolvedor directo por defecto.
• Caso 3: Un problema de ondas electromagnéticas resuelto con el resolvedor iterativo por defecto.
• Caso 4: El mismo problema de mecánica estructural del Caso 2, pero utilizando un resolvedor iterativo.
• Caso 5: Un problema de transferencia de calor de un bloque de material. Solo se considera transferencia de calor conductiva. El modelo se resuelve con el resolvedor iterativo por defecto.

Lo que se debería ver en este gráfico es que, con un ordenador que tenga 64 GB de memoria de acceso aleatorio (RAM), se pueden resolver problemas de un tamaño entre ~26.000 grados de libertad, en el limite inferior, hasta alcanzar casi 14 millones de grados de libertad. Pero, ¿por qué este rango de números tan amplio? Vamos a ver cómo interpretar estos datos...

Los grados de libertad, explicación

Para la mayoría de problemas, COMSOL Multiphysics resuelve un conjunto de ecuaciones diferenciales parciales aplicables a través del método de los elementos finitos, que toma el modelo CAD y subdivide los dominios en elementos, que se definen por un conjunto de nodos en los contornos.

En cada nodo, habrá como mínimo una incógnita, y el número de esas incógnitas se basa en la física que se está resolviendo. Por ejemplo, cuando se resuelve la temperatura, únicamente se dispone de una incógnita (llamada por defecto T) en cada nodo. En cambio, cuando se resuelve un problema estructural, se están calculando tensiones y las deformaciones resultantes, por lo tanto se están resolviendo tres incógnitas (u,v,w), que son los desplazamientos de cada nodo en el espacio x-y-z.

Para un problema de flujo de fluido turbulento, se resuelven las velocidades del fluido (también llamdas, por defecto, u,v,w) y la presión (p) así como otras incógnitas extra que describen la turbulencia. Si se está resolviendo un problema de difusión con muchas especies diferentes, se tendrán tantas incógnitas por nodo como especies químicas se tengan. Además, físicas diferentes con el mismo modelo pueden tener un orden de discretización por defecto diferente, lo que significa que pueden haber nodos adicionales a lo largo de las aristas de los elementos, como también en el interior del elemento.

Un elemento tetraédrico de segundo orden resolviendo el campo de temperatura, T, tendrá un total de 10 incógnitas por elemento, mientras que un elmento de primer orden que resuelve las ecuaciones de Navier-Stokes laminar para la velocidad, u=(u_x, u_y, u_z), y la presión, p, tendrá un total de 16 incógnitas por elemento.

COMSOL Multiphysics utilizará la información sobre la física, las propiedades del material, las condiciones de contorno, tipo de elemento, y forma de elemento para montar un sistema de ecuaciones (una matriz cuadrada), que tiene que ser resuelta para obtener la respuesta al problema de elementos finitos. El tamaño de esta matriz es el número de grados de libertad (DOF) del modelo, donde el número de DOF es una función del número de elementos, el orden de discretización utilizado en cada física, y el número de variables que se resuelven.

Estos sistemas de ecuaciones son normalmente dispersos, lo que significa que la mayoría de los términos de la matriz son ceros. Para la mayoría de los tipos de modelos de elementos finitos, cada nodo está conectado únicamente a los nodos vecinos en la malla. Hay que destacar que la forma del elemento importa; una malla compuesta por tetraedros tendrá una dispersión de la matriz diferente que una malla compuesta de elementos hexaédricos (ladrillo).

Algunos modelos incluirán acoplamientos no locales entre nodos, lo que supone una matriz del sistema relativamente densa. La transferencia de calor radiativa es un problema típico que tendrá una matriz densa del sistema. Existe intercambio de calor radiativo entre cualquier superficie que pueda ver a otra, por lo que cada nodo en las superficies radiantes está conectado a cualquier otro nodo. El resultado de esto se ve claramente en los gráficos mostrado al principio del artículo. El modelo térmico que incluye radiación tiene unos requisitos de memoria mucho más grandes que los modelos térmicos sin radiación.

En este punto se debería ver que no es solo el número de grados de libertad (DOF), sino también la dispersión de la matriz del sistema, lo que afectará a la cantidad de memoria necesaria para resolver el modelo de COMSOL Multiphysics. Vamos a echar un vistazo a cómo el ordenador gestiona la memoria.

¿Cómo gestiona la memoria el sistema operativo?

COMSOL Multiphysics utiliza los algoritmos de gestión de memoria proporcionados por el Sistema Operativo (SO) con el que se está trabajando. Independientemente del SO que se esté utilizando, el rendimiento de estos algoritmos es bastante similar en todos los últimos SO soportados por COMSOL.

El SO crea una Pila de Memoria Virtual, que el software de COMSOL ve como un espacio continuo de memoria libre. Este bloque continuo de memoria virtual en realidad puede mapearse en diferentes localizaciones físicas, por lo que parte de los datos pueden estar almacenados en la RAM y otras partes se almacenarán en el disco duro. El SO gestiona donde (en la RAM o en el disco) se almacenan los datos realmente, y por defecto no se tiene ningún control sobre ésto. La cantidad de memoria virtual es controlada por el SO, y no es algo que habitualmente se desee cambiar.

En circunstancias ideales, los datos que necesita almacenar COMSOL Multiphysics se posicionarán enteramente en la RAM, pero una vez que no exista espacio suficiente, parte de los datos desbordarán al disco duro. Cuando esto ocurre, el rendimiento de todos los programas en ejecución en el ordenador se degradará notablemente. 

Si el programa COMSOL requiere mucho espacio de memoria, entonces el SO determinará que ya no puede gestionar de forma eficiente la memoria (incluso a través del disco duro) y le dira a COMSOL Multiphysics que no existe más memoria disponible. Este es el punto en el que se obtendrá un mensaje de out-of-memory y COMSOL Multiphysics parará de intentar resolver el modelo.

A continuación, vamos a echar un vistazo a lo que hace COMSOL Multiphysics cuando se recibe este mensaje de memoria llena (out-of-memory) y qué se puede hacer con él.

¿Cuándo utiliza  COMSOL la mayoría de la memoria?

Cuando se configura y resuelve un problema de elementos finitos, existen tres etapas de uso intensivo de memoria: Mallado, Montaje, y Resolución.

• Mallado: Durante la etapa de mallado, la geometría CAD se subdivide en elementos finitos. El algoritmo de mallado por defecto aplica una malla tetraédrica libre sobre la mayor parte del espacio de modelado. El mallado tetraédrico libre de grandes estructuras complejas requerirá una gran cantidad de memoria. De hecho, a veces puede requerir más memoria que la resolución del sistema de ecuaciones, así que es posible quedarse sin memoria incluso en este paso. Si se encuentra que el mallado utiliza un tiempo y memoria significativos, entonces debería subdividirse (o partir) la geometría en subdominios más pequeños. En general, mientras más pequeños sean los dominios, menos memoria intensiva requerirá el mallarlos. Si se malla en una secuencia de operaciones en vez de todo de una vez, se pueden reducir los requisitos de memoria. En el contexto de este artículo, también se considera que no existen simplificaciones del modelo (como explotar la simetría o utilizar condiciones de contorno de capa fina) que podrían ser utilizados para simplificar el modelo y reducir el tamaño de la malla.
• Montaje: Durante la etapa de montaje, COMSOL Multiphysics forma la matriz del sistema además de un vector que describe las cargas. El montaje y almacenamiento de esta matriz requiere bastante memoria — posiblemente más que la etapa de mallado — pero siempre menos que la etapa de resolución. Si se tiene un problema de memoria disponible en esta etapa, se deberá de incrementar la cantidad de memoria RAM en el sistema.
• Resolución: Durante la etapa de resolución, COMSOL Multiphysics utiliza algoritmos muy generales y robustos capaces de resolver problemas no lineales, que pueden constar de fisicas arbitrariamente acopladas. En el núcleo más profundo de estos algoritmos, sin embargo, el software estará siempre resolviendo un sistema de ecuaciones lineales, y esto se puede realizar tanto con métodos directos como iterativos. Así que vamos a ver estos dos métodos desde el punto de vista de cuándo deben de ser utilizados y cuánta memoria necesitan.

Resolvedores directos

Los resolvedores directos son muy robustos y pueden manejar esencialmente cualquier problema que surja durante el modelado por elementos finitos. Los resolvedores directos de matriz dispersa utilizados por COMSOL Multiphysics son los resolvedores MUMPS, PARDISO, y SPOOLES. También hay un resolvedor de matriz densa, que se utilizaría únicamente si se sabe que la matriz del sistema está muy poblada.

El inconveniente de todos estos resolvedores es que la memoria y el tiempo requeridos crece muy rápidamente a medida que el número de DOF y la densidad de la matriz crecen; el escalado es muy próximo a cuadrático respecto al número de DOF.

En el momento actual, tanto los resolvedores directos MUMPS como PARDISO vienen con una opción out-of-core. Esta opción anula la gestión de memoria del SO y permite a COMSOL Multiphysics controlar directamente cuántos datos se almacenarán en la RAM y cuándo y cómo empezar a escribir datos en el disco duro. Aunque éste es un algoritmo de gestión de memoria superior que el del SO, el proceso de resolución será más lento que resolver el problema completamente en la RAM.

Si se dispone de acceso a un supercomputador clúster, como el servicio Amazon Web Service™ Amazon Elastic Compute Cloud™, también se puede utilizar el resolvedor MUMPS para distribuir el problema en muchos nodos del clúster. Aunque esto permite resolver problemas mucho más grandes también es importante considerar que resolver problemas en un clúster puede ser más lento que resolverlos en una única máquina.

Debido a su agresivo escalado (aproximadamente cuadrático) con el tamaño del problema, los resolvedores directos solo se utilizan como el resolvedor por defecto para unas pocas interfaces físicas 3D (aunque son casi siempre utilizados para modelos 2D, para los que el escalado es mucho mejor.)

El caso más típico donde se utiliza el resolvedor directo por defecto es en los problemas de mecánca de estructuras 3D. Aunque esta elección se ha hecho por robustez, también es posible utilizar un resolvedor iterativo en muchos problemas de mecánica de estructuras. El método para conmutar los ajustes del resolvedor se muestra en el modelo de ejemplo de las tensiones en una llave plana.

Resolvedores iterativos

Los resolvedores iterativos requieren relativamente mucha menos memoria que los resolvedores directos, pero requieren más personalización de los ajustes para que conseguir que trabajen bien.

Con todas las interfaces físicas predefinidas donde es razonable utilizarlos, se han proporcionado sugerencias del resolvedor iterativo por defecto, que se seleccionan por su robustez. Estos ajustes son gestionados de forma automática y no requieren ninguna interacción del usuario, por lo que mientras se estén utilizando interfaces físicas internas, no hay que preocuparse sobre esos ajustes.

La memoria y el tiempo necesitados por un resolvedor iterativo será relativamente mucho menor que el de un resolvedor directo, para el mismo problema, así que cuando se pueda deberían de ser utilizados. El escalado cuando el problema crece es mucho más parecido a lineal, en oposición que el típico escalado cuadrático de los resolvedores directos.

En estos momentos, los resolvedores iterativos deberían de utilizarse en un ordenador que tenga suficiente RAM para resolver el problema, así que si se recibe un mensaje de memoria llena (out-of-memory) cuando se utilice un resolvedor iterativo, debería de aumentarse la cantidad de RAM del ordenador.

También es posible utilizar un resolvedor iterativo en un clúster de ordenadores utilizando métodos de Descomposición de Dominio. Esta clase de métodos iterativos se ha introducido recientemente en el software, así que permanezcan atentos a más detalles sobre este tema que vendrán en el futuro.

Predecir los requisitos de memoria

Aunque los datos mostrados anteriormente proporcionan unos límites superior e inferior de requisitos de memoria, estos límites son bastante amplios. Hemos visto que al introducir un pequeño cambio en el modelo, como introducir un acoplamiento no local como una transferencia de calor radiativa, puede cambiar significativamente los requisitos de memoria. Así que introduzcamos una receta general para poder predecir los requisitos de memoria. 

Empezar con un modelo representativo que contenga la combinación de las físicas que se quieren resolver y aproxime la verdadera complejidad geométrica. Empezar con un mallado grueso si es posible y entonces, refinar la malla gradualmente. Alternativamente, empezar con una representación más pequeña del modelo e incrementar gradualmente el tamaño.

Resolver cada modelo y monitorizar los requisitos de memoria. Observar el resolvedor por defecto que se está utilizando. Si se trata de un resolvedor directo, utilizar la opción out-of-core en las pruebas, o considerar si se puede utilizar un resolvedor iterativo en su lugar. Ajustar un polinomio de segundo orden a los datos, y utilizar esa curva para predecir la memoria requerida para el tamaño de problema más grande que realmente se quiere resolver. Esta es la forma más fiable de predecir los requisitos de memoria de modelos multifísicos 3D complejos y grandes.

Como acabamos de ver, la memoria necesaria dependerá de (como mínimo) la geometría, la malla, el tipo de elementos, la combinación de físicas que se quiere resolver, los acoplamientos entre las físicas, y el alcance de cualquier acoplamiento del modelo no local. En este punto, debería también aclararse que no es posible, en general, predecir los requisitos de memoria en todos los casos. Se puede necesitar repetir este proceso varias veces para ver las variaciones del modelo. 

También es justo decir que configurar y resolver modelos grandes de la forma más eficiente posible es algo que puede requerir unos conocimientos profundos, no solo de los ajustes del resolvedor, sino también del modelado de elementos finitos en general. Si tiene un problema de modelado en particular, contacte con el equipo de soporte de COMSOL para que le guíe. 

Resumen

Llegados a este punto debería de comprender por qué los requisitos de memoria de un modelo de COMSOL Multiphysics pueden variar drásticamente. También debería de ser capaz de predecir con confianza los requisitos de memoria de sus grandes modelos y decidir que tipo de hardware requieren sus retos de modelado. 

Amazon Web Services y Amazon Elastic Compute Cloud son marcas comerciales de Amazon.com, Inc. o sus afiliadas en Estados Unidos y/o otros paises.