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 exécuté 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é, chaque code va se charger d'aller récupérer les dernières observations à traiter, d’exécuter l'algorithme de détection (ou tracking ou autre), puis de générer les fichiers contenant les résultats de la détection (.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 lancer la copie sur le serveur ftpbass2000.obspm.fr les derniers fichiers produits par les codes. En pratique hfc_upload_frc.sh appelle un sous-script Python upload_frc.py qui effectue la copie. Les fichiers copiés sont ensuite effacés sur tycho afin de libérer de l'espace (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. En pratique hfc_insert_fr.sh appelle le code Java hfc_insert qui effectue l'insertion.
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.

Organisation des fichiers produits par les codes¶

Il existe 2 types de fichiers produits par les codes (FRC), des fichiers au format .csv (i.e., fichier ASCII avec le caractère ";" comme séparateur) et des fichiers .jpg pour les images (quicklooks).
En principe un jeu de fichiers .csv et .jpg est produit pour chaque fichier d'observation (e.g., image, spectre) traité par un code.

Les fichiers .csv¶

Les fichiers .csv contiennent les paramètres (données) extraits par les codes de détection, ainsi que toutes les informations (meta-données) relatives à l'observation.
Le tableau ci-dessous donne la liste des fichiers .csv à produire par les codes, leur contenu, les extensions standards de fichier attendues, et la ou les tables de la base dans lesquelles les données du fichier sont insérées.

EXTENSION	CONTENU	TABLES HFC
_init.csv	contient les meta-données relatives à l'observation (e.g, résolution de l'image, nom et format du fichier, date de création, etc.)	OBSERVATIONS
_observatory.csv	contient les méta-données relatives à l'observatoire utilisé pour réaliser l'observation (e.g., type, nom, sous-instrument, caractéristiques, etc.)	OBSERVATORY
_frc_info.csv	contient les méta-données relatives au code de detection (e.g., nom, version, auteur, référence, etc.)	FRC_INFO
_feat.csv	contient les paramètres des features detectés (e.g., position, contour, intensité, etc.)	nom de la table liée au feature (e.g., "ACTIVEREGIONS" pour les régions actives)
_track.csv	contient les données relatives au suivi (tracking) des features	nom de la table tracking liée au feature (e.g., "FILAMENTS_TRACKING" pour le tracking des filaments)
_norm.csv	contient les méta-données relatives aux observations pré-processées (e.g., pré-traitement opérés, nouvelles caractéristiques, etc.)	PP_OUTPUT
_pp_info.csv	contient les méta-données relatives au programme de pré-traitement (e.g., nom, version, auteur, référence, etc.)	PP_INFO

Pour un code donné, les fichiers .csv sont copiés par le script hfc_ftp_upload.sh sur le serveur ftpbass2000.obspm.fr dans le dossier :

/pub/helio/[frc_name]/[YYYY]

Où [frc_name] est le nom du code (e.g., SDOSS) et [YYYY] l'année de l'observation traitée (4 digits).

Les fichiers .jpg¶

La plupart des codes de détection produisent également une image au format jpg de l'observation traitée (par ex., image du soleil ou spectre dynamique). Ces images sont copiées par le programme upload_frc.py sur le serveur ftpbass2000.

Pour des raisons "historiques", les images sont copiées dans un dossier différent des fichiers .csv :

/temp/qlk/[observat]/[instrume]/[YYYY]/

Où [observat], [instrume] et [YYYY] correspond à l'observatoire, l'instrument et l'année (sur 4 digits) de l'observation.

Note: Si deux codes produisent une image .jpg provenant de la même observation, elle n'est donc copiée qu'une fois sur le ftpbass2000.

Les interfaces utilisateur¶

Voir la page Interfaces.