Reprise en main du programme d Affectation de transport en commun Modifications indispensables pour bonne compilation : Utilisation de visual C++ express pour avoir accès à un débuggeur et un compilateur puissant (permet de détecter plus d erreurs et donc faire les modifications plus rapidement) Rajout des fichiers d entête.h pour tous les fichiers.cpp du programme. En effet, pour l édition des liens et pour plus de clartés, il est préférable de séparer distinctement les différentes fonctions du programme et de créer les dépendances entre les fichiers uniquement à travers les fichiers d entête (#include toto.h). Par la suite ces fonctions seront insérées dans des classes pour une plus grande portabilité et un code orienté objet. Distinction physique (au niveau des répertoires et des projets compilés) des 2 sous programmes «Construction du réseau» et «affectation au réseau». Ce qui se traduit sous Visual par la création de 2 projets avec chacun un main() qui permet la création de 2 exécutables. Le programme avait initialement 2 main() pour un seul exécutable compiler. Il ne peut y avoir en C++ qu un seul main par projet et donc par exécutable. Piste à discuter : transformer la construction du réseau en une librairie dynamique (.dll sous windows ou.o sous Linux) qui sera appelée dans le programme principale d affectation par le biais d une fonction par exemple contruit_reseau( ). Une librairie dynamique doit être utilisée ici car elle permet de ne pas avoir à recompiler le programme quand on a modifié celle-ci. Toutes les variables du programme sont changées de variables globales en variables locales. En effet, le fait de définir les variables en globale peut amener des confusions au niveau des noms de variables ( i était défini en variable globale et redéfini en variable locale) et donc à des erreurs. Les variables spécifiques du programme sont déclarées dans la fonction principale et ensuite rajoutées en paramètres dans les différentes fonctions où elles sont appelées. Modification de la classe AssisDebout qui était «étalée» sur plusieurs fichiers pour des questions de dépendances. Création de fichier.cpp et.h correspondant uniquement à la classe AssisDebout. Mise à jour un problème de dépendance entre les fichiers «ClassesRéseau», Confort et AssisDebout qui dépendent les uns des autres sans hiérarchie. Création d un destructeur pour détruire tous les pointeurs qui n étaient jamais détruits Beaucoup de paramètres du programme sont déclarés statiquement donc dès le lancement du programme, on réserve de la mémoire (sur la pile) pour toutes les variables jusqu à la fin de l exécution du programme. Ce qui nécessite beaucoup de mémoire vive. Le mieux est donc (quand cela est possible) de créer ces variables localement dans les fonctions dynamiquement et de les détruire dès que l on en a plus besoin pour libérer de la mémoire. Pour le moment, la solution intermédiaire est d augmenter la taille de la pile pour que toutes les variables puissent avoir une mémoire réservée. (Sous Visual la taille de la pile est de 1Mo augmentée pour nos besoins à 2Go pour être sûr que ça passe) Dans les classes «classes_reseau» rajout de constructeurs par défaut là où c était indispensable pour les déclarations de classe. Problème qui a été difficile à résoudre : la fonction add de la classe IntChaine déclare localement un nouveau pointeur sur une classe IntChaine, mais sans détruire ce pointeur par la suite. Cela permet de garder en mémoire les IntChaine même en sortant de la classe. Pour résoudre ce problème de fuite 1
mémoire, la solution n est donc pas de rajouter un delete dans la classe car alors on détruit le pointeur local qui a remplacé le pointeur global lors de la nouvelle déclaration. On perd donc tout en sortant de la classe. Pour résoudre ce problème, il faut donc sortir de la classe la déclaration de ce nouveau pointeur IntChaine et le détruire juste après être sorti de la classe pour ne pas le garder en mémoire au prochain appel. Amélioration immédiates apportées : Création des répertoires de sortie automatique, commandes différentes suivant le système d exploitation utilisé (pour pouvoir permettre une compilation sous Windows et linux). En effet, l utilisateur devait créer le répertoire de sortie avant d exécuter le programme sinon il n obtenait aucun résultat. Le programme peut donc être compilé puis exécuté sous Linux ou Windows. Tous les objets dynamiques créés sont détruits à la fin du programme. Création d un fichier de paramètres en anglais avec les liens vers les données d entrée et vers le répertoire parent du répertoire de sortie et les paramètres du programme. Les paramètres des modèles (FF et confort) et le nombre d itérations maximales ainsi que le GAP sont rajoutés au fichier. Pour l instant, les paramètres de taille maximale de stockage sont restés dans le fichier des constantes (en.h) qui doit, à terme, disparaître. L affichage des exécutables est en anglais. Piste pour optimisation : La partie du programme qui construit le réseau écrit dans des fichiers les variables du réseau qu elle a extraite des fichiers d entrée. Le programme principal lit à son tour ces fichiers pour recharger ces mêmes variables. Le fait d écrire et de lire dans des fichiers est assez long surtout que la taille des fichiers pour charger un réseau est assez conséquente. L idée est donc d appeler directement une fonction charger_reseau() dans le programme d affectation qui serait l équivalent du main() de la partie de la construction du réseau avec en paramètre les variables utiles au programme sans avoir à les écrire dans un fichier. Faire tourner les logiciels Purify et Quantify sur le code. Le premier permet de détecter les fuites mémoires et donc les sources de bugs et le deuxième le nombre de fois et le temps passé dans chaque boucle et fonction, très utile pour une optimisation du temps de calcul. Déjà fait ou en cours pour l optimisation : L allocation dynamique dans chaque fonction au lieu d une allocation externe donc globale permet à l ordinateur de ne s occuper dynamiquement uniquement des variables dont il a besoin et non de toutes les variables actives en permanence dans l exécution du programme. On arrive à 1100s Le nombre d opération dans beaucoup de fonction appelée plusieurs millions de fois a été réduites autant que possible pour réduire le temps de calcul. (dans le calcul de la stratégie optimal, le rapport des fréquences de Spiess et Florian était calculé 10 fois dans une même boucle). De plus la fonction RS qui calcule la différence entre 2 valeurs +1 est appelée de nombreuses fois pour retourner la valeur 0 ou plusieurs fois la même valeur dans la même boucle. Après ces évolutions, on passe à 840s d exécution. 2
On arrive à 770s en détruisant la pile de stockage pour calculer le plus court chemin tout les 20000 ars au lieu de tous les 2000 arcs ; en effet, la destruction de la pile est très longue. C est pourquoi, après plusieurs essais, on décide de supprimer la réallocation et la destruction partielle de mémoire à la Heap en cours de traitement. On créée la Heap au début avec la taille maximale qu elle peut avoir et on la détruit quand on en a plus besoin. Cela permet de réduire le temps de calcul. Gestion des fuites mémoires : On utilise le logiciel de détection de fuites mémoires Valgrind sous LINUX. Avec l exécution du programme d affectation, on lance le logiciel, qui renvoie un rapport d erreurs avec le nombre d octets victimes de fuites mémoires. Les erreurs principales outre les non destruction de pointeur, sont les mélanges entre les molloc, realloc et les deletes. La principale erreur, celle qui faisait planter le programme pour dépassement de mémoire est la suivante. Lors de la fonction du calcul de la solution optimale, on créée une Heap binaire qui a la taille du nombre d arc et que l on détruit à la fin de la fonction. Le problème est que l on peut sortir de la boucle qui calcule la stratégie optimale en cours de traitement avec la fonction return au lieu de la fonction break ce qui fait qu il ne passait pas par la destruction de la pile d où le dépassement de mémoire. Problème d intégration de la gestion du coût lié au confort sur les arcs. Expliqué dans un document annexe «Integration_Assis_Debout» Amélioration ou modification apportées après Dans la lecture des données, quand la capacité n est pas renseignée dans le fichier capacites.txt, sur une ligne, le nombre de places assise est fixée à la capacité par défaut soit 99999 et la capacité au double du nombre de places assises. Pour éviter les confusions dans l affectation avec l option de confort, on fixe le nombre de places assises à 0. Architecture orientée objet (C++) Le programme actuel est codé en C++ mais sans utilisé le principe des classes. La réarchitecture du code peut donc être très lourde. A l étude Ci-dessous : Diagramme succin des fichiers de fonctions utiles pour la construction du réseau. 3
Ci-dessous : pareil pour le programme d affectation. 4
Intégration du modèle de confort Assis/Debout dans le programme d affectation Introduction Le programme d affectation programmé par Askoura doit prendre en compte la gestion du confort lié à la possibilité d être assis ou non dans un véhicule. Le calcul sur une ligne de la probabilité d être assis ou debout, le coût résultant entre 2 station d une ligne est déjà codé. Le problème est que pour chaque arc réel du réseau, si l arc est un arc de ligne on charge sur cet arc le coût d être assis/debout sur cet arc. Cela implique que sur un arc donné, le coût de cet arc sera le même pour une personne qui est rentré en tête de ligne et qui a une probabilité très forte d être assise et une personne qui vient de rentrer et qui à une probabilité très forte d être debout. La solution est donc de créer des arcs virtuels qui correspondent au trajet entre chaque arc d une ligne (voir «Passenger Confort and Route Choice in Urban Transit» Leurent, Liu) Mise en œuvre informatique Toutes les modifications suivantes ne sont effectives que dans le cas où l utilisateur choisit de prendre en compte le confort. La première étape est la création d un objet Arc_virtuel. On utilise la classe ArcClass qui permet de gérer les arcs réels. Les fonctions membres et les attributs utilisés sont les mêmes. On rajoute seulement un attribut Id_Arc_Reel qui permet de faire correspondre un arc réel avec un arc virtuel quand ils sont identiques (les arcs boarding, alighting, rabattement et transfert) et 2 opérateurs pour faciliter la création des arcs virtuels : le + qui permet de mettre deux arcs bout à bout et le = qui permet la création immédiate d un arc virtuel qui aura les mêmes caractéristiques que l arc réel. On crée un fichier qui contient spécifiquement les fonctions liées au chargement et au traitement des arcs virtuels. Description des fonctions créées : NCArc_Virtuel_Create( ) : Fonction de création des arcs virtuels à partir de la liste des arcs réels. Si les arcs ne sont ni stationnement D ni interstation S, on a juste à copier les attributs de l arc réel sur l arc virtuel (avec l opérateur «= «) Sinon, il faut créer sur chaque ligne des arcs virtuels qui relient tous les nœuds de la montée à la descente 2 à 2. Pour chaque arc réel d interstation, on parcourt la ligne associée jusqu à la fin de la ligne. Tous les 2 arcs, on créée un arc virtuel, ce qui correspond à chaque descente de ligne comme montré sur le schéma suivant. Sur la première ligne, la ligne à laquelle appartient l arc et dessous tout les arcs créés à partir de cette arcs jusqu à la fin de la ligne. 5
S D S S On fait de même pour tout les arcs de type S interstation et on obtient tous les arcs virtuels. Il n y a donc plus d arc de stationnement, en effet quand on emprunte une ligne on prend directement l arc virtuel qui part de notre arc de montée sur la ligne jusqu à notre arc de descente. On n emprunte donc qu un seul arc par ligne. Virtual_aminus_Create( ) : sur le même modèle que la création des aminus pour les arcs réels. On créée donc des objets de même type : SetClass. Arc_Virtuel_Calcul_Cost( ) : Le coût par arc virtuel et le flux par arc sont chargés dans cette fonction à partir des legs sur lesquels on vient de calculer le coût et le flux. On fait par ligne pour chaque arc virtuel en décomposant pour faire la correspondance avec les legs. OrderTab_Virtual_Arc_To_arc( ) n est pas utilisé. Permet de créer la liste des arcs virtuels parcourus suivant la stratégie optimale. FF_Arc_To_Virtual_Arc( ) simple : si on a un arc virtuel boarding, on charge la fréquence effective de l arc réel correspondant. Modification des fonctions existantes : Pour plus de clarté, le nombre de modification impose de créer un nouveau fichier «proc_affect_confort» sur le modèle de «proc_affect» mais pour traiter les arcs virtuels. On modifie donc dans ce fichier les fonctions d affectation du flux et le calcul de la stratégie optimale. Les fonctions qui calculent la fréquence effective ne sont pas modifiées, on calcule toujours la fréquence effective le long de ces arcs. On copie ensuite la fréquence obtenue des arcs réels vers les arcs virtuels. Le calcul de la stratégie optimale se fait avec les arcs virtuels. Il faut donc pouvoir avoir tous les arcs virtuels entrant dans chaque nœud. C est pourquoi on créée une fonction qui charge dans une structure «aminus_virtual» ces arcs sur le modèle des «aminus» des arcs réels. De même pour le calcul du coût des éléments de la heap, on utilise dorénavant le coût des arcs virtuels. (Modifications dans «insereheap» et «SupprimeMax») Toujours dans le fichier proc_affect_confort.cpp, on modifie l affectation du flux. Affect_flux_confort() A partir des Arcs virtuels de la stratégie optimale, on charge le flux par arc réel car le flux ne peut être qu explicite par rapport à la capacité qu en fonction des arcs réels. La difficulté réside dans le fait qu on peut passer plusieurs fois par le même arc réel. 6
Il faut donc créer des volumes de stockages intermédiaires pour pouvoir garder le flux qui monte dans un véhicule et qui descend : volume_boarding et volume_alighting. Pour les arcs de transfert et de rabattement on charge directement sur l arc réel le flux à partir du nœud amont, en effet sur ces arcs on ne passera qu une seul fois. Pour les arcs boarding, on charge de même le flux sur l arc réel mais on initialise volume_boarding avec ce flux. Si on a un arc virtuel de type interstation, on rajoute le flux qui vient de monter (volume_boarding) sur tous les arcs qui correspondent à l arc virtuel. On charge à la fin de l arc virtuel volume_alighting, le flux qui descend à cette station. On peut donc charger pour les arcs de descente volume_alighting : le flux qui est descendu à cette station de la ligne. Pour les flux totaux par arc et le volume total par nœud, on fait comme avec les arcs réels. Aucune modification dans Assis_Debout. Et dans «Confort.cpp», dans la fonction Record_Existing_Stop(), on utilise les arcs virtuels et non les réels pour connaître le nœud de descente. Dans la fonction Record_Boadrding_Flow(), on enregistre un flux sur un leg qui correspond à un flux sur un arc virtuel. Il faut connaître le nombre de nœud sur la ligne avant le nœud d origine et le nombre de nœud du début de la ligne jusqu à la destination. On décompose donc les arcs virtuels en arcs réels pour avoir tous les nœuds d une ligne. On fait de la même manière le calcul du coût du confort sur un arc virtuel à partir du coût des legs. Dans la fonction Confort_Cost() qui calcule le coût sur un arc donné à partir des legs, on a un arc virtuel en entrée. Il faut donc faire correspondre l arc virtuel avec le leg correspondant. On fait de la même manière que précédemment. 7
8