Equation Chapter 1 Section 1
Proyecto Fin de Carrera
Ingeniería en Organización Industrial
Determinación de Frecuencias y Capacidades
Óptimas en Redes Densas de Ferrocarril de
Tránsito Rápido
Autor: José Antonio Quirós Alés
Tutor: José David Canca Ortiz
Dep. Organización Industrial y Gestión de Empresas I
Escuela Técnica Superior de Ingeniería
1
Proyecto Fin de Carrera
Ingeniería en Organización Industrial
Determinación de Frecuencias y Capacidades
Óptimas en Redes Densas de Ferrocarril de
Tránsito Rápido
Autor: José Antonio Quirós Alés
Tutor: José David Canca Ortiz
Dep. Organización Industrial y Gestión de Empresas I
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2015
Ingeniería en Organización Industrial
Determinación de Frecuencias y Capacidades
Óptimas en Redes Densas de Ferrocarril de
Dep. Organización Industrial y Gestión de Empresas I
Escuela Técnica Superior de Ingeniería
2
3
Proyecto Fin de Carrera
Ingeniería en Organización Industrial
Determinación de Frecuencias y Capacidades
Óptimas en Redes Densas de Ferrocarril de
Tránsito Rápido
Autor:
José Antonio Quirós Alés
Tutor:
José David Canca Ortiz
Profesor titular
Dep. Organización Industrial y Gestión de Empresas I
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2015
4
5
Proyecto Fin de Carrera: Determinación de Frecuencias y Capacidades Óptimas en Redes Densas de Ferrocarril de Tránsito Rápido
Autor: José Antonio Quirós Alés
Tutor: José David Canca Ortiz
El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2015
El Secretario del Tribunal
6
ÍNDICE
Objetivos ....................................................................................................................................... 8
Introducción a la planificación ferroviaria ................................................................................... 9
1.Planificación estratégica ....................................................................................................... 10
2.Planificación táctica .............................................................................................................. 11
3.Planificación operativa ......................................................................................................... 13
El problema de la determinación de frecuencias ...................................................................... 16
1.Programación cíclica............................................................................................................. 18
2.Programación no cíclica ....................................................................................................... 19
Redes de tránsito rápido por ferrocarril. Segmentos compartidos .......................................... 21
El modelo propuesto .................................................................................................................. 27
1.Exposición de los elementos del modelo ............................................................................. 27
1.1 Sets ................................................................................................................................ 27
1.2 Notación de índices ....................................................................................................... 28
1.3 Parámetros .................................................................................................................... 28
1.4 Variables ........................................................................................................................ 29
1.5 Función objetivo ............................................................................................................ 30
1.6 Restricciones ................................................................................................................. 31
1.6.1 Restricciones de flujo y transbordos ..................................................................... 31
1.6.2 Restricciones de tiempo de viaje ........................................................................... 33
1.6.3 Restricciones de frecuencias y headways ............................................................. 34
1.6.4 Restricciones de tramos de vías compartidos por varias líneas ............................ 34
1.6.5 Restricciones de capacidad ................................................................................... 36
Resolución por medio de GAMS ................................................................................................ 37
1.Introducción al software “GAMS” ....................................................................................... 37
2. Solvers ................................................................................................................................. 42
2.1 CoinBonMin ................................................................................................................... 43
2.2 SBB ................................................................................................................................ 43
2.3 Alpha ECP ...................................................................................................................... 44
3. Implantación del modelo en GAMS. Códigos de programación y estructura de archivos .. 45
3.1 Arquitectura de los códigos de programación empleados, relación entre los distintos
ficheros ................................................................................................................................ 46
Índice
7
3.1.1 Archivo principal o lanzador .................................................................................. 47
3.1.2 Archivo de datos del caso computacional ............................................................. 50
3.1.3 Archivo de definición de variables ........................................................................ 58
3.1.4 Archivo de restricciones del modelo ..................................................................... 59
Pruebas computacionales. Descripción de escenarios y resolución ......................................... 70
1.Descripción de escenarios ................................................................................................... 70
1.1 Prueba computacional A: red de tránsito rápido por ferrocarril de 8 nodos y 10 pares
Origen-Destino .................................................................................................................... 70
1.2 Prueba computacional B: red de tránsito rápido por ferrocarril de 12 nodos y 56 pares
Origen-Destino ................................................................................................................... 73
1.3 Prueba computacional C: red de tránsito rápido por ferrocarril de 36 nodos y 800
pares Origen-Destino ......................................................................................................... 77
1.4 Características comunes de los diferentes casos computacionales ............................. 83
2. Resolución de los escenarios computacionales .................................................................. 86
2.1 Exposición del algoritmo de Yen. Modo de aplicación para el cálculo de k-caminos más
cortos .................................................................................................................................. 88
2.2 Decripción de resultados de los casos computacionales. Análisis de sensibilidad ....... 90
2.2.1 Exposición de resultados de los casos computacionales ...................................... 90
2.2.1.1 Descripción de los resultados obtenidos mediante la aplicación del solver
Alpha ECP. Caso computacional A (8 nodos y 10 pares O-D) ..................................... 93
2.2.1.2 Descripción de los resultados obtenidos mediante la aplicación del solver
Alpha ECP. Caso computacional B (12 nodos y 56 pares O-D) ................................... 98
2.2.1.3 Descripción de los resultados obtenidos mediante la aplicación del solver
Alpha ECP. Caso computacional C (36 nodos y 800 pares O-D) ............................... 103
2.2.2 Descripción de los análisis de sensibilidad realizados ......................................... 113
2.2.2.1 Análisis de sensibilidad: capacidad de absorción de demanda de la red para el
caso computacional C ............................................................................................... 113
2.2.2.2 Análisis de sensibilidad: efecto de la disminución y aumento del peso
monetario del tiempo de viaje de los pasajeros para la red del caso computacional C
................................................................................................................................... 118
Conclusiones ............................................................................................................................. 122
Bibliografía ................................................................................................................................ 124
Anexo: Códigos de programación en GAMS ............................................................................ 127
8
Objetivos
El presente proyecto tiene como principal objetivo definir y desarrollar un
modelo matemático para la gestión de redes de tránsito rápido por ferrocarril (como
es el caso de redes de cercanías y metro). Concretamente, se pretende obtener los
valores óptimos de frecuencias y capacidades de los ferrocarriles que componen cada
una de las líneas de la red considerada teniendo en cuenta la demanda existente, todo
ello de modo que se minimicen los costes asociados al funcionamiento de una red de
las características comentadas.
Es objeto no sólo la minimización de los costes tangibles de la red (compra de
material rodante, gastos de operación de los ferrocarriles y personal de tripulación),
sino que también se persigue maximizar la eficiencia en lo referido a la atención de la
demanda existente, de modo que el modelo asume como costes aspectos como el
tiempo que los pasajeros emplean en desplazarse por la red, el número de transbordos
que se realizan y la cantidad de demanda que no es atendida, todo ello para favorecer
un movimiento rápido y directo de los pasajeros en su desplazamiento a la par que se
maximiza tanto como sea posible el número de viajeros atendidos.
Se busca pues construir un modelo que además de resultar de utilidad en la
planificación de líneas (en lo referente al cálculo de frecuencias) y en la determinación
de capacidades, tenga la facultad (teniendo en cuenta dichos valores de frecuencia y
capacidad) de realizar asignaciones de rutas para la demanda existente de acuerdo con
los criterios anteriormente señalados de optimización tanto para los costes del
operador de la red como para la eficiencia en los desplazamientos de los pasajeros.
Con el propósito de evaluar el desempeño del modelo en múltiples escenarios,
se han desarrollado tres experimentos computacionales de distinta complejidad, todos
ellos emplazados en la gestión operativa de una red de tránsito rápido durante un
intervalo de tiempo de una hora. Para la realización de los referidos experimentos se
implementaron mediante programación todos los elementos necesarios (datos de los
casos computacionales y modelo de optimización) en el software GAMS (versiones
22.9.2 y 23.0.2).
Asimismo, para obtener un mejor conocimiento del rendimiento del modelo,
cada uno de los tres experimentos computacionales se ha ejecutado con tres solvers
distintos disponibles en GAMS: Alpha ECP, CoinBonMin y SBB. Posteriormente a esas
ejecuciones se realizó un análisis de sensibilidad encaminado a comprobar la reacción
del modelo frente a condiciones poco ortodoxas a fin de extraer conclusiones que
permitan introducir mejoras en el mismo.
9
Introducción a la planificación ferroviaria
Tal y como se argumenta en (Orro, 2006) la planificación en los servicios y
sistemas de transporte es una actividad que, debido a su influencia e importancia en la
vida cotidiana del conjunto de la sociedad, debe estar en constante desarrollo y
evolucionar a medida que lo hace ésta.
Las medidas de planificación pueden clasificarse de muchas formas distintas
atendiendo a diversos factores; en el presente texto se hablará principalmente por un
lado de medidas orientadas a la planificación de la frecuencia de los trenes
(dependiendo del tipo de servicio) y por otro lado de la planificación del material
rodante (denominado Rolling Stock) y personal necesario.
Publicaciones ampliamente conocidas como (Porter, 1980) permiten establecer
unas pautas de planteamiento de modo que una organización o proyecto sea
competitivo con independencia de su naturaleza, lo que trasladado al ámbito
ferroviario implica constituir una planificación desde diferentes horizontes temporales,
asegurando un correcto funcionamiento de todo el sistema tanto en el día a día como
también a medio y largo plazo. Según este enfoque, se distinguen tres bloques
principales de planificación para los sistemas ferroviarios:
- Planificación Estratégica
- Planificación Táctica
- Planificación Operativa
Más adelante se entrará a valorar en qué consisten cada uno de estos bloques
de planificación, atendiendo además dentro de cada uno a las medidas de diseño de
frecuencias y medios a las que anteriormente se hacía referencia.
Se podría decir que la planificación ferroviaria no posee un único objetivo, sino
que atiende a un conjunto de propósitos que son fundamentales para calificar como
correcto el funcionamiento de un sistema de este tipo. Estos objetivos son prestar un
servicio de transporte eficaz, seguro y de calidad, que sea económicamente viable,
respetuoso con el medio ambiente y de acceso universal.
Por un servicio de transporte ferroviario eficaz, seguro y de calidad se entiende
que los trenes y todo el sistema inherente a ellos funcionen correctamente. Esto es,
que los transportes se realicen en el tiempo y forma adecuados, con los dispositivos y
medidas que garanticen el mayor grado de seguridad y comodidad posible para los
usuarios del sistema, todo ello contando con un plan de actuación en caso de
imprevistos (averías, accidentes, etc).
Introducción a la planificación operativa
10
El objetivo de que sea económicamente viable hace hincapié en la necesidad de
desarrollar una planificación de modo que el sistema preste unos servicios adecuados,
pero siempre teniendo en cuenta los gastos asociados a este funcionamiento o dicho
de otro modo, que exista un equilibrio entre los gastos asociados al sistema ferroviario
(operacionales, de mantenimiento, adquisición de Rolling Stock, etc) y la calidad del
servicio ofertado de tal manera que se genere un beneficio razonable o se incurra en
mínimas pérdidas.
La importancia de la preservación del medio ambiente hace ineludible abordar
la planificación ferroviaria de modo que la explotación de los elementos del sistema se
realice del modo menos agresivo ecológicamente hablando, ya sea empleando un
combustible menos contaminante y/o bien gestionando las redes ferroviarias
(incluyendo la construcción de las nuevas líneas) de la manera menos invasiva posible
con el medio ambiente.
Evidentemente una planificación ferroviaria adecuada debe siempre incorporar
elementos en los que tenga cabida el conjunto de todas las personas sea cual sea su
condición, desarrollando aquellos aspectos necesarios (sistemas de soporte para
personas con movilidad reducida, por ejemplo) para que toda la sociedad tenga la
misma posibilidad de acceso al sistema ferroviario.
1. Planificación estratégica
La planificación estratégica se realiza con una visión del sistema ferroviario a
largo plazo, manejando usualmente horizontes temporales de varios años. La finalidad
de este tipo de planificación es anticiparse a los futuros escenarios en los que se
desarrollará la actividad ferroviaria. Este tipo de planificación ha sido objeto de
trabajos muy notables como es el caso de (Mintzberg, Quinn, & Voyer, 1997)
Lo que se desea es responder con solvencia a situaciones futuras de demanda,
la cual se estima con la ayuda de técnicas tanto cualitativas como cuantitativas. Para
garantizar una respuesta adecuada a esas exigencias de mercado previstas se deberán
acometer actuaciones encaminadas a disponer de los medios necesarios para en el
futuro poder afrontar la situación pronosticada.
Los modelos de previsión de demanda permiten construir pares Origen-Destino
con el número aproximado de personas que tiene la intención de viajar entre dos
estaciones cualquiera, lo que a su vez hace posible establecer una frecuencia (y por
tanto un horario) conveniente en el servicio de trenes en función del número de
pasajeros previsto para un tramo horario determinado.
Introducción a la planificación operativa
11
Dicho horario está condicionado además al tipo de servicio en cuestión, de
modo que los trenes de cercanías funcionan con frecuencias relativamente elevadas,
mientras que por el contrario los trenes de larga distancia operan a frecuencias mucho
menores (pocos trenes al día).
En lo referido al personal y material rodante, la planificación estratégica se
centra en determinar el tipo y cantidad necesario de elementos para cubrir con
garantías los servicios previstos. Esto es, comprar trenes o aumentar la capacidad de
éstos con nuevos vagones si es necesario, establecer un mantenimiento adecuado a
los medios actuales para prolongar su vida útil en el tiempo y contratar o despedir
personal (técnicos, conductores, personal de servicio, revisores, etc) en función de la
demanda.
Como se puede deducir, las decisiones tomadas en el ámbito de la planificación
estratégica son de vital importancia ya que en muchos casos comprometen una gran
cantidad de dinero y/o activos durante varios años. Una inversión desacertada (por
ejemplo el sobredimensionamiento de una línea) podría tener muy graves
consecuencias mientras que por el contrario una programación adecuada permitiría
minimizar los costes operacionales a la par que se da un servicio de transporte
adecuado a los usuarios, por lo que es vital disponer de toda la información posible.
(Sánchez Borrás, 2012) constituye un ejemplo en el que se detalla ampliamente un
proceso de planificación estratégica.
2. Planificación táctica
La planificación táctica está orientada a un futuro más cercano, tratando en
general con un horizonte temporal de varios meses (aunque se dan casos en los que
este tipo de planteamiento tiene un plazo temporal considerablemente más pequeño,
por ejemplo de varias semanas). El enfoque se sitúa en este caso en un lugar
intermedio entre el corto y el largo plazo. La clave de la planificación táctica radica en
disponer la organización de modo que se tenga más adelante una operación efectiva
en el día a día sin perder de vista los objetivos marcados a largo plazo. Una idea de la
gran importancia que este tipo de planteamiento tiene sobre muchos aspectos de un
sistema de transporte ferroviario puede obtenerse con (Budai-Balke, 2009), donde se
aborda el problema de la planificación táctica desde un punto de vista centrado en las
operaciones de mantenimiento del material rodante.
En España (y el resto de Europa) es usual que los servicios dispongan de un
horario o frecuencia establecidos en función de su naturaleza (larga distancia, media
distancia, cercanías…). Evidentemente se trata de compatibilizar la capacidad que se
tiene gracias a los medios disponibles en cada momento con las necesidades de los
viajeros.
Introducción a la planificación operativa
12
Tal y como se expone en (Maróti, 2006), para cada servicio suele configurarse
un horario fijo que se repite de forma cíclica en función de los días de la semana
durante un período de tiempo que abarca varios meses. Por ejemplo, hay trenes de
larga distancia que tienen el mismo horario todos los días durante un año, del mismo
modo que hay trenes de media distancia que cubren un servicio con un horario
distinto de lunes a viernes del que tienen los fines de semana(o bien no circulan algún
día), como también hay trenes que sólo operan ciertos días.
El objetivo pues, de esta planificación es configurar un sistema de frecuencias y
horarios que, con unas infraestructuras ferroviarias dadas, permita simultanear todos
los servicios necesarios en cualquier fecha y además posibilite en su caso a los viajeros
varias opciones de transbordo o enlace con otros trenes o transportes.
En lo referido a la planificación táctica de personal y material, resulta clave la
correcta distribución de todos los elementos del sistema (de los que se debe disponer
en calidad y número suficiente si la planificación estratégica ha sido la correcta) de
modo que los servicios de transporte se efectúen adecuadamente.
Para ello, en primer lugar se sigue un principio básico de la planificación táctica
que consiste en dividir el problema en cuestiones más pequeñas para satisfacer los
objetivos principales. Eso se traduce en que se debe considerar la red ferroviaria como
un conjunto subdividido en diferentes grupos de líneas dentro de cada uno de los
cuales existen líneas que están conectadas entre sí.
Una vez realizada la división se asigna y distribuye el material rodante entre los
diferentes grupos de líneas de modo que se atienda de forma efectiva a la demanda
existente intentando también que en cada grupo siempre operen (dentro de lo
posible) los mismos trenes con lo que se ahorran sucesivas asignaciones. De este modo
se consigue disminuir la confluencia con trenes procedentes de otros grupos en ciertos
tramos de vías y estaciones de uso compartido, con lo que un problema en un grupo
de vías o un tren determinado tiene menos posibilidades de perturbar el
funcionamiento de otros trenes ajenos al grupo de líneas afectado.
En cualquier caso, una correcta planificación debe tener en cuenta el uso
simultáneo de tramos compartidos por varios trenes, ya sean estos pertenecientes a al
mismo grupo de líneas o no. Esto implica una necesaria compatibilidad entre los
horarios o frecuencias de los trenes implicados, de modo que exista un cierto margen
de tiempo entre el paso de un tren y el siguiente. No obstante, hay ciertos casos en los
que, por retrasos, averías o incompatibilidad horaria, alguno de los trenes debe
disminuir su velocidad o incluso detenerse en un cruce de vías para dejar paso al otro.
Es objeto de la planificación táctica y operativa intentar evitar estos sucesos en la
medida que sea posible.
Introducción a la planificación operativa
13
Este mismo problema se da con más frecuencia en las estaciones que son
destino u origen de un gran número de servicios. Además, se tiene la necesidad
adicional de gestionar el material rodante en las estaciones una vez éste ha terminado
con todos sus trayectos para ese día. Debe, para tal efecto, existir un grupo de
planificadores que se encargue de gestionar los movimientos de los trenes a su paso
por las estaciones, los cuales podrán solicitar cambios en el recorrido u horario de los
mismos en caso de que se presente una incompatibilidad grave que no sean capaces
de gestionar con los medios disponibles a su alcance.
La planificación táctica se encarga asimismo de definir la carga de trabajo
necesaria para el funcionamiento de los distintos sistemas, definiendo los turnos de
trabajo que se ejecutarán en base a una serie de factores que deben tenerse en cuenta
como los requerimientos de personal por parte de un determinado servicio, (por
ejemplo, un tren larga distancia necesitará disponer de uno o varios maquinista
además de revisores, numeroso personal de servicio, etcétera), respetando también
determinados aspectos como son un límite de horas al día de trabajo y un descanso
para la comida.
Al igual que ocurre en otros sectores, existen varios de tipos de turnos de
trabajo, de modo que dependiendo de la plantilla de personal de la cual se dispone
con respecto a los servicios que se deben cubrir, se asignan grupos de trabajo en los
cuales más adelante (planificación operativa) se proporcionará un horario a cada
empleado con una determinada carga de trabajo que es compatible con la de sus
compañeros.
Esto quiere decir que un trabajador que hace un determinado turno tiene
establecido un tiempo de descanso en función de su actividad (por ejemplo, un caso
clásico de una persona con una carga de trabajo de 8 horas al día trabaja 5 días a la
semana y descansa otros 2). Durante dicho período de tiempo libre otro compañero
tiene su turno configurado de modo que cubre ese trabajo mientras el primero
descansa, y así sucesivamente con todo el personal creándose una cadena cíclica en la
que unos se cubren a otros permitiendo que todos los servicios funcionen con
normalidad y a la vez el personal disfrute de los períodos de descanso
correspondientes.
3. Planificación operativa
Esta modalidad de planificación maneja un horizonte temporal mucho más
reducido que las dos anteriores, siendo en este caso de varios días como mucho. A
modo resumen, la planificación operativa se encarga de establecer los medios
necesarios para garantizar el funcionamiento del sistema ferroviario a corto plazo.
Introducción a la planificación operativa
14
Para ello se apoya en elementos que permiten realizar una gestión dinámica de
la demanda, con lo que se consigue un seguimiento en tiempo real del
comportamiento de los viajeros, posibilitando así una optimización de la oferta de
transporte y la anticipación a posibles situaciones extraordinarias.
De acuerdo con lo descrito en (Maróti, 2006), en este nivel de planificación no
se producen grandes flujos de trabajo con respecto a las frecuencias y horarios de los
trenes, ya que vienen prácticamente fijados por los bloques de planificación
estratégica y táctica. Lo que se hace en este caso es reajustar los horarios y frecuencias
en el caso de que se produzca alguna situación no esperada como puede ser la
disposición de servicios de última hora (por eventos especiales como encuentros
deportivos, congresos, etcétera), averías o retrasos, de modo que el sistema pueda
adaptarse a estos cambios sin alteraciones graves en su funcionamiento.
En cuanto a la planificación de material rodante, normalmente las unidades de
transporte ya están dispuestas según la organización planteada en las planificaciones
estratégica y táctica, de modo que en este caso lo que se hace es gestionar el
movimiento de los trenes en las vías, cuidando especialmente los segmentos que
comparten varios trenes de líneas o servicios distintos en un mismo tramo horario así
como el paso por la estaciones de modo que la circulación sea lo más fluida posible.
Otro aspecto a gestionar en la planificación operativa son las actividades destinadas a
reajustar la composición de los trenes, como son ensamblajes con otros trenes o
vagones para dar servicio a una mayor o menor demanda.
Cabe decir que, pese a los esfuerzos de planificación previos realizados,
siempre aparecen situaciones que obligan a tomar medidas extraordinarias, como por
ejemplo en escenarios de climatología adversa debido a temporales de nieve.
Este tipo de ocasiones, que originan una notable cantidad de retrasos y averías,
afectando al tráfico de una buena parte de la red ferroviaria, obligan a los centros de
control a tomar decisiones en un plazo de tiempo muy reducido, priorizándose unos
servicios sobre otros, decidiendo que trenes tienen preferencia en el paso por
estaciones y vías, recolocando viajeros mediante transbordos, apartando las unidades
averiadas para su mantenimiento, etc. En estos casos, la escasez de tiempo y medios
hacen imposible prestar un servicio optimizado, así que la reorganización que se lleva a
cabo está orientada resolver la situación de modo que se evite un colapso de la red
ferroviaria.
Introducción a la planificación operativa
15
En lo referente a la planificación de personal, ocurre algo similar a lo
anteriormente expuesto con el material rodante. Ya existen bloques de planificación
anteriores con directrices acerca del número de empleados necesarios y los turnos de
trabajo ideales correspondientes para cada servicio, por lo que en la planificación a
corto plazo lo que se hace es asignar a cada trabajador un puesto concreto en un
servicio durante el tiempo que corresponde a su turno y revisar que todas las tareas
están cubiertas con el personal necesario.
Si un tren no cuenta con los empleados necesarios especificados (maquinista,
revisores, personal de servicio…) es retrasado hasta conseguirlos o, en caso de
imposibilidad de esto último, normalmente el servicio es cancelado reubicando a los
viajeros en otros trenes.
De lo anterior se deduce que planificación operacional tiene que enfrentarse
comúnmente a alteraciones en el funcionamiento del sistema que exigirán un gran
número de recolocaciones de personal por múltiples causas: enfermedades, retrasos,
necesidades de refuerzo de personal debido a circunstancias excepcionales,
cancelación de servicios, etc. Resolver con éxito todos aquellos escenarios que se
presenten en el día a día y facilitar un buen servicio de transporte ferroviario para los
viajeros es la razón de ser de la planificación operativa y el hecho de contar con los
medios adecuados para ello siempre vendrá condicionado por la planificación
estratégica y la planificación táctica.
16
El problema de determinación de frecuencias
Existen una serie de elementos de capital importancia a la hora de realizar la
programación de los trenes que operarán en los distintos servicios de transporte de
pasajeros de un sistema ferroviario dado, como son: el número de vagones de los que
se compone cada tren, la frecuencia de los servicios, planificación de paradas, el tipo
de tren, etc.
La programación de los trenes, tal y como se indica en (Deng, Zeng, Zhou, &
Shi, 2014); es un problema que aparece principalmente en el bloque de planificación
táctica. De los elementos anteriormente enunciados hay dos que se consideran claves
y que determinan la calidad del servicio de transporte prestado y la capacidad de
transporte de pasajeros; estos elementos son la frecuencia con la que operan los
ferrocarriles pertenecientes a las diferentes líneas y la cantidad de vagones de los que
se componen los trenes (factor también llamado composición de un tren). El presente
apartado se centra en el análisis de la importancia que conlleva una planificación de
frecuencias adecuada y la dificultad asociada a la realización de esta tarea de
organización.
Dentro del ámbito de la programación de los servicios de ferrocarril un término
muy empleado es el de “línea de tren” o “línea de ferrocarril”, elemento que
básicamente hace referencia a un grupo de trenes que conforma un subconjunto
dentro del conjunto global de los ferrocarriles operativos de una red que se caracteriza
por realizar siempre el mismo recorrido realizando sus paradas siempre (o casi
siempre) en las mismas estaciones, de modo que la única diferencia entre en el modus
operandi de dos trenes de una misma línea es la hora de entrada y salida de cada
estación. La frecuencia de una línea indica la cantidad de trenes que pasan por cada
nodo de la red en un intervalo de tiempo dado (usualmente la frecuencia viene dada
para intervalos de una hora).
Así pues, debe destacarse que el concepto “línea de tren” resulta básico sobre
todo en redes de tránsito rápido por ferrocarril (en adelante RTR), en las cuáles se
centra el contexto de análisis del presente proyecto. En ellas, los trenes de pasajeros
normalmente operan en base a intervalos regulares de tiempo que en definitiva son
programaciones periódicas o cíclicas de circulación. Teniendo en cuenta que la
demanda de pasajeros fluctúa en función del tramo horario, normalmente se establece
un horizonte de planificación que se divide en períodos concretos de operación, cada
uno con sus frecuencias de servicio específicas de acuerdo con la demanda existente
(Chang, Yeh, & Shen, 2000).
El problema de la determinación de frecuencias
17
Establecer una frecuencia para los distintos servicios en función del tramo de
horario es una tarea realmente difícil en redes ferroviarias complejas ya que dicha
frecuencia debe cumplir siempre con un conjunto de condiciones que depende de la
red.
Fijar la frecuencia de una línea implica marcar un determinado horario que
debe cumplirse para la salida y la llegada de los trenes de esa línea a cada parada o
estación estipulada en su recurrido y esta planificación horaria tiene que satisfacer
necesariamente regulaciones tales como un margen de tiempo con los trenes que
circulan justo por delante y por detrás de cada ferrocarril (en otras palabras, cumplir
con una distancia de seguridad). En tramos compartidos por trenes de líneas distintas,
la frecuencia de todas las líneas que circulan por un mismo trayecto debe ser
compatible, de modo que no se solapen unos a otros en ningún tramo horario, lo que
imposibilita operar con frecuencias muy altas en tramos con un número elevado de
trenes en circulación.
Uno de los objetivos que se busca conseguir al planificar las frecuencias de las
distintas líneas de servicio es minimizar el tiempo que los viajeros emplean en su
transporte a través de la red ferroviaria, lo cual implica disminuir en la medida de lo
posible tanto el tiempo que los pasajeros permanecen esperando en las paradas para
tomar el correspondiente tren, como el tiempo empleado en el trayecto desde la
parada origen hasta la parada destino (evidentemente la velocidad media de los trenes
es otro factor a tener muy cuenta a estos efectos).
Es también trascendente el hecho de que cuando se planifica la frecuencia de
los trenes de cada línea siempre se intenta encontrar un equilibrio de modo que el
paso de éstos por las estaciones sea lo suficientemente fluido como para atender a
toda la demanda de pasajeros con garantías de calidad y sin superar la capacidad de
los trenes, pero también sin alcanzar una frecuencia excesiva que implique un uso
desproporcionado de los recursos del sistema, lo que supondría incurrir en gastos
inasumibles. Asimismo debe tenerse un cuenta que un servicio que satisfaga a los
pasajeros con solvencia evidentemente puede catalogarse como un transporte de
calidad y en consecuencia es previsible una atracción hacia dicho sistema de usuarios
que solían desplazarse con otros medios, aumentando la demanda del sistema.
De todo lo comentado anteriormente se deduce la enorme importancia de
hallar frecuencias de operación adecuadas para los distintos servicios y el considerable
grado de dificultad asociado a este hecho. Es por ello que existen muchos modelos de
optimización que contemplan entre sus cometidos identificar la(s) mejor(es)
frecuencia(s) de operación de los distintas líneas de tren ya que esto permite a su vez
cumplir con un doble objetivo: la minimización de los costes totales de viaje para los
pasajeros y la maximización del beneficio generado para el administrador del sistema
ferroviario.
El problema de la determinación de frecuencias
18
El problema de la determinación de frecuencias, debido al peso fundamental
que tiene en la planificación general de operación de trenes y estaciones, ha sido
ampliamente estudiado. Para RTR por ferrocarril se habla de frecuencias altas y
distancias relativamente pequeñas si comparamos este tipo de servicios con otros
tales como trenes de media y larga distancia.
En cualquier caso, la definición de la frecuencia de operación no sólo afecta
como es evidente al establecimiento de horarios (como más adelante se comentará),
sino que es también un aspecto de notable peso en la planificación general las líneas,
estando muy relacionado con otros aspectos tales como la capacidad de los trenes.
Para un operador es una prioridad atender a toda la demanda de pasajeros existente y
en relación a eso existen varias posibilidades de configuración de la actividad de los
trenes, pudiendo éstos circular con una capacidad de aforo de viajeros relativamente
elevada y con un frecuencia baja o por contra operar con una frecuencia de paso
elevada y una menor capacidad de transporte de pasajeros
Así pues, para RTR según la planificación de horarios que se lleve a cabo se
puede hablar de una programación horaria cíclica o por el contrario no cíclica.
1. Programación cíclica
Las líneas de ferrocarril que operan haciendo uso de una programación cíclica
se caracterizan por que cada transporte cumple con un horario que especifica la hora
de entrada y salida de los trenes por las distintas estaciones contemplando además el
tiempo de parada en cada una de ellas, de forma que dicho horario se repite de
manera periódica. En otras palabras, los trenes siempre entran y salen de las
estaciones con el mismo periodo de tiempo de diferencia entre ellos.
Tal y como ha sido descrito en otros trabajos como (Cadarso & Marín, 2012)
para los pasajeros es más fácil de usar y recordar un servicio con programación cíclica
ya que la frecuencia con la que pasan los trenes en cuestión por una estación
determinada es siempre la misma (en el tramo horario considerado). Por ejemplo, las
horas de paso para una línea de cercanías cuyos trenes pasan 2 veces por hora podría
ser 9:45,10:15,10:45,11:15… y así durante el período de tiempo considerado en la
planificación.
En el apartado de desventajas, tal y como se menciona en (Caprara, Kroon,
Monaci, Peeters, & Toth, 2007), se tiene que la programación de horarios cíclica es
bastante costosa. Esto ocurre debido a que en las horas del día entre las horas pico y
las horas valle de demanda las líneas operan con frecuencias y horarios prácticamente
iguales a los de las horas pico.
El problema de la determinación de frecuencias
19
El único modo de controlar la adecuación entre la demanda de pasajeros y la
capacidad de los trenes con programaciones de este tipo es alterando la longitud de
los trenes, bien mediante operaciones de ensamblado o desensamblado o bien
mediante la introducción de trenes de un tipo diferente a partir del momento que se
considere necesario. Evidentemente esto ocasiona también costes variables de
material rodante y tripulación (los trenes largos requieren de más personal a bordo).
La programación cíclica ha sido objeto de estudio de numerosos trabajos entre
los cuales se pueden destacar (Nachtigall & Voget, 1996) o (Kroon & Peeters, 2003),
que desarrollan el denominado Problema de Programación de Eventos Periódicos
(PESP, por sus siglas en inglés), basado a su vez en el artículo de (Serafini & Ukovich,
1989) en el que, sin considerar la demanda de pasajeros, se conseguía programar un
conjunto de sucesos repetitivos utilizando unas restricciones de períodos de tiempo
cíclicos.
2. Programación no cíclica
La programación horaria no cíclica, aunque menos intuitiva desde el punto de
vista de los pasajeros, es igualmente muy importante en RTR (especialmente en áreas
metropolitanas de tráfico denso), en las que se deben compaginar multitud de
servicios con frecuencias distintas en infraestructuras con unas limitaciones dadas.
Según (Caprara, Kroon, Monaci, Peeters, & Toth, 2007), este tipo de
programación tiene el siguiente planteamiento básico: cada línea en cuestión recorre
un tramo que une dos estaciones principales, una que hace las veces de origen de la
línea y otra que actúa como destino final de la misma, existiendo en medio de ambas
una serie de estaciones intermedias en las cuáles los trenes tienen programada una
parada.
En un principio existe un planteamiento de horario ideal que contempla la hora
de salida desde la primera estación, la hora de entrada y salida de las estaciones
intermedias así como el tiempo de parada y finalmente el tiempo de llegada al destino,
estableciendo además un margen de tiempo en el que puede alterarse la
programación de cada uno de estos aspectos según se necesite para cumplir con el
nivel de demanda de pasajeros.
El hecho de que esta programación horaria sea susceptible a cambios hace que
no se pueda hablar de una frecuencia de servicio constante. Además, aunque existe un
margen recomendable de actuación establecido para las alteraciones en la
programación, lo cierto es que no hay un límite claro para dichas modificaciones.
El problema de la determinación de frecuencias
20
De este modo, pueden llevarse a cabo una gran variedad de acciones posibles:
los trenes pueden disminuir su ritmo de paso por las paradas si la demanda es baja o
aumentarlo en caso contrario, así como también existe la posibilidad de anular la
salida de ciertos trenes desde la primera estación si se considera conveniente o incluso
permitir el adelanto de un tren a otro (ambos de la misma línea) mediante una parada
no planificada del primero en una estación (se consigue así que el segundo recoja a los
siguientes pasajeros evitando la saturación del primero, pero esta acción requiere el
uso de varias vías por trenes de la misma línea de forma simultánea).
Este tipo de organización de horarios no cíclica ha sido considerada en trabajos
muy notables, un ejemplo es (Brännlund, Lindberg, Nou, & Nilsson, 1998), donde se
hacía una discretización del tiempo, dividiendo éste en una serie de intervalos y la
línea de ferrocarril analizada en bloques. El problema de programación se resolvía
utilizando restricciones de modo que evitase el uso de un determinado bloque de la
línea por dos trenes diferentes en un mismo espacio de tiempo.
En (Carraresi, Malucelli, & Pallottino, 1996) también se hace referencia a la
programación no cíclica, aunque en este caso se abordó la cuestión de la efectividad
de las RTR por medio de una mejora consistente en desarrollar un modelo que
minimizase el tiempo de espera de los viajeros modificando los tiempos de salida de
ciertos trenes tomando como dato de entrada la asignación específica de pasajeros
que satisface la capacidad de los trenes implicados.
21
Redes de tránsito rápido por ferrocarril. Segmentos compartidos
Un sistema de transporte de tránsito rápido por ferrocarril es un medio de
transporte de pasajeros que opera de forma separada al resto de sistemas de
transporte urbanos (tranvías, autobuses, etc) y que se caracteriza por operar con una
frecuencia y capacidad relativamente altas, funcionando en áreas metropolitanas de
ciudades con elevada población, de modo que conecta los distintos puntos de una
ciudad, desde el centro hasta las afueras e incluso áreas suburbanas. Las redes de
tránsito rápido por ferrocarril están electrificadas y cabe decir que con frecuencia este
medio de transporte opera en redes subterráneas, aunque se dan casos en los que los
ferrocarriles, (sin contar nunca con pasos a nivel) circulan sobre rieles elevados o a
nivel del suelo. Un ejemplo de red de tránsito rápido podría ser el metro.
Tal y como se indica en (Martínez, Garzón, Melián, Mesa, Moreno, & Ortega,
2005), la población mínima de una ciudad para plantear la posibilidad de crear una red
de tránsito rápido sobre raíles viene determinada por una serie de factores tales como:
densidad de población, disponibilidad de vehículos de transporte privado, congestión
del tráfico, cuestiones medioambientales, etc. En cualquier caso la consideración de
estos factores ha permitido que el límite mínimo de población pase de dos millones de
personas en los años 60 a cerca medio millón en la actualidad, lo que evidentemente
ha derivado en una mayor cantidad de ciudades interesadas en incorporar este tipo de
redes de transporte.
La planificación en redes de tránsito rápido por ferrocarril está compuesta por
una serie de fases relacionadas entre sí: diseño de la red, planificación de líneas,
programación de horarios, planificación de material rodante o vehículos y finalmente
planificación de la tripulación.
El diseño de la red de tránsito tiene por objeto configurar una serie de rutas de
vías por las cuales circularán los trenes, ubicando en dichas rutas una serie de paradas.
Para llevar a cabo este diseño se necesitan conocer datos de topología del terreno (se
sabe así dónde colocar exactamente las vías, las posibilidades de zonas de transbordo,
situación de las terminales de las vías, situación de cocheras, etc) y además datos de la
demanda prevista, que debe venir presentada en forma de una matriz OD (Origen-
Destino) que especifica el número de pasajeros que desea viajar desde cada ubicación
origen a cada destino para cada uno de los tramos horarios que se incluirán en el
servicio. Esto último permite diseñar la red de vías con sus paradas de modo que se
satisfaga la demanda en la mayor medida posible.
Redes de tránsito rápido por ferrocarril. Segmentos compartidos.
22
La planificación de líneas en la terminología ferroviaria consta de una serie de
factores intrínsecos tal y como se comentó en el apartado anterior: un par de
estaciones terminales (una de ella origen y otra destino de cada línea), un conjunto de
paradas intermedias, la frecuencia de los trenes que circulan por esa línea y la
capacidad de dichos trenes. El objetivo de esta planificación es definir un conjunto de
líneas con sus frecuencias de modo que se realice un servicio de transporte adecuado
de acuerdo con determinados objetivos, que para el caso de un planteamiento
multiobjetivo es atender a toda la demanda posible de pasajeros minimizando los
costes para el operador tanto como sea posible. Más adelante se analizará la
planificación de líneas en mayor profundidad.
La programación de horarios se encarga de especificar los tiempos de llegada y
salida de los trenes de cada línea en cada estación o parada. Como se comentó en el
apartado anterior, la programación horaria puede ser cíclica o no cíclica pero en
cualquier caso el procedimiento inicial es establecer una hora de salida desde la
estación terminal origen y posteriormente definir una hora de paso deseada por cada
estación considerando el tiempo que tarda el tren en recorrer la distancia entre cada
par de estaciones (aspecto tenido en cuenta en el diseño de la red) y el tiempo de
parada del tren en cada estación. Para poder hacer esta programación horaria con
éxito evidentemente es necesario partir del conocimiento de las líneas de ferrocarril
implicadas y el recorrido con las paradas que hace cada una, además de conocer la
demanda existente para intentar minimizar los tiempos de espera y viaje de los
pasajeros.
Mediante la planificación del material rodante se decide el número y tipo de
trenes necesario para el correcto funcionamiento de todas las líneas. Esto se consigue
mediante un análisis exhaustivo de los resultados de las planificaciones anteriormente
comentadas. Por ejemplo, si la frecuencia de paso de una línea determinada está
estimada en cinco trenes a la hora, necesitará, a igualdad de capacidad de todos los
trenes, un número mayor de ferrocarriles que en el caso hipotético de que la
frecuencia de paso de dicha línea este fijada en dos ferrocarriles por hora. Esta
frecuencia viene determinada principalmente por el nivel de demanda que se
pretenda atender en cada período de tiempo considerado. Asimismo, deben ser
contemplados en este punto aspectos como el lugar donde se almacena el material
rodante al final de la jornada (usualmente garajes o depósitos cercanos a grandes
estaciones o terminales) así como otro equipamiento rodante reservado para
refuerzos de líneas o imprevistos tales como averías.
Redes de tránsito rápido por ferrocarril. Segmentos compartidos.
23
La planificación de la tripulación tiene por objeto determinar las ocupaciones
de los distintos trabajadores en función del personal necesario para cada uno de los
trenes que componen las distintas líneas. Como se comentó anteriormente esta
planificación tiene que asegurar una plantilla mínima para que todas las líneas
funcionen con garantías pero también se procura que conductores, revisores y demás
personal necesario trabajen de acuerdo a una serie de consideraciones laborales
(límite de días y horas seguidos trabajando, descansos estipulados).
Una vez esclarecidas de forma resumida cada una de las fases de planificación
que atañen a la redes de tránsito rápido por ferrocarril, debido a su mayor grado de
importancia y difícil gestión, a continuación se analizará con mayor detalle la
problemática inherente a la planificación de líneas.
El problema de la planificación de líneas ha sido objeto de investigación de
numerosos estudios. El primer aspecto a considerar es el objetivo buscado, hay
muchos estudios que orientan la planificación de líneas hacia la atención a los
pasajeros y otros que buscan minimizar costes, (Schöbel, 2011) expone una muy
buena recopilación de las principales funciones objetivo y modelos desarrollados
dependiendo del punto de vista considerado.
Así pues, aquellos modelos que están orientados a los costes suelen centrarse
en la minimización de los gastos asociados a la operación de los trenes, siendo un
ejemplo de estos modelos el desarrollado por (Claessens, Van Dijk, & Zwaneveld,
1998), en el cual se definía una estructura de costes que incluía costes fijos por coche
(o vagón) y hora, costes variables por vagón y kilómetro y costes variables por tren y
kilómetro. El problema pues consistía en estructurar las líneas de entre un grupo, sus
frecuencias así como el tipo de tren que opera en cada línea y el número de coches de
cada tren. De este modo, mediante el uso de variables binarias se indicaba si una línea
“l” era operada por trenes del tipo “t” con “c” coches, originando un problema de
programación no-lineal.
Por otro lado, los modelos orientados a los pasajeros suelen tener la común
característica de maximizar el número de viajes directos, lo que a priori parece
ventajoso aunque muchos de estos modelos presentan la grave desventaja de no tener
en cuenta el tiempo total de viaje de los pasajeros, con lo que tienden a dar soluciones
con pocos transbordos pero con tiempos de viaje largos.
Redes de tránsito rápido por ferrocarril. Segmentos compartidos.
24
En (Schöbel & Scholl, 2006) se consideró como función objetivo el tiempo total
de viaje de todos los pasajeros, introduciendo una penalización por cada transbordo
que los viajeros realizaban en el cálculo de dicho tiempo total de viaje, interpretando
así la molestia que los transbordos suponen para los viajeros. Además, se definió un
gráfico denominado “Change&Go” para abordar el problema que suponía la
planificación de líneas y en el que la cuestión radicaba básicamente en encontrar un
camino entre cada par Origen-Destino respetando el presupuesto asignado para los
costes de operación.
Otros factores intrínsecos a la planificación de líneas, tal y como se ha indicado
con anterioridad, son la determinación de la frecuencia de los trenes de cada línea
(aspecto que ya ha sido analizado en el apartado previo), la capacidad de los trenes y,
aunque no se ha citado expresamente aún en el presente capítulo; la correcta gestión
de los tramos compartidos por trenes de distintas líneas.
Evidentemente todos estos factores guardan una fuerte relación entre sí ya que
por ejemplo para atender a una demanda fija una mayor frecuencia de paso de los
trenes supone que la capacidad de los mismos puede verse reducida y viceversa. En
todo caso es importante analizar por separado las singularidades de cada factor.
La capacidad de un tren establece la cantidad de viajeros que pueden viajar en
el mismo, ya sea de pie o en plazas con asiento. En RTR (se puede tomar a modo de
ejemplo la red de cercanías de una ciudad cualquiera) puede darse el caso de que el
número de viajeros que toma un tren supera al número de personas que dicho tren
tiene establecido como capacidad, o en otras palabras se supera el aforo máximo
establecido para ese tren, llegándose en este caso a una situación de sobresaturación
o sobrecarga.
Es deseable evitar este tipo de situaciones pues acarrea una serie de efectos
perjudiciales tanto para el operador como para los usuarios del sistema de transporte.
Algunas de las consecuencias más graves de una situación de sobrecarga se detallan a
continuación:
- Se originan retrasos, lo que altera el funcionamiento de la red y además
imposibilita un cálculo correcto del tiempo de viaje por parte de los viajeros,
ocasionando problemas de planificación horaria para cada persona de forma
individual al no poder saber cuánto tiempo le llevará el desplazamiento.
- El material rodante se sometido a esfuerzos superiores a los previstos, lo que
acarrea mayores costes de operación y mantenimiento.
- Se produce un “coste de oportunidad” para el operador, ya que un sistema
colapsado a ojos de los viajeros es sinónimo de una deficiencia de calidad y por
tanto aumentan las posibilidades de pérdida o fuga de clientes.
Redes de tránsito rápido por ferrocarril. Segmentos compartidos.
25
- Pueden originarse cambios en el comportamiento de los pasajeros,
decantándose éstos ante la sobrecarga por alterar su trayecto a través de la red
dando rodeos a través de otras líneas que sean menos directas para el para
origen-destino considerado.
Si el diseño de la red de tránsito rápido es el apropiado, las situaciones de
sobrecarga pueden prevenirse con una correcta planificación de líneas y horarios, de
modo que se dispongan los trenes en la frecuencia y capacidad suficientes para
atender a la demanda prevista con una cierta holgura.
El otro factor a considerar es la gestión y planificación de la circulación de
trenes por tramos de vías compartidos entre varias líneas, factor para el cual debe
tenerse muy en consideración el problema de la determinación de frecuencias, ya
comentado en el anterior apartado y que está muy relacionado con este punto, siendo
su resolución de vital importancia para una correcta planificación de los segmentos
compartidos.
El uso de tramos compartidos es beneficioso desde el punto de vista económico
ya que supone un ahorro en la construcción y mantenimiento de infraestructuras y a la
vez proporciona más alternativas de viaje a los usuarios de esos tramos, que pueden
escoger entre más de una línea y ven aumentadas sus opciones de enlace de una línea
a otra a través de transbordos.
No obstante, el hecho de que dos líneas distintas hagan un uso común de un
tramo de vías hace que sea necesaria una planificación y gestión de la operación
especialmente cuidadosas con respecto a esos tramos compartidos. En primer lugar,
para que dos líneas de ferrocarril distintas usen un mismo tramo existe el requisito de
que las frecuencias de paso de los trenes de las líneas implicadas no sean muy altas. Se
puede poner como ejemplo de incompatibilidad dos líneas de frecuencias de 10 y 6
trenes a la hora respectivamente (es decir los trenes de las dos líneas pasan cada 6 y
10 min respectivamente), ya que suponiendo un tiempo de seguridad entre trenes de
un minuto y un tiempo de parada en estación de un minuto se tiene como resultado
una obstrucción mutua en la circulación de los ferrocarriles de las dos líneas, tal y
como se muestra en la siguiente figura:
Redes de tránsito rápido por ferrocarril. Segmentos compartidos.
Fig. 1.1 Incompatibilidad entre líneas con frecuencias de 10 y 6 trenes/hora.
Por lo tanto, se debe partir del hecho de que la frecuencia de las líneas debe
ser compatible y para ello dichas frecuencias no pueden ser altas. Otra
usualmente se debe cumplir es que una de las frecuencias sea múltiplo de la otra, lo
que permite una buena coordinación de la circulación de los trenes de ambas líneas.
Aún con esto la condición de multiplicidad no es completamente exigible,
frecuencias de paso relativamente bajas, (como es el caso de 2 y 3 trenes a la hora) se
pueden encontrar planificaciones perfectamente válidas. Por tanto se concluye que la
multiplicidad es un requisito recomendable pero no obligatorio.
Una vez halladas frecuencias de paso compatibles para las líneas que pueden
verse implicadas en la compartición de tramos se deberá decidir la conveniencia o no
de adoptar ese modo de funcionamiento atendiendo a otros aspectos como pueden
ser la viabilidad en lo referido a una correcta atención de la demanda o la dificultad de
la gestión operativa de esas líneas, ya que cualquier pequeña incidencia en un tren de
una línea (por ejemplo un retraso) tiene un potencial efecto perjudicial en la otra y
exigirá una reprogramación circunstancial que posiblemente condicionará la
circulación de los trenes durante un cierto intervalo de tiempo.
En definitiva el uso de tramos de vías compartidos abre un campo de operación
con beneficios muy interesantes pero con ciertos condicion
tener en cuenta por lo que para decidir si es posible y aconsejable su implantación se
debe analizar con detenimiento tanto su viabilidad como las ventajas y desventajas
inherentes a cada caso particular.
rápido por ferrocarril. Segmentos compartidos.
26
Fig. 1.1 Incompatibilidad entre líneas con frecuencias de 10 y 6 trenes/hora.
Por lo tanto, se debe partir del hecho de que la frecuencia de las líneas debe
ser compatible y para ello dichas frecuencias no pueden ser altas. Otra
usualmente se debe cumplir es que una de las frecuencias sea múltiplo de la otra, lo
que permite una buena coordinación de la circulación de los trenes de ambas líneas.
Aún con esto la condición de multiplicidad no es completamente exigible,
frecuencias de paso relativamente bajas, (como es el caso de 2 y 3 trenes a la hora) se
pueden encontrar planificaciones perfectamente válidas. Por tanto se concluye que la
multiplicidad es un requisito recomendable pero no obligatorio.
lladas frecuencias de paso compatibles para las líneas que pueden
verse implicadas en la compartición de tramos se deberá decidir la conveniencia o no
de adoptar ese modo de funcionamiento atendiendo a otros aspectos como pueden
erido a una correcta atención de la demanda o la dificultad de
la gestión operativa de esas líneas, ya que cualquier pequeña incidencia en un tren de
una línea (por ejemplo un retraso) tiene un potencial efecto perjudicial en la otra y
mación circunstancial que posiblemente condicionará la
circulación de los trenes durante un cierto intervalo de tiempo.
En definitiva el uso de tramos de vías compartidos abre un campo de operación
con beneficios muy interesantes pero con ciertos condicionantes de funcionamiento a
tener en cuenta por lo que para decidir si es posible y aconsejable su implantación se
debe analizar con detenimiento tanto su viabilidad como las ventajas y desventajas
inherentes a cada caso particular.
rápido por ferrocarril. Segmentos compartidos.
Fig. 1.1 Incompatibilidad entre líneas con frecuencias de 10 y 6 trenes/hora.
Por lo tanto, se debe partir del hecho de que la frecuencia de las líneas debe
ser compatible y para ello dichas frecuencias no pueden ser altas. Otra condición que
usualmente se debe cumplir es que una de las frecuencias sea múltiplo de la otra, lo
que permite una buena coordinación de la circulación de los trenes de ambas líneas.
Aún con esto la condición de multiplicidad no es completamente exigible, ya que a
frecuencias de paso relativamente bajas, (como es el caso de 2 y 3 trenes a la hora) se
pueden encontrar planificaciones perfectamente válidas. Por tanto se concluye que la
lladas frecuencias de paso compatibles para las líneas que pueden
verse implicadas en la compartición de tramos se deberá decidir la conveniencia o no
de adoptar ese modo de funcionamiento atendiendo a otros aspectos como pueden
erido a una correcta atención de la demanda o la dificultad de
la gestión operativa de esas líneas, ya que cualquier pequeña incidencia en un tren de
una línea (por ejemplo un retraso) tiene un potencial efecto perjudicial en la otra y
mación circunstancial que posiblemente condicionará la
En definitiva el uso de tramos de vías compartidos abre un campo de operación
antes de funcionamiento a
tener en cuenta por lo que para decidir si es posible y aconsejable su implantación se
debe analizar con detenimiento tanto su viabilidad como las ventajas y desventajas
27
Modelo Propuesto
El modelo que se desarrolla y expone en el presente proyecto tiene por objeto
determinar los valores óptimos de frecuencia (aspecto asociado al problema de
planificación de líneas, Line Planning Problem [LPP] en inglés) y capacidad de los trenes
de cada línea de una red de transporte por ferrocarril de modo que se minimicen los
costes de operación de dicha red, todo ello atendiendo al mayor porcentaje posible de
pasajeros que conforman la demanda existente (para tal efecto se construye una
matriz con los datos de los viajeros para cada Origen-Destino en un período de tiempo
de una hora); siendo un modelo aplicable preferentemente a redes de tránsito rápido
(por ejemplo redes de metro o cercanías).
Además, el modelo propuesto contempla la posibilidad de asignación de rutas
para el desplazamiento de los pasajeros en función de las capacidades de los trenes.
Existen numerosos estudios que analizan los diversos efectos de la frecuencia
de paso de los trenes así como su capacidad, como es el caso de (Deng, Zeng, Zhou, &
Shi, 2014), donde el objetivo es determinar el efecto de la frecuencia y la capacidad de
los trenes sobre la programación de la circulación de los mismos, analizando también
la influencia de dichos factores sobre la demanda de pasajeros. Otro trabajo en este
campo muy reseñable es el de (Hu & Liu, 2014), en el que mediante un método de
programación matemática se desarrolla un modelo de cálculo de “headways”
(diferencia de tiempo entre trenes consecutivos de una misma línea, parámetro
inversamente proporcional a la frecuencia) dirigido a minimizar los costes de un
sistema de tránsito rápido basándose también en series temporales de datos sobre la
distribución espacio temporal de los pasajeros.
1. Exposición de los elementos del modelo
1.1. Sets
• L; conjunto de líneas
• N; conjunto de nodos (estaciones)
• A; conjunto de arcos (i,j): i, j Є N
• W; conjunto de pares Origen-Destino en la red
Notación auxiliar:
� ���� = �1 � �� �í �� � ������� �� ���� ��, ��Є � 0 � ���� ��� �
� ��� = �1 � �� �í �� � ��� ��� �� ��� � Є � 0 � ���� ��� �
El modelo propuesto
28
• ST; conjunto de tramos de vías que incluyen segmentos compartidos (conjunto
de arcos que son recorridos por más de una línea), = ��, �� ∈ �: ∑ ���� > 1� ∈" .
• L(s); conjunto de líneas que recorren segmentos s Є ST.
• NT(s); número de vías del segmento s Є ST: |NT(s) ≤ L(s)|.
• V; conjunto de valores enteros de headways admisibles en el modelo,
o V= {2,3,4,5,6,10,12,15,20} (en minutos).
1.2. Notación de índices
• l se refiere a una línea que pertenece al conjunto L. l´ se empleará para denotar
a otra línea cuando sea necesario.
• i,j indican estaciones pertenecientes a N.
• w señala un par Origen-Destino genérico perteneciente a W. wo representa el
origen del par w mientras que wd representa el nodo destino.
• ѵ se refiere a un valor de headway (o frecuencia) admisible que pertenece al
conjunto V. “ѵ´” se empleará para representar otro headway cuando sea
necesario.
• s simboliza un segmento dentro de ST.
1.3. Parámetros
• ɣl; longitud de la línea l Є L en kilómetros (km).
• gw; elemento de la matriz de demanda correspondiente al par Origen-Destino
w Є W.
• v; velocidad comercial en kilómetros por hora (km/h) de los trenes (velocidad
media de circulación de los ferrocarriles por los arcos que componen la red).
• C; capacidad de un coche o vagón (número de pasajeros con plaza, tanto
sentados como a pie).
• NVmax; número máximo de coches no autopropulsados en un tren. Debe
indicarse que los trenes están compuestos por dos vagones autopropulsados
en la cabeza y cola del ferrocarril y un número variable de coches no
autopropulsados.
• NVmin; número mínimo de coches no autopropulsados en un tren.
• dij; longitud del arco (i,j) Є A en kilómetros (km).
• Vmax; valor máximo del conjunto V.
• sft; headway de seguridad en arcos y estaciones en minutos (min).
• Dwt; tiempo de parada en estaciones en minutos (min).
• ckmloc; coste variable de operación de una locomotora, dependiente de la
capacidad y la frecuencia de línea. Expresado en Euros por kilómetro.
• ckmcarr; coste variable de operación de un vagón (no autopropulsado),
dependiente de la capacidad y la frecuencia de línea. Expresado en Euros por
kilómetro.
El modelo propuesto
29
• ctloc; coste de compra de una locomotora en millones de euros (M€).
• ctcarr; coste de compra de un vagón (no autopropulsado) en millones de euros
(M€).
• Hor; horizonte temporal para imputar costes por la compra de material rodante
en años.
• Ѳѵѵ´; elemento de la matriz de compatibilidad de valores de frecuencia, toma
valor igual a 1 si las frecuencias ѵ y ѵ´son compatibles y 0 en otro caso.
• Ѳ1; valor monetario del tiempo de viaje expresado en €/minuto (min).
• Ѳ2; valor monetario de los transbordos expresado en €/transbordo.
• Ѳ4; valor monetario de los costes de la tripulación a cargo de cada ferrocarril,
expresado en €/hora.
1.4. Variables
• #��$�; flujo (número de pasajeros) correspondiente al par Origen-Destino w que
recorren el arco (i,j) usando la línea l.
• ��$��´; flujo correspondiente al par Origen-Destino w que hacen transbordo
desde la línea l hasta la línea l´ en la estación i, (con i distinto de wo,wd).
• %��$�; variable binaria empleada en evitar la formación de bucles en las rutas de
los distintos flujos, siendo el significado de sus posibles valores el siguiente:
�1 � �� #�&�� ��� ��� ' ������� �� �� ���� ��, �� ∈ � ���� � � � &� �� �� �í �� � ∈ ( 0 � ���� ��� �
• hdl; headway de la línea l Є L.
• fl; frecuencia de la línea l Є L, dicha frecuencia sólo puede tomar los valores del
conjunto V.
• )�ѵ; variable binaria utilizada para asignar las frecuencias a cada línea, sus dos
posibles valores son:
�1 � �� #���&� ��� ѵ ℎ� ��� ������� ��� ���� �� �í �� � 0 � ���� ��� �
• -.�/; variable binaria empleada para asignar líneas a ciertas vías en segmentos
compartidos, el significado de los valores que puede tomar se define a
continuación:
�1 � �� �í �� � ℎ� ��� ��0 ��� � �� 1í� � ��� �02� �� ��2������� 0 � ���� ��� �
• #.�/; frecuencia de la línea l en la vía t del segmento compartido s.
• nvl; número de vagones no autopropulsados para los trenes de la línea l Є L .
• natdemw; número de pasajeros del par Origen-Destino w que el modelo no
consigue atender.
El modelo propuesto
30
1.5. Función objetivo
Tal y como se ha expuesto al inicio del presente capítulo, el objetivo del modelo
es determinar el valor óptimo de una serie de factores (frecuencia y capacidad de las
distintas líneas) así como el analizar otros aspectos asociados a la planificación de una
red de tránsito rápido por ferrocarril (rutas de los pasajeros, gestión de tramos
compartidos), todo ello a fin de establecer un régimen de operación para los distintos
elementos de la red que permita minimizar los costes de operación del sistema
considerado.
Este propósito queda reflejado en el presente modelo a través de la siguiente
función objetivo (FO):
345 67 8 &$$∈9
+ 6; 8 8 8 8 ��$��< + 8 2#�>��∈"
��?2�@A + �?2ABCC� 1� + 1���∈":
DEFG7�<∈":DEF<G7
�∈H$∈9
+6I 8 2 >�1 #��∈"
+ J�� 8 K 2 >�1 #��2���@A + ��ABCC 1��L +�M"
8 5 ∗ 10�P� ����2$�$Є9
Como se puede ver, la función objetivo considerada consta de cinco términos
que pueden ser analizados de manera independiente, de los cuáles los dos primeros
cuantifican costes relacionados con el consumidor y los tres últimos determinan
costes ligados al operador de la red, más un componente de penalización por demanda
no atendida:
� La primera parte de la FO; 67 ∑ &$$∈9 ; (siendo “uw” la suma total de los
tiempos de viaje) cuantifica el coste asociado al tiempo de viaje para todos los
posibles pares origen-destino contemplados.
� El Segundo miembro de la FO; 6; ∑ ∑ ∑ ∑ ��$��<�∈":DEFG7�<∈":
DEF<G7�∈H$∈9 ; establece una
penalización por el número de transbordos que se producen en toda la red.
� El tercer sumando de la FO; ∑ 2#�>��∈" ��?2�@A + �?2ABCC� 1� + 1��; mide el
coste variable de operación debido a la distancia recorrida por los trenes de las
distintas líneas y al servicio de mantenimiento correspondiente a cada
ferrocarril.
El modelo propuesto
31
� El cuarto término de la FO; 6I ∑ 2 QFR #��∈" ; determina el coste asociado al
tiempo de operación de los trenes (concretamente el coste por hora de
funcionamiento). Se trata, dicho de otro modo, de los gastos asociados a la
tripulación de los distintos trenes.
� El quinto y último componente de la FO; J�� ∑ S 2 QFR #��2���@A +�M"
��ABCC 1��T; estima el coste asociado a la adquisición del material rodante
(coches autopropulsados [o locomotoras] y no autopropulsados para todos los
trenes necesarios), atendiendo a un horizonte temporal de Hor años en el que
se amortizarán los costes de compra.
� La penalización por demanda no atendida; ∑ 5 ∗ 10�P� ����2$�$Є9 ;
establece un fuerte “castigo” económico sobre la función objetivo por cada
pasajero que el modelo no consigue desplazar de acuerdo a su par Origen-
Destino, de modo que se incita al modelo a que intente atender a toda la
demanda posible, aún a costa de acarrear en mayores costes en otros sentidos.
1.6 Restricciones
1.6.1 Restricciones de Flujo y Transbordos
Restricciones (1):
8 8 #$U�$�
�∈":BVUWF G7�∈X�$U�
= 0$ − ����2' ∀' ∈ [
Restricciones (2):
8 8 #�$\
$��∈":
BWV\F G7�∈X�$\�= 0$ − ����2' ∀' ∈ [
Restricciones (3):
8 8 #��$�
�∈":BEWF G7�∈X���
= 8 8 #]�$� ∀' ∈ [ , ∀� ∈ �{'@, '_}�∈":
BaEF G7]∈X���
El modelo propuesto
32
Restricciones (4):
8 8 #��$�
�∈":BWEF G7�∈X���
+ 8 8 ��$�<��∈":
DEFG7�<∈":DEF<G7
= 8 8 #�]$��∈":
BEaF G7]∈X���+ 8 8 ��$��< ∀� ∈ ( ,
�∈":DEFG7
∀' ∈ [, ∀� ∈ �{'@ , '_}�<∈":
DEF<G7
Restricciones (5):
%��$� + %��$�´ ≤ 1 ∀ ��, �� ∈ � , ∀' ∈ [, ∀� ∈ (: d���� = 1e , ∀ �´ ∈ (: d����´ = 1e
Restricciones (6):
#��$� ≤ %��$� · 0$ ∀ ��, �� ∈ � , ∀' ∈ [, ∀� ∈ (: d���� = 1e El bloque de restricciones arriba indicadas tiene el objeto de garantizar la
continuidad de las variables que representan los distintos flujos de pasajeros. Así pues,
la condición (1) establece que la suma de todos los flujos salientes del nodo origen wo
para un determinado par w debe ser igual al correspondiente elemento de la matriz de
demanda Origen-Destino para ese mismo par (gw), menos la demanda no atendida
(natdemw). La restricción (2) dispone algo parecido a la anterior pero en este caso
atendiendo al nodo destino del par, de modo que la suma de todos los flujos entrantes
en dicho nodo destino wd debe ser igual al correspondiente elemento de la matriz de
demanda Origen-Destino para ese par en concreto (gw) menos la demanda no atendida
(natdemw).
Mediante (3) se garantiza la conservación del flujo, de modo que para cada uno
de los pares Origen-Destino w, se ha de cumplir que, para un nodo distinto del nodo
origen wo y del nodo destino wd la suma de todos los flujos que entran han de ser igual
a la suma de todos los flujos salientes. Por otro lado, a través de (4) se certifica la
conservación en los transbordos, cumpliéndose que, para cada par Origen-Destino w y
en cada nodo de cada uno de esos pares OD que no sea ni el nodo origen wo ni el nodo
destino wd, la suma del flujo de pasajeros que llega mediante la línea l más el flujo
pasajeros que en ese mismo nodo hacen transbordo desde una línea l´ diferente a la
anterior a la línea l debe ser igual a la suma del flujo viajeros que abandonan el nodo
considerado empleando la línea l más el flujo correspondiente al número de pasajeros
que se transfieren desde l hasta l´.
El modelo propuesto
33
El objeto de la restricción (5) es impedir la formación de bucles en las rutas que
se establezcan para los diferentes flujos. Mediante variables binarias se impide que un
arco sea recorrido por una o diferentes líneas en ambos sentidos para un mismo par
Origen-Destino w. En ocasiones, al realizar cálculos computacionales se obtienen
soluciones poco realistas en las que aparecen bucles de modo que algunos tramos son
recorridos en dos o más ocasiones y en ambos sentidos en lugar de utilizar otras rutas
sin bucles, y es precisamente para evitar eso por lo que se incorpora esta restricción.
La relación entre las variables binarias comentadas en el apartado anterior y los
distintos flujos de pasajeros por la red se establece a través de (6), de modo que se
garantice que si está prohibido por (5) el recorrido de una línea l a través de un tramo
i,j para un determinado par origen-destino w, el flujo correspondiente a los pasajeros
que recorrerán ese arco i,j a bordo de esa línea l para ese par concreto w
necesariamente debe valer 0. Y evidentemente, para los casos en los que sí esté
permitida la circulación según (5), el valor del flujo de pasajeros al que se acaba de
hacer referencia será como máximo igual al correspondiente elemento de la matriz de
demanda Origen-Destino para el par considerado, gw.
1.6.2 Restricciones de tiempo de viaje
Restricciones (7):
#@$� = 8 #$U� $� ∀' ∈ [ , � ∈ (: {�$U� = 1}�∈X�$U�:
DWFG7
Restricciones (8):
&$ = 8� 8 601��,��∈h:
BEWF G7
���#��$� + 12 #@$�ℎ�� + 1
2 8 8 ��$��<
�<∈":DEF<G7
�∈H:DEFG7
ℎ��<��∈"
∀' ∈ [
Este bloque de restricciones regula un correcto cálculo del tiempo medio de
viaje de los usuarios de la red en clave de flujos anteriormente descritos. De este
modo, con (7) se determina el valor del parámetro #@$�, flujo que refleja cantidad total
de pasajeros que salen desde el nodo origen wo del par w usando la línea l. Dicho flujo
es usado posteriormente en (8) junto con otros factores para cuantificar el tiempo
total de viaje de los pasajeros de los distintos pares Origen-Destino w considerando
los caminos empleados para llevar a cabo el desplazamiento desde el nodo origen de
cada par wo hasta el correspondiente nodo destino de ese mismo par wd.
El modelo propuesto
34
1.6.3 Restricciones de frecuencias y headways
Restricciones (9):
#� · ℎ�� = 60 ∀� ∈ (
Restricciones (10):
#� = 8 ѵ · )� ѵ ∀� ∈ (ѵ∈i
8 )�ѵѵ∈i
= 1 ∀� ∈ (
Las restricciones (9) y (10) están formuladas con el propósito de regular los
posibles valores de frecuencias o headways así como la relación existente entre ellos.
En (9), queda patente que ambos factores son inversamente proporcionales, mientras
que mediante las condiciones especificadas en (10) se fuerza a que la frecuencia para
cada una de las líneas tome un único valor entero de los especificados en el conjunto
V.
1.6.4 Restricciones de tramos de vías compartidos por varias líneas
Restricciones (11):
8 -.�//∈Hj�.�
= 1 ∀ ∈ kl, ∀� ∈ (��
Restricciones (12):
#� = 8 #.�/ ∀ ∈ kl, ∀� ∈ (��/∈Hj�.�
Restricciones (13):
#.�/ ≤ mnBo. -.�/ ∀ ∈ kl, ∀� ∈ (��, � ∈ �l�� Restricciones (14):
8 #.�/�#� + �'�� ≤ 60 ∀ ∈ kl, � ∈ �l�� �∈"�.�
El modelo propuesto
35
Restricciones (15):
-.�/ + -.�′/ ≤ 3 + 6RR′ − S)�R + )�′R′r ∀ ∈ kl,
� ∈ �l��, �, �´ ∈ (��: � < �´,
ѵ, ѵ´ ∈ m: ѵ < ѵ´
Este conjunto de restricciones regula la asignación de líneas a vías en
segmentos compartidos así como los posibles valores de las frecuencias de cada línea y
la compatibilidad entre dichas frecuencias. De este modo, mediante (11) se impone
que cada línea que recorra un tramo compartido sea asignada a una única vía de ese
tramo.
En (12) se divide la frecuencia original de cada línea en un conjunto de
frecuencias variables, una para cada vía existente en el tramo compartido y
posteriormente a través de las condiciones establecidas en (13) se fuerza a que sólo
una de este conjunto de frecuencias sea positiva, que será aquella que corresponda a
la frecuencia de la línea que se asignó a la vía en cuestión con la restricción (11), siendo
dicho valor igual a la frecuencia de circulación de la línea fuera de los tramos
compartidos y teniéndose como límite superior para dicha frecuencia el máximo del
conjunto V.
La restricción (14) garantiza que exista tiempo material para la operación de
todas las líneas de ferrocarril que circulen en la vía t del tramo compartido s durante el
intervalo de tiempo considerado, que en este caso es de una hora y lo hace
contemplando el tiempo de seguridad entre trenes, el tiempo de parada en las
estaciones y los valores de frecuencia de esas líneas en el tramo compartido.
La compatibilidad entre las frecuencias de las líneas que operan en la vía t del
segmento compartido s queda determinada por la restricción (15), lo que se consigue
introduciendo el término Ѳѵѵ´ correspondiente a la matriz de compatibilidad de valores
de frecuencia y que especifica si dos líneas con sus respectivos valores de frecuencia (ѵ
y ѵ´) se pueden compaginar o no. En caso afirmativo este término vale 1 y la
implantación de las líneas en la misma vía resulta posible. En caso negativo el valor es
0 y por lo tanto ambas líneas no podrán usar la vía en cuestión de forma simultánea. El
uso en (15) de las variables )�R % )�′R′
resulta imprescindible ya que no se sabe a priori el
valor que tomarán las frecuencias de las líneas implicadas.
El modelo propuesto
36
1.6.5 Restricciones de capacidad
Restricciones (16):
8 #��$�$∈9
≤ �2 + 1��. t. #� ∀��, �� ∈ �, ∀� ∈ (: ���� = 1
Restricciones (17):
�mn�u ≤ 1� ≤ �mnBo � ∈ (
Las restricciones de capacidad descritas en esta sección tienen el objeto de
cuantificar el número de coches necesario para los trenes de cada línea así como
asegurar que dicha cantidad de vagones se encuentra dentro de unos límites
establecidos.
Así pues, en (16) se fija la cantidad mínima de vagones para los ferrocarriles de
cada línea en función del flujo de pasajeros que se mueve por dicha línea para cada
arco del recorrido, teniéndose en cuenta para ello tanto la capacidad de viajeros por
vagón como la frecuencia de los trenes.
Finalmente, con (17) se garantiza un tamaño mínimo y máximo para los
ferrocarriles de las distintas líneas obligando a que el número de vagones no
autopropulsados nvl esté comprendido entre dos límites, NVmin como valor mínimo y
NVmax como valor máximo.
37
Resolución por medio de GAMS
1. Introducción al software “GAMS”
Para probar la utilidad y eficacia del modelo propuesto en el apartado anterior
es necesario evaluarlo mediante la realización de experiencias computacionales en las
que dicho modelo es aplicado a una serie de casos prácticos o ejemplos de redes de
tránsito rápido por ferrocarril. Posteriormente a la ejecución de dichas pruebas será
posible analizar los datos que arroja como resultado de las planificaciones operativas
que realiza (en materia de flujos, frecuencias…) para lograr la optimización en costes
para cada una de las redes estudiadas. Ése análisis de datos y resultados permitirá
comprender como se comporta o trabaja el modelo, hasta qué punto resulta útil, qué
fallos presenta y si es posible depurarlo de una manera u otra.
Para llevar a cabo dicha experimentación es necesario emplear un software
apropiado que permita implementar y aplicar modelos de optimización, además de
permitir una visualización y análisis profundos de los datos y resultados que se
obtendrán tras la resolución de cada problema con el modelo en cuestión. El software
que ha sido elegido con estos fines y que se usará para la resolución de los escenarios
propuestos en el presente proyecto es GAMS (General Algebraic Modeling System).
Desarrollado a finales de la década de los ochenta (aunque el concepto de
GAMS ya existía y fue objeto de coloquio previamente, en los años setenta) por un
conjunto de economistas (Anthony Brooke, David Kendrick y Alexander Meeraus) del
Banco Mundial, GAMS fue concebido como una aplicación que permitía una
modelización integral de problemas de desarrollo económico y la utilización de
programas de optimización que permitía obtener una solución numérica y concreta a
los diferentes modelos propuestos. En 1987 GAMS se convierte en un producto
comercial y rápidamente expande su uso más allá de índoles económicas, teniendo
actualmente un ámbito de aplicación y utilidad amplísimo.
GAMS es un programa de alto nivel ampliamente utilizado para el modelado y
resolución de una gran variedad de problemas (tanto lineales como no lineales, entre
otros tipos). Dicho software funciona planteando un lenguaje de modelización que
posibilita escribir la formulación matemática del problema en cuestión, con todas las
variables, parámetros, restricciones y otros elementos que ello implica para
posteriormente emplear un “solver” o software de resolución (GAMS posee una
amplia selección disponible para su uso según la licencia disponible) para encontrar la
solución óptima del modelo.
Resolución por medio de GAMS
38
Este software presenta un entorno de desarrollo integrado (en adelante IDE,
por sus siglas en inglés) que actúa como editor de código fuente y depurador,
ofreciendo una serie de herramientas de construcción automáticas además de otras
utilidades de bastante importancia.
Fig. 1.1 Interfaz del IDE de GAMS. Fuente: GAMS 22.9.2
En el IDE de GAMS pueden distinguirse dos partes bien diferenciadas; por un
lado la pantalla en la que se escriben los comandos (recuadro azul en Fig. 1.1) y por
otra la barra de herramientas con los botones de acción principales (recuadro rojo en
Fig 1.1.).
La barra de herramientas se compone de 7 pestañas:
• File (archivo); recoge las opciones básicas de creación de nuevos archivos,
apertura de ficheros existentes, guardado e impresión. Permite el acceso a
opciones más avanzadas de edición de archivos, compilación, ejecución,
manejo de solvers, licencias y proyectos.
• Edit (edición); abarca comandos genéricos orientados a la edición del
archivo como son los comandos cortar, copiar, pegar, seleccionar todo,
deshacer o rehacer; entre otros.
• Search (búsqueda); reúne herramientas destinadas a la búsqueda de
información (buscar texto, reemplazar, enlazar paréntesis, etc).
• Windows (ventana); contiene los distintos tipos de visualización disponibles
para la ventana del IDE.
Resolución por medio de GAMS
39
• Utilities (herramientas); contiene comandos muy útiles pero cuyo uso por lo
general es menos frecuente. Las herramientas contenidas en la pestaña son
4 en concreto: GDXDiff, un software que compara la información de
entidades del mismo nombre y tipo, borrado de los archivos 225 (donde se
almacenan los datos de las ejecuciones realizadas para un proyecto de
GAMS), manejo de comandos y finalmente editor de opciones.
• Model libraries (librerías de modelos); conjunto de librerías con modelos
pre-programados listos para su uso y orientados cada uno a la resolución de
un problema tipo.
• Help (ayuda); sección habitual de ayuda al usuario, ofrece apartados con
consejos para el manejo de GAMS, información acerca del software y guías
de uso del programa y de los solvers.
Los botones que aparecen debajo de la barra de herramientas (también dentro
del recuadro rojo en Fig 1.1) son “accesos directos” de algunos de los comandos con
mayor frecuencia de uso contenidos en las pestañas anteriormente descritas. De
izquierda a derecha, los botones corresponden a las instrucciones de apertura de
archivo, guardado, búsqueda en ficheros, búsqueda general, repetición de la
búsqueda, texto a buscar, enlace de paréntesis, impresión y ejecución de GAMS.
En lo referente a la programación e implantación del código en el IDE de GAMS,
la variedad de opciones, utilidades y comandos es enorme. Desde este punto de vista a
continuación se describen, de forma muy breve y según la información recogida en
(Rosenthal, 2008) los elementos e instrucciones principales que se han empleado en la
construcción del modelo:
Fig. 1.2 Estructura básica de un modelo GAMS. Fuente: (Rosenthal, 2008)
Resolución por medio de GAMS
40
• Sets (conjuntos); unidad básica de construcción de bloques en GAMS,
corresponden a los índices que se emplean en la representación algebraica del
modelo.
• Data (información del modelo); son los datos de entrada que se le facilitan al
software acerca del modelo de optimización. Existen tres formas principales de
introducción de estos datos:
� Parameters (parámetros)
� Tables (Tablas)
� Scalars (escalares)
• Variables; constituyen aquellos elementos necesarios para el modelo que
carecen de un valor de entrada ya que es el propio modelo el que, mientras
resuelve el caso computacional, asigna el valor más apropiado para cada
variable. Es necesario declararlas (se informa al software de que existen) y
definir su tipo (pueden ser libres, enteras, binarias, positivas y negativas) para
que el modelo las pueda manejar.
Fig. 1.3 Estructura básica de un modelo GAMS. Fuente: (Rosenthal, 2008)
• Equations (ecuaciones); son los elementos que representan las estructuras
algebraicas que conforman el modelo (restricciones, relaciones entre variables,
parámetros, factores, e incluso función objetivo) en un lenguaje que GAMS
puede entender e interpretar. Deben ser declaradas y luego definidas (se
establece la estructura con los componentes de la ecuación).
• Display (instrucciones de visualización); comandos orientados a modificar la
salida estándar de datos. Permite analizar de forma cómoda el valor de las
variables o sets que se consideren importantes.
• Model and Solve Statement; es la instrucción que se usa para transmitirle a
GAMS cuáles de las ecuaciones definidas participan en la ejecución, el tipo de
modelo y la dirección de optimización.
• Alias; comando destinado para dar otros nombres a un set que ha sido
previamente definido.
Resolución por medio de GAMS
41
• Sumatorios; consta de dos partes, una primera donde se detallan los índices del
sumatorio y las condiciones de aplicación del mismo (si las hubiere) y una
segunda donde se define la estructura de los sumandos.
• Loop (bucle); realiza un recorrido por todos los posibles valores del set que lo
define.
• If (condición); establece un requisito para que pueda ejecutarse un
determinado comando o acción (en la definición de ecuaciones, sets y
sumatorios se usa el símbolo “$”).
• Variable.lo y variable.up; comandos para la asignación de límite inferior y
superior para el valor de cualquier variable.
• $Ontext y $Offtext; comandos empleados para convertir las líneas de código
que queden encuadradas entre ellos en comentarios (el símbolo “*” a principio
de línea tiene la misma función, pero sólo para dicha línea).
• $include; inserta el código de otro fichero en el archivo actual.
En cuanto a los tipos de ficheros que genera y maneja GAMS para la
experimentación con modelos, cabe decir que destacan los siguientes cuatro:
• Fichero .gms; archivo en el que se ha escrito el código de programación
mediante el IDE de GAMS.
• Fichero .lst; es un archivo de salida que genera el programa después de una
ejecución, muestra los resultados del experimento y es esencial para el análisis
del comportamiento del modelo.
• Fichero .lxi; contiene la información que el IDE utiliza para crear la ventana de
navegación que permite investigar el fichero .lst.
• Fichero .log; almacena información importante relacionada con el estado de la
ejecución realizada y la solución hallada (si la hubiese).
Fig. 1.4 Ejemplo de archivo .LST. Fuente: GAMS 22.9.2
Resolución por medio de GAMS
42
2. Solvers
Como se ha señalado anteriormente, para resolver los problemas de modelado
y optimización GAMS emplea los denominados “solvers” o software de resolución. Un
solver es un término empleado para describir un programa de lógica matemática cuya
utilidad es encontrar la solución óptima de un problema empleando para ello un
procedimiento determinado que dependerá del solver en cuestión.
En la actualidad se cuenta con una amplía cantidad de solvers, pudiendo
utilizarse cada uno de ellos en función del tipo de problema o modelo a resolver. Los
solvers más genéricos se apoyan en la arquitectura presentada por el programa
pionero GPS (General Program Solver, cuya traducción aproximada al castellano es
“Solucionador General de Problemas”), desarrollado en 1957 y descrito en (Newell,
Simon, & Shaw, 1959) fue presentado como un solver universal que, en teoría, podía
resolver cualquier problema (que pueda trasladarse a un lenguaje simbólico) con la
configuración adecuada.
De este modo, estos solvers genéricos, al igual que GPS, utilizan un código que
a partir de los datos y la definición del problema a resolver generan una estrategia
específica para abordarlo. La diferencia entre GPS y los solvers actuales es que éstos
están mucho más perfeccionados de modo que permiten una aproximación muy
especializada para el tipo de problema para el cual han sido diseñados.
GAMS implementa una colección de solvers que son capaces de solucionar
problemas de diversa índole, estando la disponibilidad de cada uno de dichos software
de resolución sujetos a la licencia del programa que el usuario en cuestión posea.
Fig. 2.1 Pantalla de selección de solver en GAMS. Fuente: GAMS 23.0
Resolución por medio de GAMS
43
A continuación se describirán brevemente las características más reseñables de
cada uno de los solvers que se emplearán en la resolución de cada uno de los casos de
estudio contemplados para el modelo expuesto en el presente proyecto (debe tenerse
en cuenta que estos solvers necesariamente deben ser capaces de solucionar casos del
tipo MINLP [Mixed Integer Non Linear Programs], ya que es la clase de problemas que
el modelo que presenta por la propia definición del mismo):
2.1 CoinBonMin
De acuerdo con lo expuesto por (COIN-OR Foundation), se trata de un solver de
código abierto que se utiliza en la programación MINLP, estando algunas de las partes
de dicho solver aún en fase experimental. El código de CoinBonMin fue desarrollado
en un proyecto conjunto entre la empresa IBM y la Universidad Carnegie Mellon. Este
Solver contiene 5 algoritmos diferentes:
• B-OA (Outer Approximation): aproximación periférica realizada a través de un
algoritmo de descomposición.
• B-BB: algoritmo Branch-and-Bound simple basado en resolver un programa no
lineal continuo en cada nodo del árbol de soluciones y ramificando las
variables.
• B-hyb: híbrido entre una aproximación periférica y programación no lineal
basado en el algoritmo Branch-and-cut.
• B-Ecp: algoritmo para realización cortes ECP (Plano de Corte Extendido)
tomando como base el procedimiento branch-and-cut.
• B-QG: aproximación periférica tomando como referencia el algoritmo branch-
and-cut.
Los algoritmos son exactos cuando el problema es convexo, en otro caso éstos
se consideran heurísticos.
2.2 SBB
Es un potente solver diseñado por la sociedad danesa ”ARKI Consulting and
Development” para GAMS, siendo empleado en la resolución de problemas de tipo
MINLP. Tal y como describe (GAMS Development Corporation) su código se construyó
a partir de la combinación entre una serie de solvers de programación no lineal (en
adelante NLP, por sus siglas en inglés) y la versión estándar del método Branch-and-
Bound empleado en programación lineal entera mixta (en adelante MILP, por sus siglas
en inglés).
Resolución por medio de GAMS
44
El modo de operación de dicho solver consiste en obtener una solución inicial a
partir de los datos del problema a resolver facilitados por el usuario en primera
instancia. Si dicha información da lugar a un escenario en el cual se produce alguna
infracción de límites preestablecidos en el modelo, origina un problema no abordable
o simplemente los datos no son coherentes, SBB se detiene de forma automática.
Una vez iniciada esta primera ejecución puede darse el caso de que todas las
variables discretas del modelo sean enteras, lo que normalmente llevará a que SBB
devuelva una solución como óptima entera. Si se da la circunstancia de que no todas
las variables discretas son enteras, SBB almacenará esta primera solución y a
continuación aplicará el método Branch and Bound.
Durante dicho proceso, la región factible para las variables discretas se divide y
los límites de dichas variables son ajustados a nuevos valores enteros que permitan
“podar” las soluciones actuales no enteras. Cada vez que se realiza un ajuste de este
tipo en los límites de las variables se resuelve un sub-modelo NLP que nace de la
solución óptima del sub-modelo anterior. Así pues, los valores de la función objetivo se
van haciendo más pequeños a medida que se solventan los sub-modelos (asumiendo
que se trata de un problema de minimización) y esto ocurre aún incluso en el caso de
que el solver NLP (parte de SBB encargado de resolver estos sub-modelos) encuentre
un óptimo local que pueda no ser el óptimo global. No obstante, puede ocurrir que
dicho solver NLP devuelva un estado de “solución local no factible” para un
determinado sub-modelo, lo que implica en la mayoría de los casos que realmente no
existe una solución viable para el sub-modelo en cuestión, incluso aunque la
inviabilidad se haya declarado como local.
Dependiendo de que el modelo sea o no convexo el solver puede comportarse
de maneras diferentes:
• En modelos convexos generalmente las condiciones se satisfacen y SBB aporta
soluciones óptimas con los límites de las variables convenientemente
ajustados.
• En modelos no convexos puede ocurrir que los límites de la función objetivo no
sean correctos puesto que existe la posibilidad de que soluciones más óptimas
se encuentren en partes no exploradas del árbol de soluciones.
2.3 Alpha ECP
Este solver está formulado a partir del conocido método de Plano de Corte
Extendido (en adelante ECP, por sus siglas en inglés) y es empleado en la resolución de
modelos de tipo MINLP, logrando obtener con gran fiabilidad soluciones óptimas para
problemas MINLP pseudoconvexos.
Resolución por medio de GAMS
45
Debe recordarse que el método ECP es una extensión del procedimiento del
Plano de Corte de Kelley, el cual fue desarrollado con el fin de solventar problemas de
clase NLP.
Para llevar a cabo su labor, y de acuerdo con lo descrito por (GAMS
Development Corporation) el solver de Kelley generaba y solucionaba un problema de
programación entera mixta (en adelante MIP, por sus siglas en inglés) con cada
iteración realizada. Estos problemas tipo MIP podían abordarse con el objetivo de
obtener una solución óptima o simplemente para obtener una solución entera “no
óptima” en iteraciones intermedias, aspecto que a posteriori permitiría a ECP
convertirse en un solver eficiente y de fácil incorporación en muchos modelos.
Evidentemente el solver actual Alpha ECP que se usa en GAMS ha sido objeto
de numerosas actualizaciones que han resultado en una mejora tanto en el modo de
operación del algoritmo como en su rendimiento. Uno de los avances más notables es
incluir algoritmos NLP que son capaces de hallar soluciones para problemas de tipo
MIP, lo que supone un incremento de la capacidad de Alpha ECP para encontrar
soluciones factibles y precisas, principalmente para problemas de tipo MINLP que
suelen contener mayormente variables continuas. Existe además la posibilidad de
emplear un método heurístico de reelección de planos de corte durante los procesos
iterativos que puede incrementar el potencial de resolución de problemas no
convexos.
3. Implantación del modelo en GAMS. Códigos de programación y
estructura de archivos.
En este sub-apartado se describirá detalladamente cómo se ha trasladado la
estructura y características del modelo de optimización descrito en el apartado
anterior (“El modelo propuesto”) al lenguaje de programación empleado en el IDE de
GAMS, de modo que con la introducción de los datos correspondientes a cada
escenario computacional sea posible resolver cada problema analizando el
comportamiento y rendimiento del modelo.
Debe aclararse que en el presente sub-apartado sólo se exponen las
herramientas empleadas para la referida implantación del modelo en el software, así
como la estructura de los archivos y los códigos definidos; por lo que el análisis de los
resultados de las pruebas, así como la decisión del solver empleado para cada una de
ellas y la descripción de los análisis de sensibilidad llevados a cabo son abordados en el
siguiente apartado: “Pruebas computacionales. Descripción de escenarios y
resolución”.
Resolución por medio de GAMS
46
3.1 Arquitectura de los códigos de programación empleados, relación
entre los distintos ficheros.
GAMS es un software muy polivalente que permite dividir la información con
los códigos de un modelo en diferentes archivos (ya sea por razones de funcionalidad,
tamaño u ordenación). En este caso se ha empleado una única estructura para los tres
casos computacionales compuesta por 4 archivos, cada uno con una información
distinta pero esencial para el buen desempeño del modelo:
• Archivo principal o lanzador.
• Archivo de datos del caso computacional, “sets” y parámetros.
• Archivo de definición de variables.
• Archivo de restricciones del modelo.
Como antes se ha señalado, cada uno de estos ficheros tiene un cometido
concreto que posibilita el objetivo global de ejecutar el modelo para el caso
computacional en cuestión y resolverlo de forma óptima permitiendo un análisis
completo del proceso y resultados.
Así pues, el archivo lanzador es aquel que se emplea como nexo de unión entre
todos los ficheros, desde él se ejecuta el solver y se produce “la llamada” a los otros
tres archivos de forma que se incorporan ordenadamente los códigos contenidos en
cada uno de ellos para que así el solver pueda leer e interpretar todos los comandos
necesarios (es necesario que cada experimento disponga de su propio fichero
lanzador). En dicho archivo se generan también ciertos parámetros y displays con el
objeto de un mejor análisis del proceso:
Fig. 3.1 Estructura de archivos GAMS para los experimentos realizados
Resolución por medio de GAMS
47
El archivo de datos del caso computacional contiene la información específica
del problema sobre el cual se va a aplicar el modelo de optimización. Incorpora y
define una serie de parámetros, tablas y conjuntos (sets) que permitirán disponer
todos los datos de modo que al modelo le sea posible interpretar toda la información
del experimento y trabajar con ella para determinar una solución adecuada. Es un
archivo único para cada experimento y para cada uno de los tres casos
computacionales ha resultado ser el fichero más pesado.
El tercero de los archivos anteriormente indicados es el que recoge y especifica
las variables empleadas en el modelo, cuya correcta definición y uso son
fundamentales para un correcto desempeño del algoritmo de optimización. En este
archivo se declaran todas las variables a utilizar, se especifica la tipología de cada una y
se fijan los límites de valores que pueden tomar (si procede). Ya que las variables a
utilizar vienen impuestas por el modelo, el archivo de variables que se emplea es el
mismo para cada uno de los tres experimentos.
El fichero de restricciones es probablemente el más complejo de elaborar pues
deben reflejarse en él todas las ecuaciones y condiciones del modelo de optimización
empleando un lenguaje de programación que esté en consonancia con los datos,
parámetros, variables y demás elementos que aparecen en los otros ficheros. Se
definen en este archivo tanto las restricciones como la función objetivo del modelo y al
tratarse de un fichero que se basa en las características del modelo de optimización es
el mismo para cada uno de los casos computacionales.
A continuación se ofrece una descripción detallada de los principales elementos
y características de cada uno de los archivos incluyendo el código usado en la
programación. Debe indicarse que dicha exposición no se realizará entrando en las
peculiaridades de cada experimento (los casos computacionales serán descritos en el
siguiente apartado), sino con el objeto de ilustrar las utilidades de GAMS empleadas y
la forma en la que se ha codificado todo lo necesario para que el modelo funcione
correctamente (arquitectura de los documentos, utilidad de los conjuntos y funciones,
razón de uso de los bucles, etc).
3.1.1 Archivo principal o lanzador
Como se ha indicado anteriormente este fichero es el que constituye el punto
de partida de todo el código puesto que es desde el que se ejecuta todo el código de
cada problema. Esto se consigue gracias al comando de llamada ($include) que se
utiliza para incorporar la codificación de los otros tres archivos involucrados en el
experimento. Previamente se ha definido un parámetro escalar que se usará para
medir el tiempo empleado por el software en resolver el problema.
Resolución por medio de GAMS
48
Fig. 3.2 Comandos de llamada en GAMS a ficheros de datos, variables y restricciones.
Posteriormente se especifican (de acuerdo a la información presente en
(McCarl, y otros, 2008)) una serie de opciones para controlar el funcionamiento del
solver mientras resuelve el problema
• RESLIM; límite de tiempo en segundos que el solver puede estar operando
consecutivamente para realizar un trabajo. Si ese tiempo es alcanzado, el solver
interrumpirá su actividad devolviendo el estado: “status 3, RESOURCE
INTERRUPT”.
• Limrow; opción que controla el número de casos que se escribirán en el archivo
.lst para cada ecuación definida en el modelo.
• ITERLIM; límite de iteraciones que puede realizar el solver para un determinado
trabajo. Si dicho límite es alcanzado, el solver interrumpirá la operación
devolviendo el estado: “status 2, ITERATION INTERRUPT”.
Tras esta definición de controles de operación del solver se ejecuta el comando
“solve” mediante el cual se le comunica al solver el tipo de problema que tiene que
resolver y el elemento que constituye el valor de la función objetivo que debe
optimizar (para el caso del modelo estudiado minimizando):
Fig. 3.3 Comando “solve” y definición del escalar runtime que recoge el tiempo
empleado por el solver en solucionar el problema. Fuente: GAMS 22.9.2
Resolución por medio de GAMS
49
Así pues, queda claro que la primera parte de este fichero lanzador se centra en
incorporar el resto de archivos, definir unas opciones de operación, calcular el tiempo
empleado en resolver el caso computacional e implantar el comando de resolución
(solve). Por otro lado, la segunda mitad del fichero está dedicada a tres cuestiones:
• Definición de parámetros encaminados a recoger los valores de las variables
que contabilizan los flujos de pasajeros y transbordos que tienen lugar en la
red.
• Declaración de parámetros para la medida de una serie de elementos;
� Costes correspondientes al personal de tripulación de los ferrocarriles
(CrewOperCost).
� Costes variables de operación (VarOperCost).
� Transbordos totales realizados desde una línea l (TotTransfromline (l)).
� Tiempo medio de viaje de los viajeros para cada par Origen-Destino,
correspondiente a la restricción número 8 del modelo de optimización
(AverWaiTime(ω)).
� Coste de adquisición de material rodante (RollBuyCost).
� Promedio entre el tiempo de viaje y la distancia recorrida para cada par
Origen-Destino (Prompartiempdis(ω)).
Fig. 3.4 Definición de parámetros de visualización de flujos y transbordos de
pasajeros en la red y de parámetros de costes y tiempos de viaje.
Fuente: GAMS 22.9.2
• Generación de “displays” de seguimiento, que como antes se adelantó son
funciones cuyo cometido es proporcionar una mejor visualización en el archivo
que se genera como output del proceso de los valores que toman aquellos
elementos del problema (variables, sets) que son de especial interés, como en
este caso son los flujos de pasajeros, transbordos, tiempo de cálculo,
parámetros de costes, tiempos de viaje, etc.
Resolución por medio de GAMS
50
3.1.2 Archivo de datos del caso computacional
Se trata del archivo que recopila todos los datos singulares de la red de
transporte por ferrocarril objeto de estudio (líneas, arcos, paradas, vías compartidas,
frecuencias posibles, etc).
La primera información que se implementa es la correspondiente al número de
nodos de la red (set i), así como número de arcos (set ij), vías disponibles en tramos
compartidos (set t), líneas (set Lines), pares Origen-Destino (set w), headways (set hd)
y tramos compartidos con posibles tracks o vías (set st).
Fig. 3.5 Implementación de datos de la red mediante la definición de “sets”.
Fuente: GAMS 22.9.2
No obstante, con esta introducción únicamente se ha especificado una ínfima
parte de la información necesaria. Para que la red quede bien definida aún deben
especificarse datos del recorrido de los trenes de cada línea, demanda existente,
orígenes y destinos para cada par, etc. Se trata pues, de incorporar una gran cantidad
de información de forma cómoda y legible para GAMS, lo cual puede hacerse gracias a
la definición de tablas. En este sentido, se han construido 7 tablas de datos en cada
uno de los archivos de datos para cada experimento:
Resolución por medio de GAMS
51
• Tabla de datos de demanda (table demanda (i,j)), en la cual se especifica la
demanda de personas que desea moverse desde un nodo i hasta un nodo j a
través de la red de ferrocarriles.
• Tabla de definición de los nodos que constituyen el origen y el destino de cada
par (table pair (i,j)), siendo el nodo i el origen y el nodo j destino de cada par.
• Tabla de datos de distancia entre cada par de nodos que constituyen un arco
(table distancia (i,j)). En esta tabla aquellas combinaciones de nodos que no
forman un arco se les asigna el valor cero, apareciendo valores no nulos sólo
para aquellos nodos que formen arcos.
Fig. 3.6 Tabla de datos de distancias entre nodos que forman arcos. Fuente: GAMS 22.9.2
• Tabla con información de los arcos por los que pasan los ferrocarriles de cada
línea en su correspondiente recorrido por la red (table linkrt (i,j,l)). En esta tabla
se representan en las filas todos los arcos de la red (formados por el nexo entre
los nodos i y j) y en las columnas las diferentes líneas representadas por la letra
l, de modo que cada elemento de la tabla toma el valor uno en el caso de que la
línea l recorra el arco i,j y por el contrario toma el valor cero si no es así.
• Tabla de referencia de paradas de los trenes de cada línea (table nodert (i,l)),
en la cual se reflejan los nodos en los que paran los trenes de cada línea. En las
filas de dicha tabla aparecen todos los nodos de la red mientras que en las
columnas se presentan las líneas. Si una determinada línea hace parada en una
estación (nodo), el valor del elemento de la tabla correspondientes es uno,
mientras que en caso contrario toma el valor cero.
Resolución por medio de GAMS
52
• Tabla de información con los k caminos más cortos para llegar desde el nodo
origen hasta el nodo destino de un determinado par (table arcopar (w,i,j)). Se
trata de una tabla auxiliar imprescindible para evitar que el tamaño del
problema se dispare. Por propia morfología de las redes a considerar, existe
una amplísima variedad de combinaciones posibles para ciertas variables y
ecuaciones implicadas en el modelo, pero lo cierto es que sólo un pequeño
porcentaje de todas estas combinaciones es utilizado, y dicha tabla permite
identificar a aquellas variables útiles e impedir la entrada del resto en la
ejecución del problema.
A modo de ejemplo, considérese la variable de cuantificación fijwl (i,j,w,l), que
representa el flujo de personas que circula por un arco entre los nodos i y j
mediante una línea l para un par Origen-Destino w. Para una red grande el
tamaño de esta variable puede alcanzar millones de elementos (a modo de
ejemplo, en una red de 20 nodos, 500 pares y 5 líneas la referida variable
tendría un millón de elementos) cuando en la realidad el modelo sólo necesita
emplear algunos miles de elementos de dicha variable.
Esta circunstancia se repite para muchas otras variables e incluso con muchas
de las ecuaciones definidas en el modelo, por lo que seleccionar y utilizar sólo
los elementos necesarios para ahorrar recursos informáticos y tiempo resulta
vital para hacer que redes de gran tamaño sean abordables por el modelo. A tal
efecto, se definen gracias a esta tabla auxiliar (y es ahí donde radica la
importancia de la misma) una serie de sub-sets (expuestos en la página 55 del
presente documento) que posteriormente se introducen en las ecuaciones del
modelo para permitir que éste sólo procese aquellos elementos que sean
imprescindibles, ahorrando millones de cálculos innecesarios.
En esta tabla las filas representan los pares y las columnas los arcos existentes
en la red. Aquellos elementos de la tabla correspondientes a los arcos i,j que se
contemplan en alguno de los caminos más cortos para la trayectoria a seguir
por un pasajero que se desplaza según un par Origen-Destino w toman el valor
uno, mientras que los arcos sin usar por estos caminos toman valor cero.
A diferencia de lo que ocurre con otras tablas, ésta ha sido generada mediante
programación informática basada en el algoritmo de Yen, de modo que se
generan los caminos más cortos deseados partiendo de los nodos existentes
(véase el apartado de “Pruebas computacionales. Descripción de escenarios y
resolución”).
Resolución por medio de GAMS
53
• Tabla de compatibilidad de frecuencias (o headways) entre dos líneas para
tramos de vías compartidos (table theta (hd,hdpr)), esencial para que el modelo
gestione la asignación de líneas a vías en los arcos con vías que son usados para
más de una línea simultáneamente así como el headway de dichas líneas
(incluso puede llegar a afectar de forma indirecta a los headways de aquellas
líneas que no están implicadas en tramos compartidos).
Las filas de la tabla constituyen los posibles valores de los headways o
frecuencias de la primera línea en análisis, mientras que las columnas
representan los valores de headways de la segunda línea a estudiar. Aquellos
elementos de la tabla con valor uno indican compatibilidad entre los valores de
headways (o frecuencias si se desea trabajar con la tabla complementaria) de
las líneas para usar una misma vía de un tramo compartido entre ambas,
mientras que los elementos con valor cero indican incompatibilidad (véase el
apartado de “Pruebas computacionales. Descripción de escenarios y
resolución”).
La utilidad de los datos de las tablas descritas se verá reflejada en los siguientes
párrafos en los que se abordan el resto de los conjuntos programados para la
experimentación. No obstante, aparte de los conjuntos hay ciertos parámetros de la
red cuya declaración (y en ciertos casos incluso cuya asignación de valor(es)) es
necesaria para el modelo, lo que también se ha llevado a cabo en el presente fichero.
Los parámetros principales a tener en cuenta son:
Tabla 3.1 Principales parámetros declarados en el archivo de datos del caso
computacional
Parámetro Nombre o declaración en GAMS
Velocidad media de los trenes Mean_speed
Posibles valores numéricos de los headways o frecuencias
hdvalue(hd)
Longitud de las líneas llenght(l)
Costes variables de operación de las locomotoras en función de la
capacidad y frecuencia para cada línea
ckm_loc
Costes variables de operación de los vagones en función de la capacidad y
frecuencia para cada línea
ckm_carr
Coste de adquisición de material rodante (locomotoras y vagones)
cost_loc y cost_carr
Volumen total de demanda a mover para cada par
g(w)
Horizonte de amortización de costes de compras de material rodante
Horizonte
Resolución por medio de GAMS
54
Tabla 3.1 (Continuación) Principales parámetros declarados en el archivo de datos
del caso computacional
Tiempo de espera en estación dwt
Tiempo de seguridad entre trenes sft
Capacidad de los vagones cap_vagon
Tiempo de ciclo de cada línea Tciclo(l)
Coeficientes de la Función Objetivo theta_one, theta_two y theta_four
Fig. 3.7 Declaración y asignación de parámetros del modelo. Fuente: GAMS 22.9.2
Conviene detenerse especialmente a analizar tanto el significado como la
asignación de valores que se realiza para volumen total de demanda a mover para
cada par g(w).
En la descripción realizada varias páginas atrás se puede observar que ya existe
una tabla de datos que recoge la demanda de pasajeros de la red. El caso es que dicha
demanda no está escalada y para que el modelo trabaje adecuadamente es necesario
escalar los datos de demanda y clasificarlos en función del par al que correspondan (el
resultado de esta operación es g(w)), para lo que es necesario asignar un número de
par w a cada pareja de nodos entre los cuales hay demanda de viajeros.
Esto se ha conseguido mediante la construcción de un bucle que primero
empareja cada elemento de la tabla pair (i,j) con un número de par w, etiquetando en
el proceso a los nodos origen y destino del par y posteriormente estableciendo el
volumen de pasajeros a mover para el par mediante la asignación a g(w) del resultado
del producto entre el elemento correspondiente de la tabla demanda (i,j), (ya
identificado por el bucle) y el factor de escala elegido (denominado como DemScala).
Resolución por medio de GAMS
55
Fig. 3.8 Asignación de valores de g(w). Fuente: GAMS 22.9.2
Como podrá verse a continuación, el fichero tiene una estructura encaminada
no solo a la disposición de la información de la red para que el modelo la procese sino
que también posibilita la generación de ciertos “Sub-sets” (llamados así por estar
construidos basándose en otros sets ya definidos) ya que se realiza una preparación en
la parte inicial y central de los elementos necesarios para construir en la parte final del
archivo estos subconjuntos que son esenciales para obtener una solución admisible en
un tiempo razonable. Su importancia radica en que permiten manejar las variables
justas necesarias para que el software no colapse por falta de memoria y a la vez
impide la generación de valores residuales indeseados en variables que no son
requeridas (tal y como se describe en la página 52 del presente documento). Dichos
subconjuntos se listan en la tabla siguiente:
Tabla 3.2 Sub-Sets con relevancia en la declaración y uso de variables
Sub-Set Significado
ls(i,j,l) En este subconjunto se guardan las líneas l que pasan por el
tramo compartido i,j
wijl(i,j,w,l) Subconjunto que almacena las combinaciones en las que el arco
i,j es recorrido por la línea l para un par w
willl(i,w,l,ll) Sub-set que recoge las posibles combinaciones de transbordos
desde una línea l a otra ll para un par w en un nodo i
wijlll(i,j,w,l,ll) Subconjunto que guarda las combinaciones en las que el arco i,j
es usado por las líneas l y ll para un par w
wnod(i,w) Sub-set que almacena los nodos que toman parte en al menos
uno de los caminos de más cortos para recorrer el par w
wnodlin(i,w,l)
Subconjunto para registrar los casos en los que una línea l para en una estación o nodo i que participa en uno de los caminos
más cortos para el recorrido del par w
wlin(w,l) Sub-set que guarda las líneas que operan en el par w
Resolución por medio de GAMS
56
Cada uno de estos subconjuntos se ha construido de forma individual atendiendo a
lo que representa cada uno:
• ls (i,j,l): se ha elaborado mediante un bucle en el que se busca el cumplimiento
de dos condiciones; en primer lugar se prueban todas las posibles
combinaciones de arcos a fin de encontrar aquellos que están involucrados en
tramos de vías compartidos (es decir, que estén contenidos en el set st(i,j,t)), y
para aquellos que cumplan este primer requisito se examina cuáles son las
líneas que los recorren mediante la comprobación de que el elemento
correspondiente en la tabla linkrt(i,j,l) es no nulo, de modo que el sub-set
existirá sólo para aquellas combinaciones que cumplan también este segundo
aspecto.
Fig. 3.9 Bucle de construcción del sub-set ls(i,j,l). Fuente: GAMS 22.9.2
• wijl (i,j,w,l): probablemente el sub-conjunto más empleado en las restricciones.
Queda definido sólo en aquellos casos en los que se cumple que tanto el
elemento correspondiente de la tabla linkrt (i,j,l) como el de la tabla arcopar
(w,i,j) valen uno.
• willl (i,w,l,ll): este sub-set sólo se define si se cumple que, para todos los nodos
j que preceden en un arco recorrido por una línea l al nodo i (esto es, si existe
un nodo j para el que se verifique que linkrt (j,i,l) es uno) se da que al menos
uno de esos arcos i,j está incluido en uno de los caminos más cortos del par w
considerado (la suma de todos los elementos de la tabla arcopar que combinan
los nodos j e i además del par w debe valer al menos uno). En los casos en los
que esto queda verificado y además se cumpla que otra línea ll pasa por el
nodo i (nodert (i,ll) valga uno) el sub-conjunto willl(i,wl,ll) queda definido.
Resolución por medio de GAMS
57
• wijlll (i,j,w,l,ll): subconjunto definido sólo en los casos en los que los
subconjuntos wijl(i,j,w,l) y wijl(i,j,w,ll) también lo están.
• wnod (i,w): sub-set construido mediante un parámetro auxiliar denominado
Tabla(i,w) que toma el valor uno sólo si se verifica que la suma entre los
elementos arcopar (w,i,j) y arcopar (w,j,i) es mayor que cero (previa condición
de que exista un nodo j que combinado con i forme un arco).
• wnodlin (i,w,l): este subconjunto se ha elaborado de forma parecida al
anterior, de modo que queda definido en los casos en los que su parámetro
auxiliar, Tabla2 (i,w,l), vale uno. A su vez Tabla2 (i,w,l) tiene valor uno si el
parámetro correspondiente Tabla (i,w) también presenta valor uno y además el
elemento pertinente de la tabla nodert (i,l) vale uno.
• wlin (w,l): al igual que los dos conjuntos anteriores, se ha construido por medio
de un parámetro auxiliar, llamado en este caso Tabla3 (w,l), de modo que wlin
(w,l) sólo existe para los valores de w y l para los que se cumple que Tabla3
(w,l) es igual a 1. Para que esto ocurra, w y l deben pertenecer al alguna
combinación para la que el sub-set wijl(i,j,w,l) quede definido, lo cual se
comprueba mediante la implementación de un bucle que recorra todos los
valores definidos de wijl(i,j,w,l).
Fig. 3.10 Definición de sub-conjuntos con relevancia para el uso de variables.
Fuente: GAMS 22.9.2
Resolución por medio de GAMS
58
Para comprobar la efectividad de la estrategia planteada de reducción del
tamaño del problema a partir del empleo de subconjuntos, se han definido una serie
de parámetros encaminados a cuantificar el ahorro que se logra para el caso de las
variables más representativas.
Fig. 3.11 Definición de parámetros para la cuantificación del ahorro en el uso de las
variables más representativas de la red. Fuente: GAMS 22.9.2
De este modo, se han definido tres grupos de parámetros, (como se puede ver
en la Fig. 3.11) cada una encargado de una función distinta:
• El grupo de parámetros size1, size2 y size3 cuantifican el tamaño de los
subconjuntos encargados de seleccionar las variables de utilidad para la
ejecución del modelo.
• Los parámetros tam1, tam2 y tam3 almacenan el tamaño original (sin
reducción) que tendrían las variables cuyo dominio coincide con los sets
incluidos en la definición del parámetro (ejemplo, tam1 indica el tamaño
original de la variable fijwl (i,j,w,l), entre otras).
• Los parámetros ahorro_var1, ahorro_var2, y ahorro_var3 determinan el
número de elementos cuya utilidad al modelo es nula y que son descartados
mediante la estrategia de ahorro planteada haciendo uso de los dos grupos de
parámetros anteriores (el número de elementos ahorrados es la diferencia
entre los parámetros tam y los parámetros size).
3.1.3 Archivo de definición de variables
En este fichero se definen todas las variables necesarias para que el modelo de
optimización pueda manejar y resolver el problema, realizando para algunas de ellas
un acotamiento manual de los valores máximo y mínimo que pueden llegar a tomar.
En la tabla siguiente se referencian todas las variables del fichero, indicando su tipo y si
están acotadas:
Resolución por medio de GAMS
59
Tabla 3.3 Variables del modelo de optimización
Variable Declaración
GAMS Tipo Acotamiento
Flujo de personas del par w que viajan por la línea l a
través del arco i,j fijwl(i,j,w,l) Positiva Valor mínimo: 0
Flujo de pasajeros del par w que usan la línea l
fwl(w,l) Positiva Valor mínimo: 0
Número de transbordos en el nodo i desde la línea l a la
línea ll para el par w trr(i,w,l,ll) Positiva Valor mínimo: 0
Frecuencia de la línea l frvar(l) Positiva Valor mínimo: 2
Valor máximo: 30
Headway de la línea l hdwvar(l) Positiva Valor mínimo: 2
Valor máximo: 20
Headway de la línea l en la vía t del segmento
compartido i,j hdwls(l,t,i,j) Positiva
Valor mínimo: 0 Valor máximo: 20
Demanda de pasajeros no atendida del par w
notatdem(w) Positiva Valor mínimo: 0
Demanda total de pasajeros no atendida para toda la
red de transporte Totaldemnotat Positiva Valor mínimo: 0
Función Objetivo TotFO Libre -
Variable de asignación del headway hd a la línea l
hdwfix(hd,l) Binaria -
Variable de asignación de la línea l a la vía t del
segmento compartido i,j delta (l,t,i,j) Binaria -
Variable de admisibilidad de flujos de viajeros del par w a través del arco i,j con la
línea l
y (i,j,w,l) Binaria -
Número de vagones no autopropulsados en los
trenes de la línea l nv(l) Entera
Valor mínimo: 0 Valor máximo: 8
*Véase el apartado “Modelo propuesto”, dónde se expone la significación de
los valores que pueden tomar las variables binarias.
3.1.4 Archivo de restricciones del modelo
Este fichero integra todas las restricciones del modelo de optimización,
incluyéndose también la función objetivo (en adelante FO). Con todas estas ecuaciones
descritas en él, se podría decir que este archivo es el lugar en el cual se escribe el
modelo en desarrollo objeto del presente proyecto y herramienta principal con la que
se abordan los casos computacionales en GAMS.
Resolución por medio de GAMS
60
El archivo contiene definidas un total de 18 conjuntos de restricciones que en
su mayoría representan las restricciones inherentes al modelo de optimización. Dos de
las mismas tienen por finalidad una conversión de variables y una constituye la FO. A
continuación se describirá la implantación de cada una de estas restricciones en GAMS
principalmente desde el punto de vista de la programación realizada (junto al nombre
de cada ecuación se señala la correspondencia con el número de restricción con el que
se le identifica en el apartado “El modelo propuesto”, el cual se recomienda consultar
para más información sobre las ecuaciones y su significado físico):
• Ecuación “no_dos_direcciones_par_link (i,j,w,l,ll)”- Restricción nº5
Sólo es aplicada para aquellas combinaciones de nodos, líneas y pares en las
que wijlll(i,j,w,l,ll) está definida. Además se contemplan sólo aquellas combinaciones
en las que el nodo i es anterior en orden al j (esto permite analizar sólo las
combinaciones implicadas en el proceso de flujo para el par w).
La ecuación fuerza a que, como máximo, sólo una de las variables binaria y sea no
nula, impidiéndose así que el arco i,j sea recorrido en ambos sentidos para flujos
correspondientes al mismo par Origen-Destino como se verá en la siguiente
restricción.
• Ecuación “bounding_flows (i,j,w,l)”- Restricción nº6
Aprovecha la asignación de valores realizada en la ecuación anterior sobre cada
variable binaria y (i,j,w,l) para acotar el valor de cada flujo fijwl(i,j,w,l); de modo que si
la binaria existe (su valor es igual a 1), el valor máximo del flujo es igual a g(w)
(demanda del par w), mientras que si se da el caso contrario el flujo tendrá que ser
necesariamente cero, ya que no se permite la circulación entre los nodos i y j para el
par origen y destino y línea considerados.
• Ecuación “Output_from_origin (w)”- Restricción nº1
Restricción de conservación de flujo, fuerza a que la suma de todos los flujos
fijwl(i,j,w,l) que salen del nodo origen i del par w hacia cualquier nodo j empleando
cualquier línea l sea igual a la demanda de ese par w menos la demanda no atendida,
notatdem(w). Sólo se suman aquellos flujos para los que se cumple que i es nodo
origen del par w (ord (i)=ORIG(w)) y que además certifican que el correspondiente
subconjunto wijl (i,j,w,l) existe.
Resolución por medio de GAMS
61
• Ecuación “Input_at-destination (w)”- Restricción nº2
Muy similar en morfología y cometido a la ecuación anterior, solo que en este
caso se suman los flujos fijwl (i,j,w,l) en los cuales j es el nodo destino del par w y dicha
suma debe ser igual a la demanda del par w menos la demanda no atendida,
notatdem(w). Las condiciones de que deben cumplir los flujos para participar en la
suma son las mismas que en la restricción anterior, con la salvedad de que j debe ser el
nodo destino de w (ord (j)=DEST (w)).
• Ecuación “Flows_balance (k,w)”- Restricción nº3
Al igual que las anteriores, es una restricción de flujo, sólo que es ligeramente
más compleja. La ecuación fuerza a que la suma de todos los flujos fijwl (j,k,w,l) que
entran en un nodo k desde cualquier estación j conectada mediante un arco j,k para
un par w usando cualquier línea l que circule para ese par y ese arco sea igual a la
suma de todos los flujos fijwl (k,u,w,l); siendo u cualquier nodo conectado a k
mediante un arco k,u para el mismo par w y usando cualquier línea l que circule para
ese par y ese arco k,u. Para que esta ecuación pueda aplicarse, el nodo k no puede ser
ni nodo origen ni destino del par w que se considere (ord (k) <> ORIG (w) and (ord (k)
<> DEST (w)) y debe estar contemplado en algún itinerario del par w (wnod (k,w) debe
existir).
Fig. 3.12 Restricciones 5, 6, 1, 2 y 3 implantadas como ecuaciones en GAMS.
Fuente: GAMS 22.9.2
Resolución por medio de GAMS
62
• Ecuación “Transfer_balance (k,w,l)”- Restricción nº4
Restricción de conservación de flujo orientada a los transbordos. Certifica que
la suma del número de pasajeros fijwl (j,k,w,l) que llega a un nodo k (desde cualquier
nodo j conectado a k) a través de una línea l para un par w más el número de pasajeros
trr (k,w,ll,l) que hacen transbordo desde cualquier línea ll hasta l debe ser igual al
número de pasajeros fijwl (k,j,w,l) que salen de un nodo k hacia cualquier nodo j
conectado a k a través de la línea l anteriormente referida para el mismo par w más el
número de pasajeros trr (k,w,l,ll) que hacen transbordo desde la línea l hasta cualquier
otra línea ll. La ecuación sólo se aplica si el nodo k no es origen ni destino del par w
(ord (k) <> ORIG (w) and (ord (k) <> DEST (w)), siendo necesario además que por dicho
nodo k pase más de una línea (nlin(k) > 1) y que el subconjunto wnodlin(k,w,l) exista.
Por otro lado, para que un flujo de pasajeros participe en la suma es necesario
que exista el correspondiente subset wijl; mientras que para que un flujo de pasajeros
de transbordo pueda entrar el sumatorio se requieren dos condiciones: primero que la
línea ll sea distinta de la línea l (ord (ll)<>ord(l)) y segundo que el subconjunto willl
respectivo exista.
• Ecuación “Agregacion_flujos_salida_por_linea (w,l)”- Restricción nº7
Como su propio nombre indica, esta ecuación tiene el cometido de agregar los
flujos de pasajeros fijwl(i,j,w,l) que proceden de un mismo nodo i (origen del par w) y
que circulan mediante la línea l, siendo el resultado de esta agregación el flujo fwl(w,l).
La única condición de aplicación para la ecuación es que wlin (w,l) exista mientras que
por otro lado para que fijwl (i,j,w,l) participe en la agregación debe cumplirse que el
nodo i sea origen del par w (ord (i)=ORIG (w)) y que el correspondiente subconjunto
wijl (i,j,w,l) esté definido.
Fig. 3.13 Restricciones 4 y 7 implantadas como ecuaciones en GAMS.
Fuente: GAMS 22.9.2
Resolución por medio de GAMS
63
• Ecuación “frequency”- Restricción nº10
Adjudica el valor de hdwvar (ln) (headway de la línea ln) en función del valor
asignado a la variable binaria hdwfix (hd,ln) (en la siguiente ecuación se explica dicha
asignación). hdwvar (ln) se obtiene de un sumatorio en el que cada sumando está
formado por el producto entre hdwfix (hd,ln) y hdvalue (hd).
• Ecuación “valores”- Restricción nº10
Restricción que fuerza mediante un sumatorio a que sólo exista una variable
binaria hdwfix (hd,ln) no nula por línea, lo que a su vez propiciará que sólo uno de los
sumandos de la ecuación anterior sea distinto de cero y por tanto el que definirá el
valor que tomará hdwvar (ln).
• Ecuación “line_allocation (i,j,l)”- Restricción nº11
Ecuación para la gestión de tramos compartidos entre líneas, la única condición
impuesta para su aplicación es que el subconjunto ls (i,j,l) exista. En esta restricción se
impone que, para un tramo de vías entre los nodos i y j de uso compartido por varias
líneas, cada línea l sea asignada a una sola vía t de ese arco, lo cual se consigue
mediante un sumatorio por el que sólo una de las variables binarias delta(l,t,i,j) (para
unos nodos i y j y una línea l dados) puede ser no nula. Para que una variable binaria
delta en cuestión pueda incluirse en el sumatorio es necesario que el conjunto st (i,j,t)
exista.
• Ecuación “frequency_for_track (i,j,l)”- Restricción nº12
Emplea un sumatorio que divide el valor total de hdwvar (l) (headway de la
línea l) entre varios valores de headway hdwls (l,t,i,j); uno para cada vía t del tramo
compartido entre i y j a la que puede asignarse la circulación de la línea l. Como
condición para que la ecuación pueda aplicarse se tiene que el subconjunto ls (i,j,l) ha
de existir; siendo necesario además que para que hdwls (l,t,i,j) participe en el
sumatorio el conjunto st (i,j,t) esté definido.
Resolución por medio de GAMS
64
Fig. 3.14 Restricciones 10,11 y 12 implantadas como ecuaciones en GAMS.
Fuente: GAMS 22.9.2
• Ecuación “constr_frequency(i,j,l,t)“- Restricción nº13
Restricción para la gestión de la frecuencia o headways de los ferrocarriles en
tramos de vías compartidos por varias líneas que permite acotar el valor de las
variables hdwls (l,t,i,j) declaradas. Esto se realiza limitando superiormente dichas
variables con el resultado del producto entre el parámetro Vmax y la variable binaria
delta (l,t,i,j) correspondiente. Ya que sólo una de las variables delta de todas las
definidas para el tránsito de la línea l a través del arco i,j valdrá uno (la
correspondiente a la vía “t” a la que finalmente se asignará la línea), todos las variables
hdwls (l,t,i,j) se anularan salvo aquella que corresponda a la vía t que la línea l
recorrerá para el arco i,j y que como máximo podrá tener valor igual a Vmax,
coincidiendo éste con el valor de hdwvar (l). El requisito para la aplicación de esta
ecuación es que tanto ls (i,j,l) como st(i,j,t) deben estar definidos.
• Ecuación “safetyhdw_dwell_time(i,j,t)“- Restricción nº14
Al igual que la anterior, esta ecuación tiene la misión de acotar el valor de las
variables hdwls (l,t,i,j), en este caso para garantizar un margen mínimo de tiempo
entre trenes que circulan por la misma vía de un tramo compartido entre líneas. Dicha
cota de valor es establecida mediante una condición que obliga a que el sumatorio de
todas las variables hdwls (l,t,i,j) correspondientes a los trenes de las distintas líneas l
que pasan por una misma vía t del tramo compartido entre los nodos i y j,
multiplicadas cada una de ellas por la suma de los valores de los parámetros sft y dwt
sea inferior o igual a 60. Esta ecuación se aplica para los casos en los que st (i,j,t) está
definido, mientras que para que una variable hdwls (l,t,i,j) pueda participar en el
sumatorio debe certificarse que el conjunto ls (i,j,l) está asimismo definido para esos
valores de l, t, i y j.
Resolución por medio de GAMS
65
• Ecuación “frequencies_compatibility(i,j,t,l,ll,hd,hdpr)“- Restricción nº15
Sin duda se trata de la ecuación más compleja de todas las implicadas en la
gestión de tramos de vías compartidos por varias líneas, tiene el objeto de definir la
compatibilidad entre las frecuencias de los trenes de distintas líneas que operan un
mismo tramo de vías.
Sólo se ejecuta para aquellas combinaciones de valores de i, j, l, ll y t para los
que los subconjuntos ls (i,j,l), ls (i,j,ll) y st (i,j,t) están definidos, siendo necesario
además que la línea l sea de orden inferior a la línea ll para evitar duplicidades de
cálculo (ord (l) < ord (ll)). La ecuación impone la condición de que la suma de las
variables delta (l,t,i,j) y delta (ll,t,i,j) (término izquierdo) tiene que ser menor o igual a
la suma de 3 más el parámetro theta (hd,hdpr) menos el resultado de la suma de
hdwfix (hd,l) y hdwfix (hdpr,ll) (término izquierdo). Nótese que para que todas las
variables delta y hdwfix valgan uno (caso en el que se produce la asignación de las
líneas l y ll a la vía t con las respectivos headways hd y hdpr) necesariamente
theta(hd, hdpr) debe valer uno.
• Ecuación “frequency_and_cap(i,j,l)“- Restricción nº16
Esta ecuación establece una relación lógica entre los factores de frecuencia y
capacidad de los trenes, y lo consigue mediante el uso de un sumatorio. Cada sumando
de éste está conformado por un producto entre el flujo de pasajeros fijwl (i,j,w,l) y el
headway de la línea l hdwvar (l).
Entre cada sumando varía únicamente el par w considerado, por lo que el arco
i,j por el que se mueve el flujo de viajeros y la línea l permanecen constantes. El
resultado de este sumando debe ser inferior o igual al producto de 60 por la capacidad
de un vagón (cap_vagon) por el número de vagones de un tren de la línea l (2+nv(l)), lo
que certifica que no se mueven más pasajeros de los que la línea puede transportar.
Para que la ecuación se ejecute valores de i, j y l deben ser tales que permitan que el
subconjunto ijl (i,j,l) esté definido. Por otro lado, sólo existirán sumandos para valores
de i, j, l y w que certifiquen que el sub-set wijl(i,j,w,l) existe.
Resolución por medio de GAMS
66
Fig. 3.15 Restricciones 13, 14, 15 y 16 implantadas como ecuaciones en GAMS.
Fuente: GAMS 22.9.2
• Ecuaciones “Frequency_and_head1 (l)” y “Frequency_and_head2 (l)”-
Restricción nº9
Como puede apreciarse en apartados y descripciones anteriores, en la
implantación del modelo realizada en GAMS se ha trabajado principalmente con
headways en lugar de con frecuencias, aunque es conveniente tener datos también de
este último factor ya que facilitará operaciones posteriores al evitar cálculos no
lineales que habrían de abordarse si sólo se dispusieran de datos de headways.
Es por ello que se definen estas dos ecuaciones con la finalidad de, a partir de
los valores de las distintas variables hdwvar (l), calcular las correspondientes variables
de frecuencia, frvar(l). Esto se consigue estableciendo unos límites inferior y superior
que se aproxime a la relación real existente entre ambos factores (frecuencia *
headway = 60) (obviamente los datos de frecuencia así obtenidos no serán exactos
pero sí bastante cercanos).
Fig. 3.16 Restricción 9 implantada como ecuación en GAMS. Fuente: GAMS 22.9.2
Resolución por medio de GAMS
67
• Función Objetivo o ecuación “obj”
Esta ecuación contiene todos los términos de la función objetivo del modelo
cuyo valor final se pretende minimizar. Puede dividirse en 5 partes atendiendo el coste
de operación de la red que se pretende cuantificar más un componente de
penalización:
� Costes asociados al tiempo de viaje de los pasajeros: es el producto del
parámetro theta_one (valor monetario del tiempo de viaje) por el propio
tiempo de viaje total de toda la demanda de la red, que se calcula con una
compleja expresión que maneja varios sumatorios.
El primer sumatorio abarca toda la ecuación e integra los tiempos de viaje
para cada par w. Existe un segundo sumatorio (que contiene el resto de la
expresión) y cuyos sumandos se diferencian únicamente en la línea l
considerada. Dentro de este sumatorio hay tres componentes:
- Un sumatorio que, para cada sumando considera un arco i,j diferente
integrando en cada uno el producto de la distancia del arco (dis(i,j))
multiplicado por 60 y por el flujo fijwl (i,j,w,l), estando todo dividido
por el parámetro Mean_speed.
- Un producto formado por la multiplicación del flujo fwl (w,l) con la
variable hdwvar (l), todo ello partido por 2.
- Dos sumatorios, uno contenido dentro de otro. En el interior de ambos
se establece un producto que consiste en la multiplicación de la
variable trr (i,w,l,ll) por la variable hdwvar (ll)(todo ello dividido entre
2). Los sumatorios sirven para adicionar las variables en función de la
línea ll (distinta de l) considerada (sumatorio interior) y del nodo i
contemplado (sumatorio exterior).
Las condiciones de aplicación de los sumatorios son numerosas e
implican la definición de ciertos subconjuntos para los valores de
líneas, pares y nodos implicados; estando orientadas a que se originen
sólo los sumandos precisos.
� Costes motivados por el número de transbordos realizados en la red: es el
producto del parámetro theta_two (valor monetario de los transbordos)
por el número total de transbordos realizados. Este número de se
determina mediante el sumatorio de todas las variables trr (i,w,l,ll). Para
que sólo se contemplen los sumandos necesarios, se exige que las líneas l
y ll sean distintas ((ord(l) <> ord (ll)) y que una serie de subconjuntos estén
definidos: wlin (w,l), wlin (w,ll) y willl (i,w,l,ll).
Resolución por medio de GAMS
68
� Costes de operación de los trenes (en función de la distancia recorrida): se
calcula con un sumatorio en el que cada sumando varía por la línea “l” de
ferrocarril contemplada y está constituido por el producto de los costes de
operación de la locomotora más el de los vagones que componen el tren
de la línea (ckm_loc + ckm_carr*(nv(l)+1), nótese que en plena circulación
sólo una de las dos locomotoras funciona como tal, actuando la otra como
un vagón corriente) por la frecuencia de la línea (frvar(l)) y por la longitud
de la línea (llenght (l)), todo ello a su vez multiplicado por 2 (para
considerar ambos sentidos de circulación).
� Coste de operación de los trenes (desde el punto de vista de la
tripulación): es el resultado de multiplicar el parámetro theta_four (valor
monetario del tiempo de operación de la tripulación a bordo de un tren)
por el número de ferrocarriles en circulación, que se determina con un
sumatorio en el que cada sumando representa el número de trenes de
cada línea, que es cuantificado mediante el producto de la frecuencia de la
línea (frvar(l)) por su longitud (llenght (l)) y por 2 (para considerar ambos
sentidos de circulación) dividido todo ello por la velocidad media de los
trenes (Mean_speed).
� Coste de compra de material rodante: este miembro se cuantifica en base
a un horizonte de amortización (1E6/Horizonte*365*24), y es el resultado
de multiplicar dicho factor de amortización por el número de trenes que
componen la flota y por el coste que tienen dichos trenes. El número de
trenes se cuantifica de forma idéntica a como se realizó en el anterior
componente de la FO (mediante un sumatorio), aunque en este caso se
añade un término multiplicando que representa el coste de compra de las
dos locomotoras y el número de trenes no autopropulsados que
componen cada tren (2*cost_loc + nv (l)*cost_carr).
Fig. 3.17 Implantación de la Función Objetivo como ecuación en GAMS.
Fuente: GAMS 22.9.2
Resolución por medio de GAMS
69
� Además de los 5 miembros anteriormente descritos, se ha implantado
en la FO una penalización por la demanda que el modelo no consigue
atender, de modo que cada pasajero que se queda sin poder
desplazarse por la red supone un coste adicional para la misma de 5
millones de Euros (5*1E6*notatdem(w), en el siguiente apartado
“Pruebas computacionales. Descripción de los escenarios y resolución”
se expone la razón de asignar dicho valor a esta penalización).
Finalmente, debe indicarse que se ha escalado el resultado final de la
FO (como puede verse en la Fig. 3.17 de presente apartado) dividiendo
la misma entre 10.000 para evitar que GAMS maneje valores
excesivamente elevados.
70
Pruebas computacionales. Descripción de escenarios y resolución.
Para llevar a cabo el análisis del comportamiento y capacidad de resolución de
problemas del modelo expuesto en el presente proyecto se llevaron a cabo una serie
de pruebas computacionales. Dichos experimentos consistieron en la resolución de
tres casos prácticos de complejidad diferente:
• Prueba computacional A: caso de red de tránsito rápido por ferrocarril de 8
nodos y 10 pares Origen-Destino.
• Prueba computacional B: caso de red de tránsito rápido por ferrocarril de 12
nodos y 56 pares Origen-Destino.
• Prueba computacional C: caso de red de tránsito rápido por ferrocarril de 36
nodos y 800 pares Origen-Destino.
Evidentemente el caso de estudio A es el más simple y por tanto aquel para el
que se encuentra con mayor facilidad y brevedad una solución óptima. El caso B
presenta un mayor nivel de dificultad aunque apenas constituye una red de tamaño
intermedio y finalmente el caso C es el de mayor complejidad, implementando un
problema de dimensiones considerables, habiéndose necesitado para el mismo
mayores cantidades de recursos y tiempo en la obtención de una solución óptima.
En el punto siguiente se realiza una descripción detallada de los escenarios
correspondientes a cada caso experimental.
1. Descripción de escenarios
1.1 Prueba computacional A: red de tránsito rápido por ferrocarril de 8
nodos y 10 pares Origen-Destino
Como anteriormente se ha mencionado, éste es el caso más sencillo a resolver
de los que en este proyecto se acometen. Se trata de una red de tránsito rápido de
pequeño tamaño, compuesta por los siguientes elementos:
• 8 nodos o estaciones.
• 3 líneas de ferrocarril.
• 14 arcos que equivalen a 7 tramos de vías que pueden ser recorridas por
los trenes en ambos sentidos y que hacen de enlace entre los nodos:
1.3, 3.1, 2.3, 3.2, 3.5, 5.3, 5.4, 4.5, 5.7, 7.5, 7.8, 8.7, 6.8 y 8.6
Pruebas computacionales. Descripción de escenarios y resolución.
71
• 10 pares origen destino que vienen dados según la siguiente tabla (se
incluyen en la misma la demanda estimada de pasajeros para cada par
Origen-Destino):
Tabla 1.1 Nodos Origen y Destino correspondientes a cada par OD.
Escenario computacional de 8 nodos y 10 pares OD.
Par OD Nodo Origen Nodo Destino Demanda/Nº Pasajeros
1 1 6 1800
2 1 8 2400
3 2 4 1800
4 2 6 900
5 4 2 1350
6 4 6 1500
7 6 1 900
8 6 2 1500
9 6 4 2400
10 8 1 1800
• 6 arcos que ofrecen la posibilidad de ser utilizados de forma común por
varias líneas de modo simultáneo:
� Arcos 3.5 y 5.3 de una sola vía, que pueden ser recorridos a la
vez por las líneas 1 y 2.
� Arcos 4.5 y 5.4 de una sola vía, que pueden ser utilizados de
forma común por las líneas 2 y 3.
� Arcos 5.7 y 7.5 de una sola vía, que pueden ser transitados por
las líneas 1 y 3 de modo simultáneo.
• Los trenes de cada una de las líneas cubren una ruta concreta de doble
sentido, las cuales se describen a continuación para cada línea:
� Línea 1:
� Sentido A: 1.3, 3.5, 5.7
� Sentido B: 7.5, 5.3, 3.1
� Línea 2:
� Sentido A: 2.3, 3.5, 5.4
� Sentido B: 4.5, 5.3, 3.2
� Línea 3:
� Sentido A: 4.5, 5.7, 7.8, 8.6
� Sentido B: 6.8, 8.7, 7.5, 5.4
Pruebas computacionales. Descripción de escenarios y resolución.
72
• Las distancias existentes entre los nodos que están enlazados por un
arco (o longitud de arco) vienen expresadas en la tabla siguiente:
Tabla 1.2 Longitudes de arco. Escenario computacional de 8 nodos y 10 pares OD*.
Arco (nodo A.nodo B) Distancia/km
1.3 5
2.3 6
3.5 6
4.5 4
5.7 5
7.8 6
6.8 5
*(Nótese que sólo se han señalado los arcos en uno de los sentidos, lo que se debe a
que cada uno de los arcos equivalentes de sentido contrario tienen la misma longitud)
La red de tránsito rápido que constituye esta prueba computacional es
totalmente ficticia y ha sido diseñada expresamente para servir como experimento de
modo que permita analizar el comportamiento del modelo y evaluar su utilidad en lo
que se refiere a la optimización de la planificación operativa para una red de tránsito
rápido por ferrocarril simple.
El siguiente gráfico se incluye con el objeto de dar una idea general de la forma
de la red de modo ilustrativo, referenciándose en el mismo las características
principales de ésta:
Fig. 1.1 Red de tránsito rápido por ferrocarril de 8 nodos y 10 pares
Pruebas computacionales. Descripción de escenarios y resolución.
73
1.2 Prueba computacional B: red de tránsito rápido por ferrocarril de 12
nodos y 56 pares Origen-Destino
Este segundo experimento constituye una versión ampliada de la anterior y por
tanto de mayor dificultad, siendo un sistema más grande y presentando una mayor
cantidad de todos los elementos inherentes a una red de tránsito rápido (nodos, arcos,
líneas, pares, etc).
No obstante, no puede considerarse como una red de tamaño grande
objetivamente hablando, aunque en lo que se refiere al presente proyecto, se puede
considerar que su dificultad es intermedia respecto de los otros dos experimentos,
teniendo siempre presente que el tercer caso experimental presenta una red más
realista y compleja. Las características de esta segunda red de tránsito rápido sobre la
cual se ha aplicado el modelo se exponen a continuación:
• 12 nodos o estaciones.
• 5 líneas de ferrocarril.
• 26 arcos que equivalen a 13 tramos de vías que pueden ser recorridas
por los trenes en ambos sentidos y que hacen de enlace entre los
nodos: 1.3, 3.1, 2.3, 3.2, 3.5, 5.3, 5.4, 4.5, 5.7, 7.5, 7.8, 8.7, 6.8, 8.6, 1.9,
9.1, 9.10, 10.9, 10.4, 4.10, 2.11, 11.2, 11.12, 12.11, 12.8 y 8.12
• 56 pares origen destino que vienen dados según la siguiente tabla (se
incluyen en la misma la demanda estimada de pasajeros para cada par
Origen-Destino):
Tabla 1.3 Nodos Origen y Destino correspondientes a cada par OD.
Escenario computacional de 12 nodos y 56 pares OD.
Par OD Nodo Origen Nodo Destino Demanda/Nº Pasajeros
1 1 2 600
2 1 3 1500
3 1 4 900
4 1 5 1800
5 1 6 300
6 1 7 1500
7 1 8 600
8 2 1 300
9 2 3 1200
10 2 4 1800
11 2 5 900
12 2 6 300
Pruebas computacionales. Descripción de escenarios y resolución.
74
Tabla 1.3 (continuación) Nodos Origen y Destino correspondientes a cada
par OD. Escenario computacional de 12 nodos y 56 pares OD.
13 2 7 1200
14 2 8 300
15 3 1 1200
16 3 2 900
17 3 4 600
18 3 5 1500
19 3 6 300
20 3 7 1500
21 3 8 600
22 4 1 900
23 4 2 1500
24 4 3 900
25 4 5 600
26 4 6 900
27 4 7 1200
28 4 8 300
29 5 1 1500
30 5 2 1200
31 5 3 1500
32 5 4 1200
33 5 6 300
34 5 7 1200
35 5 8 600
36 6 1 300
37 6 2 300
38 6 3 600
39 6 4 300
40 6 5 900
41 6 7 1800
42 6 8 1500
43 7 1 1200
44 7 2 300
45 7 3 1500
46 7 4 600
47 7 5 1800
48 7 6 1500
49 7 8 1200
50 8 1 300
51 8 2 600
52 8 3 1200
53 8 4 900
Pruebas computacionales. Descripción de escenarios y resolución.
75
Tabla 1.3 (continuación) Nodos Origen y Destino correspondientes a cada
par OD. Escenario computacional de 12 nodos y 56 pares OD.
54 8 5 1500
55 8 6 1500
56 8 7 1200
• 2 arcos que ofrecen la posibilidad de ser utilizados de forma común por
dos líneas de modo simultáneo:
� Arcos 3.5 y 5.3 de una sola vía, que pueden ser recorridos a la
vez por las líneas 1 y 2.
• Los trenes de cada una de las líneas cubren una ruta de doble sentido,
siendo los itinerarios concretos los que se describen a continuación para
cada línea:
� Línea 1:
� Sentido A: 1.3, 3.5, 5.7
� Sentido B: 7.5, 5.3, 3.1
� Línea 2:
� Sentido A: 2.3, 3.5, 5.4
� Sentido B: 4.5, 5.3, 3.2
� Línea 3:
� Sentido A: 7.8, 8.6
� Sentido B: 6.8, 8.7
� Línea 4:
� Sentido A: 1.9, 9.10, 10.4
� Sentido B: 4.10, 10.9, 9.1
� Línea 5:
� Sentido A: 2.11, 11.12, 12.8
� Sentido B: 8.12, 12.11, 11.2
• Las distancias existentes entre los nodos que están enlazados por un arco (o
longitud de arco) vienen expresadas en la tabla siguiente:
Pruebas computacionales. Descripción de escenarios y resolución.
76
Tabla 1.4 Longitudes de arco. Escenario computacional de 12 nodos y 56 pares OD*.
Arco (nodo A.nodo B) Distancia/km
1.3 5
2.3 6
3.5 6
4.5 4
5.7 5
7.8 6
6.8 5
1.9 4
9.10 4
10.4 4
2.11 4
11.12 6
12.8 4
*(Nótese que sólo se han señalado los arcos en uno de los sentidos, lo que se debe a
que cada uno de los arcos equivalentes de sentido contrario tienen la misma longitud)
Al igual que en el experimento computacional anterior, esta red de tránsito
rápido por ferrocarril es totalmente ficticia y se ha elaborado con el objetivo de
analizar el comportamiento del modelo y evaluar su utilidad en lo que se refiere a la
optimización de la planificación operativa para una red de tránsito rápido por
ferrocarril de tamaño moderado.
De hecho, tal y como se ha comentado anteriormente, esta red de tránsito
rápido es una variación de la anterior que, como se desprende de los datos aportados,
implementa un mayor grado de complejidad en todos los aspectos (es una red
globalmente más extensa) salvo en el de la gestión de tramos compartidos, ya que los
arcos de este tipo se ven reducidos de seis a dos.
La siguiente ilustración tiene la finalidad de proporcionar una idea general de la
forma de la red para este segundo caso computacional, referenciándose en el mismo
las características principales de ésta:
Pruebas computacionales. Descripción de escenarios y resolución.
77
Fig. 1.2 Red de tránsito rápido por ferrocarril de 12 nodos y 56 pares
1.3 Prueba computacional C: red de tránsito rápido por ferrocarril de 36
nodos y 800 pares Origen-Destino
El tercero de los escenarios computacionales constituye sin duda el
experimento más complejo, en el cual el modelo propuesto se enfrenta a un caso
bastante realista, lo cual permitirá sacar conclusiones más precisas acerca de la
utilidad práctica del mismo.
Para elaborar esta tercera prueba computacional se ha tomado como base la
red de cercanías existente en la ciudad de Madrid, la cual ha sido analizada obteniendo
de la misma prácticamente la totalidad de los datos que a posteriori se usan en la
prueba. Dicha red de cercanías representa un muy buen caso de estudio debido a su
tamaño, su gran número de trenes y pasajeros potenciales, su variedad de caminos y
su complejidad de funcionamiento, siendo una de las más grandes e importantes de
España. Para un mayor conocimiento de la red que ha posibilitado la realización del
caso práctico descrito en el presente apartado, a continuación se ofrecen una breve
serie de datos acerca de la red de cercanías de Madrid:
Pruebas computacionales. Descripción de escenarios y resolución.
78
• Tiene una longitud de aproximadamente 370 km si se tienen en cuenta
todas sus vías férreas.
• La plantilla de empleados que se encarga de su operación es de 1300
personas.
• Posee un total 89 estaciones, varias de ellas con conexión con el metro
de Madrid y una con el tranvía de Parla.
• Operan un total de 9 líneas distintas de ferrocarril.
• En días laborables circulan cerca de 1390 trenes, lo que supone una
capacidad de desplazamiento de aproximadamente 900000 personas al
día.
A la vista de los datos referenciados, se puede comprobar que se trata de una
red de magnitud importante, y si bien se ha intentado representar dicha red en el
experimento computacional de la forma más fiel posible a la realidad en algunos
aspectos se han realizado simplificaciones que más adelante serán comentadas.
Las características de este tercer escenario computacional sobre el cual se
aplica el modelo propuesto y que refleja una red de tránsito rápido por ferrocarril
similar a la red de cercanías de Madrid son expuestas a continuación:
• 36 nodos o estaciones.
• 7 líneas de ferrocarril.
• 76 arcos que equivalen a 38 tramos de vías que pueden ser recorridas
por los trenes en ambos sentidos y que hacen de enlace entre los
nodos: 1.2, 2.1, 1.19, 19.1, 1.30, 30.1, 1.35, 35.1, 2.3, 3.2, 2.4, 4.2, 3.5,
5.3, 4.5, 5.4, 5.6, 6.5, 5.21, 21.5, 6.7, 7.6, 7.8, 8.7, 8.9, 9.8, 9.10, 10.9,
10.30, 30.10, 11.12, 12.11, 12.13, 13.12, 13.14, 14.13, 14.5, 5.14, 15.5,
5.15, 15.16, 16.15, 16.17, 17.16, 16.36, 36.16, 16.29, 29.16, 17.18,
18.17, 19.20, 20.19, 21.22, 22.21, 22.23, 23.22, 23.24, 24.23, 24.25,
25.24, 25.26, 26.25, 27.28, 28.27, 28.29, 29.28, 29.5, 5.29, 30.31, 31.30,
31.32, 32.31, 32.33, 33.32, 34.35 y 35.34
• 800 pares Origen-Destino. Al considerar si se incluye en esta descripción
la extensísima relación de pares existentes se opta por omitir la tabla
detallada de los mismos con su demanda asociada a fin obtener una
mayor simplicidad y legibilidad en este apartado.
Pruebas computacionales. Descripción de escenarios y resolución.
79
No obstante, si se desea consultar los datos empleados a este efecto en
el presente caso computacional, en la documentación anexa con los
códigos de programación implementados en GAMS se recoge el archivo
“Ejemplo REDUC Madrid Model 2 800W”, en el cual aparecen las tablas
pair (i,j) y demanda (i,j), detallándose en la primera los nodos inicio y
final de cada par Origen-Destino y en la segunda la demanda de
pasajeros para cada par, debiendo multiplicar los datos de dicha tabla
por el factor DemScala para obtener la cantidad exacta de pasajeros en
cada caso.
• 24 arcos que ofrecen la posibilidad de ser utilizados de forma común
por varias líneas de modo simultáneo:
� Arcos 1.30 y 30.1 de una sola vía, que pueden ser recorridos a la
vez por las líneas 3 y 6.
� Arcos 30.31, 31.30, 31.32 y 32.31 de dos vías, en los que pueden
circular de forma simultánea las líneas 3,6 y 7.
� Arcos 6.7, 7.6, 5.6, 6.5, 1.19 y 19.1 de una sola vía, susceptibles
de ser transitados de forma común por las líneas 1 y 7.
� Arcos 1.2 y 2.1 de tres vías, disponibles para ser usados de forma
conjunta por las líneas 1, 2, 3, 4 y 7.
� Arcos 2.3, 3.2, 3.5 y 5.3 de dos vías, que pueden ser recorridos
de manera simultánea por las líneas 1,2 y 7.
� Arcos 2.4, 4.2, 4.5, 5.4, 5.29 y 29.5 de una sola vía, en los que
pueden circular de forma simultánea los trenes de las líneas 3 y
4.
• Los trenes de cada una de las líneas cubren una ruta concreta de doble
sentido, dichas rutas vienen descritas a continuación para cada línea:
� Línea 1:
� Sentido A: 20.19, 19.1, 1.2, 2.3, 3.5, 5.6, 6.7
� Sentido B: 7.6, 6.5, 5.3, 3.2, 2.1, 1.19, 19.20
� Línea 2:
� Sentido A: 1.2, 2.3, 3.5, 5.21, 21.22, 22.23, 23.24, 24.25,
25.26
� Sentido B: 26.25, 25.24, 24.23, 23.22, 22.21, 21.5, 5.3,
3.2, 2.1
Pruebas computacionales. Descripción de escenarios y resolución.
80
� Línea 3:
� Sentido A: 33.32, 32.31, 31.30, 30.1, 1.2, 2.4, 4.5, 5.29,
29.28, 28.27
� Sentido B: 27.28, 28.29, 29.5, 5.4, 4.2, 2.1, 1.30, 30.31,
31.32, 32.33
� Línea 4:
� Sentido A: 34.35, 35.1, 1.2, 2.4, 4.5, 5.29, 29.16, 16.36
� Sentido B: 36.16, 16.29, 29.5, 5.4, 4.2, 2.1, 1.35, 35.34
� Línea 5:
� Sentido A: 11.12, 12.13, 13.14, 14.5, 5.15, 15.16, 16.17,
17.18
� Sentido B: 18.17, 17.16, 16.15, 15.5, 5.14, 14.13, 13.12,
12.11
� Línea 6:
� Sentido A: 32.31, 31.30, 30.1
� Sentido B: 1.30, 30.31, 31.32
� Línea 7:
� Sentido A: 19.1, 1.2, 2.3, 3.5, 5.6, 6.7, 7.8, 8.9, 9.10,
10.30, 30.31, 31.32
� Sentido B: 32.31, 31.30, 30.10, 10.9, 9.8, 8.7, 7.6, 6.5, 5.3,
3.2, 2.1, 1.19
• Las distancias existentes entre los nodos que están enlazados por un arco (o
longitud de arco) vienen expresadas en la tabla siguiente:
Tabla 1.5 Longitudes de arco. Escenario computacional de 36 nodos y 800 pares OD*.
Arco (nodo A.nodo B) Distancia/km
1.2 5
1.19 5
1.30 30
1.35 5
2.3 4
2.4 5
3.5 4
4.5 4
5.6 3
5.21 7
6.7 7
Pruebas computacionales. Descripción de escenarios y resolución.
81
Tabla 1.5 (Continuación) Longitudes de arco. Escenario computacional de 36 nodos
y 800 pares OD*.
7.8 5
8.9 3
9.10 6
10.30 17
11.12 4
12.13 5
13.14 7
14.5 9
15.5 5
15.16 5
16.17 5
16.36 14
16.29 3
17.18 10
19.20 7
21.22 3
22.23 4
23.24 3
24.25 7
25.26 10
27.28 20
28.29 16
29.5 9
30.31 4
31.32 4
32.33 12
34.35 6
*(Nótese que sólo se han señalado los arcos en uno de los sentidos, evidentemente
cada uno de los arcos equivalentes pero de sentido contrario tendrán la misma
longitud que su arco de sentido inverso correspondiente)
Como se desprende de los datos aportados, el volumen de información que el
modelo debe manejar para encontrar una solución óptima es bastante grande a pesar
de las simplificaciones introducidas con respecto a la red de cercanías real.
Pruebas computacionales. Descripción de escenarios y resolución.
82
El motivo de introducir dichas simplificaciones radica en que, aunque se busca
generar un caso computacional de complejidad y tamaños importantes para testear el
modelo, resulta ventajoso que el escenario y los datos de trabajo sean manejables y no
excedan de ciertos límites (al menos no en este nivel de desarrollo del modelo) debido
a que se está trabajando con un algoritmo sujeto a mejoras o modificaciones y
enfrentarlo a un caso excesivamente complejo dificultaría el estudio de su desempeño
en relación con los datos del problema y las consiguientes rectificaciones en su código
o estructura que se debieran llevar a cabo para refinarlo.
Las principales simplificaciones introducidas con respecto a la red real de
cercanías de Madrid son las siguientes:
• El número de nodos o estaciones se ve reducido de 89 en la red real a 36 en el
experimento computacional.
• La longitud completa de la red real es 93 km más larga que la implementada en
el caso de cálculo generado.
• En la red de cercanías real de Madrid operan un total de 9 líneas de ferrocarril,
frente a las 7 contempladas en el experimento.
• El número de arcos (como se deduce de las dos simplificaciones anteriores) es
drásticamente inferior al de la red real.
• En la prueba computacional se han considerado los mismos posibles valores de
headways para todas las líneas mientras que en la realidad cada línea se mueve
en su propio rango de posibles valores en función de las poblaciones que visita
y la demanda que atienden, pasando de headways de pocos minutos cada tren
para las líneas más utilizadas hasta una hora de diferencia de paso entre trenes
de la línea con menor demanda.
Además de estos matices que se acaban de señalar, existen otras diferencias
entre el experimento desarrollado y la red real, pero son de muy diversa índole y no
repercuten tanto en el modelo como las ya comentadas, en cualquier caso se recuerda
que uno de los objetivos básicos es el de desarrollar un modelo de optimización
orientando a la práctica y por consiguiente cualquier variación o simplificación entre la
red real tomada como base y el experimento diseñado se debe a la búsqueda de un
ejercicio manejable y un análisis útil que permitan depurar el modelo en cuestión.
Con objeto de transmitir una idea general de la morfología de la red
desarrollada en el caso computacional se facilita a continuación un gráfico a modo de
mapa ilustrativo de la red de prueba implementada:
Pruebas computacionales. Descripción de escenarios y resolución.
83
Fig. 1.3 Red de tránsito rápido por ferrocarril de 36 nodos y 800 pares
1.4 Características comunes de los diferentes escenarios computacionales
Existen ciertos elementos que han sido definidos de modo que aparezcan en
todas las pruebas desarrolladas con valor y/o forma idénticos, lo cual se debe tanto al
modus operandi del modelo de optimización que se está depurando como a la
búsqueda de un cierto grado de paralelismo entre los distintos escenarios. A
continuación se describen dichos términos:
• Como se habrá observado en descripciones de apartados anteriores, en todos
los escenarios se trabaja tanto con headways como con frecuencias, términos
estrechamente ligados e inversamente proporcionales entre sí (se recuerda que
al estar trabajando en el ámbito de las redes de tránsito rápido se decidió
proceder usando frecuencias [o headways] en lugar de horarios por que
permitían un manejo más sencillo y dinámico de datos).
Pruebas computacionales. Descripción de escenarios y resolución.
84
En lo que se refiere a los valores que se manejan, se decidió partir de datos
relativos a headways para que luego el modelo calculase la frecuencia de los
trenes en función de la asignación realizada por el modelo. En cualquier caso,
para cada escenario se ha establecido un abanico de posibles valores de entre
los cuáles el algoritmo de optimización asignará uno a cada línea de ferrocarril
para cada escenario propuesto. Estos posibles valores de headways con los que
pueden circular los trenes de cada una de las distintas líneas son:
� 2, 3, 4, 5, 6, 10, 12, 15 y 20 (en minutos)
• En apartados anteriores se ha comentado el peso que tienen en estas pruebas
y en las soluciones aportadas por el modelo los tramos o arcos compartidos por
varias líneas. Uno de los aspectos más decisivos a la hora de identificar si dos o
más líneas de ferrocarril pueden circular de forma simultánea por la misma vía
(o “track”) es la compatibilidad entre las frecuencias o headways de operación
de las líneas involucradas. Tal y como se describió en el apartado del presente
proyecto dedicado al análisis del modelo, existe una restricción que comprueba
la viabilidad de asignar pares de líneas a la misma vía, y en dicha restricción
aparece un término (Ѳѵѵ´) que representa la anteriormente referida
compatibilidad de frecuencias o headways.
De este modo, si existe compatibilidad entre los headways (o frecuencias) de
las líneas afectadas, el término Ѳѵѵ´ toma el valor 1 y en caso contrario su valor
es 0. Con el fin de prefijar dicho valor para cada caso que se pueda presentar y
posibilitar una asignación de la cifra por parte del modelo, se construyó e
implementó en todos los casos computacionales (previo análisis y observación
del funcionamiento de redes reales) la siguiente tabla en la que se recoge las
compatibilidades o incompatibilidades entre los posibles valores de los
headways:
Tabla 1.6 Compatibilidades e incompatibilidades entre los posibles valores de
headway para las líneas en circulación por un tramo compartido.
Hd/min 2 3 4 5 6 10 12 15 20
2 0 0 0 0 0 0 0 0 0
3 0 0 0 0 0 0 0 0 0
4 0 0 0 0 0 0 0 0 0
5 0 0 0 0 0 0 0 0 1
6 0 0 0 0 0 0 0 0 1
10 0 0 0 0 0 0 1 1 1
12 0 0 0 0 0 1 1 1 1
15 0 0 0 0 0 1 1 1 1
20 0 0 0 1 1 1 1 1 1
Pruebas computacionales. Descripción de escenarios y resolución.
85
• La capacidad máxima de un vagón es de 200 personas para todos los trenes
que operan en cada uno de los escenarios. Esto, unido al hecho de que para
cada tren hay establecido un límite máximo de 8 vagones no autopropulsados y
de que en cualquier caso todos los trenes cuentan con 2 vagones
autopropulsados (en cabeza y cola) hace que la capacidad máxima de los trenes
sea de 2000 personas para cualquiera de los trenes considerados en los
distintos escenarios.
• Para todas las pruebas llevadas a cabo el headway de seguridad (es decir, el
margen mínimo de tiempo entre dos trenes que circulan por la misma vía de
forma consecutiva) es de 1 minuto, siendo también de 1 minuto el tiempo de
parada de los trenes al llegar a cada nodo o estación (dwell time).
• Como no podía ser de otro modo, la función objetivo (FO) es una parte
fundamental del modelo de optimización, y en la misma se deben definir
ciertos parámetros a los que nos referiremos como términos theta (ya descritos
en el apartado del presente proyecto en el cual se analiza el modelo propuesto)
que tienen un peso muy importante en la solución final buscada y que en la
práctica dependen de forma inherente de cada escenario estudiado. No
obstante, en los tres experimentos se han empleado los mismos valores para
cada término theta (debe recordarse que el único caso basado en la realidad es
el tercero y que por tanto es el que marca los valores que, por unicidad, se usan
en los otros dos), siendo los señalados a continuación:
� Theta_one; hace referencia al peso monetario ligado al tiempo de viaje
de los pasajeros cuando se desplazan por la red, su valor es de 1 Euro
por minuto y persona.
� Theta_two; penalización impuesta a la función objetivo por cada
transbordo que se realiza en el sistema (de esta manera se induce al
modelo a intentar definir rutas directas para los pasajeros de cada par),
su valor es de 10 Euros por transbordo realizado.
� Theta_four; factor de coste debido a la tripulación de cada ferrocarril,
(maquinista, revisores, etc) estimado en 40 Euros/hora por tren.
• Con respecto al coste de compra de material rodante, se ha estimado en 2,5
millones de Euros para cada locomotora y 0,9 millones de Euros para cada
vagón. Se considerará un horizonte temporal de 50 años para la amortización
de dichos costes de compra.
Pruebas computacionales. Descripción de escenarios y resolución.
86
• Por otro lado, los costes de operación se han definido con un valor de 34 Euros
por kilómetro para las locomotoras y 2 Euros por kilómetro para los vagones no
autopropulsados.
• La velocidad media de los trenes se ha fijado en 60 kilómetros por hora.
• Para todos los experimentos de cálculo se ha establecido una muy considerable
penalización de 5 millones de Euros en la función objetivo por cada pasajero
que la red no consiga atender, induciendo así al modelo a maximizar la
demanda atendida.
2. Resolución de los escenarios computacionales
Una vez descritas las características propias de cada prueba computacional así
como las comunes a los distintos experimentos se procede en el presente punto a
realizar una descripción de los pasos seguidos para el planteamiento y resolución de
los anteriormente referenciados escenarios. Más adelante, se analizarán en
profundidad los resultados derivados de cada experimento una vez acometidas las
pruebas. El primer paso fue obviamente recopilar los datos correspondientes a los
distintos escenarios. Se recuerda que los casos A y B corresponden a redes ficticias y
que por tanto la totalidad de la información que se usa en los mismos es aleatoria y se
generó expresamente para dichas pruebas, si bien siempre se procuró implantar datos
que se puedan considerar coherentes y realistas, ya que al fin y al cabo se pretende
desarrollar un modelo de uso práctico para redes de tránsito rápido por ferrocarril
reales.
En cuanto al caso computacional C, se recopiló prácticamente la totalidad de
los datos de la página web del operador de ferrocarriles a nivel nacional en España
(Renfe Operadora). Como antes se ha indicado, dicho caso se basa en la red de
cercanías de Madrid, de modo que el experimento abarca aproximadamente el 50% de
la red real, por lo que los datos de arcos, número de líneas y su recorrido, nodos y
distancia entre los mismos, etc; son un reflejo de la real pero con algunas
simplificaciones ya comentadas. Los datos de demanda pretenden reflejar el tránsito
medio real de pasajeros registrados en dicha red considerando un intervalo de una
hora en un día laborable.
Un aspecto que no se ha comentado hasta el presente momento y que resulta
de vital importancia especialmente para el caso de cálculo C es determinar cuáles son
los caminos que los pasajeros describirán en su trayecto desde el nodo Origen de la
red desde el que parten hasta el nodo Destino en el que abandonen el sistema, esto
es, determinar la trayectoria a través de los arcos recorrida para cada par Origen-
Destino.
Pruebas computacionales. Descripción de escenarios y resolución.
87
La trascendencia de determinar estos caminos surge de la necesidad de hacer
más abordable el modelo desde el punto de vista informático tal y como se ha descrito
en el apartado anterior del presente proyecto (“Resolución por medio de GAMS”). El
escollo principal a este efecto lo constituye el caso experimental C, que debido al
tamaño que presenta su red origina una enorme cantidad de ecuaciones, variables,
parámetros y otros elementos inherentes al modelo que tendrán que ser almacenados
y manejados durante la realización de los cálculos.
De no preseleccionar que elementos deben utilizarse y cuáles no, el
procedimiento de cálculo resultaría prácticamente inviable debido a la cantidad de
memoria requerida por el programa y a la excesiva cantidad de tiempo necesario a
invertir para resolver el problema.
Un modo de reducir notablemente la cantidad de datos a manejar es calcular
de forma previa cuáles son los arcos que se recorrerán para cada par Origen-Destino,
de modo que aquellos que no se usan son anulados para cada par, ahorrando con ello
muchísima memoria ya que el programa no tendrá que manejar la totalidad de los
flujos de pasajeros posibles para cada arco y par, sino solo los imprescindibles para la
resolución del experimento. Dicha determinación de caminos puede llevarse a cabo
mediante una considerable cantidad de métodos diferentes; siendo el elegido y
empleado para la presente cuestión el denominado “Algoritmo de Yen”, cuyo análisis
se abordará una vez terminada la descripción de los pasos seguidos para el
planteamiento y resolución de los distintos escenarios.
Una vez determinados los itinerarios antes referidos, el segundo paso para la
resolución de los escenarios computacionales consistió en implementar los datos de
los experimentos así como toda la estructura del modelo en forma de código para el
software “GAMS”, que como ya se ha comentado constituye una potente herramienta
capaz de ejecutar una grandísima variedad de modelos de optimización. La resolución
de los distintos escenarios a través de la aplicación en GAMS del modelo en el que se
centra el presente proyecto permitirá observar su desempeño, resultados y opciones
de mejora (se recuerda que en el apartado “Resolución por medio de GAMS” de este
proyecto se realiza una profunda descripción de la implementación de los códigos y
datos necesarios en el software GAMS, así como un análisis de los elementos de dicho
programa [solvers que se emplearán, características y utilidades, modo de operación,
etc]).
Tras la implementación de la información necesaria, se procedió a la ejecución
mediante GAMS de los tres casos computacionales empleando tres solvers distintos:
CoinBonMin, Alpha ECP y SBB. En el caso de la prueba C la ejecución se repitió
modificando sucesivamente elementos clave tanto para el modelo como para el
escenario con el fin de realizar análisis de sensibilidad que más adelante serán
comentados.
Pruebas computacionales. Descripción de escenarios y resolución.
88
2.1 Exposición del Algoritmo de Yen. Modo de aplicación para el cálculo de
k-caminos más cortos.
En el punto anterior se comentaba la conveniencia de calcular los caminos de
tránsito más cortos para cada uno de los pares Origen-Destino considerados para el
caso computacional C. Evidentemente esta labor podría ser realizada por cualquier
persona simplemente observando el mapa de la red en cuestión y estableciendo que
rutas son las más adecuadas para desplazarse entre cada par de nodos origen y
destino; no obstante considerando la cantidad de pares, nodos y arcos implicados
sobre todo para el caso computacional C, dicha tarea sería bastante larga y tediosa,
por lo que resulta mucho más eficiente usar un software que permita determinar
dichos caminos de forma automática.
Precisamente para el caso C, que es el de mayor complejidad se ha optado por
considerar para los distintos pares los tres caminos más cortos de cada par w. Dicho
problema de determinación de caminos (conocido como “k-shortest paths problem”
en inglés, en referencia al cálculo de los k-caminos más cortos de tránsito en un
problema de transporte) ha sido ampliamente estudiado y existe una buena colección
de métodos para abordarlo. El algoritmo de Yen, elaborado por Jin Y.Yen en 1971, ha
sido el elegido para este menester debido a su conocida solvencia y a su buena
capacidad de implantación en códigos de programación informáticos.
Así pues, tal y como se describe en (Yen, 1971), se trata de un algoritmo de
cálculo de k-caminos más cortos para un grafo (o red) sin bucles con arcos de coste no
negativos. Para facilitar el entendimiento de la descripción acerca del funcionamiento
del algoritmo de Yen se facilita la siguiente notación:
- Ak; k-ésimo camino más corto desde el nodo origen hasta el nodo destino para
el par considerado.
- dij; coste de recorrer el arco existente entre el nodo “i” y el nodo “j”.
- Aki; desviación de ruta para Ak-1 que aparece en un nodo “i”, que puede ser
desde el nodo origen del par en cuestión hasta un nodo “Qk”, situado
justamente antes de llegar al nodo destino del par considerado.
- Rki; camino principal de la desviación Ak
i, que imita a la ruta de Ak-1 y llega hasta
el nodo i-ésimo de Aki.
- Ski; camino directo de la desviación Ak
i, que nace en el nodo i-ésimo de Aki y
finaliza en el nodo destino del par Origen-Destino estudiado.
El funcionamiento de este método puede dividirse en dos partes: por un lado el
cálculo del primer k-camino más corto (que se denotará como “A1”) y por otro el
cálculo del resto de los k-caminos más cortos. Considérese un grupo de rutas “A” que
contendrá los k-caminos más cortos y otro grupo “B” que almacenará potenciales k-
caminos más cortos.
Pruebas computacionales. Descripción de escenarios y resolución.
89
Para la determinación de A1 puede emplearse cualquier método de
determinación de caminos más cortos (usualmente se emplea el algoritmo “Dijkstra”),
mientras que para obtener cada camino más corto Ak (donde k puede valer desde 2
hasta el número de caminos “K” que se pretenda determinar) el algoritmo de Yen
supone que todos los caminos desde A1 hasta Ak-1 han sido previamente determinados.
Se inicia así una iteración que se divide en dos procesos, por un lado encontrar las
desviaciones Aki y por otro seleccionar un camino de longitud mínima que se convierta
en Ak.
El primer proceso, conducente a la obtención de las desviaciones Aki se divide a
su vez en tres operaciones secundarias:
• Elegir el camino principal Rki, escogido al encontrar un sub-camino Ak-1
que aparece en el nodo “i” de Aj (donde j puede tomar valores desde 1
hasta k-1). En el caso de que se encuentre dicha sub-ruta, el coste del
arco di(i+1) de Aj se considera infinito.
• Descubrir el camino directo Ski, calculando el camino más corto desde el
nodo “spur” hasta el nodo destino. En este cálculo se eliminan los arcos
empleados desde “i” hasta “i+1”, lo que certifica que el camino directo
es diferente al anteriormente hallado.
• Sumar el camino principal Rki y el camino directo Sk
i de modo que el
resultado es Aki:
� Aki= Rk
i+ Ski
Y seguidamente esta desviación es añadida al grupo de rutas “B”. Una
vez dentro del grupo, aquellos arcos cuyo coste fue elevado al infinito y
luego eliminados reaparecen con su coste original.
La segunda parte, encaminada a encontrar un camino Ak adecuado, consiste en
localizar la ruta dentro del grupo de itinerarios “B” que tenga el menor coste. Una vez
hallado, dicho camino es trasladado desde el grupo “B” hasta el grupo “A”, dando
comienzo inmediatamente después la siguiente iteración. Nótese que la cantidad de
caminos almacenados en “B” debe forzosamente ser igual o superior al número de k-
caminos más cortos que aún reste por fijar.
De este modo, una vez seleccionado el método de cálculo para los tres caminos
más cortos y comprendido su funcionamiento, se programó un código en lenguaje C++
que reproducía el método de Yen y se introdujeron los datos necesarios para el cálculo
de los caminos requeridos para cada caso computacional (esto es, se definieron los
arcos que componen la red y el número de caminos más corto a determinar).
Pruebas computacionales. Descripción de escenarios y resolución.
90
Posteriormente se trasladaron los resultados del método de Yen a GAMS
mediante una tabla que reflejase para cada arco si era empleado o no por alguno de
los caminos más cortos para cada par. Para los arcos que entraron en alguno de los
recorridos más cortos el elemento correspondiente de la tabla tomó el valor “1” y para
aquellos que no participasen en ninguna ruta de las calculadas el elemento de la tabla
tomó el valor “0”.
La decisión de construir una tabla viene determinada por la buena disposición
de GAMS de leer datos ordenados de este modo. Así pues, para introducir los datos de
las rutas calculadas por el método de Yen en formato tabla a GAMS, se programó una
función en C++ que escribía dicha tabla con los caminos en el formato binario antes
especificado en un bloc de notas conforme las rutas de cada par se iban calculando.
Una vez acabado el proceso en C++ y escrita la tabla completa en el bloc, solo se tuvo
que copiar dicha tabla a GAMS para finalizar la implantación de los datos. Con ello, no
sólo se ahorraban tiempo y recursos de memoria para el cálculo informático, sino que
se consideraba dentro del modelo un comportamiento lógico por parte de los
pasajeros en su elección de ruta dentro de la red.
2.2 Descripción de resultados de los casos computacionales. Análisis de
sensibilidad.
Se aborda en el presente apartado la exposición de los resultados de los
experimentos computacionales, de modo que primero se comentarán los datos
obtenidos y comportamiento del modelo en la resolución de los escenarios originales
ya descritos sin modificación alguna, mientras que posteriormente se entrará a
comentar los resultados de los análisis de sensibilidad realizados.
2.2.1 Exposición de resultados de los escenarios computacionales
Es necesario aclarar que cada uno de los tres escenarios computacionales
(originales) han sido resueltos por tres veces cada uno empleando tres solvers
distintos: Alpha ECP, SBB y CoinBonMin, ya descritos en el apartado “Resolución por
medio de GAMS”. A continuación se abordará de forma resumida los resultados
obtenidos para cada escenario computacional y solver empleado, de modo que pueda
discernirse qué software de resolución es el más efectivo y cómo se comporta en
general el modelo para cada uno de los experimentos. Una vez determinado que
solver es el más efectivo, se realizará una descripción detallada de los resultados
obtenidos para cada test empleando dicho solver.
En primer lugar, se presentan de forma resumida los resultados obtenidos para
el caso computacional “A” mediante el empleo de los distintos solvers en la siguiente
tabla :
Pruebas computacionales. Descripción de escenarios y resolución.
91
Tabla 2.1 Resumen de resultados caso computacional “A” para cada uno de los
solvers de resolución utilizados.
Factor\Solver Alpha ECP CoinBonMin SBB
Resolución satisfactoria
del caso computacional Sí Sí Sí
Valor Función Obj. 642.350 € 642.350 € 642.350 €
Tiempo empleado en la resolución
4,44 segundos 177,03 segundos 11,10 segundos
Demanda no atendida 0 viajeros 0 viajeros 0 viajeros
Headway de cada línea
L1-12 minutos L2-12 minutos L3-10 minutos
L1-12 minutos L2-12 minutos L3-10 minutos
L1-12 minutos L2-12 minutos L3-10 minutos
Número de vagones
para los ferrocarriles de cada línea (incluyendo
locomotoras)
L1-5 vagones L2-3 vagones L3-6 vagones
L1-5 vagones L2-3 vagones L3-6 vagones
L1-5 vagones L2-3 vagones L3-6 vagones
Como puede apreciarse, los resultados obtenidos por los distintos solvers son
prácticamente idénticos: todos consiguen resolver el problema planteado en el
experimento obteniendo una solución entera que consigue atender a la totalidad de la
demanda con un valor para la función objetivo de 642.350 Euros, asignando también el
mismo valor de headways y tamaños a los trenes distintas líneas. La principal y única
diferencia de peso entre el desempeño de los distintos solvers es el tiempo empleado
para la resolución del caso computacional, habiendo resultado el solver Alpha ECP ser
el más rápido necesitando tan sólo 4, 44 segundos.
Tabla 2.2 Resumen de resultados caso computacional “B” para cada uno de los
solvers de resolución utilizados.
Factor\Solver Alpha ECP CoinBonMin SBB
Resolución satisfactoria
del caso computacional Sí Sí No
Valor Función Obj. 1.189.199 € 1.291.388 -
Tiempo empleado en la
resolución 14,89 segundos 922,83 segundos -
Demanda no atendida 0 viajeros 0 viajeros -
Headway de cada línea
L1-10 minutos L2-12 minutos
L3-3 minutos L4-15 minutos L5-12 minutos
L1-12 minutos L2-10 minutos
L3-15 minutos L4-15 minutos L5-10 minutos
-
Número de vagones para los ferrocarriles de
cada línea (incluyendo locomotoras)
L1-10 vagones L2-7 vagones L3-3 vagones L4-2 vagones L5-2 vagones
L1-10 vagones L2-6 vagones
L3-10 vagones L4-2 vagones L5-2 vagones
-
Pruebas computacionales. Descripción de escenarios y resolución.
92
En cambio, en este segundo test se producen diferencias de rendimiento
notables para cada uno de los tres solvers; siendo sin duda SBB el de menor utilidad
puesto que no consigue obtener una solución óptima entera para el problema
planteado, logro que sí completan los otros dos software de resolución. De estos dos,
Alpha ECP es sin duda el que más rendimiento ofrece, ya que consigue resolver el
problema de forma más rápida (14,89 segundos frente a los 922,83 segundos de
CoinBonMin) y además consigue el valor más bajo para la función objetivo: 1.189.199
euros (aproximadamente 100.000 euros menor que el valor logrado por CoinBonMin),
más que posiblemente gracias a que la media de los headways de sus líneas es menor
que la asignada por CoinBonMin.
Tabla 2.3 Resumen de resultados caso computacional “C” para cada uno de los
solvers de resolución utilizados.
Factor\Solver Alpha ECP CoinBonMin SBB
Resolución satisfactoria del caso computacional
Sí No* No
Valor Función Obj. 4.966.077 € - -
Tiempo empleado en la resolución
2407, 76 segundos - -
Demanda no atendida 0 viajeros - -
Headway de cada línea
L1-20 minutos L2-5 minutos
L3-10 minutos L4-12 minutos
L5-4 minutos L6-20 minutos L7-5 minutos
- -
Número de vagones para los ferrocarriles de cada línea (incluyendo
locomotoras)
L1-7 vagones L2-10 vagones L3-7vagones L4-8 vagones L5-5 vagones L6-2 vagones
L7-10 vagones
- -
*Descartado debido a la excesiva cantidad de tiempo que necesitaría para terminar la
ejecución (no necesariamente de forma exitosa).
A pesar de que se trata sin duda del caso computacional más complejo es el
que presenta el análisis de efectividad de solvers más sencillo puesto que sólo Alpha
ECP consigue resolverlo (con un tiempo de resolución de 2407,76 segundos),
ofreciendo una solución entera mediante la cual se obtiene un valor de la función
objetivo de 4.966.077 Euros.
Pruebas computacionales. Descripción de escenarios y resolución.
93
Se tiene con esto que la efectividad de los solvers se ha visto menguada
conforme mayor es la complejidad del caso computacional a abordar (lo cual resultaba
previsible), de modo que la red de 8 nodos y 10 pares es la única de las planteadas que
ha sido satisfactoriamente resuelta por todos los solvers, mientras que la de 12 nodos
y 56 pares ha resultado inviable para SBB y finalmente el sistema de mayor tamaño y
complejidad, de 36 nodos y 800 pares únicamente se ha podido resolver con la ayuda
del Alpha ECP.
Así pues, puede deducirse con facilidad que el solver más indicado de entre los
propuestos para ejecutar el modelo en desarrollo en el presente proyecto es
efectivamente Alpha ECP, el único que ha conseguido resolver los tres casos
computacionales, siendo también el más rápido para cada uno de los casos y además
ofreciendo en todos los experimentos el valor óptimo de la función objetivo más
reducido. Resulta por otra parte llamativo el mejor desempeño del solver CoinBonMin
sobre SBB (que sólo resuelve el caso computacional A), siendo un software de código
abierto que demuestra su versatilidad con problemas de entidad, si bien es cierto que
requiere de tiempos de resolución en general superiores a los de los otros solvers.
Cabe decir finalmente que ya que Alpha ECP ha resultado ser el solver más
eficiente, tanto el análisis de los resultados de resolución para los distintos casos
computacionales como los correspondientes análisis de sensibilidad comentados en
los siguientes puntos corresponderán a las ejecuciones realizadas por este solver.
2.2.1.1 Descripción de los resultados obtenidos mediante la aplicación del
solver Alpha ECP. Caso computacional A (8 nodos y 10 pares O-D).
Este caso computacional ha sido resuelto por GAMS (solver Alpha ECP) de
forma satisfactoria en un plazo de tiempo bastante corto (4,44 segundos),
encontrando una solución entera para la cual el valor de la función objetivo es de
642.350 Euros (se recuerda que la ecuación de la FO está dividida por 10.000 en el
archivo de “Network Loading Model 2 Constraints.gms” para evitar que GAMS arroje
valores excesivamente altos).
De este montante de 642.350 Euros, la amplia mayoría corresponde al coste
asociado al tiempo de viaje de los pasajeros, que supone un importe de 501.600,48
Euros (un 78,09 % del valor total de la FO) por lo que es claramente el factor de mayor
peso en la función objetivo.
Pruebas computacionales. Descripción de escenarios y resolución.
94
Fig. 2.1 Informe de resolución en archivo .lst para caso computacional A.
Este valor resulta comprensible si se tiene en cuenta que se calcula en base al
tiempo total que tardan todos los pasajeros de la red en realizar su viaje, estando
estimado el coste asociado al tiempo de desplazamiento en 1 €/minuto para cada
pasajero, lo que unido al hecho de que la demanda total de la red es de 16.350
personas hace previsible el elevado coste que generalmente va a tener esta partida
(como se verá más adelante, los tiempos de viaje para los pares en este caso
computacional superan los 20 minutos, por lo que se trata de un importe esperado
para este miembro de la FO).
El segundo componente de la función objetivo de mayor cuantía es el
correspondiente a la penalización por el número de transbordos que realizan los
pasajeros, lo que supone un importe de 93.000 Euros (14,48 % del valor total de la FO),
bastante alejado de los costes del miembro anteriormente descrito. En todo caso,
debe indicarse que este miembro constituye un “castigo” para la FO (cada transbordo
acarrea un coste de 10 Euros) ya que lo que se pretende es que el modelo consiga
asignar el máximo número de rutas directas a los pasajeros de modo que realice la
mínima cantidad de transbordos posibles.
Aún con esto, como se desprende de la cuantía de 93.000 Euros antes
mencionada, se han producido numerosos transbordos consecuencia de la morfología
de la red y de ciertos componentes asociados a otros costes. Más adelante se
describirán los transbordos registrados con mayor detalle.
Pruebas computacionales. Descripción de escenarios y resolución.
95
El coste de operación de los ferrocarriles (dependiente de los kilómetros
recorridos) asciende a la cantidad de 46.681,07 Euros (7,27% del valor de la FO)
mientras que los correspondientes a la cuota de amortización por la compra de
material rodante y al personal de tripulación de los trenes son ya muy reducidos en
comparación con los anteriores (debe recordarse no obstante que estos costes están
calculados para un plazo temporal de una hora de funcionamiento de la red),
alcanzando los importes de 322,41 Euros y 746,04 Euros respectivamente (suponen
apenas a unos porcentajes sobre el total de la FO del 0,05% para el coste de compra de
material rodante y 0,12% para el coste de tripulación).
Fig. 2.2 Valor miembros FO y factores asociados. Caso computacional A.
Por otro lado, el modelo ha conseguido atender a la totalidad de la demanda,
estableciendo para ello un conjunto de flujos de pasajeros que abarcan la totalidad de
la red y que son considerables sobre todo en los arcos 3.5, 5.7 y 7.8 (en ambos
sentidos) donde se han registrado flujos totales de hasta 6600 pasajeros por arco,
siendo las líneas 1 y 3 las más utilizadas.
En lo referente al número de transbordos, cabe decir que ha sido destacable
alcanzando la cifra de 9300, lo que supone que aproximadamente uno de cada dos
pasajeros realiza un transbordo en su viaje, estando concentrados dichos transbordos
sobre todo en el nodo 5 que constituye el punto de interconexión más versátil de la
red puesto que en él confluyen las tres líneas, aunque también resulta de importancia
a este efecto el nodo 7, en el cual se hace obligatorio cambiar de la línea 1 a la línea 3
para aquellos que desde el nodo 5 o puntos alejados pretendan llegar a las estaciones
8 y 6 (misma circunstancia se da para pasajeros con el itinerario inverso). Esto último
además explica por qué las líneas 1 y 3 son desde las cuales se inician mayores
cantidades de transbordos.
Pruebas computacionales. Descripción de escenarios y resolución.
96
Por otro lado, los headways que el modelo ha establecido para cada una de las
líneas son los siguientes:
• Línea 1: headway de 12 minutos entre trenes, lo que corresponde a una
frecuencia de 5 trenes cada hora.
• Línea 2: headway de 12 minutos entre ferrocarriles al igual que línea 1
(frecuencia de paso de 5 trenes a la hora).
• Línea 3: headway de 10 minutos entre trenes, lo que equivale a una frecuencia
de 6 trenes cada hora.
Como se puede ver, los valores de headways son moderadamente elevados y
bastante parecidos para todas las líneas, siendo la línea 3 la de mayor frecuencia
debido probablemente a que es la que más pasajeros transporta. El hecho de que
todas las líneas estén implicadas en algún tramo compartido sin duda ha propiciado
estos valores de frecuencia de modo que el uso común de vías por líneas distintas sea
posible.
La asignación de líneas a vías en segmentos compartidos ha resultado bastante
sencilla a tenor de que se trata de una red simple de tan sólo tres tramos compartidos
(arcos 3.5, 5.4 y 5.7 en ambos sentidos) en los cuales las dos líneas que podían
compartir cada arco se han asignado a la única vía disponible de cada tramo con el
mínimo valor de headway compatible con dicha asignación (12 y 10 minutos).
En lo referido a la capacidad de los trenes, decir que no es necesaria la
implantación de ferrocarriles de grandes dimensiones, ya que la línea que opera con
los trenes de mayor tamaño es la número 3, que tienen un total de 6 vagones (4 de
ellos no autopropulsados) y debe recordarse que cada vagón (sea locomotora o no)
tiene aforo para 200 personas, luego los ferrocarriles de la línea 3 pueden dar servicio
a toda la demanda necesaria con una capacidad de sólo 1200 personas por tren (el
máximo posible para cualquier tren que opere en la red está situado en 10 vagones, es
decir, 2000 pasajeros).
El número de vagones asignado a la línea 1 ha sido de 5 (capacidad de 1000
pasajeros) mientras que la línea 2 opera sólo con 3 vagones (capacidad para 600
viajeros). Teniendo en cuenta que antes se señaló que los mayores flujos de pasajeros
se daban para las líneas 1 y 3 (se deduce que la línea 2 es menos utilizada) dichos
valores de capacidad resultan bastante lógicos.
Pruebas computacionales. Descripción de escenarios y resolución.
97
Nótese que el tamaño de los ferrocarriles también se ve afectado por el hecho
de que las tres líneas tomen parte en algún tramo de vía compartido, lo que impide
que el valor del headway entre trenes de cualquier línea sea inferior a 10 min y por
consiguiente no pueden asignarse frecuencias de paso superiores, lo que supondría
emplear trenes con menor número de vagones y el correspondiente ahorro de compra
de material rodante.
Fig. 2.3 Número de vagones no autopropulsados por línea. Caso computacional A.
Resulta conveniente señalar que el tiempo medio de viaje más alto (39
minutos) se ha dado para los pares Origen-Destino 4 y 8 (tienen el mismo trazado pero
distinto sentido) mientras que el trayecto más rápido a lo largo de la red (22 minutos)
es el que se ha dado para los pares 3 y 5 (que también comparten trazado pero con
distinto sentido). En general el promedio entre los tiempos de viaje y la distancia a
recorrer es bastante similar para todos los pares (cociente entre el tiempo empleado
por los pasajeros para efectuar su desplazamiento para ese par y la longitud de dicho
trayecto) de modo que la diferencia entre el promedio más alto y el más bajo es de
0,25 minutos por kilómetro recorrido, lo que implica que la red está bastante
equilibrada (líneas y frecuencias bien distribuidas) y que los pasajeros viajan a
velocidades muy parecidas con independencia del par Origen-Destino según el cual se
muevan, por lo que la diferencia de tiempos obedece principalmente a la longitud de
los desplazamientos.
En el apartado anterior “Resolución por medio de GAMS” se hacía referencia a
la importancia de reducir el tamaño del modelo mediante el ahorro de uso de variables
y ecuaciones innecesarias empleando una serie de subconjuntos (wijl (i,j,w,l),
willl(i,w,l,ll), etc), que preseleccionasen los elementos justos y necesarios para las
ejecuciones y así no colapsar la memoria del ordenador mientras se ejecuta el modelo.
Este hecho queda patente para redes de transporte de mayor envergadura, pero aún
para el presente caso puede verse la potencial ventaja de usar dichos subconjuntos
sobre algunas variables representativas:
Pruebas computacionales. Descripción de escenarios y resolución.
98
Tabla 2.4 Ahorro de variables mediante el uso de subconjuntos. Caso
computacional A.
Variable Tamaño original
Tamaño reducido con los Sets
Ahorro
fijwl(i,j,w,l) 1920 62 1858
fwl(w,l) 30 30 0
trr(i,w,l,ll) 720 68 652
2.2.1.2 Descripción de los resultados obtenidos mediante la aplicación del
solver Alpha ECP. Caso computacional B (12 nodos y 56 pares O-D).
Para realizar este experimento GAMS emplea un poco más de tiempo que para
el caso computacional anterior (debe recordarse que la red ahora considerada es
ligeramente de mayor envergadura), empleando un total de 14,89 segundos en
resolverlo. En cualquier caso, se puede considerar como un muy rápido tiempo de
resolución para el experimento considerado.
El valor que ha alcanzado la FO objetivo es de 1.189.199 Euros, importe al cual
contribuyen especialmente los costes ligados al tiempo de viaje de los pasajeros que
circulan a través de la red de ferrocarriles, ascendiendo dicho coste a la cantidad de
922.199,58 Euros (supone un 77,56% del total de la FO).
Al igual que en el caso anterior, este término de la FO abarca aproximadamente
tres cuartas partes de los costes totales de la red, siendo sin duda el miembro de
mayor peso de la FO. De nuevo, el alto importe con respecto al resto de los
componentes de la FO se explica por la demanda y el valor monetario del tiempo de
desplazamiento (1 €/minuto para cada pasajero, con una demanda total de 54.300
personas), factores que elevan este coste de forma muy considerable a medida que
aumenta el tiempo empleado en los desplazamientos (a modo ilustrativo, si se diera en
este caso un tiempo de viaje de 20 minutos para todos los pasajeros, el importe de
este componente de la FO superaría el millón de Euros).
Le sigue en importancia el término que cuantifica los costes debidos a la
penalización por los transbordos realizados, que en este experimento computacional
alcanzan un importe de 180.000 Euros (15,13% del valor de la FO). A pesar de ser el
segundo componente en peso de la FO, la proporción de transbordos ha disminuido
con respecto al anterior experimento computacional de forma notable, haciéndose
valer el “castigo” de 10 Euros impuesto a la FO por cada transbordo realizado, de
modo que en este caso la proporción se reduce a que uno de cada tres pasajeros debe
cambiarse de línea durante su viaje.
Pruebas computacionales. Descripción de escenarios y resolución.
99
Si se analiza el comportamiento de los pasajeros en una red real de grandes
dimensiones se puede comprobar que efectivamente muchas personas tienen que
realizar al menos un transbordo durante su desplazamiento mediante cercanías o
metro, por lo que dicho valor de transbordos arrojado por el modelo puede
considerarse algo menor al de que corresponde a una red real de tránsito rápido.
Por otro lado, los costes de operación de los ferrocarriles (costes por km
recorridos) ocupan el tercer lugar en cuantía de entre todos los miembros de la FO,
aunque supone menos de una décima parte del valor de ésta con 85.049,07 Euros
(7,15% de la FO). Los términos restantes tienen una importancia mucho menor que los
anteriormente comentados ya que entre ambos apenas suman poco más de la
milésima parte del valor de la FO con un importe de 580,83 Euros (0,05%) para los
gastos en concepto de amortización asociados a la compra de material rodante y de
1.369,52 Euros (0,12%) para los costes del personal a cargo de la tripulación de los
trenes.
Fig. 2.4 Valor miembros FO y factores asociados. Caso computacional B.
Nuevamente el modelo consigue atender a toda la demanda (todas las
variables notatdem (w) valen 0). En lo referente a los flujos de pasajeros, cabe destacar
que los arcos 8.7, 7.5 y 5.3 han sido en los que mayor movimiento de pasajeros se ha
registrado (también en sentido inverso aunque en menor medida), mientras que los
arcos periféricos como 9.10, 11.12 o 10.4 son muy poco empleados, aunque esto debe
achacarse mayormente a que varios de los nodos situados en dichos arcos no actúan
como origen ni destino de ningún par sino que más bien son nodos de paso. La línea
más utilizada es la línea 1 mientras que la 4 es la de menor uso con gran diferencia (el
recorrido de ésta comprende los arcos periféricos a los que antes se hacía referencia).
Pruebas computacionales. Descripción de escenarios y resolución.
100
Por otra parte, el número de total de transbordos en la red es de 18.000 en
este caso, siendo los puntos principales en los que se concentran las transferencias de
pasajeros los nodos 7 y 5, el primero por ser estación de transbordo obligatorio entre
las líneas 1 y 3 para todos los viajeros que procedan del nodo 5 salvo aquellos cuyo
destino sea el propio nodo 7 y el segundo por constituir un punto de intercambio en
este caso entre las líneas 1 y 2, estando situado en el corazón de la red. En lo referente
a las líneas la número 1 y la número 3 son las que mayores cantidades de traslados de
pasajeros hacia otras líneas registran (en consonancia con lo comentado acerca de los
transbordos en el nodo 7).
En cuanto a los headways asignados a las líneas, decir que han sido valores
relativamente similares entre sí salvo para la línea 3, como puede verse a
continuación:
• Línea 1: headway de 10 minutos entre trenes, lo que corresponde a una
frecuencia de 6 trenes cada hora.
• Línea 2: headway de 12 minutos entre ferrocarriles, con una frecuencia de paso
de 5 trenes a la hora.
• Línea 3: headway de 3 minutos entre trenes, lo que equivale a una frecuencia
de 20 trenes cada hora.
• Línea 4: headway de 15 minutos entre ferrocarriles, por lo que la frecuencia es
de 4 trenes a la hora.
• Línea 5: headway de 12 minutos entre trenes, con lo que se tiene que la
frecuencia es de 5 trenes a la hora.
Fig. 2.5 Valores de headways y frecuencias para las distintas líneas. Caso
computacional B.
Pruebas computacionales. Descripción de escenarios y resolución.
101
Las líneas en general tienen valores de headway que son mayormente elevados
salvando la excepción de la línea 3, que aunque maneja un número de pasajeros
cercano (aunque ligeramente inferior) al de la línea 2, posee una frecuencia mucho
más elevada debido a que no se encuentra en presente en ningún tramo compartido y
por tanto su headway no está acotado a valores más altos como si ocurre con las líneas
1 y 2, a lo que hay que sumar el hecho de que tener una frecuencia elevada permite a
dicha línea operar con trenes de tamaño más reducido, con el correspondiente ahorro
de compra de material rodante.
Los valores de headway para las líneas 4 y 5 son bastante elevados a pesar de
que dichas líneas no toman parte en ningún tramo compartido. Esto se explica por el
reducido volumen de demanda que manejan en comparación con las otras tres, que
además queda reflejado en la circunstancia de que a pesar de que operan con valores
bajos de frecuencia usan trenes del tamaño mínimo permitido (2 locomotoras por
ferrocarril).
Por otro lado, en este experimento computacional existe un único tramo
compartido en ambas direcciones (arcos 3.5 y 5.3) por las líneas 1 y 2 que han sido
asignadas a la misma vía con los valores de headway compatibles más bajos posibles
(10 y 12 minutos) para que exista compatibilidad entre dichas líneas.
El tamaño de los trenes es muy dispar como consecuencia de las circunstancias
que rodean a cada línea, de modo que tal y como se ha comentado antes las líneas 4 y
5 cuentan con ferrocarriles del tamaño más pequeño permitido debido a la baja
cantidad de pasajeros que deben de transportar. La línea 3, por otra parte, opera con
trenes de 3 vagones como consecuencia de su elevada frecuencia que le permite
transportar toda la demanda necesaria con ferrocarriles más pequeños (no obstante,
nótese que la cantidad de trenes que circulan en dicha línea se incrementa). Las líneas
1 y 2 son las que operan con los trenes de mayor tamaño debido a la imposibilidad de
aumentar su frecuencia de paso por la compatibilidad de frecuencias en el tramo
compartido. El número de vagones es alto sobre todo en la primera que emplea trenes
con el mayor tamaño posible (10 vagones en total, contando las locomotoras),
mientras que los de la línea 2 son algo más pequeños (7 vagones) puesto que
transporta una menor cantidad de pasajeros que la primera.
Fig. 2.6 Número de vagones no autopropulsados por línea. Caso computacional B.
Pruebas computacionales. Descripción de escenarios y resolución.
102
Por último, hay que reseñar que los tiempos promedio de viaje han sido
lógicamente más dispares que en el caso anterior debido principalmente a la mayor
variedad de trazados a realizar, hecho favorecido por el mayor tamaño de la red. Aún
con esto, la diferencia de tiempos entre los pares cuyo recorrido se tarda más en
realizar (pares 5 y 36, con tiempo promedio de viaje de 33 minutos y medio) y los
itinerarios de más rápida realización (pares 42 y 55, con un tiempo medio de 6 minutos
y medio) sigue sin sobrepasar la media hora (27 minutos).
Fig. 2.7 Proporción tiempo de viaje/distancia recorrida para cada par w.
Caso computacional B.
Si se considera la relación entre el tiempo empleado y la distancia recorrida
para cada par, se tiene que la diferencia entre el mejor promedio y el peor es
aproximadamente de 2 minutos, casi diez veces el valor obtenido para el caso
computacional anterior, lo que indica un peor equilibrio en lo referente a la situación
de las líneas con respecto a la morfología de la red, si bien puede considerarse más
que admisible comparado con la diferencia de promedios existente en una red de
tránsito rápido por ferrocarril real. Debe indicarse que conforme aumentan las
dimensiones de la red estudiada evidentemente es más complicado definir un reparto
equilibrado de las rutas de las líneas por los nodos y es previsible una mayor diferencia
entre los tiempos de viaje según la ruta escogida por los pasajeros, por lo que no sólo
influirá la distancia a recorrer con independencia del par Origen-Destino, sino también
el itinerario a realizar (nótese que los pares antes referidos no son aquellos de peor ni
de mejor promedio)
En cuanto al ahorro logrado en el uso de variables, cabe destacar que es
bastante más notorio que para el caso anterior, si bien no se puede apreciar aún la
total magnitud del potencial del procedimiento, que quedará patente con los datos
recogidos en el experimento computacional C. Para el presente caso, los datos de
ahorro en las variables representativas son los siguientes:
Pruebas computacionales. Descripción de escenarios y resolución.
103
Tabla 2.5 Ahorro de variables mediante el uso de subconjuntos. Caso
computacional B.
Variable Tamaño original
Tamaño reducido con los Sets
Ahorro
fijwl(i,j,w,l) 40320 231 40089
fwl(w,l) 280 132 148
trr(i,w,l,ll) 16800 187 16613
2.2.1.3 Descripción de los resultados obtenidos mediante la aplicación del
solver Alpha ECP. Caso computacional C (36 nodos y 800 pares O-D).
Sin duda se aborda ahora el experimento más próximo a la realidad para una
red de transporte rápido por ferrocarril de entre los contemplados en el presente
proyecto. En este caso computacional GAMS necesitó bastante más tiempo que para
los anteriores: 2407,76 segundos (algo más de 40 minutos), lo que puede considerarse
un tiempo de cálculo relativamente rápido considerando el tamaño del problema.
El valor de la FO asciende para este experimento a la cantidad de 4.966.077
Euros, más de 4 veces el importe total de la FO del caso computacional B y casi 8 veces
el valor total de la FO del test computacional A, lo que da una idea de la mayor
envergadura de la red ahora considerada. Lo que sí se vuelve a repetir es el que el
miembro de la FO que aporta la mayor parte del valor de la misma es el coste asociado
a los tiempos de viaje de los pasajeros con un importe de 3.750.392,25 Euros (75,52%
del total de la FO), cifra cuya explicación reside en el valor monetario del tiempo de
viaje (1 €/minuto para cada pasajero) y en el número total de personas que constituye
la demanda de la red de transporte (113.925 usuarios). Con estos datos, se puede ver
claramente que el tiempo promedio de viaje en la red es ligeramente superior a 30
minutos, que prácticamente equivaldría a un coste de este miembro de la FO de algo
menos de 3 millones y medio de Euros:
1€2� ∗ ������� ∗ 30 min∗ 113925 ������� = 3.417.750€
Valor de tiempo que puede considerarse aceptable para una red real teniendo
en cuenta la cantidad de rutas diferentes que toman los pasajeros, el número de
transbordos a realizar, el nivel de congestión de la red y otras incidencias que tienen
lugar.
Pruebas computacionales. Descripción de escenarios y resolución.
104
Fig. 2.8 Informe de resolución en archivo .lst para caso computacional C.
Otra nueva diferencia se presenta con respecto a los casos computacionales
anteriores en lo que se refiere al segundo miembro de la FO con más peso en el valor
final, y es que en esta ocasión dicho lugar corresponde a los costes de operación de los
ferrocarriles (en base a la distancia recorrida) en lugar de a la penalización por el
número de transbordos realizados. Dichos costes de operación alcanzan el importe de
604.176, 10 Euros (12,17% del total de la FO) y su mayor valor respecto a los otros
casos computacionales puede explicarse por el número de líneas desplegadas, la
mayor distancia cubierta por el recorrido de dichas líneas y también por el
consiguiente aumento del número de ferrocarriles que se desprende no sólo de los
valores de distancia y número de líneas, sino también por la alta frecuencia con la que
operan ciertas líneas (más adelante se evaluará en detalle) para dar servicio a una
demanda también mucho más numerosa para este test computacional.
El tercer componente de mayor peso de la FO es el ocupado por la penalización
debido al número de transbordos realizados con un valor de 598.100 Euros (12,04%
del valor de la FO), lo que supone que en proporción la mitad de los usuarios de la red
tiene que hacer un transbordo en su desplazamiento (52,5% de los pasajeros). Se trata
de un valor aproximadamente acorde con lo que ocurre en la realidad en redes de
cercanías o metro en grandes ciudades, donde comúnmente los pasajeros se ven
obligados a cambiar una o más veces de línea para efectuar su viaje. El alto valor
registrado por el miembro de la FO se explica por la penalización introducida por el
modelo (10 Euros por transbordo realizado) con el que se pretende asignar rutas
directas sin cambios de línea para el mayor número de pasajeros posible.
Pruebas computacionales. Descripción de escenarios y resolución.
105
Los dos miembros restantes de la FO son sin duda los que menor influencia
ejercen sobre el valor final, con aproximadamente un 0,27% del importe total de la FO
entre ambos. Por un lado, el componente que cuantifica los costes de amortización por
compra de material rodante asciende a la cantidad de 4.917,07 Euros (0,1% del total),
cifra nada desdeñable si se tiene en cuenta que dicho importe ha de ser abonado
durante cada hora durante todo el horizonte de amortización, que es de 50 años. Por
otra parte, el coste debido a la tripulación de la flota de las distintas líneas alcanza la
cantidad de 8.491,58 Euros (0,17% del valor total de la FO), cuantía bastante realista si
se considera que este valor corresponde a una sola hora de trabajo al día en una red
con 113.925 usuarios.
Fig. 2.9 Valor de varios miembros de la FO. Caso computacional C.
De nuevo, y al igual que con los casos computacionales anteriores, el modelo
logra atender a toda la demanda del sistema (todas las variables notadem(w) valen
cero), aunque debe indicarse que el hecho de que exista demanda no atendida
penaliza notoriamente el valor de la FO, así que el modelo prioriza atender a todos los
viajeros mientras le sea posible. En cuanto al flujo de pasajeros por los distintos arcos y
líneas, resulta complejo dar una descripción detallada debido al volumen de la red y la
cantidad de elementos que maneja.
No obstante, se puede ofrecer un resumen bastante representativo a este
efecto, y es que claramente el flujo de pasajeros es muy alto en los arcos que
conforman el centro de la red, entre los nodos 1 y 5, que es donde se concentra la
mayor cantidad de viajeros en movimiento, sobre todo en los arcos 1.2, 2.3 y 3.5 en
ambos sentidos (también en 2.4 y 4.5 en ambos sentidos, aunque en menor medida),
que participan en una amplísima cantidad de itinerarios para diversos pares. El resto
de los flujos son menores a los de los arcos señalados pero significativos en arcos como
5.6 o 5.21 que sirven de nexo entre el centro de la red y las zonas periféricas, si bien se
ve un claro descenso en la cuantía de los pasajeros en movimiento conforme más lejos
se esté de los arcos centrales.
Las línea que transporta la mayor cantidad de pasajeros es la línea 7, que como
se detallará más adelante opera con una frecuencia bastante alta y utiliza los trenes
del tamaño más grande permitido, dando servicio a la zona central de la red y llegando
a una gran cantidad de nodos fuera del centro (6, 7, 8, 9, 10, 30, 31 y 32).
Pruebas computacionales. Descripción de escenarios y resolución.
106
Otras líneas con flujos de pasajeros reseñables son la 2 (también atraviesa la
zona central y es la única que da servicio a partir del nodo 21), así como las líneas 3,4
(que tienen un recorrido extenso pasando por la concurrida zona central) y la línea 5,
que opera con una elevada frecuencia en la parte suroeste de la red (no comparte
tramo alguno con otra línea luego debe atender a la totalidad de la demanda que
circula por dicha zona). En el otro extremo se haya la línea 6, que sorprendentemente
no se ocupa de transportar ningún flujo de pasajeros debido a que da servicio a una
zona periférica con bajo movimiento de viajeros en la cual la demanda existente es
absorbida en su totalidad por las líneas 7 y 3, de frecuencia más alta con las cuales la
línea 6 comparte todo su trazado (salvo en el arco 1.30 en ambos sentidos en la cual
sólo comparte vía con la línea 3).
En lo referido a los transbordos cabe decir que se realizaron un total de 59.810,
de los cuales la amplísima mayoría tuvieron lugar en el nodo 5, punto de interconexión
de hasta 6 líneas que conecta el centro con diversas zonas de la periferia, si bien
también se produjeron un número significativo de cambios de línea (pero en una
proporción mucho menor) en los nodos 1 (conecta la zona norte con el centro, con
servicio de hasta 6 líneas), 2 (encrucijada entre las líneas 1,2 y 7 por un lado y las líneas
3 y 4 por otro) y 16 (punto de transbordo entre las líneas 4 y 5 en la zona sur de la red).
Por líneas la número 5 y la número 2 fueron aquellas desde las cuales se realizaron
mayores cantidades de transbordos, en el primer caso debido a la imposición de
cambiar de línea en el nodo 5 para llegar al centro desde el suroeste de la red o
viceversa y en el segundo caso por la misma circunstancia pero con la parte este de la
red.
Una vez comentados los resultados de flujos y transbordos se analiza a
continuación la asignación de headway para cada línea y su relación con respecto a la
compatibilidad de frecuencias en tramos compartidos. Concretamente, los headways y
frecuencias de cada línea son los siguientes:
• Línea 1: headway de 20 minutos entre trenes, que corresponde a una
frecuencia de paso de 3 ferrocarriles cada hora.
• Línea 2: headway de 5 minutos entre ferrocarriles, que implica una frecuencia
de paso de 12 trenes a la hora.
• Línea 3: headway de 10 minutos entre trenes, lo que equivale a una frecuencia
de 6 trenes cada hora.
• Línea 4: headway de 12 minutos entre ferrocarriles, por lo que tiene una
frecuencia de 5 trenes a la hora.
Pruebas computacionales. Descripción de escenarios y resolución.
107
• Línea 5: headway de 4 minutos entre trenes, a lo que corresponde una
frecuencia de 15 trenes a la hora.
• Línea 6: headway de 20 minutos entre ferrocarriles, que implica una frecuencia
de paso de 3 trenes cada hora.
• Línea 7: headway de 5 minutos entre trenes, que equivale a una frecuencia de
paso de 12 trenes cada hora.
Fig. 2.10 Valores de headways y frecuencias para las distintas líneas. Caso
computacional C.
Como se puede ver, existe diversidad en los valores de frecuencia para las
distintas líneas fruto de los recorridos de cada una, su demanda a atender y la
pertenencia o no a algún tramo compartido. La línea 5 (15 trenes a la hora) es la que
presenta el valor de frecuencia más elevado, posibilitado por el hecho de que no
participa en ningún tramo de vías compartido y que además da servicio a un volumen
de demanda importante considerando que no se encuentra en el centro de la red.
Además, dicha frecuencia le permite emplear trenes relativamente pequeños (5
vagones contando ambas locomotoras).
Las líneas 7 y 2 presentan el mismo valor de frecuencia (12 trenes por hora),
también alto aunque no tanto como se da para la línea 5, consecuencia de la elevada
demanda a la que dan servicio al pasar por el centro de la red. Estos valores altos de
frecuencia permiten mejorar el tiempo medio de viaje de la red, pero se ven acotados
inferiormente a ese headway de 5 minutos debido a que ambas líneas toman parte en
ciertos tramos de vía compartidos (un valor de headway inferior para cualquiera de las
líneas implicaría que debería de realizar todo su recorrido sin compartir línea, hecho
que tal y como está concebida la red sólo es posible para la línea 2).
Pruebas computacionales. Descripción de escenarios y resolución.
108
Las líneas 3 y 4 tienen valores de frecuencia intermedios y parecidos
consecuencia de su uso de común de tramos compartidos con un nivel de flujo de
pasajeros que no resulta excesivo. Los valores de frecuencia más bajos permitidos se
dan para el caso de las líneas 1 y 6 (3 trenes a la hora), aunque por distintos motivos;
en el caso de la primera línea se debe a que su frecuencia se ve penalizada para
permitir una mayor frecuencia de otras líneas (2 y 7) con las que debe ser compatible
en ciertos tramos mientras que para la línea 6 se trata de una cuestión de falta de
demanda absoluta, puesto que todo el posible flujo que podría atender es absorbido
por las líneas 7 y 3 con las que comparte su recorrido.
Sin duda, uno de los puntos de análisis más interesantes es el constituido por la
gestión que el modelo hace de los distintos tramos compartidos. En las siguientes
tablas (una para cada sentido) se recogen la asignación de líneas a vías en tramos
compartidos junto con el headway correspondiente de cada línea:
Tabla 2.6 Gestión de los tramos compartidos por distintas líneas. Caso
computacional C, sentido A.
Tramo (nº de vías disponibles)
Líneas asignadas a vía 1
(headways de
línea en minutos)
Líneas asignadas a vía 2
(headways de
línea en minutos)
Líneas asignadas a vía 3
(headways de
línea en minutos)
1-2 (3) Línea 7 (5) Línea 1 (20) Línea 2 (5)
Línea 3 (10) Línea 4 (12)
2-3 (2) Línea 1 (20) Línea 7 (5)
Línea 2 (5) -
3-5 (2) Línea 1 (20) Línea 7 (5)
Línea 2 (5) -
2-4 (1) Línea 3 (10) Línea 4 (12)
- -
4-5 (1) Línea 3 (10) Línea 4 (12)
- -
5-6 (1) Línea 1 (20) Línea 7 (5)
- -
6-7 (1) Línea 1 (20) Línea 7 (5)
- -
5-29 (1) Línea 3 (10) Línea 4 (12)
- -
1-19 (1) Línea 1 (20) Línea 7 (5)
- -
1-30 (1) Línea 3 (10) Línea 6 (20)
- -
30-31 (2) Línea 3 (10) Línea 6 (20) Línea 7 (5)
-
31-32 (2) Línea 3 (10) Línea 6 (20)
Línea 7 (5) -
Pruebas computacionales. Descripción de escenarios y resolución.
109
Tabla 2.7 Gestión de los tramos compartidos por distintas líneas. Caso
computacional C, sentido B.
Tramo (nº de vías disponibles)
Líneas asignadas a vía 1
(headways de
línea en minutos)
Líneas asignadas a vía 2
(headways de
línea en minutos)
Líneas asignadas a vía 3
(headways de
línea en minutos)
2-1 (3) Línea 3 (10) Línea 4 (12)
Línea 1 (20) Línea 2 (5)
Línea 7 (5)
3-2 (2) Línea 7 (5) Línea 1 (20) Línea 2 (5)
-
5-3 (2) Línea 7 (5) Línea 1 (20) Línea 2 (5)
-
4-2 (1) Línea 3 (10) Línea 4 (12)
- -
5-4 (1) Línea 3 (10) Línea 4 (12)
- -
6-5 (1) Línea 1 (20) Línea 7 (5)
- -
7-6 (1) Línea 1 (20) Línea 7 (5)
- -
29-5 (1) Línea 3 (10) Línea 4 (12)
- -
19-1 (1) Línea 1 (20) Línea 7 (5)
- -
30-1 (1) Línea 3 (10) Línea 6 (20)
- -
31-30 (2) Línea 3 (10) Línea 6 (20) Línea 7 (5)
-
32-31 (2) Línea 3 (10) Línea 6 (20) Línea 7 (5)
-
Como se puede ver la configuración de las combinaciones de líneas para las vías
de cada tramo compartido es parecida (sin tener en cuenta el número de vía por la que
circulan) en ambos sentidos con las salvedades del tramo 32.31, en el que la línea 6
cambia de vía para compartir el tramo con la línea 7 en lugar de hacerlo con la línea 3
como hacía en el sentido opuesto y de los tramos 5.3 y 3.2, en los cuales la línea 1 pasa
a compartir vía con la línea 7 en lugar de hacerlo con la línea 2 como hacía en el
sentido inverso. Por lo demás, todas las combinaciones de líneas siguen siendo las
mismas en todos los tramos compartidos con independencia del sentido. El tramo más
complejo es sin duda el configurado entre los nodos 1 y 2, en el cual 5 líneas deben
repartirse entre tres carriles disponibles. En dicho tramo las líneas 3 y 4 comparten una
de las tres vías del mismo modo que lo hacen las líneas 1 y 2 mientras que la línea 7
circula en solitario por la última vía libre (para ambos sentidos).
Pruebas computacionales. Descripción de escenarios y resolución.
110
A partir del nodo 2, en el sentido de circulación “A” (véase tabla 2.6) las líneas
3 y 4 siguen un trazado distinto de una sola vía a través del nodo 4 mientras que las
otras 3 líneas pasan por el nodo 3 usando dos vías. En el arco 2.3 la línea 1 se cambia
de vía para compartir el carril con la línea 7 hasta el nodo 5, combinación que resulta
equivalente desde el punto de vista de las frecuencias a la de usar de forma común
dicha vía con la línea 2. De hecho, en el sentido inverso para los arcos 3.2 y 5.3 la línea
que circula en solitario es la número 7 mientras que las líneas 1 y 2 comparten vía.
Fig. 2.11 Restricción “frequencies_compatibility”. Detalle de compatibilidad
en la asignación de vías y frecuencias para las líneas 1 y 2 en el tramo 1.2.
Caso computacional C.
Fuera de la zona central de la red las líneas 1 y 7 comparten la misma vía desde
la estación 5 hasta la número 7 y en el arco 19.1 (ambos sentidos) del mismo modo
que lo hacen las líneas 4 y 3 en el arco 5.29 (ambos sentidos), aunque esta última línea
también comparte vía con la número 6 en el arco 1.30 (ambos sentidos) y en el 31.32,
circulando en solitario a través de los tramos compartidos 31.30 (ambos sentidos) y
32.31. La línea 7 presenta probablemente el recorrido con más arcos de uso común
por varias líneas, aunque su elevada frecuencia hace que sólo sea compatible con las
líneas 1 y 6.
Nótese la gran influencia de los tramos compartidos sobre el valor de los
headways y especialmente sobre la línea 1, cuyo headway se ve maximizado para
compatibilizarse a la frecuencia de las líneas 2 y 7 con las que comparte vía en diversos
tramos. En las líneas 3 y 4 también se ve reflejado este hecho ya que ambas, de poder
circular completamente en solitario, reducirían drásticamente su frecuencia para
disminuir el tamaño de sus trenes.
Pruebas computacionales. Descripción de escenarios y resolución.
111
Y es precisamente un aspecto significativo el del número de vagones de los
trenes de las distintas líneas, ya que tanto la línea 2 como la línea 7 manejan trenes de
máxima longitud (10 vagones, capacidad de transporte de 2000 pasajeros por tren) a
pesar de tener ambas una frecuencia de paso de 12 trenes cada hora, de las más altas
de todo el sistema; lo que da una idea del gran volumen de demanda que ambas
manejan, pero de que también, al compartir vía con la línea 1, su frecuencia no puede
ser mayor a pesar de la disminución inherente en el tamaño de los trenes que se
produciría debido a la necesidad de compatibilidad en el uso de tramos compartidos.
Las líneas 1, 3 y 4 operan con trenes de tamaño menor (8 vagones para la línea
4 y 7 para las otras dos). La línea 1 (cuyo recorrido es casi paralelo al de la línea 7)
recorre el centro y básicamente atiende a aquellas personas que no pueden viajar por
la línea 7 debido a que ésta ya funciona al máximo de capacidad. Por otro lado, las
líneas 3 y 4 atienden un nivel de demanda similar, estando motivada la diferencia de
tamaño por las frecuencias de cada una.
Fig. 2.12 Número de vagones no autopropulsados por línea. Caso computacional C.
La línea 6 circula con trenes del menor tamaño posible (2 locomotoras) y con la
menor frecuencia de paso debido a que su posible cuota de demanda es “robada” por
las líneas 3 y 7 con las que comparte vía durante todo su recorrido, así que tanto el
tamaño de sus trenes como su frecuencia de paso están orientados a minimizar costes
y compatibilizar el uso compartido de vías. La línea 5 es en cambio el ejemplo de que el
hecho de no depender de tramos compartidos permite aumentar la frecuencia y
operar con trenes más pequeños para ahorrar en la compra de material rodante, pues
circula con frecuencias de paso de 15 trenes a la hora (la más alta de toda la red) y
emplea trenes de 5 vagones, el menor tamaño del sistema sino se tiene en cuenta la
línea 6.
Pruebas computacionales. Descripción de escenarios y resolución.
112
En cuanto a los tiempos promedio de viaje, el considerable tamaño de la red y
la diversidad de rutas que siguen los pasajeros para los distintos pares producen, como
cabía esperar, una disparidad considerable en dicho factor para cada par, abarcando
desde los 6 minutos y medio para el par número 44 que es prácticamente el
desplazamiento más rápido hasta los 79 minutos y medio que son necesarios para que
los viajeros del par 700 (uno de los más largos en tiempo) efectúen su viaje. Hay una
diferencia de 73 minutos entre ambos pares que puede ser simplemente indicativo del
gran tamaño de la red y de la diferencia entre la distancia a recorrer entre pares en el
caso de una red balanceada o bien producto de desequilibrios en el trazado de las
líneas.
De este modo, el promedio entre el tiempo empleado y la distancia a recorrer
para los trayectos correspondientes a cada par permite hacerse una idea del buen o
mal trazado de las líneas por la red. En el presente caso computacional los valores para
la gran mayoría de los pares rondan promedios que se encuentran entre 0,5 y 2
minutos por kilómetro aproximadamente, llegando en ocasiones a ser del orden de 3
minutos, pero muy raramente superando la barrera de los 4 minutos.
Fig. 2.13 Valores promedio tiempo/distancia extremos de los pares del sistema.
Caso computacional C.
La diferencia más extrema posiblemente se da entre los pares 44 y 799, que
tiempo un promedio tiempo/distancia de 0,210 y 6,6 minutos/kilómetro
respectivamente, por lo que se habla en proporción del orden de 6 minutos de
diferencia para recorrer un kilómetro. No obstante, se trata de una comparativa de
casos no demasiado frecuentes, por lo que en general se puede hablar de una
aproximación realista a lo que constituye una red de cercanías real (con algunas
salvedades concretas como la ya señalada con el par 700) en la que los
desplazamientos en las zonas de mayor concentración de pasajeros en trayecto suelen
ser más rápidos motivados por el mayor número de líneas y trenes de alta frecuencia
disponibles y por el contrario las zonas de la red más periféricas motivan viajes más
largos por la menor disponibilidad y frecuencia de los trenes.
Pruebas computacionales. Descripción de escenarios y resolución.
113
En cualquier caso, es un valor que indica cierto desequilibrio y que puede
mejorarse con una distribución distinta en el trazado de las líneas o modificando el
número de vías a compartir en ciertos tramos a fin de mejorar la frecuencia de ciertas
líneas.
Finalmente, se debe hacer referencia al importante ahorro de memoria y
recursos informáticos conseguidos mediante el empleo de los subconjuntos de
selección de variables y ecuaciones, que en este caso sí que es esencial para la
viabilidad del experimento así como su resolución en un tiempo admisible. Los datos
de ahorro de variables que se han tomado como patrón se indican a continuación:
Tabla 2.8 Ahorro de variables mediante el uso de subconjuntos. Caso
computacional C.
Variable Tamaño original
Tamaño reducido con los Sets
Ahorro
fijwl(i,j,w,l) 7257600 17319 7240281
fwl(w,l) 5600 4310 1290
trr(i,w,l,ll) 1411200 40933 1370267
Sólo para las variables patrón, se tiene un ahorro de más de 8 millones y medio
de variables, sin tener en cuenta tanto el resto de variables como las ecuaciones
implicadas en las restricciones que se ahorran con el uso de estos tipos de
subconjuntos, por lo que la utilidad y necesidad de la estrategia de determinar los k-
caminos más cortos y asociarlos a las variables mediante subconjuntos queda patente
con estos datos.
2.2.2 Descripción de los análisis de sensibilidad realizados
Una vez analizados los resultados de los diferentes experimentos, se considera
conveniente realizar dos análisis de sensibilidad diferentes; uno centrado en la
capacidad de gestión de demanda por parte de la red y otro modificando el miembro
con más peso de la FO de modo que se perciba y cuantifique la influencia del mismo.
Como anteriormente se comentó, estos análisis de sensibilidad se han realizado sobre
el caso computacional C, que al ser el más complejo y cercano a un caso real resulta a
priori el caso de estudio más interesante.
2.2.2.1 Análisis de sensibilidad: capacidad de absorción de demanda de la
red para el caso computacional C.
Se aborda ahora la exposición de los resultados y conclusiones del primero de
los dos análisis de sensibilidad a realizar. Básicamente lo que se ha hecho en este
análisis es aumentar gradualmente la demanda a gestionar por el modelo con el objeto
de ver cuál es el límite que el mismo puede manejar atendiendo a todos los pasajeros.
Pruebas computacionales. Descripción de escenarios y resolución.
114
Para ello se han realizado ejecuciones en las que el factor de escala de la
demanda (parámetro DemScala en el código implementado, de valor 5 en el caso
original) se ha ido incrementando en 0,5 unidades hasta conseguir que el modelo
comience a dejar demanda sin atender. Los resultados de dichas ejecuciones (5 en
total sin contar el caso computacional original) se muestran en las siguientes dos
tablas en las cuales se resume el valor de los elementos más significativos de la red:
Tabla 2.9 Resultados análisis computacional de absorción de demanda,
primera parte. Caso computacional C.
Factor\P.DemScala 5(CO*) 5,5 6
Resolución satisfactoria
del caso computacional Sí Sí Sí
Tiempo de resolución 2407,76 seg. 1350,38 seg. 1430,96 seg.
Demanda a atender*2 113.925 viajeros 125.318 viajeros 136.710 viajeros
Demanda no atendida 0 viajeros 0 viajeros 0 viajeros
Penalización económica
por demanda no atendida
0 € 0 € 0 €
Valor FO 4.966.077 € 5.416.616 € 5.880.504 €
M1-FO Coste Tiempo de Viaje
3.750.392,25 € 4.107.733,45 € 4.507.128,19 €
M2-FO Penalización por transbordos
598.100 € 657.910 € 717.720 €
M3-FO Coste operación ferrocarriles
604.176,10 € 637.516,29 € 641.472,99 €
M4-FO Coste
tripulaciones 8.491,58 € 8467,60 € 8.867,27 €
M5-FO Coste de amortización de compra
de material rodante
4.917,07 € 4.988,66 € 5.315,55 €
Headway de cada línea
L1-20 minutos L2-5 minutos
L3-10 minutos L4-12 minutos
L5-4 minutos L6-20 minutos L7-5 minutos
L1-20 minutos L2-4 minutos
L3-10 minutos L4-12 minutos
L5-5 minutos L6-20 minutos L7-5 minutos
L1-20 minutos L2-4 minutos
L3-10 minutos L4-12 minutos
L5-4 minutos L6-20 minutos L7-5 minutos
Tamaño de los ferrocarriles de cada
línea (incluso locomotoras)
L1-7 vagones L2-10 vagones L3-7vagones L4-8 vagones L5-5 vagones L6-2 vagones
L7-10 vagones
L1-8 vagones L2-8 vagones L3-7vagones L4-8 vagones L5-7 vagones L6-2 vagones
L7-10 vagones
L1-8 vagones L2-9 vagones L3-8 vagones L4-9 vagones L5-6 vagones L6-2 vagones
L7-10 vagones
Pruebas computacionales. Descripción de escenarios y resolución.
115
*Caso Original.*2La demanda a atender se ha redondeado media unidad hacia arriba
para el caso con DemScala=5,5 puesto que dicho factor de escala produce algunos
valores no enteros y ya que se trata de número de pasajeros no tiene sentido emplear
valores fraccionarios.
Tabla 2.10 Resultados análisis computacional de absorción de demanda,
segunda parte. Caso computacional C.
Factor\P.DemScala 6,5 7 7,5
Resolución satisfactoria del caso computacional
Sí Sí Sí
Tiempo de resolución 1285,49 seg. 1379,09 seg. 1136,31 seg.
Demanda a atender* 148102 viajeros 159.495 viajeros 170.888 viajeros
Demanda no atendida 0 viajeros 108 viajeros 830 viajeros
Penalización económica por demanda no
atendida
0 € 540 M€ 4150 M€
Valor FO 6.352.858 € 546.887.849 € 4.157.416.942 €
M1-FO Coste Tiempo de
Viaje 4.898.212,84 € 5.314.139,07 € 5.704.297,64 €
M2-FO Penalización por
transbordos 783.420 € 862.990 € 939.350 €
M3-FO Coste operación ferrocarriles
656.780,23 € 695.388,03 € 756.600,97 €
M4-FO Coste tripulaciones
8.867,27 € 9.493,42 € 10.362,02 €
M5-FO Coste de amortización de compra
de material rodante
5.577,66 € 5.838,48 € 6.331,37 €
Headway de cada línea
L1-20 minutos L2-4 minutos
L3-10 minutos L4-12 minutos
L5-4 minutos L6-20 minutos L7-5 minutos
L1-20 minutos L2-3 minutos
L3-10 minutos L4-12 minutos
L5-4 minutos L6-20 minutos L7-5 minutos
L1-20 minutos L2-3 minutos
L3-10 minutos L4-12 minutos
L5-3 minutos L6-12 minutos L7-5 minutos
Tamaño de los
ferrocarriles de cada línea (incluso locomotoras)
L1-10 vagones L2-10 vagones L3-8 vagones
L4-10 vagones L5-7 vagones L6-2 vagones
L7-10 vagones
L1-10 vagones L2-8 vagones L3-9 vagones
L4-10 vagones L5-7 vagones L6-2 vagones
L7-10 vagones
L1-10 vagones L2-9 vagones
L3-10 vagones L4-10 vagones L5-6 vagones L6-2 vagones
L7-10 vagones
*La demanda a atender se ha redondeado media unidad hacia arriba para los casos
con DemScala=5,5 y DemScala=7,5 puesto que dichos factores de escala producen
algunos valores no enteros y ya que se trata de número de pasajeros no tiene sentido
emplear valores fraccionarios.
Pruebas computacionales. Descripción de escenarios y resolución.
116
A la vista de estos resultados pueden extraerse un buen número de
conclusiones, pero quizá la más interesante corresponde al límite de absorción de
demanda de la red, que consigue atender a la totalidad de los pasajeros hasta la
penúltima ejecución realizada, punto en el que el factor de escala de demanda vale 7 y
el modelo se ve forzado a dejar de atender a un grupo de 108 pasajeros del par 709
(origen en nodo 34 y destino en nodo 7). Esto significa que la capacidad global de
atención de demanda (sin dejar de atender a ningún viajero) para esta red y según el
modelo propuesto es de algo más de 159.000 pasajeros, cifra nada desdeñable si se
tienen en cuenta que la capacidad máxima de un tren del mayor tamaño permitido es
de 2000 personas.
Evidentemente si se siguen empleando valores por encima de DemScala=7 se
provoca un continuo aumento de la demanda no atendida debido a la incapacidad del
modelo de seguir transportando viajeros en ciertos pares debido a la morfología de la
red (de una demanda global de 170.888 pasajeros 830 personas [pares 709 y 730] se
quedaron sin viajar según la ejecución con factor de escala de 7,5), aunque puede
verse claramente que aún existe capacidad para gestionar más demanda en muchos
otros pares ya que en general el número de pasajeros atendidos ha crecido también.
Queda asimismo patente la reasignación de frecuencias de las líneas,
(usualmente a la baja) y el aumento constante del tamaño de los ferrocarriles con cada
nueva ejecución a fin de intentar atender a toda la nueva demanda que va
apareciendo (salvo en algunos casos aislados en el que se produce una bajada de
frecuencia que permite reducir el número de vagones no autopropulsados en una
determinada línea, como por ejemplo ocurre con la línea 2 en las ejecuciones con
DemScala=6,5 y DemScala=7).
Otro de los aspectos que se puede observar es el crecimiento de todos los
costes de la red a medida que se va introduciendo más demanda, aunque mención
especial merecen los correspondientes al tiempo de viaje de los pasajeros y a la
penalización por transbordos que, al depender fuertemente de la demanda se ven
aumentados en mucha mayor proporción de lo que ocurre con el resto de las partidas,
las cuales al estar ligadas mayormente al número, frecuencia y recorrido de los
ferrocarriles experimentan aumentos bastante más moderados, sobre todo en los
costes debidos a la tripulación de los trenes y al coste de amortización por compra de
material rodante, que crecen en importes de aproximadamente 2.000 Euros para el
primero y 1.500 Euros para el segundo entre las ejecuciones correspondientes al caso
computacional original y aquella en la que más se fuerza al sistema, con DemScala=7,5.
Pruebas computacionales. Descripción de escenarios y resolución.
117
Evidentemente si se siguiera aumentando de forma global el número de
pasajeros con factores de escala mayores el valor de la FO se dispararía muchísimo
más teniendo en cuenta que la red, en la última de las ejecuciones realizadas apenas
dispone de capacidad de absorción de demanda, y la que posee es sólo para ciertos
pares. Debe recordarse que se introduce una muy fuerte penalización por cada
pasajero que se queda sin atender (5 millones de Euros) para forzar al modelo a que
atienda a la mayor cantidad de demanda posible, siendo esta la principal razón de que
la FO alcance unos valores tan desorbitados.
De hecho, cabe esperar que llegue un punto en el cual la red esté tan saturada
que no pueda aumentar el tamaño ni el número de los trenes, ni tampoco alterar los
headways para atender más demanda, por lo que todos los miembros de la FO
quedarán aproximadamente fijados en un valor máximo a pesar de que el valor de la
FO siga creciendo por el efecto de la penalización de seguir dejando demanda sin
atender.
Puede apreciarse que los términos correspondientes a costes por tripulación y
amortización debido a la compra de material rodante se mantienen casi constantes en
las ejecuciones con factor de escala de 6 y 6,5 mientras que para 7 vuelven a crecer de
forma moderada. Esto se debe a que cuando se alcanza la barrera de los 140.000
pasajeros aproximadamente de demanda global; la red, tal y como está concebida,
apenas puede apurar el margen del cual dispone en lo referente al tamaño máximo de
los ferrocarriles y a las posibilidades de reducción de frecuencias para atender a unos
pocos viajeros más, pero prácticamente se encuentra al límite de su capacidad de
transporte, como queda evidenciado cuando aparece demanda no atendida al
aumentar el factor de escala a 7.
Queda asimismo patente el momento en el cual el modelo incluso se ve forzado
a emplear también la línea 6 para transportar pasajeros, que apenas había atendido a
una ínfima cuota de demanda en la ejecución anterior. Esta entrada en servicio de
dicha línea (nótese la disminución de su headway) es lo que provoca el aumento más
destacado en la última ejecución de los costes debidos a operación de los ferrocarriles,
tripulaciones y amortización por la compra de material rodante. No obstante, de seguir
incrementando la demanda a atender llegará el punto en el que incluso dicha línea
también se vea saturada, con lo que definitivamente el modelo será incapaz de seguir
aumentando el número de pasajeros atendidos.
Pruebas computacionales. Descripción de escenarios y resolución.
118
2.2.2.2 Análisis de sensibilidad: efecto de la disminución y aumento del
peso monetario del tiempo de viaje de los pasajeros para la red del caso
computacional C.
Este segundo análisis de sensibilidad está encaminado a comprobar el efecto
que tiene un cambio sobre el factor que regula el peso monetario del tiempo de viaje
de los pasajeros sobre el desempeño del modelo. Como se ha visto en los resultados,
el componente de la FO que cuantifica el coste debido al tiempo de viaje de los
pasajeros aporta aproximadamente el 75% del valor global de la FO para todos los
casos computacionales, de ahí la importancia en conocer el efecto del factor referido.
El análisis de sensibilidad consta de 4 ejecuciones en las que se varía el peso
monetario del tiempo de viaje (parámetro theta_one en GAMS), dos de ellas al alza, a
los valores de 1.25 y 1.5, y las otras dos a la baja con valores de 0,75 y 0,5. Pueden
extraerse interesantes conclusiones a partir de dichas ejecuciones, cuyos resultados se
muestran resumidos en los valores de las variables más representativas en las
siguientes tablas:
Tabla 2.11 Resultados análisis computacional para la modificación del peso
monetario correspondiente a tiempo de viaje, primera parte. Caso computacional C.
Factor\Theta_one 0,5 0,75 1 (CO)*
Resolución satisfactoria del caso computacional
Sí Sí Sí
Tiempo de resolución 1.290,65 seg. 1.181,37seg. 2.407,76 seg.
Valor FO 3.074.158 € 4.026.427 € 4.966.077 €
M1-FO Coste Tiempo de Viaje
1.919.456,23 € 2.826.740,32 € 3.750.392,25 €
M2-FO Penalización por transbordos
596.300 € 598.100 € 598.100 €
M3-FO Coste operación ferrocarriles
546.352,33 € 588.589,10 € 604.176,10 €
M4-FO Coste tripulaciones
7.468,44 € 8.091,92 € 8.491,58 €
M5-FO Coste de
amortización de compra de material rodante
4.581 € 4.905,66 € 4.917,07 €
Headway de cada línea
L1-20 minutos L2-5 minutos
L3-10 minutos L4-12 minutos L5-6 minutos
L6-20 minutos L7-6 minutos
L1-20 minutos L2-5 minutos
L3-10 minutos L4-12 minutos L5-5 minutos
L6-20 minutos L7-5 minutos
L1-20 minutos L2-5 minutos L3-10minutos L4-12 minutos L5-4 minutos
L6-20 minutos L7-5 minutos
Pruebas computacionales. Descripción de escenarios y resolución.
119
Tabla 2.11 (Continuación) Resultados análisis computacional para la
modificación del peso monetario correspondiente a tiempo de viaje, primera parte.
Caso computacional C.
Tamaño de los ferrocarriles de cada
línea (incluso locomotoras)
L1-7 vagones L2-10 vagones L3-7 vagones
L4-8 vagones L5-8 vagones L6-2 vagones
L7-10 vagones
L1-7 vagones L2-10 vagones L3-7 vagones
L4-8 vagones L5-7 vagones L6-2 vagones
L7-10 vagones
L1-7 vagones L2-10 vagones L3-7vagones
L4-8 vagones L5-5 vagones L6-2 vagones
L7-10 vagones
*Caso Original
Tabla 2.12 Resultados análisis computacional para la modificación del peso
monetario correspondiente a tiempo de viaje, segunda parte. Caso computacional C.
Factor\Theta_one 1,25 1,5
Resolución satisfactoria del caso computacional
Sí Sí
Tiempo de resolución 1956,94 seg. 2.085,02 seg.
Valor FO 5.896.231 € 6.828.645 €
M1-FO Coste Tiempo de Viaje
4.662.068,98 € 5.594.482,98 €
M2-FO Penalización por transbordos
598.100 € 598.100 €
M3-FO Coste operación
ferrocarriles 622.209,06 € 622.209,06 €
M4-FO Coste tripulaciones
8.867,27 € 8.867,27 €
M5-FO Coste de amortización de compra
de material rodante
4.985,69 € 4.985,69 €
Headway de cada línea
L1-20 minutos L2-4 minutos
L3-10 minutos L4-12 minutos L5-4 minutos
L6-20 minutos L7-5 minutos
L1-20 minutos L2-4 minutos
L3-10 minutos L4-12 minutos L5-4 minutos
L6-20 minutos L7-5 minutos
Tamaño de los ferrocarriles de cada
línea (incluso locomotoras)
L1-7 vagones L2-8 vagones L3-7 vagones L4-8 vagones L5-5 vagones L6-2 vagones
L7-10 vagones
L1-7 vagones L2-8 vagones L3-7 vagones L4-8 vagones L5-5 vagones L6-2 vagones
L7-10 vagones
Pruebas computacionales. Descripción de escenarios y resolución.
120
A la vista de los resultados obtenidos, queda demostrada la importante
influencia de dicho factor sobre el valor global de la FO y otros aspectos de la red tales
como el tamaño de los trenes de cada una de las líneas o el headway de las mismas.
El efecto más evidente del cambio de factor es el aumento o disminución del
componente de la FO que cuantifica los costes asociados a los tiempos de viaje con el
respectivo cambio al alza o a la baja del parámetro theta_one, ya que al ser el
miembro de la FO con mayor peso en la misma le provoca notables cambios de valor
como puede verse en cada una de las ejecuciones, en las que una variación de 0,25
€/min de theta_one llega al punto de suponer un aproximadamente un millón de Euros
de diferencia para la FO.
Se ha comentado el indiscutible y previsible efecto que tiene la variación del
factor estudiado sobre la FO y en concreto sobre el primer miembro de ésta, pero no
es éste el único componente de la FO que se ve afectado, si bien es cierto que la
influencia ejercida sobre los demás es muchísimo menor. De hecho, el coste debido a
la penalización por transbordos permanece constante durante todas las ejecuciones
exceptuando a la realizada para el valor más reducido de theta_one (0,5 €/min y
pasajero), de lo que se deduce que no hay cambios significativos en los aspectos que
pudiesen afectar al número de transbordos realizados en el sistema.
Para los otros tres miembros restantes de la FO sí que se producen cambios con
cada nueva ejecución, con la excepción de la última en la permanecen constantes con
respecto al experimento con theta_one igual a 1,25 Euros por minuto y pasajero, por
lo que todos los valores de los componentes de la FO para dichos casos de análisis son
idénticos salvo aquel que cuantifica el coste por los tiempos de viaje que se ve alterado
por el cambio de factor de forma directa. En cualquier caso, para el resto de las
ejecuciones se puede observar como los costes por operación de los ferrocarriles,
tripulación y amortización por la compra de material rodante experimentan en general
un ligero ascenso si el factor analizado se modifica al alza y al contrario si este es
modificado a la baja. Esto se explica por la mayor o menor influencia de conseguir un
mejor tiempo de viaje para los pasajeros:
• Si theta_one crece, el peso de los tiempos de viaje sobre la FO aumenta, de
forma que el modelo tiende a efectuar ligeras modificaciones aumentando las
frecuencias de paso de los trenes de algunas líneas para lograr un
desplazamiento más rápido de la demanda (nótese como para varias
ejecuciones la suma de los headways disminuye conforme mayor es
theta_one), con lo que se implementa un mayor número de ferrocarriles por
línea, e incluso en ocasiones se observa como las líneas también modifican el
tamaño de sus trenes en función del cambio de frecuencia realizado (disminuye
el número de vagones con el aumento de la frecuencia de paso).
Pruebas computacionales. Descripción de escenarios y resolución.
121
Estas modificaciones requieren de una flota de trenes algo mayor, que a su vez
justifica aumentos en los costes de tripulación, operación y compra de material
rodante aunque a cambio se consigue un beneficio más que compensatorio con
la reducción de los costes por tiempo de viaje.
• Del mismo modo, si theta_one se hace más pequeño la importancia coste del
tiempo de viaje con respecto al resto de los componentes de la FO también
disminuye, por lo que a efectos de gasto global resulta ventajoso eliminar
algunos trenes por disminución de frecuencias de paso de alguna línea para
ahorrar costes por compra de material rodante, tripulación u operación de los
trenes. Debe tenerse en cuenta que aunque esto produzca un ligero aumento
del tiempo medio de viaje, son 3 los componentes de la FO los que se ven
beneficiados.
122
Conclusiones
A la vista de los resultados obtenidos, puede concluirse el potencial del modelo
planteado para la gestión de redes de tránsito rápido por ferrocarril. Esto queda
patente si se atiende sobre todo a los resultados de ejecución del caso computacional
C (que constituye aproximadamente el 50% de la red de cercanías real de Madrid), en
el que se obtienen datos bastante coherentes de frecuencias, capacidades, flujos de
pasajeros, transbordos y costes.
No obstante, se puede ver claramente como el uso compartido de tramos de vías
por varias líneas, que constituye un ahorro importante en de construcción
infraestructuras (vías, ampliación de estaciones, etc) y aporta una serie de ventajas
organizativas, afecta notablemente a la frecuencia de las líneas implicadas,
observándose por parte del modelo 2 modos de asignación de frecuencias para dichas
líneas:
• “Sacrificar” una de las líneas reduciendo al mínimo su frecuencia de tal
forma que la otra línea puede incrementar la suya hasta el máximo de
compatibilidad en tramos compartidos (líneas 1 y 7 en caso de cálculo C).
• Utilizar frecuencias similares de 5 o 6 trenes a la hora para ambas líneas,
que es la combinación con mayor frecuencia sin “sacrificar” a ninguna de
las líneas implicadas (líneas 3 y 4 en caso computacional C).
De esto se deduce la importancia que tiene la definición de las rutas de las líneas
y la conveniencia de analizar en profundidad si dos líneas deben o no de circular por
una misma vía, aunque exista la clara posibilidad de uso compartido, pues o bien una
de las líneas reducirá mucho su frecuencia, con la penalización correspondiente en los
promedios tiempo/distancia para los viajeros que usen dicha línea, o bien se dará la
imposibilidad de circular con frecuencias superiores a los 6 trenes a la hora.
Los costes de operación, mantenimiento y amortización por la compra de
material rodante se ven muy superados en cuantía para todos los experimentos por los
costes asociados al desplazamiento de los pasajeros (tiempo de viaje, transbordos y
demanda no atendida), lo cual viene determinado por el peso que se le ha dado en el
modelo a estos gastos asociados al comportamiento de la demanda en la red, que está
en consonancia con la premisa existente de lograr que todos los pasajeros sean
atendidos realizando su viaje de forma rápida y con el menor número de transbordos
posibles.
Conclusiones
123
Este aspecto puede regularse modificando los parámetros theta_one y
theta_two que controlan respectivamente el peso monetario por tiempo de viaje y el
peso monetario debido a los transbordos realizados así como la penalización por
demanda no atendida en la función objetivo; todo ello según se considere más o
menos relevante el desempeño del modelo en lo referente al movimiento de los
pasajeros de la red con respecto a los otros costes asociados al funcionamiento de la
misma.
En lo referente a la actuación desde el punto de vista informático, cabe destacar
el buen rendimiento del modelo con el solver Alpha ECP, con el cual se ha conseguido
resolver la totalidad de los experimentos y análisis de sensibilidad en plazos de tiempo
bastante cortos (del orden de 25 minutos normalmente, si bien en algún caso aislado
se ha necesitado un máximo de 40 minutos). El resultado con los otros dos solvers
contemplados en el presente proyecto (CoinBonMin y SBB) no ha sido tan positivo
puesto que ninguno ha logrado resolver el caso computacional más complejo, por lo
que resultaría interesante experimentar con un conjunto más amplio de solvers e
incluso otro software distinto a GAMS a fin de evaluar el comportamiento del modelo
y las posibles adaptaciones que se podrían hacer del mismo para hacerlo más versátil.
Por otro lado, los análisis de sensibilidad permiten apreciar como el modelo
presenta un comportamiento lógico frente a modificaciones importantes; en el análisis
de absorción de demanda, el modelo gestiona adecuadamente la disminución de
frecuencias y aumento de las capacidades de los trenes para maximizar la demanda
atendida, logrando en el caso computacional C absorber aumentos de casi el 40% de
la demanda inicial existente sin verse saturado. El análisis de sensibilidad
correspondiente a la modificación del peso monetario del tiempo de viaje permite
comprobar cómo el modelo prioriza el gasto según el valor del tiempo de los viajeros,
de modo que si éste es alto la red incurre en mayores gastos de operación a fin de
reducir los tiempos de viaje, procediendo en caso contrario si se produce una
disminución en el valor del tiempo de viaje.
Finalmente, queda patente la necesidad de reducir el tamaño del problema a
considerar cuando el modelo ha de gestionar redes de tamaño y complejidad
importantes, pues como se ha visto para el caso computacional C, la estrategia de
ahorro en el uso de variables y ecuaciones ha permitido evitar el empleo innecesario
de millones de variables, parámetros, y ecuaciones que hubiesen acarreado a su vez
millones de cálculos sin efecto alguno en la resolución del caso computacional, lo que
ha permitido no sólo manejar tiempos de resolución más cortos y ahorrar recursos
informáticos, sino también obtener una solución de gran exactitud ya, que se evita la
inclusión de valores residuales de variables y ecuaciones derivados de cálculos
innecesarios.
124
Bibliografía
• Brännlund, U., Lindberg, P. O., Nou, A., & Nilsson, J.-E. (1998). Railway
Timetabling using Lagrangian Relaxation. Transportation Science , 34(4), 358-
369.
• Budai-Balke, G. (2009). Operations Research Models for Scheduling Railway
Infrastructure Maintenance. Rotterdam: Tinbergen Institute (Erasmus
University Rotterdam).
• Cadarso, L., & Marín, Á. (2012). Integration of timetable planning and rolling
stock in rapid transit networks. Annals of Operation Research , 199, 113-135.
• Caprara, A., Kroon, L., Monaci, M., Peeters, M., & Toth, P. (2007). Passenger
Railway Optimization. In transportation, Handbooks in Operations Research
and Management Science , 14, 129-187.
• Carraresi, P., Malucelli, F., & Pallottino, S. (1996). Regional mass transit
assignment with resource constraints. Transportation Research Part B:
Methodological , 20(2), 81-98.
• Chang, Y.-H., Yeh, C.-H., & Shen, C.-C. (2000). A multiobjective model for
passenger train services planning: application to Taiwan´s high speed rail line.
Transportation research Part B , 91-106.
• Claessens, M., Van Dijk, N., & Zwaneveld, P. (1998). Cost optimal allocation of
rail passenger lines. European Journal of Operational Research , 110(3), 474-
489.
• CoinBonMin. Fundación COIN-OR, Inc. (s.f.).http://www.coin-
or.org/foundation.html
• Deng, L., Zeng, Q., Zhou, W., & Shi, F. (2014). The effect of train formation
lenght and service frequency on the determination of train schedules. Journal
of Rail and Rapid Transit , 378-388.
• GAMS Development Corporation. General Algebraic Modeling System. (s.f.).
http://www.gams.com/
Bibliografía
125
• Hu, S.-R., & Liu, C.-T. (2014). Optimizing Headways for Mass Rapid Transit
Services. Journal of Transportation Engineering , 140(11), 04014053.
• Kroon, L., & Peeters. (2003). A variable trip time model for cyclic railway
timetabling. Transportation Science , 37, 198-212.
• Maróti, G. (2006). Operations research models for railway rolling stock
planning. Technische Universiteit Eindhoven.
• Martínez, F. J., Garzón, A., Melián, B., Mesa, J. A., Moreno, J. A., & Ortega, F. A.
(2005). Metaheurística GRASP para el diseño de redes de tránsito rápido. IV
Congreso Español sobre Metaheurísticas, Algoritmos Evolutivos y Bioinspirados
(MAEB´05), 601-608. Granada (España).
• McCarl, A, B., Meeraus, A., Eijk, v. d., Paul, Bussieck, M., y otros. (2008). McCarl
GAMS User Guide v 22.9. Texas: GAMS Development Corporation.
• Mintzberg, H., Quinn, J. B., & Voyer, J. (1997). El proceso estratégico:
conceptos, contextos y casos. Prentice-Hall.
• Nachtigall, K., & Voget, S. (1996). A genetic algorithm approach to periodic
railway synchronization. Computers & Operation Research , 23, 453-463.
• Newell, A., Simon, H., & Shaw, J. (1959). Report on a general problem-solving
program. Proceedings of the International Conference on Information
Processing, 256-264.
• Orro, A. (2006). Planificación de sistemas ferroviarios metropolitanos.
Ingeniería y territorio , 76, 18-23.
• Porter, M. E. (1980). Competitive Strategy: Techniques for Analyzing Industries
and Competitors. Free Press.
• Rosenthal, R. E. (2008). A GAMS Tutorial. Monterey: Naval Post graduate
School.
• Sánchez Borrás, M. (2012). Agenda estratégica de investigación del sector
ferroviario: visión 2030. Plataforma Tecnológica Ferroviaria Española.
• Schöbel, A. (2011). Line planning in public transportation: models and methods.
OR Spectrum , 34(3), 491-510.
Bibliografía
126
• Schöbel, A., & Scholl, S. (2006). Line planning with minimal traveling time. 5th
Workshop on Algorithmic Methods and Models for Optimization of Railways,
ATMOS 2005.
• Serafini, P., & Ukovich, W. (1989). A mathematical model for periodic event
scheduling problems. Journal on Discrete Mathematics , 2, 550-581.
• Yen, J. Y. (1971). Finding the k Shortest Loopless Paths in a Network.
Management Science , 17 (11), 712-716.
127
Anexo: Códigos de Programación en GAMS
• Lanzador caso computacional A, “Lanzador 8 nodos 10 pares.gms”. Scalar starttime comienza a contar el cpu time ;
starttime=jnow; *Cargando ejemplo $include Ejemplo 8 nodos 10 pares.gms *Cargando definicion de variables $include Network Loading Model 2 Variables.gms
*cargando restricciones $include Network Loading Model 2 Constraints.gms **************************** Preparando modelo para resolver bucle cambiando * alfa y sacar pareto cu rva set values_alfa /1*10/ ;
**************************** definicion del model o model networkloading /all/ ;
*opciones OPTION RESLIM=50000; Option Limrow=10; OPTION ITERLIM=999999;
****************************** SOLVING Scalar starttime comienza a contar el cpu time ;
starttime=jnow; solve networkloading using minlp minimizing TotFO;
Scalar runtime calcula el tiempo de cómputo en segundos ;
runtime = (jnow - starttime)*24*3600;
******** Cargando resultados de forma cómoda parameter fwlij(w,l,i,j),trwilll(w,i,l,ll);
fwlij(w,l,i,j)=fijwl.l(i,j,w,l); trwilll(w,i,l,ll)=trr.l(i,w,l,ll); Scalars
VarOperCost valor operación ferrocarriles CrewOperCost coste de la tripulación ; Parameters
TotTransfromline(l) transbordos totales desde la línea l AverWaiTime(w) tiempor promedio de viaje par w RollBuyCost valor de compra de equipos Prompartiempdis(w) relación tiempo-distancia para el par w ; CrewOperCost=theta_four* sum(l,2*llenght(l)*(frvar.l(l)/Mean_speed)); VarOperCost= sum(l,2*llenght(l)*(frvar.l(l))*(ckm_loc+ckm_carr*(Nv. l(l)
+1)));
Anexo: Códigos de programación en GAMS
128
TotTransfromline(l)= sum(ll$( ord(l) <> ord(ll)), sum(w$(wlin(w,l) and wlin(w,ll)), sum(i$(willl(i,w,l,ll)),trr.l(i,w,l,ll) )));
AverWaiTime(w)=(1/g(w))*( sum(l$wlin(w,l), sum(ij(i,j)$(wijl(i,j,w,l)),fijwl.l(i,j,w,l)*(60/Mean_ speed)*dis(i,j))+ (fwl.l(w,l)*hdwvar.l(l)/2)+ sum(i, sum(ll$( ord(l) <> ord(ll) and
(willl(i,w,l,ll))),trr.l(i,w,l,ll)*(hdwvar.l(ll)/2) ))));
RollBuyCost=(1E6/(Horizonte*365*24))* sum(l,2*llenght(l)*(frvar.l(l)/Me
an_speed)*(2*cost_loc+ nv.l(l)*cost_carr)); Prompartiempdis(w)= AverWaiTime(w)/llenghtpar(w);
******* Generando displays de seguimiento display runtime; option fwlij:0:2:2; option trwilll:0:2:2; display fwlij,trwilll; Display TotTransfromline,AverWaiTime,VarOperCost,CrewOperC ost,
RollBuyCost,Prompartiempdis;
display demanda; display ls; display st; display g; display pair;
Anexo: Códigos de programación en GAMS
129
• Lanzador caso computacional B, “Lanzador 12 nodos 56 pares.gms”. Scalar starttime comienza a contar el cpu time ;
starttime=jnow; *Cargando ejemplo $include Ejemplo 12 nodos 56 pares.gms *Cargando definicion de variables $include Network Loading Model 2 Variables.gms *cargando restricciones $include Network Loading Model 2 Constraints.gms **************************** Preparando modelo para resolver bucle cambiando * alfa y sacar pareto cu rva set values_alfa /1*10/ ;
**************************** definicion del model o model networkloading /all/ ;
*opciones OPTION RESLIM=50200; Option Limrow=10; OPTION ITERLIM=999999;
****************************** SOLVING Scalar starttime comienza a contar el cpu time ;
starttime=jnow; solve networkloading using minlp minimizing TotFO;
Scalar runtime calcula el tiempo de cómputo en segundos ;
runtime = (jnow - starttime)*24*3600; ******** Cargando resultados de forma cómoda parameter fwlij(w,l,i,j),trwilll(w,i,l,ll);
fwlij(w,l,i,j)=fijwl.l(i,j,w,l); trwilll(w,i,l,ll)=trr.l(i,w,l,ll); Scalars
VarOperCost coste de operación de los ferrocarriles CrewOperCost coste de la tripulación ; Parameters
TotTransfromline(l) transbordos totales desde la línea l AverWaiTime(w) tiempo promedio de viaje para el par w RollBuyCost valor de compra de equipos Prompartiempdis(w) relación tiempo-distancia para el par w ; CrewOperCost=theta_four* sum(l,2*llenght(l)*(frvar.l(l)/Mean_speed));
VarOperCost= sum(l,2*llenght(l)*(frvar.l(l))*(ckm_loc+ckm_carr*(Nv. l(l)
+1)));
Anexo: Códigos de programación en GAMS
130
TotTransfromline(l)= sum(ll$( ord(l) <> ord(ll)), sum(w$(wlin(w,l) and wlin(w,ll)), sum(i$(willl(i,w,l,ll)),trr.l(i,w,l,ll) )));
AverWaiTime(w)=(1/g(w))*( sum(l$wlin(w,l), sum(ij(i,j)$(wijl(i,j,w,l)),fijwl.l(i,j,w,l)*(60/Mean_ speed)*dis(i,j))+(fwl.l(w,l)*hdwvar.l(l)/2)+ sum(i, sum(ll$( ord(l) <> ord(ll) and
(willl(i,w,l,ll))),trr.l(i,w,l,ll)*(hdwvar.l(ll)/2) ))));
RollBuyCost=(1E6/(Horizonte*365*24))* sum(l,2*llenght(l)*(frvar.l(l)/Me
an_speed)*(2*cost_loc+ nv.l(l)*cost_carr)); Prompartiempdis(w)= AverWaiTime(w)/llenghtpar(w);
******* Generando displays de seguimiento display runtime; option fwlij:0:2:2; option trwilll:0:2:2; display fwlij,trwilll; Display TotTransfromline,AverWaiTime,VarOperCost,CrewOperC ost,
RollBuyCost,Prompartiempdis; display demanda; display ls; display st; display g; display pair;
Anexo: Códigos de programación en GAMS
131
• Lanzador Caso computacional C, “Lanzador EJEMPLO DE Madrid completo
con demanda desatendida 800 W.gms”. Scalar starttime comienza a contar el cpu time ;
starttime=jnow;
*Cargando ejemplo $include Ejemplo REDUC Madrid Model 2 800W.gms
*Cargando definicion de variables $include Network Loading Model 2 Variables.gms
*cargando restricciones $include Network Loading Model 2 Constraints.gms
**************************** Preparando modelo para resolver bucle cambiando * alfa y sacar pareto cu rva set values_alfa /1*10/ ;
**************************** definicion del model o model networkloading /all/ ;
*opciones OPTION RESLIM=50000; Option Limrow=10; OPTION ITERLIM=999999;
****************************** SOLVING Scalar starttime comienza a contar el cpu time ;
starttime=jnow; solve networkloading using minlp minimizing TotFO;
Scalar runtime calcula el tiempo de cómputo en segundos ;
runtime = (jnow - starttime)*24*3600; ******** Cargando resultados de forma cómoda parameter fwlij(w,l,i,j),trwilll(w,i,l,ll);
fwlij(w,l,i,j)=fijwl.l(i,j,w,l); trwilll(w,i,l,ll)=trr.l(i,w,l,ll); Scalars
VarOperCost coste de operación de los ferrocarriles CrewOperCost coste de la tripulación ; Parameters
TotTransfromline(l) número total de transbordos desde la línea l AverWaiTime(w) tiempo promedio de viaje de los pasajeros del par w RollBuyCost valor de compra de equipos Prompartiempdis(w) relación tiempo-distancia para el par w ; CrewOperCost=theta_four* sum(l,2*llenght(l)*(frvar.l(l)/Mean_speed));
Anexo: Códigos de programación en GAMS
132
VarOperCost= sum(l,2*llenght(l)*(frvar.l(l))*(ckm_loc+ckm_carr*(Nv. l(l)
+1))); TotTransfromline(l)= sum(ll$( ord(l) <> ord(ll)), sum(w$(wlin(w,l) and wlin(w,ll)), sum(i$(willl(i,w,l,ll)),trr.l(i,w,l,ll) )));
AverWaiTime(w)=(1/g(w))*( sum(l$wlin(w,l), sum(ij(i,j)$(wijl(i,j,w,l)),fijwl.l(i,j,w,l)*(60/Mean_ speed)*dis(i,j))+(fwl.l(w,l)*hdwvar.l(l)/2)+ sum(i, sum(ll$( ord(l) <> ord(ll) and
(willl(i,w,l,ll))),trr.l(i,w,l,ll)*(hdwvar.l(ll)/2) ))));
RollBuyCost=(1E6/(Horizonte*365*24))* sum(l,2*llenght(l)*(frvar.l(l)/Me
an_speed)*(2*cost_loc+ nv.l(l)*cost_carr)); Prompartiempdis(w)= AverWaiTime(w)/llenghtpar(w);
******* Generando displays de seguimiento display runtime; option fwlij:0:2:2; option trwilll:0:2:2; display fwlij,trwilll; Display TotTransfromline,AverWaiTime,VarOperCost,RollBuyCo st,
CrewOperCost,Prompartiempdis; display demanda; display ls; display st; display g; display pair;
Anexo: Códigos de programación en GAMS
133
• Archivo de datos del caso computacional A, “Ejemplo 8 nodos 10 pares.gms”. sets
i Nodes /1*8/
* Probably not necessary but first and last element of node set pt(i) primer node ut(i) ultimo node ij(i,i) Arcos /1.3, 3.1, 2.3, 3.2, 3.5, 5.3, 5.4, 4.5, 5.7, 7.5, 7.8, 8.7, 6.8, 8.6/ t numero de vias que se pueden asignar a trenes en el tramo compartido st /1*3/ l Lines /1*3/ w Origin-Destination pairs /1*10/ hd posible values of headways or frequencies /1*9/
lines(i) set of lines that traverse node i ;
* Alternative names for use in equations when neede d alias(i,j,k,u,v); alias(l,ll,ln,lnn); alias(hd,hdpr);
pt(i)= yes$( ord(i) eq 1); ut(i)= yes$( ord(i) eq card(i)); sets
st(i,j,t) Conjunto de tramos compartidos con posibles tracks /3.5.1, 5.3.1, 4.5.1, 5.4.1, 5.7.1, 7.5.1/ ;
Table demanda(i,j) matriz de demanda
1 2 3 4 5 6 7 8 1 0 0 0 0 0 60 0 0 800 2 0 0 0 600 0 30 0 0 0 3 0 0 0 0 0 0 0 0 4 0 450 0 0 0 50 0 0 0 5 0 0 0 0 0 0 0 0 6 300 500 0 800 0 0 0 0 7 0 0 0 0 0 0 0 0 8 600 0 0 0 0 0 0 0 ; Table pair(i,j) numero de par correspondiente a i-j
1 2 3 4 5 6 7 8 1 0 0 0 0 0 1 0 2 2 0 0 0 3 0 4 0 0 3 0 0 0 0 0 0 0 0 4 0 5 0 0 0 6 0 0 5 0 0 0 0 0 0 0 0 6 7 8 0 9 0 0 0 0 7 0 0 0 0 0 0 0 0 8 10 0 0 0 0 0 0 0 ;
Anexo: Códigos de programación en GAMS
134
Table dis(i,j) numero de par correspondiente a i-j
1 2 3 4 5 6 7 8 1 0 0 5 0 0 0 0 0 2 0 0 6 0 0 0 0 0 3 5 6 0 0 6 0 0 0 4 0 0 0 0 4 0 0 0 5 0 0 6 4 0 0 5 0 6 0 0 0 0 0 0 0 5 7 0 0 0 0 5 0 0 6 8 0 0 0 0 0 5 6 0 ; Table linkrt(i,j,l) relacion entre arcos y rutas
1 2 3 1.3 1 0 0 3.1 1 0 0 2.3 0 1 0 3.2 0 1 0 3.5 1 1 0 5.3 1 1 0 5.4 0 1 1 4.5 0 1 1 5.7 1 0 1 7.5 1 0 1 7.8 0 0 1 8.7 0 0 1 6.8 0 0 1 8.6 0 0 1 ; Table nodert(i,l) relacion entre arcos y rutas
1 2 3 1 1 0 0 2 0 1 0 3 1 1 0 4 0 1 1 5 1 1 1 6 0 0 1 7 1 0 1 8 0 0 1 ;
Anexo: Códigos de programación en GAMS
135
Table arcopar(w,i,j) Recoge los links que se usan para 3-caminos mas cor tos de cada par OD 1.3 3.1 2.3 3.2 3.5 5.3 5.4 4.5 5.7 7.5 7.8 8.7 6.8 8.6 1 1 0 0 0 1 0 0 0 1 0 1 0 0 1 2 1 0 0 0 1 0 0 0 1 0 1 0 0 0 3 0 0 1 0 1 0 1 0 0 0 0 0 0 0 4 0 0 1 0 1 0 0 0 1 0 1 0 0 1 5 0 0 0 1 0 1 0 1 0 0 0 0 0 0 6 0 0 0 0 0 0 0 1 1 0 1 0 0 1 7 0 1 0 0 0 1 0 0 0 1 0 1 1 0 8 0 0 0 1 0 1 0 0 0 1 0 1 1 0 9 0 0 0 0 0 0 1 0 0 1 0 1 1 0 10 0 1 0 0 0 1 0 0 0 1 0 1 0 0
;
* 2 3 4 5 6 10 12 15 20/ Table theta(hd,hdpr) variable de compatibilidad entre trenes en shared t racks
1 2 3 4 5 6 7 8 9 1 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 1 5 0 0 0 0 0 0 0 0 1 6 0 0 0 0 0 0 1 1 1 7 0 0 0 0 0 1 1 1 1 8 0 0 0 0 0 1 1 1 1 9 0 0 0 1 1 1 1 1 1 ;
Anexo: Códigos de Programación en GAMS
136
Parameters
* hdw(l) headway de las lineas /1=10, 2=5, 3=1 2/ fr(l) frecuencia de las lineas cap(l) capacidad de cada linea (DEL TREN) /1=2000, 2=2000, 3=2000/ line(i,l,ll) parametro que indica coincidencia de lineas en nodos Mean_speed "Velocidad media de los trenes en km/h" /60/ hdvalue(hd) /1=2,2=3,3=4,4=5,5=6,6=10,7=12,8=15,9=20/ llenght(l) longitud de la linea l ckm_loc coste variable de operacion de la linea (€ por Km plaza y hora) dependiente de la capacidad y frecue ncia /34/ ckm_carr Coste variable de operacion de la linea (€ por Km plaza y hora) dependiente de la capacidad y frecue ncia /2/ cost_loc Coste de compra de una locomotora por 1E6 /2.5/ cost_carr Coste de compra de un vagon por 1E6 /0.9/ Horizonte horizonte para umputar costes de compra de rolling stocks medido en años /50/ cap_vagon cap de un vagon /200/ Vmax Maximum of set V /20/ sft headway de seguridad entre trenes /1/ dwt tiempo de espera en la estacion /1/ theta_one Monetary value of travel time /1/ theta_two Monetary value of transfers /10/
* theta_three Monetary value for variable cost s per km /10/ theta_four Monetary value for variable costs per hour /40/
* theta_five Monetary value for purchases /200 / ORIG(w) Origen de cada par O_D DEST(w) Destino de cada par O_D
* orige(st) Nodo de origen en el tramo compa rtido st * desti(st) Nodo destino en el tramo compart ido st g(w) Volumen a mover en el par w size1 size2 size3 tam1 tam2 tam3 ahorro_var1 ahorro_var2 ahorro_var3 Tabla(i,w) Vale 1 si el nodo i pertenece al par w Tabla2(i,w,l) Vale 1 si el nodo i pertenece al par w usando linea l Tabla3(w,l) Vale 1 si la linea l se usa para dar servicio al par w ;
Anexo: Códigos de Programación en GAMS
137
Sets
ijl(i,j,l) Solo aquellas combinaciones de arcos y lineas existentes il(i,l) Solo aquellos pares o combinaciones de nodos y lineas existentes illl(i,l,ll) Solo aquellos nodos que comparten lineas (combinaciones existentes) ijlll(i,j,l,ll) Solo aquellos arcos que comparten lineas lll(l,ll) Solo contiene pares de lineas que coinciden en algún arco
* s(i,j) Tramos compartidos por más de una línea ls(i,j,l) Líneas que recorren el tramo compartido entre el nodo i y el nodo j wijl(i,j,w,l) Solo aquellas combinaciones de pares arcos y lineas existentes willl(i,w,l,ll) Solo aquellas combinaciones existentes de verdad
* f(i,j,w,l) gagagaga * ttt(i,w,l,ll) aaaaa wijlll(i,j,w,l,ll) wnod(i,w) wnodlin(i,w,l) wlin(w,l) chklink(i,j) ;
ijl(i,j,l)$(linkrt(i,j,l))= yes; il(i,l)$(nodert(i,l))= yes; illl(i,l,ll)$(nodert(i,l) and nodert(i,ll) and ( ord(l) <> ord(ll)))= yes; ijlll(i,j,l,ll)$(linkrt(i,j,l) and linkrt(i,j,ll) and ( ord(l) < ord(ll)) and ( ord(i) < ord(j)))= yes; lll(l,ll)$( sum(ijlll(i,j,ln,lnn)$( ord(l)= ord(ln) and ord (ll)= ord(lnn)),1)>0)= yes;
wijl(i,j,w,l)$(linkrt(i,j,l) and arcopar(w,i,j))= yes; willl(i,w,l,ll)$(( sum(j$(linkrt(j,i,l)),arcopar(w,j,i))>0) and nodert(i,ll) and ( ord(l) <> ord(ll)))= yes; wijlll(i,j,w,l,ll)$(wijl(i,j,w,l) and wijl(i,j,w,ll))= yes;
Tabla(i,w)=0; Tabla(i,w)=1$( sum(j$(ij(i,j)),arcopar(w,i,j)+arcopar(w,j,i))>0);
Tabla2(i,w,l)=0; Tabla2(i,w,l)=1$(Tabla(i,w) and nodert(i,l));
Tabla3(w,l)=0; loop(ij(i,j), loop(w, loop(l, if((wijl(i,j,w,l)), Tabla3(w,l)=1;);
); ); );
Anexo: Códigos de Programación en GAMS
138
display Tabla, Tabla2,Tabla3;
wnod(i,w)$(Tabla(i,w))= yes; wnodlin(i,w,l)$(Tabla2(i,w,l))= yes; wlin(w,l)$(tabla3(w,l))= yes;
*wil(i,w,l)=yes$((sum(j,arcopar(w,j,i))>0) and node rt(i,l)); display wlin;
*f(i,j,w,l)=yes; *ttt(i,w,l,ll)=yes; size1= card(wijl); size2= card(willl); size3= card(wlin);
tam1= card(i)* card(j)* card(w)* card(l); tam2= card(i)* card(l)* card(w)* card(ll); tam3= card(w)* card(l);
ahorro_var1=tam1-size1; ahorro_var2=tam2-size2; ahorro_var3=tam3-size3; display ahorro_var1, ahorro_var2, ahorro_var3;
Scalars
DemScala Escala para aumentar demanda entre pares /3/ ; * Rellenando origen y destino de cada par loop(w, loop(i, loop(j, if(pair(i,j)= ord(w), ORIG(w)= ord(i); DEST(w)= ord(j);
g(w)=demanda(i,j)*DemScala; ); ); ); );
* rellenando numero de personas a mpver en cada par Display ORIG,DEST,g; Display linkrt,nodert;
option ijlll:0:2:2; option illl:0:1:2; option ijl:0:2:1; display wijl,willl,wijlll;
;
*fr(l)=60/hdw(l);
Anexo: Códigos de Programación en GAMS
139
* parametro que indica coincidencia de lineas en no dos line(i,l,ll)=0; loop(i, loop(l, loop(ll, if((nodert(i,l)=1 and nodert(i,ll)=1), line(i,l,ll)=1;
); ); ); ); Display line;
loop(i, loop(j, loop(t, if(st(i,j,t), loop(l, ls(i,j,l)= yes$(linkrt(i,j,l));
); ); ); ); ); display ls;
parameter nlin(k)
llenghtpar(w) Tciclo(l); nlin(k)= sum(l$(nodert(k,l)), nodert(k,l)); display nlin; llenght(l)= sum(ij(i,j)$ijl(i,j,l),dis(i,j)); display llenght,wnod,wnodlin,wlin; llenghtpar(w)= sum(ij(i,j)$arcopar(w,i,j),dis(i,j)); display llenghtpar;
Tciclo(l)=2*llenght(l)*(60.0/Mean_speed); display tciclo; chklink(i,j)= yes$(ij(i,j) and dis(i,j)<>dis(j,i)); display chklink;
scalar Wtotal; Wtotal= sum(w,g(w)); Display Wtotal;
Anexo: Códigos de Programación en GAMS
140
• Archivo de datos del caso computacional B, “Ejemplo 12 nodos 56 pares.gms” sets
i Nodes /1*12/ t numero de vias que se pueden asignar a trenes en el tramo compartido st /1*3/ * Probably not necessary but first and last element of node set pt(i) primer node ut(i) ultimo node ij(i,i) Arcos /1.3, 3.1, 2.3, 3.2, 3.5, 5.3, 5.4, 4.5, 5.7, 7.5, 7.8, 8.7, 6.8, 8.6, 1.9, 9.1, 9.10, 10.9, 10.4, 4.10, 2.11, 11.2, 11.12, 12.11, 12.8, 8.12/ l Lines /1*5/ w Origin-Destination pairs /1*56/ hd posible values of headways or frequencies /1*9/
lines(i) set of lines that traverse node i ; ;
* Alternative names for use in equations when neede d alias(i,j,k,u,v); alias(l,ll,ln,lnn); alias(hd,hdpr);
; sets
st(i,j,t) Conjunto de tramos compartidos con posibles tracks asociados /3.5.1, 5.3.1/ ; pt(i)= yes$( ord(i) eq 1); ut(i)= yes$( ord(i) eq card(i));
Table demanda(i,j) matriz de demanda
1 2 3 4 5 6 7 8 9 10 11 12 1 0 2 5 3 6 1 5 2 0 0 0 0 2 1 0 4 6 3 1 4 1 0 0 0 0 3 4 3 0 2 5 1 5 2 0 0 0 0 4 3 5 3 0 2 3 4 1 0 0 0 0 5 5 4 5 3 0 1 4 2 0 0 0 0 6 1 1 2 1 3 0 6 5 0 0 0 0 7 4 1 5 2 6 5 0 4 0 0 0 0 8 1 2 4 3 5 5 4 0 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 0 0 ;
Anexo: Códigos de Programación en GAMS
141
Table pair(i,j) numero de par correspondiente a i-j
1 2 3 4 5 6 7 8 9 1 0 11 12 1 0 1 2 3 4 5 6 7 0 0 0 0 2 8 0 9 10 11 12 13 14 0 0 0 0 3 15 16 0 17 18 19 20 21 0 0 0 0 4 22 23 24 0 25 26 27 28 0 0 0 0 5 29 30 31 32 0 33 34 35 0 0 0 0 6 36 37 38 39 40 0 41 42 0 0 0 0 7 43 44 45 46 47 48 0 49 0 0 0 0 8 50 51 52 53 54 55 56 0 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 0 0 ; Table dis(i,j) numero de par correspondiente a i-j
1 2 3 4 5 6 7 8 9 10 1 1 12 1 0 0 5 0 0 0 0 0 4 0 0 0 2 0 0 6 0 0 0 0 0 0 0 4 0 3 5 6 0 0 6 0 0 0 0 0 0 0 4 0 0 0 0 4 0 0 0 0 4 0 0 5 0 0 6 4 0 0 5 0 0 0 0 0 6 0 0 0 0 0 0 0 5 0 0 0 0 7 0 0 0 0 5 0 0 6 0 0 0 0 8 0 0 0 0 0 5 6 0 0 0 0 4 9 4 0 0 0 0 0 0 0 0 4 0 0 10 0 0 0 4 0 0 0 0 4 0 0 0 11 0 4 0 0 0 0 0 0 0 0 0 6 12 0 0 0 0 0 0 0 4 0 0 6 0 ; Table linkrt(i,j,l) relacion entre arcos y rutas
1 2 3 4 5 1.3 1 0 0 0 0 3.1 1 0 0 0 0 2.3 0 1 0 0 0 3.2 0 1 0 0 0 3.5 1 1 0 0 0 5.3 1 1 0 0 0 5.4 0 1 0 0 0 4.5 0 1 0 0 0 5.7 1 0 0 0 0 7.5 1 0 0 0 0 7.8 0 0 1 0 0 8.7 0 0 1 0 0 6.8 0 0 1 0 0 8.6 0 0 1 0 0 1.9 0 0 0 1 0 9.1 0 0 0 1 0 9.10 0 0 0 1 0 10.9 0 0 0 1 0 10.4 0 0 0 1 0
Anexo: Códigos de Programación en GAMS
142
4.10 0 0 0 1 0 2.11 0 0 0 0 1 11.2 0 0 0 0 1 11.12 0 0 0 0 1 12.11 0 0 0 0 1 12.8 0 0 0 0 1 8.12 0 0 0 0 1 ; Table nodert(i,l) relacion entre nodos y rutas
1 2 3 4 5 1 1 0 0 1 0 2 0 1 0 0 1 3 1 1 0 0 0 4 0 1 0 1 0 5 1 1 0 0 0 6 0 0 1 0 0 7 1 0 1 0 0 8 0 0 1 0 1 9 0 0 0 1 0 10 0 0 0 1 0 11 0 0 0 0 1 12 0 0 0 0 1 ;
*Por cuestiones de legibilidad, se omite la tabla auxiliar “arcopar (w,i,j) “ del presente
archivo de datos correspondiente al caso computacional B.
* 2 3 4 5 6 10 12 15 20/ Table theta(hd,hdpr) variable de compatibilidad entre trenes en shared
tracks 1 2 3 4 5 6 7 8 9 1 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 1 5 0 0 0 0 0 0 0 0 1 6 0 0 0 0 0 0 1 1 1 7 0 0 0 0 0 1 1 1 1 8 0 0 0 0 0 1 1 1 1 9 0 0 0 1 1 1 1 1 1 ;
Parameters
ORIG(w) Origen de cada par O_D DEST(w) Destino de cada par O_D * orige(st) Nodo de origen en el tramo comp artido st * desti(st) Nodo destino en el tramo compart ido st g(w) Volumen a mover en el par w size1 size2 size3 tam1
Anexo: Códigos de Programación en GAMS
143
tam2 tam3 ahorro_var1 ahorro_var2 ahorro_var3 Tabla(i,w) Tabla2(i,w,l) Tabla3(w,l) ;
Sets
ijl(i,j,l) Solo aquellas combinaciones de arcos y lineas existentes il(i,l) Solo aquellos pares o combinaciones de nodos y lineas existentes illl(i,l,ll) Solo aquellos nodos que comparten lineas (combinaciones existentes) ijlll(i,j,l,ll) Solo aquellos arcos que comparten lineas lll(l,ll) Solo contiene pares de lineas que coinciden en algún arco * s(i,j) Tramos compartidos por más de una línea ls(i,j,l) Líneas que recorren el tramo compartido entre el nodo i y el nodo j wijl(i,j,w,l) Solo aquellas combinaciones de pares arcos y lineas existentes willl(i,w,l,ll) Solo aquellas combinaciones existentes de verdad wijlll(i,j,w,l,ll) wnod(i,w) wnodlin(i,w,l) wlin(w,l) chklink(i,j) ;
ijl(i,j,l)$(linkrt(i,j,l))= yes; il(i,l)$(nodert(i,l))= yes; illl(i,l,ll)$(nodert(i,l) and nodert(i,ll) and ord(l) <> ord(ll))= yes; ijlll(i,j,l,ll)$(linkrt(i,j,l) and linkrt(i,j,ll) and ( ord(l) < ord(ll)) and ( ord(i) < ord(j)))= yes; lll(l,ll)$( sum(ijlll(i,j,ln,lnn)$( ord(l)= ord(ln) and ord (ll)= ord(lnn)),1)>0)= yes;
*s(i,j)=1$(sum(l,linkrt(i,j,l)) gt 1 and (ord (i) < ord (j))); wijl(i,j,w,l)$(linkrt(i,j,l) and arcopar(w,i,j))= yes; willl(i,w,l,ll)$(( sum(j$(linkrt(j,i,l)),arcopar(w,j,i))>0) and nodert(i,ll) and ( ord(l) <> ord(ll)))= yes; wijlll(i,j,w,l,ll)$(wijl(i,j,w,l) and wijl(i,j,w,ll))= yes;
Tabla(i,w)=0; Tabla(i,w)=1$( sum(j$(ij(i,j)),arcopar(w,i,j)+arcopar(w,j,i))>0);
Tabla2(i,w,l)=0; Tabla2(i,w,l)=1$(Tabla(i,w) and nodert(i,l));
Anexo: Códigos de Programación en GAMS
144
Tabla3(w,l)=0; loop(ij(i,j), loop(w, loop(l, if((wijl(i,j,w,l)), Tabla3(w,l)=1;);
); ); ); display Tabla, Tabla2,Tabla3;
wnod(i,w)$(Tabla(i,w))= yes; wnodlin(i,w,l)$(Tabla2(i,w,l))= yes; wlin(w,l)$(tabla3(w,l))= yes;
size1= card(wijl); size2= card(willl); size3= card(wlin);
tam1= card(i)* card(j)* card(w)* card(l); tam2= card(i)* card(l)* card(w)* card(ll); tam3= card(w)* card(l);
ahorro_var1=tam1-size1; ahorro_var2=tam2-size2; ahorro_var3=tam3-size3; display ahorro_var1, ahorro_var2, ahorro_var3; option ijlll:0:2:2; option illl:0:1:2; option ijl:0:2:1;
*display ijl,illl,ijlll,lll; display wijl,willl,wijlll;
Scalars
DemScala Escala para aumentar demanda entre pares /300/ ; * Rellenando origen y destino de cada par loop(w, loop(i, loop(j, if(pair(i,j)= ord(w), ORIG(w)= ord(i); DEST(w)= ord(j);
g(w)=demanda(i,j)*DemScala; ); ); ); );
* rellenando numero de personas a mpver en cada par Display ORIG,DEST;
Anexo: Códigos de Programación en GAMS
145
Display g,linkrt,nodert; Parameters
* hdw(l) headway de las lineas /1=10, 2=5, 3=1 2/ fr(l) frecuencia de las lineas cap(l) capacidad de cada linea (del tren) /1=2000, 2=2000, 3=2000, 4=2000, 5=2000/ line(i,l,ll) parametro que indica coincidencia de lineas en nodos Mean_speed "Velocidad media de los trenes en km/h" /60/ hdvalue(hd) /1=2,2=3,3=4,4=5,5=6,6=10,7=12,8=15,9=20/ llenght(l) longitud de la linea l ckm_loc coste variable de operacion de la linea (€ por Km plaza y hora) dependiente de la capacidad y frecue ncia /34/ ckm_carr Coste variable de operacion de la linea (€ por Km plaza y hora) dependiente de la capacidad y frecue ncia /2/ cost_loc Coste de compra de una locomotora por 1E6 /2.5/ cost_carr Coste de compra de un vagon por 1E6 /0.9/ Horizonte horizonte para umputar costes de compra de rolling stocks medido en años /50/ cap_vagon cap de un vagon /200/
* guarda_linea(st,l) parametro para guardar las lineas que comparten un determinado arco st Vmax Maximum of set V /20/ sft headway de seguridad entre trenes /1/ dwt tiempo de espera en la estacion /1/ theta_one Monetary value of travel time /1/ theta_two Monetary value of transfers /10/
* theta_three Monetary value for variable cost s per km /10/ theta_four Monetary value for variable costs per hour /40/
* theta_five Monetary value for purchases /200 / ;
*fr(l)=60/hdw(l); line(i,l,ll)=0; loop(i, loop(l, loop(ll, if((nodert(i,l)=1 and nodert(i,ll)=1), line(i,l,ll)=1;
); ); ); ); Display line;
*Guardando origen y destino de los shared tracks y tracks asociados loop(i, loop(j, loop(t,
Anexo: Códigos de Programación en GAMS
146
if(st(i,j,t), loop(l, ls(i,j,l)= yes$(linkrt(i,j,l));
); ); ); ); ); display ls;
parameter nlin(k)
llenghtpar(w) Tciclo(l); nlin(k)= sum(l$(nodert(k,l)), nodert(k,l)); display nlin; llenght(l)= sum(ij(i,j)$ijl(i,j,l),dis(i,j)); display llenght,wnod,wnodlin,wlin; llenghtpar(w)= sum(ij(i,j)$arcopar(w,i,j),dis(i,j)); display llenghtpar;
Tciclo(l)=2*llenght(l)*(60.0/Mean_speed); display tciclo; chklink(i,j)= yes$(ij(i,j) and dis(i,j)<>dis(j,i)); display chklink;
scalar Wtotal; Wtotal= sum(w,g(w)); Display Wtotal;
Anexo: Códigos de Programación en GAMS
147
• Archivo de datos del caso computacional C, “Ejemplo REDUC Madrid Model 2
800W. gms” sets
i Nodes /1*36/
* Probably not necessary but first and last element of node set pt(i) primer node ut(i) ultimo node ij(i,i) Arcos /1.2, 2.3, 2.4, 3.5, 4.5, 5.6, 6.7, 7.8, 8.9, 9.10, 10.30, 30.31, 31.32, 32.33, 1.30, 1.35, 35.34 , 11.12, 12.13, 13.14, 14.5, 5.15, 15.16, 16.17, 17.18, 36.16, 16.2 9, 27.28, 28.29, 29.5, 1.19, 19.20, 5.21, 21.22, 22.23, 23.24, 24.25 , 25.26 2.1, 3.2, 4.2, 5.3, 5.4, 6.5, 7.6, 8.7, 9.8, 10.9, 30.10, 31.30, 32.31, 33.32, 30.1, 35.1, 34.35, 12.11, 13.12, 14.1 3, 5.14, 15.5, 16.15, 17.16, 18.17, 16.36, 29.16, 28.27, 29.28, 5. 29, 19.1, 20.19, 21.5, 22.21, 23.22, 24.23, 25.24, 26.25/ t numero de vias que se pueden asignar a trenes en el tramo compartido st /1*3/ l Lines /1*7/ w Origin-Destination pairs /1*800/ hd posible values of headways or frequencies /1*9/
lines(i) set of lines that traverse node i ; ;
* Alternative names for use in equations when neede d alias(i,j,k,u,v); alias(l,ll,ln,lnn); alias(hd,hdpr);
; sets
st(i,j,t) Conjunto de tramos compartidos con posibles tracks /1.30.1, 30.1.1, 30.31.1, 31.30.1, 30.31.2, 31.30.2 , 31.32.1, 32.31.1, 31.32.2, 32.31.2, 7.6.1, 6.7.1, 6.5.1, 5.6.1, 2.3.1 , 3.2.1, 2.3.2, 3.2.2, 3.5.1, 5.3.1, 3.5.2, 5.3.2, 2.4.1, 4.2.1, 4. 5.1, 5.4.1, 5.29.1, 29.5.1, 1.2.1, 2.1.1, 1.2.2, 2.1.2, 1.2.3, 2.1.3, 1 .19.1, 19.1.1/ ; * Defining first and last nodes of Set Nodes and al so set A(i) and D(i) pt(i)= yes$( ord(i) eq 1); ut(i)= yes$( ord(i) eq card(i));
Anexo: Códigos de Programación en GAMS
148
Table demanda(i,j) matriz de demanda * (Primera mitad)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 7 18 1 0 34 9 12 7 13 9 15 10 13 0 6 14 11 9 11 7 0 2 0 0 0 11 7 8 7 14 10 12 0 9 6 13 10 12 12 0 3 14 10 0 0 9 10 14 8 10 14 0 13 10 13 10 8 7 0 4 10 15 0 0 0 11 5 10 14 15 0 13 13 14 9 14 6 0 5 6 6 7 0 0 0 6 10 6 13 0 9 12 6 10 7 11 0 6 9 9 14 14 0 0 0 11 12 7 0 11 14 10 6 14 11 0 7 9 4 12 9 13 0 0 0 8 13 0 10 12 14 6 13 12 0 8 77 50 91 82 83 94 0 0 0 10 0 12 12 12 10 14 9 0 9 79 34 87 95 94 87 80 0 0 0 0 8 10 11 9 13 13 0 10 83 38 88 93 87 96 100 8 0 0 0 11 9 8 10 14 14 0 11 88 68 97 95 94 96 97 15 14 0 0 0 13 8 14 9 11 0 12 95 78 79 80 95 99 87 14 11 7 0 0 0 6 10 7 14 0 13 98 88 93 81 89 79 80 5 7 7 11 0 0 0 8 10 9 0 14 83 53 91 85 99 88 94 10 6 6 12 13 0 0 0 8 14 0 15 96 66 84 88 90 90 78 13 14 12 11 9 10 0 0 0 8 0 16 86 76 88 86 80 79 92 14 11 11 13 15 14 13 0 0 0 0 17 86 56 100 87 91 78 91 14 5 9 6 13 8 6 8 0 0 0 18 82 71 86 91 83 82 79 5 12 8 0 7 9 7 9 7 0 0 19 75 89 99 91 94 81 77 13 8 8 0 7 14 6 13 13 15 0 20 99 79 76 99 84 81 80 13 13 9 12 11 6 7 8 13 14 0 21 93 82 77 83 80 76 76 12 7 14 13 7 12 7 10 10 6 0 22 97 37 98 92 87 92 98 5 14 10 15 6 6 7 12 8 14 0 23 86 75 91 92 90 79 87 9 14 9 6 14 11 13 8 15 8 0 24 90 80 82 98 94 95 83 14 7 10 14 14 11 12 13 9 7 0 25 79 77 90 92 97 91 98 12 6 12 14 7 10 11 10 10 9 0 26 95 64 76 99 85 77 76 12 12 15 0 6 13 6 13 7 6 0 27 99 13 78 78 96 95 91 10 6 13 0 8 9 7 14 12 9 0 28 77 73 76 97 77 90 99 11 10 10 11 10 15 12 13 9 15 0 29 89 56 99 87 88 99 100 11 11 6 13 9 5 12 13 5 14 13 30 77 66 97 93 90 90 99 15 15 15 14 6 10 14 13 6 10 10 31 85 75 86 86 75 81 79 14 6 14 8 14 11 13 7 9 6 5 32 87 97 90 89 84 99 86 7 6 9 14 15 5 12 6 14 14 10 33 80 86 94 82 77 95 90 12 6 12 8 14 10 12 14 12 14 5 34 77 65 100 85 86 75 84 12 14 11 0 6 11 14 13 6 10 0 35 78 71 80 90 85 87 80 13 10 5 0 6 9 8 11 14 12 0 36 13 23 20 10 25 27 10 13 10 5 0 6 9 8 11 14 12 0
Anexo: Códigos de Programación en GAMS
149
Table demanda(i,j) matriz de demanda * (Segunda mitad) 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 1 0 10 15 6 12 7 0 0 0 0 13 14 13 0 0 0 0 0 2 0 12 14 6 7 12 0 0 0 0 6 10 13 0 0 0 0 0 3 0 6 15 12 9 13 0 0 0 0 5 10 10 0 0 0 0 0 4 0 5 13 15 6 5 0 0 0 0 9 10 14 0 0 0 0 0 5 0 10 12 14 10 10 0 0 0 0 10 10 12 0 0 0 0 0 6 0 7 14 15 9 14 0 0 0 0 13 8 10 0 0 0 0 0 7 0 8 14 12 12 6 0 0 0 0 10 11 12 0 0 0 0 0 8 0 9 6 13 11 9 0 0 0 0 14 10 6 0 0 0 0 0 9 0 13 5 5 11 12 0 0 0 0 14 13 7 0 0 0 0 0 10 0 13 11 7 11 13 0 0 0 0 8 8 13 0 0 0 0 0 11 0 13 11 11 14 8 0 0 0 0 12 13 12 0 0 0 0 0 12 0 8 8 11 13 6 0 0 0 0 6 11 11 0 0 0 0 0 13 0 10 9 10 5 15 0 0 0 0 6 6 10 0 0 0 0 0 14 0 6 5 12 8 11 0 0 0 0 10 13 14 0 0 0 0 0 15 0 14 8 12 9 10 0 0 0 0 6 14 9 0 0 0 0 0 16 0 8 14 14 6 10 0 0 0 0 9 15 10 0 0 0 0 0 17 0 10 6 13 12 10 0 0 0 0 12 15 15 0 0 0 0 0 18 0 9 6 15 12 7 0 0 0 0 7 7 8 0 0 0 0 0 19 0 0 14 8 12 6 11 0 0 0 11 13 10 0 0 0 0 0 20 0 0 0 10 7 13 0 0 0 0 7 15 9 0 0 0 0 0 21 0 0 0 0 7 5 0 0 0 0 9 6 7 0 0 0 0 0 22 0 7 0 0 0 13 0 0 0 0 10 12 13 0 0 0 0 0 23 0 12 12 0 0 0 0 0 0 0 13 7 5 0 0 0 0 0 24 0 11 6 9 0 0 0 0 0 0 7 10 13 0 0 0 0 0 25 0 14 12 10 7 0 0 0 0 0 9 13 11 0 0 0 0 0 26 0 13 15 9 11 13 0 0 0 0 8 10 11 0 0 0 0 0 27 0 12 13 6 10 11 0 0 0 0 11 12 5 0 0 0 0 0 28 0 12 9 6 12 8 0 0 0 0 0 11 14 0 0 0 0 0 29 7 10 11 14 13 15 0 0 0 0 0 0 0 0 0 0 0 0 30 9 14 6 7 6 5 10 0 0 0 0 0 0 0 0 0 0 0 31 15 5 7 9 11 13 0 0 0 0 6 0 0 0 0 0 0 0 32 12 5 9 6 7 10 0 0 0 0 12 13 0 0 0 0 0 0 33 9 10 10 15 10 7 0 0 0 0 13 7 15 0 0 0 0 0 34 0 14 13 14 9 7 0 0 0 0 10 12 14 0 0 0 0 0 35 0 7 8 15 6 11 0 0 0 0 6 5 7 0 0 0 0 0 36 0 7 8 12 12 11 0 0 0 0 16 8 10 0 0 0 0 0 ;
Anexo: Códigos de Programación en GAMS
150
Table pair(i,j) numero de par correspondiente a i-j * (Primera mitad) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1 0 0 1 2 3 4 5 6 7 8 0 9 10 11 12 13 14 0 2 0 0 0 23 24 25 26 27 28 29 0 30 31 32 33 34 35 0 3 767 0 0 0 44 45 46 47 48 49 0 50 51 52 53 54 55 0 4 768 64 0 0 0 65 66 67 68 69 0 70 71 72 73 74 75 0 5 769 84 85 0 0 0 86 87 88 89 0 90 91 92 93 94 95 0 6 770 104 105 106 0 0 0 107 108 109 0 110 111 112 1 13 114 115 0 7 771 124 125 126 127 0 0 0 128 129 0 130 131 132 1 33 134 135 0 8 772 144 145 146 147 148 0 0 0 149 0 150 151 152 1 53 154 155 0 9 773 164 165 166 167 168 169 0 0 0 0 170 171 172 1 73 174 175 0 10 774 184 185 186 187 188 189 190 0 0 0 191 192 193 1 94 195 196 0 11 775 205 206 207 208 209 210 211 212 0 0 0 213 214 2 15 216 217 0 12 776 226 227 228 229 230 231 232 233 234 0 0 0 235 2 36 237 238 0 13 777 247 248 249 250 251 252 253 254 255 256 0 0 0 2 57 258 259 0 14 778 268 269 270 271 272 273 274 275 276 277 278 0 0 0 279 280 0 15 779 289 290 291 292 293 294 295 296 297 298 299 300 0 0 0 301 0 16 780 310 311 312 313 314 315 316 317 318 319 320 321 322 0 0 0 0 17 781 331 332 333 334 335 336 337 338 339 340 341 342 343 3 44 0 0 0 18 782 353 354 355 356 357 358 359 360 361 0 362 363 364 3 65 366 0 0 19 783 374 375 376 377 378 379 380 381 382 0 383 384 385 3 86 387 388 0 20 784 397 398 399 400 401 402 403 404 405 406 407 408 409 4 10 411 412 0 21 785 419 420 421 422 423 424 425 426 427 428 429 430 431 4 32 433 434 0 22 786 440 441 442 443 444 445 446 447 448 449 450 451 452 4 53 454 455 0 23 787 459 460 461 462 463 464 465 466 467 468 469 470 471 4 72 473 474 0 24 788 478 479 480 481 482 483 484 485 486 487 488 489 490 4 91 492 493 0 25 789 498 499 500 501 502 503 504 505 506 507 508 509 510 5 11 512 513 0 26 790 519 520 521 522 523 524 525 526 527 0 528 529 530 5 31 532 533 0 27 791 540 541 542 543 544 545 546 547 548 0 549 550 551 5 52 553 554 0 28 792 561 562 563 564 565 566 567 568 569 570 571 572 573 5 74 575 576 0 29 793 582 583 584 585 586 587 588 589 590 591 592 593 594 5 95 596 597 598 30 794 605 606 607 608 609 610 611 612 613 614 615 616 617 6 18 619 620 621 31 795 629 630 631 632 633 634 635 636 637 638 639 640 641 6 42 643 644 645 32 796 653 654 655 656 657 658 659 660 661 662 663 664 665 6 66 667 668 669 33 797 678 679 680 681 682 683 684 685 686 687 688 689 690 6 91 692 693 694 34 798 704 705 706 707 708 709 710 711 712 0 713 714 715 7 16 717 718 0 35 799 725 726 727 728 729 730 731 732 733 0 734 735 736 7 37 738 739 0 36 800 746 747 748 749 750 751 752 753 754 0 755 756 757 7 58 759 760 0
Anexo: Códigos de Programación en GAMS
151
Table pair(i,j) numero de par correspondiente a i-j * (Segunda mitad) 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 1 0 15 16 17 18 19 0 0 0 0 20 21 22 0 0 0 0 0 2 0 36 37 38 39 40 0 0 0 0 41 42 43 0 0 0 0 0 3 0 56 57 58 59 60 0 0 0 0 61 62 63 0 0 0 0 0 4 0 76 77 78 79 80 0 0 0 0 81 82 83 0 0 0 0 0 5 0 96 97 98 99 100 0 0 0 0 101 102 103 0 0 0 0 0 6 0 116 117 118 119 120 0 0 0 0 121 122 123 0 0 0 0 0 7 0 136 137 138 139 140 0 0 0 0 141 142 143 0 0 0 0 0 8 0 156 157 158 159 160 0 0 0 0 161 162 163 0 0 0 0 0 9 0 176 177 178 179 180 0 0 0 0 181 182 183 0 0 0 0 0 10 0 197 198 199 200 201 0 0 0 0 202 203 204 0 0 0 0 0 11 0 218 219 220 221 222 0 0 0 0 223 224 225 0 0 0 0 0 12 0 239 240 241 242 243 0 0 0 0 244 245 246 0 0 0 0 0 13 0 260 261 262 263 264 0 0 0 0 265 266 267 0 0 0 0 0 14 0 281 282 283 284 285 0 0 0 0 286 287 288 0 0 0 0 0 15 0 302 303 304 305 306 0 0 0 0 307 308 309 0 0 0 0 0 16 0 323 324 325 326 327 0 0 0 0 328 329 330 0 0 0 0 0 17 0 345 346 347 348 349 0 0 0 0 350 351 352 0 0 0 0 0 18 0 366 367 368 369 370 0 0 0 0 371 372 373 0 0 0 0 0 19 0 0 389 390 391 392 393 0 0 0 394 395 396 0 0 0 0 0 20 0 0 0 413 414 415 0 0 0 0 416 417 418 0 0 0 0 0 21 0 0 0 0 435 436 0 0 0 0 437 438 439 0 0 0 0 0 22 0 454 0 0 0 455 0 0 0 0 456 457 458 0 0 0 0 0 23 0 473 474 0 0 0 0 0 0 0 475 476 477 0 0 0 0 0 24 0 492 493 494 0 0 0 0 0 0 495 496 497 0 0 0 0 0 25 0 512 513 514 515 0 0 0 0 0 516 517 518 0 0 0 0 0 26 0 532 533 534 535 536 0 0 0 0 537 538 539 0 0 0 0 0 27 0 553 554 555 556 557 0 0 0 0 558 559 560 0 0 0 0 0 28 0 575 576 577 578 579 0 0 0 0 0 580 581 0 0 0 0 0 29 599 600 601 602 603 604 0 0 0 0 0 0 0 0 0 0 0 0 30 622 623 624 625 626 627 628 0 0 0 0 0 0 0 0 0 0 0 31 646 647 648 649 650 651 0 0 0 0 652 0 0 0 0 0 0 0 32 670 671 672 673 674 675 0 0 0 0 676 677 0 0 0 0 0 0 33 695 696 697 698 699 700 0 0 0 0 701 702 703 0 0 0 0 0 34 0 717 718 719 720 721 0 0 0 0 722 723 724 0 0 0 0 0 35 0 738 739 740 741 742 0 0 0 0 743 744 745 0 0 0 0 0 36 0 759 760 761 762 763 0 0 0 0 764 765 766 0 0 0 0 0
;
Anexo: Códigos de Programación en GAMS
152
Table dis(i,j) ndistancia de nodo a nodo i-j * (Primera mitad)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1 0 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 5 0 4 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 4 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 5 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 4 4 0 3 0 0 0 0 0 0 0 9 5 0 0 0 6 0 0 0 0 3 0 7 0 0 0 0 0 0 0 0 0 0 0 7 0 0 0 0 0 7 0 5 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 5 0 3 0 0 0 0 0 0 0 0 0 9 0 0 0 0 0 0 0 3 0 6 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 4 0 5 0 0 0 0 0 13 0 0 0 0 0 0 0 0 0 0 0 5 0 7 0 0 0 0 14 0 0 0 0 9 0 0 0 0 0 0 0 7 0 0 0 0 0 15 0 0 0 0 5 0 0 0 0 0 0 0 0 0 0 5 0 0 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 5 0 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 10 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 0 19 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 21 0 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 0 0 22 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 23 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 24 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 25 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 26 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 27 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 28 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 29 0 0 0 0 8 0 0 0 0 0 0 0 0 0 0 3 0 0 30 30 0 0 0 0 0 0 0 0 17 0 0 0 0 0 0 0 0 31 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 33 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 35 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 36 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 14 0 0
Anexo: Códigos de Programación en GAMS
153
Table dis(i,j) ndistancia de nodo a nodo i-j * (Segunda mitad)
19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 1 5 0 0 0 0 0 0 0 0 0 0 30 0 0 0 0 5 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 7 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 6 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 9 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 0 0 17 0 0 0 0 0 0 11 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 12 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 13 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 14 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 15 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 16 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 1 17 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 18 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 19 0 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 20 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 21 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 22 0 0 3 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 23 0 0 0 4 0 3 0 0 0 0 0 0 0 0 0 0 0 0 24 0 0 0 0 3 0 7 0 0 0 0 0 0 0 0 0 0 0 25 0 0 0 0 0 7 0 10 0 0 0 0 0 0 0 0 0 0 26 0 0 0 0 0 0 10 0 0 0 0 0 0 0 0 0 0 0 27 0 0 0 0 0 0 0 0 0 20 0 0 0 0 0 0 0 0 28 0 0 0 0 0 0 0 0 20 0 16 0 0 0 0 0 0 0 29 0 0 0 0 0 0 0 0 0 16 0 0 0 0 0 0 0 0 30 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 31 0 0 0 0 0 0 0 0 0 0 0 4 0 4 0 0 0 0 32 0 0 0 0 0 0 0 0 0 0 0 0 4 0 4 0 0 0 33 0 0 0 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 34 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 0 35 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6 0 0 36 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
;
Anexo: Códigos de Programación en GAMS
154
Table linkrt(i,j,l) relacion entre arcos y rutas
1 2 3 4 5 6 7 1.2 1 1 1 1 0 0 1 2.3 1 1 0 0 0 0 1 2.4 0 0 1 1 0 0 0 3.5 1 1 0 0 0 0 1 4.5 0 0 1 1 0 0 0 5.6 1 0 0 0 0 0 1 6.7 1 0 0 0 0 0 1 7.8 0 0 0 0 0 0 1 8.9 0 0 0 0 0 0 1 9.10 0 0 0 0 0 0 1 10.30 0 0 0 0 0 0 1 30.31 0 0 1 0 0 1 1 31.32 0 0 1 0 0 1 1 32.33 0 0 1 0 0 0 0 1.30 0 0 1 0 0 1 0 1.35 0 0 0 1 0 0 0 35.34 0 0 0 1 0 0 0 11.12 0 0 0 0 1 0 0 12.13 0 0 0 0 1 0 0 13.14 0 0 0 0 1 0 0 14.5 0 0 0 0 1 0 0 5.15 0 0 0 0 1 0 0 15.16 0 0 0 0 1 0 0 16.17 0 0 0 0 1 0 0 17.18 0 0 0 0 1 0 0 36.16 0 0 0 1 0 0 0 16.29 0 0 0 1 0 0 0 27.28 0 0 1 0 0 0 0 28.29 0 0 1 0 0 0 0 29.5 0 0 1 1 0 0 0 1.19 1 0 0 0 0 0 1 19.20 1 0 0 0 0 0 0 5.21 0 1 0 0 0 0 0 21.22 0 1 0 0 0 0 0 22.23 0 1 0 0 0 0 0 23.24 0 1 0 0 0 0 0 24.25 0 1 0 0 0 0 0 25.26 0 1 0 0 0 0 0 2.1 1 1 1 1 0 0 1 3.2 1 1 0 0 0 0 1 4.2 0 0 1 1 0 0 0 5.3 1 1 0 0 0 0 1 5.4 0 0 1 1 0 0 0 6.5 1 0 0 0 0 0 1 7.6 1 0 0 0 0 0 1 8.7 0 0 0 0 0 0 1 9.8 0 0 0 0 0 0 1 10.9 0 0 0 0 0 0 1 30.10 0 0 0 0 0 0 1 31.30 0 0 1 0 0 1 1 32.31 0 0 1 0 0 1 1
Anexo: Códigos de Programación en GAMS
155
33.32 0 0 1 0 0 0 0 30.1 0 0 1 0 0 1 0 35.1 0 0 0 1 0 0 0 34.35 0 0 0 1 0 0 0 12.11 0 0 0 0 1 0 0 13.12 0 0 0 0 1 0 0 14.13 0 0 0 0 1 0 0 5.14 0 0 0 0 1 0 0 15.5 0 0 0 0 1 0 0 16.15 0 0 0 0 1 0 0 17.16 0 0 0 0 1 0 0 18.17 0 0 0 0 1 0 0 16.36 0 0 0 1 0 0 0 29.16 0 0 0 1 0 0 0 28.27 0 0 1 0 0 0 0 29.28 0 0 1 0 0 0 0 5.29 0 0 1 1 0 0 0 19.1 1 0 0 0 0 0 1 20.19 1 0 0 0 0 0 0 21.5 0 1 0 0 0 0 0 22.21 0 1 0 0 0 0 0 23.22 0 1 0 0 0 0 0 24.23 0 1 0 0 0 0 0 25.24 0 1 0 0 0 0 0 26.25 0 1 0 0 0 0 0 ; Table nodert(i,l) relacion entre nodos y rutas
1 2 3 4 5 6 7 1 1 1 1 1 0 1 1 2 1 1 1 1 0 0 1 3 1 1 0 0 0 0 1 4 0 0 1 1 0 0 0 5 1 1 1 1 1 0 1 6 1 0 0 0 0 0 1 7 1 0 0 0 0 0 1 8 0 0 0 0 0 0 1 9 0 0 0 0 0 0 1 10 0 0 0 0 0 0 1 11 0 0 0 0 1 0 0 12 0 0 0 0 1 0 0 13 0 0 0 0 1 0 0 14 0 0 0 0 1 0 0 15 0 0 0 0 1 0 0 16 0 0 0 1 1 0 0 17 0 0 0 0 1 0 0 18 0 0 0 0 1 0 0 19 1 0 0 0 0 0 1 20 1 0 0 0 0 0 0 21 0 1 0 0 0 0 0 22 0 1 0 0 0 0 0 23 0 1 0 0 0 0 0 24 0 1 0 0 0 0 0 25 0 1 0 0 0 0 0
Anexo: Códigos de Programación en GAMS
156
26 0 1 0 0 0 0 0 27 0 0 1 0 0 0 0 28 0 0 1 0 0 0 0 29 0 0 1 1 0 0 0 30 0 0 1 0 0 1 1 31 0 0 1 0 0 1 1 32 0 0 1 0 0 1 1 33 0 0 1 0 0 0 0 34 0 0 0 1 0 0 0 35 0 0 0 1 0 0 0 36 0 0 0 1 0 0 0 ;
*Por cuestiones de legibilidad, se omite la tabla auxiliar “arcopar (w,i,j) “ del presente
archivo de datos correspondiente al caso computacional C.
Parameters
* hdw(l) headway de las lineas /1=10, 2=5, 3=1 2/ fr(l) frecuencia de las lineas cap(l) capacidad de cada linea (DEL TREN) /1=2000, 2=2000, 3=2000, 4=2000, 5=2000, 6=2000, 7=2000/ line(i,l,ll) parametro que indica coincidencia de lineas en nodos Mean_speed "Velocidad media de los trenes en km/h" /60/ hdvalue(hd) /1=2,2=3,3=4,4=5,5=6,6=10,7=12,8=15,9=20/ llenght(l) longitud de la linea l ckm_loc coste variable de operacion de la linea (€ por Km plaza y hora) dependiente de la capacidad y frecue ncia /34/ ckm_carr Coste variable de operacion de la linea (€ por Km plaza y hora) dependiente de la capacidad y frecue ncia /2/ cost_loc Coste de compra de una locomotora por 1E6 /2.5/ cost_carr Coste de compra de un vagon por 1E6 /0.9/ Horizonte horizonte para imputar costes de compra de rolling stocks medido en años /50/ cap_vagon cap de un vagon /200/ Vmax Maximum of set V /20/ sft headway de seguridad entre trenes /1/ dwt tiempo de espera en la estacion /1/ theta_one Monetary value of travel time /1/ theta_two Monetary value of transfers /10/ * theta_three Monetary value for variable cost s per km /10/ theta_four Monetary value for variable costs per hour /40/ * theta_five Monetary value for purchases /200 / ;
Anexo: Códigos de Programación en GAMS
157
* 2 3 4 5 6 10 12 1 5 20/ Table theta(hd,hdpr) variable de compatibilidad entre trenes en shared
tracks 1 2 3 4 5 6 7 8 9 1 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 0 1 5 0 0 0 0 0 0 0 0 1 6 0 0 0 0 0 0 1 1 1 7 0 0 0 0 0 1 1 1 1 8 0 0 0 0 0 1 1 1 1 9 0 0 0 1 1 1 1 1 1 ;
Parameters
ORIG(w) Origen de cada par O_D DEST(w) Destino de cada par O_D
* orige(st) Nodo de origen en el tramo compa rtido st * desti(st) Nodo destino en el tramo compart ido st g(w) Volumen a mover en el par w size1 size2 size3 tam1 tam2 tam3 ahorro_var1 ahorro_var2 ahorro_var3 Tabla(i,w) Tabla2(i,w,l) Tabla3(w,l);
Sets
ijl(i,j,l) Solo aquellas combinaciones de arcos y lineas existentes il(i,l) Solo aquellos pares o combinaciones de nodos y lineas existentes illl(i,l,ll) Solo aquellos nodos que comparten lineas (combinaciones existentes) ijlll(i,j,l,ll) Solo aquellos arcos que comparten lineas lll(l,ll) Solo contiene pares de lineas que coinciden en algún arco * s(i,j) Tramos compartidos por más de una línea ls(i,j,l) Líneas que recorren el tramo compartido entre el nodo i y el nodo j wijl(i,j,w,l) Solo aquellas combinaciones de pares arcos y lineas existentes willl(i,w,l,ll) Solo aquellas combinaciones existentes de verdad
Anexo: Códigos de Programación en GAMS
158
* f(i,j,w,l) gagagaga * ttt(i,w,l,ll) aaaaa wijlll(i,j,w,l,ll) wnod(i,w) wnodlin(i,w,l) wlin(w,l) chklink(i,j) ;
ijl(i,j,l)$(linkrt(i,j,l))= yes; il(i,l)$(nodert(i,l))= yes; illl(i,l,ll)$(nodert(i,l) and nodert(i,ll) and ord(l) <> ord(ll))= yes; ijlll(i,j,l,ll)$(linkrt(i,j,l) and linkrt(i,j,ll) and ( ord(l) < ord(ll)) and ( ord(i) < ord(j)))= yes; lll(l,ll)$( sum(ijlll(i,j,ln,lnn)$( ord(l)= ord(ln) and ord (ll)= ord(lnn)),1)>0)= yes;
wijl(i,j,w,l)$(linkrt(i,j,l) and arcopar(w,i,j))= yes; willl(i,w,l,ll)$(( sum(j$(linkrt(j,i,l)),arcopar(w,j,i))>0) and nodert(i,ll) and ( ord(l) <> ord(ll)))= yes; wijlll(i,j,w,l,ll)$(wijl(i,j,w,l) and wijl(i,j,w,ll))= yes;
Tabla(i,w)=0; Tabla(i,w)=1$( sum(j$(ij(i,j)),arcopar(w,i,j)+arcopar(w,j,i))>0);
Tabla2(i,w,l)=0; Tabla2(i,w,l)=1$(Tabla(i,w) and nodert(i,l));
Tabla3(w,l)=0; loop(ij(i,j), loop(w, loop(l, if((wijl(i,j,w,l)), Tabla3(w,l)=1;);
); ); ); display Tabla, Tabla2,Tabla3;
wnod(i,w)$(Tabla(i,w))= yes; wnodlin(i,w,l)$(Tabla2(i,w,l))= yes; wlin(w,l)$(tabla3(w,l))= yes;
size1= card(wijl); size2= card(willl); size3= card(wlin);
tam1= card(i)* card(j)* card(w)* card(l); tam2= card(i)* card(l)* card(w)* card(ll); tam3= card(w)* card(l);
ahorro_var1=tam1-size1; ahorro_var2=tam2-size2; ahorro_var3=tam3-size3;
Anexo: Códigos de Programación en GAMS
159
display ahorro_var1, ahorro_var2, ahorro_var3;
option ijlll:0:2:2; option illl:0:1:2; option ijl:0:2:1;
*display ijl,illl,ijlll,lll; display wijl,willl,wijlll;
; Scalars
DemScala Escala para aumentar demanda entre pares /5/ ; * Rellenando origen y destino de cada par loop(w, loop(i, loop(j, if(pair(i,j)= ord(w), ORIG(w)= ord(i); DEST(w)= ord(j);
g(w)=demanda(i,j)*DemScala; ); ); ); );
* rellenando numero de personas a mpver en cada par Display ORIG,DEST,g; Display linkrt,nodert;
*fr(l)=60/hdw(l); line(i,l,ll)=0; loop(i, loop(l, loop(ll, if((nodert(i,l)=1 and nodert(i,ll)=1), line(i,l,ll)=1;
); ); ); ); Display line; loop(i, loop(j, loop(t, if(st(i,j,t), loop(l, ls(i,j,l)= yes$(linkrt(i,j,l));
); ); );
Anexo: Códigos de Programación en GAMS
160
); ); display ls;
parameter nlin(k)
llenghtpar(w) Tciclo(l); nlin(k)= sum(l$(nodert(k,l)), nodert(k,l)); display nlin; llenght(l)= sum(ij(i,j)$ijl(i,j,l),dis(i,j)); display llenght,wnod,wnodlin,wlin; llenghtpar(w)= sum(ij(i,j)$arcopar(w,i,j),dis(i,j))/3; display llenghtpar;
Tciclo(l)=2*llenght(l)*(60.0/Mean_speed); display tciclo; chklink(i,j)= yes$(ij(i,j) and dis(i,j)<>dis(j,i)); display chklink;
scalar Wtotal; Wtotal= sum(w,g(w)); Display Wtotal;
Anexo: Códigos de Programación en GAMS
161
• Archivo de definición de variables, “Network Loading Model 2 Variables.gms” Positive Variables
* fijwl(i,j,w,l) i-j-w-l Demand corresponding to w that uses link (i-j) using line l* fijl(i,j,l) i-j-l Demand corresponding to all o-d pairs that uses link (i-j) using line l fijw(i,j,w) i-j-w Demanda del par w agregada sobre el arco ij para todas las lineas fwl(w,l) w-l f(i,j) i-j tr(i,w,l) i-w-l Proportion of the demand of pair w that transfers to line l at node i trr(i,w,l,ll) i-w-l-ll Proportion of the demand of w that transfers form l to ll at node i taver(w) Average travel time corresponding to pair w capvar(l) Capacity as variable aunque tambien esta modelado en funcion de numero vagones frvar(l) frequency as variable for each line hdwvar(l) hdwls(l,t,i,j) headway de una linea l en un track t del segmento compartido entre nodos i-j notatdem(w) Demanda no atendida para par w ;
Positive variable
Totaldemnotat Total de demanda no atendida ; Free variable TotFO
; Binary variables
hdwfix(hd,l) sirven para fijar el valor de hdwvar delta(l,t,i,j) no nulo si se asigna la línea l a la vía t del segmento compartido desde el nodo i hasta el nodo j ; Binary variables y(i,j,w,l) se usan para evitar movimientos de flujo
en ambos sentidos de un link para un mismo trayecto ; hdwvar.lo(l)=hdvalue( '1' ); hdwvar.up(l)=hdvalue( '9' ); hdwls.lo(l,t,i,j)=0; hdwls.up(l,t,i,j)=hdvalue( '9' ); Integer variables
nv(l) número vagones de linea l fleet_size(l) number of trains needed for line l ; nv.lo(l)=0; nv.up(l)=8; hdwvar.lo(l)=2; hdwvar.up(l)=20; frvar.lo(l)=2; frvar.up(l)=30;
Anexo: Códigos de Programación en GAMS
162
• Archivo de restricciones del modelo, “Network Loading Model 2
Constraints.gms” *Ecuación 5 Equation no_dos_direcciones_par_link(i,j,w,l,ll) se ; no_dos_direcciones_par_link(i,j,w,l,ll)$(( ord(i) < ord(j)) and
(wijlll(i,j,w,l,ll)))..y(i,j,w,l)+y(j,i,w,ll)=l=1; *Ecuación 6 Equation bounding_flows(i,j,w,l) se ;
bounding_flows(i,j,w,l)$(wijl(i,j,w,l))..fijwl(i,j, w,l)=l=y(i,j,w,l)*g(w); *Ecuación 1 Equation Output_from_origin(w) Outgoing flow from pair
origins w ; Output_from_origin(w).. sum(l$(wlin(w,l)), sum(ij(i,j)$(( ord(i)=ORIG(w)) and wijl(i,j,w,l)),fijwl(i,j,w,l)))+notatdem(w)=e=g(w) ;
*Ecuación 2 Equation Input_at_destination(w) Ingoing flow at pair
destination w ; Input_at_destination(w).. sum(l$(wlin(w,l)), sum(ij(i,j)$(( ord(j)=DEST(w)) and wijl(i,j,w,l)),fijwl(i,j,w,l)))+notatdem(w)=e=g(w) ;
*Ecuación 3 Equation Flows_balance(k,w) Flow balance at nodes k w ; Flows_balance(k,w)$(( ord(k) <> ORIG(w)) and ( ord(k) <> DEST(w)) and
(wnod(k,w))).. sum(l, sum(j$(ij(j,k) and wijl(j,k,w,l)),fijwl(j,k,w,l)))=e= sum(l, sum(u$(ij(k,u) and wijl(k,u,w,l)),fijwl(k,u,w,l)));
*Ecuación 4 Equation Transfers_balance(k,w,l) Flow balance at nodes kwl ; Transfers_balance(k,w,l)$(( ord(k) <> ORIG(w)) and ( ord(k) <> DEST(w)) and (nlin(k) > 1) and (wnodlin(k,w,l))).. sum(j$(ij(j,k) and (wijl(j,k,w,l))),fijwl(j,k,w,l))+ sum(ll$(( ord(ll) <> ord(l)) and (willl(k,w,ll,l))),trr(k,w,ll,l))=e= sum(j$(ij(k,j) and (wijl(k,j,w,l))),fijwl(k,j,w,l)) + sum(ll$(( ord(ll) <> ord(l)) and
(willl(k,w,l,ll))),trr(k,w,l,ll));
*Ecuación 7 Equation Agregacion_flujos_salida_por_linea(w,l) se agregan los flujos
de todos los pares sobre un arco de salida del orig en; Agregacion_flujos_salida_por_linea(w,l)$(wlin(w,l)) ..fwl(w,l)=e= sum(ij(i,j)$( ord(i)=ORIG(w) and wijl(i,j,w,l)),fijwl(i,j,w,l));
Anexo: Códigos de Programación en GAMS
163
*Ecuaciones 10 Equation frequency ecuación que fr y sus posibles valores ; frequency(ln)..hdwvar(ln)=e= sum(hd,hdwfix(hd,ln)*hdvalue(hd));
Equation valores ecuacion que impone que solo se tome un valor ; valores(ln)..1=e= sum(hd,hdwfix(hd,ln));
***SHARED TRACKS*** *Ecuación 11 Equation line_allocation(i,j,l) situa cada linea en una unica via ; line_allocation(i,j,l)$(ls(i,j,l))..1=e= sum(t$(st(i,j,t)),delta(l,t,i,
j));
*Ecuación 12 Equation frequency_for_track(i,j,l) frecuencia de cada línea en el
track correspondiente ; frequency_for_track(i,j,l)$(ls(i,j,l))..hdwvar(l)=e =sum(t$(st(i,j,t)),
hdwls(l,t,i,j));
*Ecuación 13 Equation constr_frequency(i,j,l,t) Obliga escoger una única frecuencia
positiva ; constr_frequency(i,j,l,t)$(ls(i,j,l) and
st(i,j,t))..hdwls(l,t,i,j)=l=Vmax*delta(l,t,i,j);
*Ecuación 14 Equation safetyhdw_dwell_time(i,j,t) Headway de seguridad y tiempo
espera ; safetyhdw_dwell_time(i,j,t)$(st(i,j,t)).. sum(l$(ls(i,j,l)),hdwls(l,t,i
,j)*(sft+dwt))=l=60;
*Ecuación 15 Equation frequencies_compatibility(i,j,t,l,ll,hd,hdpr) Compatibilidad
entre frecuencias de trenes en tramos compartidos ; frequencies_compatibility(i,j,t,l,ll,hd,hdpr)$(ls(i ,j,l) and ls(i,j,ll) and st(i,j,t) and ( ord(l) < ord
(ll)))..delta(l,t,i,j)+delta(ll,t,i,j)=l=3+theta(hd ,hdpr)-(hdwfix(hd,l)+hdwfix(hdpr,ll));
*Ecuacion 16 Equation Frequency_and_cap(i,j,l) Linking frequency and capacity
(link to link) ; Frequency_and_cap(i,j,l)$(ijl(i,j,l))..( sum(w$(wijl(i,j,w,l)),fijwl(i,
j,w,l)))*hdwvar(l)=l=60*cap_vagon*(2+nv(l));
Anexo: Códigos de Programación en GAMS
164
Equation Frequency_and_head1(l) Linking frequency and capacity
(link to link) ; Frequency_and_head1(l)..hdwvar(l)*frvar(l)=l=60+0.0 5; Equation Frequency_and_head2(l) Linking frequency and capacity
(link to link) ; Frequency_and_head2(l)..hdwvar(l)*frvar(l)=g=60-0.0 5;
Equation obj total cost ; obj.. TotFO=e=(1/10000)*( sum(w,5*1E6*notatdem(w))+
* coste variable por km sum(l,2*llenght(l)*frvar(l)*(ckm_loc+ckm_carr*(nv(l)+1 )))
* coste de tripulaciones + theta_four* sum(l,2*llenght(l)*frvar(l)/Mean_speed)
* coste por compra de flota + (1E6/(Horizonte*365*24))* sum(l,2*llenght(l)*(frvar(l)/Mean_speed)*(2*c
ost_loc + nv(l)*cost_carr)) * Penalizacion por transfers + theta_two* sum(l, sum(ll$( ord(l) <> ord(ll)), sum(w$(wlin(w,l) and wlin(w,ll)), sum(i$(willl(i,w,l,ll)),trr(i,w,l,ll) ))) ) + theta_one* sum(w$(g(w) >0),( sum(l$wlin(w,l), sum(ij(i,j)$(wijl(i,j,w,l)),(60/Mean_speed)*dis(i,j)*f ijwl(i,j,w,l))
+ fwl(w,l)*hdwvar(l)/2 + sum(i, sum(ll$(( ord(l) <> ord(ll)) and
willl(i,w,l,ll)),trr(i,w,l,ll)*hdwvar(ll)/2))))) );
Recommended