Minutes of the SNAP meeting 12-13 April 2007 at MPE, Garching ------------------------------------------------------------- 12 April: Start at 9:45 Present: Franck Le Petit (FLP), Mireille Louys (ML), Igor Chilingarian (IC), Sebastien Derriere (SD), Norman Gray (NG), Kim Jai Won (KJW), Claudio Gheller (CG), Ugo Becciani (UB), Miguel Cervino (MC), Herve Wozniak (HW), Gerard Lemson (GL), Patricia Manzato (PM) Presentation of participant [ALL] [GL]: welcome, agenda, summary of previous efforts, list of discussion items: - name of protocol - what kind of simulations/services IC: example of Horizon spectrophotometrically calibrated simulation. SNAP can be used to retrieve some properties needed to compute the calibration on the fly. CG: definition of simulation accesssible by SNAP could be there exists any transform allowing to convert a physical coordinate into a spatial one MC: a implicit feature of SNAP is that space must connected NG: another one is snapshot only (one at a time) [GL]: simulation data model Summary: ------- - should be able to discover . related data (as thumbnails, other datasets) . related non-standard services - use cases for the discovery of simulations - protocole (snap) deals with 3D spatial simulations - other standard SNAP services - density calculation on grid (i.e. gridding) - - characterization . center of mass (or reference value) . higher moments . initial conditions - units . waiting for SD's IVOA note (Semantics WG). need standardization? . comoving coordinates - query protocol: be explicit . no NULL in POS and SIZE . BOUNDARY superseeded . if query exceeds the size of the box and PERIODIC, then message is issued - what is included in a BOX: . all elements that have an influence on properties in the box . or simpler (e.g. SPH only if center in the box) . what are service providers able/willing to provide ? - how to identify RESOURCES . NG: HTTP all the way . alternative: DATASOURCE='...' . we will follow DAL and GRiD WebService WG - data format: should follow MIME-type - thumbnails: propose . random subset (particles) . coarse sampling (AMR) . gridding (particles) (total mass, average temperature...) all the three produce 3D files . projection onto 2D grid (N-body, mesh) . movies (to be kept but similar to multiple projection images) . catalogue of objects (could be tricky to handle) - need to gather use cases => survey astronomers . use case for SNAP on wiki page 13 April Start at 9:50 Present: Franck Le Petit (FLP), Mireille Louys (ML), Igor Chilingarian (IC), Sebastien Derriere (SD), Norman Gray (NG), Kim Jai Won (KJW), Claudio Gheller (CG), Ugo Becciani (UB), Miguel Cervino (MC) GL: use of SNAP model hierarchical implementation of SNAP query model multiple http get vs ADQL queries in one step we need examples of queries SNAPexperiment.goals.label="galaxy:cluster" proposal: we base utype on our logical model. We allow people to post or get output return is linked to potentially interesting simulations have to define root elements (e.g. SNAPexperiment?) definitely need ontology AI: have to find volunteers to try an implementation (UB in Italy, IC+HW on horizon databases, others?) implementation of browser and/or direct query (possibly translate in xpath) NG: RDF representation of our schema UB+CG: web implementation onto italian repository (client+archive) IC+HW: same on Horizon databases ADQL implementation as well CG: SNAP results support scalar and array (list) of scalar but not vector little/big endian, IEEE 754 floating point representatoin: should follow VO-table (and then FITS) standard potential problems with AMR storage; AMR code holders must have a look to this issue utype in SNAP VOTable? regular meshes: can uses FITS amr and particles: to be investigated arraysize= in each unit: to be normalized Afternoon ========= CG: stagging GL what's append if no stagging ML: If two types of output parameters may be issued, e.g. a data set if the code is finished and run well , a message if not, then the validation of chains of codes (such as workflows) becomes more complex: need to check various types of output parameters. GL: Registry 1/ SNAP archive / registry . browser . ADQL . "simple" (utype=value, http...) each of this could be registred independantly or could we have one service with three flavors? . registration 2/ SNAP cutout service and others possibile standard service 3/ custom SNAP services 4/ simulation dataset archives also registred? or always through 1/ GL: path forward Todo list: - logical model should be worked out further (Action:CG,PM,IC,Alessandro Costa - catania,ML,GL) DL: 1 w before Beijing - telecon or visio) . serialization: xml schema (registration), relational model(ADQL), RDF mapping (Action:NG) - validation of the logical model: map concrete data models (action: INAF - PM, Horizon - HW,IC,Jean-Paul Lefevre, MPA - GL, P. Teuben, more... alternatives: FLP, ML) DL: Beijing meeting mai 07 for PM, HZ+IC+Jean-Paul Lefevre, GL) - "simple" http query syntax: define (action: IC,ML,NG,CG,GL + FLP & Marie-Lise Dubernet) - "browsing": implementations (action: UB = organizer, HW for Horizon; tester: MC and all DL: Cambridge INTEROP, sept 07) Action GL: . contact national representative + poll community DL: after Beijing interop . feedback from national representative before Cambridge INTEROP . email about SNAP name GL: SNAP issues - what kind of data snap supports ? 3D cartesian "real" space - lower dim needed ? - thumbnail section to be updated. investigated what could be useful from community and users (action: INAF, Horizon) - snap action: to be properly defined (CG, NG, GL) - http vs datasource/service (linked to logical model somehow) (action: CG, NG, GL) - AMR storage description (Enzo, Flash, Ramses to be looked in) (action: HW + Dave Zurek) - VOTable: how ot bring in the coordinate system; be more compliant; propose improvment for hierarchical data Should involve Francois Oschenbein + CG Documents to provide - updating SNAP document (Action: CG,Laurie Shaw,HW,GL,FLP,IC) - keep two documents. will include the discovery part of model in section 3 of SNAP (action: GL)