I'm trying to formulate the necessary queries to the star catalogs.
Are there any rough guidelines on how we can constrain the queries, so that we do not stress the servers unnecessarily? I'm thinking of

• what is the minimum magnitude
• which band should be use
• any other exclusion criteria?

Also, if we decide to use GAIA when looking for guide star candidates, this would be convenient, since `astroquery.gaia` allows ADQL queries, and I could directly use the polygonal shapes of the guide cam FOVs in these queries. As far as I understood, `astroquery.vizier` (which is currently used by shuffle) only allows simple cone and box searches, so that I would have to do more post-processing on the results.

Dear Martin,

this is an incomplete answer. We should be able to configure the magnitude cutoffs. I think this functionality exists (somewhat crudely) in shuffle already. This should be per band. So for GAIA G,Gbp,Grb. The syntax of the current configuration file does not lend itself to this right away as it is tied to sdss magnitudes. 

Ideally we would allow for a freeform filter like "(G > 10 & G < 24) " or similar.

As for other limits. We may want to restrict too large peculiar motions (not sure) and close pairs.

All TBD.

Max

Thank you very much! I think the freeform filter is not a problem since the constraints can be passed to the query as a string.

I was mainly interested to have some approximate, but realistic numbers to play with, since (as a numerics person) I have absolutely no intuition what kind of magnitude range might be required. With the example you gave me I can be sure that I don't torture the server unduly.

By the way, it seems that ADQL even has constraints which can filter out close pairs directly in the query, which could be extremely convenient!

Hi Martin,

great. The values in the config are actually for a 10m telescope. So they are probably good starting points.

Max

Small update: I managed to formulate an ADQL query which allows specifying a region of interest (circle or polygon) and magnitude limits, and which allows selecting only stars with proper motion data. Such a more complicated and flexible query is necessary, I think, because without some magnitude preselection the returned tables for the full FOV would just become too large.

Using this query syntax we can

• get a (presumably short) list of uncomfortably bright stars in the full telescope FOV (expressed as a large circle), which we can test for proximity with any allocated fiber, and
• for each guide camera FOV (expressed as a polygon) obtain a list of guide star candidates (here the magnitude limits will most likely be different)

I thought I had seen a way that would already eliminate close pairs on the server side when looking for guide stars, but unfortunately cannot find it again at the moment. In any case, doing that locally is not a big effort and does not have a big impact on the size of the query results.

One problem with this approach is however that it only works for catalogs that support ADQL queries. So far I have only tested this for GAIA, but judging from pages like http://tapvizier.u-strasbg.fr/adql/ I assume that this also works for other catalogs if we should need them.

We only care about proper motions for the stars that fall on the guide chips which are a pretty small area. Are you doing this for the entire focal plane in order to visualise the field? If so, can't we use a magnitude limit instead?

Max's idea was to obtain a list of bright stars in the entire field to make sure no fiber was in close vicinity to one of those. It's no problem to use different queries for this purpose and for the small areas seen by the guide chips. In fact, I've just verified that polygon queries work fine for that purpose; proper motion could then be requested for the small-area queries only.

I agree with Max about bright stars, although I don't think we know what the bright limit is yet. Hmm, we could put the brightest star on a black spot, but I don't know if that's actually better then letting its light scatter around in the PFI's guts.

Do you happen to know if it is possible to put a magnitude limit to a simple Vizier cone search? At least in hetdex_shuffle, this wasn't done, and I couldn't find any examples for this on the net either. So I guessed that I would have to go to full-fledged ADQL... I'd be happy if I'm wrong, of course, because that makes using other catalogs much easier.

There is a Vizier service at http://tapvizier.u-strasbg.fr/adql/ which allows full ADQL queries on all catalogs they have available, and that seems to include everything we need. I have proof-of-concept code which performs SDSS and GAIA queries using this service, and I verified that the GAIA query results match those from the official GAIA server.

Using ADQL to access this server (and, as a backup, the official Gaia server) is a very elegant and powerful way to resolve this issue, but I see two drawbacks:

• if both of these servers are down simultaneously, I'm not sure if there is any other backup service (there might be more ADQL servers around, but I couldn't verify this so far)
• I don't know how to deal with manually supplied catalogs (e.g. in form of Python dictionaries) in this context

There is now a script called `demo_shuffle.py` in branch `demo` of https://github.com/Subaru-PFS/ets_shuffle, which showcases the queries, corrections, and spatial selections I intend to do in order to get the lists of guide star candidates. This is an isolated script with hardwired input and no output, since I don't yet know how the code will be integrated into the higher-level components (e.g. as a library via function call, or as a separate script with command line arguments, etc.).

Please have a look if you have the time; any feedback is welcome!

P.S.: to make this script easy to run, I copied a few files (which contain the coordinate conversion code) from `pfs_utils`, since I didn't manage to install this locally. This is temporary and will hopefully change soon!

Additional question on "close pair" avoidance for guide star candidates:

• I assume that we also want to avoid close neighbors that are somewhat fainter than the magnitude limit for our guide stars (i.e. which would not be guide star candidates themselves). Is that correct?
• We probably should also exclude close pairs of which one star is outside the camera's field of view.

If that is the case, the underlying queries will become a bit more complicated, but should still be fairly straightforward.
Please let me know what you think!

I think this is right in principle, but then if we select a guide star right on the edge of the field of view of a guide image we have done something wrong in the first place. An autoguider can not guide off a stare that falls right on the edge of a detector. 

