🔬 physics

Mosaic: A Benchmark Suite for Differentiable Physics Solvers

El artículo presenta Mosaic, un marco de evaluación de código abierto que estandariza la evaluación de los resolvedores de EDP diferenciables al empaquetarlos como componentes en contenedores, revelando variaciones significativas en el costo computacional, el condicionamiento numérico y la compatibilidad entre 14 resolvedores, al tiempo que demuestra que todos los resolvedores que producen gradientes convergen a óptimos similares.

Autores originales: Andrin Rehmann, Heiko Zimmermann, Dion Häfner

Publicado 2026-06-29

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Andrin Rehmann, Heiko Zimmermann, Dion Häfner

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 que eres un chef intentando inventar una nueva receta. Tienes una cocina llena de diferentes hornos (los solucionadores de física). Algunos son hornos inteligentes de alta tecnología, otros son estufas de gas de la vieja escuela y otros son sofisticadas unidades de convección. Todos hornean pan, pero lo hacen de maneras muy diferentes.

Ahora, imagina que quieres usar un brazo robótico para ajustar la receta automáticamente. Para hacer esto, el robot necesita saber exactamente cómo el cambio en la temperatura o en la cantidad de harina cambia el sabor final. En el mundo de las simulaciones de física, este "feedback del sabor" se llama gradiente.

Durante mucho tiempo, los científicos han tenido estos hornos, pero nadie sabía qué horno le daría al robot el feedback más preciso, cuánto costaría la electricidad para obtener ese feedback, o si el horno incluso explotaría si le hicieras la pregunta equivocada.

Entra "Mosaic".

Piensa en Mosaic como una cocina de pruebas universal. Los investigadores construyeron una configuración estandarizada donde pueden conectar 14 "hornos" diferentes (programas informáticos que resuelven ecuaciones de física) y probarlos uno al lado del otro. Envolvieron cada horno en una caja especial (llamada Tesseract) para que, sin importar en qué lenguaje haya sido construido el horno (Python, Julia, C++) o cómo funcione por dentro, el brazo robótico pueda hacerle exactamente la misma pregunta de la misma manera.

Aquí está lo que descubrieron cuando empezaron a hornear:

1. El "Feedback" varía enormemente

Al igual que algunos hornos tardan 5 minutos en precalentar y otros 30, el costo de obtener ese "feedback del sabor" (el gradiente) varía masivamente.

Los Velocistas: Algunos hornos modernos (como los construidos sobre JAX o PyTorch) pueden darte el feedback casi instantáneamente, con casi ningún esfuerzo adicional. Es como tener un horno inteligente que te dice la temperatura en el segundo en que abres la puerta.
Los de Gran Capacidad: Otros hornos (como OpenFOAM o deal.II) son potentes pero requieren una enorme cantidad de trabajo manual para obtener ese feedback. Es como tener que medir manualmente el calor con un termómetro por cada grado de cambio. Los investigadores descubrieron que para algunos de estos, escribir el código para obtener el feedback requería cientos o incluso miles de líneas de código adicionales.

2. La trampa de la "Estabilidad"

Algunos hornos son excelentes para hornear un pan sencillo (un problema de física suave y fácil), pero si intentas hornear un soufflé complejo (un problema de flujo de fluido caótico), podrían colapsar.

El artículo encontró que para algunas tareas, como optimizar la forma de un cilindro para reducir la resistencia en el agua, la mitad de los hornos simplemente no podían usarse en absoluto. Eran estructuralmente incompatibles. Es como intentar usar una tostadora para hornear un pastel; la máquina no está construida para esa forma de problema.
Incluso entre los que podían funcionar, algunos eran "inestables". Si les pedías simular un periodo de tiempo largo, los números se volvían muy desordenados (un concepto matemático llamado mal condicionamiento) de modo que el brazo robótico empezaba a girar en círculos, incapaz de encontrar la mejor solución.

3. El horno "Perfecto" no existe

¿La mayor sorpresa? La precisión no era el problema principal.
La mayoría de los hornos, una vez que lograban dar el feedback, eran sorprendentemente precisos. Si no fallaban, generalmente encontraban la misma "receta perfecta" (la solución óptima).

Los verdaderos cuellos de botella no eran que las matemáticas estuvieran mal, sino que la memoria se agotaba (el horno se calentaba demasiado), la configuración era demasiado difícil de implementar, o el costo era demasiado alto.
Es como tener 10 chefs que pueden cocinar un filete perfecto. El problema no es que no sepan cocinar; es que tres de ellos necesitan una cocina de $10,000, uno de ellos necesita un tiempo de preparación de 24 horas, y uno de ellos se niega a cocinar a menos que le des un tipo específico de cuchillo.

