Here is a 60 second dark and Master flat, when I use both of these on the M108 image in ASTAP it solves in 8 seconds

Dark_60sec

MasterFlat

OK, I could not find a decent image (with enough stars) at 20 seconds, so I went to 30 seconds, here is a MasterDark for 30 seconds and a 30 second image that I am having difficulty solving in both
ASTAP (with Dark and Flat applied) or in SexySolver. It could be because of the ellipticity of the stars as I was not well aligned that night.

MasterDark_30sec
Lumen_30sec

Is there an option in SexySolver that makes it shut down after processing? it seems to be doing that, so maybe it is not crashing the system but just shutting down?

Ron

So, I think you might be confused about one thing. When you run Parallel Solves, it starts a bunch of processes. One of them will be successful, the others will either fail, either because they failed to solve, or because we aborted/killed the processes after the one is successful. I am changing the log messages so that this is more clear in the next version. It didn't fail to solve, and it didn't crash. It succeeded and then shut down the others.

Well, there is some erratic behavior on my Rpi; i have unchecked parallel to avoid that issue. I have only been running the internal extractor and internal solver. The extractor never has an issue. I can extract stars in one file and open another.

The solver, runs, sometimes solves, sometimes not depending on the options. However, sometimes the solver finishes its processing, hangs (I cannot move or check anything in the solver window)and then closes. Sometimes it doesn't 'crash'? I cannot make the solver behave consistently in this regard. I have not figured out what it is doing. The stuff I found in syslog does not seem to match up with the time that the solver crashes, so I don't really see any info there.

Where does the log file get written. I cannot seem to find it if I check log to file? I thought I found it once (know I did I will have to look back thru this discussion)
thanks,
Ron

Yup, found the log file, again, in /tmp!
Ron

Ron,

The last image dubhe_Light_Lumen_30_secs_2020-05-16T23-51-08_001 is a difficult one. The darks help but due to tracking information some star are pretty oval. ASTAP, SExysolver and nova.astrometry.net all fail.


Rob,

How does the program divide the parallel solving work between the solvers. I can guess but is it on areas?

Cheers, Han

Han,
Yes, I am having difficulty with that one as well. I don't think I have found any combination that has solved it. However, the elliptical shape problem seems a little strange given that your star streak image solved. I tried the online solver and it complained about many objects being too big!?

I don't know why, but for last couple of hours the SSTester program has NOT crashed even after failed solves. As I said before I don't know what was going on there.
Ron

OK, I just got it to solve: I ran star extractor with Min area = 40, Photo params shape = ellipse, Star filtering Max Ell = .7, keep 100 stars results were 53 stars found after filtering and they all look like actual stars in the image.

then InternalSolver using scale only and it solved in 16 seconds!

Ron

Using the same extraction stars (53) and running ASTAP solver did not solve. Nor did the classic solver.

Ron

"The last image dubhe_Light_Lumen_30_secs_2020-05-16T23-51-08_001 is a difficult one."

I modified the extractor options a bit to try and get more 'valid' stars. (Valid being that when I zoom in and see what it found, they look like faint stars and not noise to me).
I dropped Min area to 30, left Shape as ellipse with r_min = 3, star filtering Max ell = .7 keep # = 100.
With these options the extractor found 75 stars.
the Internal Solver solved in 15 sec.

running int SEP and Ext Astap it failed in 43 sec

running int SEP and ext Astrometry.net (locally /usr/bin/solve-field) it failed.

running int SEP and online Astrometry.net it solved in 75 sec.

I am not knowledgable enough about how these programs work to comment on why these are the results. It does seem that the extractor can be made to select a decent set of stars even from a sloppy image like this one. Also, the Internal SSolver (I refer to this combination as Extract-n-Solve) seems to do a better (faster or successfully) job with fewer stars than the other programs.

But the default options for Extract-n-Solve, do not handle this poor of an image, you do need to fiddle with it a bit.

Ron

Hi Ron, I just pushed a new version to GIT with a bunch of changes. You might want to test it. I refined some of the profiles, added a Minimum Star Size setting, improved the parallel performance, improved the logging information so that it is less confusing. I hopefully eliminated the two reasons that it might have crashed before. I am not yet ready to publish a new release with windows and Mac binaries, since Windows is having an issue with headers right now that I have to straighten out, but since you are doing your testing on Linux, you can just do a git pull and rebuild. If you can perfect a good profile for solving your images, can you send me the settings and maybe I will make that a new profile?

Online Astrometry.net (either type) is always going to be slower because you have to wait your turn for the solve to take place on their servers online. The only advantage to the online version is that you don't have to install or download anything to your computer. It always takes at least half a minute. Once your turn comes, it actually solves very fast most of the time, but the wait time is very long.

Han,

There are a couple of algorithms that I have made so far. You can select these in the options, the Parallel Solving profiles are all set to AUTO, but if you are customizing options you can force one of them to be selected.

1 - Multiple Scales. This option starts multiple threads of solvers each with a different set of scale high and low settings. First I determine the optimal number of threads on your computer. Then I divide up the scale range into chunks for each solver. If the "use_scale" option is selected, it uses those as the min and max scales. If it is not selected, it uses the min and max width settings as the min and max scales. Originally I had it divide up the range equally, but I found that was not efficient. Now, I use a quadratic equation to divvy up the scale ranges, giving the smaller scales less of a range, and the larger scales more of a range. This seems to be much more effective because the larger scale solvers tend to finish faster, so giving them a larger range to search makes them more effective.

2 - Multiple depths. This was based on your suggestion Han. I use astrometry.net's depth settings to split up the work. First I determine the optimal number of threads on your computer. Then I use the number of stars specified by keepNum (or if keepNum is not specified, it just uses 200) to figure out how many stars to use in the depth settings. I divide the number of stars by the number of threads to determine the depth range each solver gets. However, if the range for each solver is going to be less than 10, I limit the number of threads since 10 seems to be an effective depth.

3 - Auto. I set up this setting to automatically choose based on the circumstances. If both the scale and position are both specified, it doesn't parallelize at all. It pretty much falls back to the FastSolver profile. If the scale is specified, it uses the multiple depths algorithm. And if the position is specified, but no the scale, or if position and scale are both not specified, it uses the multiple scales algorithm.

I might add more in the future. One that might be nice would be to divide up the regions of the sky. But I am concerned about that because the position in astrometry.net is always specified to be a radius of sky around the selected spot. If I divide up the sky among a bunch of threads, it will be a grid. Circles in a grid do not work very well. I am afraid that I will either overlap circles or that spots in between the circles will be missed. But it is worth a shot after I work on some other things.