GDL

Fiche logiciel validé
  • Création ou MAJ importante : 11/07/13
  • Correction mineure : 11/07/13
Mots-clés
Fiche en recherche de relecteurs
Cette fiche est en recherche de relecteurs. Si vous êtes intéressé(e)s, contactez-nous !

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 (géophysique, télédétection, médecine). Il s'agit d'un langage interprété à la syntaxe simple, typé 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 dans l'interpréteur de commande (CLI) et de les afficher aisément.

Pour les calculs, ce langage interprété fait appel à des bibliothèques écrites en C et C++, ce qui n'est pas pénalisant niveau temps de calcul lorsque l'on sait s'en servir ! (cf. le paragraphe Astuces ci-dessous). Ce langage sait gérer des objets à plusieurs dimensions (vecteurs, images, cubes, ...) et des structures. À travers des commandes concises, il permet un affichage simple de courbes, surfaces et images, avec une grande richesse de paramétrage. C'est un langage idéal pour écrire des prototypes et des pipelines complexes, tester des idées de traitement sur des données, ...

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. Réciproquement, on peut appeler des codes en syntaxe GDL depuis python (nous avons eu très peu de retours sur ces usages).

Interopérabilité

De nombreux tests de régression sont faits de routine par rapport aux formats. Il ne faut pas hésiter à remonter les problèmes, notamment pour les très gros fichiers (> 4Go) et les petits/grands indiens.

  • Tout format ASCII (dont CSV lisible par tout tableur) en entrée et en sortie
  • Le format FITS est écrit et lu (via Astron ; format fréquent en astronomie)
  • Le format XDR est écrit et lu (via une bibliothèque externe, à la licence empêchant son intégration dans GDL)
  • Le format netCDF est réputé parfaitement supporté
  • Le format HDF est partiellement supporté (dans la pratique, assez largement)
  • Le format PDS est assez largement supporté
  • Le format HEALPix est supporté
  • Certains formats binaires, avec des aléas sous certaines plates-formes (de plus en plus rare)
  • Existence de bibliothèques pour d'autres formats (images, formats métier...).
Contexte d'utilisation dans mon laboratoire/service

Plusieurs personnes, chercheurs, ITA et étudiants (master et thèse), utilisent GDL de manière régulière ou sporadique à l'Observatoire de Paris/Meudon. Je (AC) suis en contact avec des utilisateurs au CEA, dans des laboratoires du Max-Planck, à la Nasa, dans des universités américaines, anglaises, en Inde, en Pologne, au Vénézuéla ... GDL est utilisée au ESC (Japon). Les nouveaux venus qui ne connaissent pas IDL sont plutôt satisfaits car la syntaxe est simple, les performances raisonnables, la stabilité aussi. Depuis 2009, des articles à "referee" sont explicitement basés sur des calculs avec GDL, après inter-validation avec IDL.

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é (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 --car décrété obsolescent-- 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
  • Nous dépendons de la qualité de logiciels extérieurs, notamment PLplot, GDL, FFTw, Eigen3, IM ou GM. Certains sont parfois mal packagés pour certaines cibles, ou connaissent des régressions temporaires. Notre suite de test permet de tester et nos problèmes et parfois des problèmes externes, notamment pour IM.
  • Les Widgets d'IDL ne sont pas que très partiellement implémentées : toute aide sera la bienvenue.
  • Certains formats sont mal relus, en particulier des fichiers binaires écrits avec IDL sur certaines plates-formes en voie d'obsolescence (e.g. VMS). Tout retour sur ces problèmes permettrait de voir si des solutions méritent d'être développées. Il ne suffit plus de dire que "ça ne marche pas", nous avons besoin de retour concret (version GDL, OS et dépendances (ldd), fichiers et code de test) pour traquer les dernières déficiences. La plupart des cas soumis ont été rapidement résolus.
  • La plupart des fonctions graphiques (plot, contour, surface, TV, ...) sont disponibles, mais certaines limitations existent (certains mots-clés manquent, absence de polices spéciales pour les titres, ...). Ceci est basé sur la bibliothèque 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%). À noter que le support de l'affichage des NaN et +-Inf a été inclus dans GDL depuis la 0.9pre4.
  • Depuis rc4, la sortie Postscript n'est plus limitée au N&B, mais il reste des problèmes dans le positionnement et la qualité des sorties Postscript.
  1. 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 bibliothèque externe manquante
    • (3) des bogues 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 bibliothèques 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 bogue 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 bibliothèques 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 (ce qui est désormais disponible nativement en OSX 10.6.x).
  • ImageMagick (IM), utilisée pour la lecture et l'écriture des formats d'images (JPG, PNG ...) est de qualité inégale. GraphicsMagick, un fork moins ambitieux, s'est révélé plus stable.
Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré

