Binary star Delta Equulei defined twice

[ajtribick]

Del Equ is defined as a binary system in both spectbins.stc and visualbins.stc, with different orbits in each file. This leaves a bit of a mess in the area around this system. Is there any way of determining which orbit is of better quality, and go with that one?

[chris]

Fridger created the visual and spectral binary catalogs for Celestia, so he would have the best idea which Delta Equ definition should be preferred.

--Chris

[t00fri]

Well, this example of Del Equ is instructive, since it illustrates once more that (Astro-) Physics is basically an experimental science . This implies that every measurement also comes with certain uncertainties ( that are often hard to evaluate).

I have compared below ALL parameters from the two completely different orbit measurements (spectroscopic vs. visual ) with each other. You see that --on the one hand -- all parameters are very close to each other which is comforting. On the other hand, they are not and CANNOT be identical. Celestia illustrates impressively that --seen from close distance-- such apparently small uncertainties can make a VERY substantial difference.

Code: Select all

                                   Del Equ

                       spectbins.stc        visualbins.stc
--------------------------------------------------------------
Barycenter:
-----------
RA                    318.619970               318.619970
Dec                    10.007718               10.007718
Distance               59.302451               60.278506

Del Equ A:
----------
SpectralType              F8V                      F5V+
AppMag                    5.25                    5.31
Period                    5.703                   5.713
SemiMajorAxis             2.045                   2.061
Eccentricity              0.440                   0.440
Inclination             123.106                 122.477
AscendingNode           114.049                 114.619
ArgOfPericenter          60.485                  55.919
MeanAnomaly              89.700                  90.551

Del Equ B:
-----------
SpectralType               ?
AppMag                    5.25                    5.39
Period                    5.703                   5.713
SemiMajorAxis             2.173                   2.192
Eccentricity              0.440                   0.440
Inclination             123.106                 122.477
AscendingNode           114.049                 114.619
ArgOfPericenter         240.485                 235.919
MeanAnomaly              89.700                  90.551


I am sure you all know the advantages and disadvantages of either method (spectroscopic <-> visual).

+++++++++++++++++
Certainly, I will eliminate one of the two orbits, but first, I want everybody to realize the following: what Chaos Syndrome called a 'mess' is just the consequence of an amazingly small uncertainty on the orbit parameters as seen from Earth! Sometimes it is just good to contemplate about implications of our "limits of knowledge". These strikingly different close distance orbit displays in Celestia drastically illustrate how little we really know about the Universe
++++++++++++++++

Bye Fridger

[ajtribick]

This does of course lead on to the question of how best to represent uncertainties in Celestia - my physics education has taught me that all numbers from experiments should be presented with uncertainties! While there has been an add-on to display parallax errors, representing uncertainties in orbits seems to me to be a lot more tricky.

[t00fri]

This does of course lead on to the question of how best to represent uncertainties in Celestia - my physics education has taught me that all numbers from experiments should be presented with uncertainties! While there has been an add-on to display parallax errors, representing uncertainties in orbits seems to me to be a lot more tricky.

Yeah, it would be great if one of us had an idea one day, how to graphically represent uncertainties in Celestia!

Imagine after some gorgous display, you hit the "error" button and suddenly the Celestia Universe's crisp beauty melts into some kind of "soft fuzz"

Bye Fridger

[ajtribick]

Imagine after some gorgous display, you hit the "error" button and suddenly the Celestia Universe's crisp beauty melts into some kind of "soft fuzz"

I'd suspect most people would regard such an "error button" as an error... an error in the code...

[Cham]

