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

[Jason Harris]

Hello,

I meant to weigh in earlier.  I think James's solution to store high  
PM stars in multiple trixel-files is the way to go.  It gives us an  
elegant and bulletproof solution to a problem that would otherwise  
require a lot of complex code to work around.

+- 10,000 years should be no problem at all.  I would be surprised if  
more than a handful of users notice.  If pressed, we could also just  
stop painting faint stars if the date drifts outside the +- 10,000  
year interval, and pop up a KMessageBox explaining why (with a "Don't  
show again" checkbox).

regards,
Jason


On Mar 31, 2008, at 2:52 AM, James Bowlin wrote:

> 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
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel