Thread: [Celestia-developers] stars.dat
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Andrew T. <ajt...@go...> - 2008-07-09 21:56:07
|
The current version of stars.dat has problems of erroneous assumptions about optical binary stars. To address this issue, I have rewritten the stars.dat generation code in Perl. Instead of hybrid data drawn from the Hipparcos main catalogue (hip_main.dat), the Tycho-1 catalogue (tyc_main.dat) and the Hipparcos doubles and multiples components solutions (h_dm_com.dat)*, the script generates the stars.dat file only from the hip_main.dat file. I have also rewritten the spectral type guessing code, which is used when the spectral type entry in the Hipparcos catalogue is missing or unparseable, to use B-V values from Lang (2001). * these files available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/239 I posted the Perl script in question as an attachment to a post on the Celestia forums at http://www.shatters.net/forum/viewtopic.php?p=105418#p105418 Comments/suggestions? Andrew |
From: Fridger S. <fri...@de...> - 2008-07-09 22:13:17
|
Andrew, that's nice. What kind of error checks did you perform? Guaranteeing intrinsic correctness of this basic dataset for Celestia is a task of formost importance! Fridger Andrew Tribick wrote: > The current version of stars.dat has problems of erroneous assumptions > about optical binary stars. To address this issue, I have rewritten > the stars.dat generation code in Perl. Instead of hybrid data drawn > from the Hipparcos main catalogue (hip_main.dat), the Tycho-1 > catalogue (tyc_main.dat) and the Hipparcos doubles and multiples > components solutions (h_dm_com.dat)*, the script generates the > stars.dat file only from the hip_main.dat file. I have also rewritten > the spectral type guessing code, which is used when the spectral type > entry in the Hipparcos catalogue is missing or unparseable, to use B-V > values from Lang (2001). > > * these files available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/239 > > I posted the Perl script in question as an attachment to a post on the > Celestia forums at > http://www.shatters.net/forum/viewtopic.php?p=105418#p105418 > > Comments/suggestions? > > Andrew > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Andrew T. <ajt...@go...> - 2008-07-09 22:36:07
|
The error checks are based on the ones originally used in the buildstardb.cpp file in stars.dat. Most of the checks are done in the TestDubious() subroutine in the code, in summary: stars without Vmag information are rejected. stars with negative parallaxes, except for naked-eye stars (Vmag<6) which are "fixed" at 0.4 (this fixing can be switched off if desired) stars with very large errors in position (sqrt(error in RA^2 + error in Dec^2)>40 mas) are rejected. Apart from the previous three criteria which result in immediate rejection, for each star points are awarded for small parallaxes (<0.4 mas), large parallax errors (w.r.t. the actual value), large errors in RA/Dec... above a certain number of points (defined in the CheckStars() subroutine), the star is rejected. It may of course be necessary/desirable to tweak the various values in the code. Andrew 2008/7/9 Fridger Schrempp <fri...@de...>: > Andrew, > > that's nice. What kind of error checks did you perform? Guaranteeing > intrinsic correctness of this basic dataset for Celestia is a task of > formost importance! > > Fridger > |
From: Fridger S. <fri...@de...> - 2008-07-09 23:24:58
|
Good, but what I mainly meant were the tests that make sure that the stars you RETAIN have the data values you think they have! PERL is great, but also tricky ;-) Fridger Andrew Tribick wrote: > The error checks are based on the ones originally used in the > buildstardb.cpp file in stars.dat. Most of the checks are done in the > TestDubious() subroutine in the code, in summary: > > stars without Vmag information are rejected. > stars with negative parallaxes, except for naked-eye stars (Vmag<6) > which are "fixed" at 0.4 (this fixing can be switched off if desired) > stars with very large errors in position (sqrt(error in RA^2 + error > in Dec^2)>40 mas) are rejected. > > Apart from the previous three criteria which result in immediate > rejection, for each star points are awarded for small parallaxes (<0.4 > mas), large parallax errors (w.r.t. the actual value), large errors in > RA/Dec... above a certain number of points (defined in the > CheckStars() subroutine), the star is rejected. > > It may of course be necessary/desirable to tweak the various values in the code. > > Andrew > > 2008/7/9 Fridger Schrempp <fri...@de...>: >> Andrew, >> >> that's nice. What kind of error checks did you perform? Guaranteeing >> intrinsic correctness of this basic dataset for Celestia is a task of >> formost importance! >> >> Fridger >> > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Andrew T. <ajt...@go...> - 2008-07-10 11:13:27
|
I'd already run a format validation program on the hip_main.dat file to make sure all the field breaks are where I expect them to be and that the values have the format I expect the input to be in - this showed no problems with the input file. If desirable I could merge the validation code into the stars.dat builder. The test cases I've tried also come out with expected results. Andrew 2008/7/10 Fridger Schrempp <fri...@de...>: > Good, but what I mainly meant were the tests that make sure that the stars > you RETAIN have the data values you think they have! PERL is great, but also > tricky ;-) > > Fridger > > Andrew Tribick wrote: >> >> The error checks are based on the ones originally used in the >> buildstardb.cpp file in stars.dat. Most of the checks are done in the >> TestDubious() subroutine in the code, in summary: >> >> stars without Vmag information are rejected. >> stars with negative parallaxes, except for naked-eye stars (Vmag<6) >> which are "fixed" at 0.4 (this fixing can be switched off if desired) >> stars with very large errors in position (sqrt(error in RA^2 + error >> in Dec^2)>40 mas) are rejected. >> >> Apart from the previous three criteria which result in immediate >> rejection, for each star points are awarded for small parallaxes (<0.4 >> mas), large parallax errors (w.r.t. the actual value), large errors in >> RA/Dec... above a certain number of points (defined in the >> CheckStars() subroutine), the star is rejected. >> >> It may of course be necessary/desirable to tweak the various values in the >> code. >> >> Andrew >> >> 2008/7/9 Fridger Schrempp <fri...@de...>: >>> >>> Andrew, >>> >>> that's nice. What kind of error checks did you perform? Guaranteeing >>> intrinsic correctness of this basic dataset for Celestia is a task of >>> formost importance! >>> >>> Fridger >>> >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > |
From: Chris L. <cl...@gm...> - 2008-07-10 21:10:55
|
Andrew, This all sounds good. I'm wondering how many stars pass the criteria? Is there a significant change from the current stars.dat? Also, are there any naked eye stars that get rejected for reasons other than bad parallaxes, for example large errors in position? --Chris On Wed, Jul 9, 2008 at 3:36 PM, Andrew Tribick <ajt...@go...> wrote: > The error checks are based on the ones originally used in the > buildstardb.cpp file in stars.dat. Most of the checks are done in the > TestDubious() subroutine in the code, in summary: > > stars without Vmag information are rejected. > stars with negative parallaxes, except for naked-eye stars (Vmag<6) > which are "fixed" at 0.4 (this fixing can be switched off if desired) > stars with very large errors in position (sqrt(error in RA^2 + error > in Dec^2)>40 mas) are rejected. > > Apart from the previous three criteria which result in immediate > rejection, for each star points are awarded for small parallaxes (<0.4 > mas), large parallax errors (w.r.t. the actual value), large errors in > RA/Dec... above a certain number of points (defined in the > CheckStars() subroutine), the star is rejected. > > It may of course be necessary/desirable to tweak the various values in the code. > > Andrew > > 2008/7/9 Fridger Schrempp <fri...@de...>: >> Andrew, >> >> that's nice. What kind of error checks did you perform? Guaranteeing >> intrinsic correctness of this basic dataset for Celestia is a task of >> formost importance! >> >> Fridger >> > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > |
From: Andrew T. <ajt...@go...> - 2008-07-10 21:48:28
|
Statistics from a modified script which adds counter for dropped bright (using Vmag<6 criterion) stars: ---------- Drop-level 0: Fix parallaxes <0.4 (including negative parallaxes), by setting parallax to 0.4. Good stars (included): 117431 Dubious stars (included): 222 Bad stars (dropped): 565 of which 7 are bright =>Total stars included: 117653 + Sun ---------- Drop-level 1 (DEFAULT) Fix parallaxes <0.4 (including negative parallaxes) of bright stars ONLY. Good stars (included): 111465 Dubious stars (included): 2024 Bad stars (dropped): 4729 of which 7 are bright =>Total stars included: 113489 + Sun ---------- Drop-level 2 Do not fix any parallaxes Good stars (included): 111426 Dubious stars (included): 2041 Bad stars (dropped): 4751 of which 29 are bright =>Total stars included: 113467 + Sun ---------- Drop-level 3 Drop dubious stars Good stars (included): 111426 Dubious+Bad stars (dropped): 6792 of which 49 are bright =>Total stars included: 111426 + Sun ---------- SVN revision 2800 stars.dat+stars.txt =>Total stars included: 112518 + Sun Andrew 2008/7/10 Chris Laurel <cl...@gm...>: > Andrew, > > This all sounds good. I'm wondering how many stars pass the criteria? > Is there a significant change from the current stars.dat? > > Also, are there any naked eye stars that get rejected for reasons > other than bad parallaxes, for example large errors in position? > > --Chris > |
From: Chris L. <cl...@gm...> - 2008-07-10 21:58:08
|
Interesting--it looks like the great majority of stars are kept, but I feel very uncomfortable dropping any stars that would be visible to the unaided eye. Do you know what criterion is causing these bright stars to be excluded at drop-level 1? It can't be parallax, and it can't be a missing Vmag (otherwise we wouldn't know that the stars were bright), so I guess it must be errors in position? I'll try playing with the script myself now. --Chris On Thu, Jul 10, 2008 at 2:48 PM, Andrew Tribick <ajt...@go...> wrote: > Statistics from a modified script which adds counter for dropped > bright (using Vmag<6 criterion) stars: > > ---------- > Drop-level 0: > Fix parallaxes <0.4 (including negative parallaxes), by setting parallax to 0.4. > > Good stars (included): 117431 > Dubious stars (included): 222 > Bad stars (dropped): 565 of which 7 are bright > =>Total stars included: 117653 + Sun > ---------- > Drop-level 1 (DEFAULT) > Fix parallaxes <0.4 (including negative parallaxes) of bright stars ONLY. > > Good stars (included): 111465 > Dubious stars (included): 2024 > Bad stars (dropped): 4729 of which 7 are bright > =>Total stars included: 113489 + Sun > ---------- > Drop-level 2 > Do not fix any parallaxes > Good stars (included): 111426 > Dubious stars (included): 2041 > Bad stars (dropped): 4751 of which 29 are bright > =>Total stars included: 113467 + Sun > ---------- > Drop-level 3 > Drop dubious stars > > Good stars (included): 111426 > Dubious+Bad stars (dropped): 6792 of which 49 are bright > =>Total stars included: 111426 + Sun > ---------- > SVN revision 2800 > stars.dat+stars.txt > > =>Total stars included: 112518 + Sun > > Andrew > > 2008/7/10 Chris Laurel <cl...@gm...>: >> Andrew, >> >> This all sounds good. I'm wondering how many stars pass the criteria? >> Is there a significant change from the current stars.dat? >> >> Also, are there any naked eye stars that get rejected for reasons >> other than bad parallaxes, for example large errors in position? >> >> --Chris >> > |
From: Andrew T. <ajt...@go...> - 2008-07-10 22:30:17
|
The 7 rejected stars at drop-levels 0 and 1 are: 55203 = ksi Uma (no measured parallax) 63121 = alf CVn B (large position errors) 71681 = alf Cen B (large position errors) 74376 = kap01 Lup (large position errors) 78727 = ksi Sco (no measured parallax) 92951 = tet02 Ser (large position errors) 115125 = HD 219834B (according to SIMBAD, rejected from HIP) Andrew 2008/7/10 Chris Laurel <cl...@gm...>: > Interesting--it looks like the great majority of stars are kept, but I > feel very uncomfortable dropping any stars that would be visible to > the unaided eye. Do you know what criterion is causing these bright > stars to be excluded at drop-level 1? It can't be parallax, and it > can't be a missing Vmag (otherwise we wouldn't know that the stars > were bright), so I guess it must be errors in position? I'll try > playing with the script myself now. > > --Chris > > On Thu, Jul 10, 2008 at 2:48 PM, Andrew Tribick > <ajt...@go...> wrote: >> Statistics from a modified script which adds counter for dropped >> bright (using Vmag<6 criterion) stars: >> >> ---------- >> Drop-level 0: >> Fix parallaxes <0.4 (including negative parallaxes), by setting parallax to 0.4. >> >> Good stars (included): 117431 >> Dubious stars (included): 222 >> Bad stars (dropped): 565 of which 7 are bright >> =>Total stars included: 117653 + Sun >> ---------- >> Drop-level 1 (DEFAULT) >> Fix parallaxes <0.4 (including negative parallaxes) of bright stars ONLY. >> >> Good stars (included): 111465 >> Dubious stars (included): 2024 >> Bad stars (dropped): 4729 of which 7 are bright >> =>Total stars included: 113489 + Sun >> ---------- >> Drop-level 2 >> Do not fix any parallaxes >> Good stars (included): 111426 >> Dubious stars (included): 2041 >> Bad stars (dropped): 4751 of which 29 are bright >> =>Total stars included: 113467 + Sun >> ---------- >> Drop-level 3 >> Drop dubious stars >> >> Good stars (included): 111426 >> Dubious+Bad stars (dropped): 6792 of which 49 are bright >> =>Total stars included: 111426 + Sun >> ---------- >> SVN revision 2800 >> stars.dat+stars.txt >> >> =>Total stars included: 112518 + Sun >> >> Andrew >> >> 2008/7/10 Chris Laurel <cl...@gm...>: >>> Andrew, >>> >>> This all sounds good. I'm wondering how many stars pass the criteria? >>> Is there a significant change from the current stars.dat? >>> >>> Also, are there any naked eye stars that get rejected for reasons >>> other than bad parallaxes, for example large errors in position? >>> >>> --Chris >>> >> > |
From: Chris L. <cl...@gm...> - 2008-07-10 23:37:34
|
Interesting. We definitely have to figure out a way to incorporate these stars in Celestia. Xi UMa and Alpha Cen B are already in nearstars.stc, so nothing special needs to be done from them. HIP 115215 was rejected? It's unclear to me exactly what this means. The star is real, is it not? Xi Sco is a multiple system (at least 5 components!) with a combined visual magnitude of 4.16--too prominent to just omit. I wonder if the that fact that it's a multiple star system complicated the parallax measurement. Kappa1 Lup is even brighter than Xi Sco: vmag = 3.85 The last two stars are fainter: Theta2 Ser: vmag = 4.98 Alpha CVn B: vmag = 5.60 ...but they should still be included. I think that we should consider relaxing the maximum allowed error in position. Star positions are stored as single precision floating point values, giving 23 bits of precision (not including the sign bit). Thus, the storage format limits us to (360*60*60)/(2^23) arcseconds, or about 154 mas. The maximum error should be half of this--still about twice as large as the currently allowed combined error for RA and declination. Checking SIMBAD, it looks like Kappa1 Lup would make the cut with a relaxed position error allowance, but Theta2 Ser and Alpha CVn B still fail. --Chris On Thu, Jul 10, 2008 at 3:30 PM, Andrew Tribick <ajt...@go...> wrote: > The 7 rejected stars at drop-levels 0 and 1 are: > > 55203 = ksi Uma (no measured parallax) > 63121 = alf CVn B (large position errors) > 71681 = alf Cen B (large position errors) > 74376 = kap01 Lup (large position errors) > 78727 = ksi Sco (no measured parallax) > 92951 = tet02 Ser (large position errors) > 115125 = HD 219834B (according to SIMBAD, rejected from HIP) > > Andrew > > 2008/7/10 Chris Laurel <cl...@gm...>: >> Interesting--it looks like the great majority of stars are kept, but I >> feel very uncomfortable dropping any stars that would be visible to >> the unaided eye. Do you know what criterion is causing these bright >> stars to be excluded at drop-level 1? It can't be parallax, and it >> can't be a missing Vmag (otherwise we wouldn't know that the stars >> were bright), so I guess it must be errors in position? I'll try >> playing with the script myself now. >> >> --Chris >> >> On Thu, Jul 10, 2008 at 2:48 PM, Andrew Tribick >> <ajt...@go...> wrote: >>> Statistics from a modified script which adds counter for dropped >>> bright (using Vmag<6 criterion) stars: >>> >>> ---------- >>> Drop-level 0: >>> Fix parallaxes <0.4 (including negative parallaxes), by setting parallax to 0.4. >>> >>> Good stars (included): 117431 >>> Dubious stars (included): 222 >>> Bad stars (dropped): 565 of which 7 are bright >>> =>Total stars included: 117653 + Sun >>> ---------- >>> Drop-level 1 (DEFAULT) >>> Fix parallaxes <0.4 (including negative parallaxes) of bright stars ONLY. >>> >>> Good stars (included): 111465 >>> Dubious stars (included): 2024 >>> Bad stars (dropped): 4729 of which 7 are bright >>> =>Total stars included: 113489 + Sun >>> ---------- >>> Drop-level 2 >>> Do not fix any parallaxes >>> Good stars (included): 111426 >>> Dubious stars (included): 2041 >>> Bad stars (dropped): 4751 of which 29 are bright >>> =>Total stars included: 113467 + Sun >>> ---------- >>> Drop-level 3 >>> Drop dubious stars >>> >>> Good stars (included): 111426 >>> Dubious+Bad stars (dropped): 6792 of which 49 are bright >>> =>Total stars included: 111426 + Sun >>> ---------- >>> SVN revision 2800 >>> stars.dat+stars.txt >>> >>> =>Total stars included: 112518 + Sun >>> >>> Andrew >>> >>> 2008/7/10 Chris Laurel <cl...@gm...>: >>>> Andrew, >>>> >>>> This all sounds good. I'm wondering how many stars pass the criteria? >>>> Is there a significant change from the current stars.dat? >>>> >>>> Also, are there any naked eye stars that get rejected for reasons >>>> other than bad parallaxes, for example large errors in position? >>>> >>>> --Chris >>>> >>> >> > |
From: Andrew T. <ajt...@go...> - 2008-07-11 13:09:46
|
Thanks for the advice on the position error thresholds. revised.stc does seem like the best place for re-adding these bright stars. As for HIP 115125, which was not measured by Hipparcos (so no parallax is given in the HIP record), according to the notes section of its SIMBAD entry it forms a common proper motion pair with HIP 115126 (=94 Aqr), so we could use the parallax from there. I'll upload an updated version of the script later today, any further suggestions to incorporate? Andrew 2008/7/11 Chris Laurel <cl...@gm...>: > Interesting. We definitely have to figure out a way to incorporate > these stars in Celestia. Xi UMa and Alpha Cen B are already in > nearstars.stc, so nothing special needs to be done from them. > > HIP 115215 was rejected? It's unclear to me exactly what this means. > The star is real, is it not? > > Xi Sco is a multiple system (at least 5 components!) with a combined > visual magnitude of 4.16--too prominent to just omit. I wonder if the > that fact that it's a multiple star system complicated the parallax > measurement. > > Kappa1 Lup is even brighter than Xi Sco: vmag = 3.85 > > The last two stars are fainter: > Theta2 Ser: vmag = 4.98 > Alpha CVn B: vmag = 5.60 > ...but they should still be included. > > I think that we should consider relaxing the maximum allowed error in > position. Star positions are stored as single precision floating point > values, giving 23 bits of precision (not including the sign bit). > Thus, the storage format limits us to (360*60*60)/(2^23) arcseconds, > or about 154 mas. The maximum error should be half of this--still > about twice as large as the currently allowed combined error for RA > and declination. Checking SIMBAD, it looks like Kappa1 Lup would make > the cut with a relaxed position error allowance, but Theta2 Ser and > Alpha CVn B still fail. > > --Chris > > On Thu, Jul 10, 2008 at 3:30 PM, Andrew Tribick > <ajt...@go...> wrote: >> The 7 rejected stars at drop-levels 0 and 1 are: >> >> 55203 = ksi Uma (no measured parallax) >> 63121 = alf CVn B (large position errors) >> 71681 = alf Cen B (large position errors) >> 74376 = kap01 Lup (large position errors) >> 78727 = ksi Sco (no measured parallax) >> 92951 = tet02 Ser (large position errors) >> 115125 = HD 219834B (according to SIMBAD, rejected from HIP) >> >> Andrew >> >> 2008/7/10 Chris Laurel <cl...@gm...>: >>> Interesting--it looks like the great majority of stars are kept, but I >>> feel very uncomfortable dropping any stars that would be visible to >>> the unaided eye. Do you know what criterion is causing these bright >>> stars to be excluded at drop-level 1? It can't be parallax, and it >>> can't be a missing Vmag (otherwise we wouldn't know that the stars >>> were bright), so I guess it must be errors in position? I'll try >>> playing with the script myself now. >>> >>> --Chris >>> >>> On Thu, Jul 10, 2008 at 2:48 PM, Andrew Tribick >>> <ajt...@go...> wrote: >>>> Statistics from a modified script which adds counter for dropped >>>> bright (using Vmag<6 criterion) stars: >>>> >>>> ---------- >>>> Drop-level 0: >>>> Fix parallaxes <0.4 (including negative parallaxes), by setting parallax to 0.4. >>>> >>>> Good stars (included): 117431 >>>> Dubious stars (included): 222 >>>> Bad stars (dropped): 565 of which 7 are bright >>>> =>Total stars included: 117653 + Sun >>>> ---------- >>>> Drop-level 1 (DEFAULT) >>>> Fix parallaxes <0.4 (including negative parallaxes) of bright stars ONLY. >>>> >>>> Good stars (included): 111465 >>>> Dubious stars (included): 2024 >>>> Bad stars (dropped): 4729 of which 7 are bright >>>> =>Total stars included: 113489 + Sun >>>> ---------- >>>> Drop-level 2 >>>> Do not fix any parallaxes >>>> Good stars (included): 111426 >>>> Dubious stars (included): 2041 >>>> Bad stars (dropped): 4751 of which 29 are bright >>>> =>Total stars included: 113467 + Sun >>>> ---------- >>>> Drop-level 3 >>>> Drop dubious stars >>>> >>>> Good stars (included): 111426 >>>> Dubious+Bad stars (dropped): 6792 of which 49 are bright >>>> =>Total stars included: 111426 + Sun >>>> ---------- >>>> SVN revision 2800 >>>> stars.dat+stars.txt >>>> >>>> =>Total stars included: 112518 + Sun >>>> >>>> Andrew >>>> >>>> 2008/7/10 Chris Laurel <cl...@gm...>: >>>>> Andrew, >>>>> >>>>> This all sounds good. I'm wondering how many stars pass the criteria? >>>>> Is there a significant change from the current stars.dat? >>>>> >>>>> Also, are there any naked eye stars that get rejected for reasons >>>>> other than bad parallaxes, for example large errors in position? >>>>> >>>>> --Chris >>>>> >>>> >>> >> > |
From: Andrew T. <ajt...@go...> - 2008-07-11 21:57:35
|
New updated version available at http://www.shatters.net/forum/viewtopic.php?p=105483#p105483 Using a cutoff threshold of 75 mas rejects only ksi UMa, ksi Sco and HIP 115125 (i.e. the ones without parallax measurements) among the bright stars at drop-level 1. New tallies: Drop-level 0: included = 117841, dropped = 377 (incl. 3 bright) Drop-level 1: included = 113637, dropped = 4581 (incl. 3 bright) Drop-level 2: included = 113615, dropped = 4603 (incl. 25 bright) Drop-level 3: included = 111638, dropped = 6580 (incl. 43 bright) Andrew 2008/7/11 Andrew Tribick <ajt...@go...>: > Thanks for the advice on the position error thresholds. > > revised.stc does seem like the best place for re-adding these bright > stars. As for HIP 115125, which was not measured by Hipparcos (so no > parallax is given in the HIP record), according to the notes section > of its SIMBAD entry it forms a common proper motion pair with HIP > 115126 (=94 Aqr), so we could use the parallax from there. > > I'll upload an updated version of the script later today, any further > suggestions to incorporate? > > Andrew > > 2008/7/11 Chris Laurel <cl...@gm...>: >> Interesting. We definitely have to figure out a way to incorporate >> these stars in Celestia. Xi UMa and Alpha Cen B are already in >> nearstars.stc, so nothing special needs to be done from them. >> >> HIP 115215 was rejected? It's unclear to me exactly what this means. >> The star is real, is it not? >> >> Xi Sco is a multiple system (at least 5 components!) with a combined >> visual magnitude of 4.16--too prominent to just omit. I wonder if the >> that fact that it's a multiple star system complicated the parallax >> measurement. >> >> Kappa1 Lup is even brighter than Xi Sco: vmag = 3.85 >> >> The last two stars are fainter: >> Theta2 Ser: vmag = 4.98 >> Alpha CVn B: vmag = 5.60 >> ...but they should still be included. >> >> I think that we should consider relaxing the maximum allowed error in >> position. Star positions are stored as single precision floating point >> values, giving 23 bits of precision (not including the sign bit). >> Thus, the storage format limits us to (360*60*60)/(2^23) arcseconds, >> or about 154 mas. The maximum error should be half of this--still >> about twice as large as the currently allowed combined error for RA >> and declination. Checking SIMBAD, it looks like Kappa1 Lup would make >> the cut with a relaxed position error allowance, but Theta2 Ser and >> Alpha CVn B still fail. >> >> --Chris >> >> On Thu, Jul 10, 2008 at 3:30 PM, Andrew Tribick >> <ajt...@go...> wrote: >>> The 7 rejected stars at drop-levels 0 and 1 are: >>> >>> 55203 = ksi Uma (no measured parallax) >>> 63121 = alf CVn B (large position errors) >>> 71681 = alf Cen B (large position errors) >>> 74376 = kap01 Lup (large position errors) >>> 78727 = ksi Sco (no measured parallax) >>> 92951 = tet02 Ser (large position errors) >>> 115125 = HD 219834B (according to SIMBAD, rejected from HIP) >>> >>> Andrew >>> >>> 2008/7/10 Chris Laurel <cl...@gm...>: >>>> Interesting--it looks like the great majority of stars are kept, but I >>>> feel very uncomfortable dropping any stars that would be visible to >>>> the unaided eye. Do you know what criterion is causing these bright >>>> stars to be excluded at drop-level 1? It can't be parallax, and it >>>> can't be a missing Vmag (otherwise we wouldn't know that the stars >>>> were bright), so I guess it must be errors in position? I'll try >>>> playing with the script myself now. >>>> >>>> --Chris >>>> >>>> On Thu, Jul 10, 2008 at 2:48 PM, Andrew Tribick >>>> <ajt...@go...> wrote: >>>>> Statistics from a modified script which adds counter for dropped >>>>> bright (using Vmag<6 criterion) stars: >>>>> >>>>> ---------- >>>>> Drop-level 0: >>>>> Fix parallaxes <0.4 (including negative parallaxes), by setting parallax to 0.4. >>>>> >>>>> Good stars (included): 117431 >>>>> Dubious stars (included): 222 >>>>> Bad stars (dropped): 565 of which 7 are bright >>>>> =>Total stars included: 117653 + Sun >>>>> ---------- >>>>> Drop-level 1 (DEFAULT) >>>>> Fix parallaxes <0.4 (including negative parallaxes) of bright stars ONLY. >>>>> >>>>> Good stars (included): 111465 >>>>> Dubious stars (included): 2024 >>>>> Bad stars (dropped): 4729 of which 7 are bright >>>>> =>Total stars included: 113489 + Sun >>>>> ---------- >>>>> Drop-level 2 >>>>> Do not fix any parallaxes >>>>> Good stars (included): 111426 >>>>> Dubious stars (included): 2041 >>>>> Bad stars (dropped): 4751 of which 29 are bright >>>>> =>Total stars included: 113467 + Sun >>>>> ---------- >>>>> Drop-level 3 >>>>> Drop dubious stars >>>>> >>>>> Good stars (included): 111426 >>>>> Dubious+Bad stars (dropped): 6792 of which 49 are bright >>>>> =>Total stars included: 111426 + Sun >>>>> ---------- >>>>> SVN revision 2800 >>>>> stars.dat+stars.txt >>>>> >>>>> =>Total stars included: 112518 + Sun >>>>> >>>>> Andrew >>>>> >>>>> 2008/7/10 Chris Laurel <cl...@gm...>: >>>>>> Andrew, >>>>>> >>>>>> This all sounds good. I'm wondering how many stars pass the criteria? >>>>>> Is there a significant change from the current stars.dat? >>>>>> >>>>>> Also, are there any naked eye stars that get rejected for reasons >>>>>> other than bad parallaxes, for example large errors in position? >>>>>> >>>>>> --Chris >>>>>> >>>>> >>>> >>> >> > |
From: Andrew T. <ajt...@go...> - 2008-07-12 15:36:53
|
I've been investigating the new reduction of the Hipparcos data (now available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... It looks like the parallax errors have either decreased or remained the same, which is good. Defining "good" parallaxes as those >0.4, the changes original (HIP1) -> new (HIP2) are: Changes for the better: negative->good = 2387 negative->low = 1858 low->good = 1294 Changes for the worse: good->negative = 4994 good->low = 1780 low->negative = 525 The question now is what to do about the latter three cases. 1) Use HIP2 regardless 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve parallax, use data from HIP1. 3) In the cases where the change is for the worse, use HIP1. 4) other I'm leaning towards option (2) myself. Andrew |
From: Chris L. <cl...@gm...> - 2008-07-14 18:04:13
|
It's nice to see that new reduction is finally available. The disturbing thing is that quite a few formerly "good" parallaxes are now negative. Option 2 gives us the largest number of useful parallaxes, but it seems difficult to defend on theoretical grounds. Shouldn't we always use the value with the lowest error? --Chris On Sat, Jul 12, 2008 at 8:36 AM, Andrew Tribick <ajt...@go...> wrote: > I've been investigating the new reduction of the Hipparcos data (now > available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... > > It looks like the parallax errors have either decreased or remained > the same, which is good. > > Defining "good" parallaxes as those >0.4, the changes original (HIP1) > -> new (HIP2) are: > > Changes for the better: > negative->good = 2387 > negative->low = 1858 > low->good = 1294 > > Changes for the worse: > good->negative = 4994 > good->low = 1780 > low->negative = 525 > > The question now is what to do about the latter three cases. > 1) Use HIP2 regardless > 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve > parallax, use data from HIP1. > 3) In the cases where the change is for the worse, use HIP1. > 4) other > > I'm leaning towards option (2) myself. > > Andrew > |
From: Selden E B. Jr <se...@le...> - 2008-07-14 18:26:12
|
The appearance of negative parallaxes when improved data reduction algorithms were applied suggests to me that the previous corresponding positive parallax values may have been incorrect. I suspect that it would be inappropriate to mix values from the two catalogs. I also suspect that there might be some discussion in the book about the new negative parallax values. I'm sure they won't have been overlooked. s. > It's nice to see that new reduction is finally available. The > disturbing thing is that quite a few formerly "good" parallaxes are > now negative. > Option 2 gives us the largest number of useful parallaxes, but it > seems difficult to defend on theoretical grounds. Shouldn't we always > use the value with the lowest error? > --Chris > On Sat, Jul 12, 2008 at 8:36 AM, Andrew Tribick > <ajt...@go...> wrote: > > I've been investigating the new reduction of the Hipparcos data (now > > available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... > > > > It looks like the parallax errors have either decreased or remained > > the same, which is good. > > > > Defining "good" parallaxes as those >0.4, the changes original (HIP1) > > -> new (HIP2) are: > > > > Changes for the better: > > negative->good = 2387 > > negative->low = 1858 > > low->good = 1294 > > > > Changes for the worse: > > good->negative = 4994 > > good->low = 1780 > > low->negative = 525 > > > > The question now is what to do about the latter three cases. > > 1) Use HIP2 regardless > > 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve > > parallax, use data from HIP1. > > 3) In the cases where the change is for the worse, use HIP1. > > 4) other > > > > I'm leaning towards option (2) myself. > > > > Andrew > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Andrew T. <ajt...@go...> - 2008-07-16 08:14:02
|
I've rewritten the generator to use the new Hipparcos dataset: the old database is only used for Vmag, BTmag, VTmag and SpType which are not given in the new revision. The script also generates a stars.txt file. Given the existence of nearstars.stc, do we need to have the Sun in stars.dat/.txt? (It cannot be represented in stars.txt without displacing it from the origin because of the use of apparent magnitude in that file, so the current script does not include it) Script on shatters.net at http://www.shatters.net/forum/viewtopic.php?p=105590#p105590 Andrew 2008/7/14 Andrew Tribick <ajt...@go...>: > From links on the CDS, I found http://fr.arxiv.org/abs/0708.1752 > "Validation of the new Hipparcos reduction" by van Leeuwen which > includes discussion of the negative parallaxes. > > Seemingly therefore it would make sense to use the new reduction for > position and parallax information despite the fact this would lead to > a smaller number of stars included. Spectral types are not listed in > the new reduction, so would have to be sourced from hip_main.dat. > > Would it be better to use the Vmag in the original hip_main.dat (which > appears to be a catalogue-derived value, rather than measured by > Hipparcos), or transform from Hp and B-V using > http://www.tass-survey.org/tass/catalogs/tycho.html ? > > Andrew > > 2008/7/14 Fridger Schrempp <fri...@de...>: >> I think Selden's arguing in the right direction. First of all, someone should >> UNDERSTAND what the physical basis was that allowed to reduce the initial >> uncertainties so significantly. Was it merely statistically based or was there >> more new input? Only then could an independent judgement be made about the >> reliability of particular reevaluated parallaxes that have changed even in >> SIGN! Certainly, to me this fact already signals a considerable instability, >> which I would want to first understand before making a decision! >> >> If I was involved with that analysis, I'd get into email contact with the >> author. That's always the safest recipe. >> >> Fridger >> >> >> Selden E Ball Jr wrote: >>> The appearance of negative parallaxes when improved data reduction >>> algorithms were applied suggests to me that the previous corresponding >>> positive parallax values may have been incorrect. >>> >>> I suspect that it would be inappropriate to mix values from the two catalogs. >>> >>> I also suspect that there might be some discussion in the book >>> about the new negative parallax values. I'm sure they won't have >>> been overlooked. >>> >>> s. >>> >>>> It's nice to see that new reduction is finally available. The >>>> disturbing thing is that quite a few formerly "good" parallaxes are >>>> now negative. >>> >>>> Option 2 gives us the largest number of useful parallaxes, but it >>>> seems difficult to defend on theoretical grounds. Shouldn't we always >>>> use the value with the lowest error? >>> >>>> --Chris >>> >>>> On Sat, Jul 12, 2008 at 8:36 AM, Andrew Tribick >>>> <ajt...@go...> wrote: >>>>> I've been investigating the new reduction of the Hipparcos data (now >>>>> available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... >>>>> >>>>> It looks like the parallax errors have either decreased or remained >>>>> the same, which is good. >>>>> >>>>> Defining "good" parallaxes as those >0.4, the changes original (HIP1) >>>>> -> new (HIP2) are: >>>>> >>>>> Changes for the better: >>>>> negative->good = 2387 >>>>> negative->low = 1858 >>>>> low->good = 1294 >>>>> >>>>> Changes for the worse: >>>>> good->negative = 4994 >>>>> good->low = 1780 >>>>> low->negative = 525 >>>>> >>>>> The question now is what to do about the latter three cases. >>>>> 1) Use HIP2 regardless >>>>> 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve >>>>> parallax, use data from HIP1. >>>>> 3) In the cases where the change is for the worse, use HIP1. >>>>> 4) other >>>>> >>>>> I'm leaning towards option (2) myself. >>>>> >>>>> Andrew >>>>> >>> >>>> ------------------------------------------------------------------------- >>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>> Studies have shown that voting for your favorite open source project, >>>> along with a healthy diet, reduces your potential for chronic lameness >>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>> _______________________________________________ >>>> Celestia-developers mailing list >>>> Cel...@li... >>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> >>> ------------------------------------------------------------------------- >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>> Studies have shown that voting for your favorite open source project, >>> along with a healthy diet, reduces your potential for chronic lameness >>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >> >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers >> > |
From: Fridger S. <fri...@de...> - 2008-07-14 18:37:26
|
I think Selden's arguing in the right direction. First of all, someone should UNDERSTAND what the physical basis was that allowed to reduce the initial uncertainties so significantly. Was it merely statistically based or was there more new input? Only then could an independent judgement be made about the reliability of particular reevaluated parallaxes that have changed even in SIGN! Certainly, to me this fact already signals a considerable instability, which I would want to first understand before making a decision! If I was involved with that analysis, I'd get into email contact with the author. That's always the safest recipe. Fridger Selden E Ball Jr wrote: > The appearance of negative parallaxes when improved data reduction > algorithms were applied suggests to me that the previous corresponding > positive parallax values may have been incorrect. > > I suspect that it would be inappropriate to mix values from the two catalogs. > > I also suspect that there might be some discussion in the book > about the new negative parallax values. I'm sure they won't have > been overlooked. > > s. > >> It's nice to see that new reduction is finally available. The >> disturbing thing is that quite a few formerly "good" parallaxes are >> now negative. > >> Option 2 gives us the largest number of useful parallaxes, but it >> seems difficult to defend on theoretical grounds. Shouldn't we always >> use the value with the lowest error? > >> --Chris > >> On Sat, Jul 12, 2008 at 8:36 AM, Andrew Tribick >> <ajt...@go...> wrote: >>> I've been investigating the new reduction of the Hipparcos data (now >>> available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... >>> >>> It looks like the parallax errors have either decreased or remained >>> the same, which is good. >>> >>> Defining "good" parallaxes as those >0.4, the changes original (HIP1) >>> -> new (HIP2) are: >>> >>> Changes for the better: >>> negative->good = 2387 >>> negative->low = 1858 >>> low->good = 1294 >>> >>> Changes for the worse: >>> good->negative = 4994 >>> good->low = 1780 >>> low->negative = 525 >>> >>> The question now is what to do about the latter three cases. >>> 1) Use HIP2 regardless >>> 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve >>> parallax, use data from HIP1. >>> 3) In the cases where the change is for the worse, use HIP1. >>> 4) other >>> >>> I'm leaning towards option (2) myself. >>> >>> Andrew >>> > >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Andrew T. <ajt...@go...> - 2008-07-14 19:58:42
|
>From links on the CDS, I found http://fr.arxiv.org/abs/0708.1752 "Validation of the new Hipparcos reduction" by van Leeuwen which includes discussion of the negative parallaxes. Seemingly therefore it would make sense to use the new reduction for position and parallax information despite the fact this would lead to a smaller number of stars included. Spectral types are not listed in the new reduction, so would have to be sourced from hip_main.dat. Would it be better to use the Vmag in the original hip_main.dat (which appears to be a catalogue-derived value, rather than measured by Hipparcos), or transform from Hp and B-V using http://www.tass-survey.org/tass/catalogs/tycho.html ? Andrew 2008/7/14 Fridger Schrempp <fri...@de...>: > I think Selden's arguing in the right direction. First of all, someone should > UNDERSTAND what the physical basis was that allowed to reduce the initial > uncertainties so significantly. Was it merely statistically based or was there > more new input? Only then could an independent judgement be made about the > reliability of particular reevaluated parallaxes that have changed even in > SIGN! Certainly, to me this fact already signals a considerable instability, > which I would want to first understand before making a decision! > > If I was involved with that analysis, I'd get into email contact with the > author. That's always the safest recipe. > > Fridger > > > Selden E Ball Jr wrote: >> The appearance of negative parallaxes when improved data reduction >> algorithms were applied suggests to me that the previous corresponding >> positive parallax values may have been incorrect. >> >> I suspect that it would be inappropriate to mix values from the two catalogs. >> >> I also suspect that there might be some discussion in the book >> about the new negative parallax values. I'm sure they won't have >> been overlooked. >> >> s. >> >>> It's nice to see that new reduction is finally available. The >>> disturbing thing is that quite a few formerly "good" parallaxes are >>> now negative. >> >>> Option 2 gives us the largest number of useful parallaxes, but it >>> seems difficult to defend on theoretical grounds. Shouldn't we always >>> use the value with the lowest error? >> >>> --Chris >> >>> On Sat, Jul 12, 2008 at 8:36 AM, Andrew Tribick >>> <ajt...@go...> wrote: >>>> I've been investigating the new reduction of the Hipparcos data (now >>>> available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... >>>> >>>> It looks like the parallax errors have either decreased or remained >>>> the same, which is good. >>>> >>>> Defining "good" parallaxes as those >0.4, the changes original (HIP1) >>>> -> new (HIP2) are: >>>> >>>> Changes for the better: >>>> negative->good = 2387 >>>> negative->low = 1858 >>>> low->good = 1294 >>>> >>>> Changes for the worse: >>>> good->negative = 4994 >>>> good->low = 1780 >>>> low->negative = 525 >>>> >>>> The question now is what to do about the latter three cases. >>>> 1) Use HIP2 regardless >>>> 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve >>>> parallax, use data from HIP1. >>>> 3) In the cases where the change is for the worse, use HIP1. >>>> 4) other >>>> >>>> I'm leaning towards option (2) myself. >>>> >>>> Andrew >>>> >> >>> ------------------------------------------------------------------------- >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>> Studies have shown that voting for your favorite open source project, >>> along with a healthy diet, reduces your potential for chronic lameness >>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > |
From: Fridger S. <fri...@de...> - 2008-07-16 09:35:52
|
How about the proper definition of Vmag that you were using? The idea is to really use the Johnson V definition throughout. A familiar approximation in terms of the Tycho mags is For Tycho-2 stars: VJ ~ VT - 0.090(BT - VT) (Høg et al. 2000) Fridger Andrew Tribick wrote: > I've rewritten the generator to use the new Hipparcos dataset: the old > database is only used for Vmag, BTmag, VTmag and SpType which are not > given in the new revision. The script also generates a stars.txt file. > Given the existence of nearstars.stc, do we need to have the Sun in > stars.dat/.txt? (It cannot be represented in stars.txt without > displacing it from the origin because of the use of apparent magnitude > in that file, so the current script does not include it) > > Script on shatters.net at > http://www.shatters.net/forum/viewtopic.php?p=105590#p105590 > > Andrew > > 2008/7/14 Andrew Tribick <ajt...@go...>: >> From links on the CDS, I found http://fr.arxiv.org/abs/0708.1752 >> "Validation of the new Hipparcos reduction" by van Leeuwen which >> includes discussion of the negative parallaxes. >> >> Seemingly therefore it would make sense to use the new reduction for >> position and parallax information despite the fact this would lead to >> a smaller number of stars included. Spectral types are not listed in >> the new reduction, so would have to be sourced from hip_main.dat. >> >> Would it be better to use the Vmag in the original hip_main.dat (which >> appears to be a catalogue-derived value, rather than measured by >> Hipparcos), or transform from Hp and B-V using >> http://www.tass-survey.org/tass/catalogs/tycho.html ? >> >> Andrew >> >> 2008/7/14 Fridger Schrempp <fri...@de...>: >>> I think Selden's arguing in the right direction. First of all, someone should >>> UNDERSTAND what the physical basis was that allowed to reduce the initial >>> uncertainties so significantly. Was it merely statistically based or was there >>> more new input? Only then could an independent judgement be made about the >>> reliability of particular reevaluated parallaxes that have changed even in >>> SIGN! Certainly, to me this fact already signals a considerable instability, >>> which I would want to first understand before making a decision! >>> >>> If I was involved with that analysis, I'd get into email contact with the >>> author. That's always the safest recipe. >>> >>> Fridger >>> >>> >>> Selden E Ball Jr wrote: >>>> The appearance of negative parallaxes when improved data reduction >>>> algorithms were applied suggests to me that the previous corresponding >>>> positive parallax values may have been incorrect. >>>> >>>> I suspect that it would be inappropriate to mix values from the two catalogs. >>>> >>>> I also suspect that there might be some discussion in the book >>>> about the new negative parallax values. I'm sure they won't have >>>> been overlooked. >>>> >>>> s. >>>> >>>>> It's nice to see that new reduction is finally available. The >>>>> disturbing thing is that quite a few formerly "good" parallaxes are >>>>> now negative. >>>>> Option 2 gives us the largest number of useful parallaxes, but it >>>>> seems difficult to defend on theoretical grounds. Shouldn't we always >>>>> use the value with the lowest error? >>>>> --Chris >>>>> On Sat, Jul 12, 2008 at 8:36 AM, Andrew Tribick >>>>> <ajt...@go...> wrote: >>>>>> I've been investigating the new reduction of the Hipparcos data (now >>>>>> available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... >>>>>> >>>>>> It looks like the parallax errors have either decreased or remained >>>>>> the same, which is good. >>>>>> >>>>>> Defining "good" parallaxes as those >0.4, the changes original (HIP1) >>>>>> -> new (HIP2) are: >>>>>> >>>>>> Changes for the better: >>>>>> negative->good = 2387 >>>>>> negative->low = 1858 >>>>>> low->good = 1294 >>>>>> >>>>>> Changes for the worse: >>>>>> good->negative = 4994 >>>>>> good->low = 1780 >>>>>> low->negative = 525 >>>>>> >>>>>> The question now is what to do about the latter three cases. >>>>>> 1) Use HIP2 regardless >>>>>> 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve >>>>>> parallax, use data from HIP1. >>>>>> 3) In the cases where the change is for the worse, use HIP1. >>>>>> 4) other >>>>>> >>>>>> I'm leaning towards option (2) myself. >>>>>> >>>>>> Andrew >>>>>> >>>>> ------------------------------------------------------------------------- >>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>>> Studies have shown that voting for your favorite open source project, >>>>> along with a healthy diet, reduces your potential for chronic lameness >>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>>> _______________________________________________ >>>>> Celestia-developers mailing list >>>>> Cel...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>> ------------------------------------------------------------------------- >>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>> Studies have shown that voting for your favorite open source project, >>>> along with a healthy diet, reduces your potential for chronic lameness >>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>> _______________________________________________ >>>> Celestia-developers mailing list >>>> Cel...@li... >>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> >>> ------------------------------------------------------------------------- >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>> Studies have shown that voting for your favorite open source project, >>> along with a healthy diet, reduces your potential for chronic lameness >>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Andrew T. <ajt...@go...> - 2008-07-16 09:52:29
|
That's the current system: I use the Johnson Vmag from hip_main.dat. Where this is not present in the datafile I use the approximations given in http://www.tass-survey.org/tass/catalogs/tycho.html. Andrew 2008/7/16 Fridger Schrempp <fri...@de...>: > How about the proper definition of Vmag that you were using? > The idea is to really use the Johnson V definition throughout. A familiar > approximation in terms of the Tycho mags is > > For Tycho-2 stars: VJ ~ VT - 0.090(BT - VT) (Høg et al. 2000) > > Fridger > > Andrew Tribick wrote: >> >> I've rewritten the generator to use the new Hipparcos dataset: the old >> database is only used for Vmag, BTmag, VTmag and SpType which are not >> given in the new revision. The script also generates a stars.txt file. >> Given the existence of nearstars.stc, do we need to have the Sun in >> stars.dat/.txt? (It cannot be represented in stars.txt without >> displacing it from the origin because of the use of apparent magnitude >> in that file, so the current script does not include it) >> >> Script on shatters.net at >> http://www.shatters.net/forum/viewtopic.php?p=105590#p105590 >> >> Andrew >> >> 2008/7/14 Andrew Tribick <ajt...@go...>: >>> >>> From links on the CDS, I found http://fr.arxiv.org/abs/0708.1752 >>> "Validation of the new Hipparcos reduction" by van Leeuwen which >>> includes discussion of the negative parallaxes. >>> >>> Seemingly therefore it would make sense to use the new reduction for >>> position and parallax information despite the fact this would lead to >>> a smaller number of stars included. Spectral types are not listed in >>> the new reduction, so would have to be sourced from hip_main.dat. >>> >>> Would it be better to use the Vmag in the original hip_main.dat (which >>> appears to be a catalogue-derived value, rather than measured by >>> Hipparcos), or transform from Hp and B-V using >>> http://www.tass-survey.org/tass/catalogs/tycho.html ? >>> >>> Andrew >>> >>> 2008/7/14 Fridger Schrempp <fri...@de...>: >>>> >>>> I think Selden's arguing in the right direction. First of all, someone >>>> should >>>> UNDERSTAND what the physical basis was that allowed to reduce the >>>> initial >>>> uncertainties so significantly. Was it merely statistically based or was >>>> there >>>> more new input? Only then could an independent judgement be made about >>>> the >>>> reliability of particular reevaluated parallaxes that have changed even >>>> in >>>> SIGN! Certainly, to me this fact already signals a considerable >>>> instability, >>>> which I would want to first understand before making a decision! >>>> >>>> If I was involved with that analysis, I'd get into email contact with >>>> the >>>> author. That's always the safest recipe. >>>> >>>> Fridger >>>> >>>> >>>> Selden E Ball Jr wrote: >>>>> >>>>> The appearance of negative parallaxes when improved data reduction >>>>> algorithms were applied suggests to me that the previous corresponding >>>>> positive parallax values may have been incorrect. >>>>> >>>>> I suspect that it would be inappropriate to mix values from the two >>>>> catalogs. >>>>> >>>>> I also suspect that there might be some discussion in the book >>>>> about the new negative parallax values. I'm sure they won't have >>>>> been overlooked. >>>>> >>>>> s. >>>>> >>>>>> It's nice to see that new reduction is finally available. The >>>>>> disturbing thing is that quite a few formerly "good" parallaxes are >>>>>> now negative. >>>>>> Option 2 gives us the largest number of useful parallaxes, but it >>>>>> seems difficult to defend on theoretical grounds. Shouldn't we always >>>>>> use the value with the lowest error? >>>>>> --Chris >>>>>> On Sat, Jul 12, 2008 at 8:36 AM, Andrew Tribick >>>>>> <ajt...@go...> wrote: >>>>>>> >>>>>>> I've been investigating the new reduction of the Hipparcos data (now >>>>>>> available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... >>>>>>> >>>>>>> It looks like the parallax errors have either decreased or remained >>>>>>> the same, which is good. >>>>>>> >>>>>>> Defining "good" parallaxes as those >0.4, the changes original (HIP1) >>>>>>> -> new (HIP2) are: >>>>>>> >>>>>>> Changes for the better: >>>>>>> negative->good = 2387 >>>>>>> negative->low = 1858 >>>>>>> low->good = 1294 >>>>>>> >>>>>>> Changes for the worse: >>>>>>> good->negative = 4994 >>>>>>> good->low = 1780 >>>>>>> low->negative = 525 >>>>>>> >>>>>>> The question now is what to do about the latter three cases. >>>>>>> 1) Use HIP2 regardless >>>>>>> 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve >>>>>>> parallax, use data from HIP1. >>>>>>> 3) In the cases where the change is for the worse, use HIP1. >>>>>>> 4) other >>>>>>> >>>>>>> I'm leaning towards option (2) myself. >>>>>>> >>>>>>> Andrew >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>>>> Studies have shown that voting for your favorite open source project, >>>>>> along with a healthy diet, reduces your potential for chronic lameness >>>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>>>> _______________________________________________ >>>>>> Celestia-developers mailing list >>>>>> Cel...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>>> Studies have shown that voting for your favorite open source project, >>>>> along with a healthy diet, reduces your potential for chronic lameness >>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>>> _______________________________________________ >>>>> Celestia-developers mailing list >>>>> Cel...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>> Studies have shown that voting for your favorite open source project, >>>> along with a healthy diet, reduces your potential for chronic lameness >>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>> _______________________________________________ >>>> Celestia-developers mailing list >>>> Cel...@li... >>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > |
From: Fridger S. <fri...@de...> - 2008-07-16 10:14:08
|
Andrew Tribick wrote: > That's the current system: I use the Johnson Vmag from hip_main.dat. > Where this is not present in the datafile I use the approximations > given in http://www.tass-survey.org/tass/catalogs/tycho.html. > > Andrew Perfect! Fridger > > 2008/7/16 Fridger Schrempp <fri...@de...>: >> How about the proper definition of Vmag that you were using? >> The idea is to really use the Johnson V definition throughout. A familiar >> approximation in terms of the Tycho mags is >> >> For Tycho-2 stars: VJ ~ VT - 0.090(BT - VT) (Høg et al. 2000) >> >> Fridger >> >> Andrew Tribick wrote: >>> I've rewritten the generator to use the new Hipparcos dataset: the old >>> database is only used for Vmag, BTmag, VTmag and SpType which are not >>> given in the new revision. The script also generates a stars.txt file. >>> Given the existence of nearstars.stc, do we need to have the Sun in >>> stars.dat/.txt? (It cannot be represented in stars.txt without >>> displacing it from the origin because of the use of apparent magnitude >>> in that file, so the current script does not include it) >>> >>> Script on shatters.net at >>> http://www.shatters.net/forum/viewtopic.php?p=105590#p105590 >>> >>> Andrew >>> >>> 2008/7/14 Andrew Tribick <ajt...@go...>: >>>> From links on the CDS, I found http://fr.arxiv.org/abs/0708.1752 >>>> "Validation of the new Hipparcos reduction" by van Leeuwen which >>>> includes discussion of the negative parallaxes. >>>> >>>> Seemingly therefore it would make sense to use the new reduction for >>>> position and parallax information despite the fact this would lead to >>>> a smaller number of stars included. Spectral types are not listed in >>>> the new reduction, so would have to be sourced from hip_main.dat. >>>> >>>> Would it be better to use the Vmag in the original hip_main.dat (which >>>> appears to be a catalogue-derived value, rather than measured by >>>> Hipparcos), or transform from Hp and B-V using >>>> http://www.tass-survey.org/tass/catalogs/tycho.html ? >>>> >>>> Andrew >>>> >>>> 2008/7/14 Fridger Schrempp <fri...@de...>: >>>>> I think Selden's arguing in the right direction. First of all, someone >>>>> should >>>>> UNDERSTAND what the physical basis was that allowed to reduce the >>>>> initial >>>>> uncertainties so significantly. Was it merely statistically based or was >>>>> there >>>>> more new input? Only then could an independent judgement be made about >>>>> the >>>>> reliability of particular reevaluated parallaxes that have changed even >>>>> in >>>>> SIGN! Certainly, to me this fact already signals a considerable >>>>> instability, >>>>> which I would want to first understand before making a decision! >>>>> >>>>> If I was involved with that analysis, I'd get into email contact with >>>>> the >>>>> author. That's always the safest recipe. >>>>> >>>>> Fridger >>>>> >>>>> >>>>> Selden E Ball Jr wrote: >>>>>> The appearance of negative parallaxes when improved data reduction >>>>>> algorithms were applied suggests to me that the previous corresponding >>>>>> positive parallax values may have been incorrect. >>>>>> >>>>>> I suspect that it would be inappropriate to mix values from the two >>>>>> catalogs. >>>>>> >>>>>> I also suspect that there might be some discussion in the book >>>>>> about the new negative parallax values. I'm sure they won't have >>>>>> been overlooked. >>>>>> >>>>>> s. >>>>>> >>>>>>> It's nice to see that new reduction is finally available. The >>>>>>> disturbing thing is that quite a few formerly "good" parallaxes are >>>>>>> now negative. >>>>>>> Option 2 gives us the largest number of useful parallaxes, but it >>>>>>> seems difficult to defend on theoretical grounds. Shouldn't we always >>>>>>> use the value with the lowest error? >>>>>>> --Chris >>>>>>> On Sat, Jul 12, 2008 at 8:36 AM, Andrew Tribick >>>>>>> <ajt...@go...> wrote: >>>>>>>> I've been investigating the new reduction of the Hipparcos data (now >>>>>>>> available at http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/311)... >>>>>>>> >>>>>>>> It looks like the parallax errors have either decreased or remained >>>>>>>> the same, which is good. >>>>>>>> >>>>>>>> Defining "good" parallaxes as those >0.4, the changes original (HIP1) >>>>>>>> -> new (HIP2) are: >>>>>>>> >>>>>>>> Changes for the better: >>>>>>>> negative->good = 2387 >>>>>>>> negative->low = 1858 >>>>>>>> low->good = 1294 >>>>>>>> >>>>>>>> Changes for the worse: >>>>>>>> good->negative = 4994 >>>>>>>> good->low = 1780 >>>>>>>> low->negative = 525 >>>>>>>> >>>>>>>> The question now is what to do about the latter three cases. >>>>>>>> 1) Use HIP2 regardless >>>>>>>> 2) In the cases where HIP1 has a +ve parallax and HIP2 has -ve >>>>>>>> parallax, use data from HIP1. >>>>>>>> 3) In the cases where the change is for the worse, use HIP1. >>>>>>>> 4) other >>>>>>>> >>>>>>>> I'm leaning towards option (2) myself. >>>>>>>> >>>>>>>> Andrew >>>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>>>>> Studies have shown that voting for your favorite open source project, >>>>>>> along with a healthy diet, reduces your potential for chronic lameness >>>>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>>>>> _______________________________________________ >>>>>>> Celestia-developers mailing list >>>>>>> Cel...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>>>> Studies have shown that voting for your favorite open source project, >>>>>> along with a healthy diet, reduces your potential for chronic lameness >>>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>>>> _______________________________________________ >>>>>> Celestia-developers mailing list >>>>>> Cel...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>> >>>>> ------------------------------------------------------------------------- >>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >>>>> Studies have shown that voting for your favorite open source project, >>>>> along with a healthy diet, reduces your potential for chronic lameness >>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >>>>> _______________________________________________ >>>>> Celestia-developers mailing list >>>>> Cel...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >> |