Réunion Mensuelle du groupe Calibrateurs du JMMC - Septembre 2012

Date fixée au 10/09/2012 de 14h à 16h.

Ordre du jour

Participants

Membre du groupe	Présent
AlainChelli
DanielBonneau
DenisMourard
GillesDuvert
GuillaumeMella
HerveBeust
JeanBaptisteLeBouquin
LaurentBourges
OlivierChesneau
SylvainLafrasse
XavierDelfosse

Constitution Groupe Calibrateur

• Jean-Baptiste Le Bouquin rejoint le groupe.
• Denis Mourard quitte le groupe.
• Pierre Cruzalèbes ne veut plus être Co-I à Nice.
• Xavier Delfosse est pris par SPIROU, mais continue son activité d'expertise (irremplaçable!) au sein du groupe.

BadCal

Activité en nette augmentation.

L'utilisation des 'essential notes' dans SIMBAD marche bien, mais n'est pas applicable pour toute les cibles, seules celles dont la binarité est inconnue ou suspectée auparavant. Inclure le catalogue de Eggleton et al. 2008 (J/MNRAS/389/869, 4500 cibles), Eker et al. 2008 (V/128/names, 409 cibles) dans SearchCal ?

%ACTION{ closed="2013-01-10" closer="Main.LaurentBourges" created="2012-09-13" creator="Main.GuillaumeMella" due="" state="closed" uid="001862" who="Main.OlivierChesneau" }% Faire un rappel OLBIN. %ACTION{ closed="2013-01-10" closer="" created="2012-09-13" creator="Main.GuillaumeMella" due="" notify="" state="closed" uid="001863" who="Main.GroupeTechnique" }% <<EOF Cross-match avec Eggleton/Eker/ JSDC à vérifier.

JB a jeter un premier coup d'oeil vis a vis de badcal cf mail du 13/09/2012

CrossMatch vis a vis du jsdc version beta sep2012 (42671 entrées):

Eggleton (4713 entrées): xmatch_jsdcSep2012Beta_Eggleton.fits : crossmatch version preliminaire sep2012 jsdc / eggleton (2492 étoiles commmunes)

• Eker (409 entrées): xmatch_jsdcSep2012Beta_Eker.fits: crossmatch version preliminaire sep2012 jsdc / eker (63 étoiles commmunes)

EOF

GetStar

La demande de mettre en ligne l'outil est présente puisqu'il est utile pour la préparation de proposal. Avant de mettre en ligne une version publique, il faut rédiger la spécification. Il faut au moins clarifier l'aspect scenario vis à vis de ceux de SearchCal ( GetStar a souvent été utilisé pour dire que SearchCal aurait dû trouver une étoile, mais n'étant pas rigoureusement identique, le diagnostic n'est pas immédiat). Quelle forme donner à GetStar: service web (un navigateur suffit) ou application autonome (ou l'on peut faire plus de chose)?

--+++ GillesDuvert - 13 Sep 2012 - pour un début de document de spec, quelques remarques:

1. la spec de GetStar se résume en 2 lignes: A) c'est les mêmes specs que SearchCal sauf qu'on montre aussi les objets retournés avec DIAM_FLAG=NO; et B) c'est par ailleurs un scénario BrightK avec une recherche de type 'radius' où radius=1 seconde d'arc.
2. Le scénario utilisé par GetStar est celui de BrightK pour l'instant mais bénéficiera des évolutions de SearchCal qui vont permettre de fusionner les méthodes bright et faint.
3. Comme l'utilisateur ne peut admettre que GetStar ne retourne pas des résultats pour les étoiles les plus connues du ciel, donc qui souvent ont des mouvements propres importants, il faut attendre que le cross-match de SearchCal soit amélioré pour tenir compte des mouvements propres.
4. L'interface Web basique, comparable à celle d'une interrogation de catalogue de Vizier, est suffisante.

%ACTION{ closed="2013-01-10" closer="Main.LaurentBourges" created="2012-09-13" creator="Main.GuillaumeMella" due="" state="closed" uid="001864" who="Main.OlivierChesneau" }% Ecrire un document de Spec. Document vierge créé https://svn.jmmc.fr/jmmc-doc/trunk/JMMC-SPE-2600-0004/

Activité JSDC

Le JSDC couvre bien les instruments existant.

La base de la V2 est déjà opérationnelle depuis longtemps. Reste à documenter/finaliser/valider les dernières étapes de filtrages pour supprimer les objets multiples (TDSC, WDS, Simbad...).

