User Tools

Site Tools


code:long_term_scheduling

Differences

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


Next revision
code:long_term_scheduling [2009/12/14 21:47] – created pkubanek
Line 1: Line 1:
 +====== Goals ======
  
 +The goal is to allow introduction of a standard observing proposals to the system. The users should be particularly able to:
 +
 +  - Create new targets through web interface
 +  - Edit various options (constraints) for their observations
 +  - Query for the best next observation
 +
 +====== Experience - design ======
 +
 +I do not belive that it is easily possible to store all strange observing constraints in the database. Major problem is that we do not exactly know in advance which constrains are needed. And it is a real pain to make database change for every new constrain.
 +
 +The ideal structure should be split into database and XML supporting files. Database is great for indexing (storing IDs of proposals), XML files are great for possibility to easy extend them without any significant penalty. The ideal design should merge those two advantages to create a flexible system which will suit our needs.
 +
 +  - have targets list
 +  - introduce proposals, which will have their PIs,..
 +  - introduce constraint for proposal (when to observe, how to observe, who should be notified,..)
 +
 +The first item is implemented in **target** table. The second is partially implemented (as part of GA scheduling experiment). The last is partially implemented in **target** table, but must be definitly moved out of the database.
 +
 +Also the next design should be **proposal** centric. Current design is **target** centric - e.g. it is impossible to schedule observation based on proposal, it is only possible to schedule observation based on target. Although multiple targets for same object can be created to overcome this problem, this is most probably not the correct solution.
 +
 +====== Current state ======
 +
 +Currently RTS2 provides those tools for creating and managing observation targets database:
 +
 +  - **rts2-newtarget**, which allows easy introduction (from CLI) of a new target. It included SIMBAD name resolver, so users do not have to bother with looking for coordinates
 +  - **rts2-target** which allows edition of script for devices and target management. Most commonly used options are -e/-d (enable/disable target), -p (priority), -c C0 -s 'script' (scripting management)
 +
 +There is **target** table in RTS2 database, which holds target information.
code/long_term_scheduling.txt · Last modified: 2009/12/14 00:00 (external edit)