Règles d’or pour bien débuter en programmation

Version pdf de cet article   [edmc_show id= »1314″]

Supposons que votre directeur de thèse ou votre collaborateur de recherche vous passe un code de calcul qui a déjà servis pour une autre application. Votre contribution serait d’implémenter un nouveau modèle ou un schéma différent ou tout simplement modifier le domaine de calcul et les conditions aux frontières en vue de l’utiliser pour une autre application.

  1. Première chose à faire : gardez en lieu sûr la version originale du code. Vous pouvez en avoir besoin si jamais vos modifications ne marchent pas et soyez sûr elles ne marcheront jamais du premier coup, c’est quasiment impossible. Vous ne voudriez pas revenir à votre encadreur pour lui demander une nouvelle copie du code parce que vous l’avez tellement manipulé qu’il ne ressemble à rien. Donc première directive : sauvegardez la version zéro dans un répertoire distinct et épargnez-vous l’humiliation de demander deux fois la même chose. La version une sera celle que vous allez essayer tout de suite.
  2. Vous l’avez compris la deuxième chose à faire est d’essayer le code tel qu’il est et pour l’application d’origine. Surtout ne touchez à rien, il faut que vous soyez sûr que vous avez en main une version qui marche bien. Retrouver les mêmes résultats que précédemment est pour vous une assurance que vous êtes entrain de piocher dans la bonne direction.
  3. Pour cela, soit vous êtes sous linux et vous avez un Makefile à exécuter pour compiler le code soit vous êtes sous Windows et vous devez chercher le ‘main program’ dans l’ensemble des fichiers du code. Parmi les fichiers que vous avez, un seul commence par PROGRAM et se termine par END. C’est lui le ‘main’ qui vous servira à créer le projet de compilation. Les autres sont des ‘subroutines’ et des modules à rajouter ultérieurement au projet de compilation.
  4. En procédant à la première exécution, vous allez repérer les fichiers INPUT nécessaires au fonctionnement du code et aussi les OUTPUT (vous pouvez suivre les instructions ‘read’ et ‘write’. Si nécessaires, vous devez peut être changer le format des fichiers OUTPUT pour qu’ils correspondent à votre logiciel de post-processing (Paraview, Tecplot, Origin ou autre…). Faites-le avec précaution et vérifiez que vous obtenez la bonne solution de l’application d’origine.
  5. Il se peut que l’application d’origine utilise une grille de calcul très lourde qui nécessite beaucoup de temps pour converger et aussi une bonne carte graphique pour manipuler les résultats. Vous pouvez vous simplifier la vie en optant pour la grille la plus légère ou tenter d’utiliser une grille beaucoup moins dense (rapide à faire converger et légère pour la manipulation des outputs)
  6. De toute façon, pour tester la bonne implémentation de votre nouveau modèle ou la modification de vos conditions aux limites, il est impératif que vous utilisez des grilles légères, vous passerez à la grille finale une fois que vous avez la version finale et qu’il ne vous manque que la précision des calculs.
  7. En commençant la modification de votre code, ne changer jamais deux trucs à la fois. Allez-y doucement, une chose à la fois et faites des tests après chaque modification (vous allez apprécier d’avoir utilisé une grille légère). En procédant ainsi vous saurez exactement la manœuvre qui a dégrader votre code ou pire l’empêche de tourner. Cette approche vous permet d’isoler la fausse manœuvre et n’hésitez pas à revenir à la version précédente (qui fonctionne bien) pour retenter la modification.
  8. Avant d’attaquer de front votre application, Il faut toujours commencer par des tests simples et théoriquement vérifiables. Par exemple, avant de runner le cas de l’écoulement turbulent à l’intérieur d’un tube cylindrique dont la paroi est ondulée, commencez par l’écoulement laminaire dans un tube cylindrique droit. Vous pouvez alors, comparez le profil de vitesse avec la distribution de Poiseille (de même pour le Nusselt, si vous traitez le transfert de chaleur). Vous passez ensuite à l’écoulement turbulent et en dernier lieu vous passez à votre application à géométrie plus compliquée. En procédant ainsi, vous êtes sûr d’éviter de vous perdre en route. C’est un peu long mais c’est sûr.
  9. Si ce n’est déjà implémenté dans votre code. Faites de sorte que le code génère des fichiers OUPTUT avant la première itération et/ou après les quelques premières itérations. Laisser le code tourner et profiter pour examiner avec votre logiciel de post-processing les champs de vitesses, pression, température et autre. Vous déciderez après si vous laisser le code tourner ou que vous devez tout arrêter et revoir la pose des conditions aux limites/initiales.
  10. Pensez à bien organiser votre travail en utilisant des répertoires distincts pour chaque cas et des noms explicites qui vous permettent de reconnaitre facilement la variante du cas traité. Effacer carrément les résultats des variantes non retenues. Les noms de fichiers de type A0001.dat, A0002.dat … sont à éviter. Donnez plutôt des noms qui reflètent le nombre de Re ou de Gr ou un paramètre géométrique qui caractérise le cas par rapport aux autres.
  11. Si vous avez à faire une étude paramétrique, vérifier bien les résultats du premier cas avant d’attaquer les autres. Il faut que vous soyez sûr que la géométrie est bonne, la grille de calcul est parfaite, les conditions aux limites bien posées et les résultats correspondent à ce qui est prévue théoriquement. A maintes reprises j’ai eu des étudiants qui font des tonnes de calculs en brassant tous les paramètres possibles sans vérifier leurs résultats. Une fois en consultation, la grille de calcul n’épouse pas exactement le domaine ou les conditions aux frontières ne sont pas bien posées, résultat : tout le travail est à jeter.
  12. N’hésitez pas d’étoffer votre programme par le maximum de commentaires possible. Expliquez chaque portion de calcul et définissez chaque variable. Ce n’est pas important seulement pour vos collaborateurs mais aussi pour vous quand vous revenez à votre programme après une période de repos. Croyez-moi, j’ai eu toujours des difficultés à reconnaitre ce que moi-même j’ai fait des mois ou des années avant. Les commentaires quand elles sont là, m’aident à m’orienter dans la jungle des instructions fortran.

Bonne chance à toutes celles et ceux qui malgré l’invasion féroce des codes commerciaux continuent à affronter le monde de la programmation.

Ce contenu a été publié dans Articles, Cours, avec comme mot(s)-clé(s) , . Vous pouvez le mettre en favoris avec ce permalien.

2 réponses à Règles d’or pour bien débuter en programmation

  1. SENMED dit :

    Que dois-je vous dire Mr AZZI, c’est ce qu’on appelle sadaka jaria.
    Merci et saha ftourek

  2. ARRIF dit :

    MERCI C’est excellent mr azzi

Les commentaires sont fermés.