Nomenclature fichiers
Environnement de développement crée sur taranis1.irap.omp.eu, pour faire cohabiter les deux versions des softs.
Prise en compte nouvelle nomenclature des noms de fichiers CDF :
mmo_<instrument>_<level>_<dataset>_<date>_<version>.cdfTélémesure L0
|
pas de version pour ces fichiers |
mmo_mppe-mdp1_l0_tm-167_20240409.dat
mmo_mppe-mea1_l0_tm-167_20240409.dat
mmo_mppe-mea2_l0_tm-167_20240409.dat
mmo_mppe-shsk_l0_tm-167_20240409.datmmo_mppe-mdp1_l0_tm-240_20240409.dat
mmo_mppe-mea1_l0_tm-240_20240409.dat
mmo_mppe-mea2_l0_tm-240_20240409.dat
mmo_mppe-shsk_l0_tm-240_20240409.datmmo_mppe-mea1_l0_tm_20240409.dat
mmo_mppe-mea2_l0_tm_20240409.datRemarques
mppe-mdp1 : contient les dump mémoires du MDP#1
mppe-shsk : contient les system-hk
mppe-mea1 : contient HK + science de MEA1
mppe-mea2 : contient HK + science de MEA2
Plusieurs fichiers regroupés pour créer au final deux fichiers pour mea1 et mea2:
-
mea1 = mdp1 + mea1 + shsk
-
mea2 = mdp1 + mea2 + shsk
Données CDF L1
Prise en compte nouvelle nomenclature
Exemple pour mea1 le 2024/04/09 :
-
mmo_mppe-mea1_l1_3d-high_20240409_V00.cdf
-
mmo_mppe-mea1_l1_3d-low_20240409_V00.cdf
-
mmo_mppe-mea1_l1_3d-med_20240409_V00.cdf
-
mmo_mppe-mea1_l1_hsk_20240409_V00.cdf
-
mmo_mppe-mea1_l1_log_20240409_V00.log
-
mmo_mppe-mea1_l1_omni-16e_20240409_V00.cdf
-
mmo_mppe-mea1_l1_omni-32e_20240409_V00.cdf
-
mmo_mppe-mea1_l1_omni-64e_20240409_V00.cdf
-
mmo_mppe-mea1_l1_pap-16s_20240409_V00.cdf
-
mmo_mppe-mea1_l1_pap-2s_20240409_V00.cdf
-
mmo_mppe-mea1_l1_pap-4s_20240409_V00.cdf
-
mmo_mppe-mea1_l1_sys-hsk_20240409_V00.cdf
-
mmo_mppe-mea1_l1_vm-low_20240409_V00.cdf
-
mmo_mppe-mea1_l1_vm-med_20240409_V00.cdf
|
|
Même nomenclature pour mea2. |
|
Vérifier le nommage des PAD (pourquoi 2s, 4s, 16s et pas low, med, high) |
Données L2 de Mathias
J’ai préparé les fichiers L2 directement en utilisant la nouvelle nomenclature.
⇒ Par contre, Mathias n’a pas généré les moments pour MEA2
|
|
Nicolas> Renommer :
|
Métadonnées
Remplacement TI0 ⇒ MDP_TI
Chaque fichier CDF contient 2 (+1) variables temporelles:
-
Epoch : CDF_TT2000
Normalement centre de l’acquisition, mais pour l’instant début de l’intervalle
⇒ Nécessite connaissance durée du spin, que je ne sais pas où trouver
-
Duration : CDF_REAL4
Représente durée de l’acquisition en secondes.
Epoch.DELTA_PLUS_VAR = DurationUltérieurement, devrait être remplacé par variable delta_epoch si on date au milieu de l’acquisition
Epoch.DELTA_PLUS_VAR = delta_epoch
Epoch.DELTA_MINUS_VAR = delta_epoch-
MDP_TI: CDF_UINT4
Time index issu de la décommutation télémesure
⇒ Une des rares contraintes imposées sur le Wiki de la Jaxa
Compléter les autres métadonnées
Je vais essayer de préparer un fichier .xls pour chaque dataset, permettant de corriger/compléter les métadonnées et de corriger les skeletons CDF
Variables globales :
-
nom, type (entier, flottant, texte) et valeur
Pour chaque variable CDF :
-
nom, type et variabilité (record varying ou unique)
Puis sa liste d’attributs :
-
nom, type, valeur
⇒ on pourra compléter certaines valeurs des .xls et j’intègrerai ensuite les modifs dans les master CDF
Mise à jour chaines de traitement L0 et L1
Nous intégrons maintenant la librairie libsctimecal de la Jaxa pour la conversion MDP_TI ⇒ CDF_TT2000
-
première étape : donner une date estimée (date du jour de traitement) pour aller rechercher un indicateur dans le fichier TIMCAL fourni par la Jaxa à partir de cette date
-
chaque incrément de l’indicateur (timecal extent) correspond à une réinitialisation du timeclock du MDP (reboot ou tous les 96 jours), et entraine une nouvelle entrée dans le fichier TIMCAL
-
à partir de ce timecal_extent et de la valeur des TI dans la télémesure, la librairie permet de calculer le temps UTC
-
on peut ensuite convertir le temps UTC en CDF_TT2000 avec la cdflib NASA
|
|
La librairie Jaxa impose en entrée un TI en 1/32s (alors que nos TI sont en 1/512s) ⇒ Cela induit une perte de précision sur la datation des données (/2ms ⇒ /31.25ms) |
Fichiers de tests pré-lancement
Les divers fichiers de tests avant le lancement ne sont pas référencés dans le fichier TIMCAL de la Jaxa.
-
Pour ces journées il est nécessaire de donner l’origine des TI (temps UTC pour TI=0)
-
On date ensuite linéairement TI0 + TI * 1/512s
⇒ Nécessité de faire cohabiter les deux versions pour la datation dans les chaines
Reste à faire
Numéros de versions
Reste encore à gérer les numéros de version.
Normalement, <version> = vM.N ou :
-
M : Major number, représente numéro version du dataset (incrément si structure modifiée)
-
N : Minor number, incrémenté à chaque nouvelle livraison d’une journée donnée (pour un même M)
Il reste encore a créer un système de catalogue pour gérer ces versions (V00 pour l’instant)
Correction tables d'énergies
Correction table 0 (forcée à >= 1 par soft de bord)
Benjamin a remarqué qu’on ne changeait que l’indicateur des tables (ht_table_id)
Il faudrait corriger la valeur des tables contenues dans chaque enregistrement
⇒ il faut encore que je finalise la détection du bug
⇒ lecture des périodes ou la table 0 est utilisée dans les logs des commandes extraits des HK de MEA
Données Omni
Intégrer nouveau facteur de correction pour éviter overflow sur les comptages, intégré au soft de bord à partir d’une date données.
⇒ Voir code Emmanuel Penou
|
|
Nicolas> OK |
Problèmes divers
Renommer MDP_TI ⇒ mdp_ti
Ajouter quality_flag
Récupération des données temps réel
Lors du dernier Cruise checkout, nous n’avons pas pu récupérer les données sciences MEA1, mais uniquement MEA2
Les données sont apparues sur le serveur SIRIUS plusieurs jours après.
Apparemment, la Jaxa a pu les récupérer sur une autre serveur ou en utilisant des ports différents des ports 10000 et 20000 habituellement utilisés.
J’ai essayé d’avoir des informations auprès de Sae, mais la personne en charge à la Jaxa, Arare ne semble pas pourvoir échanger en Anglais.
⇒ toujours en attente
S’il y a de nouveaux paramètres (IP ou port) il faut demander la modification des règles du firewall de l’IRAP
Si ca devait se reproduire, ca pourrait être ennuyeux pour récupérer les données en temps réel.
