Muchos de los fenómenos de la vida real, se pueden modelar matemáticamente, aunque en la mayoría de los casos no se consigue solucionarlos por medio de algún método exacto y aunque algunas veces puede lograrse una solución, la misma puede resultar demasiado laboriosa en términos de tiempo y de recursos computacionales

Los Métodos Numéricos (MN) tratan de solucionan este tipo de problemas mediante la búsqueda de una solución numérica aproximada y su cálculo del error asociado (el cual se espera que sea razonablemente pequeño) mediante algoritmos, que permiten la resolución de algunos complejos problemas matemáticos que generalmente no pueden resolverse con los métodos analíticos tradicionales. Sus aplicaciones son inmensas, y se utilizan intensivamente en ingeniería, economía y ciencias naturales.

Salvo en raras ocasiones los datos proporcionados a estos cálculos son exactos, puesto que suelen originarse en procesos de medida, aunque casi siempre hay un error probable en la información de entrada y además, el propio algoritmo introduce también otros errores o redondeos inevitables. Por todo ello la información de salida de un programa informático que utilice MN podrá contener los errores generados por ambas fuentes.El error obtenido podríamos definirlo como la discrepancia entre la magnitud “verdadera” y la «obtenida» en el cálculo. Vamos a explicarlo con un ejemplo:

Imaginemos el número 0.1 decimal que debe almacenarse en un microprocesador. Estos aparatos almacenan los números y caracteres en lenguaje binario, por lo que lo primero que tiene que hacer el mismo es transformar ese número decimal a binario. El MN utilizado utiliza un algoritmo como este:

1) Se toma el número a transformar y se multiplica por 2:

0.1 * 2 = 0.2

2) Se separa la parte entera de la parte decimal del valor resultante

La parte entera de 0.2 es 0
La parte decimal de 0.2 es 0.2

3) La parte entera se toma como el primer dígito significativo del número binario. Saldría así:

0.0______

3) Para los siguientes dígitos binarios se repiten los pasos 1 y 2 usando la parte decimal obtenida del paso anterior y repitiendo este proceso hasta que el resultado obtenido sea cero o se obtenga una secuencia periódica. Es decir:

0.2 * 2 = 0.4 -> 0

Este sería el segundo dígito del número binario que quedaría así:

0.00______

0.4 * 2 = 0.8 -> 0

Este sería el tercer dígito del número binario que quedaría así:

0.000______

0.8 * 2 = 1.6 -> 1

Este sería el cuarto dígito del número binario que quedaría así:

0.0001______

0.6 * 2 = 1.2 -> 1

Este sería el quinto dígito del número binario que quedaría así:

0.00011______

0.2 * 2 = 0.4 -> 0

Y al obtenerlo vuelve a reiniciarse la secuencia

Es decir que con este algoritmo el ordenador obtiene la representación binaria del número decimal 0.1 que es:

0.00011…….. periódico

Como las computadoras tienen una cantidad finita de bits para almacenar cualquier número, los números periódicos se almacenarán truncados. O sea que nuestra computadora solo almacenará el valor 0.00011 y no el «valor real» de los cálculos que sería 0.000110011001100110011… (hasta el infinito), pero. en la práctica lo que se almacena en la computadora al convertir el binario a decimal sería este número:

0.00011 = 1/16 + 1/32 = 0.09375

Y ya empezamos con los problemas de precisión pues no es lo mismo almacenar el número 0.1 en la computadora que el número 0.09375.

Esto puede ser un error tolerable, pero a veces los cálculos numéricos fallan estrepitosamente en un ordenador por problemas de su arquitectura o diseño del software y entonces pueden originarse errores muy costosos porque el sistema no es capaz de interpretar correctamente los algoritmos numéricos. Hoy vamos a exponer tres casos muy famosos

Primero .- Los errores de redondeo del sistema de guiado del misil «Patriot»

El sistema de misiles «Patriot» es un sistema móvil de Defensa Aérea con posibilidad de actuar a cortos y largos alcances, desde muy baja a media altura, con capacidad todo tiempo y que utiliza misiles guiados que simultáneamente enganchan y destruyen múltiples objetivos tales como misiles balísticos tácticos (TBM,s), objetivos de pequeña sección radar (LRCS), misiles de crucero (CM,s) y objetivos convencionales (aviones de ultima generación y helicópteros) desde muy baja a media altura bajo un ambiente de contramedidas electrónicas.

El 25 de febrero de 1991, durante la Guerra del Golfo, una batería de misiles Patriot estadounidense en Dharan, Arabia Saudita, no logró interceptar un misil Scud iraquí entrante .El Scud posteriormente impactó contra un cuartel del ejército estadounidense y mató a 28 soldados. Un informe de la General Accounting Office titulado Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia informó sobre la causa de aquel fallo manifestando que fue un cálculo incorrecto del tiempo transcurrido desde el arranque debido a un error de redondeo en el software de guiado del ordenador del misil «Patriot«.

En concreto, se trató del cálculo del tiempo en décimas de segundo, medido por el reloj interno del sistema del misil que multiplicaba por 1/10 (en binario) para sacar el tiempo en segundos. Este cálculo se realizó con un registro de punto fijo de 24 bits. Vamos a explicar lo que pasó.

El error de redondeo es debido a las limitaciones propias del aparato que usa el método numérico para representar cantidades que requieren un gran número de dígitos. Se produce en máquinas con arquitectura de Punto Fijo que fueron introducidas comienzos de la década de los 80, y que están basadas en una representación que contiene una cantidad fija de dígitos después del llamado «radix point«.

En notación decimal (base10) la coma separa los decimales pero en la notación binaria (base 2) usada por los ordenadores solo se usan potencias de 2. Así por ejemplo el número 13,625 (base 10 decimal) en base 2 (binario) es 1101.101. El punto de corte lo llamamos «radix point» y por eso el número 1101.101 binario que representa al 13,625 tiene las siguientes cifras:

Por lo que su conversión en decimal se puede calcular de esta manera

Como vemos el 1101, que está a la izquierda del «radix point» es la representación binaria del número decimal 13 y a la derecha de ese «radix point» está el 101, que es la representación binaria de la fracción decimal 625/1000 ( o 5/8).

En el sistema de guiado del aquel misil el valor 1/10, se cortó a 24 bits después del «radix point«. Se trata de un pequeño error pero que cuando se multiplica por un gran número para calcular el tiempo en décimas de segundo, puede originar un error mucho más significativo. En efecto, la batería de aquel Patriot tenía una autonomía de alrededor de 100 horas, y un cálculo fácil nos muestra cómo el error del tiempo resultante calculado debido al error del corte del «radix point» por haber usado en el misil una máquina de arquitectura de Punto Fijo fue de aproximadamente 0,34 segundos.

¿ Y ello por qué? Pues porque la arquitectura de punto fijo nos permite representar magnitudes mayores pero sólo a costa de reducir la precisión después del «radix point«, es decir que hay una pérdida de precisión en las operaciones matemáticas en las que el resultado tiende a ser de mayor orden que los operandos. Veamos esta multiplicación en binario y como la toma el ordenador

La máquina considera «overflow» parte de los datos a la izquierda y no los representa pero a la derecha también corta y descarta parte de los datos. Veamos los cálculos que hizo para aquel misil fallido

El número 1/10 es igual a

Y su expresión binaria sería

0,0001100110011001100110011001100 ….

Con la arquitectura de Punto Fijo (registro de 24 bits) el Patriot solo pudo almacenar este otro numero

0.00011001100110011001100

Despreciando el resto a la derecha del último cero que era ….. 11001100 esto supuso introducir un error de:0,0000000000000000000000011001100 … en binario, que viene a ser de alrededor de 0,000000095 en decimal. No parece muy grande pero si multiplicamos este error por el número de décimas de segundo que hay en las 100 horas que dura la batería del misil obtenemos este resultado:

0,000000095 × 100 × 60 × 60 × 10 = 0,34

Y 0,34 segundos son mucho porque un misil Scud iraquí se desplazaba a unos 1.676 metros por segundo, y en 0,34 segundos tiene tiempo suficiente para recorrer más de medio kilómetro y quedar fuera del «radio de alcance» del misil interceptador Patriot que iba siguiéndolo.

Irónicamente, el hecho de que el cálculo defectuoso del tiempo se había mejorado en algunas partes del código de programación no se pudo depurar en su totalidad y la cosa acabó en un desastre. El siguiente párrafo está extraído del informe de la GAO.

