Accueil
Fiche logiciel validé
  • Création ou MAJ importante : 15/10/08
  • Correction mineure : 15/10/08
Auteur :
Relecteur(s) :
Responsable thématique :
Mots-clés

GDL : langage interactif (alternative libre à IDL)

Description
Fonctionnalités générales : 

GDL est un clone libre d’IDL, logiciel propriétaire largement utilisé en astronomie et dans d’autres domaines (télédétection, médecine). Il s’agit d’un langage interprété à la syntaxe simple, typée dynamiquement, permettant d’écrire des fonctions complexes. Par rapport aux langages compilés classiques, il présente l’avantage de laisser la main sur les données à tout moment et de les afficher aisément.

Pour les calculs, ce langage interprété fait appel à des librairies écrites en C++, ce qui n’est pas pénalisant niveau temps de calcul lorsque l’on sait s’en servir ! (cf Astuces ci-dessous). Ce langage sait gérer des objets à plusieurs dimensions (vecteurs, images, cubes, …) et des structures. A travers des commandes concises, il permet un affichage simple de courbes, surfaces et images, avec une grande richesse de paramétrage.

Cf les définitions sur wikipedia :

Autres fonctionnalités : 

GDL a une interface avec Python, des routines écrites en python peuvent être appelées depuis GDL.

Interopérabilité : 
  • Tout format ASCII (dont CSV lisible par tout tableur) en entrée et en sortie
  • Le format FITS est écrit et lu (format fréquent en astronomie)
  • Le format XDR est écrit et lu
  • Certains formats binaires, avec des aléas sous certaines plates-formes
  • Existence de librairies pour d’autres formats (images, …).
Contexte d'utilisation : 

Plusieurs personnes, chercheurs, ITA et étudiants (master et thèse), utilisent GDL de manière régulière ou sporadique à l’Observatoire. Je (AC) suis en contact avec des utilisateurs au CEA, dans des laboratoires du Max-Planck, à la Nasa, dans des universités américaines, en Inde … Les nouveaux venus qui ne connaissent pas IDL sont plutôt satisfaits car la syntaxe est simple, les performances raisonnables, la stabilité aussi.

