dataesr/scientific-paragraphs-categorization huggingface dataset:
Intégration des données Pléiades et des produits à valeur ajoutée Plusieurs produits avec différents niveau de valeur ajoutée sont intégrés au coeur du dispositif Qêhnelö TM : • Les données Pléiades étalonnées et orthorectifiées ; • Une mosaique d'orthoimage en couleurs naturelles à des fins de visulaisation ; • Le modèle numérique de surface ; • Les produits à valeur ajoutée créés spécifiquement pour les besoins des utilisateurs à l'aide du logiciel ERDAS Imagine 2014 (typologie des sols, des mangroves, de la végétation). Les données raster ont été insérées en base de données PostGIS 2. 1 et interfacées avec un serveur de données géographiques GeoServer afin de permettre leur exploitation par différents protocoles web d'analyse selon les manipulations effectuées au sein des différents modules de la plateforme : • WCS pour les modèles d'analyse et de traitement des images • WPS pour l'exploitation des modèles de production sédimentaire, de risque de submersion, d'analyse topographique, ou d'identification des changements, etc.
Visualisation et analyse des données Le module QeSIG permet de croiser, mettre en forme et générer un projet à partir de l'ensemble des données géographiques de la plateforme. Ce module se connecte à distance aux différentes bases de données qui respectent les normes OGC. L'ensemble des flux (WMS, WFS, WMTS, WMS-T) sont optimisés permettant une navigation rapide malgré l'importance des masses de données qui circulent. Le module Qcarto permet de faire de la cartographie rapide à partir d'un projet précédemment généré avec le module Q-eSIG. En quelques clics la carte est éditée, avec l'habillage, l'échelle, la légende et les sources de données puis envoyée directement à l'impression. C'est en couplant ces deux modules avec les données issues des satellites Pléiades (image, modèle numérique de surface, végétation littorale) en entrées du modèle d'estimation des zones soumises à l'aléa de submersion par tsunami ou vague de tempête que les équipes du Centre de Secours et d'Incendie de Yaté ont créé des cartes afin que les élus prennent les bonnes décisions lors des conseils municipaux (figure  13 ).
Exploitation opérationnelle L'exploitation opérationnelle des données satellitaires à très haute résolution en synergie avec des bases de données distribuées au sein du dispositif Qëhnelö TM a été démontrée lors de l'événement pluvieux des 2 et 3 juillet 2013. Lors de cet événement, un maximum de 714 mm de précipitations en 24 h ont été relevées sur la commune de Yaté, détrônant le précédent record datant de 1975 de précipitations enregistrées en 24 h (Météo Nouvelle-Calédonie, 2013). Ces précipitations ont entrainé un apport important de sédiments dans les baies du littoral et la mort de nombreux organismes marins  (OEIL, 2013). L'exploitation synergique des données satellitaires à très haute résolution au sein de Qëhnelö TM a fourni aux décideurs locaux un ensemble complet d'information afin de répondre à leurs questionnements : quel est l'étendue spatiale de l'impact dans les baies de l'apport d'eau turbide ? D'où proviennent les sédiments charriés par les rivières lors de cet événement ? Une image Worldview-2, acquise le 5 juillet 2013, a été exploitée afin d'estimer la concentration en sédiments des baies du littoral de Yaté selon la méthode développée par  (Ouillon S.
Remerciements Cet article a été réalisé dans le cadre  du programme  d' accompagnement ORFEO -Recette Thématique utilisateurs des données Pléiades. Nous tenons ainsi à remercier  Claire Tinel ,  Delphine Fontanaz ,  Benoît Boissin  ainsi que toute l' équipe du  projet  ORFEO du CNES. Nous remercions également Airbus  DS/Spot Image. Nous remercions également INTERGRAPH New Zeeland pour nous avoir offert la possibilité d'évaluer la solution eATE d'ERDAS 2014 avec les données Pléiades tristéréoscopiques. Enfin, nous remercions  Jean-Daniel Cieslak et Jean-Michel N 'Guyen de VALE NC  de nous avoir permis d'utiliser leur modèle numérique de terrain à des fins de comparaison avec le modèle numérique de surface obtenu à l'aide des données Pléiades.
4. Mise à disposition des utilisateurs finaux 4. 1. Le dispositif de Geospatial Cloud Computing Qëhnelö TM s'appuient sur des bases de données PostGis 2. 1 permettant ainsi d'exploiter des séries temporelles raster. Le dispositif de Geospatial Cloud Computing comprend un ensemble de services de types WCS et WPS. Le WCS (Web Coverage Service) fournit un accès aux Qëhnelö™ est le système d'aide à la décision en aménagement et gestion de l'environnement sur le WEB qui à été développé pour répondre aux attentes des décideurs et des populations océanniennes. Avec un simple navigateur Internet, Qëhnelö™ donne l'accès à l'ensemble des connaissances relatives à un territoire. Cette technologie, "le Geospatial Cloud le Cloud. Son architecture modulaire permet de Computing", à vocation géographique, est inscrite dans données de type raster (imagerie, classification) selon le format standard définit par l'OGC (Open Geospatial Consortium) afin que celles-ci puissent être utilisables par des modèles ou des algorithmes de calcul (OGC, 2012).
Le WPS (Web Processing Service) permet d'offrir des fonctionnalités de traitement des données spatiales selon le standard international de l'OGC (OGC s'adapter de manière précise à de multiples demandes. Une plateforme Qëhnelö™ est un ensemble d'applications (ou logiciels/modules) auquel les utilisateurs accèdent de manière sécurisée par le WEB. Ces applications utilisent des ressources en ligne (bases de données géographiques, bibliothèques, annuaires, modèles mathématiques) et offrent des services à haute valeur ajoutée (cartographie rapide, analyse du territoire, suivi environnemental, prévision, études d'impact) (Lille D. , 2007). La technologie Qëhnelö™ est basée sur une architecture client-serveurs et utilise les technologies les plus récentes afin de fournir un service fluide tout en réalisant des taches complexes.
Nous visons, dans cet article, à résoudre les problèmes de performances du GBIF. Dans cette perspective, nous proposons une approche d'optimisation de requête d'analyse de données de biodiversité qui s'adapte dynamiquement au contexte des environnements répartis à large échelle pour garantir la disponibilité des données. L'implémentation de notre solution et les résultats des expériences sont satisfaisants pour la garantie de performance et du passage à l'échelle. ABSTRACT. The amount of data produced by many areas is constantly increasing and makes treatment more difficult to manage. One of those areas is the biodiversity field, which the GBIF (Global Biodiversity Information Facility) aims to federate and share data produced by many worldwide suppliers. Actually, with a growing number of users characterized by a versatile behavior and a high frequency and randomly data access, existing solutions are not well suited to face such challenge.
Introduction 1. Contexte et problématique Le GBIF (Global Biodiversity Information Facility) est une initiative visant à fédérer et partager les données de biodiversité produites par de nombreux fournisseurs à l'échelle mondiale. Les données collectées par le GBIF décrivent principalement des occurrences de specimens vivants. Les données sont structurées : une occurrence est un nuplet dont les attributs décrivent la classification taxinomique du specimen, son lieu et sa date d'observation, l'observateur, le fournisseur, etc. En termes de taille, la base de données contient plus de 500 millions d'occurrences issues de plus de 14000 collections et 650 fournisseurs  [19]. Ces données servent de matière première à une large communauté des chercheurs qui étudient plusieurs aspects de la biodiversité comme, par exemple, l'impact du réchauffement climatique sur certaines espèces.
Motivations Le phénomène du « Big Data » est de plus en plus perçu comme l'un des grands défis informatique de la décennie en cours. De nombreux domaines font face à un 'déluge' de données sans précédent. La quantité des données produites augmente constamment et rend leur traitement de plus en plus difficile à gérer avec les outils actuels. Par exemple, Facebook enregistre plus de 800 millions d'utilisateurs actifs en moyenne par jour  [17]  et ajoute quotidiennement plus de 500 TB de données  [22]. La base de données astrométrique européenne est complétée avec plus de 100 Go de données de nouvelles observations par jour  [11]. En outre, selon une étude de Industrial Development Corporation (IDC) et EMC Corporation  [24] , la quantité de données générées en 2020 serait 44 fois supérieures par rapport à 2009 avec un taux de 35 ZB par an.
Il peut utiliser le système de fichiers HDFS pour le stockage persistent des données. L'abstraction que Spark utilise pour représenter les données est une collection générique appelée RDD (pour Resilient Distributed Dataset  [26] ). Cette abstraction permet de manipuler des données distribuées sur plusieurs machines aussi simplement que des données centralisées. Spark s'appuie sur le paradigme MapReduce pour proposer des opérations algébriques de manipulation de données (sélection, projection, regroupement, etc. ) qui transforment des RDD en d'autres RDD. Une RDD peut ainsi être définie comme un enchaînement d'opérations algébriques et peut être recalculée si nécessaire. Cela permet à Spark de garder les données en mémoire en fonction des requêtes et de garantir leur recouvrement en cas de panne.
Environnement et outils Nous avons implémenté notre solution sur une infrastructure composée de onze machines. Chaque machine dispose des caractéristiques suivantes : 22 CPU de 2. 394 GHz de fréquence, une mémoire de 62 Go avec comme système d'exploitation Debian 3. 2. 54-2 x 64. Une première machine est utilisée pour représenter le portail GBIF et dispose de toutes les données dans une base locale. Une deuxième machine est utilisée pour générer des requêtes et simuler des utilisateurs qui envoient des requêtes d'analyse au système décentralisé. Une troisième machine contrôle les accès à la base de données du GBIF. Les huit machines restantes sont utilisées pour instancier chacune un site du système décentralisé. Chaque site dispose d'une base de données locale en plus des fonctions pour évaluer les OL et les OG.
Autant d'éléments qui interagissent fortement avec la scénographie proprement verbale »  (Maingueneau, 2013 : 80 [19] ). La toile rassemble d'une part, des ressources proprement verbales, et de l'autre, des ressources multimodales (image fixe, mouvement, son) ainsi que les opérations hypertextuelles qui impliquent une technique. Pour sa part,  Barats (2013 [3] ), dans l'introduction au Manuel d'analyse du web avertit que l'hétérogénéité devient aujourd'hui presque une condition intrinsèque quand on veut travailler sur des données provenant du web, ce qui dévoile « la nécessité de construire des méthodes adaptées aux objets et phénomènes étudiés et aux particularités du web »  (Barats, 2013 : 6 [3] ). Pour sa part, Garric et Longhi (2012  [14] ), dans l'introduction du numéro de la revue Langages intitulé « L'analyse de corpus face à l'hétérogénéité des données : d'une difficulté méthodologique à une nécessité épistémologique » travaillent sur la base de données émanant de différents matériaux sémiotiques et proposent de définir le corpus comme une « construction, potentiellement hétérogène et donc évolutive » (Garric et Longhi, 2012 : 6  [14] ).
Les simulations gyrocinétiques nécessitent d'importants moyens de calcul. Jusqu'à présent, le code semi-Lagrangien GYSELA réalise des simulations sur quelques dizaines de milliers de coeurs de calcul (65k coeurs). Mais pour comprendre plus finement la nature de la turbulence des plasmas, nous devons raffiner la résolution de nos maillages, ce qui fera de GYSELA un candidat sérieux pour exploiter la puissance des futures machines de type Exascale. Le fait d'avoir moins de mémoire par coeur est une des difficultés majeures des machines envisagées pour l'Exascale. Cet article porte sur la réduction du pic mémoire. Il présente aussi une approche pour comprendre le comportement mémoire d'une application utilisant de très grands maillages. Ceci nous permet d'extrapoler dès maintenant le comportement de GYSELA sur des configurations de type Exascale.
ABSTRACT. Gyrokinetic simulations lead to huge computational needs. Up to now, the Semi-Lagrangian code GYSELA performs large simulations using up to 65k cores. To understand more accurately the nature of plasma turbulence, finer resolutions are necessary which make GYSELA a good candidate to exploit the computational power of future Extreme scale machines. Among the Exascale challenges, the less memory per core is one of the most critical issues. This paper deals with memory management in order to reduce the memory peak and presents a general method to understand the memory behavior of an application when dealing with very large meshes. This enables us to extrapolate the behavior of GYSELA for expected capabilities of Extreme scale machines.
Le code GYSELA exploite déjà efficacement les capacités des super-calculateurs  (Latu et al. , 2011). Dans cet article, nous nous intéressons en particulier à sa consommation mémoire. C'est un point crucial pour la simulation de cas physiques plus conséquents avec une quantité de mémoire toujours limitée par coeur. Un module spécifique à l'application GYSELA a été développé pour permettre la génération d'une trace mémoire. Néanmoins, notre but final (pas encore atteint) est de définir une méthodologie et une bibliothèque portable pour aider le développeur à optimiser l'utilisation de la mémoire pour un certain type d'applications scientifiques parallèles. Le but du travail présenté ici est de décomposer et de réduire l'empreinte mémoire de GYSELA pour améliorer son passage à l'échelle du point de vue mémoire.
Nous présentons un outil qui permet de visualiser les allocations/désallocations mémoire de GYSELA dans un mode hors-ligne. Un autre outil nous permet de prédire le pic mémoire en fonction de certains paramètres d'entrée. Cela est utile pour vérifier si les besoins mémoire futurs des simulations pourront tenir dans l'espace mémoire d'une machine donnée. L'amélioration de l'extensibilité mémoire de GYSELA nécessite l'introduction d'allocations dynamiques. Une étude de leur impact sur le temps de calcul est menée. Le travail présenté par cet article fait suite à  (Rozar et al. , 2014 ; 2015). Cet article est organisé selon le plan suivant. La section 2 décrit le domaine d'application de GYSELA et donne une description succincte du code. La section 3 présente l'empreinte mémoire de GYSELA. La section 4 présente le module implémenté pour générer le fichier de traces des allocations/désallocations.
Dans sa formulation générale, la résolution de l'équation de Vlasov est coûteuse en termes de temps de calcul pour des domaines de calcul de taille réaliste. Pour que les simulations soient réalisables dans un temps raisonnable, des modèles qui réduisent la taille du problème ont été développés. Le travail effectué dans cet article concerne le code de simulation GYSELA qui résout le couplage non linéaire des équations Vlasov et Maxwell dans la modélisation gyrocinétique. L'hypothèse gyrocinétique permet, notamment à l'aide d'un changement de variables lentes/rapides, de supprimer une des dimensions de vitesse et de réduire ainsi d'une dimension le problème. A l'échelle de temps simulé par GYSELA, le champ magnétique B est considéré comme statique, ce qui permet de n'avoir à calculer uniquement que le champ électrique E à chaque itération.
Outils de modélisation de la consommation mémoire Pour suivre la consommation mémoire de GYSELA et pour mesurer la réduction de l'empreinte mémoire, des outils complémentaires ont été développés : un module FORTRAN d'instrumentation pour générer un fichier de traces des allocations/désallocations et un script PYTHON de visualisation & prédiction qui exploite ce fichier de traces. Les informations collectées durant l'exécution de GYSELA grâce au module d'instrumentation est un composant clé de notre analyse mémoire. Une vue d'ensemble des outils d'analyse de performances et de profilage mémoire est donnée en section 4. 1. Les sections 4. 2-4. 4 détaillent en partie l'implémentation des outils que nous utilisons pour notre analyse. La dernière section 4. 5 discute de la généralisation et des limitations de notre approche concernant la possibilité de prédire la consommation mémoire d'une application autre que GYSELA.
Travaux relatifs Dans la communauté des chercheurs travaillant sur les outils d'analyse de performances d'applications parallèles, différentes approches existent. Souvent ces approches s'appuient sur des fichiers de traces. Un fichier de traces collecte des informations durant l'exécution de l'application concernant un ou plusieurs de ses aspects : le temps d'exécution, le nombre de messages MPI envoyés, le temps inoccupé (idle), la consommation mémoire, et plus encore. Pour obtenir ces informations, l'application doit être instrumentée. L'instrumentation peut être faite à 4 niveaux : dans le code source, à la compilation, à l'édition de lien ou durant l'exécution (just in time). Différents outils génériques sont disponibles pour analyser les aspects performance d'un programme. L'outil de performance SCALASCA  (Geimer et al.
, 2010)  est capable d'instrumenter le code source à la compilation. Cette approche a l'avantage de couvrir toutes les parties du code et elle permet la personnalisation des informations à récupérer. Cette approche systématique donne une trace complète mais la récupération d'informations dans toutes les sous-routines du code peut induire un surcoût en exécution important. L'ensemble d'outils EZTRACE  (Aulagnon et al. , 2013)  offre la possibilité d'étudier, entre autres choses, la consommation mémoire en interceptant les appels à l'ensemble des fonctions C qui gère les allocations mémoires (p. ex. malloc(), free()). Cet outil peut rapidement instrumenter une application grâce à un lien avec des biblio-Passage à l'Échelle Mémoire thèques de tierce-partie lors de l'édition de lien. Contrairement à notre approche, celleci ne nécessite pas une instrumentation du code source.
Après compilation, il est difficile de faire le rapprochement entre les valeurs que contient la pile d'exécution lors d'une allocation et les variables du code source responsables de cette allocation. C'est un aspect qui est essentiel pour notre outil de prédiction de la consommation mémoire. Le but de l'outil de prédiction développé dans GYSELA est de prédire la consommation mémoire du programme si la valeur de certains paramètres change (p. ex. les dimensions du maillage). La prédiction de la consommation mémoire est inaccessible si on ne peut pas faire le lien entre la taille des structures allouées et le nom des variables qui donnent les dimensions des allocations. Afin de récupérer les informations nécessaires à la prédiction, notre approche se base sur une instrumentation au niveau du code source qui est à la charge du développeur.
L'outil que nous avons développé nous permet de mesurer les performances de GYSELA, du point de vue mémoire. Un outil de visualisation a été développé pour permettre l'analyse de ce fichier de traces. Il offre une vision globale de la consommation mémoire et une vision précise autour du pic mémoire pour aider le développeur à réduire l'empreinte mémoire. La sortie sur terminal du script de post-traitement donne des informations précises au sujet des tableaux alloués au moment du pic mémoire. Etant donné un fichier de traces, il est possible de prédire exactement la consommation mémoire en fonction des paramètres d'entrée. Ce nouvel outil nous permet d'investiguer l'extensibilité mémoire. Nous ne connaissons pas d'outil équivalent pour modéliser le comportement mémoire.
Format du fichier de traces GYSELA fait intervenir différents types de structures de données et afin de gérer leurs allocations/désallocations, un module FORTRAN dédié a été développé pour les enregistrer dans un fichier : la trace mémoire dynamique. Une trace est générée par processus MPI. Le processus 0 étant généralement le plus gourmand, notre analyse se concentre généralement sur sa trace. Le fichier de trace mémoire obtenu grâce au module d'instrumentation est analysé de façon post-mortem. Le module d'instrumentation propose dans son interface les fonctions take() et drop(), qui enveloppe les appels à allocate() et deallocate(). Les sous-routines take() et drop() réalisent respectivement l'allocation et la désallocation d'un tableau manipulé et elles enregistrent cette action dans le fichier de traces.
Soit la valeur de la variable est fixée ou soit une expression arithmétique dépendant d'autres variables est renseignée. Ces actions sont réalisées respectivement par les sous-routines write_param() et write_expr(). L'écriture des expressions permet de restituer les liens qui existent entre les différents paramètres. Ils sont essentiels pour que la prédiction soit correcte (cf. section 4. 4). L'extrait de code suivant est un exemple de l'enregistrement des paramètres a0, a1, b0, b1 : call write_param('a0', 1); call write_param('a1', 10) call write_param('b0', 1); call write_expr('b1', '2 * (a1-a0+1)') Le module d'instrumentation se limite actuellement aux tableaux qui contiennent des types de base de FORTRAN : entier, float et complexe. Une des extensions possible du module serait de pouvoir gérer des tableaux de structures.
Visualisation de la consommation mémoire Afin d'analyser finement la consommation mémoire, notre outil permet d'identifier les parties du code où l'usage de la mémoire atteint son pic. Le fichier de traces peut être volumineux, plusieurs Méga octets. Un script PYTHON a été développé pour visualiser ces traces. Cet outil aide le développeur à comprendre le coût mémoire des algorithmes qu'il manipule et lui donne des indices sur comment et où il peut appliquer des modifications pour diminuer l'empreinte mémoire. Ces informations sont restituées par deux types de graphiques. La figure 3 trace la consommation de mémoire dynamique en Go en fonction du temps. L'axe des abscisses représente les entrées/sorties chronologiques des sous-routines instrumentées. L'axe des ordonnées donne la consommation en Go.
La figure 4 montre dans quelles sous-routines les tableaux sont alloués. L'axe des abscisses reste identique au graphique précédent et l'axe des ordonnées montre les noms des tableaux. L'allocation d'un tableau correspond à un rectangle en gris clair ou en gris foncé dans sa ligne correspondante. La largeur des rectangles dépend de la durée de l'allocation. Sur la figure  3 , on peut localiser dans quelle sous-routine le pic mémoire est atteint. Sur la figure  4 , on peut ensuite identifier les tableaux qui sont effectivement alloués quand le pic mémoire est atteint. Grâce à ces informations, nous savons exactement où modifier le code pour réduire le pic mémoire.
Prédiction du pic mémoire Pour anticiper nos besoins mémoire avant de lancer une simulation donnée, il est utile de prédire la consommation mémoire pour un jeu de paramètres d'entrée. Grâce aux expressions des tailles de tableau et la valeur ou l'expression des paramètres numériques contenue dans le fichier trace, nous pouvons modéliser le comportement mémoire hors ligne. L'idée ici est de reproduire les allocations avec n'importe quel ensemble de paramètres d'entrée. Il est possible qu'une valeur d'un paramètre ne puisse pas être exprimée en une ligne d'expression arithmétique (p. ex. une boucle d'optimisation multicritère pour déterminer cette valeur). Pour gérer ce cas, la partie de code FORTRAN qui retourne la valeur dans GYSELA est appelée depuis le script PYTHON. Cela est possible grâce à une compilation du code FORTRAN avec f2py  (Peterson, 2009).