Vos experiences avec Python (que je n'ai jamais utilisé) vont m'inciter
à aller voir de plus près de quoi il s'agit et ce que l'on peut en
faire. Cependant, il y a un point qui risque de coincer (a priori, car
je ne conais pas encore python).
Je redoute plus que tout dans ces langages de trop haut niveau le coté
boite noire. Dans nos codes de recherche tout les algorithmes utilisés
ont été validés par toute une série de tests. Il y a toujours un
argument important qui fait que l'on a choisi telle ou telle manière de
procéder. Nos solveurs, nos FFT, nos générateurs de nombres
aléatoires....etc sont inclus dans le source et validés. On a par
exemple eu des déboires il y a quelques années avec un générateur de
nombres aléatoires fourni par le système qui engendrait des périodicités
dans les écoulements à très haute résolution (10 à 15 millions de points
de calcul) et on a perdu beaucoup de temps à isoler le problème! Pas
question donc d'utiliser des librairies en boite noire dans lesquelles
on ne maitrise pas ce qui est fait et ou nous serions à la merci d'un
rpm -U changeant un algorithme.
Bien sur, nous somme à la merci des mises à jour des compilateurs (pas
très fréquentes quand même) et des librairies du système, mais il y a
toujours un moyen de compiler sans aucune optimisation une série de
tests puis de monter progressivement les options même si cela ne permet
pas de déceler des problèmes comme celui décrit ci-dessus.
En ce qui concerne l'existant, hélas! Il est énorme et on y trouve du
fortran 77, mais aussi du fortran66 (si! si!) et même quelques rares
morceaux en fortran8X! On se demande parfois comment ca compile toujours
;-)
Patrick
--
===============================================================
| Equipe M.O.S.T. | http://most.hmg.inpg.fr |
| Patrick BEGOU | ------------ |
| LEGI | mailto:Patrick.Begou@hmg.inpg.fr |
| BP 53 X | Tel 04 76 82 51 35 |
| 38041 GRENOBLE CEDEX | Fax 04 76 82 52 71 |
===============================================================
