Comments (7)
Un immense merci @Sasha-Laniece pour ce travail de formalisation et de consolidation ! C'est très précieux
Harmonisation
Ces modifications […] doivent aussi faire l'objet d'une modification dans
openfisca-core
.
J'attire l'attention sur le fait que les noms choisis devront être discutés plus largement dans ce cadre ; on n'est donc pas à l'abri d'un renommage ultérieur, mais le cas échéant probablement meilleur grâce à la participation de personnes anglophones
on renomme le champ
href
enurl
Ce point n'est pas présent dans l'exemple donné
API
Je suis personnellement très favorable à une modernisation du moteur de l'API web.
Charte
- Formaliser ces points dans un document.
from openfisca-france.
[ 6 - CHARTE D'USAGE - DROITS ET CONDITIONS ]
Dans cet atelier mené par @MattiSG , il a été rappelé qu'il faut:
- mettre à jour le modèle sur la zone de responsabilité
- rendre visible les travaux en cours
- indiquer ses zones d'expertise métier et répondre à la communauté
- respecter les règles de contribution (rappellées dans le Wiki )
- répondre aux questions à la suite d'une contribution
- pas d'exclusivité sur les zones législatives
- rendre accessible le code source sur la forge publique
Obligations :
- afficher la mention "Calculé par OpenFisca version XX" à côté des résultats et dans les mentions légales (avec un lien vers le site)
- référencer sa réutilisation sur le site OpenFisca (fait ici: #2003 (comment))
- correspondant.e
- ouvrir des issues
- partager ses statistiques d'usage
- informer des communications faites au sujet d'OpenFisca
- utiliser des bases de présentation partagées
- informer d'ajouts / outils annexes / expérimentations
- conditions sur le logo : non utilisation pour donner l'impression d'affiliation
ceci est une ébauche, @MattiSG ou @sandcha je vous laisse corriger et compléter
from openfisca-france.
[ 1 - L'HARMONISATION ]
Le chantier d'harmonisation, qui vise à rapprocher les paramètres d'OpenFisca-France de ceux des Barèmes-Ipp afin d'en faire un unique répertoire, a été démarré par @benjello, @sandcha, @eraviart et @Sasha-Laniece au printemps 2021 dans cette issue: #1519
Il s'est découpé en de nombreuses actions résumées ici:
- Initialisation : #1537
- 1 - Prélèvements sociaux : #1597
- 2 - Impôt sur le revenu : #1598
- 3 - Taxation du capital: #1599
- 6 - Prestations sociales: #1600
- 8 - Chômage et préretraites: #1602
- 9 - Marché du travail : #1603
Ce qui n'est pas rapproché car inutile dans OpenFisca-France (d'après @benjello )
- 4 - Taxation indirecte : #1604
- 5 - Fiscalité des entreprises: #1605
- 7 - Retraite: #1601
- 10 - Tarifs réglementés de l'énergie : #1606
Pour mener à bien ce travail, il reste encore quelques étapes:
- La création d'une tâche de CI pour maintenir le travail d'harmonisation PR ici (@sandcha )
- Passer le Validateur yaml de la CI en test 'bloquant' pour empêcher de détricoter l'harmonisation (@eraviart )
- Finir la migration côté IPP ( @benjello )
- Fusionner les répertoires !
from openfisca-france.
[ 2 - LA RFC DE NORMALISATION DES PARAMÈTRES ]
Lors de l'harmonisation, devant la disparité des formats observés dans les paramètres, on s'est posé la question des "bonnes pratiques" quant à la rédaction d'un yaml de paramètres.
S'est ensuivi un débat avec de nombreux échanges tous résumés dans la RFC #1672 .
Malheureusement le timing et la charge de travail des différents participants font qu'elle n'a pas été clôturée et les choses sont restées en suspens. Profitant de la présence de nombreux contributeurs lors de la Studieuse, nous avons voulu finaliser cette RFC.
Les actions suivantes ont été prises:
1 - Renommage et normalisation des champs des paramètres, avec précision de leur définition dans cette PR #1998 . En bref:
description
devientlabel
ux_name
devientshort_label
description_en
devientlabel_en
last_review
devientlast_value_still_valid_on
Ces modifications seront poussées ici: #2001, et doivent aussi faire l'objet d'une modification dansopenfisca-core
.
2 - La normalisation du champ reference
a fait l'objet d'un débat à part, dont les conclusions sont ici : #2002 . Les informations cruciales à retenir sont:
- la
reference
est OBLIGATOIRE - on doit pouvoir trouver la valeur du paramètre EN UN CLIC (pour les décrets, utiliser la version originale)
- le format de l'URL est important
- on renomme le champ
href
enurl
En pratique, on change le format pour mettre les références à côté de la value qu'elles concernent:
label: SMIC brut mensuel
values:
2022-08-01:
value: 1678.95
reference:
title: Arrêté du 29/07/2022
href: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000046113517
2023-01-01:
value: 1709.28
reference:
title: Décret 2022-1608 du 22/12/2022
href: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000046780043
metadata:
short_label: SMIC brut mensuel
last_value_still_valid_on: "2022-08-03"
label_en: Minimum wage - SMIC (1970 -)
Pour mener à bien ce travail, il reste encore quelques étapes:
- Faire la PR de modification du format des références (avec un script automatique) (@eraviart ?)
- Faire les modifications correspondantes dans
openfisca-core
(@eraviart ou @sandcha ou @MattiSG ? ) - Rédiger ces décisions dans le Wiki, dans la partie Guide des Bonnes Pratiques : https://github.com/openfisca/openfisca-france/wiki/Bonnes-pratiques-de-mod%C3%A9lisation (@Sasha-Laniece )
from openfisca-france.
[ 3 - RÉFÉRENCEMENT DES PRODUITS ]
Suite à la demande de @MattiSG , chaque équipe a fourni des informations pour enrichir le site OpenFisca.org de toutes les applications du modèle.
Le dépôt de modification du site openfica est ici : https://github.com/openfisca/openfisca.org
La vitrine se voit ici : https://openfisca.org/fr/showcase/
from openfisca-france.
[ 5 - ÉCHANGE SUR LES CHOIX D'INSTANCIATION ]
CR d' @Olivier-Bernard-IMSA :
"
Cet atelier était à l’initiative de MesDroitsSociaux.
Nous nous sommes retrouvés à 2, @benoit-cty et moi pour échanger sur la manière dont nous utilisons et instancions le moteur OF pour répondre à nos besoins.
J’en profite pour le remercier pour toutes les informations et pistes d’améliorations qu’il a partagé concernant Python et le moteur OF, notre expertise côté MDS étant plus sur les architectures à base de Java.
Côté MDS, le besoin d’échanger sur cet atelier vient les difficultés que nous avons rencontré sur des tests de performances où notre service de simulation basé sur OF est notre facteur limitant de monté en charge. Les temps de réponses sont limitants et la consommation en mémoire nous interroge vis-à-vis de l’exploitabilité de la plateforme MDS.
Nos usages du moteur sont unitaires : un utilisateur va demander une simulation d’aide sur MDS à partir des données qui lui sont demandées et ou récupérées par MDS dans la sphère sociale et publique. Nous utilisons l’API Rest d’OF et OF est instancié dans un conteneur orchestré en tant que « pod » dans une infrastructure Cloud privé basée sur Kubernetes administrée par Rancher, et sur des nodes qui sont des VMs sur des ESXs VMWare. Les appels sont internes au cluster Kubernetes.
Nous avons été surpris par l’usage mémoire des instances d’OF (> 4 à 6GB), car c’est un service de calcul stateless, et que nous avons une bonne expérience sur côté moteur de calcul de prestations avec l’usage ODM, pour la tarification des feuilles de soins et pour la simulation et calcul de retraite, qui consomme surtout de la cpu.
Cet usage de mémoire nous interroge sur la pertinence de conserver OF en pod dans Kubernetes au regard d’une instanciation sur des VMs plus stables quitte à être moins flexible/scalables.
En effet, idéalement un service fournit par Kubernetes doit pouvoir démarrer très rapidement et être déplaçable facilement d’un nœud à un autre pour s’adapter aux besoins d’élasticité du cluster et de la disponibilité de ces nodes/nœuds. Or nos nodes sont actuellement des VMs relativement petite en mémoire, ce qui limite la capacité de Kubernetes à instancier des pods OF, et peut poser des difficultés d’exploitabilité : trouver un nœud suffisamment vide pour y instancier un pods OF par exemple.
Côté LexImpact, le cas d’usage métier est bien différent : le moteur OF est sollicité sur des jeux de données volumineux (et non pas unitaire par individu), pour évaluer sur des segments de population des impacts sur le budget de l’état de réformes. Ils l’utilisent donc essentiellement dans un cadre de calcul matriciel.
LexImpact n’utilise par l’API d’OF, ils ont fait le choix d’encapsuler OF dans leur produit et de mettre à disposition des services via une API Rest basé sur le framework Python FastAPI pour assurer de meilleures performances (ils considèrent l’API OF actuelle assez obsolète) et une généricité dans l’API qui répond mieux à leurs besoins.
Ils instancient cette application via une plateforme Proxmox, et expose le service via Gunicorn qui répartit le travail sur et 4 instances de conteneurs (LXC) contenant l’application.
Afin de limiter les sollicitation inutiles, ils utilisent un cache Redis pour stocker les résultats au regard des requêtes entrantes et les resservir.
Le monitoring est assuré via Prometheus (utilisé aussi côté MDS), FastApi y étant câblé.
Pour finir, ils utilisent le protocole Websocket entre la partie IHM côté navigateur vers l’applicatif afin d’assurer un affichage progressif des informations.
Benoit a aussi rencontré des problèmes de mémoire an arrivant jusqu’à 8GB, et ce malgré le mécanisme de débordement sur disque.
Il existe en effet un mécanisme d’OF de débordement sur disque, avec des possibilités de choix d’éviction des objets , qui se paramètre via un flag memory_config. Une trace est produite au démarrage permettant de vérifier si le mécanisme est actif et le débordement s’active à partir de 95% d’usage de la mémoire.
Il a utilisé un outil d’exploration de la mémoire, et c’est une piste à explorer un peu plus (par exemple https://blog.octo.com/rendre-son-code-python-performant-grace-au-profiling/ ), comme sur l’usage du GC.
Se posera aussi probablement des impacts sur l’architecture du produit OF nécessaires pour servir des cas d’usages qui sont potentiellement très différent : appels unitaires avec forte exigence réponse rapide et peu de besoin de matriciel versus appel unitaire avec fort volume de donnée.
Il a aussi constaté des temps de démarrage long. Il pense que c’est dû au mode de chargement de paramètres, et il pense que l’on pourrait beaucoup gagner en optimisant la fourniture des paramètres, comme par exemple de les fournir sous forme d’objets sérialisés via Pickle.
"
Les prochaines étapes pour remplir ces missions:
- Échanger avec d'autres usagers de l'API Web.
- Faire du profiling pour identifier les sources de problèmes.
- Migrer l'API Web OpenFisca sur un framework plus moderne, tel FastAPI ?
- Étudier comment accélérer le chargement des paramètres : parallélisation et/ou cache dans un seul fichier.
from openfisca-france.
[ 4 - UTILISATION DE CONDA AU LIEU DE PIP
]
Suite au travail de @benoit-cty dans ces PRs : #1778, #1779, #1786 et https://github.com/openfisca/openfisca-france/pull/17863 , on peut désormais publier OpenFisca-France dans un package Conda.
Le but n'est pas de remplacer pip mais d'offrir une alternative aux personnes qui le souhaitent.
L'équipe LexImpact utilise pip
pour le développement en local et Conda sur le Centre d'Accès Sécurisé aux Données, CASD.
L'IPP utilise Conda pour installer Python mais utilise ensuite pip à l'intérieur de Conda.
Les prochaines étapes pour remplir ces missions:
- L'IPP regarde si Conda peut convenir à leur usage du CASD qui est différent de LexImpact. ( @bfabre01 ?)
from openfisca-france.
Related Issues (20)
- Doublons sur 'ecodev' / 'compte_epargne_codev' ? (Réductions impôt) HOT 7
- Mettre à jour les plafond de ressources PLAI HOT 6
- Mettre à jour l'indice minimal de traitement dans la fonction publique HOT 1
- Doublons dans `parameters/impot_revenu/calcul_reductions_impots/pme` ? HOT 1
- Erreur de date dans `calcul_revenus_imposables.charges_deductibles.pensions_alimentaires` ? HOT 4
- Créer une unité point d'indice majoré HOT 1
- Modification assiette des prestations d'assurance maladie et maternité (exclusion revenu 2020)
- Certains liens du readme ne sont pas/plus fonctionnels HOT 2
- Reval ASS 2022
- Reval Aides au logement - RLS - Plafond ressources 01-2023
- Reval Prestations famille, et SMIC
- Doublons dans les variables de bourse HOT 1
- `cerfa_field` manquant dans la variable f7oc HOT 2
- La dénomination de la variable nombre_allers_retours de l'aide à la mobilité n'est pas clair
- Clôture de la RFC des paramètres HOT 1
- Ranger et harmoniser `complement_are` HOT 1
- Débat sur le formatage des références HOT 8
- Ordre chronologique ou inversement chronologique des formules d'une même variable
- Incohérence entre CSG et cotisations retraite complémentaire sur ARE HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openfisca-france.