Optimizaci´
on de Problemas Multiobjetivo de
Ingenier´ıa Civil con jMetal
Antonio J. Nebro
Gustavo R. Zavala
Juan J. Durillo
Francisco Luna
Resumen— Este art´ıculo describe el uso del fra-mework de optimizaci´on multiobjetivo jMetal para afrontar la resoluci´on de problemas de ingenier´ıa ci-vil; en particular, lo que se ha hecho ha sido integrar un software Open Source para el dise˜no de estructu-ras, denominado Ebes, con jMetal. De esta forma los ingenieros civiles tienen a su disposici´on una herra-mienta que les permite dise˜nar estructuras que luego pueden ser optimizadas con metaheur´ısticas multiob-jetivo atendiendo a varios criterios, como minimizar el peso y minimizar la deformaci´on. Por otro lado, este tipo de problemas pueden ser objeto de estudios por parte de investigadores del ´area de las metaheur´ ısti-cas, que pueden usarlos como casos de estudio. Tras presentar tanto jMetal como Ebes, se detalla la in-tegraci´on de ambas herramientas, se presentan tres casos de estudio y se proponen algunas l´ıneas abier-tas de investigaci´on.
Palabras clave— Optimizaci´on Multiobjetivo, Dise˜no de Estructuras, Framework de Optimizaci´on
I. Introducci´on
El framework de optimizaci´on multiobjetivo
jMe-tal [1] es una de las herramientas software m´as
usa-das dentro de la comunidad de investigadores
in-teresados en problemas de optimizaci´on
multiobje-tivo [2]. Estos problemas se caracterizan por estar
compuestos por dos o m´as funciones contrapuestas
a optimizar a la vez, de forma que una mejora en
una funci´on implica un empeoramiento de las otras.
El framework proporciona una cantidad destacable
de algoritmos, operadores y problemas, siendo ´estos
principalmente problemas sint´eticos, por lo que
pre-sentan un inter´es en la pr´actica muy reducido.
Es-tos problemas incluyen la mayor parte los bancos de
prueba m´as usados, como los ZDT [3], DTLZ [4],
WFG [5] y la competici´on del CEC2009 [6].
Un motivo por el que jMetal es ampliamente usado
es su dise˜no, que se basa en una arquitectura
orienta-da a objetos donde caorienta-da entiorienta-dad (algoritmo,
opera-dor, codificaci´on, problema) est´a claramente
defini-da, as´ı como las relaciones entre ellas. Otras razones
son su implementaci´on en Java, el ser c´odigo
abier-to, la atenci´on prestada a la calidad del c´odigo y la
documentaci´on disponible.
En este trabajo presentamos c´omo jMetal se ha
integrado con una herramienta del campo de la
in-Departamento de Lenguajes y Ciencias de la Computaci´on. Universidad de M´alaga. E-mail: [email protected]
Khaos Research Group. Universidad de M´alaga. E-mail: [email protected]
Institute of Computer Science. University of Innsbruck. E-mail: [email protected]
Departamento de Sistemas Inform´aticos y Telem´aticos, Centro Universitario de M´erida. Universidad de Extremadura. E-mail: [email protected]
genier´ıa civil, que tiene la particularidad de no estar hecha en Java, sino en otro lenguaje (Visual Basic .Net). Dicha herramienta, denominada Ebes (de “Es-tructuras de barras espaciales”), es un proyecto de
Gustavo R. Zavala que permite dise˜nar estructuras
2D y 3D compuestas de barras de distinto tipo (cir-culares, en forma de I, etc.) y de distinto material (acero, madera, etc.). Ejemplos de estas estructuras son puentes atirantados, naves industriales, gruas, etc.
Para situar el contexto del art´ıculo vamos a
enu-merar los pasos a seguir para conseguir un dise˜no
optimizado de una estructura de barras: primero se
dise˜na el esquema de la estructura; segundo, se
de-fine el problema de optimizaci´on multiobjetivo
co-rrespondiente (indicando los objetivos a optimizar, t´ıpicamente reducir peso y aumentar la robustez);
tercero, se aplica una t´ecnica de optimizaci´on
(me-taheur´ıstica multiobjetivo en nuestro caso); cuarto,
se visualiza la aproximaci´on al frente de Pareto con
las soluciones obtenidas; por ´ultimo, se analizan
di-chas soluciones y se elige una de ellas.
Por lo que sabemos no existe ninguna herramienta que permita realizar todas estas tareas de forma
in-tegrada, y menos a´un proporcionando
metaheur´ısti-cas multiobjetivo para usarlas en el proceso. Esto nos ha llevado a desarrollar un software, llamado Ebes+jMetal, para cubrir esta carencia [7]. En el presente art´ıculo no nos vamos a centrar en la pers-pectiva desde el punto de vista del ingeniero civil sino en la del investigador en metaheur´ısticas multi-objetivo. En un survey que realizamos sobre la
apli-caci´on de este tipo de t´ecnicas a problemas de dise˜no
estructural [8], tras analizar 51 art´ıculos se lleg´o a
la conclusi´on de que en la mayor parte de los
es-tudios se han usado sobre todo algoritmos evoluti-vos, principalmente NSGA-II [9] y en menor medida
SPEA2 [10], siendo la utilizaci´on de otras t´ecnicas
(PSO, b´usqueda tab´u, etc.) muy marginal. Por
tan-to, se puede afirmar que el desarrollo de algoritmos multiobjetivo para resolver estos problemas es un campo abierto, en el que se podr´ıan realizar muchos estudios si se dispusiese de problemas reales que se
pudiesen usar f´acilmente. Uno de los objetivos de
nuestro trabajo se centra en este punto.
El resto del art´ıculo se estructura de la siguiente
forma. En la secci´on II se presenta el tipo de
pro-blemas de dise˜no estrutural que se abordan en este
trabajo. La secci´on IV se dedica a describir las
he-rramientas software Ebes y jMetal. La siguiente
Fig. 1. Dise˜no de una nave industrial con el software Ebes.
En la secci´on V se analizan tres casos de estudio y
se dan ideas sobre l´ıneas de investigaci´on abiertas.
Por ´ultimo, la secci´on VI presenta las conclusiones
del art´ıculo.
II. Problemas de Dise˜no de Estructuras
Para ilustrar el tipo de problemas que estamos considerando tomemos como ejemplo la Fig. 1.
Me-diante una herramienta de dise˜no (Ebes en nuestro
caso) se puede hacer un dise˜no de una estructura,
como la nave industrial que se muestra. La nave
tie-ne unas dimensiotie-nes prefijadas, y est´a compuesta
por una serie de barras o elementos longitudinales
que est´an unidas entre s´ı a trav´es de unos nudos. El
dise˜no debe cumplir una serie de restricciones para
que, por ejemplo, la nave no se colapse por elegir
elementos con tama˜nos insuficientes.
Fig. 2. Tipos de barras y representaci´on de las variables.
1 2 3 4 5 6 7 8 9 …… N
4 1 4
y
z ty
tz D y
z ty
tz …… N
Shape
Variables
Position
y z ty tz D y z ty tz …… N
Existen varios tipos de barras, como se muestra en la Fig. 2, cado uno de los cuales tiene diferentes
dimensiones. As´ı, una barra circular est´a
caracteriza-da por su di´ametro, mientras que la que tiene forma
de I tiene cuatro medidas. El problema de
optimi-zaci´on se puede formular de forma informal c´omo
determinar cu´ales son las dimensiones adecuadas de
todas las barras que componen la estructura de
for-ma que se satisfagan las restricciones del problefor-ma
y se satisfagan algunos criterios. Entre ´estos vamos
a considerar dos: minimizar el peso de la
estructu-ra (paestructu-ra abaestructu-ratar el coste de construcci´on) y
mini-mizar la deformaci´on de la misma en determinados
puntos (para aumentar su robustez). Estos objetivos son contrapuestos, luego se trata de un problema de
optimizaci´on multiobjetivo (bi-objetivo en
particu-lar).
La Fig. 2 muestra c´omo ser´ıa la representaci´on
de los individuos en vistas a usar una t´ecnica
me-taheur´ıstica. Se trata de un problema de
optimiza-ci´on continua, donde el conjunto de variables estar´a
compuesto por los valores que caracterizan a todas las barras de la estructura. La complejidad del
pro-blema vendr´a dada por el n´umero de barras y por los
tipos de las mismas (por ejemplo, la barras circulares
son m´as simples que el resto).
Hay que rese˜nar que existen otros tipos de
pro-blemas de dise˜no de estructuras. En el survey [8] se
propuso la siguiente clasificaci´on:
1. Dise˜no de barras o elementos
Optimizaci´on de ´area (1.y)
Optimizaci´on de tama˜no (2.y)
Optimizaci´on de forma (3.y)
Optimizaci´on de la topolog´ıa de las secciones
transversales (4.x)
2. Dise˜no de topolog´ıa
Sin optimizaci´on (x.1)
Optimizaci´on discreta (x.2)
Optimizaci´on continua (3)
Dado que ambas clasificaciones no son
excluyen-tes, se usa la notaci´on (x.y) asociada a cada tipo,
donde la x representa el tipo de dise˜no de barras
(por lo que puede tomar, por tanto, valores entre 1
y 4) y la y el tipo de dise˜no topol´ogico (pudiendo
Fig. 3. Variantes de problemas de dise˜no de barras: (1) ´Area sin tama˜no, (2) tama˜no, (3) forma, and (4) topolog´ıa de la secci´on transversal
(1) (2)
(3) (4)
ya que aqu´ı se optimiza toda la estructura.
En la Fig. 3 se ilustran los tipos de poblemas del primer grupo.
Los problemas que aqu´ı se consideran pertenecen a la categor´ıa (2.1), es decir, se busca optimizar el
tama˜no de las barras de la estructura, sin
optimiza-ci´on de la topolog´ıa de la misma, ya que ´esta se ha
definido previamente.
III. Descripci´on de las Herramientas
En esta secci´on se describen las dos herramientas
software, Ebes y jMetal, que se han usado en este trabajo.
A. Ebes
Ebes es una aplicaci´on escrita en Visual Basic .Net
que est´a enfocada al dise˜no, c´alculo y an´alisis de es-tructuras de barras, tanto 2D como 3D. Tiene una
interfaz gr´afica (como se aprecia en la Fig. 1) que
ofrece diferentes formas de visualizaci´on (escalado,
desplazamiento, etc), permite la edici´on de nodos y
barras, y muestra los datos de las estructuras (geo-metr´ıa, carga de nodos, carga de barras,
agrupacio-nes de barras, etc.). Las capacidades de soluci´on
de Ebes tambi´en incluyen la relaci´on el´astica
en-tre tensi´on-deformaci´on para los materiales, el efecto
Fig. 4. Contenido de un fichero “.ebe”. * EBEs
GENERAL DATA
Name: Mobile_Bridge_25N_35B_8G_16OrdZXY Description: units of measure MN, m, MPa, MN/m3 Amount of NODES: 25
Amount of SUPPORTS: 4 Amount of ELEMENTS GROUPS: 8 Amount of ELEMENTS: 35
Groups of element same ELASTICITY: 2 Groups of element same SECTION: 8
Groups of element same INERTIA in Z axis: 8 Total load HYPOTHESIS: 1
Hypothesis COMBINATION of LOADS: 0 WEIGHT OWN OF ELEMENTS: True STATIC OVERLOAD in elements: 28 STATIC LOAD in nodes: 0 LOAD for FREE FALL in node: 0 DISPLACEMENTS amount in nodes: 0 ASSEMBLY ERROR: 0
MAXIMUM DISPLACEMENTS to Nodes: 20 CUTTING Effect: False
SECOND ORDER: False BUCKLING Check: True
Precision for EQUILIBRIUM of FORCES: 0.01 Precision for EQUILIBRIUM of MOMENTUMS: 0.01 NODES
0 0 0 0 111000 0 0 0 0 0 0 1 3 0 0 111000 0 0 0 0 0 0 2 3 3 0 000000 0 0 0 0 0 0 3 4 0.05 0 000000 0 0 0 0 0 0 4 5 0.1 0 000000 0 0 0 0 0 0 5 6 0.125 0 000000 0 0 0 0 0 0 6 7 0.15 0 000000 0 0 0 0 0 0 7 8 0.175 0 000000 0 0 0 0 0 0
de segundo orden no-lineal geom´etrico y la
verifica-ci´on al pandeo en elementos comprimidos o
flexo-comprimidos.
Una vez que una estructura se ha dise˜nado, el
re-sultado se puede almacenar en un fichero de texto
(con extensi´on “.ebe”). La mayor´ıa de los datos se
al-macenan como pares (clave: valor), excepto aqu´ellos
relacionados a los nodos, grupos y barras (elemen-tos), que se incluyen de forma tabular. Un ejemplo se muestra en la Fig. 4.
B. jMetal
jMetal es un framework de optimizaci´on
multi-objetivo con metaheur´ısticas implementado en
Ja-va [1]. El proyecto jMetal comenz´o en 2006, cuando
el an´alisis de los paquetes de optimizaci´on
multiob-jetivo existentes mostr´o que ninguno cumpl´ıa una
seria de requisitos b´asicos, siendo los principales que
ofreciesen una arquitectura orientada a objetos que
fuese extensible y f´acil de usar, y que los programas
tuvienen un m´ınimo de calidad para facilitar su
com-prensi´on. Desde entonces jMetal se ha convertido en
una de las herramientas m´as usadas por la
comuni-dad de optimizaci´on multiobjetivo.
Las principales caracter´ısticas de jMetal se inclu-yen en la siguiente lista:
Algoritmos: 20 multiobjetivo y 4 monoobjetivo. Problemas: 5 benchmarks (ZDT, DTLZ, WFG,
LZ09, CEC2009), problemas cl´asicos (5), con
restric-ciones (6), combinatorios (2).
Fig. 5. Arquitectura de jMetal. Crossover +setParameter(): void +getParameter(): Object +execute(object: Object):Object
# parameters_ : HastTable
Operator Mutation Selection +addOperator(): void +getOperator(): Object
+setInputParameter(name: String, object: Object): void +getInputParameter(): Object
+setOutputParameter(): void
+getOutputParameter(name: String, object: Object): Object +execute(): SolutionSet
# parameters_ : HastTable
Algorithm
*
contains
+evaluate(solution: Solution): void
+evaluateConstraints(solution: Solution): void
Problem
solve
+createVariables(): Variable []
- size: int
SolutionType +add(): void +remove(): void +size(): int +replace(): void SolutionSet -fitness: double[] Solution 1..* manage has +getEvaluations(): int LocalSearch * Variable 1..* consist of defines determines -value: double Real -bits: BitSet Binary -bits: BitSet -value: double BinaryReal Schaffer Kursawe ZDT1 DTLZ2 WFG3 NSGAII SPEA2 PAES AbYSS MOEAD IBEA MOCell SMPSO SinglePointCrossover PolynomialMutation BinaryTournament SBXCrossover
Codificaciones: binaria, real, real codificada en
bi-nario, entera, permutaci´on.
La arquitectura de jMetal se muestra en la Fig. 5, en la que se incluye el diagrama de clases en UML. Es una arquitectura orientada a objetos que es flexible
y extensible, siendo f´acil el a˜nadir nuevos algoritmos,
codificaciones, operadores y problemas.
IV. Integraci´on de Ebes y jMetal
Dado que Ebes y jMetal son dos sistemas indepen-dientes, que pertenecen a disciplinas distintas y que
est´an implementados en lenguajes de programaci´on
diferentes, combinarlos planteaba una serie de retos.
La soluci´on adoptada se bas´o en usar ficheros de
texto para interconectar los dos componentes. En
concreto, dado que los dise˜nos de Ebes se
almace-nan en ficheros “.ebe”, la idea fue hacer que jMetal fuese capaz de leer este tipo de ficheros. Sin embargo, para computar los valores de las funciones objetivos
hac´ıa falta el m´etodo de c´alculo que estaba inclu´ıdo
en Ebes, por lo que se opt´o por traducir ese c´odigo a
Java e incluirlo en jMetal en forma de problema
(lla-madoEbes.java). Como resultado, dicho problema
es con diferencia el m´as complejo que incluye el
fra-mework, conteniendo m´as de 3000 l´ıneas de c´odigo.
Una vez que se dispon´ıa del problema se pod´ıa
usar cualquiera de los algoritmos de optimizaci´on
continua que existen en jMetal. Para facilitar la
elec-ci´on de la metaheur´ıstica, Ebes se extendi´o para
po-der elegir un algoritmo de entre los disponibles y as´ı
poder invocarlo. Este proceso se llev´o a cabo
me-diante la ejecuci´on de un fichero .jar que contiene el
framework jMetal completo. La Fig. 6 muestra una
captura de la ejecuci´on del algoritmo MOCell, que
se ha seleccionado para optimizar el dise˜no de un
puente levadizo.
La ejecuci´on de una metaheur´ıstica multiobjetivo
devuelve una aproximaci´on al frente del Pareto del
problema en forma de dos ficheros de texto: uno que almacena los valores de variables y otro que alma-cena los correspondientes valores de las funciones. Ambos ficheros contienen tantas l´ıneas como
solu-ciones devueltas por el algoritmo. El ´ultimo paso de
la integraci´on consisti´o en hacer que Ebes pudiese
leer esos ficheros y mostrar los frentes para que el ingeniero civil pudiese elegir las soluciones
apropia-das. Este paso requiri´o adem´as que los valores de las
soluciones seleccionadas se incorporasen a la
estruc-tura para as´ı poder disponer del dise˜no optimizado.
En la Fig. 7 se muestra un frente de soluciones obtenido con jMetal importado en Ebes. La
inter-faz gr´afica permite seleccionar cualquier soluci´on del
frente, mostrar los valores de cada variable del pro-blema y pasar esas variables a las barras. Este
proce-so aporta las medidas de la forma geom´etrica de
ca-da secci´on de las barras, definiendo el volumen de las
mismas. Con la selecci´on de los datos se determinan
Fig. 6. Ejecuci´on de una metaheur´ıstica en Ebes+jMetal.
Fig. 7. An´alisis de un frente de soluciones en Ebes.
tipo de secci´on, siendo ´estas ´area, inercia, momento
est´atico, etc. Con las variables junto a otros datos
definidos previamente se obtiene un dise˜no tentativo
completo de la estructura.
El resultado final es una herramienta Open Source denominada Ebes+jMetal, a la que se puede acceder
a traves un sitio Web1, que contiene enlaces al c´odigo
fuente, un ejemplo de utilizaci´on y los frentes
apro-1http://ebesjmetal.sourceforge.net
ximados de Pareto de varios problemas.
Para finalizar esta secci´on, la Fig. 8 muestra un
ejemplo t´ıpico de aproximaci´on al frente de Pareto y
tres instancias concretas. Se observa claramente que
el grosor de las estructuras cambia seg´un las
solu-ciones se obtienen hacia la parte derecha del frente. En este punto ser´ıa el experto en el problema (el
in-geniero civil) el que deber´a tomar la decisi´on acerca
Fig. 8. Ejemplo de aproximaci´on al frente de Pareto.
V. Consideraciones Pr´acticas Sobre el Proceso de Optimizaci´on
El uso de Ebes+jMetal involucra las dos etapas
de un proceso de optimizaci´on completo: la
optimi-zaci´on en s´ı y la toma de decisiones. Mientras que la
segunda fase est´a claramente en manos del experto
del problema, la primera involucra a los investiga-dores en metaheur´ısticas. Desde el punto de vista
de estos ´ultimos hay mucho que aportar dentro del
´
ambito en el que se desarrolla el presente trabajo.
Los problemas considerados est´an lejos de ser
trivia-les y su optimizaci´on no es nada sencilla, y ´este es
un tema que queda lejos de los ingenieros civiles, que
generalmente no ser´an expertos en metaheur´ısticas.
Si prestamos atenci´on a la Fig. 6 podemos
obser-var que existen m´as de 20 t´ecnicas multiobjetivo en
jMetal que se puede seleccionar para ser aplicadas
en Ebes, luego estudiar qu´e algoritmo es el m´as
pro-metedor para resolver un problema dado es tema
abierto, como lo es determinar cu´ales son las
mejo-res configuraciones de los mismos.
Un aspecto pr´actico a considerar es que la
optimi-zaci´on de los problemas se puede hacer sin la
integra-ci´on con Ebes; basta con tener el fichero “.ebe” que
describa la estructura para poder proceder como si
fuera un problema m´as. Como consecuencia, no
ha-ce falta la intervenci´on del experto en el problema
y el fin a perseguir ser´a obtener aproximaciones a
los frentes de Pareto de los problemas de dise˜no que
sean lo m´as precisos posible, atendiendo a los ya
es-tablecidos criterios de convergencia y diversidad. Es
decir, se podr´ıan usar los problemas de dise˜no
estruc-tural a modo debenchmarkreal para aplicar en ellos
nuevos avances en metaheur´ısticas multi-objetivo. Otro tema a tener en cuenta es el coste compu-tacional para evaluar las funciones objetivo. Es
ob-vio que tiempo de c´alculo depender´a del n´umero y
tipo de las barras. Para dar una idea concreta sobre el orden de magnitud de dicho coste vamos a con-siderar tres ejemplos, que se corresponden con tres
dise˜nos de distinto tama˜no de un puente atirantado
(cable-stayed bridge).
A. Puente 25N 35B
El puente que se muestra en la Fig. 9 puede con-siderarse como una estructura relativamente simple.
Est´a compuesto de 25 nodos y 35 barras, por lo que
lo denominamos como puente 25N 35B. Tiene dos
columnas que soportan parte del peso del tablero de
tr´ansito, y el resto del peso es soportado por los
ca-bles anclados detr´as de las columnas. La longitud del
puente es de 9 metros.
Fig. 9. Puente 25N 35B.
Si se configura el algoritmo NSGA-II para hacer
150.000 evaluaciones el tiempo de ejecuci´on est´a en
torno a seis minutos en un MacBook Pro con proce-sador Intel Core i7 a 2.2GHz, 8GB de RAM (DDR3 a 1333MHz), disco SSD de 256GB, sistema
operati-vo MacOS X 10.9.2 y Java JDK versi´on 1.8.0. Este
tiempo no es muy elevado y permitir´ıa hacer un es-tudio que involucrase a varios algoritmos sin la ne-cesidad de muchos recursos computacionales.
La Fig. 10 resume los resultados obtenidos al ha-cer una comparativa que involucra a siete algoritmos representativos; se muestran los boxplots de los va-lores del indicador de calidad Hypervolume [11] so-bre 30 ejecuciones independientes de cada algoritmo.
Adem´as hemos podido hacer un estudio de
parame-tros para ajustar los algoritmos, pero para ello hemos
tenido que usar un cluster de m´as de 400 cores para
terminar todas las pruebas en un par dias, dado el
elevado n´umero de combinaciones de valores de los
par´ametros que se tuvo en cuenta.
B. Puente 133N 221B
El puente de la Fig. 11, denominado puente
133N 221B, se caracteriza por tener 133 nodos y
221 barras y una lontigud total de 44 metros. Dada la simetr´ıa del puente, para simplificar su
optimiza-ci´on se ha considerado la mitad del mismo.
El tiempo requerido para ejecutar NSGA-II en es-te caso asciende a 4,4 horas en el mismo ordenador usado en el puente anterior. Es un tiempo
bastan-te elevado que pr´acticamente obliga a hacer uso de
un sistema paralelo si se quiere hacer un estudio con varios algoritmos.
C. Puente 837N 1584B
El puente de mayor tama˜no que hemos optimizado
ba-Fig. 10. Comparativa sobre el puente 25N 35B.
NSGAII PAES MOCell FastSMSEMOAcMOEAD SMPSO GDE3
0.55
0.60
0.65
0.70
0.75
0.80
0.85
HV:EBEs
Fig. 11. Puente 133N 221B.
rras y una longitud total de 162 metros. Para dar una idea de la complejidad de este problema, en nuestro caso fue necesario usar el cluster anterior para poder
completar una ejecuci´on del algoritmo NSGA-II en
unas 10 horas.
Fig. 12. Puente 837N 1584B.
Longitudinal view
Aereal view
Perspective
Transversal view
Este puente, junto con el anterior, fue sujeto de estudio en el art´ıculo [12].
D. Discusi´on
Los tres puente comentados dan una idea
aproxi-mada de posibles v´ıas de investigaci´on. En el caso de
la instancia m´as peque˜na, en la que hacer una
eje-cuci´on aislada tiene un coste computacional
relativa-mente bajo, hacer un estudio experimental t´ıpico que involucre a varios algoritmos puede requerir usar un
cl´uster de al menos algunas decenas de m´aquinas
pa-ra tener los resultados en un tiempo pa-razonable. En el caso de la instancia mediana ya estar´ıamos hablando
de necesitar algunos cientos de m´aquinas para hacer
un estudio similar, y si se intentan abordar
proble-mas como el puente de mayor tama˜no entonces usar
un elevado n´umero de procesadores es poco menos
que obligatorio para hacer una ´unica ejecuci´on.
Parece claro que, por un lado, estudiar qu´e
algorit-mos son m´as eficaces para problemas de dimemsi´on
reducida o media tendr´ıa mucha utilidad para los ingenieros civiles, que tendr´ıan al menos una
orien-taci´on sobre qu´e t´ecnicas ser´ıan los m´as
promete-doras para resolver un problema concreto. En este
sentido tambi´en ser´ıa de inter´es determinar qu´e
con-figuraci´on de par´ametros proporcionar´ıa los mejores
resultados a un algoritmo determinado.
Por otro lado, dado que el coste de evaluar las funciones objetivo puede ser considerable, reducir el
n´umero de ´estas para proporcionar resultados
acep-tables al ingeniero civil en el menor tiempo posible
tambi´en ser´ıa un avance importante. Aplicar t´
ecni-cas de b´usqueda local podr´ıa ser un estrategia a
con-siderar aqu´ı, as´ı como el uso adaptativo de
diferen-tes operadores de variaci´on durante el proceso de
b´usqueda.
Por ´ultimo, dise˜nar metaheur´ısticas que saquen
partido de conocimiento del problema, probablemen-te definiendo operadores espec´ıficos, ser´ıa un avance
significativo en este ´area.
VI. Conclusiones
En este art´ıculo hemos presentado la integraci´on
del framework de optimizaci´on multiobjetivo
jMe-tal con un software de dise˜no de estructuras civiles
denominado Ebes. El resultado es una herramienta que permite al ingeniero civil utilizar los algoritmos incorporados en jMetal de forma que los frentes re-sultantes se pueden analizar con Ebes y as´ı poder analizar las soluciones de compromiso obtenidas y
poder elegir la que m´as se ajuste a las necesidades o
a los requisitos que se hayan establecido.
Los problemas de ingenier´ıa que se pueden
abor-dar son problemas de dise˜no estructural, en los que
la topolog´ıa ya est´a de definida y se trata de
determi-nar las dimensiones de cada barra para minimizar el
peso y la deformaci´on de la construcci´on resultante.
Mediante Ebes+jMetal se pueden abordar las dis-tintas etapas que hay que llevar a cabo, empezando
por el dise˜no inicial, siguiendo por el proceso de
op-timizaci´on y terminando por la toma de decisiones
por parte del experto en el dominio.
Dado que el proceso de optimizaci´on no requiere
necesariamente el uso de Ebes se pueden realizar
es-tudios de optimizaci´on usando ´unicamente jMetal, lo
que abre muchas posibilidades a investigadores que
multiobjeti-vo con metaheur´ısticas. Para ilustrar las dificultades computacionales que se pueden presentar a la hora de resolver estos problemas se han tomado tres ins-tancias de distinta complejidad y se han ofrecido los tiempos obtenidos al resolverlos con un ordenador concreto.
En base a estos ejemplos se han presentado algu-nas ideas sobre temas abiertos que se pueden aplicar
a los problemas de dise˜no estructural, lo que dar´ıa
lugar a resultados de gran inter´es en ese dominio.
En el estado del arte actual la presentaci´on de
nue-vas propuestas algor´ımicas enfocadas a resolver estos problemas de forma eficiente es un campo por explo-rar.
Agradecimientos
Este trabajo ha sido financiado por los proyectos
TIN2011-25840 (Ministerio de Ciencia e Innovaci´on)
y P11- TIC-7529 and P12-TIC-1519 (Plan Andaluz
de Investigaci´on, Desarrollo e Innovaci´on).
Referencias
[1] Juan J. Durillo and Antonio J. Nebro, “jmetal: A java framework for multi-objective optimization,” Advances in Engineering Software, vol. 42, pp. 760–771, 2011. [2] I. Giagkiozis, R.J. Lygoe, and P.J. Fleming, “Liger:
an open source integrated optimization environment,” inGenetic and Evolutionary Computation Conference, GECCO ’13, Amsterdam, The Netherlands, July 6-10, 2013, Companion Material Proceedings, 2013, pp. 1089– 1096.
[3] E. Zitzler, K. Deb, and L. Thiele, “Comparison of mul-tiobjective evolutionary algorithms: Empirical results,”
Evolutionary Computation, vol. 8, no. 2, pp. 173–195, Summer 2000.
[4] K. Deb, L. Thiele, M. Laumanns, and E. Zitzler, “Sca-lable test problems for evolutionary multiobjective opti-mization,” inEvolutionary Multiobjective Optimization. Theoretical Advances and Applications, Ajith Abraham, Lakhmi Jain, and Robert Goldberg, Eds., pp. 105–145. Springer, USA, 2005.
[5] S. Huband, L. Barone, R.L. While, and P. Hings-ton, “A scalable multi-objective test problem tool-kit,” inThird International Conference on Evolutionary MultiCriterion Optimization, EMO 2005, C.A. Coello, A. Hern´andez, and E. Zitler, Eds. 2005, vol. 3410 of Lec-ture Notes in Computer Science, pp. 280–295, Springer. [6] Q. Zhang and P. N. Suganthan, “Special session on per-formance assessment of multiobjective optimization al-gorithms/cec 09 moea competition,” May 2009. [7] Gustavo R. Zavala, Antonio J. Nebro, Juan J. Durillo,
and Francisco Luna, “Integrating a multi-objective op-timization framework into a structural design software,”
Advances in Engineering Software, vol. 76, no. 0, pp. 161 – 170, 2014.
[8] G.R. Zavala, A.J. Nebro, F. Luna, and C.A. Coello Coello, “A survey of multi-objective metaheuristics ap-plied to structural optimization,” Structural and Multi-disciplinary Optimization, vol. 49, no. 4, pp. 1–22, 2013. [9] K. Deb, A. Pratap, S. Agarwal, and T. Meyarivan, “A fast and elitist multiobjective genetic algorithm: NSGA-II,” IEEE Transactions on Evolutionary Computation, vol. 6, no. 2, pp. 182–197, 2002.
[10] E. Zitzler, M. Laumanns, and L. Thiele, “SPEA2: Impro-ving the strength pareto evolutionary algorithm,” in EU-ROGEN 2001. Evolutionary Methods for Design, Op-timization and Control with Applications to Industrial Problems, K. Giannakoglou, D. Tsahalis, J. Periaux, P. Papailou, and T. Fogarty, Eds., Athens, Greece, 2002, pp. 95–100.
[11] E. Zitzler and L. Thiele, “Multiobjective evolutionary algorithms: a comparative case study and the strength
pareto approach,” IEEE Transactions on Evolutionary Computation, vol. 3, no. 4, pp. 257–271, 1999.
