Implémentation du covoiturage

[matt-gau]

Implémenter le covoiturage en se basant sur le mode TIM

• Modéliser un mode par taux d'occupation : carpool2, carpool3, carpool4 sont trois modes différents
• Création de carpoolN_travel_costs basé sur car_travel_costs avec +(5% et 1km/5min) de détour par passager
• Tests avec une fonction d'utilité modifiée (prise en compte des couts + du temps) : @FlxPo je veux bien que tu me dises les valeurs que tu utilises (pour cost_of_time et couts kilométriques puis pour les beta)
• En ajustant fonction d'utilité, s'approcher des taux obtenus avec EDGT-MRMT

[FlxPo]

Peux tu récupérer le code de la branche add-switzerland pour faire ce travail ?

La dernière version de la fonction d'utilité est ici, et prend la forme : U = 2 * cost_of_time(travel_distance) * travel_time + 2 * cost_of_distance * travel_distance + crossborder_utility(origin, destination).

Tu devrais donc pouvoir ajuster travel_distance et travel_time pour obtenir ce que tu veux. Comme discuté ensemble on pourrait aussi faire en sorte que le calcul d'utilité soit géré de manière indépendante pour chaque mode, mais ça peut être dans un deuxième temps.

[matt-gau]

J'ai codé CarpoolTravelCosts sur la branche modus-geneve, mais je ne peux pas la push car je n'ai pas les droits (du coup GitHub me propose de faire un fork mais ca ne va pas si ?). Comment peut on faire (notamment pour que tu vois mon code en cas de besoin).

[FlxPo]

Quelques points en parcourant ton code :

• Il faut que tu sauvergardes les coûts dans un fichier parquet dans la fonction create_and_get_asset() de CarpoolTravelCosts (

  mobility/mobility/carpool_travel_costs.py

  Line 50 in 391e1cc

  def create_and_get_asset(self) -> pd.DataFrame:

  ).
• Il faut que tu ajoutes les coûts calculés pour le covoiturage aux autres couts pour bien les retrouver dans les résultats de MultiModalTravelCosts (

  mobility/mobility/multimodal_travel_costs.py

  Line 63 in 391e1cc

  def create_and_get_asset(self) -> pd.DataFrame:

  ).

[matt-gau]

J'ai commit ces changements et push la branche (et publié une branche carpool-run dans mobility-grand-geneve), par contre ca s'arrete toujours sur public_transport_travel_costs (il ne trouve pas le fichier parquet, et en fait il ne trouve pas le fichier : /Users/matthieugautrot/Documents/mobility_data/data_geneve/c95e7652fd8459a0460db3a1e1031122-gtfs_router.rds. Je te mets la console quand je demande d'afficher les commentaires de R (debug = True) si ca peut aider :
erreur-console.txt

De maniere générale j'ai encore du mal a saisir le fonctionnement global des fichiers dans le cache : par exemple si je veux créer une nouvelle instance d'une classe, je dois supprimer les fichiers deja presents dans mon dossier data_geneve ? (le cas echeant quand je fais un multimodal_travel_costs_carpool, ca va recuperer les fichiers dans le cache et pas en créer un nouveau non ? Pareil si je fais un transport_zones_test ?).
Merci Félix

[FlxPo]

Le cache sert à ne pas recalculer tout à chaque fois que tu executes ton script. Chaque classe de type Asset (TransportZones par exemple) stocke ses résultats lors de la première execution, résultats qui sont ensuite utilisés pour les runs suivants avec les mêmes inputs. Si tu changes les inputs, la différence est détectée automatiquement et le calcul est relancé.

Ce fonctionnement se propage de manière recursive pour être sur que toute la chaine de calcul a généré les données nécessaires et qu'elles sont enregistrées : MultiModalTravelCosts dépend de TravelCosts par exemple.

Tu peux forcer un recalcul en supprimant les fichiers dans le cache. Il y a deux type de fichiers, ceux qui sont générés par Mobility et utilisés quelque soit les zones de transport (données du recensement INSEE par exemple), et ceux qui sont spécifiques à un projet (les données des couts de transport par exemple).

Là dans ton log il y a visiblement un bug dans le script R prepare_gtfs_router.R. Peut être un fichier GTFS qui ne passe pas, mais j'ai un peu de mal à comprendre pourquoi ça ne marche plus d'un coup ?

[matt-gau]

Merci pour les explications. Pour savoir si je comprends bien, si je fais ca :

• travel_costs_2024 = mobility.MultimodalTravelCosts(transport_zones)
• trans_mode_cm_2024 = mobility.TransportModeChoiceModel(travel_costs_2024)
• modification de la classe MultimodalTravelCosts donnant un output différent
• travel_costs_2024_test = mobility.MultimodalTravelCosts(transport_zones)
• trans_mode_cm_2024_test = mobility.TransportModeChoiceModel(travel_costs_2024_test)

J'obtiendrai travel_costs_2024_test = travel_costs_2024 (vu que l'input est le meme on ne recréé pas de fichier et on en recalcule pas les couts) et donc trans_mode_cm_2024_test = trans_mode_cm_2024 c'est bien ca ?

