Skip to content
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

Open
2 of 3 tasks
taldcroft opened this issue Aug 27, 2018 · 6 comments
Open
2 of 3 tasks

Support proseco catalogs in starcheck #252

taldcroft opened this issue Aug 27, 2018 · 6 comments

Comments

@taldcroft
Copy link
Member

taldcroft commented Aug 27, 2018

There are a number of changes needed to support proseco catalogs:

@taldcroft taldcroft changed the title Support proseco catalogs Support proseco catalogs in starcheck Aug 27, 2018
@jeanconn
Copy link
Contributor

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.

@jeanconn
Copy link
Contributor

Also, regard to scope, what about running starcheck 4.0 in parallel? Too confusing?

@taldcroft
Copy link
Member Author

Yes, there should be just one definitive tool for load review and approval.

We'll have no way of telling which of these are valuable warnings.

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 proseco.pkl file is available).

We probably need an independent implementation of the hot pixel check in starcheck.

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).

@jeanconn
Copy link
Contributor

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 proseco.pkl file is available).

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.

Not super keen on re-implementation.

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.

@taldcroft
Copy link
Member Author

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.

@jeanconn
Copy link
Contributor

jeanconn commented Oct 13, 2018

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.

@taldcroft taldcroft added this to the 13.0 proseco milestone Dec 18, 2018
@jeanconn jeanconn modified the milestones: 13.0 proseco, 13.1 Jan 16, 2019
@jeanconn jeanconn modified the milestones: 13.1, 13.2 Mar 20, 2019
@jeanconn jeanconn removed this from the 13.3 milestone Dec 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants