En programación existen muchos métodos para la búsqueda de soluciones de problemas.
El más simple de implementar computacionalmente, el más básico, el más trivial, es el de la “fuerza bruta”.
¿En qué consiste?
En ir probando valores, de la variable desconocida, en una ecuación hasta que se llegue a la solución.
Piensa en la siguiente ecuación (sí, muy básica, lo sé, pero tampoco vamos a dar una clase de métodos numéricos aquí, ¿verdad):
X + 2 = 10
Aquí, por fuerza bruta, un programa debería probar, iterativamente, valores de X desde cero hasta que la suma de los valores a la izquierda sea igual a 10.
¿A que es fácil?
Desventaja: que es computacionalmente ineficiente pues, dependiendo del problema, puedes estar toda una vida —algo exagerado de mi parte, cierto— probando números.
Pero la verdad es que, en la mayoría de los casos, llegas siempre a un resultado.
Respecto a esto de la “ineficiencia computacional”, recuerdo que, cuando realizábamos el plan maestro de la red de acueducto de la zona norte de Valencia (Venezuela), por allá por los años 90 del siglo pasado, yo tenía un programa muy básico para la “optimización” de redes creado en lenguaje Quick Basic.
Ese programa lo que hacía era resolver la red utilizando métodos matriciales —lo mismo que hace nuestro AQUEDUCTOS— pero, después de resolver la red, modificaba los diámetros en los que, por ejemplo, la pérdida de carga excediera cierto valor.
El proceso era:
Paso 0: fijar diámetros “a ojo”. Yo hacía la distribución manual de caudales y, en base a una velocidad de diseño, fijaba un diámetro inicial para cada tramo.
Paso 1: Se realizaba el cálculo —balance hidráulico— de la red.
Paso 2: Con los caudales obtenidos del paso anterior se determinaban las pérdidas unitarias de cada tramo. Fijamos uno de 2 m/Km de pérdida unitaria máxima.
Paso 3: Para aquellas tuberías con una pérdida unitaria mayor a 2 m/Km, se aumentaba el diámetro al siguiente tamaño en la lista de diámetros comerciales.
Paso 4: Repetir los pasos anteriores (excluyendo el 0, claro) hasta que todas las tuberías cumplieran la condición.
Esto fue una implementación por fuerza bruta clásica. Bueno, también había algo de brutalidad en mi forma de analizar estos problemas en aquella época, pero no me lo tomes en cuenta (inexperiencia-flojera, ya sabes).
En fin. Para esa red, que no tendría más de 100 tramos de tubería recuerdo que la corrida —en un “super” computador 386 de la época— tardó unas tres horas.
Imagínate eso!!!
Pero, como necesitábamos rapidez (la idea era probar diversas opciones de distribución), tres horas resultaba demasiado.
¿Qué hice?
¿Buscar un método más eficiente?
¡Que va!
(recuerda, soy ingeniero civil: practicidad total y además
estaba lo de mi brutalidad referida previamente).
Lo que hice fue cambiar el lenguaje de programación.
Un profesor de la Universidad en la que hacía el posgrado, me recomendó utilizar FORTRAN por ser más eficiente (computacionalmente).
Un lenguaje que yo asumía como desaparecido — se utilizaba cuando los computadores se programaban con tarjetas, tarjetas de cartón, por cierto—.
Pues, bien, realicé la traducción de código desde QuickBasic a FORTRAN y, definitivamente, la ejecución se redujo a unos 20 minutos.
De 2 horas (120 minutos) a 20 minutos!!
con el mismo algoritmo de fuerza bruta, con el mismo computador 386 y con el mismo (cutre) programador.
Bien.
En los tiempos actuales, lenguajes de programación tan ineficientes como el QuickBasic ya no existen.
Nuestros programas están creados en C-Sharp. Es un descendiente del lenguaje C y medio hermano del súper potente C++. Dos de los lenguajes más eficientes que han existido.
Así que, si sumamos esto a los procesadores actuales, realmente tendrías que tener una red muy complicada, con miles de tramos, para estar más de 5 minutos aplicando cualquier método de fuerza bruta.
En nuestro AQUEDUCTOS no tenemos rutina para “optimizar” por pérdidas de carga pues, en mi criterio —y de lo aprendido con este proyecto que te comenté— no es lo más usado.
En AQUEDUCTOS aplicamos el diseño-optimización por velocidad:
- A partir de una velocidad única de diseño para cualquier caudal.
- A partir de una tabla de velocidades de diseño (en muchos libros las llaman velocidades económicas), en las que, dependiendo del rango de caudal, se aplica una velocidad específica para determinar el diámetro del tramo (realmente aquí está una optimización).
Simple ¿a que sí?
Si has utilizado AQUEDUCTOS en tus diseños ya habrás probado estas opciones y, probablemente, tengas ya tu preferida para tus proyectos.
Y si no lo has utilizado, pues empieza a aplicar —sin darte cuenta— métodos de fuerza bruta en tus diseños.
Feliz semana.
Alfredo Simancas
P.D.: Clic en el enlace de arriba.