gpscope-DT UPS 855

Partenaires

menu

• Parc mobile
  • Les logiciels de communication et les notices d’utilisation
  • Les caractéristiques des antennes
  • Rapports d’activités et comptes rendus
  • Contrôle des antennes
• Chantiers pemanents hors de France
• Campagnes
• Documentation technique
  • Monumentation
  • foudre
  • Récepteurs
  • Capteurs météo
  • Accessoires
  • télécommunications
    • GPRS
  • Présentations techniques
  • traitement des données

Rechercher

Contrairement aux données de campagne dont on peut réserver le traitement pour un moment plus propice, le flot de données issues des stations permanentes impose une prise en compte régulière sous peine d’accumuler un retard qui se chiffre rapidement en plusieurs semaines de temps de calcul ininterrompu. La solution décrite ici permet d’obtenir quotidiennement des graphiques de séries temporelles au fur et àmesure de l’arrivée des données.

La méthode et les utilitaires décrits ci-après sont basés sur la suite gamit/globk/glorg du MIT.

Une règle de base que je me suis imposée dans mes développements a été de ne jamais modifier les programmes du MIT, même si cela semblait parfois plus simple. L’intérêt est de pouvoir suivre les mises àjour du MIT sans avoir àreporter (et adapter) ces modifications àchaque fois.

Une sécurité quand il s’agit de traitement automatisé est, indépendamment des procédures, de créer un utilisateur dédié àcette application (ici gpscope) indépendant de tous les noms d’utilisateurs "en chair et en os" qui risqueraient de faire une fausse manoeuvre compromettant le bon déroulement des tâches automatisées.

L’ensemble du processus s’appuie sur une structure de quatre grands répertoires :
 le répertoire des données àtraiter
 le répertoire de calcul
 le répertoire d’archivage des données
 le répertoire de la page web consacrée au chantier

Acheminement des données

Cette étape est spécifique àchaque source de données. Le traitement "générique" des données ne peut commencer qu’après cette étape dont les procédures sont forcément dédiées. La seule contrainte commune àtoutes ces procédures est d’amener les données, sous un format compris de gamit (texte RINEX, Hatanaka, compressé ou non), au point d’entrée de l’étape suivante qui elle, est générique.

Ce point d’entrée est un répertoire "de dépôt" où convergent toutes les données nouvelles pour un même chantier. dans notre cas, nous avons les répertoires gpscope/deposit/cori pour le chantier Corinthe, gpscope/deposit/chil pour le chantier chili, etc.

J’ai successivement développé plusieurs méthodes d’acheminement des données. Je les survole rapidement :

Le premier cas est celui où elles arrivent directement du récepteur GPS. Nous avons alors un fichier brut au format constructeur. Nous sommes donc « centre opérationnel » et il est de notre responsabilité de sauvegarder ces fichiers bruts avant de les traduite en rinex et de les introduire dans le calcul.

Le second cas est celui où nous avons directement accès àdes données RINEX.

J’ai d’abord travaillé avec des scripts shell qui utilisaient ftp. Tous ces scripts de rapatriement de données devaient maintenir une liste des données déjàtéléchargées. Cette liste était comparée chaque jour àla liste des données présentes sur le site distant [1], de façon àne télécharger que les nouveaux fichiers. L’élément critique de cette méthode est la liste des fichiers déjàtéléchargés : une manipulation malheureuse et on reprend tout àzéro.

Maintenant je préfère comparer les fichiers distants au contenu de l’archive locale ET àcelui du répertoire des données en attente de calcul. C’est un peu acrobatique en script shell mais immédiat en Perl grâce aux modules Net::FTP et POSIX.