I removed the offending visual binary from my installation (adding a # on each line). When both of them are activated, I get one star (Del Equ B from the visual bin) which is moving alone around a barycenter, and the other member isn't showing at all. There's a kind of conflict here, and only the spectral bin is showing completely.


Which one should be the most reliable ?

[t00fri]

I have to revisit the catalogs. The main point of my above discussion was that it is certainly not obvious which method gives the most accurate orbits /in general/. However, for specific configurations, it might be that one of the two may be argued to be superior.

Clearly we cannot leave both orbits in the system.

Bye Fridger

[t00fri]

The case of ?? Equ continues to be most instructive.

The first question to ask is what is the dominant source of discrepancy between the two orbit parameter sets (visual vs. spectroscopic)??

I went back to the original papers and found that in the Pourbaix paper (spectroscopic data) ?? Equ is considered to be a very well determined orbit with good /independent/ information on BOTH components A and B.

It is discussed there that there is often a significant discrepancy of the parallax with the Hipparcos catalog data. In the light of this, Pourbaix took into account other cross checks that turned out to favour his parallax values over HIP (used in the visual data)!

So I proceeded and set /both/ distances equal to the Pourbaix value . Amazingly this is what I get



++++++++++++++++++
Obviously, the distance (parallax) was indeed by far the dominant source of discrepancy!
++++++++++++++++++

The residual differences between the two resulting orbits for the A and B components are really small as you can nicely see yourself from my image above. Also the two orbit planes are almost coincident as a side view revealed.

++++++++++++++++
This surprisingly close agreement confirms the high quality of our orbit data, both visual and spectroscopic!
++++++++++++++++

Since Pourbaix obviously took great care to get the distances right, I will eliminate the ?? Equ entry from the visualbin.stc data set in CVS.

++++++++++++++++++
Last not least, this close inspection of the ?? Equ system once more revealed the highly unsatisfactory status of Chris' bright star rendering approach.
++++++++++++++++++
In this closeup you see clearly


that the halos of the bright B components nonsensically enhance the brightness of the nearby faint background stars, such that the whole thing looks like an "open star cluster" rather than two bright stars!

Of course, I am aware of the underlying problematics.
Still my preferred approach is quite different:

I am always for reducing realism before displaying obvious physical NONSENSE!

Bye Fridger

[t00fri]

The final physics question from the above discussion of uncertainties would be the following.

What is the minimal distance observers of the ?? Equ system should respect in Celestia, in order that the residual discrepancies between the two orbit parameter sets (due to visual and spectroscopic measurements) cease to be distinguishable? Since the 2 used methods are so different, this consideration provides a quite reliable estimate of the inherent systematic uncertainty.

When observing the system from this limiting distance and larger ones, we can therefore be pretty sure that the displayed graphical information is really correct.

Here is the result that you can easily obtain by increasing the observer distance from ?? Equ until the two orbit sets appear indistinguishable (equating the distance parameter for both sets).

Limit of Knowledge (LOK) Result: min. distance ~ 80 AU



+++++++++++++++
A possible action of the above-discussed LOK "error" button could now consist in blocking observer access to distances closer than 80 AU in this example.

Of course, this is meant as a "Gedankenexperiment" rather than as a challenge for really implementing such a LOK button
+++++++++++++++

A word to our science/astronomy teachers: this sort of discussion I consider way more instructive for students than presenting so-called educational Celestia material with "lots of action", but limited scientific documentation quality...

Bye Fridger

[chris]

Since Pourbaix obviously took great care to get the distances right, I will eliminate the ?? Equ entry from the visualbin.stc data set in CVS.

Thank you for looking into this. You have me convinced that eliminating ?? Equ entry from the visualbin.stc is the right thing to do.

++++++++++++++++++
Last not least, this close inspection of the ?? Equ system once more revealed the highly unsatisfactory status of Chris' bright star rendering approach.
++++++++++++++++++

Unfortunately, I'm really constrained by OpenGL. HDR rendering is the best long-term solution. But until that's implemented in Celestia, I just don't have any better ideas. The glare halos could be eliminated completely, but I really don't think that's a good idea.

--Chris

[ajtribick]

I've come across the problem of things becoming brighter behind transparent objects before in GIMP, I solved it by copying the transparency channel into a separate (black & white) layer and using it to do a subtract operation. Is it possible to do that in OpenGL?

[chris]

I've come across the problem of things becoming brighter behind transparent objects before in GIMP, I solved it by copying the transparency channel into a separate (black & white) layer and using it to do a subtract operation. Is it possible to do that in OpenGL?

Yes, it is.

Now the long answer . . . I've experimented with it before, and it does mitigate somewhat the brightening of background stars. The problem is that the stars themselves are rendered in two parts: the disc (or point), and the glare halo. These parts must be combined additively, otherwise the star looks just like a hazy smear with no definite center. The workaround is to render the disc with additive blending *after* the glare halo. Unfortunately, this is more complicated than it sounds because of how stars must be batched for efficient rendering. A pixel shader to do star rendering in a single pass is one way to address the problem (and also make star rendering more efficient), but it's a more involved solution than I'd like to try to squeeze into 1.5.0.

Additive blending:


Cs*As+(1-Cs)*Cd blending:


Aside from the dimmer solar disc, the second image looks subjectively more correct. However, there is nothing more physically correct about the second blend function. If anything, plain old additive blending is more correct. The light contribution from glare really does sum with everything else in the field of view, e.g. the familiar bleed of glare into an object silhouetted against the sun:
http://imagesource.allposters.com/image ... osters.jpg

--Chris

[t00fri]

What I consider a /physically/ preferrable compromise via a "reduction of realism", would be to constrain the ratio (halo size)/(star disk size) such that for brighter stars the disk size is made to grow more (compared to your present approach), while the halo is RESTRICTED to remain below ~25% of the disk size, say. In your ansatz the disk is tiny compared to the halo size for bright stars. That causes most of the problems under discussion.
This is apparent for the limiting case where halo=0 and the brightness is expressed through a large disk size only:

The mentioned problems are lacking entirely, yet the realism is clearly decreased...

My proposal is to admit <= 25% of halo, but NOT MORE.
This you may easily achieve also by making the Gaussian tail of the halo steeper for sufficiently big disks...

Bye Fridger

[t00fri]

Since Pourbaix obviously took great care to get the distances right, I will eliminate the ?? Equ entry from the visualbin.stc data set in CVS.

Thank you for looking into this. You have me convinced that eliminating ?? Equ entry from the visualbin.stc is the right thing to do.
...
--Chris

I wanted to make clear, however, that the visualbins.stc ORBIT data are in NO WAY inferior wrto ?? Equ! In particular Soederhjelm uses specle-interferometric data in addition for ?? Equ. In my above discussion, it should have become clear that the orbits are really of equal quality from Soederhjelm's and Pourbaix's analysis.

The final "poker" is to "guess"timate who picked the best parallax... As was also discussed above, perhaps one day, one of us has a brilliant idea how to render measurement uncertainties in Celestia (cf. my "error" button above)

Bye Fridger

[t00fri]

Chris,

..and while you are at it, why don't you modify (at last) the GOTO in case of binary orbits such that ALL orbits just fit onto the screen after hitting the G key? I have suggested this many times.

It's easy and a neat feature. I can do it, too, of course. Moreover, I would also prefer to identify the view vector for the G-command with the one corresponding to earth-bound observation of the system. Since it's up to us to choose a direction of approach to the binary system, we may as well take the one corresponding to the sky plane, such that one may directly compare with standard plots from the familiar sources!

Like so, for example,



Bye Fridger

[Hamiltonian]

While the binary files are being revised, can the previously reported distance problem for 85 Peg also be fixed?

[chris]

Chris,

..and while you are at it, why don't you modify (at last) the GOTO in case of binary orbits such that ALL orbits just fit onto the screen after hitting the G key? I have suggested this many times.

I think this is a good idea. I interpret your suggestion to mean that if a star system barycenter is selected, the default view distance should be far enough away that the entire system fits roughly in camera view. But, for a star, the current default of 100*radius is fine. I'd rather not make the field of view be part of the calculation; a field of 45 degrees could be assumed.

It's easy and a neat feature. I can do it, too, of course. Moreover, I would also prefer to identify the view vector for the G-command with the one corresponding to earth-bound observation of the system. Since it's up to us to choose a direction of approach to the binary system, we may as well take the one corresponding to the sky plane, such that one may directly compare with standard plots from the familiar sources!

This I disagree with. It seems much too specialized for the particular task you're involved with now: comparing binary star orbits. I generally subscribe to the 'principle of least surprise' in UI design. In all other cases* the view vector is chosen to lie on the line between the current viewer position and the target object. I'd like to maintain that consistency. The feature that you want is best implemented as a script, possibly one with a few other useful tools for examining binary stars.

--Chris

*An exception is when traveling between locations on a planet. In order to avoid traveling through the planet, a great circle path is chosen.

[t00fri]

Chris,

did you notice also my previous post

http://www.celestiaproject.net/forum/viewtopic ... 8&start=13

about halos etc.?

Bye Fridger

[t00fri]

Chris,

..and while you are at it, why don't you modify (at last) the GOTO in case of binary orbits such that ALL orbits just fit onto the screen after hitting the G key? I have suggested this many times.

I think this is a good idea. I interpret your suggestion to mean that if a star system barycenter is selected, the default view distance should be far enough away that the entire system fits roughly in camera view. But, for a star, the current default of 100*radius is fine. I'd rather not make the field of view be part of the calculation; a field of 45 degrees could be assumed.

Precisely.

It's easy and a neat feature. I can do it, too, of course. Moreover, I would also prefer to identify the view vector for the G-command with the one corresponding to earth-bound observation of the system. Since it's up to us to choose a direction of approach to the binary system, we may as well take the one corresponding to the sky plane, such that one may directly compare with standard plots from the familiar sources!

This I disagree with. It seems much too specialized for the particular task you're involved with now: comparing binary star orbits. I generally subscribe to the 'principle of least surprise' in UI design. In all other cases* the view vector is chosen to lie on the line between the current viewer position and the target object. I'd like to maintain that consistency. The feature that you want is best implemented as a script, possibly one with a few other useful tools for examining binary stars.

--Chris

*An exception is when traveling between locations on a planet. In order to avoid traveling through the planet, a great circle path is chosen.

In the 5 years of working with Celestia, I have never bothered to find out what the view vector precisely was in case of binary orbits etc.
I certainly see your intention to keep things consistent and simple.

Given your above specification of the view vector in general, this should mean that when I select a double star from the /surface of Earth/ and hit the G-key, the observer should move there and see the orbit precisely under the skyplane perspective. Right? If true, this should be sufficient for (amateur) astronomers who want to quickly check out binary configurations (usually for earth-bound observations). The latter represent the main motivation behind my proposal. What happens to the 'North' direction on screen when hitting G?

Astronomers tend to use another frame, though, placing one star into the origin and drawing the orbit of the secondary around it (cf above example). Perhaps, one day such and many other useful frame transformations could be part of a standard Celestia toolbox (Lua...)?

Bye Fridger