Heliophysics VO Projects » Helio Feature Catalogue

h1. Actuelle (HFC V12)

h2. Description générale

La figure ci-dessous présente l'enchaînement de processus (worfklow) opéré par le pipeline du HFC pour traiter, insérer et rendre visible les données.

Ce workflow est executé toute les nuits de manière automatique: lancement via cron depuis la machine tycho pour l'execution des codes et le transfert des fichiers produits sur le serveur ftpbass2000. Puis lancement quelques heures plus tard toujours via cron mais depuis la machine voparis-helio, de l'insertion dans la base des données des nouveaux fichiers sur ftpbass2000. Les 3 tâches "exécution des codes", "copie sur le serveur ftp" et "insertion dans la base" sont indépendantes et réalisées par des scripts différents (voir plus bas).

!{width: 60%}helio_hfc_v1.2_dataflow_v1.png!

Les étapes de ce workflow ainsi que les interfaces utilisateur (boîtes vertes en bas de la figure) sont décrites dans les sections suivantes.

h2. Principales étapes du traitement et de la mise à disposition des données

Les principales étapes du workflow sont les suivantes :

# Lancement des FRC sur la machine tycho.obspm.fr par le script run_hfc_frc.sh. Les FRC sont lancés à 1 min d'intervalle, la plupart étant gérée via le gestionnaire SLURM (voir http://dio.obspm.fr/Calcul/tycho/ pour plus de détails) 

# Une fois lancés, chaque code va se charger d'aller récupérer les dernières observations à traiter, d’exécuter le code de detection (ou tracking ou autre), puis de générer les fichiers contenant les résultats de la detection (.csv) et les quickloock (.jpg) des observations. (Sauf exception, chaque produit un jeu de fichiers (.csv, .jpg) par observation. Ces fichiers sont sauvegardés dans un dossier dédié sur tycho (/data) 

# Un second script hfc_upload_fr.sh se charge ensuite de copier sur le serveur ftpbass2000.obspm.fr les derniers fichiers produits par les codes. Les fichiers copiés sont ensuite effacés sur tycho (le programme vérifie que les fichiers sont correctement copiés avant de les effacer).

# Un dernier script hfc_insert_fr.sh s'occupe ensuite de l'insertion des données de ces fichiers dans la base du HFC (l'insertion se fait en pratique en appelant le code Java hfc_insert).

# Les interfaces utilisateur ne nécessitent pas de mise à jour régulière, excepté EPN-TAP dont les vues matérialisées de la base gavo doivent être mises à jour pour correspondre aux derniers données de la base HFC.

h2. Les interfaces utilisateur

h3. Page Web HFC

La page web (dite GUI(Graphical User Interface)) du HFC est hébergée sur le serveur voparis-helio et gérée via Apache 

La page est accessible depuis : http://voparis-helio.obspm.fr/hfc-gui/.

Le code source de la page se trouve dans le dossier /usr/local/www/data/hfc-gui sur voparis-helio.

h3. HQI

Le HQI(HELIO Query Interface) est une interface Web permettant d'interroger les services HELIO de manière standard.

Il permet l'envoie de requête via SOAP ou HTTP (des interfaces TAP et VOSI sont également implémentées, mais non pleinement opérationnelles selon K.Benson).

Techniquement le HIQ est une servlet java (.war) déployée sous Tomcat sur la machine voparis-helio. (voir http://voparis-helio.obspm.fr:8082/, autorisation nécessaire pour accéder à la page d'administration de Tomcat).

h3. EPN-TAP

Le service EPN-TAP du HFC est hébergé sur la machine voparis-tap-helio, et géré à l'aide de l'outil "DaCHS":http://docs.g-vo.org/DaCHS/.

Une fois installé et configuré, DaCHS se charge de publier les données via un service TAP(Table Access Protocol) pleinement opérationnel, à la condition de lui fournir les inputs suivants :

* une table postgres *.epncore respectant le data model (DM) epnCore, et contenant les meta-données visibles par le service. En pratique, on utilise une vue matérialisée 

* un fichier q.rd (1 par table) 

h3. STILTS

Le service "STILTS":http://www.star.bris.ac.uk/~mbt/stilts/ n'est pas supposé être une interface publique, mais un outil pour la maintenance du service. Cependant en pratique le client IDL du package HELIO de SolarSoft nécessite qu'il reste fonctionnel.