The document discusses developing a tool to select guide stars for giant telescopes using virtual observatory technologies. It outlines key challenges in finding enough bright, isolated stars within a small field of view. The tool will search astronomical catalogs to identify candidate guide stars, prioritizing reliability over availability if needed. The project plan involves building the search capabilities incrementally, with early milestones including basic point source searching and integrating multiple catalogs.

1. The Selection of Guide Stars for
Giant Telescopes using Virtual
Observatory Technologies
Hector Quintero Casanova
University of Edinburgh

2. Title is too long...

Selection: universal search tool.
– General service available to applications.

Guide stars: trackable starry objects in the sky.
– Point-like: cannot be resolved to extended shape.
– Stationary: no proper motion.
– Other constraints: number, size, brightness...

Giant telescopes: Extremely Large Telescopes.
– 10s metres in diameter.
– 100s millions in budget.

Virtual Observatory Technologies: suspense...

3. ?
Depends on constraints
They are tough for ELTs
Are we running out of stars?

4. 1.Availability

European ELT specs:
– At least 3 Guide Stars (GS).
– All must be magnitude 14.
– And within 10 arcminutes.

Not that many meet those conditions.
– Acute in the galactic poles.
NOTE: This will be the project's test case.

5. 2.Reliability

Out of only 6, 2 are galaxies and 1 is “funny”.

Culprits: Number of GSs and their magnitude.
Most stars here

6. Adaptive optics
• Atmospheric turbulence ruins the light party.

Adaptive optics removes distortion real-time.

Needs a GS to probe turbulence pattern:
– Bright enough: limiting magnitude.
– Isolated: near-neighbour problem.
– Initially, at minimum distance from target.
• Otherwise, affected by different turbulence.
• Solved with multiple GSs ≃ MCAO
• MCAO applied in ELTs.

7. The challenge

MCAO requires at least 3 stars magnitude 19.

ELTs work with a smaller Field Of View (FOV).
– AO corrections more accurate: brighter Gss.

But in a smaller FOV, less bright GSs.
– Stronger dependence on less reliable GSs.
• Shape might help filter out some of those.
• Other data to filter some more: proper motion.
• What happens with still point-like ones?

8. Galaxy PGC 214696

Happens also with double stars, nebulae...

For simplicity, consider only galaxies.


9. Catalogues

Tables of objects in all or part of the sky.

Format and fields vary. Required:
– Coordinates and proper motion (astrometry).
– Magnitude (photometry; band V).
– Shape (eccentricity, ellipticity...).
– Class (star/galaxy separation, number...).

May contain artifacts. Class field handy.

Which? All... More information, less guesses.

10. Virtual Observatory

Provides uniform access to astronomy data.

Framework of standards. Most relevant:
– UCDs: universally describe fields.
– Cone search: most catalogues support it.

But full automation is not possible:
– UCDs cannot be used in queries.
 Cannot abstract completely from schema.
– No descriptor for sky coverage.
 Cannot search by spatial relevance.

11. Pre-emptive catalogue selection

All-sky catalogues that include all/most fields.

At least, all magnitude 14 stars or brighter.
Magnitude Approx. number of
Name
range objects
Hipparcos <= 12 100 K
Tycho2 <= 12 2.5 M
UCAC3 8 – 16+ 100 M
2MASS PS <= 14 500 M
USNO-B1 12 – 21 1000 M
NOMAD <= 21 1100 M
GSC 2.3.2 <= 20 900 M
Updated list of recommended catalogues by U.S. Naval Obs.

GSC 2.3.2 with highest % of correctness: 98%

12. Pre-emptive catalogue selection

Use GSC 2.3.2 as a baseline against user's:
– To guarantee availability of required fields.
• More flexibility allowed in user's choice.
– To use its classifier as a first coarse filter.
• Reduces no. of operations in point-like search.
• Cannot use GSC 2.3.2 data directly anyway.

Use crossmatching to relate catalogues.

At service level, all catalogues as parameters.

At interface level, recommended catalogues.

13. Limitations

Similar accuracy in user & baseline catalogues?
– Introduces slight differences in astrometry.
• Not so bad for point-like search.
• Hampers near-neighbour filtering: object repetition.
• Hampers galaxy filtering: object off-setting.

Solutions:
– List of recommended catalogues is vital.
– Near-neighbour and galaxy filtering low-priority.
• Galaxy filtering similar process to baseline filtering.
• Generalise as crossmatching wrapper for extension.

14. Limitations

Balance between availability and reliability?
– Model of successive filtering favours reliability.
• In areas like the NGP, it may affect availability.
• So far, user has been left out in that process.

Solutions:
– Sort list of final candidates by shape fidelity.
• How much of a point-like object are they?
– Introduce parameter for level of filtering.
• Relevant when doing filtering with other catalogues.
 Make it low-priority.

15. Project Milestones and Priorities
1.Build point-like search as assembly basic ops.
2.Build wrapper for crossmatching catalogues.
3.Build point-like search with baseline reference.
4.Build user interface with sorting.
5.Build service.
6.Add galaxy filtering.
7.Add near-neighbour filtering.
8.Improve performance and other aspects.

16. Project plan

Software methodology: waterfall + iterative devel.
– Although important, interface is not central.
– Requirements are likely to be stable.
– Simple model to follow: less technical digressions.

Risk mitigation:
– Study of complexities and prioritisation (checked).
• Helps increase de-coupling from supervisor's input.
– Iterative development and testing. Design of tests.
– Plan with as much detail of design as possible.
– Include intermediate stages. Will act as buffer.

17. ¿?