[Kstars-devel] Binary star data loading accomplished in Branch!

[Akarsh Simha]

> > + Storing a pointer to the spectral type string in SkyObject::SpType,
> >   instead of the string itself.
> 
> This is a very minor point but I don't understand why you did this.
> Wouldn't it be better (faster, smaller) to store the string itself
> instead of a pointer?  

That was required so that we don't segfault when we do a memcpy(). I
only have a vague idea of how this saved us from segfaulting. I notice
that QString stores the data as a pointer to the data, so we might be
overwriting the same thing, but I don't know why it segfaulted.

> > Also replacing call to skyMesh::indexStar(...) by a simple method of
> > obtaining the trixel ID. [Works only for level 3 HTM]
> 
> That's fine that it only works with one mesh size.  If we want to work 
> with other mesh sizes, we will have to supply other data files.   

Yeah.

> > This seems to have brought down the time to load each star by a
> > factor of 6!! On my system, it now takes about 225 seconds on an
> > average to load 41560 stars, as against ~1745 seconds earlier. The
> > timing code is currently left as it is, for testing this out.
> 
> Great!!  I think you meant milliseconds instead of seconds.  If I did
> the arithmetic right, you've got the time down to 4.5 usecs/star.  This
> is wonderful.  This is roughly the same time it will take to do an 
> update() according to Jason's earlier measurements.  This means we 
> might be able to fully load a dynamic star in 10 usecs which meets our
> design goal.  Good work!

Yes, I meant milliseconds :)
I found it out to be 6 usecs/star with a calculator.

> > Some of the newly implemented code could be dangerous, as it uses
> > pointers at a very low level. This code is almost surely going to
> > result in a segmentation fault when we implement storage and
> > retrieval of observing log data and user-added links!
> 
> H'mm.  I see nothing wrong with using pointers at a very low level.
> IMO, this is a good thing.  It is true that if we screw up, we could
> cause segfaults but we just need to be a little careful.  

Yeah. We need to be careful. I doubt if it will work when we enable
saving of observing log data and user-added links.

> > > a perfect solution for dealing with them.  I think we may end up
> > > having to have the named stars kept in their own little list that
> > > gets drawn separately from the unnamed stars.   This may cause a
> > > much larger problem with nearly duplicated code, which might be
> > > "solved" by replacing the StarComponent class with
> > > PlainStarComponent and NamedStarComponent classes.
> >
> > Why will this be required? The if(...) statement in the
> > StarComponent::readData() seems to be doing a good job, atleast for
> > now.
> 
> Fine.  I thought you were the one who was worried about it.  I'm all
> for using the if(...).   The reason we might want two StarComponent
> classes (in the future) is for the draw() routines.  I don't now see
> how we can get away from having at least 2 draw() routines for the 
> stars.

I initially thought it was required. It seems to have worked out far
more smoothly than I thought it would. I'm sorry for that.

> > > One problem we face is that my idea of promoting dim named stars to
> > > the global stars group was a bad idea because it breaks the simple
> > > idea of ending the draw loop as soon as we get a star dimmer than a
> > > threshold magnitude.
> >
> > How will it break that? We aren't sorting the list of names by
> > magnitude, but we are sorting them first by HTM index and then by
> > magnitude.
> 
> As we were recently reminded, the list of stars for any one trixel
> must be sorted by magnitude.  If the global stars are all brighter than
> the dynamic per-trixel stars then everything is fine.  The problem 
> occurs when we "promote" a dim named star to the global star file.  
> This breaks the strict ordering by magnitude.  If ALL named stars will 
> naturally land in the global star file (because they are bright enough) 
> then this issue does not exist.  Otherwise, I think the simplest 
> solution is to keep the named stars in their own separate list.

Yes, but aren't we going to handle "global + named" stars together
separately from the "dynamic" stars?

> > We could do the good old reindexing on global stars. It shouldn't
> > take much. If we really want to save on that, then we should probably
> > be putting HD numbers or (if they don't exist) some other unique
> > named ID in our star name files.
> 
> I don't think adding the HD number will help solve this problem, but
> I think it is a good idea to have the HD number in the starname file 
> anyway for other reasons (error detection).

Will a HD number not help, because it cannot be searched easily in the
starnames.dat file?

> > > Right now, I'm leaning toward keeping the named stars in their own
> > > list (StarIndex structure) that gets drawn separately from the rest
> > > of the stars.  The named stars would get treated the way we are
> > > currently treating all the stars.  They would even have
> > > HighPMStarLists and if necessary, we could re-index all the named
> > > stars.
> >
> > Why would this be necessary, again?
> 
> Proper motion.  For the vast number of unnamed stars, we are planning on
> simply duplicating a few high PM stars to deal with proper motion.  I am
> worried that duplicating named stars may cause unwanted interactions 
> with the rest of KStars.  If duplicating named stars will not cause any 
> problems with KStars then we can treat all the stars the same and 
> things are easy and we don't have to worry about any of what I'm about 
> to say below.

One solution is to put a UID in the name data file, as I mentioned
earlier, and quickly look that up. The HD number, as I infer from this
source,
http://www.willbell.com/software/hypersky/hd.htm
goes upto a maximum of about 360000. We could use the remaining bits
to hold a UID for named stars. The lower 19 ~ 20 bits could be
provided for the HD numbers and the upper 11 ~ 12 bits for the UID for
named stars. How does this work?

That way, we can duplicate star entries and still be able to look up
star names randomly, by fseeking to a position that we can compute
based on the sequentially assigned UIDs.

> No.  I'm saying let's use constructors for named stars and only use the
> memcpy() trick for unnamed stars.

That's fine.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20080604/414c4f0a/attachment.pgp