Eros Anastasis

Sous ce titre étrange, Jargon NIO, se cache en réalité une évolution importante de l’environnement ErosDb II: celui-ci devient portable grâce à la librairie Jargon, librairie Java donnant accès au serveur iRods. Le mot « NIO » dans le titre fait référence à la librairie Java d’entrées-sorties, librairie définissant une convention pour l’intégration de systèmes de fichiers extérieurs. L’intégration de la librairie Jargon à l’environnement NIO donne donc une version unifiée des fichiers iRods et des fichiers locaux, ce qui constitue une simplification importante pour le développement d’applications.

ErosDb 6.6.0 utilise cette possibilité et devient donc de ce fait utilisable sur toute plateforme supportant Java 8.

Le prix à payer réside dans la difficulté à diffuser les mots de passe d’accès à iRods et à la base de données.

Un mécanisme d’encodage des mots de passe et fichiers de configuration est donc mis en place. Ce mécanisme présente évidemment des faiblesses mais s’appuie essentiellement sur la coopération des utilisateurs.

Les kits de distribution sont disponibles à l’onglet Distribution du site web ErosDb (http://eros.lal.in2p3.fr/ErosDB/) et les procédures d’installation et de configuration à l’onglet Configuration.

En comparant la liste des suivis et des références référencés dans la base de données pour la production P5 et les fichiers effectivement présents dans iRods, il apparait une différence de:

• 43 références manquantes
• 3 092 suivis manquants

Malheureusement, lors de la production P5, la mise à jour de la base de données a été incomplète, et il est difficile de savoir ce qui s’est réellement passé alors.

Toutefois, il existe assez d’information pour tenter quelques hypothèses.

Les références

Sur les 43 références absentes de iRods, 42 n’ont aucune information d’état ni de nombres d’étoiles associées dans la base de données. Normalement, la base de données devrait contenir le nombre d’étoiles détectées et la référence devrait être dans l’état « A », pour ‘associée’, signifiant l’association des étoiles des images bleues et rouges. C’est bien le cas pour les références présentes dans iRods.

Le fait qu’il n’y ait aucune information laisse penser que la production de ces références a échoué…

Par ailleurs, la base de données ne conserve aucune trace de fichier correspondant à ces références. Normalement, la base de données devrait conserver la trace des fichiers qui étaient présents dans l’ancien système HPSS, avait la grande réorganisation. C’est logique pour les 42 références non associées : les fichiers n’ont probablement pas été créés ou sauvés.

La dernière référence manquante n’était donc pas présente dans le système HPSS. Il est donc logique qu’elle ne soit pas dans iRods. Quant à savoir ce qu’il est advenu…?

Les suivis

Sur les 3 092 suivis manquants, 2 899 concernent des programmes mineurs (cp, dg, eg, um, xm), qui n’ont pas été migrés vers iRods – donc de ce point de vue, tout est « normal » (ou en tout cas logique).

Sur les 193 autres suivis, 173 n’ont pas de fichiers correspondant dans l’ancien HPSS enregistrés dans la base de données. On peut donc penser que leur production a échoué.

Les 20 fichiers restants correspondent aux deux couleurs de deux quarts de CCD : cg 624 4k et lm 051 7k, 6 blocs pour le quart CG, 4 pour le quart LMC.

Le point préoccupant est que les archives contenant ces fichiers existent dans HPSS mais qu’elles n’ont pas été correctement recopiées vers iRods.

Ces archives viennent d’être transférées vers iRods et leur migration reprend…

Les courbes de lumière SMC sont enfin disponible. Il ne reste plus d’archives de courbes de lumière à migrer et il y a autant de fichiers « time » que de d’étoiles référencées dans les catalogues ASCII.

Nos lecteurs nous écrivent

Dans un post du 14 Septembre, vous signaliez « Toutes les archives [des courbes de lumière (ndr)] ont été migrées… » mais clairement il manque les courbes de lumière du programme SMC.

Force est de constater : il n’y a que 449 508 courbes de lumière SMC dans iRods sur les quelques 4 millions attendus.

Par ailleurs, détail croustillant, deux lignes plus hauts, on lit : « Il reste donc : (…)  9 fichiers sm002 .. sm010 – à explorer ».

Surtout que le 18 Juillet, un précédent post précisé le problème et annonçait, optimiste, qu’il était facile à régler…

Difficile d’être plus incohérent – l’enthousiasme d’une belle rentrée de vacances peut-être… ?

En tout cas, voici clairement un point à traiter en priorité…

Heureusement qu’il y avait un point d’interrogation dans le titre du 14 Septembre « (et fin ?) ». On n’est jamais trop prudent.

Les images compositées sont des images produites à partir d’autres images afin d’améliorer la détection des étoiles.

Plusieurs techniques ont été utilisées dans Eros. Le traitement appliqué pour la création de l’image est représenté dans le nom de l’image produite par une lettre : principalement « c » – technique initialement utilisée ; ou « x » – correspondant à un traitement différentiel (si j’ai bien tout suivi…).

Puis les images « x » – ou en tout cas certaines d’entre elles – ont été retraitées afin de les calibrer astrométriquement. Différents traitements géométriques ont été appliqués.

Le problème est que les images corrigées ont reçu le même nom que les images d’origine. D’où une inévitable confusion pour savoir qui est qui. Et l’impossibilité d’entrer ces images dans la base de données ErosDB qui rejette les doublons de nom.

La proposition est donc de changer le code des images calibrées astrométriquement et de leur affecter un nouveau code – par exemple « w », afin de rappeler le traitement réalisé grâce au logiciel IMWCS.

Cela suppose de modifier le nom des fichiers, de modifier la clé FILENAME de leur entête Fits et d’ajouter une clé HISTORY pour indiquer les modifications réalisées.

Pour mémoire, les différents codes de traitement connus (de la base de données) :

• b : 5047 références – les images brutes prises par les caméras du Marly, non réduites
• c : 14027 références – les images compositées premières générations
• f : 640 références – aucune idée …
• r : 1974701 références – les images réduites capturées par le télescope Marly
• x : 20505 références – les images compositées par traitement différentiel

Dans un post du 18 Juillet, je déclarais – optimiste – qu’il ne restait plus qu’une poignée de semaines pour finir la migration des courbes de lumière. C’était sans compter avec les soubresauts du CC et les interruptions liées au climat.

C’est passé et les courbes de lumières ASCII Eros 2 sont disponibles.

Il reste cependant différentes archives issues du HPSS qui n’ont pas été traitées. Ces fichiers portent des noms non reconnus des programmes de migration. Il faut donc analyser individuellement chacune de ces archives afin de pouvoir les traiter.

Il faut aussi définir la suite des opérations, et les priorités…

Continuer la lecture →

Les migrations se poursuivent donc.

3 cas distincts. Les « petits » programmes, Bs, Gn, Gs et Tm, d’une dizaine de champs ou moins, sont migrés.

Les « gros » programmes, Cg et Lmc, sont en cours. 70 champs pour chaque programme sont encore à transférer. A raison de 6 migrations par jour et par programme, les opérations devraient être terminées dans 10 à 12 jours.

Reste le cas SMC. Le souci est qu’il existe une incohérence entre l’archive des catalogues, cat_fields.tar, utilisée pour préparer les migrations, et l’une des archives SMC. Pour être plus précis, les courbes de lumière, et le catalogue correspondant, de l’un des quarts de CCD, sm0020m, ne semblent pas avoir été créés avec les autres. L’index de l’archive sm002.tar montrent une différence de deux mois entre l’archive des courbes de lumière de sm0020m et les autres sm002. Manque de chance, la correction n’a été réalisée qu’une semaine après la construction de l’archive des catalogues…

En pratique, ce n’est pas un souci, juste une complication. Il va falloir enregistrer le catalogue manquant avant de relancer les opérations SMC. Fort heureusement, il n’y a que 9 champs SMC. Le rattrapage devrait donc se faire assez vite.

Le Centre de calcul a rencontré différentes difficultés avec iRods. D’une part l’actuel serveur utilisé par Eros, partagé avec d’autres groupes, a saturé du fait d’une utilisation inappropriée par un autre groupe ; et d’autre part, les nouveaux serveurs destinés à le suppléer connaissaient des problèmes de performances. La migration des courbes de lumière a donc dû être différée.

Mais maintenant, ça y est. Les 6 champs BS, utilisé à titre de cobaye, ont été migrés dans la nuit.

Les migrations peuvent donc se poursuivre, à un rythme un peu plus soutenu puisqu’il est possible de traiter les 6 programmes restant simultanément (CG, GS, GN, LMC, SMC, TM).

Continuer la lecture →

Jusqu’à récemment, l’accès direct via iRods aux fichiers d’une archive Tar ne fonctionnait pas pour les archives Eros – trop volumineuses, trop de fichiers.

J’ai donc étudié des solutions de placement des courbes de lumière directement dans des répertoires iRods. Le CC nous avait donné son accord.

La difficulté résidait dans le nombre de fichiers associés à un quart de CCD : plus de 20 milles dans de nombreux cas. Cela aurait très certainement perturbé le fonctionnement des serveurs.

Plusieurs découpages étaient possibles : par lots arbitraires, par lots basés sur les indexes des étoiles référencées dans les catalogues, en fonction de la géométrie des caméras, …

L’une des pistes intéressantes car correspondant à la logique adoptée par l’expérience était le découpage en seizièmes de CCD – prévu dès les origines. Cela consistait à découper les CCD en 16 (voir Codes des sous images [voir aussi note ci-dessous]). La solution naturelle était donc de découper chaque quart de CCD en 4.

En toute logique, cela faisait encore plus de 6 000 fichiers par répertoire pour les champs les plus saturés, mais c’était peut-être jouable.

Expérimentalement, le résultat fut désastreux ! Bien sûr, tout ceci a été tenté en simulation, mais certains répertoires semblaient vides alors que d’autres saturaient…

Après avoir débuggé, il apparaissait nettement que le problème n’était pas dans l’algorithme de placement.

Il restait donc plus qu’à remonter aux données…

Les images bs300.jpg et bs303.jpg montrent une représentation graphique du placement des quarts de CCD de deux champs particulièrement atteints.

• le quart 2K de BS300 est clairement décalé vers la gauche et est complétement « hors champ »
  • les zones bleues en arrière-plan montrent les emplacements « logique » des CCD
• le champ 3L de BS300 à lui aussi glissé à gauche et chevauche le 2N
• les champs 0N et 6N de BS303 ont eux aussi glissés à gauche et empiètent sur leurs voisins
• des quarts de CCD sont absents, ou fortement réduits

L’image sm001.jpg montre un champ où l’un des quarts de CCD fait défaut.

Un sondage rapide sur quelques champs pris au hasard des différents programmes montre:

• que BS semble seul être affecté par ce problème de quarts de CCD baladeurs (6 champs)
• que CD et LM ne semblent pas affectés – leurs quarts sont présents et bien placés
• que SM présentent des quarts absents –le 7N – mais que les autres quarts sont bien équilibrés
• que GN, GS et TM présentent des quarts manquants ou réduits

Mais il ne s’agit que d’un sondage sur une quinzaine de champs…

Situation

Suite à une discussion avec Marc, j’ai exploré un peu plus le cas du champ BS3002N.

1.  L’archive regroupant les courbes de lumière d’un quart contient le catalogue des étoiles de ce quart.
   • Ce catalogue est dupliqué dans une archive contenant tous les catalogues et tous les fichiers field.
   •  Le catalogue des archives des courbes de lumière est identique au catalogue de l’archive générale.
     •  il n’y a donc pas eu une confusion lors de la sauvegarde des catalogues…
2. L’exploration du catalogue du quart de CCD à problème BS 300 2N confirme les valeurs enregistrées dans le fichier field.
   • Il n’y a donc pas eu d’erreur lors de la construction du fichier field…

Une hypothèse

Il pourrait y a eu une confusion lors du calage des images de références des champs du programme BS.

Si c’est bien le cas, il s’agirait donc que d’effectuer une correction sur les alphas/deltas des étoiles des quarts affectés.

Soit la martingale est simple, il est facile de traiter le cas à Lyon, à condition de connaitre tous les quarts affectés, soit cela suppose un « certain doigté » et il faudra me fournir les catalogues corrigés que je sauverais en remplacement de ceux en erreur.

A faire

• Explorer les différents champs et chercher les situations où il y a recouvrement des quarts de CCD.
• Vérifier dans les fichiers catalogues si les informations contenues dans les fichiers fields sont valides.
• Voir s’il est possible de reconstruire les courbes de lumière à partir des suivis.
• Vérifier les images de référence ayant servies à construire piloter les productions.
• Il serait aussi précieux de pouvoir revenir aux fichiers de référence issus de ces images de référence.

Note sur les quarts de CCD

Le découpage présenté correspond aux propositions faites à l’origine d’Eros. Pour des raisons mystérieuses, le choix finalement adopté fut une organisation verticale :

K  M
L  N

…

Les points abordés :

• Fichiers manquants
• Courbes de lumière

Fichiers manquants

Lors de la migration, il est apparu qu’il manquait des fichiers, tout particulièrement des images et des fichiers de suivis. Cette détection a été rendue possible par l’enregistrement des fichiers dans la base de données.

Ces images et ces suivis sont-ils disponibles par ailleurs ? Est-il possible de les récupérer ?

• Dresser et publier la liste des images et des suivis manquants.

Les courbes de lumière ne sont pas référencées dans la base de données, mais il existe deux sources des catalogues, référençant les étoiles, et donc les fichiers. Si des archives sont manquantes, il serait possible de le détecter en comparant le contenu des catalogues aux fichiers disponibles.

Par ailleurs, les suivis et les références résultants des productions sont enregistrés dans la base de données. On peut donc comparer ces différentes listes afin de détecter d’éventuelles absences.

Courbes de lumière

La migration des courbes de lumière s’est heurtée jusqu’ici à une difficulté dans l’organisation de ces fichiers du fait du TRES GRAND NOMBRE de fichiers par quart de CCD : fréquemment plus de 20 milles.

Situation

Il y a près de 90 millions de fichiers courbes de lumière. Actuellement, ces fichiers sont conservés sous une forme GZippée dans des archives Tar organisées par quart de CCD, archives elles-mêmes GZippées et regroupées dans des archives Tar par champ.

Cette organisation a vraisemblablement été adoptée de manière à créer des fichiers de dimensions compatibles avec les contraintes des cartouches du HPSS.

• un fichier courbe de lumière, nommé « .time », fait environ 15 à 20 K
  • sous forme compressée par GZip, sa taille est de 3 à 5 K
• une archive Tar d’un quart de CCD fait environ 35 M
  • la compression ne sert à rien puisque les fichiers contenus sont déjà gzippés
• une archive Tar d’un champ, contenant l’ensemble des courbes de lumière gzippées des 32 quarts de CCD fait de 1.5 à 2 G (donc 4 fois plus si on gunzip).

Une partie au moins des contraintes originelles sont levées grâce à iRods. Il est donc désormais possible d’adopter une organisation plus confortable pour les utilisateurs.

LA QUESTION EST DE DEFINIR LE MODELE D’UTILISATION DES DONNEES !

Cas 1 : accès individuel aux courbes de lumière

C’est typiquement le cas où on recherche les quelques étoiles autour d’un point donné. L’accès aux identifiants de ces étoiles se fait grâce à l’outil de recherche utilisant les alphas/deltas et les catalogues enregistrés dans la base de données. De ces identifiants, on identifie les fichiers courbes de lumière.

Le transfert de ces fichiers est plus simple et plus rapide si les courbes sont conservées individuellement dans iRods.

Le Centre de calcul a donné son accord pour une telle organisation.

Cas 2 : traitement massif des données

Dans ce cas, il est sans doute plus efficace de transférer massivement tous les fichiers correspondant à un quart de CCD. Un regroupement par archives Tar, éventuellement comprimées, peut être ce qu’il y a de plus efficace.

Le souci est que cette organisation est incompatible avec le cas 1. Pour accéder individuellement aux courbes de lumière, il faut transférer les archives et en extraire les courbes de lumière ensuite.

Solution mixte

EN PRINCIPE, iRods peut concilier les deux organisations en permettant d’indexer directement le contenu des archives Tar. Les fichiers sont vus comme des fichiers individuels, mais restent dans l’archive Tar.

L’avantage est donc qu’il est possible d’accéder directement aux courbes de lumière sans avoir à dupliquer le volume des données.

MAIS jusqu’ici, cette possibilité ne fonctionnait pas avec les archives Eros : trop volumineuses, trop de fichiers.

Le CC NOUS PROMET que cela marche avec la dernière version installée.

ATTENTION : le prix à payer est que l’accès aux courbes de lumière nécessite tout de même l’accès à l’archive Tar et l’extraction des fichiers. Mais ceci est fait sur le serveur. Il n’y a donc pas de transfert sur le réseau. Le temps nécessaire à l’opération doit donc être réduit.

Mais si l’archive est dans le robot, il faut le temps de monter la cartouche et transférer le fichier sur disque. Il peut donc y avoir des délais.

Proposition

• Vérifier si l’accès aux fichiers des archives Tar Eros dans leur format compressé fonctionne.
• Si cela fonctionne, utiliser cette possibilité pour placer les archives contenant les courbes de lumière dans iRods et indexer individuellement chacun des fichiers.
  • Il faudra toutefois vérifier avec le CC s’il y a des contraintes sur le nombre d’éléments par pseudo-répertoires.

Il ne semble pas souhaitable de conserver l’organisation à deux niveaux d’archives Tar, ni d’avoir des archives comprimées de fichiers comprimés.

SI L’INDEXATION DIRECTE des fichiers dans une archive Tar fonctionne bien, on peut envisager de conserver la structure en archive Tar par quart de CCD. Il pourrait dans ce cas être intéressant de comprimer les archives Tar SI IRODS LE SUPPORTE et d’avoir les courbes de lumière non compressées. Ceci permettrait de les extraire directement sans avoir à les décompresser à l’arrivé.

Plan de migration

• Descendre les archives Tar de l’espace HPSS par champ
• Extraire les archives comprimées des courbes de lumière par quart de CCD
• Extraire de ces archives les courbes de lumière compressées
• Décomprimer ces courbes de lumière
• Reconstruire l’archive du quart de CCD contenant désormais les courbes non comprimées
• Compresser l’archive
• La sauver dans iRods
• Indexer dans iRods les courbes de lumière contenu dans l’archive

L’intérêt du CC est qu’il est possible de traiter les différents programmes simultanément.