Actuelle (HFC V12)¶

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).

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.

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

Les principales étapes du workflow sont les suivantes :

1. 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)
2. 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)
3. 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).
4. 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).
5. 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.

Les interfaces utilisateur¶

Page Web HFC¶

La page web (dite GUI) 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.

HQI¶

Le HQI 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).

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.
Une fois installé et configuré, DaCHS se charge de publier les données via un service TAP 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)

STILTS¶

Le service 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.