new star.dat

[ajtribick]

Does the cross-reference format allow for cross referencing catalogs with multiple numbers, e.g. Bonner Durchmusterung, or catalogs which have the potential to have points in them e.g. Gliese?

[chris]

Does the cross-reference format allow for cross referencing catalogs with multiple numbers, e.g. Bonner Durchmusterung, or catalogs which have the potential to have points in them e.g. Gliese?

Sort of. You need to modify the Celestia code slightly to handle new catalogs, and for a catalog with multiple numbers, you need to write a parsing function that converts the numbers into a single 32 bit value. With more work, I could make it possible to add new cross indexes with arbitrarily formatted catalog numbers without modifying the Celestia code, but it doesn't seem worth the effort. It's much simpler just to hardcode the values. After I've finished my star class overhaul, I'll add support for the Bonner Durchmusterung catalog.

--Chris

[chris]

------------------------------
A sensible i.e. satisfactory requirement of consistency rather is that the numerical math errors (extinction, rounding...) merely have to remain smaller than the Gauss propagated physical errors. With different compilers, on different machines...
------------------------------

Nothing else is really relevant.

But with Celestia, it is very relevant. Merely keeping the numerical error less than the physical error is not adequate. If people are to be able to share cel:// URLs, then stars need to be in the exact same position for everyone running Celestia. Even one bit of single precision floating point error cannot be tolerated, as it could cause an error of 100au or more in the position of a star.

Now, it should be possible to avoid the problem by performing the conversion at double precision, then converting back to single precision. It would be very rare that a bit of double precision error would result in one bit single precision error. However, I thought it best to avoid the problem entirely and just store rectangular coordinates.

I don't see what the loss is unless you envision the stars.dat to be some sort of interchange format. I look at it as the Celestia data file format only, and since Celestia must convert the star positions to rectangular coordinates to render them, there's no loss in performing the conversion ahead of time with an external program. If Celestia used spherical coordinates directly when rendering, I think you'd have a valid point about retaining spherical coordinate in stars.dat. The source file from which stars.dat is built (stars.txt) does use spherical coordinates extracted directly from HIPPARCOS database for precisely the reason you recommend, and to make editing more convenient.

--Chris

[selden]

Chris,

One problem, it seems to me, is that the cartesian coordinates calculated while creating the new binary stars.dat still are going to be calculated differently on different types of systems. If the creation of the binary stars.dat is part of building from CVS (and I think it should be), then when stars.dat is built on different platforms or on the same kind of platform but with different compilers and math libraries, then Celestia running on different systems still will have different coordinates for some of the stars.

In other words, if you solve the reproducability problem for the algorithm that calculates star positions for a cartesian stars.dat, then you've also solved it for use within Celestia.

[t00fri]

------------------------------
A sensible i.e. satisfactory requirement of consistency rather is that the numerical math errors (extinction, rounding...) merely have to remain smaller than the Gauss propagated physical errors. With different compilers, on different machines...
------------------------------

Nothing else is really relevant.

But with Celestia, it is very relevant. Merely keeping the numerical error less than the physical error is not adequate. If people are to be able to share cel:// URLs, then stars need to be in the exact same position for everyone running Celestia. Even one bit of single precision floating point error cannot be tolerated, as it could cause an error of 100au or more in the position of a star.

My statement above referred to physical relevance not to numerical one in the first place.

Those last bits may well be relevant for cel://url's to work in the code as it is now. But it is surely physically nonsensical to generate and take seriously rectangular coordinates to many digits from measured star data that have a comparatively low precision, notably as to the distance r=sqrt(x^2+y^2+z^2) due to low precision (5% to >40 %) parallax information.

One main reason why I dislike (x,y,z) input coordinates is this: in polar coordinates the hierarchy of physical uncertainties is obvious: ra & dec are relatively well measured, while the parallax (--> distance) is known with much lower precision! In contrast x,y,z coordinates involve a thorough mix of the high and the low precision input. Too bad..!

In addition the x,y,z input now depends on the precise value of the obliquity of the ecliptic ...

For me the only sensible consequence would be to retain the criterion that I gave above for physics reasons and modify the code for cel://url's (in case of stars) instead.

The direction seems quite obvious: For stars (only), cel://urls should not be sensitive to more digits than are physically justifiable! So what has to be done there is to truncate the formally calculated result to the number of /physically/ sensible i.e. reliably calculable digits. This to me is the only consistent alternative ...

Now, it should be possible to avoid the problem by performing the conversion at double precision, then converting back to single precision.

You seem to be saying something similar here, except that I would want to compare the number of retained digits with a Gauss propagated error estimate...


Please note that my main plea is to do the polar to rectangular conversion in a most careful and physically sensible way, including optimal rewritings of the trig functions involved, etc. Whether you prefer to generate (e.g. also for reasons of speed) an intermediate binary (z,y,z) file from the input catalogs is of secondary importance to me. I am arguing to retain maximal transparency wrto measurement uncertainties in the calculations. Moreover, only the original catalog data should be visible in readable form in the distribution.

Bye Fridger

[Guckytos]

Just a brain-deads input into this discussion.

I just understood the whole astronomy system of RA and Dec and the distance problem. Now Chris proposes to change the whole data format for the stars.dat.
The trouble that has been discribed is that different compilers result in different positions of stars in Celestia. Now a question: How much of a difference are we talking about anyways?? Is this really that serious, because the same difference in position is also "used" in the addons, so that the errors are "only" global ones?

And if you now have ONE stars.dat in rectangular coordinates, that is true for all versions of Celestia, what happens to all the addons? The coordinates for them are still calculated from different compiler versions, resulting in individual errors in position for the different Celestias. Now IMHO this is a bigger problem. Especially if real stars are used as a point of reference.
So it would probably force the people to change their coordinate system, and as of now i just dislike the idea of rectangular coordinates, that base on the ecilptic of the earth (if i have understood it correct).

But what i (perversely) would like would be the possibility to introduce local rectangular coordinates around a certain reference star, so that it would be much easier to create star cluster addons, with exact position definitions.

Otherwise i agree with Fridger.

Regards,

Guckytos

[granthutchison]

While I understand Fridger's concerns, I just don't see why they're an issue for Celestia - it's not Celestia's business to distribute accurate astronomical data, but to portray it realistically.
A simple warning in the README, pointing out the limitations of rectangular coordinates and directing the user to the original data seems to me to be all that's necessary.

Grant

[ajtribick]

Won't the problem still be there when the RA and Declination definitions are read from the .stc file... moving stars.dat to rectangular coordinates would not solve that problem for an add-on like Ran.

The only solution would be to define your own trig functions which take the Taylor/Maclaurin series (or whatever) to the same number of terms in all implementations.