8. CONCLUSIONES Y FUTURAS INVESTIGACIONES A

Capitulo 8. Conclusiones y Futuras Investigaciones
8.
Optimización Estocástica Multi-Etapa con Manejo de Riesgo
CONCLUSIONES Y FUTURAS INVESTIGACIONES
A continuación se presentan las conclusiones y recomendaciones para futuras investigaciones en el tema
de la optimización estocástica multi-etapa con análisis de riesgo.
8.1.
CONCLUSIONES
La investigación realizada tenía como objetivo estudiar el estado del arte de la optimización estocástica
multi-etapa con la finalidad de desarrollar nuevas metodologías que permitan incluir efectivamente el
análisis de riesgo en problemas de gran dimensionalidad. Para ello se ha:
ƒ Integrado en un solo marco de referencia el uso de la Teoría de Benders y de la Relajación
Lagrangeana aplicadas a la partición y a la descomposición de problemas dinámicos multi-etapa de
optimización estocástica;
ƒ Desarrollado la denominada Programación Dinámica Dual Generalizada (GDDP, Generalized
Dual Dynamic Programming) y su correspondiente extensión estocástica denominada
Programación Lineal Estocástica Multi-Etapa Generalizada (Generalized Multistage Stochastic
Linear Programming) como un medio eficaz para manejar los aspectos dinámicos y funcionales de
los sistemas;
ƒ Desarrollado la denominada Descomposición Generalizada de Escenarios Estocásticos (Stochastic
Scenario Generalized Decomposition) basada en los conceptos de Relajación Lagrangeana, como
una metodología eficaz para integrar los conceptos de la Programación Lineal Estocástica MultiEtapa Generalizada con el manejo controlado de los riesgos derivados de la estocasticidad del
sistema;
ƒ Analizado sistema reales en el sector eléctrico, en los que la estructura de los problemas prácticos que
se deben resolver se adapta a los formatos matemáticos de las metodologías desarrolladas, de manera
tal que dichas metodologías puedan ser utilizadas en la implementación de algoritmos para resolver
problemas de gran tamaño asociados a problemas de la vida real.
8.2.
FUTURAS INVESTIGACIONES
Dado que el objetivo de la presente investigación no era desarrollar códigos computacionales (tecnologías)
para probar la eficiencia computacional de las metodologías desarrolladas, el paso lógico a seguir es la
implementación de dichas metodologías en ambientes de computación modernos basados en
procesamiento paralelo.
Para lo anterior, se debe tener en cuenta que el desarrollo de códigos de gran escala para problemas reales
(antes miles de variables y de restricciones, después centenares de miles, hoy millones) es una labor larga
y de mucho esfuerzo en la programación del software, ambiente que ha cambiado radicalmente con
respecto al desarrollo de soluciones para casos reales. Con base en la experiencia, considero que para
adelantar dichas investigaciones, quien comienza en el tema, debe tener en cuenta varios aspectos
relacionados con los cambios sufridos y la situación actual:
ƒ
En la década de los setenta y comienzos de los ochenta el uso de la Teoría de Benders (TB) para la
solución problemas reales de expansión y/o de operación de sistemas de múltiples embalses con base
en modelos de optimización estocástica (por ejemplo: i. diseño y operación del sistema de riego
Guarico-Orituco en Venezuela con diez embalses potenciales; y ii. Plan Maestro de los Recursos
Hidráulicos de la Zona 1A del Estado Zulia en Venezuela), implicaba el desarrollo en FORTRAN de
todas las componentes del software (algoritmos básicos para programación lineal (PL), algoritmos
8-1
Capitulo 8. Conclusiones y Futuras Investigaciones
Optimización Estocástica Multi-Etapa con Manejo de Riesgo
básicos para programación binaria-entera (PE) y algoritmos de coordinación utilizando TB). El éxito
de dichos proyectos radicaba en el análisis estructural del problema, llegando al nivel del análisis de
las estructuras de las submatrices que integran la gran matriz del problema. Con base en ello se
implementaban códigos especiales de PL que se caracterizaban por tener rutinas especializadas para
manejar matrices con solo unos (que implican procesamiento basado solo en sumas, no en
multiplicaciones), y matrices “completas” para el manejo de los cortes de Benders (que no es eficiente
manejarlos con técnicas para matrices dispersas). En este ambiente, los códigos computacionales, los
problemas matemáticos y la aplicación específica se fundían en un programa computacional con total
interdependencia, cambiar un elemento implicada cambiar el programa de computador final. De otra
forma no se hubiesen podido resolver los problemas reales en los computadores a que se tenía acceso
en dicha época (Velásquez 1981)
ƒ
Al final de la década de los ochenta y comienzo de la de los noventa, se evolucionó de
implementaciones específicas a implementaciones genéricas, independientes de la formulación del
problema de programación matemática. Es el momento en que comienzan a aparecer plataformas
genéricas soportadas en la integración de librerías de algoritmos básicos de optimización (como
CPLEX de Ilog Inc. y OSL de IBM) con generadores de modelos (como GAMS y AMPL) que se
han consolidado y son las vigentes hasta el día de hoy. Simultáneamente comienzan a desaparecer el
desarrollo de programas específicos basados en lenguajes de programación como C y FORTRAN.
Bajo esta concepción, la implementación de tecnologías de gran escala como la Teoría de Benders
Multinivel (Nested Benders) se desarrolla integrando programación en C o FORTRAN con librerías
de alto rendimiento matemático (CPLEX y OSL) para resolver los problemas básicos de
Programación Lineal (PL) y Programación Entera (PE), ya que la situación era bastante diferente a la
vivida diez años atrás. Por ejemplo, es así como se resuelven, en computadores personales 386/486
para la expansión de BAVARIA S.A., la mayor empresa cervecera de Colombia y una de las más
grandes a nivel americano (18 plantas industriales más de 230 productos finales).
ƒ
Desde hace varios años los ‘solvers’ comerciales directos para PE (como CPLEX) son mucho más
eficientes para resolver el problema real asociado a BAVARIA. Lo anterior no implica que las teorías
de gran escala no sean prácticas, y ricas en conceptos para enfrentar los problemas de expansión,
implica que la complejidad del problema real de BAVARIA es, de acuerdo con el estado del arte
actual, muy “pequeña” para requerir de técnicas de gran escala, lo que conlleva que para probar
actualmente la bondad computacional de las teorías de gran escala, se requiere encontrar el problema
de gran tamaño para el que dichas teorías sean eficientes computacionalmente al compararlas con
otras alternativas. Sin embargo todo el enfoque teórico que soportan los algoritmos sigue siendo
válido. Esto implica que encontrar problemas donde las técnicas de gran escala son más eficientes que
las disponibles comercialmente, es parte del problema.
ƒ
En la implementación de software para resolver problemas reales de gran tamaño utilizando técnicas
de gran escala es muy importante el algoritmo que resuelve los sub-problemas. Por ejemplo en el caso
de PE, la selección de una alternativa se complica al considerar que la relación entre los tiempos de
solución de los problemas combinatorios y los algoritmos de solución no es estable. Para visualizar las
implicaciones que esta inestabilidad puede conllevar, a continuación se transcriben resultados
comparativos entre MINTO v2.3 (“solver” experimental especializado, desarrollado por el Georgia
Institute of Technology) y CPLEX v4.0 que fueron presentados en 1997 Barcelona (España) en la
Conferencia Mundial Conjunta de INFORMS y EURO (Johnson et al, 1997). Los experimentos
fueron realizados en un computador IBM RS6000/590 utilizando la asignación de parámetros por
defecto (“default configuration”) para el algoritmo Branch and Bound (B&B) de CPLEX v4.0. Los
problemas se refieren a un subconjunto de la librería de problemas MIPLIB v3.0. En ambos casos se
impuso un tiempo máximo de CPU de 30 minutos.
8-2
Capitulo 8. Conclusiones y Futuras Investigaciones
Grupos
Casos
I
II
III
Optimización Estocástica Multi-Etapa con Manejo de Riesgo
COMPARACION DE RENDIMIENTOS MINTO VERSUS CPLEX
MINTO v2.3
CPLEX v4.0
Caso
#
GAP
CPU
#
GAP
Nodos
%
(Seg)
Nodos
%
P2756
87
0
46
6667
0.512
MODGLOB
831
0
85
158167
0.106
VPM1
3739
0
57
168171
0
FIBER
159
0
18
93506
4.646
MITRE
24
0
61
17400
24.397
BLEND2
2899
0
453
144774
4.295
FIXNET6
649
0
78
167200
30.328
HARP2
1988
0.742
1800
54975
0.752
CAP6000
1512
0.016
1800
2800
PP80A
32416
5.850
1800
172451
5.655
GT2
29000
82.547
1800
308489
0
MISCX07
15010
0
1800
22440
0
NW04
151
0.272
1800
2390
0
QIU
1497
3.331
1800
9883
0
QNET1
14478
8.976
1800
359
0
CPU
(Seg)
1800
1800
1800
1800
1800
1800
1800
1800
1800
1800
520
325
1308
1760
24
En 1997, la principal diferencia entre MINTO v2.3 y CPLEX v 4.0 era el esfuerzo teórico hecho en
MINTO como un optimizador especializado en programación mixta, ya que incorporaba varias
técnicas matemáticas que potencialmente mejoraban el rendimiento. Esta diferencia se nota en el
número de nodos que cada algoritmo evalúa. MINTO realiza un esfuerzo en mejorar la calidad de los
problemas lineales relajados que resuelve en cada nodo, en tanto que CPLEX evalúa muchos más
nodos con base en problemas lineales relajados más elementales. La primera parte de la tabla (I)
muestra claramente el beneficio que se obtiene como consecuencia de las técnicas más elaboradas que
incorpora MINTO (Nemhauser et al., 1994, Linderoth et al. 1997 y Savelsbergh et al. 1998) y
presenta una sustancial mejora en el rendimiento de técnicas basadas en relajación de problemas
lineales. Sin embargo, la segunda parte de la tabla también muestra claramente que estas técnicas (II y
III) pueden degradar significativamente el rendimiento cuando no consiguen ser exitosas. Realmente
cuando las técnicas sofisticadas son exitosas, no se puede atribuir el éxito a una técnica sino al efecto
combinado de muchas de ellas. Nótese que para el caso II, tanto CPLEX como MINTO fracasan. Por
lo tanto el éxito depende del problema, y fracasar en la solución de un problema específico no
descalifica la técnica.
ƒ
De 1997 a la fecha, la situación ha cambiado y cada vez más se incorporan en los “solvers”
comerciales metodologías aceleradoras que antes solo eran contempladas en “solvers” experimentales.
La realidad parece ser que CPLEX es una librería con algoritmos dominantes y por lo tanto ese debe
ser el punto de partida para cualquier comparación. Sin embargo, para afirmarlo de manera sólida se
debe comenzar por un estudio comparativo de CPLEX con otras alternativas.
ƒ
Por lo anterior, el problema de implementar códigos computacionales eficaces para problemas reales
de gran tamaño, depende de muchos factores tecnológicos que implican que, para probar la eficacia de
una implementación computacional (no necesariamente de las metodologías que integran dicha
solución computacional), se requiere de un ambiente tecnológico ideal, costoso, propio de los países
desarrollados que disponga de amplio soporte de tecnologías computacionales, quizás no disponible
fácilmente en países en vías de desarrollo, como Colombia.
ƒ
Para probar la eficacia computacional de una metodología, comparada con otras, se requiere de:
ƒ Un laboratorio computacional apropiado (hardware más software básico)
ƒ Un conjunto de casos de control, no basta con uno
ƒ Implementación eficiente (optimizada) de la metodología en estudio
8-3
Capitulo 8. Conclusiones y Futuras Investigaciones
ƒ
Optimización Estocástica Multi-Etapa con Manejo de Riesgo
Implementación eficiente (optimizada) de las metodologías que se desean comparar;
alternativamente, se requiere un conjunto de “benchmarks” estandarizados, para el que se
disponga de resultados normalizados de todas las tecnologías.
Por lo anterior, se debe ser conciente de la dificultad de desarrollar soluciones computacionalmente
eficaces.
8-4