Les utilisateurs avertis d’IDL sont plus gênés car :

  • ils ne retrouvent pas certaines de leurs fonctions et procédures intrinsèques préférées d’IDL, même si le taux de couverture a significativement augmenté en 2007 (cf http://aramis.obspm.fr/~coulais/IDL_et_GDL/Matrice....
  • ils connaissent un grand nombre de mots-clefs dont certains ne sont pas encore disponibles dans GDL (les développeurs de GDL ne sachant parfois même pas que tel ou tel mot-clef historique et non documenté d’IDL existait !).
  • ils espèrent utiliser des codes IDL directement sans toucher au code source mais se heurtent à des difficultés en cascade, le plus souvent à cause de mots-clés manquants.
Limitations, difficultés, fonctionnalités importantes non couvertes : 
  • Les Widgets d’IDL ne sont pas implémentées actuellement et rien n’est prévu à un horizon de six mois ou un an.
  • Certains formats sont mal relus, en particulier des fichiers binaires écrits avec IDL sur certaines plates-formes. Tout retour sur ces problèmes permettrait de voir si des solutions méritent d’être développées.
  • La plupart des fonctions graphiques (plot, contour, surface, TV, …) sont disponibles, mais certaines limitations existent (certains mots-clés manquent, absence de fontes spéciales pour les titres, …). Ceci est basé sur la librairie Plplot, globalement satisfaisante dans GDL par rapport à la rapidité d’affichage dans IDL (sauf sous Debian où un écart significatif persiste (parfois +50%), les écarts sont désormais négligeables (environ 10%). A noter que le support de l’affichage des NaN et +-Inf a été inclus dans GDL depuis la 0.9pre4.
  • La sortie Postscript est actuellement limitée au N&B.

  • Certains programmes fonctionnant en IDL ne tournent pas immédiatement sous GDL. On peut distinguer plusieurs cas :

    • (1) une fonctionnalité intrinsèque manquante dans GDL
    • (2) une librairie externe manquante
    • (3) des boggues dans GDL ou
    • (4) des problèmes de syntaxe du côté de GDL.

Dans le cas 1, il faudra voir s’il existe un moyen simple de contourner le problème, ou d’implémenter le code manquant (en *.pro ou en C++, cf cas Bessel). Sinon, faire une demande aux développeurs. Dans le cas 2, bien vérifier ce qui est dans les chemins. On a eu des retours de personnes n’ayant pas compris comment ajouter Astron ou Mpfit dans le chemin des librairies vues par GDL. Oui, l’installation complète de GDL avec Save/Restore, la cartographie, FFTw et ImageMagick (pour les entrées-sorties dans divers formats graphiques) peut être longue ! Dans les cas (3) et (4), un rapport de boggue sera bénéfique à tout le monde, car la version actuelle est plutôt bien stabilisée pour l’usage quotidien des principaux utilisateurs connus et des développeurs.
* On peut utiliser le flag !GDL (DEFSYSV, ‘!gdl’, exist=flag) pour tester si on est en IDL ou en GDL, ce qui permet de contourner aisément les éventuels problèmes restants en traitant les 2 cas (cf cet usage dans testsuite/test_besel.pro dans le CVS).
* Certaines versions ou évolutions de librairies externes (readline, plplot, GSL, FFTw, …) peuvent poser problème (à la compilation ou durant l’usage de GDL). Ainsi, les dernières versions de PLplot (5.6.x et 5.8) semblent poser problème avec GDL 0.9 pre 4/5/6. La version historique 5.5.3 disponible pré-packagée sous Debian ne pose pas de problème… Sous OSX, la readline fournie par Apple, ancienne et limitée, doit impérativement être mise à jour pour compiler GDL.

Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré : 
  • Il existe une version pré-compilée pour Mac OS X
  • Depuis GDL 0.9pre5, GDL est disponible via Fink sous Mac OS X http://finkproject.org/pdb/package.php/gdl
  • Il existe une version pré-compilée dans Ubuntu http://doc.ubuntu-fr.org/gdl, version 0.9pre6, en retard donc. J’ai eu des retours contrastés sur cette version
  • Il existe des RPM pour Fedora et Mandriva, pas toujours à jour, même si des efforts sont faits côté Fedora pour coller aux avancées significatives du CVS
  • Cependant, il est recommandé de privilégier les dernières versions, et même la version CVS pour les utilisateurs avancés d’IDL
  • Sur de nombreuses distributions, la plupart des dépendances (readline, GSL, python, plplot) sont déjà pré-compilées (.rpm ou .deb)
Plates-formes : 
  • Linux (Fedora, Mandriva, Debian, Ubuntu) en x86 (32 bits) et x86_64 (64 bits)
  • Mac OS X en PPC et x86 (pour cette plate-forme le site de téléchargement est : http://hpc.sourceforge.net/ ou via fink)
  • Aurait été compilé sous SunOS
  • Très délicat à compiler sous Tru64
  • N’a pas pour projet d’être utilisable en natif sous les OS Microsoft, cependant il est possible d’y compiler GDL grâce au projet CoLinux, comme expliquer ici http://hesperia.gsfc.nasa.gov/colinux/

Il y a une demande forte pour GDL sous Mac OS X, et régulièrement du retour sous Linux. Très peu de retour des autres Unix, qui semblent désormais être en phase d’obsolescence accélérée (fin de vie des machines, pas de renouvellement, basculement à Linux pour les serveurs, et à Linux et Mac OS pour les portables).

Logiciels connexes : 

Principales bibliothèques dont dépend GDL. On n’indiquera pas ici les modules métier (netcdf/hdf/hdf5) :

  • [obligatoire] gcc (pour la compilation. Sous Mac OS X, il faut gcc >= 4.0.1)
  • [obligatoire] plplot http://plplot.sourceforge.net/ (librairie pour affichage des courbes, contours, surfaces et images)
  • [optionnel, fortement recommandé] readline (cette librairie permet de gérer le clavier, la mémoire des commandes, les allers et retours sur la ligne courante (crtl-a/crtl-e …))
  • [optionnel, recommandé] GSL (GDL utilise la GSL pour plusieurs fonctions mathématiques spéciales (Bessel, Beta, …))
  • [optionnel, facultatif] python (permet d’utiliser des programmes python dans GDL)
  • [optionnel, facultatif] FFTw (l’usage de cette librairie de référence pour les FFT permet de gagner un facteur 2 par rapport à l’implémentation des FFT dans la GSL)
  • [optionnel, facultatif] libproj4 (cartographie terrestre)
  • [optionnel, facultatif] ImageMagick (permet d’importer et d’exporter dans différents formats d’image)
Autres logiciels aux fonctionnalités équivalentes : 
Environnement de développement
Type de structure associée au développement : 

Arborescence CVS : http://gnudatalanguage.cvs.sourceforge.net/gnudata...
Une dizaine de développeurs dispersés ont les privilèges pour modifier tout ou partie du CVS.

Eléments de pérennité : 
  • Logiciel libre dont le code source est disponible et qui utilise des librairies solides et largement répandues (GCC, Readline, GSL, FFTw, Plplot, ImageMagick, …)
  • Début de création d’une communauté
  • Projet hébergé chez http://sourceforge.net/
Références d'utilisateurs institutionnels : 
  • Dans mon environnement proche des enseignants de l’UFE de l’Observatoire de Paris/Meudon
  • Des personnes à la NASA, au CEA, au Max Planck, dans des laboratoires français et étrangers.
Environnement utilisateur
Liste de diffusion ou de discussion, support et forums : 

Forum : http://sourceforge.net/forum/?group_id=97659
Newsgroup : comp.lang.idl-pvwave (syntaxe, exemples, …)

Documentation utilisateur : 
Divers (astuces, actualités, sécurité) : 
  • Garantie : comme la plupart des logiciels, ce logiciel vient sans aucune garantie, et ceci a d’autant plus de sens qu’il s’agit de calcul numérique où des bugs internes peuvent ne pas apparaître immédiatement : pensez à la testabilité de vos codes et n’hésitez pas à douter du logiciel. J’ai trouvé plusieurs déficiences (souvent anecdotiques mais réelles) dans IDL en faisant des tests pour GDL.
  • La version CVS est une copie de l’état du développement public du logiciel. Elle contient les dernières corrections et améliorations, même si elle a pour but de devenir la base de la prochaine version figée, elle peut contenir des erreurs, des régressions, des ajouts peu testés ou seulement sur une plate-forme (avec les petites nuances entre les différentes distributions linux d’un côté et des versions Mac OS de l’autre, sans parler des bibliothèques connexes, cela prend vite son sens de version en cours de développement !)
    • En attendant la 0.9rc2, ne pas négliger l’intérêt des versions CVS
    • Lors de compilations de versions CVS, bien penser à conserver en parallèle des versions N-1 ou N-2 en cas de régression, ce qui arrive sporadiquement. Typiquement, le CVS apporte souvent des corrections demandées par des utilisateurs mais pas toujours testées assez largement !
  • Compatible avec les librairies Astron, Mpfit, …
  • Bien configurer les variables GDL_PATH et GDL_STARTUP (même si IDL_PATH et IDL_STARTUP peuvent être utilisées)
  • Efficacité calcul et écriture du code
    • On entend souvent dire que IDL ou GDL vont être lents parce qu’ils sont des langages interprétés. (On parle là des temps d’exécution, et non du temps d’écriture du code, car il est désormais évident que ce sont des langages permettant d’écrire très rapidement des petits codes ou du code concis). C’est bien souvent faux, car les fonctions intrinsèques sont en fait écrites en C ou en C++ et le temps d’interprétation est marginal devant le temps de calcul (si on parle de calcul. Par exemple, la FFT). La grande difficulté est de convaincre les nouveaux venus qui connaissent déjà des langages classiques (Fortran 77, C, Basic, Pascal, Java, …) à penser “sans boucle” et sans indices en IDL/GDL. Pour obtenir du code efficace, il faut laisser le langage gérer lui-même les boucles (en C++) et utiliser la syntaxe orientée objet. Pour le produit matriciel, on n’écrit pas la boucle du produit, on utilise l’opérateur adéquat (# ou ## selon les cas). Pour additionner deux vecteurs ou deux cubes de même taille, il suffit de faire A+B, on ne parcourt pas les tableaux. De même avec les autres opérations élémentaires (*, /, -, ^2). D’autres opérateurs comme WHERE, SHIFT, SORT, “<” et “>” … ont une approche identique. Dès le moment où on commence à envisager une boucle “for” probablement coûteuse en temps CPU, il convient de chercher à éviter de l’écrire en utilisant les opérateurs et les fonctions intrinsèques, parfois en découpant les opérations en quelques étapes élémentaires. Ceci fait généralement du code concis, et, s’il est bien conçu, plus général (doit pouvoir gérer le cas quelles que soient les dimensions des objets d’entrée).
    • pour information, d’après plusieurs tests (cf dans répertoire testsuite/ test_plot_benchmark), aussi bien en calcul pur qu’en affichage, GDL et IDL se tiennent à mieux que 20%, sauf situation exceptionnelle (merci de remonter les cas) ou système particulier (sous Debian, des écarts plus importants ont été relevés).
    • par ailleurs, lorsque le code est convenablement écrit des deux côtés, IDL et Matlab sont comparables en temps de calcul (test sur des FFT); donc GDL aussi …
  • Nouveautés :
    • depuis la version 0.9pre6, ont été rajoutées les fonctionnalités importantes suivantes : filtrage médian 1D/2D avec fenêtre, RK4, CURSOR, VOIGT, SKIP_LUN
    • depuis la version 0.9pre4 les NaN et Inf sont gérés dans les graphiques (PLOT, …)
Contributions : 
  • Ne pas hésiter à reporter les problèmes (et les succès). Ce sont les demandes des utilisateurs qui guident les développements, les utilisateurs connus et réguliers semblent satisfaits de l’état actuel du logiciel !
  • Signaler les (éventuels) bugs, si possible avec un petit exemple auto-suffisant en se basant sur les dernières versions (0.9pre6 ou CVS) : http://sourceforge.net/tracker/?group_id=97659 [indiquer la plateforme, les versions de l’OS, des bibliothèques actives (par exemple la sortie de “ldd gdl”) est un plus].
  • Pour les utilisateurs de longue date d’IDL, merci de reporter les éventuels problèmes, les mots-clés manquants, les différences éventuelles de comportement…
  • GDL est réputé se comporter correctement sur les procédures et fonctions de la librairie Astron largement utilisée en Astronomie, ainsi, tout retour de problème sera bienvenu.
  • Faire des essais (compilation, tests) sur des plates-formes exotiques ou nouvelles (les nouveaux Mac à processeur Intel ont posé problème pour la version actuelle d’une librairie externe mais nécessaire (Plplot)).
  • Il est relativement aisé d’ajouter en C++ des fonctionnalités intrinsèques simples, en se basant sur du code C++ GDL existant et du code externe (par. ex. la GSL). Ainsi le code (quoique incomplet par rapport à IDL) des 4 fonctions de Bessel en C++ a été ajouté après une après-midi de travail par un non-spécialiste.
  • Ne pas hésiter à soumettre une version corrigée de code en syntaxe GDL (fichiers de l’arborescence src/pro/) ou un bout de code utile.
  • Ne pas hésiter à demander le statut de tel ou tel point. Du code non publié existe (caractères mathématiques dans les titres des “plot”, …)

Commentaires

Mer, 15/10/2008 - 10:48 — Anne Durand

Fiches plume sur les logiciels aux fonctionnalités équivalentes