Try another combination for low guide_count?

[jeanconn]

While looking at the WiP for too small boxes #258 , it occurs to me that an equivalent justification to try a candidate in the "next" stage would be if you have insufficient guide stars by the temperature-mag-guide-count. You could have a brighter star than your worst already-selected candidate in the "next" stage.

So, if guide_count is right up there in priorities, it would make sense to me to do that check and perhaps swap in a brighter star from a later stage if needed.

You'd have a significantly shorter possible candidate list (first 5 stars + any star in a later stage brighter than the dimmest star in that set with a cap).

Now that we have the updated guide_count, let me see how many observations would hit this and if they'd see improvement (also probably need to nail down the bright star changes to stages, as that would feed back into this).

[jeanconn]

Though if we want proseco to use guide_count at all, I'd prefer that sot/chandra_aca#71 get updated with the newest count from aca_preview.

[taldcroft]

Yeah, we should just go ahead with the chandra_aca update (with the latest version using count_9th). That will hit starcheck of course, but I guess that's the point.

[jeanconn]

I want the chandra_aca update in ska3-matlab for the release, but I'd actually be inclined to hold of on the ska3-flight update until starcheck 13.1 .

[taldcroft]

Wouldn't this count as one of this "it's a dependency of starcheck, but doesn't introduce any algorithmic change?" I realize it could potentially change some review dispositions, but that doesn't need a new release of starcheck, just documentation in the chandra_aca change request.

[jeanconn]

I just haven't thought it all the way through yet and didn't want to rush it.

[taldcroft]

OK. I guess what works (and is according to our original grand plan) is if you can build a package for it and put into the test channel. Then I'll just be developing in my ska3-test env. I'll go clean up that PR to get it ready.