• Print view

## Problem with barycenter

Post requests, images, descriptions and reports about work in progress here.
Topic author
LukeCEL
Posts: 365
Joined: 26.09.2017
With us: 3 years 6 months

### Problem with barycenter

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:

Code: Select all

`Barycenter 2009541973 "KELT-4 BC"{   RA 157.062757   Dec 25.5735699   Distance 684.928}"KELT-4 B"{   RA 157.062761   Dec 25.5735643   Distance 684.928   AbsMag 8.13 # from radius and temperature    SpectralType "K"}"KELT-4 C"{   RA 157.062753   Dec 25.5735755   Distance 684.928   AbsMag 8.13 # from radius and temperature    SpectralType "K"}`

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?

selden
Developer
Posts: 10139
Joined: 04.09.2002
With us: 18 years 7 months
Location: NY, USA
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.
Selden

Janus
Posts: 531
Joined: 13.08.2016
With us: 4 years 7 months
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.

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.

Code: Select all

`            Eigen::Vector3d pos =                astro::equatorialToCelestialCart((double) RA * 24.0 / 360.0,                                                 (double) dec,                                                 (double) distance);            x = (float) pos.x();            y = (float) pos.y();            z = (float) pos.z();`

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

Code: Select all

`   foreach my \$HIP (sort { \$a <=> \$b } keys %stars)   {      my \$dist = PlxToDistance(\$stars{\$HIP}{'Plx'});      my \$theta = \$stars{\$HIP}{'RArad'} + pi;      my \$phi = \$stars{\$HIP}{'DErad'} - pi / 2;      my @xyz = (          \$dist * cos(\$theta) * sin(\$phi),          \$dist * cos(\$phi),         -\$dist * sin(\$theta) * sin(\$phi)      );      my \$xc = \$eqToCel[0][0] * \$xyz[0] + \$eqToCel[1][0] * \$xyz[1] + \$eqToCel[2][0] * \$xyz[2];      my \$yc = \$eqToCel[0][1] * \$xyz[0] + \$eqToCel[1][1] * \$xyz[1] + \$eqToCel[2][1] * \$xyz[2];      my \$zc = \$eqToCel[0][2] * \$xyz[0] + \$eqToCel[1][2] * \$xyz[1] + \$eqToCel[2][2] * \$xyz[2];      my \$absMag = AppMagToAbsMag(\$stars{\$HIP}{'Vmag'}, \$stars{\$HIP}{'Plx'});      my \$spType = ParseSpType(\$stars{\$HIP}{'SpType'});      print DATFILE pack('LfffsS', \$HIP, \$xc, \$yc, \$zc, \$absMag * 256, \$spType);      print TXTFILE sprintf("%u  %.9f %+.9f %.6f %.2f %s\n", \$HIP,                            rad2deg(\$stars{\$HIP}{'RArad'}), rad2deg(\$stars{\$HIP}{'DErad'}),                       \$dist, \$stars{\$HIP}{'Vmag'}, \$stars{\$HIP}{'SpType'});}`

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

Janus.

onetwothree
Posts: 537
Joined: 22.09.2018
With us: 2 years 6 months
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.

Janus
Posts: 531
Joined: 13.08.2016
With us: 4 years 7 months
@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.

Topic author
LukeCEL
Posts: 365
Joined: 26.09.2017
With us: 3 years 6 months
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.

Janus
Posts: 531
Joined: 13.08.2016
With us: 4 years 7 months
@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.