×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Read More...

New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

  • Posts: 118
  • Thank you received: 19

Replied by Alan Archer on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

Rob,
Yes I see that, I have seen the message when I did have all the relevant indexes installed. Also what you have said explains why I found if I was slightly over generous when downloading the index files with Astronomy.net, the solving speeds actually improved. On a good night a first solve of 15 to 20 seconds and subsequent solves in 8 to 12 seconds. I wonder if the message could be made more of a basic / some type of prompt to check the installed index files, rather than just fail. It would act as a guide or starting point to sorting the issue of a failed solve.

By the way, we had the first clear night here for a few weeks last night and the new StellarSolver in KSTARS worked great right from the off, not a single failed solve during the session.

Many thanks

Alan
3 years 4 months ago #63198

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182

Replied by Jose Corazon on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed



Rob,

The parallel solving speeds up the solver significantly (about 4-5 fold under my conditions). It now solves routinely in under 1 s on my Pi4/8Gb, but it takes up to 5 seconds otherwise. However, for this to work I need to restrict the astrometry files the Solver loads into RAM to a minimum. Since I am using a wide-field scope at 250 mm focal length, that is feasible on a Pi4. However, when I select all the astrometry files needed to solve on any of my scopes, including an 8" RC, then the file size exceeds the RAM available and solving slows down dramatically.
At the moment, I am managing this by manually moving the astrometry files that are not needed for my short focal length into a subfolder from which they are not loaded. I then can manually move them back when I am putting a larger scope on the mount.

What I am wondering is whether it would be possible for the Solver to just load those files it ANTICIPATES it needs for parallel solving BASED ON FOV into RAM and ignore the rest for first pass. Only when solving is unsuccessful, it would then include the remainder of the astrometry files for sequential solving.

That way, it would not be necessary for the observer to make that decision and then, if solving fails, having to move back larger astrometry files into the folder on which the Solver is looking for them.

I would think it should be possible to do that in an automated fashion?

Thoughts?

Jo
3 years 4 months ago #63206

Please Log in or Create an account to join the conversation.

  • Posts: 2877
  • Thank you received: 812

Replied by Rob Lancaster on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

Jo,

This is certainly a good idea for the future, but right now unfortunately it might be kind of hard to implement. As I mentioned, it is slightly hard to say exactly which index file will solve any particular image. You can say that certain index files tend to work pretty well with a certain setup for sure, but you never know with certainty which exact one will solve it. So then the question would be, how would we determine which indexes to load? Do we load just the ones closest toe the scale we think it is? How much bigger or smaller do we go? Should that be somehow user configurable?

Also I would want to make sure that whichever way we do this for the internal solver, it will also work for the local solver as well. Right now, both the internal and external solvers are configured to just load all the indexes the given folder list. It is certainly possible to load just specific files for both the internal and external methods, but that would require a significant change to the code. Right now the only options are "load all the indexes" or don't do it and load them sequentially. I have considered a third option to have it automatically determine which one to do. This would be like a fourth option?

Another problem is that I'm not 100% sure that the RAM calculation that I have in there is perfect yet. It is supposed to shut off the "load all indexes in memory" option if there is not enough RAM. Before we would play with loading only certain indexes, I would want to be certain that that calculation works.
3 years 4 months ago #63242

Please Log in or Create an account to join the conversation.

  • Posts: 1119
  • Thank you received: 182

Replied by Jose Corazon on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed



Rob,

Making it user configurable would be one option. What I did was just move all the index files the astrometry page in the solver options told me were optional (i.e. those marked with an asterisk, presumably this is based on the calculated FOV of my telescope (?)), into a subfolder so they would not be loaded. That made a TREMENDOUS difference in speed.

I was hoping that would be easy to implement, to the tune of adding another check box "Do not load optional index files for parallel solving" or something to that effect.

Although my Pi4 has 8 Gb of RAM plus another 8 Gb of Swap Space on an SSD, and the total size of the index files I have downloaded is 5.6 Gb, the solver consistently determines that there is not enough RAM to load them all into memory. However, just moving the largest sets (those >1Gb) into a subfolder where the solver can't see them, makes the solver happy and I am rewarded with a 5 fold speed increase.

The advantage of having this option of initially loading only the non-optional index files would eliminate the need for moving the optional files into a subfolder, thus keeping them accessible to the solver if parallel solving fails. It could then fall back to sequential solving, now making use of the entire data set.

I thought that was the way the code was structured anyway, but I understand that if that is not the case significant changes might be necessary which do not appear justified at the moment.

But please keep this in mind nevertheless. The difference in speed is indeed enormous and many of us are using small SBCs with limited RAM to run their rigs. That means parallel solving might always necessitate manually removing optional index files - and moving them back in those special cases when the solver fails. That just feels a bit klutzy.

But, by all means, thanks again for building this fantastic solver!

Jo
3 years 4 months ago #63247

Please Log in or Create an account to join the conversation.

  • Posts: 106
  • Thank you received: 4

Replied by Heiko on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

@ Development Team

Thanks a lot!

Powered by

GNU / Linux
Git
KDE neon
KStars | EKOS | INDI

and some cheap hardware
3 years 4 months ago #63275
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20

Replied by David Allmon on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

I just upgraded and got the latest Kstars - Build: 2020-11-23T10:39:52Z. It won't solve. As the image comes in it prints "Image received", then Kstars goes away after about half a second. Here's everything I could gather on it.
Align settings:
 
