Determinación de Frecuencias y Capacidades Óptimas en ...

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





Tránsito Rápido





Universidad de Sevilla

Sevilla, 2015






3





Tránsito Rápido

Autor:

José Antonio Quirós Alés

Tutor:

José David Canca Ortiz

Profesor titular



Universidad de Sevilla

Sevilla, 2015

5

Proyecto Fin de Carrera: Determinación de Frecuencias y Capacidades Óptimas en Redes Densas de Ferrocarril de Tránsito Rápido



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


Alpha ECP. Caso computacional B (12 nodos y 56 pares O-D) ................................... 98


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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:


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



ser compatible y para ello dichas frecuencias no pueden ser altas. Otra



Aún con esto la condición de multiplicidad no es completamente exigible,



multiplicidad es un requisito recomendable pero no obligatorio.

lladas frecuencias de paso compatibles para las líneas que pueden



erido a una correcta atención de la demanda o la dificultad de



mación circunstancial que posiblemente condicionará la

circulación de los trenes durante un cierto intervalo de tiempo.


con beneficios muy interesantes pero con ciertos condicionantes de funcionamiento a



inherentes a cada caso particular.

rápido por ferrocarril. Segmentos compartidos.



ser compatible y para ello dichas frecuencias no pueden ser altas. Otra condición que



Aún con esto la condición de multiplicidad no es completamente exigible, ya que a



lladas frecuencias de paso compatibles para las líneas que pueden



erido a una correcta atención de la demanda o la dificultad de



mación circunstancial que posiblemente condicionará la


antes de funcionamiento a



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.


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.


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)


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.


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


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


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).


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.


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”.


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


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.


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


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.


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:


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.


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”).


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


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).


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


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.


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


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:


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.


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.


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


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


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.


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.


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.


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


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).


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


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


• Prueba computacional C: caso de red de tránsito rápido por ferrocarril de 36


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


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


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


73

1.2 Prueba computacional B: red de tránsito rápido por ferrocarril de 12


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:



• 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


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


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:



• 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:


76



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:


77


1.3 Prueba computacional C: red de tránsito rápido por ferrocarril de 36


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:


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:



• 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.


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 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


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:



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


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.


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:


83


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).


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


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.


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.


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.


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.


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).


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 :


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



Número de vagones

para los ferrocarriles de cada línea (incluyendo

locomotoras)

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




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 -


L1-10 minutos L2-12 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


-


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



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 - -





- -

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.


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.


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.


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.


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.


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:


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


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.


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).


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 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.


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.


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:


103


computacional B.



Ahorro

fijwl(i,j,w,l) 40320 231 40089

fwl(w,l) 280 132 148

trr(i,w,l,ll) 16800 187 16613


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.


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.


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).


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 4: headway de 12 minutos entre ferrocarriles, por lo que tiene una

frecuencia de 5 trenes a la hora.


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).


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)


(headways de

línea en minutos)


(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)

- -


-

31-32 (2) Línea 3 (10) Línea 6 (20)

Línea 7 (5) -


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)


(headways de

línea en minutos)


(headways de

línea en minutos)


(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)


-


-

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)

- -


-


-

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).


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.


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.


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.


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.


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:


computacional C.



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.


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


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


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 €











Tamaño de los ferrocarriles de cada

línea (incluso locomotoras)


L7-10 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


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


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


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 €


656.780,23 € 695.388,03 € 756.600,97 €

M4-FO Coste tripulaciones

8.867,27 € 9.493,42 € 10.362,02 €


de material rodante

5.577,66 € 5.838,48 € 6.331,37 €











Tamaño de los

ferrocarriles de cada línea (incluso locomotoras)



L7-10 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.


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.


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.


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)*


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 €


1.919.456,23 € 2.826.740,32 € 3.750.392,25 €


596.300 € 598.100 € 598.100 €


546.352,33 € 588.589,10 € 604.176,10 €


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 €








L1-20 minutos L2-5 minutos L3-10minutos L4-12 minutos L5-4 minutos



119

Tabla 2.11 (Continuación) Resultados análisis computacional para la

modificación del peso monetario correspondiente a tiempo de viaje, primera parte.






L7-10 vagones



L7-10 vagones

L1-7 vagones L2-10 vagones L3-7vagones


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


Sí Sí

Tiempo de resolución 1956,94 seg. 2.085,02 seg.

Valor FO 5.896.231 € 6.828.645 €


4.662.068,98 € 5.594.482,98 €


598.100 € 598.100 €

M3-FO Coste operación

ferrocarriles 622.209,06 € 622.209,06 €


8.867,27 € 8.867,27 €


de material rodante

4.985,69 € 4.985,69 €











L7-10 vagones


L7-10 vagones


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).


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;


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/ ;






runtime = (jnow - starttime)*24*3600; ******** Cargando resultados de forma cómoda parameter fwlij(w,l,i,j),trwilll(w,i,l,ll);


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)));


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




******* 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;


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/ ;






runtime = (jnow - starttime)*24*3600; ******** Cargando resultados de forma cómoda parameter fwlij(w,l,i,j),trwilll(w,i,l,ll);


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));


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




******* 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;


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 ;


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 ;


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 ;


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 ;


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;);

); ); );


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);


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;


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 ; ;


; 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 ;


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


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


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;




144


); ); ); display Tabla, Tabla2,Tabla3;


size1= card(wijl); size2= card(willl); size3= card(wlin);


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



* rellenando numero de personas a mpver en cada par Display ORIG,DEST;


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,


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;




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 ; ;


; 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));


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


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 ;


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


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

;


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


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

;


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


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


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 / ;


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


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;




); ); ); display Tabla, Tabla2,Tabla3;


size1= card(wijl); size2= card(willl); size3= card(wlin);


ahorro_var1=tam1-size1; ahorro_var2=tam2-size2; ahorro_var3=tam3-size3;


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



* 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));

); ); );


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;




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;


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));


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));


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))))) );

Determinación de Frecuencias y Capacidades Óptimas en ...

Documents

Transcript of Determinación de Frecuencias y Capacidades Óptimas en ...