ASTAP Plate Solving Anomaly

I’m running version v3.1.0.457 of SGPro and have experienced the following issue when plate solving.

I’ve been testing the new plate solver ASTAP as well has checking that my change to using the local instance ‘ANSVR ‘ of the Astrometry.net blind solver has worked. The testing has been undertaken due to seeing odd behaviour during my last imaging session whereby:

  • If I initiated a ‘Scope Centering’ | ‘Solve & Sync’ process the new ASTAP utility quickly solved after taken its first plate solve frame, leaving the image in a Plate Solve window.

  • In addition, whenever I right-click action either a ‘Centre Here’ or ‘Plate Solve’ request when the image currently displayed is in a ‘Plate-Solve’ window the ASTAP or local blind solver completes satisfactorily.

  • If instead I took a ‘Frame and Focus’ image at the same location using a known object, followed by a right-click ‘Plate Solve’ using the ASTAP option as well as entering the target object and RA & Dec in the hint fields the process fails to complete. Indeed, on one occasion a division by zero error message was displayed.

To further this investigation, I cleared any old log files so as to run the sequence from a clean starting point. As I was not at my dome, I started SGPro without any equipment connected. Instead, I loaded a previously taken image that contained all the necessary header data to identify image centre, etc. [copy in Dropbox]

  • I initiated a right-click ‘Plate Solve’ using the ASTAP option as well as entering the target object given the centre RA & Dec were auto-read from the header in the hint fields. Again, the process failed to complete. And after a while a floating-point division by zero error message was displayed, as shown in the screenshot. [in this One Drive folder. As are copies of the Log file, test image, User and Equipment profiles]

I am running SGPro under Windows 10 Pro with the latest version for both, and have been rebuilding the PC after a drive crash, hence the My User Profile has only limited information in. That said the image being used does contain this data. This of course may be the issue? This is also the first time I’ve changed both the plate solving utilities, so am quite expecting this report to highlight an erroneous setting somewhere that I’ve either made or omitted to make.

Regards

Dave

Hello Dave,

Thanks for providing the feedback and all the files. I’m the author of ASTAP, so I can only look to that part. I have tried the command line from the log with the FITS file provided and it solves wihthout any problem. According the screenshot ASTAP has a runtime failure and SGP can’t find the solution file.apm.

At the moment, I can’t explain the error. Can you try again with an other file and does it happen again?
If so, could your reinstall ASTAP and the G17 star database. Maybe one of the files has been damaged. If it still happens after reinstallation can you report it?

An other possibility is there is something wrong with the FITS file created by SGP at the C:\users… directory. That file is used for solving but let’s park that for a later investigation.

Han

Hello Han,

Many thanks for your quick response and request. I will indeed do another run against a different FITS image. Otherwise, yes I’ll re-install said files. This may take a little time so please be patient. Either way I will report my findings.

Kind regards,
Dave

Well I’m at a loss as to why the anomaly showed up, since tonight I started once again from a clean slate, went to a random target and did nothing more than a right-click plate solve using ASTAP and it worked within a couple of seconds.

I then moved the scope slightly, took and Frame & Focus frame followed by a right-click plate solve, thus running against a frame & focus window rather than a plate solve window, and again it completed within a few seconds

I did a similar sequence using the local ANSVR server, which again worked perfectly albeit after a much longer wait.

Needless to say, I will keep a watching brief just in case the hiccup occurs again but otherwise I agree with Han’s findings, i.e. no fault found.

Sorry to have wasted both Han’s and my time writing this one up in the first place.

Cheers,
Dave

Dave,

Feedback like yours is important. There could always something overlooked and most users don’t bother to report abnormalities. Don’t hesitate to report any other problem and hopefully it’s possible to trace the problem.

Han