1 / 33

GAIA Simulator Development Example A Java code for Fundamental Algo r ithms

GAIA Simulator Development Example A Java code for Fundamental Algo r ithms. An example : Fundamental Algorithms What are the Fundamental Algorithms? Parameters review and Interactions with other Simulator Parts. The GAIA Simulator structure Simulator is not GDAAS GASS GIBIS

pia
Download Presentation

GAIA Simulator Development Example A Java code for Fundamental Algo r ithms

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GAIA Simulator Development Example A Java code for Fundamental Algorithms RRFWG Meeting at Dresden

  2. An example : Fundamental Algorithms • What are the Fundamental Algorithms? • Parameters review and Interactions with other Simulator Parts • The GAIA Simulator structure • Simulator is not GDAAS • GASS • GIBIS • Common Libraries • Java language • Portability & modular structure as priorities • Speed ,Performance and Read-at-Once • Wrapping from C/C++ & Fortranto Java • Conclusions RRFWG Meeting at Dresden

  3. The GAIA Simulator structure RRFWG Meeting at Dresden

  4. GAIA Simulator is an “independent” effort to provide the input Raw data to GDAAS contract and other development efforts. People working with the simulator spent their “scientific” time in the development of this tool. • Simulator is not GDAAS GDAAS is the ESA contract which has to solve the problem of the GAIA reduction process, giving as a final result a closed, tested package capable of reduce the 5 years mission data in a reasonable time and in a robust self-consistent way (Global Iterative solution). RRFWG Meeting at Dresden

  5. GASS GAIA System Simulator GASS is designed to simulate the telemetry stream of the GAIA mission according to the GDAAS (Gaia Data Access and Analysis Study) specifications, using models of the astronomical objects and instruments. GASS has a Grafic User Interface and must be downloaded with a compilable version of the whole simulator to run properly GIBIS GAIA Image and Basic Instrument Simulator Generates images of all sky features (stars, galaxies, nebulas, background,etc...) as seen by the intruments (at the pixel level) with the aim of develop Quick-look routines, classification, and on-board detection of all kind of objects and events. GIBIS has a web interface which allows you to send queries via internet. http://www.ast.cam.ac.uk:8080/gibis RRFWG Meeting at Dresden

  6. It is planed to release a full compiled and documented version of the whole GASS simulator v2.0 It will be distributed in a few weeks (under request) Coordinator : Eduard Masana, emasana@am.ub.es RRFWG Meeting at Dresden

  7. http://www.ast.cam.ac.uk:8080/gibis GIBIS v1.4 has a fully functional version throught the internet (password needed) pixel level simulator == images Coordinator : Carine Babusiaux, carine@ast.cam.ac.uk RRFWG Meeting at Dresden

  8. Recent meeting information and other documents (Simulator documentation, User guides,etc.) are going to be available through SWG web page : http://gaia.am.ub.es/SWG/ To access SWG Work Area, please send an e-mail to : Xavier Luri : xluri@am.ub.es RRFWG Meeting at Dresden

  9. Common Libraries(gaiasimu package) Both simulator efforts use the same libraries in order to preserve consistency and to save time duplicating job. RRFWG Meeting at Dresden

  10. This libraries are in a package called gaiasimu, which contains the univers models,satellite and intruments models, all required routines, as well as the the used numerical libraries. It is expected this libraries being “flexible” and portable enough to allow the community use them for their particular simulation purposes (i.e; supernova and other event detection, stocastic microlensing noise, variability detection, etc.) RRFWG Meeting at Dresden

  11. Java ; the language of the Simulator RRFWG Meeting at Dresden

  12. Portable and Modular as a development priority Algorithm and routines implementation must be as flexible as possible to allow its generic implementation in any of the present/future simulator efforts. The code must be portable. It could run in any machine with identical results. The code must be modular. Diferent parts are developed by diferent groups and are being integrated in the same structure. In the same philosophy, the code must be efficiently documented. Documentation can be found at SWG web page RRFWG Meeting at Dresden

  13. The portability of Java (not machine dependent) have some essential counterparts. For example, the maximum precision you can use (using basic algebraic manipulation) is 64 bits : long : integer value double : floating point value Java is not so fast as other languages (as Fortran or C/C++) in some specific tasks (I/O from files for example). 1 bit sign + 63 bits mantise 1 bit sign + 63 bits mantise + 1 bit sign + 7 bits exponent • Performance, speed and Read-at-Once The use of temporary files is HIGHLY not recomended. If a routine must read from a file a set of parameters it is recommended to Read-at-Once the file at the first time the routine is initialised. RRFWG Meeting at Dresden

  14. Wrapping from C/C++ and Fortran to Java If an algorithm is a bottle neck or its translation is very complicated, Java allows wrapping from other languages. Wrapping must be avoided if it is not considered essential, because it makes the Simulator lose its portability... ... and because the people working in the Simulator structure should have to wrap the routines themselves. RRFWG Meeting at Dresden

  15. An example : Fundamental Algorithms RRFWG Meeting at Dresden

  16. What are the “Fundamental Algorithms”? • The so-called Fundamental Algorithms (LL-44) are those equations/processes which relate observations with catalog astrometric data. • Due to the nominal high precission astrometry stated for GAIA, a full relativistic treatment of the observation process must be carefully tested and developed. RRFWG Meeting at Dresden

  17. In this process there are some independent tasks involved : Main Task Observables parametrization (parallax, and proper motions, solar system objects orbits), Gravitational Light deflection and relativistic aberration modelization Related Tasks : - Reference Frames definition - Satellite ephemeris model (position , velocity) - Solar System model (postion and velocity of relevant massive bodies). Eventually, other object properties may be required from the model. - Time transformations (i.e; simulated telemetry data MUST be given in satellite proper time) - Attitude parametrization RRFWG Meeting at Dresden

  18. Parameters review and interactions RRFWG Meeting at Dresden

  19. Baricentric position at Observation Time source position source velocity tobs RRFWG Meeting at Dresden

  20. Parallax Correction source position source velocity tobs observer’s position RRFWG Meeting at Dresden

  21. Gravitational light deflection source position source velocity tobs observer’s position solar system ephemeris Gamma ppn parameter RRFWG Meeting at Dresden

  22. Observed direction (aberration correction) source position(*) source velocity(*) tobs(*) observer’sposition observer’s velocity solar system ephemeris Gamma ppn parameter tobs(*) Satellite Proper Time S vector Field Of view Angles RRFWG Meeting at Dresden

  23. Input parameters Satellite ephemeris Solar System Model Global Parameters Time ephemeris Attitude source position(*) source velocity(*) tobs(*) observer’sposition observer’s velocity solar system ephemeris Gamma ppn parameter tobs(*) Satellite Proper Time S vector Field Of View Angles RRFWG Meeting at Dresden

  24. Generated by the Universe Models (Galaxy model ; Torra et Al) Chebychev representation (F.Mignard GAIA-FM-13) Chebychev representation ? (F.Mignard To be done) General Relativity  = 1.0 (A. Einstein) Chevychev representation ? To be defined Quaternion formalism (L.Lindegren) Input parameters Satellite ephemeris Solar System Model* Global Parameters Time ephemeris Attitude RRFWG Meeting at Dresden

  25. Perpendicular Models Input parameters Satellite ephemeris Fundamental Algorithms Main Task Solar System Model* Global Parameters Time ephemeris Attitude ,  ,  RRFWG Meeting at Dresden

  26. Pure PPN perturbative formalism (S.A.Klioner et al) General Relativistic “semi-analítical” approach (F.de Felice, A.Vechiatto et al.) Fundamental Algorithms Main Task RRFWG Meeting at Dresden

  27. What the Simulator people has to say about.... Fundamental Algorithms Main Task Routines will not have direct acces to “perpendicular models”, if they are not coded in Java In this case, access has to be provided by a GAIA Simulator interface coded in Java. This impose to such routines to be as much “parametric” as possible RRFWG Meeting at Dresden

  28. RRFWG Meeting at Dresden

  29. The Simulator interface is partially done waiting to be decide the final structure I/O methods. For test purposes it has been implemented a Java version of S.A.Klioner routines following the presented structure for the F.A.Core Tasks. Fundamental.java Observer.java (satellite ephemeris) SolarSystemModel.java (solar system massive objects ephemeris) If it is all intilialised correctly, a call of : getDirectionOnSatellite(double tobs, double[] x, double[] v) return the desired S vector. RRFWG Meeting at Dresden

  30. Some reference performance results Some simple test permormed with diferent configurations: Only Sun, Only Jupiter , Sun & Jupiter This tests have shown that the numerical stability is guaranted at as precision working at 64 bits precision (theoretical defelction has been obtained using : RRFWG Meeting at Dresden

  31. Intel P4 [2.4 GHz] Some initial rounding problems at the time to estimate  were solved using an aproximate rule to calculate the angle between to very similar unit vectors : Because of initial rounding problems we tryed to perform all calculations at “arbitrary precission”. When the rounding problems were solved in final angle estimation, arbitrary precision showed to give almost the same results as working in standard 64bits. - Using arbitrary precision operations 12000 sec / 106 stars = 12.1 miliseconds per star - Using double precision operations 105 sec / 106 stars= 0.105 miliseconds per star RRFWG Meeting at Dresden

  32. - I/O flow must be decided being this fact independent of the implementation chosen. • CONCLUSIONS • From the GAIA Simulator point of view, the “Perpendicular” model + a Java Interface; is the best option to keep the modular structure. • It allows to develop such models independently from F.A. RRFWG Meeting at Dresden

  33. Chevychev representation ? To be defined Time ephemeris • As a crucial part of the telemetry production, a decision must be taken. • To proceed with the time integration it is needed a Solar System model for ephemeris compatible with the satellite ephemeris. RRFWG Meeting at Dresden

More Related