Celestia Forums

Hi everyone. I'm currently working on an exoplanet catalogue right now, which entails writing in a lot of binary stars. I have this code for KELT-4 BC, a pair of two K-type stars with equal masses:



To find the coordinates of the barycenter, I simply took the averages of the RA and Dec for KELT-4 B and KELT-4 C. This gives me exactly 157.062757 and 25.5735699. However, when I visit the stars, the barycenter's right ascension seems to be significantly off:

Can you point me to what might be wrong?

Unfortunately, you aren't doing anything wrong. You've encountered a limitation in the resolution of Celestia's STC reader: Celestia interprets the RA and Dec values as single precision (32 bit) binary floating point numbers. This means that they are limited to (approximately) 8 decimal digits of precision.

If you define 9 stars with RA values which increment by one the last digit of the RA value that you're supplying, from 157.062754 to 157.062762, you'll discover that Celestia draws their RA positions in just two locations. The KELT B and C stars just happen to be defined far enough apart in RA that Celestia draws them at different locations.

The limitation is not in just the STC reader.

The binary DB is also in float {32-bit}, as are all other handlers except the actual position information.

The position is held as an eigen 128-bit int, int128_t if you want a nice way of saying it.

Fixing this would require a rewrite and redesign of several steps.
The fix however, would break backwards compatibility with longtime DB.
It still needs to happens however.

I had a fork where I had rebuilt the DB with double instead of float{single} for positions, along with preserving RaDec.
It didn't add much time to loading, nor did keeping the Radec I added to the DB.
This was before I found other ways to generate to display realtime RaDec of selection focus items.
It was also nice since I could search via celx for stars via RaDecDist functions I added.
Sadly however, HDD failures do happen, and it was way back when the original forum was active.
I remember I had to modify the CPP DB builder because I could not figure out how to force perl to use double.

It shouldn't be very hard to switch to using doubles since eigen returns vector3d, which is three doubles in a record.



Or if there is a way to force perl to use doubles, this can be changed in buildstardb.pl as needed..



Though I am not a real C/C++ programmer, so there may be some gotchas I don't know about.


Janus.

Janus wrote:Sadly however, HDD failures do happen, and it was way back when the original forum was active.

That's because you don't want to use version control systems able to work with remote copies.

@onetwothree

I don't work with remote copies.
Nor do I want to.
I leave that to people who work on large distributed projects where it belongs.
Nothing wrong with it, it works well for those who work that way, just not a habit I want to catch.
It works better for me to send code to people who do work on large projects so they can integrate it properly as per project needs.


Janus.

selden wrote:Unfortunately, you aren't doing anything wrong. You've encountered a limitation in the resolution of Celestia's STC reader: Celestia interprets the RA and Dec values as single precision (32 bit) binary floating point numbers. This means that they are limited to (approximately) 8 decimal digits of precision.

Aha, thanks for the response. I guess I'll have to make a cheesy attempt at a binary orbit for this one...

Janus wrote:The binary DB is also in float {32-bit}, as are all other handlers except the actual position information.

The position is held as an eigen 128-bit int, int128_t if you want a nice way of saying it.

Fixing this would require a rewrite and redesign of several steps.
The fix however, would break backwards compatibility with longtime DB.
It still needs to happens however.

Uh-oh, I may have just started another discussion on Celestia development I don't know if this is possible, but I would suggest only adding extra precision to the STC file reader. The stars.dat file is fine right now, because high precision is only needed for stars that are very close together, like binary stars.

@LukeCEL

Don't be deceived by things that sound simple, it is far better in the long run to keep the same resolution all the way through.
Numerous times over the years I have seen customers "Save time and effort" by only updating the little part they needed at the moment.
Then I have to figure out why it either crashes, relatively simple, or gives odd results, much more interesting, and TIME!!! consuming.

If this is going to be changed, then do it all at once.
Shift everything to double, that way you get the full advantage and never wonder how much better it will be when the rest is updated.

It would also be a good foundation for making an asteroids.dat & comets.dat containing just the name & orbit info in binary form.
Use generic textures with specific updates by name if available.

Just a thought.


Janus.