[US] Mettre à niveau le mode covoiturage simple de Mobility

[Mind-the-Cap]

En tant que modélisateur.ice, je veux pouvoir rapidement tester l'effet du covoiturage sur un territoire sans entrer dans les détails.

Idées à l’œuvre

• Mobility dispose de deux modélisations du covoiturage, une simple et une plus complexe ("detailed")
• En version "simple", on prend simplement les temps et distances de trajet de l'autosolisme et on leur applique des modifications (forfait de temps de rencontre, prix du temps et des distances, incitations covoiturage...). Elle est moins précise que le mode "detailed", mais est beaucoup plus rapide à intégrer dans une simulation car ne nécessitant pas de création d'un graphe de transport dédié.
• Cette version "simple" n'est pas à jour par rapport aux derniers changements de Mobility, il faudrait la mettre à niveau si l'on souhaite la conserver.

Modélisation concernée

Sujet	Changements
Modes	Mettre à jour le mode covoiturage
Utilités	NC
Coûts	Déterminer les coûts de ce mode
Puits et opportunités	NC
Prospective	NC

Livrables

Code

Classe SimpleCarpoolTravelCosts mise à jour et fonctionnelle, avec des valeurs par défaut cohérents avec les autres modes

Visualisations

Mêmes visualisations que pour les autres modes de transport (vérifier si des changements sont nécessaires dans PopulationTrips.plot_modal_share et .plot_od_flows

Visualisations intermédiaires

NC

Examples

Ajouter un exemple simple d'utilisation dans le dossier examples

Rapports et logs

Tests

Ajouter un test utilisant cette classe, ou mettre à jour un des tests existants pour l'utiliser

Impacts techniques

Sur la modélisation

Pas d'impact prévu

Sur l'architecture et les classes

Pas d'impact prévu

Au sein de classes déterminées

Refonte de SimpleCarpoolTravelCosts

Pré-requis

A priori aucun

Le développement sera réussi si...

• Tous les tests pré-existants continuent de passer (rétro-compatibilité)
• Le code respecte les normes de formatage
• Le taux de couverture ne baisse pas ou marginalement
• Les visualisations intermédiaires permettent de déboguer
• Le temps de calcul n'est pas affecté, ou raisonnablement peu
• Condition(s) fonctionnelle(s)

Retour d'expérience

Compléter cette partie une fois le développement terminé

[mathilderichard2001-rgb]

### Problème : constantes du coût de distance définies à plusieurs endroits

Certaines constantes identiques sont définies à plusieurs endroits dans le code.

Exemple 1 — dans la classe DetailedCarpoolGeneralizedCostParameters :

car_cost_of_distance: float = 0.1
carpooling_cost_of_distance: float = 0.05

Exemple 2 — dans la fonction get_population_trips() :

cost_of_distance = {
"car": 0.0,
"carpool": 0.0
}

Question

Quelle définition prévaut sur l’autre ?
Est-ce que la classe de paramètres écrase les valeurs définies dans get_population_trips(), ou l’inverse ?

[Mind-the-Cap]

Hello @mathilderichard2001-rgb,

DetailedCarpoolGeneralizedCostParameters est une dataclass (tu peux le voir avec le décorateur @dataclass au-dessus du def - si tu ne connais pas ces deux notions, je te conseille de prendre quelques minutes pour te former, c'est très utile en Python, et quasiment tous les paramètres de Mobility sont gérés par des dataclasses).
Cela implique que toutes les valeurs à l'intérieur de cette dataclass sont des valeurs par défaut. Tu peux ensuite les modifier quand tu crée le mode de transport.

[mathilderichard2001-rgb]

Je m'excuse pour mes questions un peu basiques, j’ai pris le temps de me renseigner.
Lorsque j’active le mode Carpool, deux modes apparaissent : Carpool et Carpool_Return. J’imagine que ce dernier correspond au trajet de retour. Ne serait-il pas plus pertinent de considérer ces deux modes comme un seul ?

[mathilderichard2001-rgb]

Problème rencontré :

Même en configurant des coûts négatifs pour le covoiturage afin de le rendre plus attractif que la voiture individuelle, cela ne semble pas influencer le comportement attendu dans le simulateur.

Lorsque le covoiturage n’est pas activé, la fonction evaluate ne retourne plus toutes les valeurs qu’elle renvoyait auparavant.

À noter : j’ai récemment effectué un pull de la branche mobility sur GitHub, ce qui pourrait expliquer certains changements de comportement.

Images jointes illustrant la configuration et le problème :

[FlxPo]

Je m'excuse pour mes questions un peu basiques, j’ai pris le temps de me renseigner. Lorsque j’active le mode Carpool, deux modes apparaissent : Carpool et Carpool_Return. J’imagine que ce dernier correspond au trajet de retour. Ne serait-il pas plus pertinent de considérer ces deux modes comme un seul ?

On fait l'hypothèse pour le moment que les personnes qui font du covoiturage pour un déplacement doivent en faire un pour le déplacement symétrique de retour. Donc dans une chaîne A -> B -> A un déplacement A -> B en covoiturage induit un déplacement en covoiturage pour B -> A.

Pour le deuxième point, il y a vraisemblablement un problème sur la congestion routière vu que le temps de trajet moyen est de 2000 heures ?

J'ai fait des modifs vendredi pour éviter un bug de la librairie dodgr que nous utilisons pour créer les graphes de transport, il est possible que ton problème vienne de là : #234. Pourrais tu essayer de relancer avec la nouvelle version en faisant un pull ?

[mathilderichard2001-rgb]

Problème avec le mode carpool et les coûts
Lorsque je lance le modèle en mode carpool, les coûts calculés semblent incorrects.
Exemple : pour les couts allant de la zone 1 à 158, ce qui ne correspond pas à mes attentes si je compare avec le mode voiture classique.

Voici un visuel illustrant le problème :

[FlxPo]

Pourrais tu créer un micro cas d'étude reproductible pour que je puisse regarder ce qui se passe ? Comme mentionné dans mon message précédent il y a visiblement un problème sur les temps de trajet voiture qui sont extrêmement élevés ?

[mathilderichard2001-rgb]

Mise à jour du mode simple Carpool – bug lors du calcul des séquences de modes

J’ai essayé de remettre à niveau le mode simple Carpool dans sa version simplifiée. Les changements principaux sont :

-Héritage de FileAsset pour SimpleCarpoolTravelCosts afin de gérer automatiquement le cache.

-Ajout d’un mode retour (carpool_return).

-Calcul du coût généralisé en utilisant les paramètres de PathTravelCosts (temps, distance, coûts, revenus, etc.).

Problème rencontré :

Lors de l’exécution du modèle, le calcul des séquences de modes échoue avec l’erreur suivante :

ComputeError: failed to retrieve first file schema (parquet): expanded paths were empty (path expansion input: 'paths: [Local("C:\Users\MathildeRichard\project_data\population_trips\weekday\tmp_results")]', glob: true). Hint: passing a schema can allow this scan to succeed with an empty DataFrame.

Le bug semble survenir dans TopKModeSequenceSearch.run() lorsque le code essaie de lire les fichiers Parquet générés dans tmp_path. Aucun fichier n’est créé dans ce dossier, ce qui provoque l’erreur de lecture.

Contexte technique :

Branche : carpool_ECOV

Besoin :

Aide pour identifier pourquoi aucun fichier n’est créé dans tmp_path et comment corriger l’erreur lors de la génération des séquences de modes.