4. El "Control Negativo" (La prueba simple)

Para asegurarse de que estaban probando los hornos y no los ingredientes, comenzaron con una tarea muy simple: calentar una placa de metal plana. Este es el "control negativo".

En esta tarea simple, cada uno de los hornos que podía ejecutarla produjo el mismo resultado perfecto. Esto demostró que las diferencias que vieron en las tareas complejas no se debían a que las matemáticas estuvieran rotas; era porque las tareas complejas expusieron las debilidades específicas del diseño de cada horno.

La Conclusión

El artículo presenta Mosaic no como una nueva forma de resolver problemas de física, sino como un menú estandarizado para investigadores.

Antes de Mosaic, elegir un solucionador era como adivinar qué horno comprar basándose en la palabra de un vendedor.
Con Mosaic, puedes mirar el menú y ver: "Si necesito hacer esta tarea específica, el Horno A es 200 veces más rápido que el Horno B, pero el Horno B maneja mejor mi forma específica".

Los investigadores concluyen que para muchos problemas, el "mejor" solucionador no es el que tiene las matemáticas más precisas, sino el que se ajusta a tus restricciones específicas (como límites de memoria o tiempo de configuración) sin colapsar. Pusieron todas sus "herramientas de cocina" y "menús" en código abierto para que cualquiera pueda añadir sus propios hornos a la cocina de pruebas y ver cómo se comparan.

Resumen Técnico: Mosaic: Una Suite de Benchmarking para Solvers de Física Diferenciable

Declaración del Problema

Si bien se promociona cada vez más que los solvers de ecuaciones diferenciales parciales (PDE) diferenciables son tecnologías habilitadoras para el aprendizaje automático con el solver en el bucle (solver-in-the-loop), el control óptimo basado en gradientes y los problemas inversos, los costos prácticos para obtener gradientes correctos y utilizables siguen siendo opacos. El panorama de los solvers diferenciables está fragmentado entre lenguajes, marcos de trabajo de diferenciación automática (AD) y métodos numéricos. Los profesionales enfrentan una incertidumbre significativa respecto a:

Esfuerzo de Integración: La variabilidad en la experiencia requerida para integrar solvers, que van desde aplicaciones listas para usar hasta kits de herramientas de kernels de bajo nivel.
Calidad del Gradiente: La falta de medición sistemática sobre la precisión del gradiente, el condicionamiento numérico y la estabilidad.
Compatibilidad Estructural: Restricciones específicas del solver (por ejemplo, condiciones de contorno solo periódicas, esquemas de penalización incompatibles) que a menudo solo surgen tras un compromiso significativo con un stack específico.

Los benchmarks actuales se centran ya sea en la precisión del forward de los sustitutos neuronales (por ejemplo, APEBench, PDEBench) o comparan backends de AD dentro de un mismo framework (por ejemplo, PhiFlow), fallando al no medir sistemáticamente las propiedades de los gradientes a través de implementaciones de solvers independientes.

Metodología

Los autores presentan Mosaic, un marco de benchmarking extensible diseñado para estandarizar el acceso a los gradientes de los solvers y permitir la comparación entre solvers. La metodología se basa en tres artefactos principales:

Interfaz de Solver Contenerizada (Tesseract):
- Los solvers se empaquetan como contenedores Docker (Tessera) que exponen una API uniforme independientemente del lenguaje o la estrategia de AD.
- La interfaz define dos puntos de entrada: apply(inputs) → outputs (pasada forward) y vector_jacobian_product(inputs, cotangents) → vjp (gradiente de modo reversa).
- Esta abstracción permite intercambiar solvers mediante cadenas de configuración sin reescribir el código de evaluación. Los solvers de solo forward (por ejemplo, OpenFOAM, deal.II) se envuelven automáticamente para proporcionar gradientes de diferencias finitas como una línea base de referencia.
Tareas de Benchmark:
- Se evalúan cuatro dominios físicos, ordenados por dificultad:
  - Transferencia de Calor (H): Inversión de conductividad (Control negativo; la física suave aísla errores de AD).
  - Mecánica Estructural (S): Minimización de cumplimiento mediante optimización de topología SIMP.
  - Fluidos 2D (F2): Minimización de arrastre mediante optimización de flujo hacia la entrada alrededor de un cilindro (No periódico, con obstáculos).
  - Fluidos 3D (F3): Recuperación de condiciones iniciales en un box de vórtice de Taylor-Green periódico.
