Problem with barycenter

Post requests, images, descriptions and reports about work in progress here.
Avatar
Topic author
LukeCEL
Posts: 373
Joined: 26.09.2017
With us: 7 years 2 months

Problem with barycenter

Post #1by LukeCEL » 19.02.2019, 14:17

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:
kelt4bc.jpg

Can you point me to what might be wrong?

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 3 months
Location: NY, USA

Post #2by selden » 20.02.2019, 14:15

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: 537
Joined: 13.08.2016
With us: 8 years 3 months

Post #3by Janus » 20.02.2019, 21:59

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.

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
Site Admin
Posts: 706
Joined: 22.09.2018
With us: 6 years 2 months

Post #4by onetwothree » 21.02.2019, 09:08

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: 537
Joined: 13.08.2016
With us: 8 years 3 months

Post #5by Janus » 21.02.2019, 09:38

@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.

Avatar
Topic author
LukeCEL
Posts: 373
Joined: 26.09.2017
With us: 7 years 2 months

Post #6by LukeCEL » 22.02.2019, 21:03

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 :wink: 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: 537
Joined: 13.08.2016
With us: 8 years 3 months

Post #7by Janus » 22.02.2019, 23:44

@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.


Return to “Add-on development”