Il s'agit techniquement parlant d'un gros ensemble de bibliothèques et d'un interpréteur C/C++. L'ensemble peut fonctionner soit en mode interprété soit en mode compilé. ROOT inclut en plus de ce qui est nécessaire à l'analyse de données une boîte à outils graphique intégrant le mécanisme slot/signal à la Qt.
Il est conçu pour être utilisé par des physiciens (sachant programmer) et non des informaticiens et devrait être maintenu un bon bout de temps.
Il est à noter qu'il existe également une implémentation en Python (PyROOT) et un module d'Apache permettant d'écrire ses pages web en C++ (caROOT). Également à noter que les physiciens étant également de grands amateurs de trolls, les environnements d'analyse n'y échappent pas et que beaucoup de gens vous diront que c'était mieux avant (PAW + FORTRAN), ou encore que le concurrent est mieux ( JAS basé sur JAVA).
Aller plus loin
- Logiciel Root (36 clics)
- Notes de version (5 clics)
- Un journal sur root (51 clics)
- Ancienne licence (1 clic)
# ROOT c'etait mieux a vent
Posté par Sebastien . Évalué à 10.
Au debut j'aimais bien ROOT. C'etait fun, tu penses bien, apres avoir programme en FORTRAN et en KUMACs (langage de script pour PAW, le papa de ROOT), jouer avec le C++ c'etait bien (TM).
Le probleme c'est que ROOT a ete ecrit au debut par l'auteur (R. Brun) de PAW. Comme aux debuts de tout programmeur dans un nouveau langage, la premiere version merite toujours un rm -rf bien senti.
Cependant, cette reorganisation de ROOT n'a pas ete menee.
Du coup on se traine des methodes de programmation qui datent des annees 90 avec un arriere gout Fortraneux des plus desagreable ainsi qu'un design des classes relativement discutable.
D'ailleurs une multitude de choix sont discutable.
Tout d'abord, laisser a un physicien ecrire des macros C++ pour l'interpreteur (CINT) est une grosse boulette. Le profil type du physicien qui va utiliser ces macros est le nouveau switcher depuis FORTRAN/PAW. A force d'essayer de lui faciliter la transition (ce qui est une attention louable en soi) on lui donne de mauvaises habitudes (on peut ecrire des horreurs qui piquent les yeux avec cet interpreteur! du genre double hyp = a**2+b**2;).
Personnellement, je n'utilise jamais cet interpreteur : je prefere de loin utiliser le prompt de python et charger les objets ROOT qui m'interessent.
Avec ROOT 5, on commence a avoir un support a peu pret correct de la STL.
Cependant, dans la majeur partie des cas (remplissage de tuples par exemple) il faut toujours passer par des tableaux "a la C", je pense que la perte de performances (combien d'ailleurs?) ou l'overhead induit par les conteneurs de la STL sont un compromis plutot honnete par rapport au gain en "sûreté"!
Design objet : ben, oui parce que ROOT ca veut dire "the Root of all Objects : an object oriented data analysis framework".
Le probleme ici c'est que certains choix de l'arbre d'heritage me laissent dubitatif : est-ce qu'un histogramme 2D est vraiment une specialisation d'un histogramme 1D ? Ou dit autrement, est-ce qu'un cercle est vraiment une sorte d'ellipse[1] ?
Un autre gros probleme : la separation du stockage des donnees et de leur representation. Dans le cas general, ca n'existe pas. L'objet servant a representer les donnees, contient egalement ces memes donnees. Du coup on est un peu gene aux entournures.
Ex: si je veux etre absolument sur que les donnees de mon histogramme ne seront jamais modifiees, je vais mettre mon histo const. Mais alors je ne pourrai pas changer le style de mes points ou la couleur des barres de d'histogramme !
On se retrouve alors a faire des copies d'histogrammes completement superflues !
Corrollaire: la constness de ROOT est une notion vaguement saupoudree dans les classes.
Et le grand final : les options que l'on peut passer aux objets.
C'est simple, tout se fait avec des chaines de caracteres :
histo->Draw("b,s,p");
Detail : ces options ne sont pas documentees (ou tres mal : use the source Luke!)
Bref, mon avis personnel est que ROOT est une usine a gaz dont le design complet est a revoir, meme s'il faut reconnaitre que les bibliotheques mathematiques n'ont pas a rougir face a GSL.
Des solutions comme HippoDraw[2] ou AIDA[3] me semblent avoir des bases plus solides et reposer sur des concepts plus robustes pour faire ce qu'on leur demande de faire.
Heureusement qu'il y a PyROOT pour faire passer la pillule.
PS : il existe aussi un module Ruby pour ROOT
http://root.cern.ch/root/HowtoRuby.html(...) [En]
PS2: un site qui detaille un peu plus les faiblesses de ROOT
http://www.insectnation.org/howto/living-without-root(...) [En]
[1] http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-2(...) [En]
[2] http://www.slac.stanford.edu/grp/ek/hippodraw/index.html(...) [En]
[3] http://aida.freehep.org/index.thtml(...) [En]
[^] # Re: ROOT c'etait mieux a vent
Posté par riba . Évalué à 4.
[^] # Re: ROOT c'etait mieux a vent
Posté par salvaire . Évalué à 5.
- Paw était parfois mieux
- une partie du code est à l'origine du fortran converti par f2c (graphique)
- à le même défaut que Paw, pseudo interpréteur fortran "commis" -> Cint
- au lieu d'utiliser des enums, ils utilisent des nombres, par exemple 2 pour la couleur rouge
- La GSL me semble plus complète sur certains points, et programmé par des gens compétents
- Des algorithmes numérique (multiplication des matrices) ont été programmé par des gens totalement ignorant en math et en calcule numérique. C'est un comble pour un tel logicielle.
Ps: pour moi, un cercle et une ellipse c'est la même chose. Seul les propriétés de la base change.
Ps: Il existe un binding SWIG (perl, python, ruby) pour Root http://www.desy.de/~salvaire/root_wrapper.html(...) qui permet d'oublier totalement Cint pour interfacer son propre code.
# Root passe à la poubelle ...
Posté par salvaire . Évalué à 6.
Je viens de découvrir qu'après 10 ans de développement! Que la fonction la plus basique, soit superposer deux histogrammes, ne fonctionne pas correctement ...
Une merveille! Si vous voulez savoir ou passe l'argent public dans la recherche, jetez un coups d'oeil dans les sources.
Au menu:
- Cint un interpréteur de C++ qui comprends seulement 60% de la norme. Avec une gestion des erreurs tellement calamiteuse. Que pour trouver une erreur de syntaxe dans un programme, il faut le compiler avec g++ ... Le parser de Swig et incomparablement meilleur.
- Utilise son propre système de documentation à chier au lieu de Doxygen
- Utilise une GUI à chier, qui ne sera entre autre jamais anti-aliasé (au lieu Qt Gtk+)
- Développe un moteur 3d qui va révolutionné le monde de la CAO (au lieu d'OpenCascade/ voir Blender), genre raytracer CSG en 3000 lignes de code. Évidement les breps, quaternion ne sont pas au programme. Quand on réinvente systématiquement la roue, on fait simple ... trop simple.
- L'api pour les graphes, histogrammes est à chier. On ne peut pas exemple, récupérer le tableau des bin, l'inverser, et le multiplier avec le tableau du contenu des bins. Soit pas d'opération de tableau, de matrice.
- et tous est comme ça ...
Le seul point positif: le système de stockage. Bien que programmé avec les pieds, est très efficace pour des volumes de plusieurs To de données.
Je dirai plutôt: Il est conçu par et pour des physiciens ne sachant pas programmer qui vive dans leur petit monde, avec leur propre idée et méthode.
Heureusement, il y a la GSL, GnuPlot, et mathlab (sic !)
[^] # Re: Root passe à la poubelle ...
Posté par riba . Évalué à 5.
même pas! Les containers et cie sont biens pensé[1], mais les I/O c'est du n'importe quoi, alors certains les réécrivent ( package RIO de http://openscientist.lal.in2p3.fr/(...) )
[1] oui enfin y'aura jamais les column wise ntuple, donc bon, c'est quand même moins bien qu'avant...
[^] # Re: Root passe à la poubelle ...
Posté par Sebastien . Évalué à 3.
Ca j'aimerais bien qu'on m'explique pourquoi.
Enfin surtout, pourquoi on les a laisses tomber...
Dans ATLAS on s'en sort grace au framework Gaudi qui nous permet d'avoir un pseudo CWNT (je dis pseudo parce que 1) je n'ai pas regarde exactement comment c'etait fait 2) comme c'est du ROOT derriere...) mais ce serait tellement plus simple si on l'avait directement (surtout dans une session en interactif)
[^] # Re: Root passe à la poubelle ...
Posté par riba . Évalué à 2.
la taille des objets devient alors dynamique (genre pour cet evt y'a 200 traces, celui d'après y'en a que 10, ...), et naviguer dans ton ntuple devient plus "sport" (tu peux plus faire 0 + n * size ). Un moyen de s'en sortir, c'est prévoir très très large et remplir normalement, et après tu fais confiance à l'algo de compression des données pour pas que la taille explose.
> Dans ATLAS on s'en sort grace au framework Gaudi
je connais[ais][1], t'as des interface virtuels qui appellent les bonnes fonctions derrière: soit la lib hbook (PAW), soit la lib rootmachinchose[2].
[1] ça a peut-être vachement changer depuis le temps (pfiouuuu).
[2] sauf que root, des que tu veux un petit bout, tu te récupères les 100Mo de libs (bienvenue dans le monde TWorld!!!)
[^] # Re: Root passe à la poubelle ...
Posté par Sebastien . Évalué à 3.
Ca a pas l'air mal.
L'interface ressemble furieusement a AIDA (ce qui n'a rien d'etonnant puisque G. Barrand fait egalement partie de l'equipe de devs).
Par contre je me demande si la partie dictionnaire est vraiment utile, puisqu'avec ROOT 5 la fusion avec le mecanisme de generation de dictionnaire de LCG/SEAL[1,2] est entamee...
Enfin, ca vaut le coup de garder un oeuil dessus : merci pour le lien :)
[1] http://seal.web.cern.ch/seal/(...)
[2] http://seal-reflex.web.cern.ch/seal-reflex/index.html(...)
[^] # Re: Root passe à la poubelle ...
Posté par riba . Évalué à 2.
Mon expérience (t'as du deviner y'a des incices) utilisait discretement ce paquage pour ses I/O au lieu de prendre les recomendations du LCG, cad ROOT, (mais chut faut pas le dire). Peut-être que maintenant ils font ça plus clean (c'était du root 3 à mon époque).
> Par contre je me demande si la partie dictionnaire est vraiment utile, puisqu'avec ROOT 5 la fusion avec le mecanisme de generation de dictionnaire de LCG/SEAL[1,2] est entamee...
Aucune idée de ce qu'est devenu root 5, mais j'ose même pas aller voir le changelog, j'ai peur!
> Enfin, ca vaut le coup de garder un oeuil dessus : merci pour le lien :)
T'as qu'à aller embeter guy de ma part. Ahh les bons vieux troll d'info, qu'est-ce-qu'on se marrer à l'époque, ça doit être moins marrant maintenant, avec le stress toussa (d'ailleurs c'est repoussé à quand maintenant le LHC? De mon temps c'était toujours "dans 5 ans", quelque soit l'année!)
[^] # Re: Root passe à la poubelle ...
Posté par Sebastien . Évalué à 2.
Et bien pour ROOT 5, les deux equipes de developpement du CERN, LCG/SEAL et ROOT, ont regroupe leurs forces pour homogeniser la gestion des dictionnaires.
Les termes du regroupement sont relativement flous, un bon resume : les gens de ROOT (et en premier R.Brun) voient cela plus comme une assimilation "a la Borg" et les gens de SEAL, plus comme un regroupement "a la Federation" (si on prend le parallele de Star-Trek ;)
Il y a aussi une reorganisation des libs de physique ainsi que l'introduction du systeme de plugins de SEAL.
Le framework SEAL est bien plus propre (a mon avis, mais ca n'engage que moi) et j'espere que l'on retrouvera plus de SEAL dans ROOT que du ROOT dans SEAL !
De mon temps c'était toujours "dans 5 ans", quelque soit l'année!
Et bien il faut recalibrer : maintenant c'est "dans 2 ans". Mais bon, on prend deja des donnees [1].
Mon expérience (t'as du deviner y'a des incices)
Je dirais que ca parle de beaute et de violation... Qu'est-ce que j'ai gagne ?
[1] http://www.nature.com/nphys/journal/vaop/nprelaunch/full/nphys005.h(...)
[^] # Re: Root passe à la poubelle ...
Posté par salvaire . Évalué à 2.
On peut l'esperer. Mais tous est tellement imbriqué, j'ai peur qu'il ne soit trop tard pour demerdouillé le bouzin. Risque de redondance, d'interface pour interfacer l'interface de ... De plus gccxml ne semble pas maintenu.
Il y a du pain sur la planche. Car je voie mal LHC se taper durant 10 ans une usine à gaz conçue en 1995. En 2010, ça fera 15 ans.
[^] # Re: Root passe à la poubelle ...
Posté par Sebastien . Évalué à 2.
Je rajouterais : il y a R et Octave ;)
http://www.r-project.org/(...) (down a l'heure ou j'ecris ces lignes)
http://www.octave.org/(...)
[^] # Re: Root passe à la poubelle ...
Posté par Anonyme . Évalué à 5.
Doxygen est apparu quand ?
« - Utilise une GUI à chier, qui ne sera entre autre jamais anti-aliasé (au lieu Qt Gtk+) »
C'est sur qu'en physique des particules, l'anti-alias des polices est vraiment la top-priorité !
« Je dirai plutôt: Il est conçu par et pour des physiciens ne sachant pas programmer qui vive dans leur petit monde, avec leur propre idée et méthode. »
En même temps, le projet à des utilisateurs non ? Donc si leur manière de faire ne te convient pas, comment dire, tu fais ton propre machin, hein ?
Parce que là, j'ai un peu l'impression que tu viens juste cracher dans la soupe.
Bon autant le dire tout de suite, moi, de ROOT, je ne vois que le "user guide" de 400 pages qui traine dans le bureau et les bôoh posters dans le couloir. :))
[^] # Re: Root passe à la poubelle ...
Posté par salvaire . Évalué à 3.
Et alors? Pourquoi garder la même merde? Dans H1oo (Root 900 classes + ...), il faut utiliser la fonction recherche pour accéder à une classe.
C'est quoi la priorité? Reprogrammé Gtk+ et Qt? Faire joujou avec l'API Freetype et X11, pour ne pas avoir des polices illisibles?
Les gens qui sont content de Root, ne doivent pas sans servir! Parce qu'il y a des jours, je reviendrai volontiers au papier millimétré.
# HEP uniquement ?
Posté par qpad . Évalué à 3.
Mais franchement à part dans notre secte de physiciens ('HEP') est-ce que ROOT est utilisé ailleurs ?
Et est-ce que tous les problèmes décrits plus haut sont reconnus dans le milieu ? Par exemple est-ce qu'on envisage sérieusement des alternatives ?
Parceque j'avais bien entendu quelques critiques, mais pas aussi virulentes ...
[^] # Re: HEP uniquement ?
Posté par salvaire . Évalué à 3.
Chute, c'est un sujet tabou ... Heureusement le milieu ne fréquente pas linuxfr.
Regarde le Lal:
Le service informatique (quand j'y était en 2002) était anti linux et pro M$. Interdiction d'avoir un poste client sous Linux. Administration des serveurs Unix sous windows. Un malheureux serveur Linux. Un projet de serveur Windows pour la physique. Pas d'administrateur Linux. Des vieux. Des gens qui développe sur des stations Alpha.
L'obtention de nouveau poste ou de budget relève du miracle. La communauté est obtus et fermé sur soi. Il n'y a pas de feedback, de partage. Le problème il est là. Dans une entreprise comme mathlab, tu peu embaucher, tu as une entré d'argent, des clients, un management, une ligne de conduite, une équipe. Mais dans un labo, tu as rien. Juste deux pauvres gars, et une communauté constitué de gens qui ne pensent qu'au prix Nobel ... C'est triste!
[^] # Re: HEP uniquement ?
Posté par riba . Évalué à 2.
ouais mais tu pouvais saturer lx1... y'avait personne dessus!
[^] # Re: HEP uniquement ?
Posté par qpad . Évalué à 2.
Mais je suis d'accord que c'est dur d'etre optimiste...
[^] # Re: HEP uniquement ?
Posté par Sebastien . Évalué à 2.
Et oui... C'est surtout utilise par les gens qui font de l'imagerie medicale. Generalement ce sont des anciens physiciens des particules qui ont senti faiblir la branche sur laquelle ils etaient assis et ont donc operes une conversion...
En fait ce qui est utilise c'est Geant4[1] pour la modelisation des depots d'energie et une surcouche ROOT pour la visualisation ou alors juste pour le stockage des donnees. Exemple : GATE[2]
Sans doute egalement des astrophysiciens (mais ce sont des cousins :P )...
[1] http://geant4.web.cern.ch/geant4/(...)
[2] http://www-lphe.epfl.ch/~PET/research/gate/physics/petbench.html(...)
[^] # Re: HEP uniquement ?
Posté par thecat . Évalué à 4.
Et pourtant on le répète encore et encore ... ne JAMAIS se connecter en root !!!
[^] # Re: HEP uniquement ?
Posté par curlyd . Évalué à 2.
Le plus drole c'est que je suis en ce moment dans un tutoriel sur..ROOT[1]!! Car c'est toujours largement diffuse et pas que par ATLAS : ALICE aussi est sur les rangs.
PS. Desole pour les ', ^ et autres `
[1] http://gks05.fzk.de/Agenda.html
http://gks05.fzk.de/upload/abstracts/ROOT_PROOF.html
http://gks05.fzk.de/upload/Exercises/exercises.html
# Une petite question sur l'analyse de données
Posté par Laurent Saint-Michel . Évalué à 3.
Le but est d'obtenir :
- une presentation type tableur des données pour pouvoir supprimer des données;
- par couple de série de données, un graphe temporel avec deux ordonnées
Connaitriez-vous un logiciel capable faire ce genre de graphe? Je précise que l'intervention humaine doit être limité au maximum si possible masi il doit être possible de modifier par exemple les couleurs ou l'ordre des colonnes.
J'ai essayé sans résultant probant SCIgraphica (crash reproductible à lecture des données), Qtiplot (inutilisable pour cestte apllication), GNUplot (trop "compliqué" pour le pekin moyen) et labplot (trop difficile aussi).
C'est un peu HS désolé
A+
L.
[^] # Re: Une petite question sur l'analyse de données
Posté par salvaire . Évalué à 1.
En gros tu peu faire la classification suivante:
- Interface graphique (souris):
* tableur (Ecxel, gnucalc, ...) pour le neuneu
* type labview pour l'électronicien, ...
* logicielle "maison" pour faire des graphes. En général, ils sont trop peu avancé pour être réellement utilisable
- Interface langage spécifique
* type matlab et clones (octave, gnuplot, scilab ...)
- Interface C++, Perl, Python
* usine à gaz, genre Root, pour le spécialiste
* logicielle basé sur Python, Perl sont ils complets?
[^] # Re: Une petite question sur l'analyse de données
Posté par salvaire . Évalué à 2.
[^] # Re: Une petite question sur l'analyse de données
Posté par Laurent Saint-Michel . Évalué à 3.
Je crois que je vais develloper une petite surcouche à GNUplot pour ce besoin precis.
Merci des infos.
A+
L.
[^] # Re: Une petite question sur l'analyse de données
Posté par salvaire . Évalué à 3.
Sinon, il y a
http://matplotlib.sourceforge.net/(...)
http://pdl.perl.org/index_en.html(...)
LaTeX est aussi très utile, voir pstricks et xypic. Je m'en sert au quotidien pour ajouter le texte dans mes plots.
[^] # Re: Une petite question sur l'analyse de données
Posté par THE_ALF_ . Évalué à 3.
J'utilises essentiellement ce logiciel pour tous mes graphiques (pour publis, rapports, présentations etc...) ainsi que pour pas mal de traitement de données. Et pour le coup du "l'intervention humaine doit être limité au maximum si possible", c'est batchable donc y'a surement moyen. C'est un à mi-chemin entre Origin et KaleidaGraph, si tu connais. Beaucoup plus utilisable et stable que SCiGraphica, a mon avis.
[^] # KaleidaGraph
Posté par salvaire . Évalué à 3.
De plus, c'est made in USA et ils vendent ça 200$ et 140$ en académique. Je pleure ...
[^] # Re: KaleidaGraph
Posté par THE_ALF_ . Évalué à 2.
Du coup, j'ai eu la joie de devoir faire tourner kaleidagraph sous Linux via Basilisk2 (émulateur mac) pour pouvoir récupérer les plus anciennes de mes données de ma thèse (vive les formats proprios)... et pouvoir les utiliser proprement avec Grace.
Quand je disais que Grace est entre Origin et Kaleida, je voulais surtout dire que Grace à des fonctionnalités s'approchant plutot de Origin, tout en ayant un look and feel plus proche de Kaleida. Enfin bon, c'est des impressions tout ça, mais si vous êtes habitués à Origin, c'est peut-être un peu déroutant au début.
# Atelier ROOT 2005
Posté par Sebastien . Évalué à 2.
Comme je le disais plus haut, il semblerait qu'avec ROOT5 on ait (enfin!) un support complet des conteneurs de la STL.
Doxygen n'est pas envisage (mais THtml va etre reecrit)
Sans doute un meilleur decoupage des bibliotheques pour qu'elles puissent etre reutilisees en dehors de ROOT.
[1] http://agenda.cern.ch/fullAgenda.php?ida=a055638(...)
# ROOT,logiciels d'analyse du CERN : comment finir par dir non à l'Europe.
Posté par Barrand Guy . Évalué à 2.
J'ai beaucoup apprécié les réactions de ce forum car cela rejoint un combat que je mène avec d'autres (trop peu) depuis maintenant plus de 20 ans pour le cas PAW et 10 ans pour le cas ROOT. En gros, comment faire pour que le CERN, un laboratoire qui prétend avoir le E de européen dans son nom et qui va être, avec le LHC, au coeur de la physique mondiale sous peu, arréte de produire du logiciel pour la physique qui est une honte pour l'humanité ?
D'abord il faut démolir les idées reçues ; ROOT n'a pas été "pensé" par des physiciens. Le drame est qu'il a été pensé par de mauvais informaticiens qui ont la chance d'être "sur place", donc proche des physiciens et là où sont produits les données. Ces gens, donc dans une position defacto dominante, sont hélas de très mauvais ingénieurs et de plus en position idéale pour faire passer a peut près n'importe quoi ; c'est le "syndrome Bill Gates" bien connu des gens qui se battent pour avoir enfin un operating system (oups un "système opératif") supportable. Ce syndrome est en gros celui de quelqu'un qui arrive avec un bout de code mal fichu mais qui a le bon goût d'arriver au moment opportun pour capturer une niche écologique importante. Pour ROOT, le parallèle avec Windows est vraiment saisissant. Voir ma page "HEP soft-war ?" à (pub) http://OpenScientist.lal.in2p3.fr pour une comparaison.
Donc ROOT n'as pas été pensé par des physiciens mais bien par de mauvais "ingénieur logiciel" (je préfère ce terme a "informaticiens" ; sans être péjoratif, ce n'est pas le même boulot d'écrire du logiciel scientifique que de faire de l'exploitation ; voir ma diatribe sur la question à la section "HEP soft-war ? Software for Physics Department in labs").
Du fait de l'emplacement stratégique du garage ou il a été mal conçu (donc près du CERN), ROOT a profité de contribution multiple de certains physiciens et de 10 ans d'input des physiciens sur PAW. Donc au premier ordre il est vrais que ROOT fait 99%
du boulot que demande un physicien. Et alors direz vous ? Et alors il est vrais aussi que Windows finit par faire 99% du boulot que l'on demande a un OS mais que tout le monde est d'accord pour dire que l'humanité se portera mieux lorsqu'on en sera enfin débarrassé. Un machin mal fichu demeure un machin mal fichu et un jour ou l'autre cela vous saute à la figure. Donc il faut s'y coller et le plus tôt sera le mieux.
A propos des physiciens, il est à noter que j'ai dit "certains". Etant dans un laboratoire HEP non-CERN, je côtoie tous les jours des gens qui s'arrachent les cheveux avec ROOT et souvent les laptops (oups les "sur-les-genoux") volent contre les mures. D'ailleurs, depuis 1995 où ROOT a commencé à polluer nos machines, je suis a peu près sûre que le taux de commandes de "sur-les-genoux" (c'est le cas de le dire) a progressé chez nous. Mais à propos de mes chers physiciens il y a tout de même quelque chose que je ne comprends pas. En gros, en HEP on récupère pas mal "de crème" : X, normalien, centralien, etc... En principe on s'attendrait à ce que ces gens aient deux brins de jugeote sur les questions techniques. Mais de manière surprenante, quasiment aucun ne se lève en place publique pour faire quelque chose pour avoir du meilleur software ; pour ROOT, tout le monde supporte sans broncher. Curieux. Ceci est probablement à corréler avec la passage très tardif chez nous du FORTRAN à des langages orientés objets. HEP a finit par percuter dix ans après tout le monde. Bizarre. Des fois il y a des choses qui m'échappent. Soudainement, qu'en on parle software les gens deviennent incroyablement bouchés (restons poli) et la "crème se met à tourner". Si un sociologue / psychologue cherche un sujet de thèse, il y a matière en HEP...
Pour les gens pas convaincu que ROOT est mal fichu, je peux en apporter une preuve simple ; l'existence de la méthode TClass::Draw() qui résume a peut près tout. En gros ces mauvais ingénieurs ne sont pas fichu de faire la différence entre un système d'introspection et un package graphique ! Pour que tout le monde suive ; en gros un système d'introspection est un truc basique important, qui hélas manque cruellement a C++ (sans commentaire). Cela permet, entre autre, par programme, d'interroger une classe sur son héritage, ses gentils membres, ses méthodes (pas catholiques pour ROOT), etc... Ceci permet de faire des tas de choses intéressantes, comme par exemple d'écrire des adapteurs de manière génériques pour faire le lien des classes "data" (description des données dans un détecteur par exemple) avec des "facilités" comme par exemple un système de stockage, où de scripting ; par exemple wrapper (enrober ?) du C++ vers du Python. (Voir ma page "architecture" sur le modèle "BAF" ou "SAF"). Fort bien, donc l'introspection est basique et devrait venir avec tout langage OO (donc gros raté du coté C++). Ici soyons honnête, ceci a été bien vu du coté du garage qui a vu l'intérêt de coupler l'introspection avec le stockage pour produire des streamers automatiques pour des classes "data" (ou user) ; d'où CINT et le TClass, très bien.
Mais peut on m'expliquer pourquoi on arrive avec une méthode Draw() dans une classe "Class" ???
Le fond du problème est que malgré tout, ces garagistes ne sont pas capable de séparer les problèmes et de comprendre qu'il faut du logiciel pour gérer le stockage des données et d'autre logiciels pour gérer le graphique ou l'interface utilisateur. C'est la base du processus scientifique que de séparer les problèmes. Un symptôme de l'esprit "intriqué" (au sens quantique) de ces gens, est par exemple le lien avec CINT.
CINT (pour Crashy INTerpreter ?) est un interpréteur C++ qui a été développé hors ROOT, et est hélas distribué maintenant à travers ROOT. (Ne cherchez pas de site pour CINT, il n'y en a pas, et c'est dommage). CINT en lui même pourrait être intéressant pour plein de chose hors ROOT, et donc il semble raisonnable de dire : je prends la distribution standard de CINT, je l'installe hors ROOT, et après je fais une installation de ROOT en s'appuyant sur l'installation standard de CINT. Ce que tout le monde fait avec zip, freetype2, OpenGL, X11, etc, etc.... Mais non ! avec CINT ça ne marche pas ; les garagistes ont réussis à polluer CINT avec du code spécifique pour ROOT, et donc CINT doit être construit de manière spéciale pour ROOT (il y a des cpp : #ifdef G__ROOT dans CINT !). Donc CINT est maintenant intriqué / pollué par ROOT et il faut faire une installation spéciale pour CINT. C'est la même chose que si en gros le "ROOT core team" s'était acoquiné avec Brian Paul, développeur de Mesa (free OpenGL) ou Guido Van Rosum, développeur de Python, et avait fini par les convaincre qu'il faut des "features" spéciales pour ROOT de tel manière que maintenant il faudrait une installation spéciale d'OpenGL ou Python pour que ROOT marche bien. Tout le monde trouverait cela aberrant ; mais non, pas au CERN !
Et personne ne bronche. Et le cas CINT n'est pas isolé. Le problème c'est que tout est comme cela ; bref, au secours !
Un truc conceptuellement super dans ROOT est la "g-intrication" ; en gros les "services" du "framework" sont accessibles par des pointeurs globaux ; les gXxx (gSystem, gStyle, gDirectory, etc...). Et chaque T-classe d'un "service" utilise les autres "services" à travers cela. En gros l'encapsulation, une base de l'orienté objet, est cassé à la base. Pour le développeur c'est un cauchemar a suivre. En particulier il
y a des relations entre classes qui n'apparaissent jamais à travers les méthodes et donc intraçable par exemple avec Doxygen.. Et je ne parle pas des liens fait avec des strings (non pas ceux la) en passant par l'interpréteur (donc par gInterpreteur !)
(des strings qui ne sont même pas des std::string (il y a des C string, donc strcmp, etc... !) et, forcément des TStrings). Si quelqu'un vous montre un diagramme de classe de ROOT fait avec Doxygen, ATTENTION ; une bonne partie de l'iceberg est invisible !
L'équation ROOT = T-tanic (ou T-panic d'ailleurs) n'est, hélas, pas une blague. (Tiens, à propos de blagues sur ROOT, si vous en avez je les collectionne (voir ma section Anti-Depression sous "HEP soft-war ?")).
Pour l'utilisateur c'est aussi très difficile à suivre ; on ne sait jamais trop ou on en est puisque un objet / gService, par un changement instantané de son état, a potentiellement un impact sur tout les objets ! Un symptôme claire de cela est que beaucoup de gens ne préfèrent pas reexécuter deux fois le même script CINT (.C) dans la même session ; pas mal de gens préfèrent relancer ROOT sur le script. Et le système de commande / script étant du C++ (donc plein de pointeurs en direct) cela ne simplifie pas les choses ; pas facile de savoir où en est l'interpréteur. Donc un scénario "de la vie de tout les jours" qui consiste à éditer son script avec un éditeur externe puis reexécuter sous la même session du programme, n'est en général pas fiable. Les gens modifient le script et relance ROOT ! (Au moins dans PAW on pouvait faire cela. Et c'est pourquoi les gens préfèrent maintenant un prompt Python).
On pourrait croire que l'on pourrait régler tout ces problèmes en sautant dans un TGV pour Genève pour discuter de manière raisonnée avec ces gens qui sont sensés être représentatif du meilleur que l'ingénierie logiciel scientifique Européenne peut produire. Mais non, on se heurte a un mure. Et la on tombe sur un problème de fond, qui est en fait très similaire avec le cas Windows. Qu'un logiciel (ou autre chose de fabriqué d'ailleurs) ne soit pas parfait, soit . Ici on pourrait paraphraser le gars de Nazareth qui semble avoir été en contact avec un très grand développeur :
"que celui qui n'a jamais fait de bug jette le premier sur-les-genoux". Le problème n'est donc pas le fait qu'il y ai des choses à revoir ; le problème est que le processus scientifique de critiquer par les paires / collègues ne fonctionne pas avec ROOT. Jamais une "software review" n'a été faite par des paires ! Les garagistes se sont toujours arrangés pour que les pseudo revues soient en fait une sorte d'opinion d'un groupe d'utilisateurs physiciens (évidement très choisi).
Je proposerais même un truc ; je propose, donc publiquement, qu'une revue de ROOT soit faite avec dans le comité : Richard Stallman, Bjarne Stroustrup, Guido van Rosum, un gars de SUN ayant participé au design de java, Josie Wernecke (Open Inventor Architecture Group SGI), le gars qui a fait MySQL. (Je ne veux personne ayant participé a l'écriture de Windows puisque personne n'a jamais pu voir les sources de Windows). Si ces gens arrivent à la conclusion que ROOT est une percée majeure de l'humanité pour le logiciel, d'accord je m'écraserai jusqu'à ma retraite.
Sûre, les physiciens sont écoutés à propos de nouvelles "features", mais pas les gens qui sont payés pour avoir une regard sur le "comment c'est fait" et qu'on appelle en bout de chaîne lorsque l'utilisateur ne s'en sort pas. En gros tout ingénieur logiciel arrivant avec des critiques sur le "comment c'est fait" est vu / détecté comme un "ennemi a la cause" qui doit en gros être éliminé. (Cela ne vous rappelle pas quelque chose ?). (Et la, je pense qu'un psy aurait pas mal à dire).
Ce comportement profondément fraternel, qui est un des fondement économique des ex colonies anglaises, est peut être la règle du jeux dans les compagnies privées ou dans des laboratoires à tendance très nationale mais, est évidement totalement inacceptable venant d'un laboratoire (donc le CERN pour les retardataires) qui a été créé pour fédérer les ressources, et donc l'ingénierie, d'une collection de pays Européen pour faire de la science (ressources que chacun ne pourrait pas se payer seul). Quelque part un comportement "à la Bill Gates" vis a vis des instituts des pays membres du CERN est en gros anti-CERN-constitutionnel. Intéressant n'est ce pas ? Je suis sûre que certains d'entre vous ont en tête cette image d'Epinal du CERN comme une grande fraternité de peuples se groupant autour de l'anneau de collision pour faire de la science et où, en gros, il ne manque plus que le feu de camp au milieu et Hugues Aufray à la guitare (et Hisse et ho).
Quand on non-discute avec le chef garagiste, il est surprenant de voir qu'il a en tête le modèle Boeing alors que, vu qui le paye, il devrait avoir en tête le modèle Airbus ! (Et qui de Airbus ou Boeing va maintenant avoir la plus grosse... capacité de transport ?). (A propos de salaire, je n'ose même pas comparer les salaires CERNois avec le mien. D'ailleurs je ne vais plus au CERN avec mon Scenic ; même propre (il faut bien, c'est la Suisse), cela fait tache sur le parking).
Il est claire que maintenant la situation est bien bloquée. Comme Bill, les garagistes se protègent maintenant derrière le nombre de leurs pauvres utilisateurs physiciens. Et comme étrangement ceux ci s'écrasent (problème de gros sous ?) (ou bien on ne touche pas au CERN ?) et bien rien ne se passe.
En tout cas si certains de mes concitoyens ont votés en Mai pour moins d'Europe dans leur vie sans trop savoir pourquoi ; je peux maintenant leur donner de bonnes raisons.
En fait, après une longue réflexion sur le sujet, je pense maintenant comprendre ce qui ne vas pas, et qu'en fait le problème est plus profond que l'on ne pense. En fait l'activité "développeur / ingénieur de soft pour la physique (ou une science en général)" n'est en gros pas reconnu en temps que tel. Tout est encore du bricolage d'individu et en gros les gens (crème ou pas) finissent par être content de trouver quelque chose qui fonctionne, même à peu près. Le code est soit produit par des physiciens qui devraient normalement concevoir des détecteurs ou buller sur la nature du monde ; ou bien produit au sein de "service informatique" par des ingénieurs n'ayant souvent pas de vue sur la physique. Et il est claire que le courant a du mal à passer. En gros on voit souvent débarquer, donc au service "informatique", des physiciens disant "mon programme Geant4 ne reproduit pas correctement les courbes de physique hadronique de diffusion de pi sur des protons" ; peux tu m'aider a décoincer cela ? Bien sure très cher ; heu, as tu vérifié que ton pi vaut bien 3.14 ? Et croyez moi que les gens qui sont capables de faire face ne courent pas les rues. Dans mon service (donc informatique) on nous appelle gentiment les super-développeurs. (D'ailleurs si un de mes super-chef lit cela, il serait sympa de penser à mon super-salaire (au moins pour avoir la bagnole qu'il faut pour aller en mission au CERN).
En gros, le code n'est toujours pas produit par des personnes qui serait donc des professionnels du soft mais ayant aussi un regard sur la physique. En fait la notion de "service développement logiciel pour la physique" est un chaînon manquant dans toute cette histoire et un jour il faudra bien faire quelque chose (Vois ma section "Software for Physics Department in labs"). Ce manque existe aussi au CERN. En fait, la bas, on ne sait pas où caser les "développeurs pour la physique" ; chez CERN/IT ou bien dans les expériences ? Il est intéressant de noter que le chef garagiste a souvent fait la navette IT / expérience (et donc a fini par déprimer dans... son garage !). (La dépression, c'est terrible, c'est incroyable les bêtises que l'on peut faire dans ces cas la).
En fait CERN/IT (300 personnes !) n'a clairement plus voix au chapitre et est clairement dédié exploitation (donc du GRID maintenant). Au point de vue logiciel pour la physique, les pauvres sont coincés a maintenir CERN/PAW (parce qu'il reste pas mal d'utilisateurs dans le monde), alors que les développements de ROOT se font en fait spirituellement dans un garage. (Donc lorsque l'on dit que ROOT est maintenu / développer par le CERN ; il faut faire attention a ce que l'on dit et surtout a ce que l'on achète ; rien n'est claire sur ce point, surtout si CERN/IT est censé représenter la voix du soft !).
Quand aux expériences (donc pour le LHC ; Alice, Atlas, LHCb, CMS), elles sont
totalement incapables de mettre une ligne de code en commun. (Et c'est dommage parce que ça draine pas mal de crème). Pour les expériences LHC, a été finalement fait un truc appelé "LCG" pour tenter de mettre du soft en commun ; pour l'instant le résultat est en gros une concaténation des bases des softs des quatre expériences. En gros la synergie conceptuelle + mise au propre, qui aurait du être faite pour partager les efforts, n'a pas été faite ; et le CERN porte une grosse part de responsabilité la dedans (rappelez vous de ce que veut dire "E" dans CERN). Et soyez sûre que chacun prend bien soin de ne pas dépendre du soft des autres. En langage physicien on peut résumer cela en disant que LCG est une collaboration "fermionic" alors que cela aurait du être, depuis au moins dix ans, une collaboration "bosonic". (En fait, qu'en on y pense, l'Europe c'est assez bien cela ; une fédération fermionique d'états).
Qui est responsable ? Les garagistes y sont pour beaucoup, ça c'est sûre. Mais en fait tout le monde et personne ! En fait le principal problème est que, historiquement, on a pas comprit que le "software pour la physique" est une activité en soi à mettre en parallèle avec l'électronique, la mécanique, l'exploitation. Et en particulier que ce n'est pas un sous produit de l'exploitation comprise comme "informatique". Dans mes pages je fais l'analogie avec Harry Potter ; écrire l'histoire d'Harry Potter n'est pas le même boulot que d'imprimer les millions de livres pour la planète. Historiquement, lorsque les laboratoires de physiques (par exemple à Orsay) ou bien le CERN ont été créés, les gens on mis les "écrivains" dans le même giron que les "éditeurs". (En fait ils n'avaient même pas conscience qu'il y avait des "écrivains"). Et PAW + ROOT vient de cela.
Qui aurait pu forcer une refonte à temps de ROOT ? Seule une entité, comme une "Software for Physic Division" composée d'écrivains professionnels et avec suffisamment de bouteille pour être écoutée par les expériences, et surtout avec sa voix propre dans les divers conseils du CERN aurait pu faire cela. Manque de chance, cette entité n'existe pas ! (Et après tout, qui peut blâmer les garagistes de profiter de la
situation ? Comme pour Windows, tant qu'il y a des gens à la vue basse pour acheter...)
LCG est peut être un début de cette entité mais cela arrive trop tard pour le LHC (et les garagistes ont tout fait pour cela). En particulier le CERN va rater le premier système de stockage de masse OO open source bien fichu. Tant pis. Mais bon, en fait ce labo est déjà connu pour être passé à côté de pas mal de choses et j'ai l'intime conviction, qu'il aurait pu inventer l'OO et un langage comme java (il y a eu une période où des gens écrivaient des compilateurs au CERN). Bon il y a eu le web, mais j'aimerais bien avoir l'opinion profonde de Tim Berners-Lee sur le CERN. (Tiens, d'ailleurs pourquoi il n'est plus au CERN celui la ?)
Donc le soft du LHC va être une honte technologique. Mais bon, ne dramatisons pas, si tout le hardware est bien fait, et le Higgs est au rendez vous, même un soft bien pourri devrait pouvoir tomber dessus. Mais il serait tout de même quelque part immorale que ce soit un comportement à la Bill Gates et surtout le soft qui va avec qui plot le Higgs.... En tout cas lorsque vous verrez des plots de Higgs partout dans les revues et que vous reconnaîtrez que c'est fait en ROOT (c'est facile a repérer) au moins vous, vous saurez de quoi il en retourne. (En fait le CERN devrait imposer que les plots pour les revues soient au moins fait en GNUplot, ou n'importe quel package de plotting dédié).
Maintenant que l'on est fixé sur le LHC, il faut voir ce que l'on peut faire pour l'après LHC ( Linear Collider, et tout les programmes qui ne sont pas rattachés au CERN). Pour ceux que cela intéresse de voir ce que je propose, voir OpenScientist donc a http://OpenScientist.lal.in2p3.fr . (Ça mûri, ça mûri....ça va bientôt être très très buvable).
(Tiens, faites moi penser un jour de parler des softs de simulation en HEP (Geant4, FLUKA, VMC, etc...). La aussi il y a des pauvres utilisateurs qui s'arrachent les cheveux. Y a pas mal å dire (et encore une fois on tombe sur les mêmes pollueurs)).
Système de stockage OO :
///////////////////////////////////////////////
Oui, donc le CERN va nous rater un système de stockage de masse OO open source bien fichu et donc le problème reste entier (sauf que maintenant j'ai Rio, mais cela ne suffit pas). En gros il me faudrait un package d'IO genre HDF5 (ou Rio) sur lequel on aurait rajouté une couche OO grâce å un système d'introspection C++ (sans methode Draw svp) avec lequel on pourrait déclarer des classes "user" et qui nous produirait les streamers pour la couche de base (par exa HDF5 ?). En plus il faudrait que le streaming soit compatible avec un parallèle fait en java (parce que mes copains du groupe AIDA de SLAC sont en java). Si les streamers pouvaient `être "pure abstract", cela serait génial. Et le tout en open source, tournant donc au moins sur les trois sur-les-genoux du moment (Linux, MacOSX, et le Win-machin de l'autre). (Du transactionnel ne m'intéresse pas et a priori du relationnel non plus).
Si quelqu'un a quelque chose... Sinon tant pis, comme d'habitude je finirai bien par faire le boulot. (La retraite est encore loin).
Voilà, voilà. Bon il faut que je retrouve mes anti-dépresseurs et que je m'y recolle. (En plus, avec tout ça, je viens de rater poubelle la vie sur la 3). (Tiens, en fait ça donne des idées ; on pourrait proposer aux scénaristes des épisodes où l'affreux Frémont commence à installer ROOT sur toute les machines du quartier du panier. Enfin un vrais virus. A creuser...)
Remerciements à mon jeune Padawan pour être tombé sur ce forum. Le peu de fois où il va au CERN seul, je m'inquiète qu'il ne croise à la cantine l'empereur Sith ou Vadehors ; il n'est pas encore prêt... (qui l'est d'ailleurs ?)
(Pour les non HEP : la cantine du CERN est évidement un endroit hautement stratégique sur cette planète ; c'est la que le vrai travail de pub, de racollage et surtout de démolition de tout produit concurent et des bonhommes qui vont avec est fait. ; la, on voit le vrai visage de l'Europe).
URL : http://OpenScientist.lal.in2p3.fr
[^] # Re: ROOT,logiciels d'analyse du CERN : comment finir par dir non à l'Eur
Posté par Barrand Guy . Évalué à 1.
se heurtant a une mûre ou un mur ; cela fait de toute façon de la confiture.
(Et donc pas sure mais sûr et pas claire mais clair. Mais bon, cela fait dix ans que je n'avais pas écrit en Francais ; je me suis deja collé les accents avec mon clavier qwerty. Donc pitié.)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.