Un des inconvénients de la programmation mathématique de grandeurs physiques est la difficulté de suivre les grandeurs utilisées au fil des variables et des calculs et donc d’assurer la cohérence du système d’unité et des multiples et sous-multiples utilisés. Habituellement, ceci passe par un lourd système de commentaires, peu efficace pour détecter les erreurs. Il apparaît donc pertinent de déclarer explicitement les unités des variables utilisées afin d’en assurer la traçabilité.
Cette pratique offre trois autres avantages :
la possibilité de convertir à la volée les grandeurs d’un système d’unité à l’autre (vital en Amérique du Nord où le système métrique cohabite avec le système impérial et provoque un crash de sonde spatial par décennie à cause de soucis d’unités)
la possibilité de débugguer un algorithme par les dimensions des résultats et les erreurs renvoyées en cas de tentatives d’opération illicites sur des grandeurs différentes
la possibilité de programmer avec des grandeur sans se soucier de les convertir à chaque étape dans le bon multiple.
Il existe différents modules Pythons pour venir à bien de cette tâche, présentés dans la vidéo ci-dessus, chacun ayant leurs forces et leurs faiblesses, et une intégration plus ou moins fine avec Numpy, qui est la base du calcul numérique sous Python. J’ai choisi quantities pour ce faire, et je vais vous présenter un cas réel commenté : la conception d’un engrenage (dimension et résistance des matériaux)
Exemple et code source
L’exemple ci-dessous est typique de l’ingénierie nord-américaine : on doit dimensionner un train d’engrenages en tenant compte :
Mais si les constantes physiques et les propriétés des matériaux sont en unités SI, les données du problème sont en unités impériales (dimensions en pouces) et en unités SI (puissance en watts). On a donc toutes les chances de se prendre les pieds dans le tapis en déroulant le calcul, et la NASA perd une sonde spatiale par décennie à cause d’erreurs de conversions d’unités de ce type.
On veut donc assurér la cohérence des résultats au cours du calcul en gardant la traçabilité des grandeurs et en évitant les erreurs de conversion.
Résultat
Commentaires
Sur la procédure de calcul, on remarque aux sections Dimension du pignon et Dimension de la roue que les calculs étant les mêmes, le code a été factorisé en passant par une classe. C’est l’une des beautés de la programmation scientifique orientée objet qui est grandement facilitée avec Python, et plus complexe – quoique possible – sous Matlab par exemple.
Sur les unités, on peut vérifier la cohérences des résultats, y compris sur les rapports de transmission sans dimension.
Cependant, on remaque un problème de calcul sur la variable W_T (section Résistance en flexion) dont la dimension est hp/(ft*rpm) en raison du facteur de correction 33000 sans unité précisée. Ainsi W_T est homogène à des livres force mais le passage dans cette unité via le module quantities introduit des constantes de conversion déjà prises en compte dans le 33 000. Le problème se propage à F.
Note : La valeur 33000 a été reprise telle quelle d’un corrigé qui ne mentionnait pas sa dimension ni son origine (Car les formules de dimensionnement d’éléments de machines relèvent parfois de la sorcellerie).
À cette exception près (qui mériterait seulement un retour à la documentation), on remarque que le passage d’un système d’unités à l’autre est presque indolore.
Utilisateur de Linux à cause de Windows Vista (2008) et développeur de scripts, plugins et logiciels libres dans 15 langages de programmation depuis 2012. J'ai mis le nez dans les ordinateurs parce qu'ils sont devenus incontournables partout et que je refuse de les subir. Initialement spécialisé en programmation pour le calcul scientifique en génie mécanique, il a fallu que je développe aussi pour le web et la bureautique, afin de résoudre des problèmes créés par des informaticiens.