Investigación, herramientas y pruebas de nuestras pruebas

En los últimos días agregamos Stabileo Research y Stabileo Tools, y reforzamos sus controles. Stabileo es software gratuito y de código abierto para ingeniería estructural con IA, publicado por Ergodic Group. LambdaClass es su brazo de desarrollo.

Investigación que se puede ejecutar

Estamos llevando artículos publicados de ingeniería estructural y benchmarks clásicos al navegador, con el visor de Stabileo. Cada página indica qué reproduce, cómo lo verificamos y los límites de la comparación. Estamos completando las páginas que todavía muestran comparaciones pendientes.

Las páginas de artículos disponibles cubren fractura de campo de fase de Shauer (2025); redes de resortes de Grossman y Boudaoud (2026); optimización topológica de Andreassen et al. (2011); estabilidad del pórtico de Roorda de Ferrari y Sigmund (2025); búsqueda de forma de redes de cables de Pastrana et al. (2026); arcos con salto de Zmyślony, Khan y Biggins (2026); y estructuras reticuladas de Fairclough et al. (2026).

Los clásicos del motor son MacNeal–Harder, el circuito de pruebas de láminas, la elástica de Mattiasson, Riks/Crisfield, Newmark, CQC, colapso plástico, la placa de Navier, el pórtico de Lee y el arco de DaDeppo–Schmidt. Las páginas distinguen cálculo en vivo de reproducción de resultados guardados y muestran los límites de la comparación. Falta la comparación de Koiter de Ferrari; Fairclough cubre un ejemplo de cinco nodos; el salto de equilibrio del arco no es una simulación transitoria.

Publicamos el alcance y la evidencia y los revisamos abiertamente. Los resultados de investigación no son resultados de diseño, y coincidir con un benchmark no es una certificación.

También hay que comprobar las pruebas

Algunas páginas eran incorrectas porque nuestros modelos de prueba estaban mal. Cada página de benchmark del motor y su prueba de CI ahora leen el mismo archivo de caso, de modo que corregir el modelo actualiza ambas. Algunas comparaciones provisionales siguen explícitamente excluidas de CI y todavía no bloquean integraciones; estamos completándolas.

