Binary star Delta Equulei defined twice

[chris]

Chris,

did you notice also my previous post

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

about halos etc.?

Yes--I'll get to that.

--Chris

[t00fri]

Chris,

I just looked a bit closer at your orbit drawings for binaries.

I think you did not really choose the orbits adequate for the various possible options:

Take e.g 70 Oph (see image):


1) Suppose you select 70 Oph (barycenter) and switch on orbits. Then what you did is fine.

2) Suppose you select 70 Oph A or B and hit the F-key (<=> follow 70 Oph A/70 Oph B) .

Then you still draw the 2 orbits that physically are only adequate for the barycentric display!

Now the selected star is AT REST and the orbit should naturally be drawn to display the path of the other component about the one at rest! That actually would be handy, since it realizes the requested change of frame that I discussed in my previous post.

Here is a graphical illustration.



After selection of 70 Oph A I used the G-key for an observer located in Hamburg for the two extremal years 1895 and 1930 (cf above image with observational data!). The perspective is about right (as I argued) and can be directly compared with the data above. North is up (grid!) . I hit the F-key (follow 70 Oph A which sets it to rest) .

Your drawn orbits do not make physical sense in the rest frame of 70 Oph A!

Bye Fridger

[chris]

Chris,

I just looked a bit closer at your orbit drawings for binaries.

I think you did not really choose the orbits adequate for the various possible options:

Take e.g 70 Oph (see image):


1) Suppose you select 70 Oph (barycenter) and switch on orbits. Then what you did is fine.

2) Suppose you select 70 Oph A or B and hit the F-key (<=> follow 70 Oph A/70 Oph B) .

Then you still draw the 2 orbits that physically are only adequate for the barycentric display!

Now the selected star is AT REST and the orbit should naturally be drawn to display the path of the other component about the one at rest! That actually would be handy, since it realizes the requested change of frame that I discussed in my previous post.

I agree completely that something needs to be done about this. What I'd really like is a way to display an orbit path in any desired reference frame. Not only would this be useful for showing the orbit of a star relative to its companion, you should use it for displaying the orbit of Cassini relative to Saturn, the heliocentric lunar orbit, the horseshoe orbits of Cruithne, etc. I have no trouble writing the underlying code. The real question is, what should the interface be? What should the user do to indicate that he or she wants to see the orbit of a star in a coordinate system centered on it's companion rather than the system barycenter? Perhaps the UI doesn't need to be completely general, but it would be nice if it could at least flexible enough for binary stars orbits and the cases that I mentioned.

--Chris

[t00fri]

I agree completely that something needs to be done about this. What I'd really like is a way to display an orbit path in any desired reference frame.

Of course, that's what I am arguing since a while!

One may ask why you did not do it in the first place, if you wanted to do it anyway?

The mistake of your present orbit realization was that it was implicitly assumed that orbits are frame independent. You may call this again an approach in "small steps" towards perfection . But actually, it's basically inappropriate.

Not only would this be useful for showing the orbit of a star relative to its companion, you should use it for displaying the orbit of Cassini relative to Saturn, the heliocentric lunar orbit, the horseshoe orbits of Cruithne, etc. I have no trouble writing the underlying code. The real question is, what should the interface be? What should the user do to indicate that he or she wants to see the orbit of a star in a coordinate system centered on it's companion rather than the system barycenter? Perhaps the UI doesn't need to be completely general, but it would be nice if it could at least flexible enough for binary stars orbits and the cases that I mentioned.

--Chris

As my example shows (the above Celestia illustration might have arrived AFTER you wrote your post!) , in many cases a sensible orbit drawing is /unique/, i.e. determined by the frame/symmetry/dynamical configuration under consideration.

So, in many cases no particular interface is even necessary! These obvious cases at least should be correctly implemented before one contemplates about some possible special cases where perhaps an interface might be convenient. At least that would be my preference hierarchy.

In the above 70 Oph example, there is only one sensible orbit to be drawn that the code should switch to AUTOMATICALLY, once you put 70 Oph A to rest by hitting the F-key!

