Minutes Telecon SWG ANR COMPASS 14 Janvier 2014 10h-11h15 ------------------------------------------------------------------------- Presents: DG YC (LESIA) CV (IPAG) BE (LAM) MP (GEPI) Excuse: GR (LESIA) BN (LAM) ------------------------------------------------------------------------- ODJ: (1) Participation de Benoit Neichel au SWG COMPASS (2) Discussion sur les specs SCAO, LTAO, MOAO, MCAO, XAO (3) Etat d'avancement des travaux en cours dans les differents labo (4) Points divers Liste des actions en cours: A8 (rappel): Collecter fiche de simulation pop. stellaire (GEPI) -> MP, asap A22: Remplir la colonne MOAO des specs de simu OA -> DG, 15/12/13 OVERDUE A24: Identifier les modules OA manquants a partir des specs -> DG + YC A26: Envoyer corrections pour site web/wiki a DG -> tous A27: identifier les moduels XAO manquants dans les codes IPAG -> CV A28: specifier l'indexation des PSF dans la BdD -> MP+infoGEPI+DG A29: ouvrir des comptes pour le SWG sur le simulateur EAGLE -> MP, asap ------------------------------------------------------------------------- (1) Participation de Benoit Neichel (BN) au SWG COMPASS BN a accepte de faire partie du SWG COMPASS et a ete ajoute a liste de diffusion. BN est interesse par les science cases (SC) "Imagerie a haute resolution/morphologie des galaxies distantes", "spectroscopie 3D des galaxies distantes" et "populations stellaires", ainsi que dans les developpements MCAO. BN souhaite limiter sa participation en raison de son implication dans sa propre ANR. BE annonce qu'il sera absent 6 mois a partir de debut mars. L'arrivee de BN permettra egalement de continuer a representer le LAM au SWG en l'absence de BE. (2) Discussion sur les specs SCAO, LTAO, MOAO, MCAO, XAO Nous disposons desormais d'un premier jet de specifications pour les simulations des systemes SCAO, LTAO, MCAO, et XAO (voir fichiers excel joint). Les systemes MOAO doivent encore etre completes (cf. A22). Pour memoire, ces specifications doivent decrire les besoins amonts en termes de simulations. Il faut donc indiquer plutot des intervals de variation attendus plutot que des valeurs typiques. Discusions sur les specifications: la partie laser LTAO est largement inspiree de la partie MCAO et d'Atlas. Une nouvelle ligne sur le nombre de cycles d'integration a ete ajoutee. En XAO, la necessite specifique d'avoir des amplitudes complexes a ete egalement ajoutee. De maniere generale, la ficher excel semble repondre au besoin des differents systemes. La table comporte un grand nombre de "TBC" qui ont vocation a etre precises au fur et a mesure. Pour memoire, ces specifications doivent servir a identifier les modules de simulation manquants. Ce travail sera mene par DG et YC (cf. A24, et par CV pour la partie XAO en comparaison avec les modules existants sur les codes existants a l'IPAG via l'heritage SPHERE, cf A27). Ce travail permettra egalement d'identifier les specifications dont le TBC est critique et doit etre precise rapidement. (3) Etat d'avancement des travaux en cours dans les differents labo Des premieres reflexions ont ete initiees sur certains cas scientifiques et comment les simuler: Developpements du simulateur instrumental (GEPI): plusieurs reunions ont eu lieu avec les informaticiens du GEPI afin de discuter des specifications et sur la maniere la plus efficace de mener les developpements. Ceux-ci se feront par strates successives: compte utilisateur + systeme d'ouverture de compte + BdD associee > formulaire de definition de simulation + BdD associee > navigation web selon le profil d'utilisateur > BdD de PSF + outil de navigation dans la BdD > script de commande pour le code de simulation et interfacage avec le code IDL et la BdD de PSF > BdD de produits de simulations + outil de navigation > generation d'email a l'utilisateur + gestion des fichiers produits. Plusieurs environnements de developpements ont ete testes et leurs avantages/inconveniants compares aux specifications; Joomla a ete retenu. Les developpements proprement dit vont maintenant demarrer. Du cote du code de simulation, le code est en cours d'optimisation pour etre couple efficacement a l'interface web. Un modele de fond de ciel+thermique plus precis et necessaire aux SC demandes va etre developpe et integre par Yanbin Yang (postdoc COMPASS au GEPI). Simulations AGN (LESIA+GEPI): trois reunions impliquants DG, YC, YY et MP ont permis d'initier des premieres simulations sur le cas AGN. Le but est de caracteriser quelles structures seront identifiables dans des AGN locaux et a plus grand z. Un point important concerne la modelisation des sources a z=0 pour lesquelles il faudra recourir a un model par manque de donnees a resolution spatiale suffisante, ce qui sera probablement le cas de tout les SC incluant des sources tres proches. Pour ce type de SC, il apparait egalement utile de ne simuler qu'un champ restreint autour de la structure a detecter. Ce SC permettra d'essuyer les platres dans le couplage OA + modele d'sintrument. Simulations Morphologie des galaxies distantes (LAM+GEPI): la fiche de simulation a ete mise a jour avec des contraintes plus precises sur la LTAO et la MCAO. La question de comment interfacer les sorties de simulations hydrodynamiques a haute resolution avec le simulateur instrumental se pose. A l'IPAG, une premiere reflexion sur les algo de simulation pour la pyramide a ete faite. Il apparait necessaire de trouver le bon compromis precision vs. rapidite. Une reflexion a egalement demarre sur le WP modelisation. Il apparait clair que celui-ci doit inclure la pyramide et le M4 mais la question est posee d'inclure ou non d'autres items comme la pupille de l'E-ELT et les coronographes. Il est propose de garder ces items pour plus tard au niveau de l'integration mais il est important dans les garder en tete tout au long du projet dans le cadre de la reflexion generale car ceux-ci peuvent impacter un certain nombre de specifications. Ces discussions font emerger quelques points sensibles au niveau des interfaces entre le simulateur OA et la simulateur instrumental: -stockage des PSF: certains cas necessitent d'echantillonner temporellement la PSF et de ne pas utiliser de PSF "moyenne". Les premiers essais ont montre que les cubes de PSF obtenus font dans les 25 Go d'espace disque. Ce type de simulations prend environ 20 hr et il apparait donc difficile de les repeter systematiquement a la demande. Il faudra donc trouver un compromis entre stockage (qui ne pourra pas etre completement exhaustif vu la taille des fichiers) et temps de calcul. Il apparait necessaire d'echantillonner la PSF temporellement uniquement dans les cas ou un effet dependant de la PSF ou un effet non-lineaire vient alterer les donnees entre chaque PSF (typiquement le cas de la haute dynamique). A l'oppose les SC extragalactiques ne necessitent pas de tenir compte de cet effet (une PSF moyenne suffit). L'ideal pourrait donc etre pour les cas concernes d'etablir une grille pre-etablie de cubes de PSF permettant de couvrir la plupart des situations d'interet pour limiter les demandes specifiques qui seront donc couteuses en temps de calcul et espace disque. -IHM (interface homme/machine): il faudra bien guider l'utilisateur dans la selection des scenes astro pour eviter d'avoir a realiser des simulations inutilement couteuses en temps de calcul et en espace disque. Dans le cas des simulations MICADO/AGN, il apparait par exemple inutile de systematiquement simuler le champ complet de MICADO. Il suffit de simuler une zone limitee autour de la structure d'interet. Les effets de variation spatiale de la PSF peuvent facilement etre reproduit en variant la PSF sur une scene astro constante (ou non) et de taille limitee. Dans le cas d'objets a plus grand redshifts, des donnees a haute resolution d'objets plus proches peuvent etre redshiftees pour simuler une scene plus complete. Il faudra donc guider l'utilisateur de maniere adequate par exemple via un systeme de menus: Galaxies > AGN > z=0 > SuperStarCluster / Spiral Arm / Torus / etc. ou Galaxies > AGN > z=? > CentralRegionOfNGC7469. Le meme type de systeme de navigation sera necessaire dans la base de donnees de PSF: un utilisateur de type "astro" devra etre guide vers des PSF typiques facilement, par exemple: MICADO > SCAO > MagNGS=13/14/15/16/17 > OffAxisDistNGS=0/0.5/1/1.5/2 arcmin. A l'oppose un utilisateur de type "super-expert" devra avoir la liberte de demander une PSF n'existant pas dans la BdD via un formulaire ou il devra renseigner l'ensemble des parametres necessaires a une simulation OA sur GPU (cf. specs des systemes OA). Ce formulaire sera envoye par email automatiquement aux responsables des simulations OA/GPU. Dans un deuxieme temps, on peut imaginer d'automatiser le lancement des simulations sur le pipeline GPU. La PSF generee sera ensuite integree a la BdD (manuellement dans un premier temps, automatiquement par la suite). -base de donnees PSF: pour permettre une bonne navigation dans la BdD, il sera necessaire de garder un maximum d'information dans les headers. Tous les parametres d'entree de la simulation OA devront etre conserves. Un numero de simulation GPU/OA incremental unique sera egalement conserve dans le header. Il pourrait egalement etre necessaire de definir un systeme d'indexation plus avance pour les PSF produites en serie pour un cas scientifique donne. Par exemple un jeu de PSF SCAO pour le cas AGN ou l'on fait seulement varier la magnitude de la NGS. Ceci pourrait permettre de relier plusieurs PSF ensembles dans la BdD et avoir une navigation plus intelligente du point de vue de l'utilisateur final. Une premiere reflexion sur la maniere d'indexer les PSF doit etre lancee des a present en lien avec les informations qui developperont cette BdD et les developpeur du pipeline GPU/OA (A28). (4) Points divers -Prochaine echance ANR: mid-term review en juin. Il faudra faire un resume des travaux en cours. Par rapport au planning de depart, il faudra faire attention a faire progresser suffisamment les "preparatory studies" (premiers tests du simulateur instrumental). Or il sera difficile de presenter un prototype entierement fonctionnel relativement tot dans le projet due a la facon dont le simulateur est developpe (voir plus haut). Afin de permettre malgre tout de faire progresser la reflexion sur les interfaces avec le simulateur OA, il est decide d'ouvrir des comptes pour le SWG sur le simulateur EAGLE/spectro 3D existant (cf. A29). Meme si l'interface finale sera differente, ceci permettra au SWG de pouvoir reflechir sur les problemes de fond, de l'IHM et des interfaces avec l'OA. -Rappel de la liste des actions en en-tete. -Prochaine teleconf le 18/03/2014 a 10h. Points a aborder: simulations AGN en cours, discussions sur l'interface du simulateur instrumental. -------------------------------------------------------------------------