With the current discussion of ASTAP, I wanted to circle back on a problem that I described a couple of months ago, but had not yet investigated.  I’ve had some time to troubleshoot and I understand what’s going on now.

The issue that I had was that, when using ASTAP as the solver through SGP, APPM would occasionally get into state where a single solve failure would cause all subsequent solves to fail.  It turns out that what was happening is that SGP was instantiating ASTAP with PlateSolve2 compatibility and a search area of “Max Regions”.  What happened then was that a solve failure would essentially try to do an all-sky solve, with a search radius of 90 degrees.  The subsequent APPM solve failures were occurring because APPM had timed out the original solve and was submitting new solve requests while the first one was still searching with that large search radius.

The solution to the problem was to reduce the number of search regions in SGP.  In my case, I was able to change from “Max Regions” in SGP to 2500, which is the highest number below “max”.  I have a fairly small field of view at 23’ x 17’.  Using a search area 2500x my field resulted in a search radius of between 7 and 8 degrees.  A failed solve with this search radius fails in a few seconds.  With ASTAP failing before the APPM timeout, all is well.  Sure, it doesn’t address that initial failure (which in my case looked to be happening because of a really poor star field), but APPM now recovers properly and I can get a good model.

I’m hoping that Ray’s implementation uses the ASTAP native command line, instead of PlateSolve2 compatibility.  If that is the case, then it will be possible to specify a search radius directly and this won’t be a problem with sane parameters.  It would be even cooler if we could configure ASTAP for both normal and blind solves.  A “normal” search could have a small search radius, say under 10 degrees.  A “blind” solve could have a search radius of 90 or 180 degrees (with an appropriate timeout).

Thanks,

-Wade