-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add PointingCalculator #2623
base: main
Are you sure you want to change the base?
add PointingCalculator #2623
Conversation
added PlainExtractor based on numpy and scipy functions
restructured the stats containers
…ctapipe into stats_extractor
Remove StarVarianceExtractor since is functionality is featured in the existing Extractors
allow overlapping extraction sequences
renaming to chunk(s) and chunk_size and _shift added test for chunk_shift and boundary case
…ry/ctapipe into PointingCalculator
I think relying on accessing the internet to get star positions is not a good idea if these will run in large batch queues, as it is a point of failure and requires outside access. Instead, maybe we should think about just making one of configurable inputs be an astropy table (i.e. read the output of astroquery, but not requiring astroquery to be called internally). I.e. if you have a config option |
@kosack that sounds good. Since the cameras will often track specific objects we can pre-create such tables for those objects. The StarTracer thant needs to have the star positions can be just given a table of positions instead of using astroquery. I will start out with some table for the crab nebula to have something for the unit tests. |
@ctoennis the yale bright star catalog is already included in ctapipe as a static resource: It is complete to magnitude 6.5, which I think is enough for the pointing estimation, right? If not, we can also include e.g. the hipparcos catalog down to a lower brightness. To get a good idea of how you could use astroquery, have a look at this script I recently wrote to find stars suitable for PSF measurement: https://github.com/maxnoe/find_psf_stars/blob/main/find_psf_stars.py It queries the HIP catalog via astroquery to Vizier and downloads two files from the HIP webpage providing additionally common names for the stars where they are available. |
In general |
Yes, the current limit in the utility function is put on ctapipe/src/ctapipe/utils/astro.py Lines 51 to 52 in 3dc94da
|
I think we can try with the V-mag and see... 6.5 magnitude is close to the limit, we need to re-evaluate the star reconstruction performance to see whether we need fainter stars. |
Ah, nevermind, the catalog export I did doesn't include |
After writing the psf stars script, I also realize that the function does not apply space motion, so stars with high proper motions will not be at the correct positions. |
Ok, i'll switch to that tool. |
ah, Vizier does it (and that's why it needs a periodic update of the cache) |
I'd not select the computed values from Vizier, but use astropy, since then we can keep the cache for a long time and just have the correct proper motions applied. It's quite fast. |
I wanted to post this pull request here for the PointingCalculator.
I have not finished adding unit tests for the calculator and the code does not run as is.
One important thing to discuss is the method of looking up star locations. Currently the code uses astroquery, which would be a new dependency.
Otherwise this is still work in progress.