Bye Fridger

[ajtribick]

Fridger - I agree with you on the switching when a component is focused. However just a few things I'd like to think through here.

Firstly, if the B component is selected, should the orbits still be drawn with respect to A?

Suppose we have a system of more than one star, e.g. A-BC where B and C form a close pair, and A is in a distant orbit. If, say, component B or C is selected, how should the orbits be drawn? Presumably the measured orbit of the BC pair would be depicted in the literature with respect to B, but when both the A-BC and the B-C orbits are drawn, this could start looking a bit strange.

[t00fri]

Fridger - I agree with you on the switching when a component is focused. However just a few things I'd like to think through here.

Firstly, if the B component is selected, should the orbits still be drawn with respect to A?

Suppose we have a system of more than one star, e.g. A-BC where B and C form a close pair, and A is in a distant orbit. If, say, component B or C is selected, how should the orbits be drawn? Presumably the measured orbit of the BC pair would be depicted in the literature with respect to B, but when both the A-BC and the B-C orbits are drawn, this could start looking a bit strange.

Chaos,

first, note that a selection alone is NOT the relevant criterion. The rule is that whenever a star is "transformed to its restframe" it should not have an orbit assigned to it anymore. That appears intuitively sensible, doesn't it?


Only components or barycenters (of subsystems) being NOT at rest in the frame considered should be associated with drawn orbits (around the guy at rest).

+++++++++++++++++
We put a given star to rest, by first selecting it and then hitting the F-key, meaning that everyone should follow that star.
+++++++++++++++++

If -- instead of the A-component-- you want to transform the B-component to rest in a binary system , select it and hit the F-key. Then I want NO orbit for B but one orbit for A, encircling B.

So let's look at your A-BC example. If you select A and hit the F-key, A is transformed to rest and the BC system orbits around A. Therefore, you would need one orbit for the BC barycenter, orbiting around A (at rest) and two (small sized) orbits for B and C, respectively, orbiting around their barycenter.

If, however, you want to transform B to rest, there is also a natural orbit prescription, following my rule: NO orbit for B (at rest), draw orbits of A and C around B. The C-orbit would encircle B very closely, while the A orbit is placed far away from B.

An explicit such example in Celestia is the Luyten 789-6 (Gliese 866) system from nearstars.stc. If you watch the present orbit lines for this multiple system and A or B put to rest, you can easily note, that they are NOT AT ALL a physical/sensible solution.

My orbit rule seems both simple and intuitive to me and in many cases is also unique /without/ an additional interface. Therefore, before contemplating an interface that might handle some possibly additional special cases, these straightforward orbit display rules should be implemented first. The orbit switching should proceed automatically (for now at least).

This is what I would call striving to perfection via "little steps"

Bye Fridger

[chris]

If, however, you want to transform B to rest, there is also a natural orbit prescription, following my rule: NO orbit for B (at rest), draw orbits of A and C around B. The C-orbit would encircle B very closely, while the A orbit is placed far away from B.

An explicit such example in Celestia is the Luyten 789-6 (Gliese 866) system from nearstars.stc. If you watch the present orbit lines for this multiple system and A or B put to rest, you can easily note, that they are NOT AT ALL a physical/sensible solution.

My orbit rule seems both simple and intuitive to me and in many cases is also unique /without/ an additional interface. Therefore, before contemplating an interface that might handle some possibly additional special cases, these straightforward orbit display rules should be implemented first. The orbit switching should proceed automatically (for now at least).

There's a moderate amount of coding work to be done in order to allow the display of orbit in different reference frames. This code is required for the automatic switching you proposed as well as for more complex scenarios. It's something that I'm excited to work on for 1.5.1. After this infrastructure is added, it should be easy to add automatic switching of orbit reference frames based on the current target object (i.e. the object being followed.)

