Adapte France à la modification de la gestion des spirales

[sandcha]

Fixes #1211
Fixes #1283
Connected to openfisca/openfisca-core#817

• Correction d'un crash affectant les inférences du système socio-fiscal.
• Périodes concernées : toutes.
• Zones impactées : RSA, revenu disponible, cotisations, réforme net/brut
• Détails :
  • Adapte France à la modification de la gestion des spirales
  • Pour plus d'informations, voir le descriptif de la PR

---

Les modifications de Core dans openfisca/openfisca-core#817 concernent la détection et la gestion des cas où le calcul d'une variable à une période implique de calculer préalablement la même variable à une autre période ("spirales").

Adaptation des tests du RSA

Les versions antérieures étaient affectées par un bug (#1283, openfisca/openfisca-core#749) se manifestant notamment pour la variable rsa, fixée par erreur à 0 lorsqu'on calculait préalablement revenu_disponible dans la même simulation, alors que sa "vraie" valeur (constatée en calculant rsa en premier) était différente.

La correction de ce bug entraîne la réintégration du RSA non nul dans le revenu disponible, et implique de forcer à 0 les valeurs du RSA incriminées. Cela concerne

• tests/formulas/aides_logement_fiabilisation.yaml
• tests/formulas/revenu_disponible.yaml

Réforme de net à brut

La réforme "de net à brut" ne fonctionne que partiellement avec ces modifications, le montant du salaire brut à partir du net est calculé correctement, mais il semble que les résultats intermédiaires sont désormais impliqués dans une spirale et par conséquent retirés du cache. Ces vérifications sont pour l'instant mises en commentaires.

Mode de recouvrement des cotisations

Le test cas_types_ui.yaml échoue car le calcul des cotisations selon le mode de recouvrement par défaut ("mensuel anticipé") exige de régler max_spiral_loops = 2 dans Core, mais cela dégrade légèrement les performances (temps d'exécution) alors que max_spiral_loops = 1 présente une amélioration. On bascule donc sur le mode mensuel_strict par défaut.

Ces deux derniers cas seront corrigés dans de futures PRs.

Tests de performance

master

Premier test revenu disponible
2.602721 s
Second test revenu disponible
2.312436 s
3e test revenu disponible
2.339221 s
Premier test ciblé spirale
1.209179 s
Second test ciblé spirale
1.118555 s
3e test ciblé spirale
1.162432 s

simplify-cycle-detection-redux

Premier test revenu disponible
2.566360 s
Second test revenu disponible
2.303230 s
3e test revenu disponible
2.196354 s
Premier test ciblé spirale
0.681062 s
Second test ciblé spirale
0.732799 s
3e test ciblé spirale
0.688142 s

---

Ces changements (effacez les lignes ne correspondant pas à votre cas) :

• Modifient l'API publique d'OpenFisca France (par exemple renommage ou suppression de variables).
• Corrigent ou améliorent un calcul déjà existant.

---

Quelques conseils à prendre en compte :

• Jetez un coup d'œil au guide de contribution.
• Regardez s'il n'y a pas une proposition introduisant ces mêmes changements.
• Documentez votre contribution avec des références législatives.
• Mettez à jour ou ajoutez des tests correspondant à votre contribution.
• Augmentez le numéro de version dans setup.py.
• Mettez à jour le CHANGELOG.md.
• Assurez-vous de bien décrire votre contribution, comme indiqué ci-dessus

[sandcha]

Premier bilan concernant les performances de cette branche et sa mère en Core.

Contexte
Avec @fpagnoux, nous avons cherché à évaluer s'il y avait une différence nette de temps d'exécution d'un calcul de variable avec spirale sur la branche master et la branche simplify-cycle-detection-redux qui ici, cherche à résoudre le problème de spirale détecté sur France.

Méthode
Nous avons mesuré le temps de simulation.calculate(...) sur France par lots de 10 simulations avec le script measure_spiral_performances.py

Résultats
Ces temps n'indiquent pas d'écart de performances net suite à l'utilisation de la branche simplify-cycle-detection-redux traitant des spirales.

Voici les traces obtenues sachant que :

• Les 3 premiers calculs de temps d'exécution font appel à revenu_disponible parce qu'il impose une profondeur de calcul supérieure à la moyenne.
• Les 3 suivants exécutent le test python remonté par mes-aides dans la branche test-cycle indiquée dans ce commentaire.

Sur branches Core et France simplify-cycle-detection-redux

Premier test revenu disponible
3.140392 s

Second test revenu disponible
2.664585 s

3e test revenu disponible
2.635230 s

Premier test ciblé spirale
1.410129 s

Second test ciblé spirale
1.464613 s

3e test ciblé spirale
1.393975 s

Sur branches master de Core 25.2.9 et France 34.5.0

Premier test revenu disponible
3.166132 s

Second test revenu disponible
2.551172 s

3e test revenu disponible
2.225182 s

Premier test ciblé spirale
1.425713 s

Second test ciblé spirale
1.119020 s

3e test ciblé spirale
1.449040 s

[bfabre01]

@Morendil @sandcha : savez-vous environ quand cette PR pourra être mergée ?

[bfabre01]

Hello @Morendil et @sandcha , savez-vous quand est-ce que cette PR pourra être mergée, pour qu'on l'importe au CASD ? Merci.

[sandcha]

On réintervient dessus cet après-midi. Etat des lieux à venir en fin de journée.

[Morendil]

@bfabre01 Pas eu le temps de boucler ça aujourd'hui, on s'y met demain matin.

[bfabre01]

@sandcha @Morendil Ok ça marche, merci !

[bfabre01]

@Morendil @sandcha : super, merci beaucoup !