[Align]
AlignExposure=3
AstrometryImageScaleHigh=26.396791751972
AstrometryImageScaleLow=19.939342695702
AstrometryPositionDE=56.736666666666665
AstrometryPositionRA=12.508333333333333
AstrometrySolverType=1
SolverBackend=0
SolverBinningIndex=1
SolverGotoOption=0
 
Align logfile:
 
#KStars version 3.5.0. Analyze log version 1.0.
 
AnalyzeStartTime,2020-11-27 18:21:56.699,MST
MountState,0.000,Idle
MountCoords,1.089,326.6833,-0.0161,196.0467,55.3889,-1,9.0333
AlignState,25.617,In Progress
 
 
 
syslog:
 
Nov 27 18:38:32 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: LX200 Autostar :  "[INFO] Device configuration saved. "
Nov 27 18:38:36 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: LX200 Autostar :  "[INFO] Time updated, updating planetary data... "
Nov 27 18:38:42 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: LX200 Autostar :  "[INFO] Site location updated to Lat  33:32:17 - Long  247:49:05 "
Nov 27 18:38:42 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: LX200 Autostar :  "[INFO] Observer location updated: Longitude (-112.182) Latitude (33.5381) "
Nov 27 18:38:44 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.ekos.align: "Capturing image..."
Nov 27 18:38:44 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.indi: SBIG CCD :  "[INFO] Taking 3.00s exposure on main camera... "
Nov 27 18:38:50 Poopster org.kde.kstars.desktop[30749]: Found one coordinate representation.
Nov 27 18:38:50 Poopster org.kde.kstars.desktop[30749]: org.kde.kstars.ekos.align: "Image received."
Nov 27 18:38:50 Poopster org.kde.kstars.desktop[30749]: kstars: symbol lookup error: /usr/local/lib/libgsl.so.23: undefined symbol: cblas_dnrm2
Nov 27 18:38:50 Poopster systemd[997]: gnome-launched-org.kde.kstars.desktop-30749.scope: Succeeded.
 

Does anyone know what might be causing this problem?

TIA
Dave
3 years 4 months ago #63514

Please Log in or Create an account to join the conversation.

  • Posts: 2877
  • Thank you received: 812

Replied by Rob Lancaster on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

This sounds to me like a library linking issue on your system. I am not 100% certain, but KStars is linked to GSL and GSL is linked to the CBLAS library. Either the link to CBLAS is broken somehow or maybe CBLAS is out of date? That is my best guess.
3 years 4 months ago #63519

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20

Replied by David Allmon on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

Thanks for the quick reply.

I thought that was the problem, but when I looked at the GSL library docs, it says they no longer link to gslcblas, leaving it to the application programmer to link the CBLAS library of their choice. I checked the indi cmake files and there is no mention of a CBLAS with any recognizable name. The libgsl has a 106 undefined symbols, all of them beginning with "cblas_".
To link against the library you need to specify both the main library and a supporting CBLAS library, which provides standard basic linear algebra subroutines. A suitable CBLAS implementation is provided in the library libgslcblas.a if your system does not provide one.


Perhaps there is an older version that includes cblas.

Thanks,
Dave
Last edit: 3 years 4 months ago by David Allmon.
3 years 4 months ago #63520

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20

Replied by David Allmon on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

For the time being I've gone back to the standard KStars release (Build: 2020-02-24T06:23:39Z). I'm going to rip everything out and reinstall during the week. I have clear cold skies and need to get some observing done.

Thanks for identifying the problem!

Dave
3 years 4 months ago #63533

Please Log in or Create an account to join the conversation.

  • Posts: 2877
  • Thank you received: 812

Replied by Rob Lancaster on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

Yeah, sorry I can't help more. If the problem was with StellarSolver or with the Mac version of KStars, I could help you a lot more, but I am not an expert on library linking on Linux systems.
3 years 4 months ago #63534

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133

Replied by Peter Sütterlin on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed


Not clear to me whether you use a self-compiled version, or installed a package? The gsl stuff seems to be in /usr/local, so it looks like that also is a self-installed one?
As I understand it, the gsl installation should (via gsl.pc) tell what should be used? At least on my system I have
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib64
includedir=/usr/include
GSL_CBLAS_LIB=-lgslcblas
 
Name: GSL
Description: GNU Scientific Library
Version: 2.6
Libs: -L/usr/lib64 -lgsl ${GSL_CBLAS_LIB} -lm -lm 
Cflags: -I/usr/include
and kstars uses that info to properly link against gsl and gslcblas.
3 years 4 months ago #63581

Please Log in or Create an account to join the conversation.

  • Posts: 194
  • Thank you received: 20

Replied by David Allmon on topic New Internal Solver for Mac, Windows, and Linux -- Testing/ Experiments needed

Well, everyone was right. Although I did not build anything, or install gsl or cblas0, they were messed up. I reinstalled them to no avail, as evidenced by the fact that siril blew up in exactly the same way KStars did while trying to register images. I reinstalled the OS, installed KStars and Siril and all is well. I am not using the bleeding-edge version, but I will tonight.

Thanks to all.
Dave
3 years 4 months ago #63588

Please Log in or Create an account to join the conversation.

Time to create page: 2.922 seconds