«La predicción del umbral de distancia del lugar donde aparecería el Scud es una función de la velocidad conocida de este misil y del tiempo de la última detección de radar. La velocidad es un número real que puede ser expresado como un número entero y un decimal (por ejemplo, 3750,2563 … millas por hora). La hora se mantiene continuamente por el reloj interno del sistema en décimas de segundo, pero se expresa como un número entero o un conjunto numérico (por ejemplo, 32, 33, 34 …). Cuanto mayor es el tiempo en el que el sistema ha estado funcionando, mayor es el número que representa ese tiempo. Para predecir dónde aparecerá el Scud, tanto el tiempo como velocidad se expresan como números reales y debido a la forma en que el ordenador Patriot realiza sus cálculos y el hecho de que sus registros sean sólo de 24 bits la conversión de tiempo de un número entero binario a un número real no puede ser más precisa en ese formato de 24 bits. Esta conversión se traduce en una pérdida de precisión haciendo el cálculo de tiempo menos preciso. El efecto de esta inexactitud en el cálculo del umbral de distancia es directamente proporcional a la velocidad del objetivo y a la duración del tiempo en que el sistema ha estado funcionando. En consecuencia la realización de la conversión después de que el Patriot estuvo funcionando de forma continua durante largos periodos de tiempo hizo que la puerta de distancia ocasionara un alejamiento del centro de la diana por lo que es menos probable que el objetivo-en este caso el Scud- fuese interceptado con éxito». Este es el Informe de la GAO (General Accounting Office ( GAO/IMTEC-92-26.)-

Segundo.- Las consecuencia de un simple desbordamiento en el SRI del Ariane 5

El 4 de junio 1996, el primer cohete no tripulado Ariane 5, fruto del más ambicioso proyecto de la Agencia Espacial Europea fue lanzado desde la base espacial de Kourou en la Guayana Francesa y transcurridos 37 segundos desde el encendido del motor principal Vulcain, se autodestruyó a 3.400 metros de altura. El cohete estaba en su primer viaje, después de una década de desarrollo con una inversión de 7 mil millones de dólares y el artefacto destruido y su carga fueron valorados en 500 millones de dólares

Técnicamente, la causa del desastre se describió como una «excepción de software«, ese mensaje que muchos hemos visto en las «pantallas azules» de Windows cuando nuestro ordenador se cuelga estrepitosamente.

Uno de ellos es el error de precisión de números denominado ‘coma flotante‘ que afecta a todos los lenguajes de programación. Los algoritmos aritméticos para las representaciones en ‘coma flotante’ deben de tener en cuenta el escalado, es decir, el conocer la posición correcta del punto donde se localiza la separación entre la parte entera y la parte decimal ya que todo dato en un computador, debe ser almacenado en un registro con un número finito de bits.

Siempre que la parte entera del resultado de un cálculo sea mayor que el número máximo de dígitos que la computadora puede mostrar, el resultado generará un error de desbordamiento. Con esto, algunas operaciones matemática pueden producir reboses, por generar resultados mayores que la capacidad storeable de la computadora. En lenguaje de programación los números de ‘coma flotante’ son otra forma de decir ‘números decimales‘ y un ‘overflow‘ también llamado ‘desbordamiento aritmético‘ es una condición que se produce en un ordenador cuando un cálculo produce un resultado de mayor magnitud que la que un determinado registro puede almacenar. Sería algo así como si al convertir un valor como ‘32790,789‘ en un número entero si el mismo supera el mayor número storeable en el registro de la computadora en vez de obtenerse el valor ‘32790‘ se nos diera otro como ‘0‘, ‘-500‘ o un error similar

En el caso de Ariane 5 el problema estaba en un código matemático del ordenador de abordo que produjo un error de software en el Sistema de Referencia Inercial del sistema de control de vuelo del mismo (SRI). La actitud del lanzador y sus movimientos en el espacio son medidos por estos SRI en el que ángulos y las velocidades se calculan en base a la información proporcionada desde una plataforma inercial dotada de acelerómetros y giróscopos. El SRI del Ariane 5 era el que se había usado en el Ariane 4, sin contar con que el Ariane 5 era un aparato con mayor potencia y distintas variables de dirección que no tenía el Ariane 4, y a pesar de que se disponían de dos equipos iguales para evitar problemas (llamados SRI1 y SRI2) no sirvió de nada porque falló primero el de reserva, y en menos de un segundo el otro, cargado ya con información errónea de su compañero.

Cuando se intentó la conversión de un número ‘coma flotante de 64 bits‘ que daba la velocidad horizontal del cohete con respecto a la plataforma a un ‘entero de 16 bits‘ no se logró la conversión porque se produjo un simple desbordamiento, ya que para los números enteros de 16 bits el mayor número storeable es 32767. Con este error los datos enviados superaban este número y desbordaron rápidamente la capacidad de los dos SRI. El programa enloqueció y empezó a transmitir informaciones erróneas al ordenador central, que a su vez dió la orden de corregir una desviación que no existía colocando al cohete en una trayectoria imposible. Curiosamente esa parte del código sólo se usaba durante la preparación para el despegue y una vez en marcha no tenía utilidad pero por un error de programación ese código continuaba funcionando durante 40 segundos tras el despegue.

Se creó un comité investigador,presidido por el matemático francés Jacques_Louis Lions con nueve miembros, En su informe se explica el problema en los párrafos siguientes del mismo

«El 4 de junio de 1996, el primer vuelo de la lanzadera Ariane 5 terminó en un fracaso. Sólo unos 40 segundos después de iniciar la secuencia de vuelo, a una altitud de aproximadamente 3700 m, el lanzador se salió de su trayectoria de vuelo, se rompió y explotó.

El fracaso del Ariane 501 fue causado por la pérdida completa de la orientación y la actitud de la información 37 segundos después del inicio de la secuencia de arranque del motor principal (30 segundos después del despegue). Esta pérdida de información se debió a la especificación y diseño errores en el software del sistema de referencia inercial.

El SRI [ Système de Référence inertielle o sistema de referencia inercial] tuvo excepción de su software interno causada durante la ejecución de una conversión de datos de coma flotante de 64 bits de valor entero con signo de 16 bits. El número de coma flotante que se convirtió tenía un valor mayor que lo que podría ser representado por un entero con signo de 16 bits.

Las compañías que fabricaron los componentes defectuosos, fueron las francesas MatraMarconi, como coordinadoras y Sextant, como suministradora del Sistema de Referencia Inertial (SRI). Sé indicó también que la responsabilidad debía también extenderse a la Sociedad Aerospatiale Francesa que, como encargada de la arquitectura industrial del proyecto formuló mal las especificaciones sobre las que trabajaron Marconi y Sextant y por último también se imputó al CNES la Agencia Espacial francesa,contratista del proyecto por no haber desarrollado un sistema de verificación que impidiese esos fallos de base. Este fue el informe de aquella Junta de Investigación y aquí pongo el vídeo de aquel desastre

Tercero.- Análisis de elementos finitos en el diseño de las celdas de flotación de la plataforma petrolera Sleipner A-1

En la mañana del Viernes, 23. agosto de 1991 en Gjandsfjord cerca de Stavanger (suroeste de la costa Noruega en el Mar del Norte) la plataforma petrolera Sleipner A-1 realizó la prueba de lastre controlado de sus flotadores antes de proceder al apareamiento con su cubierta y apareció un fallo en uno de ellos que tuvo una fuga, comenzando a hacer agua. En menos de 19 minutos se hundió completamente y aquel accidente causó un evento sísmico de clase 3.0 en la escala de Richter convirtiéndose en un montón de escombros que se hundieron a 220m de profundidad. Aquel fracaso no tuvo perdidas de vidas humanas pero implicó una pérdida económica total de alrededor de 700 millones de dólares.

La posterior investigación del accidente descubrió que hubo un error de aproximación inexacta en el cálculo de una de las celdas de los flotadores realizado por el método de análisis de elementos finitos del modelo elástico lineal de la Tricell (utilizando el popular programa de elementos finitos de nombre NASTRAN).

El  Analisis de elementos finitos  (FEA de sussiglas en inglés «Finite Element Analysis) es una técnica de simulación por computador y un método numérico de resolución de problemas de mecánica de sólidos. Se trata de una herramienta de cálculo muy potente para el cálculo de estructuras cuya idea básica no puede ser más sencilla: dado un sólido, sometido a un sistema de cargas coaccionado por unas ligaduras, el método consiste en subdividir este sólido en pequeñas partes (elementos) interconectadas entre sí a través de los nudos de los elementos, de manera que suponemos que, el campo de desplazamientos en el interior de cada elemento, puede expresarse en función de los desplazamientos que sufren los nudos del elemento (desplazamientos nodales).

Posteriormente, se podrá determinar la matriz de rigidez de cada elemento, las cuales una vez ensambladas (siguiendo los pasos del análisis matricial de estructuras), permitirán la obtención de los desplazamientos en los nudos de cada elemento.De esa manera, una vez conocidos dichos desplazamientos, podríamos determinar, de una forma aproximada-como ya dijimos antes- las tensiones y las deformaciones en el interior del elemento.

Esta técnica se encuentra automatizada en herramientas de software y es muy utilizada en ingeniería debido a que muchos problemas físicos se formulan mediante la resolución de una ecuación diferencial en derivadas parciales, a partir de cuya solución es posible modelar dicho problema (transmisión del calor, electromagnetismo, cálculo de estructuras, etc). sin embargo, es un método que no proporciona una solución “exacta” a un problema dado, sino que, en realidad, solo posibilita obtener una solución aproximada

Con este soft se calcularon los apoyos de aquella plataforma llamada Sleipner A (SLA-1) que se iba a utilizar para la extracción de petróleo y gas natural en el yacimiento de gas Sleipner, en el mar del Norte y vamos a explicar el proceso constructivo

Aquella plataforma petrolera se diseñó a la manera de las plataformas tipo Condeep que se forman con una estructura de base de hormigón de gravedad formada por 24 celdas. En la Sleipner A aquellas celdas de flotación tenían un área de la base total de 16.000 m2 y debían apoyarse en el fondo marino a una profundidad de 82 m.

El proceso de construcción de una plataforma Condeep se inicia en un dique seco, donde se construyen las celdas de flotación. Como antes dijimos aquellas 24 celdas se diseñaron y calcularon por un software de elementos finitos.

Cuatro de estas células son alargadas para servir de ejes de apoyo de la cubierta de la plataforma. Esta era la cubierta superior que pesaba 57.000 toneladas, y proporcionaría alojamiento para unas 200 personas y el apoyo a los equipos de perforación que pesaban alrededor de 40.000 toneladas.

Mientras se construye la plataforma se terminan las celdas de flotación y se bombea agua a para hundir la estructura pero se mantiene la construcción de esta plataforma cerca del agua. Una vez que se ha completado la estructura de esa plataforma con los cuatro soportes en donde debe apoyarse, se somete el conjunto de los flotadores a una prueba de lastre controlado. Si la misma se supera entonces se procede al apareamiento entre cubierta y flotadores y pueden liberarse las células de flotación que levantan la cubierta en el aire. Así queda la plataforma terminada y se la puede llevar flotando hasta su ubicación final donde será anclada en el fondo.

Como resultado de la necesidad de hacer flotar una estructura tan pesada de hormigón, hay que hacer los cálculos con mucha exactitud y uno de los factores críticos de diseño para una plataforma petrolera en alta mar es el espesor de la pared celular de flotabilidad: si las paredes son demasiado delgadas, se romperán durante el apareamiento con la cubierta y si son demasiado gruesas, la estructura simplemente no flotará o será difícil de mover a su destino final. Para hacer frente a la delgada línea que existe entre paredes «demasiado gruesas» o «demasiado delgadas«, se tiene que hacer un análisis muy preciso de la geometría de la celda de flotación y eso se hizo con el software de Análisis de elementos finito NASTRAN.

El Sleipner A-1 estaba programado para el apareamiento entre cubierta y flotadores el 1 de septiembre de 1991 y se hizo la prueba de lastre el 23. agosto de 1991. En la misma la cosa falló por un defectuoso cálculo en el Análisis de elementos finitos en una de las celdas de flotación resultando que los esfuerzos de corte se subestimaron en un 47%, y esto llevó a un diseño insuficiente. En particular, algunos muros de hormigón no eran lo suficientemente gruesos y uno de ellos se rompió, El fracaso de la pared celular fue rastreado como se indica en el siguiente diagrama.

Se concluyó que las paredes de las células marcadas fueron los puntos más débiles de la plataforma; Los cálculos basados en el Análisis de elementos finitos mostraron que la carga en estas partes estaba muy cerca de su capacidad máxima y hubo posiblemente un aplastamiento del hormigón en la intersección entre la pared celular tri y la articulación de la célula.

Más información se puede encontrar en los artículos siguientes:

La plataforma Sleipner accidentes, por B. Jakobsen y F. Rosendahl, Ingeniería Estructural Internacional 4 (3), agosto de 1994, pp. 190-193.

El fracaso de una plataforma offshore, por RG Selby, FJ Vecchio, y MP Collins, Hormigón Internacional 19 (8), agosto de 1997, pp. 28-35.

Y aquí tenemos un vídeo de aquel desastre

El uso del software lleva implícito el error humano y cuando se programa software de complejidad considerable, los desastres atribuibles a malos cálculos numéricos en los ordenadores implicados pueden causar perdidas muy considerables. Ya lo dijo Voltaire (1694-1778) aquel filósofo y escritor francés cuando afirmó eso de que: «el hombre se precipita en el error con más rapidez que los ríos corren hacia el mar»

Fuentes:

https://en.wikipedia.org/wiki/Radix_point

http://www.math.umn.edu/~arnold/disasters/patriot.html por Douglas N. Arnold

http://www.math.umn.edu/~arnold/disasters/ariane.html por Douglas N. Arnold