Automatización y parametrización de cálculo de estructuras
Mi primer contacto con la automatización ocurrió más o menos en el año 1986, cuando empecé jugar con ordenadores. Mi hermano me enseñó como se hacía un programa en el BASIC del ordenador Amstrad CPC 6128 para automatizar el cálculo del área de un triángulo. En ese momento, en la mente de ese niño de diez años se abrió un mundo de posibilidades en el que, incluso, podías llegar a tener un programa que calculase el área de cualquier polígono (seguramente pensaba que no había vida más allá de los polígonos regulares). Sigo afrontando el trabajo con la misma alma de ese niño perezoso que no quería repetir por enésima vez el mismo problema de matemáticas, y de ahí mi ‘obsesión’ con la automatización.
Por su parte, mi interés por la parametrización llegó en mi madurez profesional, cuando me di cuenta de que igual la mejor solución para el cálculo, por ejemplo, de un talud con los datos que nos suelen dar a los ‘mortales’ son esos fantásticos ábacos que ya usaban los ingenieros antes de que la computación invadiera, para bien o para mal, el mundo de la ingeniería.
Qué hago
Mis proyectos paralelos activos
01.
Hojas de cálculo
Empiezo la serie con la automatización en EXCEL del cálculo de la resistencia al empuje lateral de un pilote.
02.
Programación
Llevo años buscando aprender a programar en PYTHON y la automatización de una unión atornillada en ANSYS puede ser un buen reto.
03.
Rhinoceros y Grashopper
Una plataforma NO-CODE en la que enlazar la automatización, el CONSTEEL y el TEKLA… ¿Qué puede salir mal?
1.-Aunque no lo sepas, debes automatizar los cálculos
Cuando un ingeniero se dedica al diseño y el cálculo, se va a encontrar repitiendo en numerosas ocasiones los mismos cálculos una y otra vez, surgiendo rápidamente la necesidad de automatizar el proceso. Si trabajas dentro de una gran ingeniería, es probable que el problema de la automatización ya esté resuelto con algún programa u hoja de cálculo “estandarizados” al que debas ceñirte.
En mi caso, por el tipo de trabajo que he realizado, los proyectos tan diferentes en los que me participado y las estructuras de trabajo en las que me he movido durante mi carrera profesional, me he visto en la situación de tener que invertir parte de mi tiempo en crear mis propias automatizaciones.
Independientemente del caso en el que te encuentres, es recomendable que trates de automatizar tú mismo el proceso. Es un fantástico ejercicio porque te va a obligar a diseñar un flujo de trabajo, a fijar las variables que caracterizan el problema y a explorar los límites de la aplicabilidad de la teoría o el modelo de cálculo en cuestión.
Es posible alegar que esto no tiene sentido hoy en día porque hay programas de cálculo que aparentemente se encargan de todo, pero, con el nivel de complejidad de las normas actuales y la sofisticación de estos programas, el ingeniero se convierte en un espectador que debe hacer un acto de fe cuando analiza los resultados. No, no soy un negacionista del software de cálculo, más bien todo lo contrario, pero creo que un ingeniero que calcula debe ejercer un control sobre el programa que utiliza porque necesita anticipar con suficiente precisión los resultados globales y el dimensionamiento de los elementos para validar la estructura.
Esta es, con diferencia, la razón fundamental por la que aún me sigo molestando en automatizar mis dimensionamientos, pero no es la única. Es, por ejemplo, una fantástica herramienta para complementar las fórmulas o parámetros ajustándolas a tus criterios, o para poder resolver el problema con formulaciones o normas diferentes que te ayudan mucho a tener una visión de conjunto. Además, raro es el programa de cálculo que no permite la exportación de resultados en formato texto o, directamente, en EXCEL, por lo que no es difícil llegar a realizar una herramienta de cálculo masivo basada en los esfuerzos de tu programa de cálculo preferido.
Además, al menos en mi caso, tengo mucho interés en controlar la salida de resultados, tanto para facilitar la revisión de los cálculos por un tercero, como para tener la capacidad de revisar el proyecto con el paso del tiempo. Nunca me gustaron las salidas basadas en listados infinitos donde tienes que bucear entre los miles de barras, nudos e hipótesis para poder rescatar algún resultado. Personalmente, soy más de usar gráficos que condensen la información y las hipótesis de carga, o resúmenes escuetos en los que se verifican solo los elementos que consideremos pésimos.
2.- El largo camino de la automatización
2.1.- Primeros pasos: las hojas de cálculo
Está claro que, si hay que buscar un programa universal entre todos los ingenieros, ese es el EXCEL. No es el más eficiente guardando datos, ni es el más rápido, pero es el software que podemos orientar a la automatización con una curva de aprendizaje más suave. Dependiendo de tus habilidades y del tiempo que emplees, puedes hacer desde una hoja en la que simplemente introduces los datos de una fórmula hasta verdaderos programas de cálculo.
Desde mi punto de vista, sus principales inconvenientes son la dificultad para el mantenimiento de las hojas de cálculo por lo complejo que resulta revisar fórmulas en las que intervienen multitud de parámetros y, relacionado en cierta forma con lo anterior, que la salida de resultados es muy poco transparente en lo relativo a la relación que hay entre los elementos.
Esto me empujó a probar alternativas como el Mathcad, donde construyes tu hoja como si de una memoria de cálculo se tratase, alternando imágenes, textos, resultados, gráficos, etc. (aquí puedes ver algunos ejemplos). Además, este programa permite el uso de unidades en las variables, lo cual te quita muchos dolores de cabeza (aunque también te da alguno). Hay otras alternativas similares, pero, si tengo que elegir, creo que el Mathcad guarda el mejor equilibrio entre dificultad y funcionalidad.
Pero el uso de programas de hojas de cálculo tiene sentido cuando se enfocan o bien a estructuras muy simples donde los esfuerzos son relativamente inmediatos o bien al proceso de dimensionamiento partiendo de unos esfuerzos que obtenemos con un programa de cálculo, pero esto no siempre es así.
2.2.- En busca del 'santo Grial': los lenguajes de programación
En mi caso, una parte importante de mi trabajo como ingeniero ha consistido y consiste en optimizar las estructuras para ahorrar en su ejecución. Esto hace que en algunos proyectos deba calcular una y otra vez variantes de la misma estructura para ver hasta dónde se pueden ajustar las dimensiones y los materiales empleados o para ver cuanto más cara en materiales es cierta variante que presenta importantes ventajas constructivas (ventajas = tiempo = dinero). Así que, cuando repites por tercera vez los mismos cálculos, desearías tener una aplicación que calcule exactamente tu estructura con solo decirle que es la variante con tres soportes en vez de con dos.
Además, desde hace unos años, hay dos factores que van, poco a poco, alterando las reglas con las que estaba acostumbrado a moverme. El primero de ellos se refiere a la deficiente organización de la estructura (no quiero sembrar una excesiva polémica con este aspecto, pero es una realidad que la estructura ha pasado, con suerte, a un segundo plano y los especialistas en esta área acceden al proceso tarde y sin capacidad de establecer sus criterios). Esto deriva en que muchos de los proyectos que llegan a mis manos no presentan un camino claro de las cargas hacia los niveles de cimentación, y requieren de la incorporación de elementos estructurales singulares, sin que se pueda abordar el problema desde el rediseño y la reorganización de la estructura.
En este escenario, la fase de predimensionamiento se complica mucho en algunas ocasiones, ya que las estructuras tienen un comportamiento hiperestático complejo en el que es difícil acotar los valores máximos de esfuerzos que van a soportar muchos de sus elementos (¿has probado alguna vez a ver cómo influye el proceso constructivo en los esfuerzos que recibe una viga de apeo?). En estos casos, no es posible usar un modelo de cálculo que permita la obtención de resultados de forma manual, sino que debes apoyarte en modelos numéricos, aunque tengan una forma simplificada, para capturar la rigidez de los elementos más relevantes y poder acotar los esfuerzos que actúan sobre un elemento en concreto.
El segundo factor está relacionado con el creciente incremento de la complejidad de las normas de cálculo. Es posible que en algunos casos, como los elementos de pared delgada, tenga cierta justificación (el comportamiento de elementos de menos de 3 milímetros de espesor que llevamos al límite de su capacidad es complejo en sí mismo), pero en otros creo se está perdiendo el norte poco a poco, especialmente cuando hablamos de estructuras no singulares.
Este factor obliga, en la práctica, a emplear programas de cálculo para que incluyan, por ejemplo, cálculos relativos a la pérdida de rigidez por fisuración del hormigón, o modos de pandeo que tengan en cuenta la abolladura o que simplemente incluyan las casi infinitas combinaciones de cálculo que se requieren en las normas europeas. De nuevo, nos vemos obligados a incluir en el flujo de trabajo el uso de un programa de cálculo con el modelo estructural completo, aunque sea en una versión simplificada.
Cuando tienes que hacer pruebas para tantear soluciones o cuando tienes que modificar la estructura para tantear la estabilidad de la solución, es necesario poder actuar rápidamente sobre el modelo de cálculo para crear versiones nuevas de la estructura sin que ello conlleve horas y horas de modelado en el software que empleemos para el cálculo.
Esto era algo que se hacía fácilmente en los primeros programas de estructuras que yo empecé a utilizar. La estructura se introducía mediante un archivo de texto en el que se podían incluir bucles, cláusulas condicionales e incluso podías incluir variables, pero se perdió rápidamente cuando se desarrollaron las potentes interfaces gráficas en estos mismos programas, que permitían cambiar el material en un bonito cuadro de diálogo o elegir con el ratón los elementos a los que afectaba la nueva sección. Si bien estas nuevas interfaces son mucho más claras y ágiles para introducir un único modelo y manipularlo una vez construido, eliminan la posibilidad de automatizar la entrada de datos.
Algunos ejemplos que siguen permitiendo la programación de los archivos de entrada de datos son el ANSYS en su entorno APDL, el CODE-ASTER o en el OpenFOAM. Otros programas que no son ajenos a estas necesidades son el SAP2000, que te ofrece su API para que te conectes a sus funciones con alguno de los lenguajes de programación más populares, o el ANSYS WORKBENCH, que permite “grabar” macros en PYTHON que luego puedes depurar y simplificar para automatizar la creación de geometrías. Finalmente, otros como el CONSTEEL te ofrecen un entorno de programación con su propio lenguaje.
Sin embargo, todos ellos comparten la necesidad de poseer ciertos conocimientos de programación, tener que aprender algo de un lenguaje de programación en concreto y tener que bucear entre líneas de código para poder trasladar tu algoritmo de cálculo. Cuando usas en tu trabajo varios de estos programas, se hace complicado justificar la inversión de tiempo que te hace falta para familiarizarte con las particularidades de cada lenguaje.
...la economía de una obra no está en la minuciosa valoración de unas solicitaciones calculadas con ilusoria precisión, sino en el acertado equilibrio en la disposición general de la estructura y, muy especialmente, en la adecuación de la misma al servicio requerido.
2.3.- 'NO CODE': la democratización de la automatización
Mientras llega el momento en el que la inteligencia artificial se encargue de buscar la variante estructural óptima sin que tengamos que programar ni una sola línea de código (esto no es broma y está mucho más cerca de lo que crees), un nuevo movimiento llamado NO-CODE promete democratizar la programación, eliminando la necesidad del lenguaje de programación.
El uso de una plataforma NO-CODE permite crear algoritmos de una forma gráfica y visual en el que el usuario conecta cajas como si de un mapa mental se tratara. Obviamente es necesario que sepas desarrollar un algoritmo, pero realmente es algo que todos hacemos de forma continua, y solo debes entrenarte en ser capaz de plasmarlo en un papel. No es que sea fácil o difícil, eso va a depender de lo complejo que sea los que quieres automatizar, pero elimina la curva de aprendizaje que se refiere al lenguaje de programación.
Este movimiento, que está relativamente extendido en los negocios virtuales, empieza a cuajar en el ámbito de las estructuras. Que yo conozca, el mejor exponente de la programación NO-CODE en nuestro sector lo encontramos con el programa de dibujo Rhinoceros 3D, que tiene un ADDON llamado GRASHOPPER que te permite parametrizar por completo tu dibujo en un entorno NO-CODE. Este ADDON tiene, además, infinidad de PLUGINS que permiten automatizar un sinfín de tareas, dentro de las cuales se encuentran algunas relacionadas con programas de estructuras como el IDEA STATICA o el CONSTEEL, y con programas de dibujo como el TEKKLA.
Aunque parezca enrevesado, este flujo de trabajo tiene la inmensa ventaja de que solo tienes que aprender a manejar bien el GRASHOPPER. Una vez que lo entiendas y sepas como automatizar geometrías, podrás usar los PLUGINS para conectar tu entrada de datos con un programa en concreto. Por supuesto, que cada uno de los PLUGINS tendrá componentes específicos, pero, si dominas el programa principal, te adaptarás casi de forma inmediata a su uso. El inconveniente es que los desarrolladores de tu software de estructuras tienen que haber tenido la inquietud de desarrollar el PLUGIN que conecte ambas plataformas.
Por último, creo que dominar programas de este tipo va a ser una gran competencia para el ingeniero de los próximos años porque, conforme aumenta la capacidad de computación, los programas de cálculo son capaces de estudiar estructuras de una forma más detallada,el que
3.- Automatizar para luego parametrizar
Una vez que logras automatizar un cálculo, creo que el siguiente paso es crear una colección de soluciones “estandarizadas” que permitan resolver el siguiente caso sin necesidad de abrir el ordenador. Obviamente, esta idea está lejos de ser una genialidad, basta con echar la mirada atrás para ver que esta inquietud no es nueva en la ingeniería civil. Hay infinidad de ejemplos en los numerosos ábacos de cálculo que han ayudado a los ingenieros con las operaciones más complejas desde hace más de cien años. Cuando yo estudié la carrera, aún usábamos los ábacos en muchos cálculos geotécnicos e hidráulicos.
Cuando se fue generalizando el uso del software de cálculo, nuestro camino se fue apartando del de estos ábacos y tablas. Ya no hacía falta simplificar el problema para encajarlo en esos gráficos de mil curvas, podíamos calcular cada vez el caso concreto e incluso podíamos emplear dos decimales en el valor del ángulo de rozamiento interno. Y entonces empezaron a aparecer más y más variables en nuestro cálculo, que se transformaban en más menús y más cuadros de diálogo, y al final nos quedamos a oscuras porque perdimos el control de lo que estábamos haciendo.
Si tus trabajos de ingeniería son siempre distintos, estas soluciones se deben ceñir a elementos estándar básicos, como correas, punzonamiento, zapatas, etc. Si tienes estructuras que se repiten muy a menudo, puedes ser ambicioso y condensar los casos más habituales porque la escala de la estructura a parametrizar no es un factor determinante, simplemente hay que cambiar la mentalidad y empezar a tratar tus estructuras como un producto que pones una y otra vez en el mercado con pequeñas variaciones.
Hay multitud de ejemplos relacionados con la parametrización de estructuras completas. En España, por ejemplo, podríamos hablar de la parametrización de estructuras que se recogían en las normas tecnológicas que recopilaban unos predimensionamientos muy completos, que incluían incluso fórmulas para realizar mediciones, cubriendo una gran variedad de temas, desde excavaciones hasta abastecimiento de agua, o de los libros de muros de contención y de cálculo de cimentaciones de J. Calavera (INTEMAC S.A.), que tenían, además de las correspondientes explicaciones para el dimensionamiento y el cálculo, unos ábacos para el dimensionamiento de la geometría y de las armaduras de la estructura.
Aunque no llegué a usarlos, recuerdo los catálogos de pasarelas del Ministerio de Obras Públicas, que recogían modelos de pasos para peatones por encima de las autopistas para diferentes luces, con sus planos y sus mediciones completas.
Otro gran trabajo, que conozco de primera mano, es el relativo a la parametrización en el campo de las naves industriales realizado por Javier Errera (Dasein ingenieros S.L.) y que culmina con la publicación de la ‘Guía para el Diseño estructural en acero de naves industriales ligeras‘ (DEANIL), donde, a partir de datos como la modulación, la luz, la altura y las cargas de viento y nieve, eres capaz de obtener una nave industrial perfectamente definida y detallada.
La pena es que algunos de estos documentos han quedado obsoletos por los cambios normativos que se han ido sucediendo (lo que da pie a un interesante debate sobre si también han quedado obsoletas las estructuras desde el punto de vista de la seguridad, la funcionalidad y la durabilidad, porque personalmente no creo que sea así), y no podemos usarlos sin riesgo de que nos digan que no cumplen con los criterios normativos actuales.
Personalmente, tengo el propósito de buscar un flujo de trabajo que me permita retomar en mis dimensionamientos el uso de ábacos y tablas. Parece inmediato, pero la complejidad de las normas, los cambios que se realizan en estas y la necesidad de calcular bajo el paraguas de normativas diferentes en función de la ubicación de la estructura, hace imposible tener una colección de tablas únicas, lo que nos lleva al título de esta sección: automatizar para luego parametrizar.