-
Notifications
You must be signed in to change notification settings - Fork 0
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
Support proseco catalogs in starcheck #252
Comments
As another issue, I suspect current starcheck will give us plenty of bad pixel warnings on new catalogs that have guide stars selected that allow "faint" hot pixels on bright stars. We'll have no way of telling which of these are valuable warnings. We probably need an independent implementation of the hot pixel check in starcheck. |
Also, regard to scope, what about running starcheck 4.0 in parallel? Too confusing? |
Yes, there should be just one definitive tool for load review and approval.
This information should be provided in a guide selection report analogous to the acq report. It could be a lightweight and manageable update to current starcheck to just provide links to those reports (and run the Python tools to generate the reports if the
Not super keen on re-implementation. The Python algorithm and implementation will be tested and validated, so you should be able to just call that from starcheck as needed, no? (I looked at the code and API change is needed, but nothing that would be difficult). |
This still seems like information "on the side" somewhat similar to running a separate load review tool, but if you think it is much better than a separate evaluation I'll keep it in mind.
I think in this case the independent implementation would actually be just running annie as part of load review... which I think you are onboard with, but probably not for the next starcheck release. |
I believe we have to find acceptable workarounds and low-effort implementations on many fronts to make the deadline. That's the driver for my suggestions. Of course I don't want to see meaningless warnings and have to click through to see if it has meaning. |
I've got a bit of an interesting question on this regarding dither. So, starcheck right now is set to check catalogs using "default" dither amp of (20, 20) if there are no previous dither commands in products. We went a bit back and forth on using kadi.commands for dither amplitude continuity, and we've been back and forth on using the OR dither amplitude values for checking of science observations. Now my question is actually, can we just use the proseco pickle dither values in the call_args? That is, do the star catalog checks on the catalog based on the saved call_args for dither on the matlab side for new products? The matlab side already had the right dither amplitude continuity so these should just be "right". It is a bit of a hack to get this information via proseco, but if we test this appropriately I think it is reasonable. My original plan was to use the proseco pkl just to have starcheck verify that the proseco call_args were right, check the catalog matched, use the acq probs on a match, and recalc acq probs on mismatch. But with regard to dither I think that starcheck should really check the catalog with the same parameters that were used to determine the catalog in proseco, unless we decide that there is value in padding the "for-checking" dither in a systematic fashion. And of course we would still warn on mismatches between the dither used for checking and the commanded dither status and available commanded dither amplitude. |
There are a number of changes needed to support proseco catalogs:
The text was updated successfully, but these errors were encountered: