[Kstars-devel] Dealing with Proper Motion in extended catalogs

[James Bowlin]

On Mon March 31 2008, Akarsh Simha wrote:
> Hi James,
>
> > When we create the files of stars ordered by position
> > and then brightness, I propose that we include high PM stars in
> > multiple lists so that if any trixel crossed by the 20,000 year
> > line is visible, we are sure the star will be displayed.
>
> I don't understand this part. Could you elaborate?

The reason proper motion causes a problem is because it causes stars
to move from one trixel to another.  For example, imagine if we are
zoomed way in so only one trixel covers the entire display area with
room to spare (call it Trixel-A).  Suppose proper motion causes a star 
that was originally in a different trixel (Trixel-B) to move into the 
display area.  It would not show up because we are only showing the 
stars that are in the single Trixel-A that covers the display area.

What I did for the original implementation was to go through 
and "manually" re-index the high PM stars, which would remove the
star above from Trixel-B and put it into Trixel-A.

When most of the stars are stored on disk, this kind of manual 
correction because very, very expensive so I was looking for a quicker,
cheaper solution.  What I proposed was that instead of "manually" moving
the star from Trixel-A to Trixel-B, we keep two copies of the same star,
one in the Trixel-A list and another in the Trixel-B list and therefore
whenever either Trixel-A or Trixel-B is on screen, we are certain the
star will be drawn.

I outlined a procedure we could use to "easily" calculate all of the 
trixels every star would need to be listed in, in order to ensure it
always gets displayed despite the proper motion.


> > If my above estimate is accurate then this will increase the size
> > of the data files by 1% and also increase the time to draw the
> > stars by 1%. The beautiful thing is that if we are willing to
> > accept this 1% redundancy then no other work is required.  Problem
> > solved!  I think it would take longer to check for repeats than it
> > would to simply draw them.
>
> I definitely think it is worth the redundancy. Where does the 1%
> figure come from?

I estimated this number.  I tried to explain the procedure I went 
through in my previous three posts on this subject (two of those posts
are in the "Google SoC" thread").  I used two different techniques.
In the data subdirectory, I ran:

  $ ./sort-hip-by-pm.pl stars.dat > sorted-stars.dat

This created a new file containing our current catalog of 125,000 stars
sorted by the magnitude of PM.  It also added a leading column that 
contains the proper motion.  This new file starts with:

 7058.37 115255.82 +374358.1 +004003.7-005813.000109.2 06.4200.75G8 0
 6896.12 230547.17 -355122.7 +006767.3+001326.700303.9 07.3501.48M2 0
 6088.16 000520.29 -372106.0 +005615.5-002352.000220.1 08.5801.37K? 0
 5280.65 210650.84 +384429.4 +004155.1+003258.900287.1 05.2001.07K5 0
 5172.39 210652.19 +384403.9 +004107.4+003143.700285.4 06.0501.31K7 0
 4802.28 110320.61 +355853.3 -000580.2-004767.100392.4 07.4901.50M2 0

I used this file to answer the question: "How many stars in our catalog
will move more than 25 arcminutes in 10,000 years?"  Arithmetic tells us 
this is the same as asking "how many stars have a PM greater than 160 
milliarcseconds/year?"  I scrolled down in the file and found that only
3.4% of our stars will move move that fast/far.

But since our 512 level-3 trixels are about 10 degrees across, many 
stars that move more than 25 arcminutes would still not need to be
re-indexed because they would stay within their original trixel.

The second technique I used was to uncomment line 103 in the file 
highpmstarlist.cpp.  This causes KStars to report how many stars it 
re-indexes when the time jumps by a large amount.  I then kept changing 
the time and seeing the results print out.  Some very fast stars would
need to get re-indexed more than once during a 20,000 year interval
so they would end up in more than two trixel lists.

I estimated that the number of extra copies of stars we would have
to add to our data files was roughly equal to 1% of the total number
of stars.

> > If, for some reason, it becomes unacceptable to draw a few stars
> > more than once, then we can add a drawID flag to every star to
> > ensure that each star only gets drawn once just like we are already
> > doing for extended objects such as constellation lines and section
> > of the Milky Way.
>
> I didn't understand this either. Why would we end up drawing a few
> stars more than once?

In the scenario I gave above, imagine if the user zooms out or pans
the view so both Trixel-A and Trixel-B are visible.  In this case
the high PM star will get displayed twice.  It will get displayed
when all of the stars in Trixel-A are displayed and it will get
displayed again when all of the stars in Trixel-B get displayed.


> > Any thoughts?  Is a +/- 10,000 year time limit acceptable?

> I primarily use KStars purely for observations, but sometimes, such
> features are very useful to understand astronomy. I think we
> shouldn't impose such a limit. 

One thing to remember is that the proper motion we have for each
star is just the linear term.  I suspect that for very high PM's
and very long times into the past and the future, our simple linear
approximations will no longer be valid.

ISTM that a +/- 10,000 year time span is quite generous, and probably
few people will actually have a real need or desire to see the sky
at times further away than that.  If we are willing to accept this
limitation then the proper motion correction I proposed would be
pretty easy to implement since it just involves altering our data
files and doesn't require any extra code in KStars.

If a +/- 10,000 year limit is not acceptable then we are going to
either have to impose a larger time limit, like +/- 20,000 years,
thus requiring a larger penalty or we are going to have to figure
out a more clever scheme for handling proper motion.

If the +/- 10,000 limit is truly unacceptable, I'm willing to try to 
figure out a way to work around it, but I don't want to do a whole 
bunch of extra work that won't really get used much at all.

> Maybe, as you said earlier, the easy way to do things is to provide
> mag 12 stars only when time is in a small interval from now.

I'm offering a +/- 10,000 year limit on the mag 12 catalog. If you are 
primarily interested in observation, I would think this limit would be
more than acceptable.  I don't even know how to enter such far away 
dates into KStars using the existing "Set Time" window.


-- 
Peace, James