Now, as for the automatic switching . . . Your proposal makes sense for stars (though I'm not completely convinced about the A-BC case) but I don't think it's the right approach for planets and satellites. If you follow a satellite, you don't suddenly want to see the orbits of all the other satellites in the system to be shown in the rest frame of the followed one. Then there's the interesting case of the Pluto-Charon system. Here, if you follow Pluto, I think the right thing to do is to show the orbits of Charon, Nix, and Hydra relative to Pluto rather than the barycenter. But what about following Charon? I think users would be rather surprised to see the orbits of Nix and Hydra in Charon's rest frame, interesting as those may be.

So, I agree with the fundamental idea. It doesn't *have* to be generalized to planets right away, but I think we should at least keep the bigger picture in mind when we design this feature.

--Chris

[t00fri]

...
Then there's the interesting case of the Pluto-Charon system. Here, if you follow Pluto, I think the right thing to do is to show the orbits of Charon, Nix, and Hydra relative to Pluto rather than the barycenter. But what about following Charon? I think users would be rather surprised to see the orbits of Nix and Hydra in Charon's rest frame, interesting as those may be.

--Chris

I think my scheme is perfectly consistent and even most educational as to the Pluto-Charon system. In fact your example (Charon at rest) has an amusing parallel to the complicated appearance of planetary orbits the old-time scientists were faced to explain when the EARTH was still considered to be the center of the Universe (Ptolemaic system)! This is a familiar story we tell our students of celestial mechanics . Are you saying that it is NOT instructive to illustrate the Ptolemaic system in Celestia??


Nobody is forced to switch on the orbit display in the Charon rest frame if he/she wants to see /simple/ orbits. But to illustrate the intriguing effects of such frame transformations it's JUST the right thing to do and this is PHYSICS.

If one follows the orbits of Pluto's moons in the charon rest system, the moons perform small retrograding loop movements (not encircling Charon!), just as the planets appear to move in the skyplane in the EARTH rest frame ...

My rule is just that objects at REST should NOT be associated with any orbit lines. All other orbits refer to that rest frame. As simple AND intuitive as that.

In any case, the present drawing of the orbit lines in the moving Pluto-Charon system with Charon being at rest, looks all but instructive. The drawn moving orbits are simply misleading, since they emphasize the INADEQUATE underlying physics picture!

[Cham]

I agree with Fridger. It's an interesting way of showing things, from a physics point of view. As another example : the charged particles trajectories that I've drawn in my magnetic fields are all relative to the rotating frame, and not in the inertial frame fixed relative to the distant stars. In this special case, the rotating frame is more "natural" than the inertial one, since the magnetic field is stationary in the rotating frame.

I strongly suggest to give the user the choice of orbits with some keyboard shortcut and a menu item.

[Guckytos]

Just my 2 cents,

as a celestia user.

I agree with Fridger and Cham, it's really an interesting way of showing things. And if it is physically correct it should in any case be implemented.

But i also say that if someone does not want it to work that way, for reasons of simplicity or whatever, it should be an option.
An option that is turned on with multiple stars, and normally turned off within a solar system.
But the GUI allows to turn it on in a solar system.

Regards,

Guckytos

[ajtribick]

Hmmm, sorry to dredge up this thread again, but it seemed to get derailed from the original bug report into a discussion of rendering strategies. Meanwhile, in the datafiles on the CVS, Delta Equulei is still defined twice!

[t00fri]

Hmmm, sorry to dredge up this thread again, but it seemed to get derailed from the original bug report into a discussion of rendering strategies. Meanwhile, in the datafiles on the CVS, Delta Equulei is still defined twice!

Done...

Developers never forget

Bye Fridger

[t00fri]

Hmmm, sorry to dredge up this thread again, but it seemed to get derailed from the original bug report into a discussion of rendering strategies. Meanwhile, in the datafiles on the CVS, Delta Equulei is still defined twice!

Done...
85 Peg (HIP 171) is also taken care of as well as HIP 85582

Developers never forget

Bye Fridger

[ajtribick]

Cheers... saw the post over in Developer Talk as well.