Minutes for the terameeting of July 22th, 2008

Present: Lila, Mathias, M., Patrick, Fred, Henry, Yannick.

Please read the summary (updated) : Yannick's summary document

Points additionnels :

I. CFHTLS Release T0005 et operations sous CONDOR:

 En lancant QFITS-out avec "-o directory1/directory2/", QFITS a cree un lien sur le lien et a detruit les images FITS du stack en cours. Yannick a du relancer la production d'un des stacks de W1 (heureusement cela s'est produit sur un CONDOR test d'un seul stack!). Fred a compris l'origine du probleme: le lancement de "mkdir directory1" est possible mais pas "mkdir directory1/directory2" . Fred va investiguer ce pb. En attendant Yannick a abandonne la commande "-o xxx" puisque de toutes facons QFITS cree automatiquement un directory par defaut construit sur "le-nom-de-l'image/qualityFITS", ce qui est parfait.

 Fred a resolu un dernier probleme rencontre par Yannick dans QFITS pour gerer les comptages de galaxies et les images cartes de PSF: Fred rappelle que le parametre de commande QFITS "-2" est indispensable pour son fonctionnement en mode QFITS-out.

 Apres ces modifs/corrections, QFITS-out fonctionne parfaitement via CONDOR.

 Concernant les incidents de SWARP via CONDOR ( "Not enough memory for multinbuf (nbuflinesmax*outwidth elements") rien n'est clair. Il est possible que cela provienne des SWARP envoyes sur des machines ne disposant pas assez d'espace disque pour faire les stack+resampling de l'ensemble des images. Fred et Mathias rappellent qu'il y a un parametre de requirement CONDOR (DiskUsage) permettant de preciser l'espace disque necessaire au job. Yannick rappelle que cela va devenir un probleme tres serieux pour les champs Deep et qu'il sera indispensable de connaitre l'espace necessaire, ou alors il faudra eviter d'utiliser CONDOR pour les Deep (2740 images D1, 1962 images D2, 2418 images D3, 2625 images D4, sans compter les cartes de poids).

 Concernant les priorites des jobs qui ont mis en Idle ceux de Yannick et mis tous ceux de Henry en Running, Henry a investigue. Il a trouve dans la doc CONDOR que les users qui sont de gros et/ou frequents utilisateurs d'un cluster sont mis en basse priorite si un jobs d'un utilisateur moins gourmant/frequent est lance.

Henry nous a envoye cette statistique:

mix10> condor_userprio -usage Last Priority Update: 7/22 23:40

Accumulated Usage Last

User Name Usage (hrs) Start Time Usage Time

hjmcc@tpx.iap.fr 338.36 6/19/2008 12:07 7/22/2008 23:40

pipeline@clic.iap.fr 5597.36 1/17/2008 21:14 7/22/2008 23:40

qui montre pourquoi pipeline fut mis en Idle lorsque hjmcc a lance ses jobs. Ci-dessous une compilation extraite de mails de Henry:

Reading the condor man pages explains why my jobs stopped the pipeline jobs.

Basically all users start out with the same priority. However, if a user uses a lot of resources, their priority drops!

mix10> condor_userprio

Last Priority Update: 7/22 22:09

Effective User Name Priority

hjmcc@tpx.iap.fr 2.07

pipeline@clic.iap.fr 16.11

Number of users shown: 2

whereas all the other users have higher default priority (0.5) because they have been using less resources!

I notice that my priority is 2.0 because of the machines I used the other day.

The idea is that all users get a fair share of the machines...

II. Outils de manipulation de base d'images:

 Fred et Patrick ont mis en place "ic", tres pratique. Mais il ne gere pas les MEF et il faudrait donc reprendre les soft construits il y a quelque temps par Emmanuel. Patrick et Gregory doivent contacter Emmanuel et s'en charger.

III. Hardware:

 Les copies des data de Goldman sur son disques sont longues: il a plus de 3.5TB de donnees et un disque de 1 TB. Fred va contacter Goldman.

 Cosmix5: toujours en panne. A renvoyer.

 Rien de neuf sur mix11, mix3 et fcix3

 Fred doit lancer les marches pour 3 machines de type fcix4.