Guide stars should only be allowed to fall into a footprint that is effectively a bit smaller than the guide camera footprint.

In practice we will probably just pretend that the guid chips are a bit smaller than they are?  

But so yes also guide stars at the edge of the field of view should not have a close neighbor outside of the field of view.

Also yes on the magnitude limit, probably best again to define a parameter.

Max

Thanks, I'll make the necessary adjustments!

Done!

Getting the following error

Installing collected packages: astroplan

Successfully installed astroplan-0.6

mxhf@lapex-07:~/work/MPE/pfs/src/ets_shuffle$ python demo_shuffle.py

Traceback (most recent call last):

  File "demo_shuffle.py", line 2, in <module>

    from coordinates.CoordTransp import CoordinateTransform as ctrans

  File "/Users/mxhf/ownCloudRZG/work/MPE/pfs/src/ets_shuffle/coordinates/CoordTransp.py", line 12, in <module>

    import astroplan

  File "/Users/mxhf/.pyenv/versions/anaconda3-5.0.1/lib/python3.6/site-packages/astroplan/_init_.py", line 32, in <module>

    get_IERS_A_or_workaround()

  File "/Users/mxhf/.pyenv/versions/anaconda3-5.0.1/lib/python3.6/site-packages/astroplan/utils.py", line 57, in get_IERS_A_or_workaround

    if IERS_A_in_cache():

  File "/Users/mxhf/.pyenv/versions/anaconda3-5.0.1/lib/python3.6/site-packages/astroplan/utils.py", line 67, in IERS_A_in_cache

    urls = (iers.conf.iers_auto_url, iers.conf.iers_auto_url_mirror)

AttributeError: 'Conf' object has no attribute 'iers_auto_url_mirror'

Interesting. I also have astroplan 0.6.0 installed and don't get this error. However I do get the following warning, which could perhaps indicate a solution:

WARNING: OldEarthOrientationDataWarning: Your version of the IERS Bulletin A is 36.4 days old. For best precision (on the order of arcseconds), you must download an up-to-date IERS Bulletin A table. To do so, run:

>>> from astroplan import download_IERS_A
>>> download_IERS_A()

Perhaps you just need to execute the above lines to populate the data structures.

Solution for a similar problem at https://github.com/astropy/astroplan/issues/443

No, unfortunately even the import of astroplan fails....hmmm

In [*2*]: import astroplan

---------------------------------------------------------------------------

AttributeError                            Traceback (most recent call last)

<ipython-input-2-4b2ee34d882b> in <module>()

----> 1 import astroplan

~/.pyenv/versions/anaconda3-5.0.1/lib/python3.6/site-packages/astroplan/_init_.py in <module>()

     30     from .periodic import *

     31

---> 32     get_IERS_A_or_workaround()

~/.pyenv/versions/anaconda3-5.0.1/lib/python3.6/site-packages/astroplan/utils.py in get_IERS_A_or_workaround()

     55     the end of the IERS table.

     56     """

---> 57     if IERS_A_in_cache():

     58         iers.IERS.iers_table = _get_IERS_A_table()

     59     else:

~/.pyenv/versions/anaconda3-5.0.1/lib/python3.6/site-packages/astroplan/utils.py in IERS_A_in_cache()

     65     Check if the IERS Bulletin A table is locally cached.

     66     """

---> 67     urls = (iers.conf.iers_auto_url, iers.conf.iers_auto_url_mirror)

     68     for url_key in urls:

     69         # The below code which accesses ``urlmapfn`` is stolen from

AttributeError: 'Conf' object has no attribute 'iers_auto_url_mirror'

In [*3*]:

Ah, thanks. Trying ... though ....hmm

  File "ets_shuffle/demo_shuffle.py", line 3, in <module>

    from ets_shuffle import query_utils

ImportError: cannot import name 'query_utils'

is query utils not in git yet, maybe?

Max

Aargh, sorry ... now it is!

OK, got it to run. So I am getting a plot of the possible guide stars.

I also executed the skyimage.py which (surprise) produces an image of the sky.

So, I guess we need to combine them yet (or make the production of an image into a pdf (or similar) optional?

Max

Yes, at the moment the output is a simple plot (in PFI coordinates).

Creating lists of PFI coordinates and GAIA IDs for all the candidates is trivial and is my next step.

Skyimage is really just a proof of concept. It cannot yet be combined with the output of the guide star selection, because I don't have the transforms from PFI to sky coordinates yet. Of course I could overplot red dots where the guide star candidates are, but at the moment there is no way to plot, e.g., AG camera FOVs or patrol regions.

Max, if you would prefer a more flexible demo that allows, say, providing parameters on the command line or interactively, please let me know which method of providing parameters would be most suitable for you.  As I said, depending on how this will be integrated with the rest of the software, this will be wildly different, so I didn't even start on this part of the code. Possible scenarios are:

• code is used as a Python module => interface is a documented public function which takes the parameters as arguments and returns the results
• code is used as a standalone script => parameters come from the command line or via a parameter file, or via entries in a data base, output is written to disk or to a data base in a TBD format

Overall, I don't expect we'll have to use configuration files specific for this task (as is done in HETDEX shuffle), as the number of parameters is fairly small, and the only really complicated ones (AG camera geometry and fiber locations) will be available via library or DB calls.

The code now outputs the pixel coordinates of the guide star candidates.

Can you please have a look whether this works as intended, Max?

OK, this seems to work. I propose to merge to master.

Martin Reinecke can we close this ticket?

Branch has been merged; I think this is OK to close.