Corregimos las referencias de Mattiasson y el tratamiento del alargamiento axial (#845), un pórtico de nudos rígidos comparado con una fórmula de reticulado puramente axial (#846) y modelos incorrectos de apoyos y cargas en láminas (#810). Estamos cambiando cómo se construyen los benchmarks para que esta clase de error no vuelva a pasar. La primera parte ya está incorporada: cada benchmark es una especificación con dos referencias independientes que deben coincidir y controles automáticos de carga aplicada, equilibrio de reacciones y simetría, incluidas comparaciones entre medio modelo y modelo completo. Estamos agregando convergencia en tres o más mallas, una prueba con error de signo que demuestra que cada benchmark puede fallar y la aprobación de un ingeniero para el conjunto principal.

También estamos incorporando unidades al sistema de tipos (#864), para detectar confusiones entre kN/N o m/mm al compilar. La primera parte, para el camino de materiales y secciones de los pórticos 2D, se integró el 3 de noviembre.

Segunda ronda: cada página revisada de nuevo

Después, cada página de investigación publicada pasó por una segunda revisión, a cargo de tres modelos de IA sucesivos (Kimi, después Codex, después Claude), y corregimos cada hallazgo que pudimos verificar. Quince páginas se revisaron juntas y se publicaron el 4 de noviembre (#1068): seis artículos (Shauer, Pastrana, Ferrari, Zmyślony, Grossman y Fairclough) y nueve benchmarks del motor (Newmark, Riks/Crisfield, Navier, Lee, MacNeal–Harder, DaDeppo–Schmidt, el ejemplo de colapso plástico según Horne, SRSS/CQC y Mattiasson, que tuvo una tercera ronda). No se aflojó ninguna tolerancia ni se eliminó ninguna prueba. La revisión por ingenieros en ejercicio todavía está pendiente.

• MacNeal–Harder comparaba valores absolutos, así que un resultado con el signo equivocado habría pasado. Las referencias ahora llevan su signo, y una prueba rechaza una respuesta invertida en cada caso.
• Riks/Crisfield podía informar un punto límite sin una caída de la carga. Ahora un punto límite exige una caída entre pasos convergidos; la página dice que el cálculo pasa el punto límite superior en lugar de “traces the snap-through”, y sus tolerancias pasaron del 5 % a valores de entre 5e-3 y 1e-5.
• Navier explicaba el error de MITC4 en lugar de medirlo. Ahora se compara con una serie de Reissner–Mindlin independiente, y el error de MITC4 con apoyo simple duro baja de −1,951 % en 4×4 a −0,036 % en 32×32, con convergencia de segundo orden.
• Las páginas dicen con qué se comparan. Newmark se verifica contra soluciones exactas en forma cerrada, no contra “the author’s code”; SRSS/CQC es una ilustración del método, no una reproducción del edificio del artículo; las cotas de colapso plástico son deducciones nuestras hechas a mano, no una cita; la referencia de 1,83 kN del pórtico de Lee es una lectura de una figura publicada, así que solo afirmamos diferencias en porcentajes enteros.

En teléfonos y tabletas

Según lo que medimos en el sitio publicado, las páginas de investigación no se desbordaban en un teléfono, pero el experimento quedaba debajo de todo el artículo, el visor quedaba apretado (356×189 px para una placa cuadrada) y cada página tenía de 25 a 40 controles de menos de 32 px y de 14 a 20 textos de menos de 12 px. Ahora el experimento aparece justo después del título, el visor se dimensiona según el modelo, los controles miden al menos 44 px y el texto al menos 12 px (#831).

Un control permanente renderiza la galería y cada página ejecutable a 360, 390, 844×390 y 810 px, en español, inglés y portugués, y falla si hay desbordamiento horizontal, controles pequeños, texto pequeño o un visor que falta, es demasiado pequeño o está demasiado abajo. Sus primeras ejecuciones encontraron errores reales, y se corrigieron los diseños, no el control: el visor de Mattiasson medía 187 px de alto con el teléfono en horizontal y ahora mide 280 px, y un gráfico de convergencia mostraba sus etiquetas a 9 px. Una prueba de reflujo encontró que las pestañas de Shauer se desbordaban en portugués y en turco a 360 px.

Ocho calculadoras, con acceso al editor

Stabileo Tools tiene calculadoras gratuitas de vigas simplemente apoyadas, ménsulas, pandeo elástico de columnas, vigas continuas, pórticos de un vano, reticulados planos, líneas de influencia de cargas móviles y frecuencias de flexión de vigas. Usan el motor de producción, muestran comparaciones clásicas independientes y explicitan sus hipótesis. Cada una abre su modelo en el editor completo. Son herramientas de análisis, no verificaciones normativas completas.

Contener los resultados incorrectos

Estamos conteniendo todos los problemas conocidos de resultados incorrectos: los rechazos o advertencias del motor incluyen el identificador del problema, en lugar de devolver un número sin verificar (#807, integrado el 5 de noviembre). Se prueba cada rechazo, incluidos los modelos dinámicos no admitidos con excentricidades de barras o láminas.

Las pruebas metamórficas revelaron errores de invariancia: modelos equivalentes podían rechazarse después de rotarlos, reflejarlos o cambiar la escala de sus unidades. Ahora ejecutamos la batería metamórfica con cada cambio para detectar estas regresiones. Estamos agregando una ejecución nocturna de modelos aleatorios que agrupa los hallazgos por causa raíz y abre una incidencia por cada causa raíz.

Desde entonces: del 1 al 3 de noviembre

• El modo de análisis de PRO está terminado. Corregimos resultados que estaban mal sin ningún aviso: el generador de cargas ya no carga los aleros de una nave como si fueran un piso, y el peso sísmico de cada nivel ahora incluye las losas y los muros dibujados como cáscaras, que dejaba afuera (#1076).
• Las exportaciones funcionan en edificios reales. Las hojas grandes de Excel se escriben fila por fila, y la memoria de un edificio de seis pisos tarda unos diez segundos en lugar de cuatro minutos. “Verificar un reporte exportado” ahora compara los números impresos, no solo las huellas (#1076).
• PRO sumó ayuda en línea que se puede apagar, un estado de guardado en el encabezado, una memoria después del análisis, resultados de placas y un visor de solo lectura para modelos compartidos con “Duplicar y editar” (#1077, #1078).
• Un factor de pandeo por encima de su cota superior certificada de forma independiente ahora se rechaza, en 2D y en 3D (#817, versión de resultados 6). Volvé a certificar antes de confiar en un certificado de pandeo anterior.
• Los enlaces compartidos con números no finitos, o con barras, apoyos o cargas que apuntan a algo que no existe, se rechazan en lugar de abrirse (#1058).
• La suite de invariancia ahora verifica seis análisis prioritarios ante rotación, simetría y superposición, y cuatro de ellos ante un escalado uniforme de la rigidez (#1060).

Controles que responden en veinte minutos

Antes de llegar a main, cada cambio en Stabileo pasa por los controles que puede afectar, y un cambio en el motor pasa por todos: pruebas del motor, pruebas unitarias de la web, builds de producción, pruebas de extremo a extremo en un navegador, las instantáneas de resultados y el control de determinismo. Una corrección que afecta la seguridad estructural no llega más rápido que esos controles, así que el 4 de noviembre trabajamos en su velocidad. Primero medimos. En una ejecución limpia de la cola de merge de 44 a 47 minutos, las pruebas del motor y las unitarias terminaban entre 8 y 15 minutos antes del final, así que sumar más en paralelo no habría servido de nada. El tiempo se iba en compilar los paquetes de investigación uno detrás de otro y en el fragmento de extremo a extremo más lento. Una vez acortados esos dos, el fragmento más lento era lento por la preparación: en una ejecución dedicó 7,2 de sus 16 minutos a las pruebas y seis y medio a descargar paquetes de navegadores desde un mirror lento.

• Compilar una vez y probar lo compilado. Las pruebas de los builds de producción hacían cinco builds propios más, cuatro de ellos del mismo árbol que CI acababa de compilar; esos cuatro ahora leen ese build (#1411). Cada build lleva un sello de todo aquello a partir de lo que se compiló, y una prueba falla, nunca se omite, si el sello no coincide con el árbol sobre el que corre.
• Caché por entradas. Cada paquete de investigación se guarda en caché bajo una clave de sus propias entradas, incluido el motor que enlaza cada paquete, de modo que un cambio en un artículo recompila solo ese artículo y un cambio en el motor los recompila todos. Un pull request reutiliza los paquetes que la cola de merge ya compiló a partir de las mismas entradas, después de verificar cada archivo contra su checksum, y puede leer esa caché pero nunca escribir en ella (#1395). Los paquetes de navegadores también salen de una caché, en lugar del mirror (#1413).
• Ejecutar solo lo que un cambio puede afectar. Un cambio en la documentación no compila nada y termina en uno o dos minutos, en lugar de una ejecución completa. Un cambio solo en el sitio omite los trabajos del motor pero mantiene todos los fragmentos de extremo a extremo, porque 59 de las 281 especificaciones leen texto en pantalla (#1381). En la cola, el alcance de cada entrada se define por su propio diff contra la entrada que tiene delante, lo cual es válido porque una entrada se integra solo si pasaron todas las entradas que tiene delante; cuando el diff falta o no es claro, se ejecuta todo (#1400).
• Equilibrar el camino más lento. Las pruebas de extremo a extremo corren en 14 fragmentos en lugar de 10, equilibrados según tiempos medidos (#1382). La tabla de tiempos anterior predecía 41,5 minutos de pruebas donde una ejecución tardó 69,8.

Un control en rojo que no es culpa del cambio

Una falla causada por la red o por una máquina perdida es ruido, pero también es un control en rojo que alguien tiene que mirar, y la costumbre de volver a ejecutar los controles en rojo es la forma en que una falla real termina dejándose pasar. Por eso los trabajos fallidos de un pull request se vuelven a ejecutar una vez, automáticamente, solo cuando cada trabajo fallido trae evidencia positiva de una falla de infraestructura: un timeout en un paso de descarga, una máquina de CI perdida a mitad del trabajo, un error de red que termina el último intento de una descarga (#1380). Cualquier cosa que parezca una falla de prueba en cualquier parte del log bloquea la reejecución, y lo mismo pasa con cualquier cosa que el clasificador no reconozca. Eso la mantiene conservadora: reejecuta como mucho una vez y nunca después de un paso de pruebas fallido. No es una garantía: una falla intermitente que el clasificador lea mal como de infraestructura podría pasar en la reejecución, y por eso cualquier cosa que no reconozca bloquea la reejecución.

Otras dos correcciones eliminaron falsas alarmas. Una ejecución de pull request cancelada porque otra más nueva sobre el mismo commit la reemplazó mostraba un control obligatorio en rojo; ahora omite ese control, pero solo después de confirmar que la ejecución más nueva existe y no falló, porque un control obligatorio omitido cuenta como aprobado (#1397). Y una descarga trabada podía dejar un proceso con el lock del gestor de paquetes, así que el reintento fallaba por el lock y no por la descarga; ahora un intento cuenta como trabado solo después de varios minutos sin salida, se detiene junto con todo lo que inició, y el reintento espera el lock (#1408).

Qué sigue

Estamos completando las comparaciones pendientes y acelerando el sitio y el solver. Lo próximo en la hoja de ruta es un paquete de Python (pip install stabileo) y un manual público de verificación generado a partir de los benchmarks.