Univers Linux

  • Depuis trois ans environ des contacts ont été pris avec les packageurs pour plusieurs distributions majeures (Debian, Ubuntu, Fedora, Gentoo ...). Les nouvelles versions de GDL sont ainsi généralement re-packagées sous de brefs délais, pour la version courante des OS mentionnés. GDL 0.9.3 est ainsi largement disponible packagée ;-) [à noter que sous Debian ou Ubuntu, il est relativement facile d'extraire les sources depuis les paquets, de faire des modifications (e.g. mise à jour via le CVS) puis de recompiler http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/]
  • Une version RPM (versions pré-compilées) un peu datée existe dans les dépôts standards de CentOS
  • Il existe des RPM pour Fedora, plutôt à jour, car des efforts sont faits côté Fedora pour coller aux avancées significatives du CVS (demande institutionnelle)
  • Il existe des paquets (versions pré-compilées .DEB) dans Ubuntu, versions 0.9.2.
    Des paquets basés sur la version CVS actuelle sont disponibles
  • Il existe des paquets pas trop anciens pour Debian

Univers OSX

  • la version MacPort est généralement très proche de la version CVS
  • Depuis GDL 0.9pre5, GDL est disponible via Fink sous Mac OSX mais ces versions ne collent pas toujours aux avancées
  • Il existe d'autres versions pré-compilées pour Mac OSX, pour PPC, x86 et x86_64, mais il faut bien s'assurer de l'adéquation avec son propre système et si la version est suffisamment récente (la version sur http://hpc.sourceforge.net/ est désormais vraiment ancienne !)
  • Cependant, au-delà des versions pré-compilées, il est recommandé de privilégier les dernières versions compilées par soi-même, et même la version CVS pour les utilisateurs avancés d'IDL. Pour OSX, un tutoriel est régulièrement mis à jour

L'équipe de développement teste régulièrement le CVS avec la suite de tests sur une quinzaine de configurations (variations autour de OSX, CentOS, Fedora, Mandriva, Debian, Ubuntu, OpenSolaris ...). Si vous avez des problèmes de compilation avec le "configure" ou son alternative "cmake", il ne faut pas hésiter à nous contacter.

Sur de nombreuses distributions, la plupart des dépendances et leur versions __devel__ (readline, GSL, python, plplot, FFTw) sont déjà pré-compilées (.rpm ou .deb)

Plates-formes
  • Linux (Fedora, CentOS, Mandriva, Mageia, Debian, Ubuntu) en x86 (32 bits) et x86_64 (64 bits)
  • Mac OSX avec processeurs PPC, x86 et x86_64
  • Aurait été compilé sous SunOS, réputé disponible sous OpenSolaris
  • 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 expliqué ici. Un port a été inclus dans le CVS mi-2013.

    Il y a une demande forte pour GDL sous Mac OSX, 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 OSX, il faut gcc >= 4.0.1)
  • [obligatoire] plplot (bibliothèque pour affichage des courbes, contours, surfaces et images). Pour des raisons d'évolution internes à plplot, nous envisageons d'exiger bientôt plplot >= 5.9.1.
  • [obligatoire] GSL (>= 1.7) (GDL utilise la GSL pour plusieurs fonctions mathématiques spéciales (Bessel, Beta, ...), les matrices et les solveurs d'équations)
  • [optionnel, fortement recommandé] readline (cette bibliothèque permet de gérer le clavier, la mémoire des commandes, les allers et retours sur la ligne courante (crtl-a/crtl-e ...) et la complétion de certaines commandes, chemins et noms de fichiers (bluffant par rapport à IDL))
  • [optionnel, fortement recommandé] Eigen3, bibliothèque de calcul vectoriel et matriciel, utilisant au mieux les subtilités internes des processeurs (SSE) et les multi-cœurs.
  • [optionnel, fortement recommandé] FFTw (l'usage de cette bibliothèque de référence pour les FFT permet de gagner un facteur 2 par rapport à l'implémentation des FFT dans la GSL ; la FFT sur des grands tableaux est plus rapide dans GDL avec FFTw que dans IDL)
  • [optionnel, recommandé] GraphicsMagick ou ImageMagick (IM) (permet d'importer et d'exporter dans différents formats d'image). Il se trouve que la qualité des versions IM est très variable, par ex. la version 6.6.9.7-5ubuntu3.1 donne des résultats faux sur 4 des 6 de nos images test.
  • [optionnel, facultatif] python (permet d'utiliser des programmes python dans GDL). Attention, nous avons parfois des soucis avec les évolutions et la localisation des versions Python. Aide bienvenue.
  • [optionnel, facultatif] libproj4 (cartographie terrestre)
  • [optionnel, facultatif] wxWidgets pour les Widgets.
Autres logiciels aux fonctionnalités équivalentes

Logiciels libres (sous licence GPL)

Propriétaires

  • IDL, logiciel propriétaire et cher
  • Matlab, dans une certaine mesure
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.

Lorsque nous recevons du code ou des patchs utiles, sous licence GPL ou compatible (aucun code dérivé des NumRecip ne peut être accepté), avec si possible des cas de tests, nous l'intégrons dans le CVS. Ces dons de code peuvent être réalisés directement auprès des auteurs, ou via le tracker sur SourceForge.

Plusieurs personnes ont pris en charge le portage de bibliothèques en syntaxe IDL vers GDL (e.g.: Astron, FITS, MPfit, HEALPix, iCosmo, PDS, ...). Ce genre d'activité peut être très instructive pour un stagiaire encadré par un utilisateur d'une telle bibliothèque et le code reversé bénéfique à tous.

Eléments de pérennité
  • Logiciel libre dont le code source est disponible et qui utilise des bibliothèques 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 et des collègues de l'Observatoire de Paris/Meudon. Plusieurs TPs numériques Bac+4 et +5 ont été tenus avec succès sous GDL par plusieurs enseignants ces deux dernières années.
  • Des personnes à la NASA, au CEA, au Max Planck, à l'Earth Simulator Center, dans des laboratoires français et étrangers.
  • Des articles scientifiques dans des revues à comité de lecture contiennent des calculs faits par GDL (pour certains, un travail préparatoire de comparaison et validation avec IDL a été fait).
  • Des calculs lourds (HPC, 400 cœurs, monté carlo pour calcul de lobes pour la mission Planck HFI) ont été faits en GDL après de larges comparaisons (précision, performance) avec IDL.
Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
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 dans IDL (souvent anecdotiques mais réelles (cf aussi le célèbre print, BESELI([1], [1,1,1]), la décimation dans INTERPOLATE() (pas de calcul interne en Double), les problèmes de retour par valeur dans CHOLDC ...)) 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 !)
    • Même si une version majeure, la 0.9.3, vient de sortir, il ne faut pas négliger l'intérêt des corrections et ajouts dans le CVS (l'usage d'Eigen3 n’apparaît que dans le CVS !)
    • Certains bugs ou déficiences connus (e.g. espaces et caractères spéciaux dans les chemins et noms de fichiers, connaître la mémoire allouée sous Linux 64b) peuvent ne pas avoir de solutions simples.
    • 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 ! (même si nous tentons d'intégrer autant de tests pertinents que possible dans la suite de tests)
  • Compatible avec les bibliothèques Astron, Mpfit, CMSV, Wavelet ...
  • Bien configurer les variables GDL_PATH et GDL_STARTUP (même si IDL_PATH et IDL_STARTUP peuvent être utilisées). Un petit script dans la racine du CVS (quick_start_GDL.sh) est là pour montrer aux débutants comment ajouter des chemins dans ces variables
  • Efficacité du 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, l'inversion de matrices, le produit matriciel ...). 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). Un gros travail a été fait sur les multi-cœurs pour GDL 0.9.2 (openmp) et GDL est fréquemment plus rapide qu'IDL 7 et 8 sur 8 et 16 cœurs sur un jeu de tests de calculs lourds.
    • 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 :
    Voir le fichier http://gnudatalanguage.cvs.sourceforge.net/viewvc/...

    • depuis la version 0.9rc4 : notamment progrès sur les fonctions autour des strings, et famille FILE_*, DIALOG_PICKFILE
    • depuis la version 0.9rc3 : NEWTON et BROYDEN, fonctions de Besel pour les ordres non entiers, de nombreuses subtilités sur les formats ASCII à la C et à la Fortran
    • depuis la version 0.9rc2 les Splines, filtrage médian 1D/2D avec fenêtre
    • depuis la version 0.9rc1, ont été rajoutées les fonctionnalités importantes suivantes : RK4, CURSOR, VOIGT, SKIP_LUN
    • depuis la version 0.9pre4 les NaN et Inf sont gérés dans les graphiques (PLOT, ...)
    • dans le CVS (après 0.9.3), un usage large de Eigen3 est fait, avec des performances très intéressantes, non seulement sur les opérations matricielles coûteuses, mais aussi sur certaines opérations élémentaires, car des subtilités des CPU sont utilisés.
Contributions
  • Ne pas hésiter à reporter les problèmes (et les succès), si possible via le tracker SourceForge. 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.9.3 ou, mieux, CVS) : http://sourceforge.net/tracker/?group_id=97659 [indiquer la plate-forme, 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... (pour des raisons historiques, certains mots-clef qui ont disparu de la documentation IDL actuelle sont toujours disponibles, et des vieux codes peuvent les utiliser : nous devons donc les gérer aussi)
  • GDL est réputé se comporter correctement sur les procédures et fonctions de la bibliothèque Astron largement utilisée en astronomie, ainsi, tout retour de problème sera bienvenu. Certains procédures récemment introduites dans IDL sont souvent utilisées par Astron: nous évitons ces problèmes en indiquant à Astron que GDL se comporte comme un vieil IDL.
  • Faire des essais (compilation, tests) sur des plates-formes exotiques ou nouvelles (fut un temps, les nouveaux Mac à processeur Intel ont posé problème pour la version actuelle d'une bibliothèque 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 (si sous licence GPL).
  • 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", ...)