Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

Different databases, different ways of specifying the query and various indexing methods have been tried.

September - October

The spatial extensions are no longer used since performances are disappointing especially when indexes need to be rebuilt.

Selection of events located within a cone is implemented more accurately.
For each event cartesian coordinates (x,y,z) were computed from the celestial coordinates (ra,dec) and have been stored in the event table.
A bounding box of the intersection of the sphere by the cone is computed. If a pole is located in the cone a whole cap is kept.
Events located inside this box are selected. For each event in this subset the dot product between their direction and the axis of the cone is computed.
A query looks like :

select event_number, run_number, time, energy, quality, ra, decl from events
where (1198 <= ra and ra <= 2041 and 1980 <= decl and decl <= 2340) and
(x * 0.35355338 + y * -0.35355338 + z * 0.8660254 > 0.9961946980917455)

A typical result with MySQL is shown here.

January - June

With a pretty small number of events and using the geographical modules available in the database procucts a first evaluation has been made.

Sample Data are stored in a relational database. Events data are kept in a table.
A perl script is run to retrieve events located in a region defined by ra_max, dec_max, ra_min,dec_min. (typically 32x32 degrees).
The time spent by the query as well as the number of events found are kept.
The query is launched 100 times, statistics are output.

...