Pour le soucis avec prepare_gtfs_router.R, c'est bizarre parce que je n'ai pas modifié ce qui touche aux gtfs.
En faisant des tests le script R de gtfs_prepare_router.R s'arrete en tentant d'executer cette ligne (fonction gtfs_timetable()). J'ai affiché ce que valait max_services_date(dans la console ca correspond aux lignes avec les dates "2024081920240826" etc.). Est ce ici qu'il y a un pb ? Je ne trouve pas la fonction gtfs_timetable :/
Voila la console :
erreur-console.txt

[FlxPo]

Oui tu obtiendras deux objets python différents, mais qui pointeront vers les même fichiers parquet.

Je viens de faire un certain nombre de modifications sur la branche add-switzerland, notamment pour mieux gérer les installations de packages R.

Après réinstallation complète de Mobility, j'ai effectivement le même problème que toi, je vais regarder ce qui cloche.

[FlxPo]

Je pense que j'ai trouvé. Les temps de transport pour les transports en commun sont évalués pour une journée donnée, qui est sélectionnée comme celle ayant le maximum de lignes en opération. Cela ne fonctionnait pas quand plusieurs jours avaient le même nombre de lignes en opération.

Cela devrait être corrigé dans la dernière version de la branche add-switzerland, peux tu ressayer ?

Pour info en mode debug j'ai ajouté des logs indiquant les arguments envoyés aux scripts R, ce qui permet ensuite de debugger plus facilement dans RStudio (il suffit de positionner args <- c(list, of, arguments, in, python, log) après args <- commandArgs(trailingOnly = TRUE)).

[matt-gau]

Merci. N'y a t il pas un pb avec ce que tu as rajouté pour les erreurs dans R ? J'obtiens cette sortie (que ce soit avec le run.py ou small_run.py) (je précise que debug=True ici) :
script_erreurs.txt

[FlxPo]

Trois pas en avant, deux pas en arrière ! Désolé.

Je pense que le problème est lié au changement de stratégie d'installation en cours de discussion avec @Mind-the-Cap dans cette issue.

Je viens de faire un push avec un fix potentiel, peux tu reessayer ?

Sinon il me semble que si tu as déjà les packages installés, un fix très temporaire serait de commenter la ligne qui lance le script d'installation.

[FlxPo]

@matt-gau je viens de faire un push sur add-switzerland pour permettre de gérer les coefficients du calcul d'utilité par mode, directement dans les paramètres de WorkDestinationModel. L'idée est que chaque classe correspondant à un motif calculera les utilités des OD à partir des résultats bruts de temps / distance envoyés par TravelCosts et PublicTravelCosts, en appliquant des éventuellement des hypothèses différenciées par mode.

[matt-gau]

J'ai réussi au début à faire tourner le code, mais pas depuis que j'ai rajouté le covoiturage comme on en avait parlé dans WorkDestinationChoiceModel et MultimodalTravelCosts, et j'ai modifié le fichier run.py également (j'ai commit et push mes changements dans carpool et carpool-run).

Je ne sais pas pourquoi, il ne trouve pas le fichier ...-work_utility_by_od_and_mode.parquet (cf la console erreur-console.txt). Quand je tente de débuguer je vois qu'il ne passe meme pas dans create_and_get_asset() de DestinationChoiceModel, alors que je change le lambda de WorkDestinationChoiceModel et qu'il devrait donc recalculer les utilités et donc y repasser non ?

De maniere generale quand il ne trouve pas un fichier parquet, il faut remonter avant la création de celui ci c'est bien ca ? Merci

[FlxPo]

Ce fichier est créé ici : https://github.com/mobility-team/mobility/blob/carpool/mobility%2Fdestination_choice_model.py#L101. Donc il faudrait voir pourquoi le code n'arrive pas jusqu'ici ?

[FlxPo]

Il est aussi possible de forcer le recalcul systématique en modifiant la classe Asset ici : https://github.com/mobility-team/mobility/blob/add-switzerland/mobility%2Fasset.py#L83. Il faut remplacer le test self.is_update_needed() par True pour que la méthode create_and_get_asset soit appelée à chaque fois. Par contre ça forcera le recalcul d'absolument tout ce que Mobility a déjà pré calculé !

[matt-gau]

C'etait quelque chose qui bloquait dans ma classe CarpoolTravelCosts et qui empechait le code de tourner jusqu'a création du fichier effectivement... C'est bon maintenant merci !