Compte-rendu de la 5ième réunion Argo France sur le «Contrôle qualité en temps différé des données Argo»

Transcription

1 Projet CREST Argo Compte-rendu de la 5ième réunion Argo France sur le «Contrôle qualité en temps différé des données Argo» V. Thierry Ifremer Centre de Brest mai 2009 Rapport interne LPO n A l heure actuelle, le réseau Argo est devenu une des plus importante source de données en assurant une couverture globale aussi bien spatialement que temporellement. Un nombre croissant d études utilisent les données Argo et des résultats remarquables ont été trouvés (cf. Dans la grande majorité des cas, les données sont bonnes et les capteurs marchent bien. Depuis le début du projet Argo, les centres de données ont également fourni un effort considérable pour mettre en place la collecte, le contrôle et la distribution des données en temps réel. Le système est de plus en plus complexe vu le nombre croissant de données à distribuer et la diversité de ces données, la complexité des mesures, les différents systèmes de transmission et le nombre de plateformes différentes qui sont actuellement en opération. Cette complexité est à l origine des problèmes plus ou moins graves découverts récemment et qui peuvent malheureusement jeter le discrédit sur ces données d une valeur inestimable. Les objectifs de la réunion étaient : d acquérir une bonne connaissance de la donnée Argo et de ses limitations pour une utilisation optimale d avoir un échange et un transfert d information sur la donnée Argo entre utilisateurs, centre de données Coriolis, R&D Coriolis et projet Argo et de discuter des problèmes connus, des difficultés rencontrées, des améliorations prévues (aussi bien du côté du centre de données que d un point de vue technologique), de l organisation du QC au niveau de Coriolis, etc Les discussions se sont donc focalisées sur les «problèmes» liées aux données Argo. Ces problèmes concernent un faible pourcentage des données. Il est néanmoins nécessaire de les traiter correctement pour ne pas avoir un jeu de données Argo contaminé par des mauvaises données. Les présentations et ce compte-rendu sont disponibles sur le site web suivant : 1 Résumé, commentaires, questions soulevées et suggestions Les données Argo ne sont pas calibrées contrairement aux données hydrographiques. Les données temps réels ne subissent que des contrôles automatiques pour une attribution de flags de qualité et les contrôles temps différé sont basés sur des méthodes statistiques, sans récupération des flotteurs. Ainsi, pour avoir des données de qualité, qui satisfont nos besoins (recherche, changement climatique, opérationnel), il faut y consacrer le temps nécessaire et les traiter avec la plus grande rigueur. Les données «mauvaises» peuvent avoir plusieurs origines qu il convient d identifier précisément pour apporter la correction adéquate. Par exemple, un problème sur le capteur de pression peut se traduire par une dérive de la salinité. Les problèmes possibles sont les suivants : Problèmes liés aux capteurs (exemple : micro-fuite dans le capteur de pression Druck, dérive des capteurs de conductivités)

2 Problèmes de programmation (exemple : mauvaise programmation des flotteurs SOLO de WHOI) Problèmes liés à la conception du flotteur (exemple : la collerette anti-pillonnnement des PROVOR FSI induisait un biais de en salinité) Problèmes de transmission Problèmes de décodage et de gestion des données (exemple : erreur de modulo pour des flotteurs SOLO, utilisation d un mauvais décodeur induisant une perte de données ou le décodage de données incorrectes) En conclusion, le contrôle qualité en temps différé d un flotteur Argo demande du temps et ne peutêtre effectué que part un expert connaissant à la fois le fonctionnement des capteurs et des flotteurs, les problèmes connus, les outils de contrôle, la dynamique de la région où dérive le flotteur. Ces informations doivent être conservées et consignées (fichier de méta-données par exemple) car dans 5 ans on ne sera plus capable de retrouver les informations indispensables. Les données doivent être regardées en détail car les contrôles automatiques ne suffisent pas. Le processus de QC est un processus en constante évolution (les plateformes évoluent, les méthodes sont améliorées, des problèmes sont découverts, la connaissance s affine) et certains flotteurs doivent être re-contrôlées (flotteurs Gyroscopes par exemple). Quelque soit le problème, il est important de le détecter le plus rapidement possible, d en avertir les centres de données et les utilisateurs et de le corriger le plus rapidement possible. C est de la responsabilité des PIs de surveiller leurs données, mais aussi du centre de données et de la cellule R&D Coriolis, des groupes techniques mais également des scientifiques qui doivent avoir un regard critique sur les données qu ils utilisent. La qualité des données Argo est l affaire de tous. Il faut être réactif lorsque des problèmes apparaissent. Recommandations aux utilisateurs Argo et aux Pis des flotteurs - quand une anomalie est détectée, quelle qu elle soit, il est important de faire remonter l information : soit au niveau de Coriolis et de la cellule R&D Coriolis (codac@ifremer.fr, deboyer@ifremer.fr), soit au niveau de Argo France (vthierry@ifremer.fr) soit au niveau Argo international (support@ucsd.edu). - les PIs doivent remplir le plus correctement possible les feuilles de mise à l eau es flotteurs et contrôler les données enregistrées dans le fichier de méta données. Si elles ne sont pas correctes, il faut en informer Coriolis au plus vite. - les PIs sont encouragés à fournir des éléments sur le fonctionnement des flotteurs dont ils ont la charge : combien de flotteurs ont une dérive en salinité? quelle est l amplitude te la direction des dérives observées? Recommandations pour le Argo Data Management - pour analyser les trajectoires des flotteurs, il est recommandé de garder les positions ARGOS transmises même si le cycle est manquant - revoir les méta-données - besoin de vérifier les formats et les données «adjusted in real time» et «delayed mode» - problème d incohérence entre date et numéro de cyle pour certains flotteurs - problème de gestion de la greylist. Elle n est pas rétroactive donc les données d un flotteur inscrit dans la greylist ne sont pas nécessairement avec un QC à 3. Recommandations pour le centre de données Coriolis et la R&D Coriolis - centraliser l information sur les problèmes connus, les données aberrantes, les flotteurs douteux, etc de manière à éviter que plusieurs utilisateurs perdent du temps sur les mêmes problèmes connus. - assurer plus de visibilité et d informations pour les produits et jeux de données mis à disposition par Coriolis - assurer le suivi des types de flotteurs et de leur fonctionnement (au moins pour les PROVOR) - revoir procédure d attribution des flags temps réels pour détecter des attributions systématiques et infondées de flags à 3 ou 4

3 - informer les Pis lorsqu un flotteur est mis en alerte par une des méthodes de détection d erreur (analyse objective, comparaison à l altimétrie) Recommandations pour Argo international - s assurer que Sea-Bird ne s engage pas dans une modification des capteurs sans en informer la communauté Argo. - favoriser une «technodiversité» des capteurs et des flotteurs - inciter les constructeurs à fournir des descriptifs détaillés sur le fonctionnement et la programmation des flotteurs. Si cette information n est pas disponible et archivée, l information sera perdue lorsque les personnes qui ont codées les instruments ne seront plus dans le projet Questions soulevées et discutées - Qui se charge des flotteurs «orphelins» ou des flotteurs qu il faut re-contrôler alors que le PI n est plus disponible? - Est-il envisageable de récupérer une partie des flotteurs pour évaluer les dérives des capteurs et la précision des mesures? - Pourrait-on avoir un document décrivant le fonctionnement de chaque flotteur? Il faudrait définir les informations dont on a besoin : capteurs, mesures transmises, traitement des données de surface, pression de surface, etc - Quel est le statut exact des flotteurs SOLO WHOI? 2 Problèmes connus et fonctionnement des plateformes Les présentations et discussion ont abordé les problèmes connus sur les données Argo. Ces discussions ont permis également de parler du fonctionnement des flotteurs. Les points détaillés ci-dessous ont été détaillés dans la présentation de V. Thierry et abordés au cours des autres présentations de la réunion dont le détail n est pas repris ici. 2.1 Température Le capteur de température est redoutablement stable (cf. présentation Marc Le Menn) et jusqu à présent aucun problème n a été détecté sur la température. Une comparaison de la température avec des données voisines sur des niveaux isobares peut révéler un problème de pression. Une dérive de la salinité détectée sur des isothermes peut cacher une dérive de la température. Il faut rester vigilant. 2.2 Pression Les différents capteurs de pression et leurs comportements typiques sont passés en revue. La mesure de la pression de surface est un moyen de détecter des anomalies du capteur de pression. Cette mesure est effectuée de manière différente suivant les types de plateformes et même suivant les versions de flotteurs. Il faut connaître la plateforme et le type de flotteur utilisé pour exploiter correctement l information de pression de surface. 2.3 Inertie thermique Le problème d inertie thermique se manifeste dans les fortes thermoclines et se manifestent par des anomalies peu salées. Une publication sur le sujet existe (Johnson et al, JAOT 2007) ainsi qu un programme matlab. Une étude complémentaire est toutefois nécessaire pour une application sur les PROVORS pour déterminer les paramètres à utiliser et la vitesse de remontée du flotteur et plus généralement si la correction des pics observés à un sens sachant que les données des PROVOR sont moyennées par couche et que l acquisition se fait avec une fréquence de 1Hz (contre 24Hz pour des CTDs utilisées dans les campagnes hydrographiques). Un stage sur le sujet a déjà été effectué (F.

4 Gaillard du LPO et C. Gac d Ifremer) et les résultats doivent être finalisés. La cellule R&D Coriolis s intéresse aussi au problème. Une publication de V. Mensah, M. Le Menn et Y. Morel du SHOM est paru en mars 2009 dans Journal of Atmospheric and Oceanic Technology et revisite les constantes de temps du capteur de conductivité SBE4 de chez Seabird. 2.4 Salinité Au début du projet Argo, le contrôle qualité en temps différé (DMQC) des données Argo était focalisé sur la détection et la correction des dérives de capteur de conductivité. La stabilité des capteurs de conductivité s est fortement améliorée avec le temps. Les capteurs Seabird sont nettement meilleurs que les capteurs FSI et les dérives sont plus subtiles à détecter. Les différentes origines pouvant expliquer les dérives des capteurs de conductivité sont passés en revue. Les contrôles réguliers effectués par M. Le Menn du SHOM, des capteurs de conductivité équipant les TSG montrent que les dérives des capteurs de conductivité sont supérieures aux spécifications de Seabird : 1,3 % des cellules de conductivité présentent des dérives < 0,02 ms/cm/an ; 38,5 % présentent des dérives comprises entre 0,02 et 0,05 ms/cm/an ; 10,3 % présentent des dérives anormales, supérieures à 0,07 ms/cm/an. En général, les dérives sont telles que la conductivité (salinité) diminue avec le temps (correction positive lors des étalonnages). Mais depuis 2006, certains capteurs dérivent dans l autre direction et tendent à surestimer la conductivité (correction négative). L origine de ces dérives n est pas claire et pourrait être due à un composant électronique. Il faut noter que si la pression d un flotteur APEX équipé du contrôleur APF8 (qui tronque les valeurs négatives à 0) présente une dérive négative (non détecté), cela se traduira par une dérive de la salinité vers des valeurs trop salées. Il faut donc faire attention à l interprétation des résultats. Il serait intéressant de lister et passer en revue les flotteurs (équipés de capteurs Sea-Bird) pour lesquels la salinité tend à devenir trop salée. D une manière générale, il serait intéressant d avoir des statistiques sur les dérives observés par type de flotteurs et de capteurs. L établissement de ces statistiques a été initié par Christine Coatanoan (cf présentation C. Coatanoan). 2.5 Problème de programmation des SOLO/ WHOI Deux problèmes de programmation des flotteurs SOLO de WHOI ont été détectés. Le premier concerne les flotteurs SOLO/WHOI équipés de capteur FSI. Les mesures faites en profil ne sont pas reportées au bon niveau de pression. Une trentaine de flotteurs sont corrigeables. Sur le site web Argo ( il est mentionné que ces flotteurs sont corrigés et qu ils sont enlevés de la greylist. Cependant, plusieurs utilisateurs ont montré que ces flotteurs ne sont plus dans la greylist mais qu ils transmettent encore des mauvaises données (cf présentations S. Guinehut, J. Gourrion). Il est probable que le problème de programmation de la pression a été corrigé (dans les données temps réels) mais que les autres données du flotteur et notamment les dérives du capteur de conductivité ne l ont pas été (il n y a pas de données temps différés). Cela reste à vérifier. Pour l autre partie des flotteurs SOLO WHOI FSI, les données techniques ne sont pas suffisantes pour corriger les données. Ils sont donc considérés comme non corrigeable et mis dans la grey list. Les flotteurs SOLO WHOI équipés de capteurs SBE ont aussi eu un problème de programmation. D après Argo International, ces flotteurs sont corrigés. D une manière générale, les flotteurs SOLO de WHOI ne fonctionnent pas très bien. De nombreux utilisateurs les éliminent de leurs analyses. 2.6 Mesures près de la surface des PROVOR

5 Le mode de fonctionnement actuel des PROVOR (les valeurs transmises sont des moyennes par tranche de pression) est tel que la valeur transmise pour des données moyennées proches de la surface sont douteuses car la pompe de la CTD est arrêtée lorsque le flotteur franchit les 5dbar. La présence de données douteuses dans la tranche de mesure dont la pression moyenne est inférieure à 5dbar a été détectée en Atlantique Nord (cf présentation V. Thierry sur le QC des flotteurs OVIDE) et en Méditerranée (cf présentation L. Prieur). On peut noter que des modifications (en cours ou prévues) vont permettre : de choisir, lors de la programmation du flotteur, la profondeur à laquelle celui-ci arrête la pompe de sa CTD (en cours de test) de transmettre la dernière mesure effectuée avant l arrêt de la pompe (mesure non moyennée) (en cours de test). de transmettre des mesures ponctuelles de température entre la profondeur d arrêt de la pompe et la surface de manière à avoir des données proche de la surface (en cours de discussion). 2.7 Problèmes de décodage Des problèmes de décodage ont été repérés par plusieurs utilisateurs. Ces problèmes concernent certainement tous les centres de données et probablement tous les types de flotteurs. C est le cas pour les flotteurs APEX et SOLO. Le décodage des PROVOR n a pas été vérifié car l écriture d un décodeur PROVOR n a pas encore été faite. Ces problèmes concernent moins de 5% des profils, il est toutefois important de les corriger car cela fait gagner du temps à tout le monde (utilisateurs ou PIs qui passent moins de temps à traiter ces cas problématiques) cela permet de récupérer des bonnes données qui, étant mal décodées, étaient incorrectes et considérées comme mauvaises cela permet de corriger des données fausses mais non aberrantes et qui étaient donc considérées comme bonnes Ces problèmes de décodage ne sont pas étonnants car pour chaque grand type de flotteurs (APEX, PROVOR, SOLO,..), il y a une multitude de versions différentes et donc de décodeurs différents (plusieurs dizaines pour décoder les différentes versions de flotteur APEX). Les codages sont complexes et parfois subtils et une documentation complète est absolument nécessaire pour décoder correctement les messages des flotteurs. Or cette documentation n existe pas toujours. 2.8 QC temps réel En général les QC sont correctement mis, il existe des cas où il y a une mauvaise attribution systématique des flags : cas des overflows en Atlantique Nord (cf présentation de V. Thierry sur QC des flotteurs OVIDE) ou des données plus profondes que 1000m en Méditerranée (cf présentation L. Prieur). Si de tels cas arrivent, il est important d en informer le centre de données pour que le problème ne se reproduise plus de façon récurrente. Lorsque qu un PI contrôle les données des flotteurs dont il a la charge, il peut donc être amené à revoir les flags de qualité appliqués en temps réel. La question se pose de savoir s il faut faire la correction des flags dans les champs de données temps réels ou dans les champs de données temps différées. Appliquer les corrections de flag sur les données temps réel permet de garder la trace de ce travail laborieux et évite d avoir à le recommencer si la correction temps différé doit être refaite. Cela permet aussi à tous les utilisateurs utilisant les données temps réels de bénéficier des résultats du contrôle et cela limite le temps passé par chacun à re-contrôler la qualité des données. C est une recommandation du comité de pilotage Argo et c est la philosophie adoptée à Coriolis. Appliquer les corrections de flag sur les données temps différé est plus logique car les données sont des données temps réel et elles n ont pas à être modifiées après coup (même s il s agit ici de modifier

6 les flags de qualité uniquement et pas les données). C est la logique suivie par les américains et soutenues par L. Prieur. La question est donc ouverte. 2.9 Méta-données, données techniques et autres Les problèmes découverts récemment et qui portaient sur des types particuliers de flotteurs (APEX équipé du contrôleur APF8, flotteurs équipés du capteur de pression Druck, SOLO de WHOI équipé d un capteur FSI, SOLO de WHOI équipé d un capteur SBE, etc ) montrent l importance des métadonnées dans lesquelles on trouve le type et la version du flotteur, les capteurs utilisés, etc. Il est donc très important de remplir le plus correctement et le plus complètement possible ces méta données. Cela signifie aussi que les feuilles de mise à l eau, à partir desquelles le fichier de métadonnées est rempli, doivent être les plus complètes et les plus précises possibles. Des suggestion de modification ont déjà été proposées, il faut en discuter au niveau de Argo Interntaional et de Coriolis : déterminer de nouvelles méta données «highly desirable» proposer une homogénéisation des appellations dans les meta-données proposer de nouvelles méta-données De nouveaux noms pour les données techniques ont été définis afin d homogénéiser les noms à travers les centres de données Argo (DAC) et de rationaliser les appellations si de nouveaux noms doivent être définis. Les fichiers du DAC Coriolis avec les nouveaux noms sont d ores et déjà disponibles sur demande. Il devrait remplacer les anciens fichiers (avec les anciens noms) d ici la fin de mois de mai Développement améliorations sur le PROVOR Les développements et améliorations prévus sur le PROVOR/ARVOR sont les suivants : Transmission de la pression avec une résolution du cbar pour détecter les variations de capteur de pression. Il faut réfléchir à la gamme de mesure ([ ] dbar ou plus?). On peut aussi se demander si l utilisation de la commande resetoffset de la tête Seabird qui permet de remettre à zéro le capteur de pression est recommandée. Modifications pour les mesures près de la surface (cf Section 2.6). Développement d un flotteur profond (350 bar) (cf Rapport interne LPO n 09-05) 3 QC des flotteurs Christine Coatanoan a rappelé les procédures de contrôles qualités «temps réel» et «temps différé» et a présenté l historique et le fonctionnement de la méthode Owens et Wong (OW) proposé par Argo pour contrôler et corriger des dérives ou des biais en salinité. Les Pis des flotteurs (personnes responsables du contrôle de ces flotteurs) doivent contrôler les données, meta-données, données techniques, données trajectoires pour se faire une idée du fonctionnement du flotteur. Ils doivent contrôler la pression de surface et la corriger si nécessaire (flotteurs APEX), vérifier les flags de qualité attribués en temps réel et chercher les pics en salinité dus à l inertie thermique. Comment corriger ces pics (cf Section 2.3)? Si ce n est pas corrigé, il faut attribuer un flag de qualité à 4 à ces données. Christine Coatanoan aide les PIs pour la méthode OW. Si nécessaire et en collaboration avec les Pis, elle peut faire marcher les programmes de la méthode OW. Les Pis valident les corrections proposées. Christine rappelle également la signification des champs «adjusted in real time» qui ont un «DATA_MODE» égal à «A». Dans ce cas, les champs «ADJUSTED» sont remplis et les ajustements sont faits en temps réel pas des procédures automatiques. Les données sont ajustés en temps réel dans 2 cas typiques : application sur les données temps réel d un biais en salinité détecté lors des contrôles temps différé, correction en temps réel de la pression des flotteurs APEX, à partir des mesures de pression de surface, et de la salinité. Rappelons que le «DATA_MODE» des données

7 temps réel et temps différé est respectivement égal à «R» et «D». Christine a mis en place des premiers tests pour s assurer que les données temps différés qu elle entre dans la base ne sont pas aberrantes. Plusieurs opérateurs ont présenté les contrôles effectués sur les lots de flotteurs dont ils ont la charge. Hormis certains flotteurs problématiques d ancienne génération, les flotteurs marchent bien. Très peu ont été corrigés en salinité : aucune correction pour les flotteurs déployés en Méditerranée, aucune correction sur les flotteurs Mouton, 2 flotteurs corrigés parmi les flotteurs OVIDE contrôlés. En fonction des spécificités régionales, le contrôle des données est plus ou moins facile. Dans les zones où les masses d eaux profondes sont stables, le contrôle est relativement aisé. C est le cas de la Méditerranée ou de la zone intergyre en Atlantique Nord-Est. Dans les zones frontales, les zones de formation des eaux profondes ou les zones pauvres en données de référence, la méthode OW n est pas très adaptée et les résultats fournis doivent être vérifiés par des méthodes complémentaires (comparaison directe à des données voisines, à des données CTD effectuées lors du déploiement du flotteur). C est le cas dans l océan Austral ou le gyre subpolaire de l Atlantique Nord. Dans ces régions, le développement d une méthode différente pourrait être envisagé. Des tests ont montré qu en Atlantique Nord, que la détection et la correction d un biais en salinité se faisait au minimum à 0.01 psu près. On a besoin de connaître les statistiques sur le nombre de flotteurs qui dérivent par type de flotteurs ou de capteurs, sur l amplitude et la direction des dérives. Les Pis sont encouragés à fournir ce genre d information à Christine Coatanoan. Lors du contrôle des flotteurs, il a été remarqué qu un flag de qualité égal à 3 ou 4 (données probablement mauvaises ou données mauvaises) était systématiquement attribué à certaines bonnes données. C est le cas des données des overflows en Atlantique Nord (cf présentation V. Thierry sur QC des flotteurs Ovide) ou des données plus profondes que 1000 m en Méditerranée (cf présentation L. Prieur). Pour éviter que ces erreurs systématiques d attribution de flag se reproduisent, il est important d en informer Coriolis au plus vite qui identifiera l origine du problème et le corrigera. Il faudrait aussi que la cellule R&D Coriolis revoit les tests temps différés pour comprendre l origine du problème et voir si d autres problèmes de ce type peuvent se reproduire. L attribution et la signification d un flag de qualité égal à 2 ont été discutées. L utilisation de ce flag n est pas claire pour tout le monde. Le manuel Argo sur le contrôle qualité des données mentionne : The following are some cases where PSAL_ADJUSTED_QC = 2 should be assigned Adjustment is based on unsatisfactory reference database. Adjustment is based on a short calibration window (because of sensor behaviour transition, or end of sensor life) and therefore may not be stable. Evaluation is based on insufficient information. Sensor is unstable (e.g. magnitude of adjustment is too big, or sensor has undergone too many sensor behaviour changes) and therefore data are inherently of mediocre quality. When a float exhibits problems with its pressure measurements. 4 Contrôles globaux Les mêmes (gros) problèmes ont été détectés par plusieurs utilisateurs à l aide d outils différents développés suivant les besoins de ces utilisateurs. Les outils présentés concernaient l utilisation d analyse objective pour comparer les données Argo à des données voisines et à la climatologie (cf présentation F. Gaillard) ou à des données Argo voisines (cf présentation C. Gourcuff)

8 la comparaison des données Argo des données indépendantes comme l altimétrie (cf présentation S. Guinehut) l utilisation des valeurs minimales/maximales par zones géographiques pour détecter des données aberrantes (cf présentation J. Gourrion) Il serait intéressant de mettre à disposition de la communauté Argo la liste de ces données aberrantes et de ces profileurs qui ont un comportement douteux de manière à éviter que chaque utilisateur perde trop de temps à refaire le même travail de nettoyage. Le cas des flotteurs SOLO de WHOI a été mentionné. Plusieurs utilisateurs ont retrouvé que ces données transmettaient des mauvaises données. Ils ont probablement été corrigés des problèmes de programmation (pression) mentionné section 2.5 mais le contrôle temps différé des autres paramètres n a pas été fait et les flotteurs qui sont détectés ont des problèmes de dérive du capteur de conductivité, des profils «gelés» (le même profil se répète d un cycle à l autre), etc Cela doit être vérifié. Vu les problèmes rencontrés sur les flotteurs SOLO de WHOI, il est préférable de ne pas les utiliser. Ces contrôles globaux sont utilisés par Coriolis pour éliminer des données aberrantes et fournir des jeux de données de meilleure qualité que les données fournies en temps réel pour lesquelles seuls des contrôles automatiques ont été effectués. La visibilité de ces jeux de données devra être amélioré pour faciliter l accès des utilisateurs à ces jeux de données de qualité. 5 R&D Coriolis Depuis quelques mois, une cellule recherche et développement a été mise en place au sein de Coriolis. Les personnes travaillant au sein de cette cellule ainsi que le rôle et les objectifs de cette cellule ont été présentés par Clément de Boyer Montégut. Une discussion a eu lieu sur le lien entre laboratoires de recherche/pis et Coriolis. Ces discussions ont abordés la question des flotteurs «orphelins». Il y a un arrangement entre les pays. Ceux qui ont la connaissance de certaines régions prennent en charge ces flotteurs orphelins. Coriolis s occupe plutôt de l Atlantique Nord. Cela soulève tout de même une question sur le centre régional Atlantique Nord : qui s en charge effectivement? Vu la complexité de la méthode OW, et la quantité de connaissance nécessaire pour contrôler correctement la qualité d un flotteur Argo, il est clair que ce contrôle doit être effectué par des «experts» qui ont l habitude de faire ce travail. Un PI responsable d une poignée de flotteurs ne pourra pas prendre en main la méthode et acquérir tous les connaissances requises pour effectuer correctement ce travail. 6 Références Gaillard F., E. Autret, V. Thierry, P. Galaup, 2009: Quality control of large Argo datasets. J Atmos. and Ocean. Tech., 26, , doi: /2008JTECHO Guinehut S., C. Coatanoan, A.-L. Dhomps, P.-Y. Le Traon, G. Larnicol, 2009: On the Use of Satellite Altimeter Data in Argo Quality Control, J Atmos. and Ocean. Tech., 26, , DOI: /2008JTECHO Johnson G. C., J. M. Toole, N. G. Larson, 2009: Sensor Corrections for Sea-Bird SBE-41CP and SBE- 41 CTDs. J Atmos. and Ocean. Tech., 24, , doi: /JTECH Mensah V., M. Le Menn and Y. Morel, 2009: Thermal Mass Correction for the Evaluation of Salinity, J Atmos. and Ocean. Tech., 26, , DOI: /2008JTECHO612.1.

9 Owens W. B., A. P. S. Wong, 2009: An improved calibration method for the drift of the conductivity sensor on autonomous CTD profiling floats by θ S climatology. Deep-Sea Res. I, 56,