! Résumé !!Récapitulation des situations dangereuses discutées plus bas *possibilité d'avoir deux matrices comportant le même numéro sur des télescopes pilotés par deux versions différentes du logiciel d'acquisition. *perte de la table de correspondance entre les canaux des photomultiplicateurs et les barreaux des matrices. *perte des relations entre les différents paramètres d'un RUN. *non enregistrement de nombreux paramètres de configuration et hardware (numéros de cartes électroniques, photomultiplicateurs, etc.) pouvant s'avérer utiles plus tard. *la situation actuelle est propice pour rendre l'utilisation des données impossible après plusieurs années. Par exemple, l'interprétation des informations codées de manière variable selon l'humeur du moment repose sur la mémoire des utilisateurs et cela conduira forcément à des incertitudes sur le sens à donner à ces informations: "on ne sera plus tout à fait sûr que, etc.". !!Besoins et remarques Le point le plus urgent à régler est le regroupement des informations de façon standardisée et fiable pour éviter leur perte et faciliter l'utilisation ultérieure des données. Actuellement, il y a trois personnes capables de traiter les données et chacune a des codes différents. On peut même ajouter un quatrième utilisateur qui a réécrit de nos codes MatLab en LabView. Il y a donc une grande hétérogénéité qui va vite devenir un chaos ingérable si on n'aboutit pas rapidement à la définition d'une procédure claire et documentée pour stocker les données. La situation se complique parce que la quantité de données augmente rapidement. Nous aurons probablement 4 télescopes en service fin 2012. Les applications à d'autres volcans (Etna, Montserrat, Mayon) et à d'autres domaines (archéologie, génie civil, stockage CO2) vont faire augmenter le nombre d'utilisateurs des données et il serait mieux que nos procédures soient définies avant leur arrivée. Dans 90% des cas, le traitement des données est fait pour un RUN particulier. Il n'est pas impossible de faire des traitements avec des données issues de RUNS différents, mais cela reste rare. À partir de ce constat, il y a deux voies possibles: * on conserve les données avec leur structure de fichier et ce sont les fichiers qui sont gérés dans une base de données * on supprime les fichiers et les données individuelles sont toutes versées dans une énorme base. Le choix dépend fortement de la possibilité (avec les moyens informatiques qui sont les nôtres) de retrouver des données dans une base de plusieurs centaines de GO. Il y a un compromis à trouver entre les possibilités offertes par une base générale et l'utilisation assez rare que l'on fera de ses possibilités. Si j'en crois ce lien (http://www.siteduzero.com/tutoriel-3-31600-mysql-et-postgresql-lequel-choisir.html) il est possible de monter à 13000 GO (mais je ne sais pas avec quel hardware). Si c'est possible pour nous, ça devrait aller pour les 10 prochaines années. '''Est-ce qu'une grande table contenant toutes les données peut être partitionnée de sorte à préserver un classement en RUNS permettant un accès aussi rapide que celui permis par le rangement en fichiers (accès qui consiste à aller dans le bon répertoire) ?''' Toujours sur ce lien (http://www.siteduzero.com/tutoriel-3-31600-mysql-et-postgresql-lequel-choisir.html) il est dit que PostGreSQL est rapide pour les gros volumes. Mais, que veut dire rapide ? '''Est-il possible de faire le test suivant ?''' *Mettre les 18 GO de données des expériences de Pont-Péan que Quentin a récupérées sur sa machine dans une seule table et faire des requêtes pour voir le temps que cela prend. *Peut-être faire quand même attention à la façon de procéder en utilisant des types de variables appropriés comme tinyint pour les numéros de matrices et de canaux, etc.. *Faut-il scinder les lignes comme on en a discuté l'autre jour à Rennes, par exemple: ** la ligne initiale ***1307903297 170908 86763271 8 2 4 358 57 180 ** devient: ***1307903297 170908 86763271 8 4 358 ***1307903297 170908 86763271 8 57 180 Un autre point concerne la structure générale de la base: '''faut-il gérer les données "muons" à part des autres données ? L'autre jour on a parlé de "sous-bases", s'agit-il de sous-ensemble de tables au sein d'une base unique ?''' ! Données de détection d'événements Les données principales sont celles provenant des matrices de détection des télescopes à partir desquelles on calcule le flux de muons dans les différentes directions de visée de l'instrument. Les fichiers de données sont produits par le logiciel d'acquisition qui est une version modifiée de celui utilisé pour l'expérience OPERA. !!Principe des mesures: !!Exemple de fichier de données brutes: 1307903297 170908 86763271 8 2 4 358 57 180 1307903297 170908 86763272 11 3 36 163 1 25 2 89 1307903297 170909 91524883 11 2 38 210 57 178 1307903297 170909 91524884 8 2 13 28 50 229 1307903298 170910 12235228 7 2 5 308 56 189 1307903298 170910 12235230 8 3 52 139 9 384 51 9 1307903298 170910 12235230 11 2 29 83 32 175 1307903298 170911 22342338 11 2 20 54 34 633 1307903298 170911 22342339 8 2 22 389 9 358 1307903298 170912 31940656 7 2 14 300 56 121 1307903298 170912 31940659 11 4 20 20 14 14 13 176 32 222 1307903298 170912 31940660 8 3 36 8 6 79 2 62 1307903298 170913 32394718 8 4 63 250 24 28 27 77 32 183 1307903298 170913 32394719 11 3 31 53 16 76 18 159 '''Explication des colonnes:''' * colonne 1: date (temps unix dans cet exemple) à la seconde près. * colonne 2: numéro de la mesure dans le run (défini plus bas). '''Important''': quand plusieurs lignes du fichier ont le même numéro de mesure, c'est parce que les mesures en question correspondent à la même séquence. C'est à dire qu'une matrice a détecté quelque chose et a déclenché l'interrogation des autres matrices qui ont envoyé leurs données. * colonne 3: temps exprimé en dizaines de ns dans la seconde en cours. * colonne 4: numéro de la matrice concernée. Dans l'exemple ci-dessus, on voit que le télescope est équipé des 3 matrices numérotées 7, 8 et 11. * colonne 5: nombre d'événements détectés par la matrice. * paires de colonnes suivantes (ex. 6 et 7): première colonne = numéro de canal du photomultiplicateur, deuxième colonne = intensité du signal détecté. Il y a autant de paires de colonnes que de nombre d'événements indiqué dans la colonne 5. À titre d'exemple, les fichiers correspondant à '''3 semaines de mesures''' de tests faites dans le jardin à Pont-Péan (15 juin au 6 juillet 2011) '''représentent 18 GO'''. La taille des fichiers peut varier assez fortement selon la configuration adoptée pour l'électronique d'acquisition. Notamment, la programmation du FPGA peut constituer un filtre très sélectif éliminant beaucoup d'événements à la source. !!Organisation des mesures sous forme de RUNS: Fondamentalement, l'acquisition des données est faites sous de formes de RUNS pendant lesquels les paramètres de mesure sont fixes. Ces paramètres sont très nombreux et constituent un des problèmes actuels dans l'exploitation des données car: *De nombreux paramètres ne sont tout simplement pas enregistrés, ou le sont de manière sporadique de manière libre quand l'opérateur pense que cela peut être utile. Plusieurs de ces paramètres pourraient probablement facilement être enregistrés car ils concernent les réglages donnés au logiciel d'acquisition (qui doit bien les avoir quelque part). *Les paramètres enregistrés sont dispersés d'une manière extrêmement '''dangereuse''': codage dans le nom des fichiers ( ex.Run8_AB1_thr200_maj2-4.dat), rangement dans des répertoires dont le nom comporte des informations (mais un nom se change facilement), écriture dans le présent WiKi, etc. *'''Exemple d'information particulièrement critique:''' la table de correspondance entre les canaux des photomultiplicateurs et les barres X/Y des matrices. Cette correspondance n'est pas toujours la même et dépend du brassage des fibres optiques connectant les barres de scintillateur aux 64 pixels des photomultiplicateurs. La perte des tables de correspondance signifie l'impossibilité d'utiliser les données. '''Actuellement, il n'y aucune procédure d'enregistrement de ces information essentielles''' (codage dans une fonction MatLab pour moi, autrement à Lyon). Il est important de noter qu'un RUN n'est pas forcément une séquence chronologique continue: il est possible d'arrêter un RUN pour modifier les paramètres d'acquisition pour procéder à un test, puis reprendre le RUN plus tard pour le compléter. !Les autres données Il y a potentiellement de nombreuses autres données complémentaires des données d'événements décrites ci-dessus. On peut distinguer: *Les mesures auxiliaires liées au fonctionnement du télescope: tensions, températures, humidité, consommation électrique, inclinaison, heure GPS, etc. Ces mesures peuvent être utilisées pour suivre le bon fonctionnement des instruments. *Les mesures environnementales "proches": température, humidité, luminosité, pression atmosphérique extérieures. *Les mesures environnementales "régionales": données météo, modèles d'atmosphère, flux neutroniques, etc. *Les données complémentaires: modèles topo (qui peut changer au cours du temps pour l'Etna, Montserrat), photos diverses, cartes, autres mesures géophysiques (gravimétrie, tomographie électrique,...), monitoring dans le cas de suivi de phénomènes variables dans le temps. !Que fait-on des données ? !!Calcul d'une radiographie en densité: La séquence de traitement consiste à: *lire les fichiers d'un RUN pour en extraire les événements jugés valides (ce point est détaillé plus bas). Cette opération est actuellement réalisée dans MatLab et consiste à appliquer une suite de tests (nombre de canaux touchés, intensité du signal, etc.) permettant de filtrer les événements. Ces tests sont très sélectifs et peuvent considérablement réduire le nombre de données conservées pour les traitements suivants. *une fois les événements sélectionnés, ils sont regroupés pour chaque direction de visée. Les directions de visée sont déterminées par la disposition des matrices du télescope. Par exemple, un télescope équipé de matrices 16x16 pixels a 31 directions horizontales de visée et 31 verticales, ce qui donne 31X31 = 961 directions. À l'issue de cette étape du traitement, on a une matrice contenant le nombre N d'événements détectés pour chacune des 961 directions. On voit donc que l'information a été considérablement compressée par rapport aux GO de données initiales. *l'étape suivante consiste à transformer le nombre d'événements N pour chaque direction en un flux de particules qui sera comparables aux modélisations physiques. Il y a plusieurs sous-étapes: **conversion en taux d'événements: on divise le nombre N par la durée de la prise de mesure. On récupère des données exprimées en nombre d'événements par seconde ou par jour. Dans le cas d'u RUN fait en plusieurs parties, il faut bien additionner les durées de chaque partie. **conversion du taux J en flux: on divise le taux par l'acceptance T du télescope pour récupérer un flux F exprimé en nombre d'événements par seconde par centimètre carré par stéradian. Ce flux est directement comparable aux résultats de modélisation. **l'acceptance T du télescope peut être obtenue via un calcul théorique utilisant uniquement les données géométriques du télescope (distance entre les matrices, taille des pixels, etc.). T peut aussi être obtenue à partir de mesures de calibration faites lors de RUN dédiés. Dans ce cas, T est un modèle issu d'une inversion Bayésienne. *production d'une radiographie en densité moyenne. Cette étape nécessite l'utilisation des informations de positionnement du télescope pour placer les lignes de visées dans un repère géographique (jusqu'à présent il suffisait de connaître les lignes de visée dans le repère propre du télescope). Les sous-étapes sont: **modélisation de la géométrie réelle de l'expérience en utilisant un modèle topographique de la région et en y plaçant le télescope. Cette étape permet de calculer l'épaisseur de roche traversée pour chaque ligne de visée. **calcul du flux théorique en utilisant la géométrie de l'étape précédente et un modèle de flux de muons à ciel ouvert. Pour chaque direction, on cherche la densité nécessaire pour que le flux théorique soit égal au flux mesuré.