Chers tous Voici le resume des activites de la periode du 19 juin au 3 juillet 2008. Alertez moi s'il manque des points que vous jugez importants. Le Tera- meeting est prevu jeudi 3 juillet a: 14:30, salle 281 Amicalement Yannick {{ATTENTION: la numerotation des images du CFHT est sur le point d'atteindre 999999 . Pensez a verifier que la lecture d'un digit supplementaire ne posera pas de probleme aux logiciels, scripts, etc...}} {{I. Processing T0005: Yannick, Fred}} Fred et Yannick ont mis en place les donnees CFHTLS Deep sur les disques de mix13. Il s'agit de 9000 images environ. Yannick s'est occupe d'inventorier et copier toutes les images Deep necessaires a T0005 et qui sont aujourd'hui localisees sur les disques mix3, mix4, mix5 et mix6. Fred a commence la reconstruction de mix3 pour permettre d'effectuer les copies des 2300 images Deep deposees sur les raid mix3 vers mix13. Fred s'est charge d'effectuer les transferts des images 2003AB et celles de 2008A du CADC vers le CFHT. Il reste donc a copier les images de mix3 et on pourra lancer les QFITS. Fred a profite de la venue de Kanoa pour regler a cette occasion des problemes de taux de transferts entre Terapix et le CFHT et accelerer ainsi le transfert des images Deep 2008A a un taux de 3Mo/sec! A noter que sur les 3036 images, une vingtaine a un CRC incorrect. Ces images doivent etre transferees de nouveau et justifient la necessite du checksum. {{II. Processing Megacam PI: Yannick, Mathias (S.)}} II.1 08AH22-Johnson/Wright Suite a une question de Johnson , il est apparu que les catalogues produits pour 08AH22-Johnson etaient composes d'une majorite de fausses detections. Yannick a investigue la raison de ces anomalies. La source du probleme est la nature du champ, compose d'un tres grand nombre d'etoiles brillantes qui perturbent fortement la structure du bruit dans les images et affectent l'estimation des seuils de detection. Cela se voit notamment sur le premier stack en bande i dont le bruit presente une structure atypique. Pour resoudre le probleme, Yannick a modifie les valeurs des seuils de detection. Les nouveaux catalogues sont conformes et ne montrent plus de fausses detections. Mathias S. a refait les catalogues multi-couleur et les plots des tracks couleur- couleur des etoiles. II.2 08AC16 08AF20 + LP-NGVS: Ferrarese, Mei Yannick a continuer la production de series de stacks pour le programme Pilot Virgo qui prefigure le Large Progam NGVS. Une des difficultes de ce projet reside dans la grande dynamique en taille et en brillance de surface des galaxies recherchees. M87 plus particulierement pose de gros problemes de soustraction de fond de ciel. Le stage de Lila devrait donc etre tres utile pour ce programme. Yannick a trouve un excellent compromis avec une mesh size de 6400 pixels (1.5 fois la plus grande longueurs des CCDs). Au-dela (e.g. 10400 pixels), on ne gagne rien. Les resultats de ces premieres analyses ont ete montres par C. Veillet (Directeur du CFHT) mardi 1er juillet au meeting de la SF2A. Les discussions au sein du groupe NGVS se poursuivent. Yannick a rencontre Paula Ferrarese au Canada vendredi dernier pour en discuter. Une reunion a eu lieu hier a la BNF avec J.-C. Cuillandre, P.-A. Duc, E. Emsellem, P. Boissier et A. Boselli pour definir les besoins et voir comment la strategie d'observation pourrait etre optimisee. {{III. Processing PI-WIRCam (Henry, Patrick):}} Pas de progres rapporte cette semaine. {{IV. Spica2 developpement: Mathias M., Gregory}} - Gregory a rencontre Kanoa a propos des tables FITS. Kanoa va preparer des tables FITS pour chaque annee d'observation et nous les enverra des son retour au CFHT. Il a aussi ete discute la possibilite de construire des tables .log synthetiques ne contenant que l'information essentielle en une ligne pour chaque image, comme celles que Terapix utilise pour le CFHTLS. Ce point a ate aborde avec Gregory, Kanoa, Jean-Charles et Yannick. Le CFHT va voir ce qu'il peut faire, voire tenter de produire des tables identiques pour WIRCam, et etudier la possibilite d'inclure ces log dans les tables FITS de Kanoa. - Dans la partie processing de Spica, Mathias M. a ajoute un nouveau plugin 'Skeleton' . Il ne fait pas grand chose si ce n'est lancer 5 jobs /usr/bin/uptime sur le cluster. Il a ete implemente en tant que "proof of concept" pour montrer que l'architecture de l'application relative aux plugins est stable et s'appuie sur des bases solides (et documentees). Pour creer un nouveau plugin, il suffit desormais de copier-coller les fichiers squelettes de Skeleton pour avoir quelque chose d'immediatement fonctionnel, puis de modifier le code en consequence pour ajouter des fonctionnalites propres au nouveau plugin. Cela permet un gain de temps de developpement substantiel. http://clix.iap.fr:8000/spica2/processing/ (onglet 'Skeleton (DEMO)') - Greg et et Mathias M. ont commence l'implementation du plugin relatif a SExtractor qui devrait etre fonctionnel la semaine prochaine (tout au moins pour une demo). - Greg et Mathias M. ont ajoute la possibilite d'utiliser un repertoire de sortie different par plugin et par utilisateur. En effet, ce probleme avait ete souleve lors d'un precedent Tera-meeting. Jusqu'a present tous les resultats de processings etaient transferes dans un meme repertoire sur une machine du cluster. Cela presentait evidemment de gros problemes si des utilisateurs travaillaient sur les meme donnees, puis que les resutats se superposaient et les fichiers de sortie etaient ecrases au fur et a mesure. Ce n'est plus le cas, un repertoire specifique est attribute a chaque utilisateur de Spica. Par exemple, si l'on se connecte en tant que 'monnerville' et qu'un processing QualityFITS y est lance, le chemin de sortie sur le cluster utilise (c'est transparent et automatique) sera: /data/mix4/raid1/spica-DEV/monnerville/fitsin/ Dans le cas d'un processing SExtractor, ce serait: /data/mix4/raid1/spica-DEV/monnerville/sextractor/ D'une maniere plus generale, le chemin suivant est utilise: /data/mix4/raid1/spica-DEV/${LOGIN}/${PLUGIN}/ Greg et Mathias M. travaillent sur la possibilite d'ajouter depuis l'interface un nom de repertoire qui viendrait completer les chemins precedents pour offrir davantage de souplesse: /data/mix4/raid1/spica-DEV/${LOGIN}/${PLUGIN}/${CUSTOM_ITEM_DIR} Il serait ainsi possible de creer un sous-repertoire pour des donnees WIRCAM, ou un autre pour regrouper les resultats d'une release particuliere etc. Cette derniere fonctionnalite est prevue pour la semaine prochaine (BUGZILLA #58). - Beaucoup de code refactoring par Mathias M. , avec notamment l'utilisation de nouveaux objets JavaScript pour encapsuler des elements utilises a la fois au niveau du plugin QualityFITSin et SExtractor et eviter la redondance de certaines parties du code (optimise l'utilisation de la bande passante). {{V. Image Processing Software/tools (Patrick, Lila, Emmanuel, henry:}} V.1. Developpement Emmanuel's suite: - PSFEx: Emmanuel s'est mis a la documentation de PSFEx. En gros la moitie du travail a ete faite. V.2. Stage Lila: Modelisation et soustraction du fond du ciel" Les differents algorithmes sont ecrits et Lila est en phase de tests sur differents ensembles d'images. Lila n'a pas encore créé les images resultats V.3. Developpement WIRCam (Patrick): Patrick a concentre sa semaine sur le script alternatif a condor_transfer.pl. Le nouveau "package" s'appelle condorize (pas beaucoup d'imagination). Il se compose de plusieurs fichiers : condorize/condorize.py condorize/condorize_wrapper.py condorize/condorlib.py condorize/curllib.py Le principe est tres simple. On execute le script condorize avec pour argument le condor submission file original: condorize.py -s subfile.sub. Plusieurs fichiers sont crees : - un nouveau condor submission file : subfile.sub_condorize.x Ce fichier condor a les parametres suivants : - seuls deux fichiers sont tranferes par condor : le wrapper (condorize_wrapper.py) et les fichiers de configurations de ce wrapper. - l'executable est le wrapper - les seuls arguments sont les fichiers de configuration du wrapper ( -c wrapper.conf ) - des fichiers de configurations pour le wrapper (condorize_wrapper.py) qui sera envoye sur les noeuds par condor. Il suffit alors de lancer le nouveau submission file par condor : cat subfile.sub_condorize.x | condor_submit Tous les fichiers a transferer du submission file original et tous les arguments sont transferes des machines hotes par ftp (CURL) comme dans le condor_transfer.pl. L'avantage est que tous les fichiers sont transferes et pas seulement ceux de la ligne de commande du submission file (mais aussi les fichier du keyword transfer_input_files). Il est egalement possible de selectionner la cible ou seront transferes les fichiers de sortie de condor par l'intermediaire des options --outdir/--outhost du script condorize. Tous les lancements de ftp sont geres en parallele avec la librairie python processing. Cette librairie est en cours d'installation (Fred ?) sur le cluster. Patrick a realise des tests sous mon ID (installation localy de processing) mais il a besoin de l'installation globale pour effectuer les derniers tests condor. Les scripts sont sur SVN dans le repertoire condor/condorize du repository private et une documentation complete est en cours d'ecriture. Je pense que je pourrai vous montrer le fonctionnement en cours de semaine. V.4. Completness (Henry) Henry tested in detail completeness computations using STUFF, Skymaker and SExtractor. The procedure is detailed in his previous emails but the basic idea is to create a noiseless simulation image (with the same zero point as the real image) and add it to a real image from which all objects have been removed using sextractor (using checkimage_type -OBJECTS). SExtractor is run again in ASSOC mode and the output catalogue is compared to the input list used to generate the simulated image. Completeness curves can be quickly generated by comparing the histograms of matched output objects with input objects for the simulations. some points: - the input list from STUFF contains objects which have negative positions (in order to avoid edge effects); the reference sample for completeness curves must be pruned of objects outside the field of view (as these obviously cannot be found in the simulation images). - including object magnitudes and using ASSOC_TYPE MIN with the magnitude helps reduce the number of false associations with the input catalogue. - No attempt was made to fill in the 'holes' in the image left by the bright objects which have been removed. See the attached grab to Henry's email (dated 07/02/2008 07:23 PM) where distant galaxies peek through the 'holes' in the cosmic wallpaper. This could potentially increase the number of detection at the faint end. Perhaps the way to fix this would be to create a 'flag-map' from the objects and then discard any detection inside these regions? - No attempt was made either to match the number density of objects or generate the correct disk scale length distributions. Results of Henry's tests: The completeness curves for stars is close to what was obtained from the previous code (but much faster). Selecting by b/t ratio one finds around one magnitude of difference between limiting magnitudes for disk dominated systems and bulge dominated systems (bulge-dominated systems being close to stars). So it seems like that this is quite a promising technique -- perhaps to be coded up in python for an automatic pipeline? Computing a realistic full-field image can be time-consuming, but this needs to be done only once, and then can be re-used for other images. {{VI. Hardware/system/cluster (Fred):}} Condor: Les interfaces réseau de chaque noeud sont maintenant celles qui est dans le sous réseau privé du cluster (donc inaccessible depuis les machines de bureau). Le mix d'adresses publiques/en tpx.iap.fr posait problème à condor. Les tests faits par Fred, Henry et Patrick sur plusieurs milliers d'images s'averent concluant. On peut donc considerer que Condor est operationnel sur l'ensemble des machines desormais. mix11 et fcix4: pas de nouvelles d'Agorus. mix3: toujours en cours de remontage. cosmix5: cette machine subit des arrets intempestifs, sans message dans les log. Fred va tester la mémoire, et enlever une des 2 cartes RAID (celle qui est en erreur). {{VI. Divers (All):}} - David Hogg doit rencontrer Emmanuel (probablement a domicile!) aux alentours du 15 juillet, pour preparer le support d'Astrometry.net dans SCAMP. Ca ne devrait pas representer trop de travail, tout en simplifiant l'etape la plus delicate du processing (le matching!). - Sante Emmanuek: le 3eme blood patch tente a Bicetre (pourtant par un des meilleurs experts francais du sujet) semble avoir reouvert une breche durale au niveau lombaire (forts maux-de-tete positionnels)! Emmanuel est a nouveau au lit, en arret-maladie au moins jusqu'au 25 juillet... En parallele des examens sont effectues pour tenter d'identifier ce qui ressemble a une 2eme breche (sinus? cervicales?) responsable des pbs de vertige et des acouphenes. - Mathias M. a termine le document 'Writing plugins for Spica', guide pour developper de nouveaux plugins (partie processing) sous Spica2 . - Yannick s'est entretenu avec Stephane Paulin-Henriksson qui souhaite se presenter au CNAP l'an prochian avec une tache de service Terapix. Stephane est d'accord que du point de vue de Terapix cela n'a de sens que s'il s'implique concretement et rapidement dans des activites Terapix ne facon a ne pas presenter une tache de service fictive ou qui ne s'inscrirait pas dans la duree. Stephane est pret a venir un jour par semaine a Terapix pour y travailler. Nous sommes convenu d'un rendez vous mardi 9 juillet a l'IAP avec Patrick, Henry et Yannick pour definir un projet de travail. - Workshop calibration: Henry et Mathias ont assiste a l'ensemble des discussions du workshop organise a l'IAP vendredi dernier. Y etait presents notamment J.-C. Cuillandre, R. Ibata, H. Aussel, et les gens du SNLS. Mathias S. a ete sollicite par le groupe SNLS pour faire une etude de calibration pour le Deep T0004 (D2 et D3 ou il y a des données SDSS). C'est en cours. Un bilan plus detaille du workshop sera fait au retour de vacances de J.-C. Cuillandre.