Differences

This shows you the differences between two versions of the page.

--- ideas:development_topics [2008/08/22 19:25] – a bit more to the scheduling mates
+++ ideas:development_topics [Unknown date] (current) – external edit (Unknown date) 127.0.0.1
@@ Line 10: / Line 10: @@
 The work may be extended so that it would take advantage of the WCS (pixel->world) calibration to provide direct 3D resolved result if observed from more than a single camera.
+====== Transient pipeline ======
+Will be provided by Pi-of-the Sky, expected to be integrated by end of 2008.
 ====== GUI ======
@@ Line 17: / Line 22: @@
 Profile: GTK, PyGTK ideal, XML-RPC, Subversion, GUI design, user documentation
-There is prototype implementation of GUI, however I do not have time to finish it. It is in [[http://www.pygtk.org|PyGTK]], uses [[http://www.xmlrpc.com|XML-RPC]] to communicate with RTS2. I am able to give away code and provide guidance what shall be implemented.
+For description of XML-RPC interface, please see [[code:xmlrpc|XML-RPC wiki page]]. Also see description of current [[doc:gui|GUI]] there.
+As astronomers are strange beasts, it **must** be multi-platform (at least Windows + Linux, Mac highly recommended). We do not expect it will be feasible to code all as Web application - standalone application is preferred. The application might integrate various programmes (image display,..) with [[http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampDoc|SAMP]]. We expect various team members will pick different areas.
+What we expect:
+  * configurable interface to display (using various fancy displays - bars, gauges,..) and change variables, display events, notification and warnings, and display and modify scheduling database.
+  * 3D telescope visualisation, with interface to describe various system attached to the telescope and describe its status, failures etc..
+  * plotting of history of selected variables (temperature,..), similar to what [[http://finance.google.com|Google]] provides for finance or [[http://meteo.othello.ch|Meteo]] provides for meteo data display
+  * display observations, images related to observations,..
 ====== RTS2 Web ======
@@ Line 35: / Line 49: @@
 We went through an interesting history none -> SOAP -> XML-RPC regarding external access to RTS2. I just recently read through Atom specification, which is widely used by Google (so that was not XML-RPC - my mistake) and do not know if that is what we wanted. I like few characteristics of Atom, but dislike few others (apparent lack of C++ library to handle Atom requests is most probably the most serious one). The tasks of this mainly theoretics work is in comparing those various possibilities, try/use simple implementation with RTS2 and compare them.
-====== Better scheduling ======
+====== Scheduling ======
-Expected costs: 1 student for 6 months
-Profile: process scheduling (mathematics or computer science), some programming
-I am currently working on making ultimate scheduling, which would fulfill all the expectations we have. Having somebody else working on some topics, but using different algorithms (I am using genetic algorithms as this is required) could be useful and surely beneficial for both parties.
-Under scheduling we understand a process of allocating observing time to various tasks (targets) based on their coordinates (i.e. accessibility and airmass), current observing conditions (sky brightness, seeing), priority (group-fair-time-allocation, priority within group) and absolute time (fixed time specified, periodic observation needed). The solution may be obtained by evaluating a certain merit function on the fly during the observation, or by passing through all the available choices using brute force and choosing the best. There are points of essential importance needed to be able to fulfill the task:
+[[ideas:Better scheduling]]
-  - A good definition of **how to observe** (i.e. signal-to-noise/exposure time request from the user), and
-  - Resultant script **execution time** (estimate) at the telescope must be known, and
-  - How to decide whether and how much succesful was the observation (it's minimum quality and bonuses if it's better i.e. the **merit**).
-RTS2 scripts already do contain a good definition of the first point, however, some information needed is missing (selection criteria, the owner) and some is present only in the database (coordinates, priority). I (mates) believe, that a good definition of the target could be achieved by extending the script into a more complex **target description** which would, in a human-and-machine readable form, contain all the information needed to plan, execute, and evaluate the observing request.
+====== Advanced scripting ======
-I believe that having this //target description// well defined is one of the essential prerequisities of a good scheduler.
+[[ideas:Advanced scripting]]
+====== Database improvements ======
+We need to improve database design. Current summary is given at [[devel:database_structure|there]]. Database was originally developed as a quick hack, and the project grows of the original scope. It is clear that we will need to improve our current design. The work should provide summary of a current state, and should try to draw a new design.