- Las tareas están diseñadas como problemas de optimización independientes sin componentes aprendidos, asegurando que los fallos puedan atribuirse al mecanismo de gradiente del solver y no a errores de aproximación del modelo.
Protocolo de Evaluación:
- Precisión del Gradiente: Medida mediante similitud de coseno y error relativo $\ell_2$ contra diferencias finitas centrales en tamaños de perturbación óptimos.
- Condicionamiento: Analizado mediante el espectro de valores singulares del Jacobiano.
- Rendimiento: Tiempo de ejecución (wall-clock time) para las pasadas forward y VJP, consumo de memoria y la relación de costo VJP/forward.
- Convergencia de Optimización: Presupuestos de iteración fijos con optimizadores Adam y L-BFGS para medir la convergencia al óptimo global.

La suite incluye 14 backends de solvers que abarcan diversas estrategias de AD (transformación de fuente, adjoints basados en tape, adjoints derivados a mano) y métodos numéricos (diferencias finitas, volúmenes finitos, elementos finitos, lattice Boltzmann, espectrales).

Resultados Clave

La evaluación de 14 solvers a través de los cuatro dominios revela varios hallazgos críticos:

Precisión del Gradiente vs. Condicionamiento: Todos los solvers diferenciables que producen gradientes logran una alta precisión (similitud de coseno > 0.999) frente a las diferencias finitas. Sin embargo, el condicionamiento del Jacobiano varía por órdenes de magnitud. Los solvers basados en proyección exhiben un decaimiento espectral pronunciado (mal condicionamiento) en comparación con los métodos de lattice Boltzmann o espectrales, lo que impacta la estabilidad de los optimizadores de segundo orden.
Costo Computacional: Existe una variación de un orden de magnitud en el costo computacional. El AD de transformación de fuente (por ejemplo, solvers basados en JAX) mantiene una relación VJP/forward casi constante, mientras que los adjoints basados en tape (por ejemplo, FEniCS, Firedrake) escalan de forma más pronunciada con el tamaño del problema.
Incompatibilidad Estructural: En la tarea más compleja (minimización de arrastre 2D con obstáculos), solo 3 de 7 backends de fluidos pudieron representar el problema debido a incompatibilidades de condiciones de contorno o penalización. Esta "atrición" ocurre antes de que la calidad del gradiente se convierta en un factor.
Resultados de Optimización: A pesar de las vastas diferencias en el condicionamiento y el costo, todos los solvers que se ejecutan con éxito convergen a óptimos similares en problemas bien condicionados (Calor, Estructural). En la tarea de recuperación de IC 3D, L-BFGS con proyección solenoidal supera significativamente a Adam y L-BFGS sin proyectar, reduciendo el error de la condición inicial de >40% a <0.5%.
Esfuerzo de Implementación: La complejidad de integración varía ampliamente. Los solvers construidos sobre frameworks de AD modernos (JAX, PyTorch) a menudo requieren cero líneas de código adicionales para los gradientes, mientras que los kits de herramientas de kernels de bajo nivel (por ejemplo, NVIDIA Warp) requieren cientos de líneas personalizadas para la implementación del adjoint.

Significación y Reivindicaciones

El artículo posiciona a Mosaic no como una fuente de nuevos resultados empíricos para un solo solver, sino como infraestructura que reduce la barrera de entrada para la investigación en física diferenciable, de forma análoga a OpenAI Gym para el aprendizaje por refuerzo.

Estandarización: Mosaic proporciona la primera interfaz estandarizada para acceder, comparar y confiar en los gradientes a través de implementaciones de solvers independientes.
Guía para Profesionales: El benchmark expone barreras prácticas (límites de memoria, estabilidad numérica, compatibilidad de configuración) que son más críticas que la precisión bruta del gradiente por sí sola. Sugiere que, para problemas bien condicionados, el solver más rápido con el menor esfuerzo de integración es la elección óptima.
Extensibilidad de la Comunidad: El marco es de código abierto y está diseñado para evolucionar. Permite a los investigadores someter a prueba los modos de fallo antes de comprometerse con un stack de solver específico y permite la construcción de pipelines de solver-in-the-loop sobre una interfaz uniforme.
Validación de AD: Los resultados validan que, si bien los adjoints derivados a mano pueden ser más rápidos, el AD de modo reversa a través de frameworks modernos ofrece el mejor equilibrio entre esfuerzo y capacidad, proporcionando suficiente precisión para la optimización a una fracción del costo de implementación.

Los autores concluyen que, si bien la calidad del gradiente es generalmente suficiente, la elección del backend del solver es un factor decisivo para que los flujos de trabajo basados en gradientes tengan éxito o fallen, principalmente debido a la compatibilidad estructural y el condicionamiento numérico, más que a la corrección del gradiente en sí.