On fait un release du JSDC (avec cross-match pas encore parfais mais amélioré). Gilles confirme que la version fast de construction est la bonne puisqu'elle part d'un catalogue initial de bons candidats ( parallaxe ) et évite les doublons causés par le mosaicing.

%ACTION{ closed="2012-09-17" closer="" created="2012-09-13" creator="Main.GuillaumeMella" due="" notify="" state="closed" uid="001865" who="Main.GroupeTechnique" }% <<EOF Créer le readme sous twiki. cf: JMMCSearchCalCDSCatalogReadme EOF %ACTION{ closed="2013-01-10" closer="Main.LaurentBourges" created="2012-09-13" creator="Main.GuillaumeMella" due="" state="closed" uid="001866" who="Main.OlivierChesneau" }% faire un release et contacter le CDS. Dire que l'autre catalogue est obsolète.

Collaboration ESO

Pas d'échanges, on suppose que la situation est satisfaisante côté ESO.

Activités SearchCal

Activité de Jean-Baptiste:

Jean-Baptise a rédigé un doc de spec AS-BUILT lors de son étude croisée entre documents et implémentations:

• La cohérence est assez bonne.
• Problème sur le code, car la complexité est grande. Repartir de zéro?
  • Opinion de JB: nettoyage, et simplification. Historique: ajout du cas faint après le bright. Deux codes imbriqués.
  • Laurent: Ne pas repartir de zéro!
• Méthode de nettoyage: réduire les différences entre les scénarios Bright et Faint. Exemple: routine de diamètre de V and K, indépendamment du scénario.
• Transition Bright/Faint: étudier les limites des parallaxes Hipparcos (Gilles proposait de s'intéresser aux parallaxes Von Leuven).
• B, V, R: Bright, I, J, K: Faint: simplifier. Choisir un système communs de bandes au cas Bright et Faint.
• Besoin d'un catalogue en R et I (problème récurrent…).
• JP11/Denis: Problème avec les R et I. Meilleures détermination de diamètre. ASCC est le dénominateur commun (et 2MASS). Découplage entre données cruciales et précises, puis données complémentaires (vérifier la validité USNO). HST Guide star catalogue.
• Problème des géantes K qui n'ont pas de parallaxe à magnitude 6.5/7. Basé sur les mouvements propres pour déterminer la classe de luminosité. Le cas bright rejete les etoiles > mag 5 sans parallaxe. Le cas faint permet de compenser et retourne suffisamment de calibrateurs, mais dans le cas ou elles ont une parallaxe les magnitudes visibles ne sont pas utilisées alors que la méthode est plus fiable/précise.

Xavier soumet l'idée que le GUI pourrait sélectionner les géantes vis a vis du mouvement propre (jusqu'à quelles magnitudes, limites en couleurs...). C'est un besoin mais qui nécessiterai une étude préalable (Xavier). Xavier propose de proposer cette étude sous forme de stage M1 par ex.

Laurent souligne que des logs scientifiques rajoutés par Jean-Baptiste sont très utiles.

Suite a une remarque sur le fait que USNO ne soit pas utilisé, Sylvain rebondit sur le fait qu'il semble pertinent et réalisable de découpler le code en plusieurs phases definition d'une liste de candidats, traitement purement SearchCal et ajout d'infos complémentaires.

Plusieurs points techniques viennent se rajouter aux aspects scientifiques. Ils peuvent être conduits de manière indépendante:

• gestion de l'action Cancel
• gestion des miroirs
• découplage dans le packaging du gui et du serveur

%ACTION{ closed="2012-09-17" closer="" created="2012-09-13" creator="Main.GuillaumeMella" due="" notify="" state="closed" uid="001867" who="Main.GroupeTechnique" }% <<EOF JB propose de modifier le cas de test en faint ( en 0:0 ) en mettant des rayons de recherches identiques (permet ainsi le crossmatch) Fait dans le tronc EOF

CrossMatch

Laurent rappel que les mouvements propres ne sont pas encore utilisée pour faire de meilleurs crossmatch (a voir aussi avec la gestion de l'epoch...)

Olivier rappel le fait qu'il existe un HST Guide star catalogue qui dispose de coordonnées précises.

Prochaine réunion

Visio conf prévue d'ici la fin de l'année.

Actions

Récapitulatif des actions (ouvertes) %ACTIONSEARCH{ topic=Jmmc.JmmcSearchCalActionList?.* state="open" }%

Un template de compte-rendu est aussi fourni pour en faciliter la rédaction.

Anniversaire

On approche des 10 ans d'anniversaire de SearchCal !!