Le cas le plus favorable est celui où l’on dispose d’un accès ssh àla machine distant. J’écris alors sur la machine distante une routine qui, chaque jour, crée un fichier texte par année d’archive contenant la liste des RINEX de l’année avec leur chemin absolu(strictement la sortie d’un ls ${annee}/*/rinex/*d.Z). Je récupére cette liste par scp sur la machine locale (l’utilisation du fichier ~/.netrc simplifie encore l’écriture du script) et je copie les fichiers manquants par scp également : plus de ftp!

Ces procédures sont durcies àchaque nouveau problème rencontré. L’interruption de la connexion pendant le téléchargement reste cependant un problème sans solution définitive. Même la comparaison des tailles des fichiers peut ne pas suffire, car elle dépend des types de systèmes de fichiers distants et locaux. Un ftp en mode ASCII sur une machine Windows peut également rajouter des \r àchaque ligne...

Pour surveiller le rapatriement, le script sh_mail_new, activé une fois par jour, explore tous les logs de tous les scripts de rapatriement (ils commencent tous en sh_ftp_data...) àla recherche de lignes du type "sitejjj0.aad.Z is a new file" et envoie un Email àune liste de diffusion prédéfinie avec la liste de ces fichiers, par script, en indiquant la date de l’information.

J’ai traité le cas des données brutes qui arrivent "àpied" àl’institut par la création d’un répertoire "de vrac" en écriture pour tous. Chacun peut y déposer ses données comme il veut et me le signale par Email. Je me charge d’en contrôler le format et de les injecter dans le circuit automatisé. Même si je ne suis pas infaillible, cela limite déjàbeaucoup les risques d’introduction de "grains de sable" dans la mécanique.

Identication des jours àcalculer

La première étape consiste àfaire l’inventaire des jours de caculs correspondant aux données présentes dans le répertoire de dépôt. Le script sh_newdata renvoie une ligne contenant tous les couples (année, jour) trouvés et copie toutes ces données dans le sous-répertoire ./rinex du répertoire d’expérience.

Ensuite, comme les données sont calculées au fur et àmesure de leur arrivée, certaines ont été caculées avec des orbites prédites ou rapides. sh_process_master explore ./rinex àla recherche de données d’il y a deux jours (délai d’obtention d’orbites rapides) et d’il y a 23 jours (pire délai constaté pour des orbites finales). Si ces données existent, ces jours sont ajoutés àla liste des calculs àlancer.

Enfin, différentes pannes d’infrastructure (coupures électriques, défaillance des disques réseau, du serveur de nom, etc.) peuvent empêcher le lancement quotidien de ces calculs. c’est pourquoi sh_process_master maintient dans le répertoire d’expérience un fichier orbit.log du type :

Il s’agit des couples (année, jour) qui n’ont pas été traités avec des orbites finales. A ce stade, tous les jours au-delàdes 23 jours indiqués au-dessus sont ajoutés àla liste des calculs àlancer.

Si le vecteur $yrdoy qui contient l’ensemble des couples (année, jour) àcalculer ne possède aucun élément, le script s’arrête.

Plus un processus tourne longtemps, plus il y a de chances pour qu’un incident extérieur (panne de courant, disparition des disques distants, redémarrage de la machine, etc.) vienne l’interrompre. Des interruptions trop fréquentes amène le vecteur $yrdoy àdépasser la taille maximale admise par le système d’exploitation ("Argument list too long" est le message d’erreur typique). J’en suis arrivé àmettre une limite en dur sur le nombre de jours traités en une fois. Pour l’instant j’ai fixé ce nombre à24 et chaque chantier est calculé une fois par jour. Je rythme alors le lancement de la procédure en fonction de la durée d’un calcul journalier de façon àêtre sà»r que deux lancements successifs ne se marchent jamais sur les pieds (une fois par jour pour La Réunion, une fois tous les quatre jours pour le Chili, etc.). Pour rattraper des gros retards sans perdre des demi-journées entières, j’ai même fini par écrire une procédure qui teste tous les quarts d’heure si la procédure principale tourne déjàen mémoire. Dans la négative, elle la lance !

calcul effectif

Après avoir affiché àl’écran la liste des couples (année, jour) pour lesquels un calcul va être lancé, sh_process_master lance sh_gamit pour chacun d’eux (le répertoire jour correspondant, s’il existe déjà, est supprimé avant chaque calcul).

La sortie écran de sh_gamit est redirigée dans le répertoire d’expérience vers le fichier sh_gamit.log (qui ne correspond donc qu’au calcul en cours ou au dernier calcul effectué).

Pour donner un minimum de flexibilité àcette procédure générique, sh_process_master regarde s’il trouve dans le répertoire d’expérience un fichier gamit.OPT. Dans l’affirmative, il s’agit d’options non standard àrajouter sur la ligne de commande sh_gamit. C’est par exemple làque j’ajoute -rinex_ftpsites ign kreiz -ftp_prog wget qui sont des options propres àun chantier et àla localisation de la machine de calcul derrière la passerelle de l’IPGP [2] (attention, il faut aussi un fichier ftp_info spécifique àl’IPGP).

Une fois le calcul effectué, sh_process_master met àjour le fichier orbit.log, affiche àl’écran les éventuelles lignes de sh_gamit.log contenant les mots ERROR ou FATAL, ainsi que la liste des fichiers rinex utilisés.

validité du calcul

La validité d’un calcul est une vaste question. J’ai choisi, àce stade, de rester modestement sur un critère que je qualifierais de purement informatique : l’existence d’un fichier o indexé en a dans le réperoitre jour.

Si ce fichier existe,
 les données sont supprimées du répertoire de dépôt (ne les supprimer que maintenant de ce répertoire est une sécurité par rapport àune panne qui interromprait la procédure : ces données restent dans "la salle d’attente" tant que l’on n’est pas sà»r de les avoir traitées au moins une fois).
 les différents fichiers h présents (du fait de calculs antérieurs) dans ./glbf et ./gsoln et les fichiers globk (.prt, .log, .gdl, .org) pour ce jour sont supprimés. Ainsi, toujours en cas d’interruption de la procédure, les séries temporelles ne risquent pas d’afficher des points issus d’anciens calculs.
 le fichier nav de ./brdc
 Si le calcul est effectué avec des orbites finales, les fichiers RINEX externes sont supprimés de ./rinex (identifiés àpartir de la mention ftprnx du fichier sites.defaults).

Si ce fichier n’existe pas,
 le fichier sh_gamit.log est renommé en ajoutant le jour julien en extension (ce qui permet de regarder a posteriori ce qui s’est passé).
 les sous-répertoires ./igs ./gfiles ./brdc et le répertoire jour sont supprimés ainsi que les fichiers ut1 et pole de ./tables [3].

Nettoyage

A la fin de l’ensemble des calculs gamit journaliers, sh_clean_expe supprime tous les fichiers temporaires accumulés dans les différents sous-répertoires. La reprise en une fois de plusieurs années de calcul peut créer un nombre de fichiers temporaires supérieur àce que peut supporter le système d’exploitation -"Argument list too long.". Mais cela n’a aucune chance de se produire dans le cas d’un calcul routinier ; il faut une intervention humaine pour provoquer ce débordement.

calcul de la série temporelle

A chaque boucle sur le calcul gamit journalier, sh_process_master a mis àjour les valeurs du plus ancien couple (année, jour) pris en compte. Il est donc en mesure maintenant de lancer sh_glred sur la période s’étendant du plus ancien jour calculé au plus récent présent dans le répertoire d’expérience.

Comme pour sh_gamit, un minimum de flexibilité est introduit par le fichier glred.OPT, présent ou non dans le répertoire d’expérience [4]. En son absence, les options G E H sont celles prises par défaut. Mais les scripts sh_plot_... qui suivent rendent l’option E de sh_glred inutile.

Lorsqu’un calcul gamit est interrompu (lors d’une panne de courant, par exemple), il arrive qu’un fichier h tronqué soit généré. Il en résulte que htoglb tourne sans fin sur ce fichier, ce qui bloque sh_glred et sh_process_master. La première chose que je fais pour palier àce problème est, avant de lancer sh_glred, de vérifier s’il y a déjàun processus htoglb en train de tourner. Dans l’affirmative je le tue. Cela a pour conséquence la sortie du processus sh_glred lié àce htoglb et la continuation de l’instance précédente de sh_process_master (àce moment là, j’ai deux sh_process_master qui tournent sur la machine). Après l’execution de sh_glred je vérifie que le dernier htoglb mentionné dans sh_glred.log traitait bien le dernier jour indiqué dans la commande sh_glred. Sinon, je supprime le répertoire jour correspondant (pour éviter que le prochain calcul ne bloque ànouveau sur ce fichier h) et je transfère les fichiers rinex de ce jour vers le répertoire "de dépôt". Le fichier h sera ainsi régénéré par le prochain calcul gamit.

création de graphiques "court-terme"

Après destruction de tous les fichiers gif ou post-script éventuellement présents dans ./gsoln, sh_plot_shortterm lance les outils de la suite gamit/globk afin de visualiser les séries temporelles des 90 derniers jours de données (sh_plot_shortterm prend en arguments les deux couples (année, jour) extrêmes de la suite de jours que l’on veut visualiser). Les fichiers finaux sont des gif.

création de graphiques "long-terme"

Après destruction de tous les fichiers gif ou post-script éventuellement présents dans ./gsoln, sh_plot_longterm lance les outils de la suite gamit/globk sur l’ensemble des fichiers org présents dans ./gsoln de façon àobtenir l’intégralité de la série temporelle acuellement disponible. Les fichiers finaux sont des gif.

Je ne développerai pas ici des aspects propres aux outils gamit/globk, mais la réalisation d’un graphique de série temporelle sur plusieurs années peut dépasser les capacités du système selon comment on utilise les utilitaires proposés par le MIT.

Dans les deux cas (court et long terme), je me suis laissé la possibilité de passer des options aux outils gamit (sh_plotcrd) par le fichier plot.OPT dans ./gsoln [5]. Les chantiers sur les volcans présentent des barres d’erreur supérieures aux autres : je prends cela en compte en choisissant des valeurs différentes pour les paramètres maxsigne et maxsigu, ce qui change le niveau de bruit des points admis sur la visualisation des séries temporelles.

archivage, publication des séries temporelles et mise àdisposition des données

Après suppression de l’ensemble des images contenues dans le répertoire du site web qui leur est dédié, sh_process_master y copie les nouvelles images de séries temporelles, puis lance sh_web_data qui explore le sous-répertoire ./rinex et copie dans l’archive de l’équipe les données qui n’y sont pas encore tout en créant différents liens symboliques sur le site Web qui permettront de trouver ces données par site ou par date sans multiplier les fichiers.

procédures spécifiques

Pour certains chantiers il m’été demandé de fournir des graphiques supplémentaires (par exemple les lignes de bases par rapport àun site). Pour permettre cette flexibilité j’ai ajouté la possibilité d’exécuter un script sh_specific_nom_expérience1 juste après sh_plot_shortterm, et un script sh_specific_nom_expérience2 juste après sh_plot_longterm. Si ce script est présent dans le répertoire d’expérience, il est exécuté par sh_process_master [6].

utilitaires

Certaines tâches devaient être exécutées indépendamment de ce calcul principal :
 sh_updt_tables : met àjour les tables gamit àpartir du site de sopac et de celui de gamit. Il travaille sur l’ensemble des versions gamit présentes [7] et termine en ré-écrivant tous les fichiers station.info de tous les chantiers (par fusion des ./tables.templates/station.info.EXPE avec le dernier station.info.sopac.newfmt, ce qui me permet de suivre l’évolution des stations IGS sans effort).
 sh_clean_old : supprime tous les répertoires jour et les données rinex (après vérification de leur existence dans l’archive de l’équipe) du répertoire d’expérience s’ils sont plus vieux qu’un certain nombre de jours actuellement fixé à60. Cela évite de saturer le disque.
 sh_arch_gamres : range les fichiers o, h et q présents dans le répertoire d’expérience dans l’archive des données.

Gestion automatique

La clef de tout ça est la crontab de la machine qui fait les calculs. Voici l’exemple de la machine qui fait non seulement le calcul de trois réseaux différents mais également le rapatriement de l’ensemble des données pour toutes les machines. On notera la sauvegarde, une fois par semaine, de certains résultats des calculs (faits localement pour gagner en temps d’accès et ne pas saturer le réseau local) vers le disque réseau qui lui, est sauvegardé par le service informatique.

Pour chaque script la sortie est redirigée vers un fichier log spécifique qui permettra de retracer les évènements en cas de problème. Afin de ne pas générer trop de logs illisibles, seules les sorties de sh_process_master n’écrasent pas la sortie précédente. Je supprime ce fichier de temps en temps, par exemple quand je vérifie que rien d’anormal ne s’est passé au cours des dernières semaines.

Evolution des procédures dans le cadre d’une unité de service

J’ai rédigé la première version de cet article lorsque je travaillais àl’IPGP qui est ce que l’IGS appelle un « centre opérationnel », c’est àdire un endroit où l’on s’occupe de la récupération des données depuis le terrain (que ce soit avec une étape dans les observatoires ou directement depuis la « maison mère »). La mise àdisposition des données sur le Web n’intervenait qu’après le calcul et constituait l’ultime étape du cheminement des données.

Aujourd’hui, en tant que support de la communauté GPS nationale, je dois distinguer deux types de services que je peux rendre aux centres opérationnels :
 La mise àdisposition sur le Web et l’archivage centralisé des données INSU au sens large.
 Le calcul automatique de certains chantiers sur demande des scientifiques concernés.

Pour séparer ces deux services, j’ai créé un répertoire de transit, avec encore des sous-répertoires par chantiers. Chaque jour je compare ce que les centres opérationnels proposent sur leur archive avec ce dont je dispose déjàet je télécharge la différence dans mon répertoire de transit.
Sur les fichiers présents dans ce répertoire j’effectue successivement :
 une copie dans mon archive
 une création des liens àpartir du site Web vers l’archive pour la mise àdisposition
 Ã©ventuellement une copie de ces mêmes fichiers dans le répertoire de dépôt, en attente de calcul.
 l’effacement de tout ce que contient le répertoire de transit.

Ce nouveau répertoire est donc vide la plupart du temps. L’archivage et la mise àdisposition sur le Web ne font plus partie de la procédure standard de calcul !