Celestia Forums

Hello everyone. This is my first post and I may be posting to the wrong forum. If that is the case, accept my apologies.

Auriga is one fascinating constellation for me since I'm particularly drawn toward binary systems. But was terribly disappointed with Celestia interpretation of the stars in this constellation. Am I doing something wrong? Is there something I can do to fix it? Here are the problems:

Alpha Aurigae: It's missing Alpha Aurigae C, itself a red dwarf binary.
Beta Aurigae: It's a ternary system, not a binary. Missing Beta Aurigae C, a red dwarf orbiting the binary system some 300 AU away.
Delta Aurigae: It's not a single star, but a star system made up of a 3 stars, with Delta Aurigae C being itself a binary system.
Epsilon Aurigae: It's not a single star, but a eclipsing binary
Theta Aurigae: It's not a single star, but a binary system.
Zeta Aurigae: Same as with Epsilon

Best regards,
Mario Figueiredo

marfig wrote:Hello everyone. This is my first post and I may be posting to the wrong forum. If that is the case, accept my apologies.

Auriga is one fascinating constellation for me since I'm particularly drawn toward binary systems. But was terribly disappointed with Celestia interpretation of the stars in this constellation. Am I doing something wrong? Is there something I can do to fix it? Here are the problems:

Alpha Aurigae: It's missing Alpha Aurigae C, itself a red dwarf binary.
Beta Aurigae: It's a ternary system, not a binary. Missing Beta Aurigae C, a red dwarf orbiting the binary system some 300 AU away.
Delta Aurigae: It's not a single star, but a star system made up of a 3 stars, with Delta Aurigae C being itself a binary system.
Epsilon Aurigae: It's not a single star, but a eclipsing binary
Theta Aurigae: It's not a single star, but a binary system.
Zeta Aurigae: Same as with Epsilon

Best regards,
Mario Figueiredo

Celestia is a simulation of the Universe in 3d! This means that for any multiple star system, we DO need the full set of orbital elements and the distance of the system's barycenter. Not just the 2d projections to the skyplane...

Celestia is concerned with scientific visualization. This means in turn that we will not display any stars corresponding to incomplete data.

Now that you reminded us about "forgetting" all those above-mentioned orbiting Auriga stars, how about providing scientifically sound measurements of all the corresponding orbital elements?

Fridger

Thanks Fridger,

I can certainly do that. Will investigate further and renew this thread when I have all the necessary data along with the sources.

EDIT: rereading your post I seem to notice you mean to say that there isn't really any current detailed information on these systems, hence them not being visualized?

marfig wrote:Thanks Fridger,

...

EDIT: rereading your post I seem to notice you mean to say that there isn't really any current detailed information on these systems, hence them not being visualized?

Certainly

I have exploited the best available data on visual and spectroscopic binary orbits. The references are in the respective visualbins.stc and spectbins.stc datafiles of the Celestia distribution. Unfortunately, the number of "3d-complete" data sets is not large, only ~ 200.
For star systems with more than 2 components, the situation becomes not only quite complex, but most of all AMBIGUOUS! Please recall that the task is to uniquely reconstruct the full 3d motion of each component merely from observations of their projections to the skyplane... So I am looking forward for your solutions of this well-known problematics, given that you addressed the missed-out multiple systems in Auriga above.

Fridger

Of course, the difficulty of implementation depends on whether you want to show orbital motion or not. If you are willing to have the stars in fixed positions and neglect relative position along the line of sight, it is fairly simple to include these multiple star components.

My current work on the star database will eventually include the multiple star components in the Hipparcos catalogue (specifically, the component solutions) included, but without orbital motion.

Well, I couldn't possibly come with a solution since I'm an hobbyist observer, not an investigator. And not mathematically oriented at that

Will hope however that the observations starting next year on the upcoming eclipses help at least better describe Epsilon and Zeta systems.

Thanks for providing insight as to the other >2 systems, troofi. I've learned something new. And looking forward to see your work ajtribik.

ajtribick wrote:Of course, the difficulty of implementation depends on whether you want to show orbital motion or not. If you are willing to have the stars in fixed positions and neglect relative position along the line of sight, it is fairly simple to include these multiple star components.

My current work on the star database will eventually include the multiple star components in the Hipparcos catalogue (specifically, the component solutions) included, but without orbital motion.

Andrew,

that "static" approach of yours concerning the display of multiple stars via stars.dat doesn't strike me as particularly well motivated in the sense of an algorithm.

So far we assumed a "small parameter" in the HIP star data, namely the small resolution corresponding roughly to visual observations. In that limit, multiple stars collapse to one at the corresponding barycenter. That's what we did so far for binaries where we did not have the complete orbit parameter set available. It's a consistent albeit limited approach.

If I got you right, you are now implementing even multiple star components with a fixed location on their complex orbits? What I dislike here is the fact that depending on the time of observation and the distance of the observer, the result may look COMPLETELY WRONG, despite creating the deceptive impression of accuracy...

I think such static configurations MUST be marked as such in some way, if you really want to pusue your approach.

Fridger

t00fri wrote:

ajtribick wrote:Of course, the difficulty of implementation depends on whether you want to show orbital motion or not. If you are willing to have the stars in fixed positions and neglect relative position along the line of sight, it is fairly simple to include these multiple star components.

My current work on the star database will eventually include the multiple star components in the Hipparcos catalogue (specifically, the component solutions) included, but without orbital motion.

Andrew,

that "static" approach of yours concerning the display of multiple stars via stars.dat doesn't strike me as particularly well motivated in the sense of an algorithm.

So far we assumed a "small parameter" in the HIP star data, namely the small resolution corresponding roughly to visual observations. In that limit, multiple stars collapse to one at the corresponding barycenter. That's what we did so far for binaries where we did not have the complete orbit parameter set available. It's a consistent albeit limited approach.

If I got you right, you are now implementing even multiple star components with a fixed location on their complex orbits? What I dislike here is the fact that depending on the time of observation and the distance of the observer, the result may look COMPLETELY WRONG, despite creating the deceptive impression of accuracy...

Although it would be desirable to have orbital solutions for all binaries, I think Andrew's approach is still worth pursuing. It's certainly 'less wrong' than than not showing the companion stars. And, depending on the orbital period, the star position may remain approximately correct for a long duration.

I think such static configurations MUST be marked as such in some way, if you really want to pusue your approach.

Any ideas on how best to do this?

--Chris

So you are suggesting we do not implement h_dm_com.dat at all? In any case, the static rendering of the binary system would surely indicate that the orbit is not implemented, no?

Plus it is not so clear the orbits files meet such rigorous standards: many published orbits have a degeneracy about which node is the ascending node (and spectroscopic binary orbits often don't have the longitude of periastron), which would also render the system COMPLETELY WRONG at close range or from viewpoints outside our solar system would it not?

I also note that within Celestia there is no indication whatsoever of the companion stars in your binary database for which visual magnitude is absent in the source datafile, nor is this marked up in the .stc file itself with comments, hence various threads about binary star systems having seemingly wrong magnitudes (including this one started by Chris Laurel himself). I'd personally suggest (visual) magnitude is a "showstopper" property: if it is not present in the dataset, the star should not be included.

If we insist on having all relevant parameters for everything, perhaps we should drop all spiral galaxies as well since the relevant database doesn't specify whether they wind clockwise or anticlockwise (thus resulting in COMPLETELY WRONG renderings even from within the Solar System), extrasolar planets (since we have no idea of the orbital inclinations are for most of the planets, hence COMPLETELY WRONG depictions of the system), etc. etc.

Shouldn't probably be addressing this issue since I'm a relative newcomer to the application (have used it in the past but only recently returned to it). But here it goes, for what's it worth...

Justifying a wrong with another wrong won't make it suddenly right, so I can understand troofi POV. On the other hand it's essentially common knowledge that any current rendering of an extrasolar planet motion (shape, mass and in most cases even color) is mostly guess work or strongly conjectural. So I wouldn't put much weight on it being detrimental to the qualities of Celestia. Same goes with some galaxies motion.

After reading the replies, I can see the problem with a static representation of a binary or ternary star system. Periods aren't that long on some of those cases where stars are currently missing (if I remember correctly, Epsilon Aurigae, for instance is just 972 days). In real time, any discrepancy would be made visibly obvious in Celestia after just 1 month. And contrary to extrasolar planets and galaxies motion, this would indeed drop the Celestia accuracy claim significantly since it wouldn't be so obvious to the casual user and at the same time provide no significant new information to the knowledgeable user.

In any case, not having the star(s) represented is also a serious setback. So this is, as I see it, an impasse unless the solution is found outside the problem scope. For that, what is probably missing from Celestia is an object type binary field describing true, and false (or conjectural) data for every relevant attribute of a given object, that would help - why not - build a submenu accessible through the object context sensitive menu.

Chris wrote:Although it would be desirable to have orbital solutions for all binaries, I think Andrew's approach is still worth pursuing. It's certainly 'less wrong' than than not showing the companion stars. And, depending on the orbital period, the star position may remain approximately correct for a long duration.

I definitely disagree. Andrews approach is methodically hard to justify, since there is NO limiting situation, where his approach becomes exact. And so far, we have always agreed to rather leave objects away, before displaying them wrongly due to lack of measurements!

I cannot follow Chris' statement saying that Andrew's approach is certainly 'less wrong' than not showing the companion stars? 'Right' and 'wrong' obviously depends on the OBSERVER's position wrto the multiple system!

Once we support static and thus often completely wrong configurations of binary components at closer distance, what does this approach distinguish from just guessing all the missing orbital parameters?? If we support this, we will be loosing ground methodically on all fronts.

Just go ahead, I have no further comments on this.

Fridger

And so far, we have always agreed to rather leave objects away, before displaying them wrongly due to lack of measurements!

So why have you included the binary systems for which visual magnitude is unknown?
So why have you included the binary systems for which the full orbital elements are unspecified?
So why have you included systems for which the descending/ascending node ambiguity is still present?

What is the justification for inclusion of such systems in the binary files, if the agreed policy is to ignore such objects before displaying them wrongly due to lack of measurements?

t00fri wrote:

Chris wrote:Although it would be desirable to have orbital solutions for all binaries, I think Andrew's approach is still worth pursuing. It's certainly 'less wrong' than than not showing the companion stars. And, depending on the orbital period, the star position may remain approximately correct for a long duration.

I cannot follow Chris' statement saying that Andrew's approach is certainly 'less wrong' than not showing the companion stars? 'Right' and 'wrong' obviously depends on the OBSERVER's position wrto the multiple system!

Once we support static and thus often completely wrong configurations of binary components at closer distance, what does this approach distinguish from just guessing all the missing orbital parameters?? If we support this, we will be loosing ground methodically on all fronts.

I have a big problem with omitting stars just because they happen to be in orbit around another star. Consider Albireo: the two components of the system have been found to be gravitationally bound, though they have a long period. Because of the long period, observations don't cover a long enough time span to determine an orbital solution. Does this this mean that we have to drop the magnitude 3.1 and 5.1 stars? (The answer is no, we cannot omit these stars.) You could argue that for very long period (~7300 years for Albireo, according to http://www.eso.org/public/outreach/eduo ... /comp.html ) system, it is ok to show all the components as static. But, then we must decide on some minimum allowable orbital period. I'm more open to this than I am to just culling stars like Albireo from Celestia's catalog, but it still feels rather arbitrary.

I'm just arguing for the inclusion of the components of visual binary and multiple systems: if we can optically resolve a pair from Earth, we should have both components in Celestia's catalog. For spectroscopic binaries, I'm not sure that it's worth including both components unless there's an orbital solution.

--Chris

chris wrote:

t00fri wrote:

Chris wrote:Although it would be desirable to have orbital solutions for all binaries, I think Andrew's approach is still worth pursuing. It's certainly 'less wrong' than than not showing the companion stars. And, depending on the orbital period, the star position may remain approximately correct for a long duration.

I cannot follow Chris' statement saying that Andrew's approach is certainly 'less wrong' than not showing the companion stars? 'Right' and 'wrong' obviously depends on the OBSERVER's position wrto the multiple system!

Once we support static and thus often completely wrong configurations of binary components at closer distance, what does this approach distinguish from just guessing all the missing orbital parameters?? If we support this, we will be loosing ground methodically on all fronts.

I have a big problem with omitting stars just because they happen to be in orbit around another star. Consider Albireo: the two components of the system have been found to be gravitationally bound, though they have a long period. Because of the long period, observations don't cover a long enough time span to determine an orbital solution. Does this this mean that we have to drop the magnitude 3.1 and 5.1 stars? (The answer is no, we cannot omit these stars.) You could argue that for very long period (~7300 years for Albireo, according to http://www.eso.org/public/outreach/eduo ... /comp.html ) system, it is ok to show all the components as static. But, then we must decide on some minimum allowable orbital period. I'm more open to this than I am to just culling stars like Albireo from Celestia's catalog, but it still feels rather arbitrary.

I'm just arguing for the inclusion of the components of visual binary and multiple systems: if we can optically resolve a pair from Earth, we should have both components in Celestia's catalog. For spectroscopic binaries, I'm not sure that it's worth including both components unless there's an orbital solution.

--Chris

Well, I have nothing against including sufficiently wide visual multiple stars, like Albireo or similar. They can either be resolved visually or at best by means of very small telescopes (e.g. Albireo, 34" separation!), which seems fine for treating the components as "individuals". Such widely separated star components would anyway be part of the standard HIP catalog. Given the wide separation and correspondingly the long orbital period of such visuals, their orbital motion might well become hard to distinguish from proper motion, which we neglect anyway (for a while to come). So again such static inclusions of wide componets would methodically fit into our setup! Clearly we must debate what distance limits we should take as a cut-off.

Obviously, we MUST make approximations of some kind. But what I ask for is that they are methodically justifyable in some acceptable limit. Therefore, I argued against Andrew's announced general inclusion of static multiple star components without presenting critically a set of "cut-off" rules first that are physically justified within the basic setup of Celestia!

Along these lines, it seems NOT a big issue, for example, to admit some guesswork for unknown spectral star classes or magnitudes, be it in HIP or in my binary catalogs. Computer monitors are anyway not very sensititive displays of magnitude or faint color differences for small enough objects.

If it went according to my gusto, then I would have introduced long ago a much more general "limit-of-knowledge" flag/key that allows to study parameter uncertainties within Celestia in some visual manner. In my view as a physicist, uncertainties are usually equally or more important than the measured data themselves.

Fridger

chris wrote:I'm just arguing for the inclusion of the components of visual binary and multiple systems: if we can optically resolve a pair from Earth, we should have both components in Celestia's catalog. For spectroscopic binaries, I'm not sure that it's worth including both components unless there's an orbital solution.

Responding to myself on this matter . . . An incomplete orbital solution for a spectroscopic binary should still be allowed, just as it is for extrasolar planets.

--Chris

Speaking of Albireo . . . Beta Cyg B is a binary, and it appears that there is a complete orbital solution:

http://www-astro.unice.fr/cgi-bin/arist ... erval=17.5

Is this useable? And have we already exploited this database (http://www-astro.unice.fr/cgi-bin/aristidi/dbltab) for binary stars?

--Chris

t00fri wrote:If it went according to my gusto, then I would have introduced long ago a much more general "limit-of-knowledge" flag/key that allows to study parameter uncertainties within Celestia in some visual manner. In my view as a physicist, uncertainties are usually equally or more important than the measured data themselves.
Fridger

If I may?
Herein lies your problems with Celestia...
This program is just as popular with Star Trek fans as it is with those who wish to use the program to view the most accurate and real details of the known Universe. In fact, it is probably downloaded by many more "hobbyists" than it is by scientists. This I say based on the kind of stuff which is being submitted to the Motherlode on an almost daily basis.

My obvious preference is for as much accuracy as I can get. In these cases, I tend to agree with the Good Doctor because he has the knowledge that I will never, ever be able to comprehend myself. And, I also know that many users here are scientists themselves. So, how do we cater to both communities?

This seems to be at the root of all of these problems when it comes to rendering things about which we still know very little. Has it ever occurred to anyone to create two versions of Celestia? One which is dedicated strictly to the facts, and one which is a bit more relaxed and allows other (non-scientific users) a chance to play with their Star Wars Tours? Or, perhaps as the Doctor suggests, a methodology for enabling LOK parameters for everything we see in Celestia when we wish to do this.

This same discussion continues to occur for almost every new feature as it is being developed and/or implemented.
Sorry... 'Twas but a thought I needed to express.

Probably a stupid/unrealistic idea:
All data get an "accuracy tag" kind a1, a2, a3, etc, a1 being the best level of accuracy we have; then a slider to display what is needed, from the more accurate to the less...

chris wrote:Speaking of Albireo . . . Beta Cyg B is a binary, and it appears that there is a complete orbital solution:

http://www-astro.unice.fr/cgi-bin/arist ... erval=17.5

Is this useable? And have we already exploited this database (http://www-astro.unice.fr/cgi-bin/aristidi/dbltab) for binary stars?

--Chris

Maybe as to the first. No, as to the last question,

but how do I get to the cgi-input page? for testing the database...I tried to get back stepwise starting from your link you gave, but no success. You obviously have used that entry point already for Beta Cyg. This site provides a great chance for learning French, Chris

Otherwise, we can send Christophe (ElChristou) to that institute. I think he currently lives in the same city, right?
http://fizeau.unice.fr/article.php3?id_ ... =en&menu=1

Fridger

BobHegwood wrote:

t00fri wrote:If it went according to my gusto, then I would have introduced long ago a much more general "limit-of-knowledge" flag/key that allows to study parameter uncertainties within Celestia in some visual manner. In my view as a physicist, uncertainties are usually equally or more important than the measured data themselves.
Fridger

If I may?
Herein lies your problems with Celestia...
This program is just as popular with Star Trek fans as it is with those who wish to use the program to view the most accurate and real details of the known Universe. In fact, it is probably downloaded by many more "hobbyists" than it is by scientists. This I say based on the kind of stuff which is being submitted to the Motherlode on an almost daily basis.

My obvious preference is for as much accuracy as I can get. In these cases, I tend to agree with the Good Doctor because he has the knowledge that I will never, ever be able to comprehend myself. And, I also know that many users here are scientists themselves. So, how do we cater to both communities?

This seems to be at the root of all of these problems when it comes to rendering things about which we still know very little. Has it ever occurred to anyone to create two versions of Celestia? One which is dedicated strictly to the facts, and one which is a bit more relaxed and allows other (non-scientific users) a chance to play with their Star Wars Tours? Or, perhaps as the Doctor suggests, a methodology for enabling LOK parameters for everything we see in Celestia when we wish to do this.

This same discussion continues to occur for almost every new feature as it is being developed and/or implemented.
Sorry... 'Twas but a thought I needed to express.

Yes, Bob,

I think you phrased things pretty well.

The more the Celestia database grows and the more we adhere to satisfying scientific standards in that data base, the more we tend to hit this general problematics. Yes, and a large (dominant?) fraction of Celestia users doesn't care a bit about all that

Let me present another typical illustration of the problem concerning uncertainties of measurements in general:

++++++++++++++
In physics, an experimental team typically takes their data for a given project within 3 weeks, and then spends 3 years working out the errors for these data! Only THEN can the measurements be accepted for publication!
++++++++++++++

The numerical value of a measured quantity, is simply worth NOTHING in physics/astrophysics, UNLESS at the same time, a convincing analysis of the corresponding uncertainties is presented/published.

ElChristou wrote:Probably a stupid/unrealistic idea:
All data get an "accuracy tag" kind a1, a2, a3, etc, a1 being the best level of accuracy we have; then a slider to display what is needed, from the more accurate to the less...

In visualization, as we attempt it with Celestia, we increasingly need a practical way of displaying such uncertainties. The real problem of visualizing uncertainties as I see it, lies in the diversity of such a task. It's close to impossible to simply code a general "error visualization routine" that might address this job.

Furthermore there is the nightmare of error correlations! Suppose we want to display a functional behaviour,

[tex]y = a\, x + b[/tex]

and the experimental parameters (a, b) habe been measured (a0,b0) with some errors (err_a, err_b)

[tex]a = a_0 \pm err_a[/tex]
[tex]b = b_0 \pm err_b[/tex].

Then usually for displaying the uncertainties of the function y(x), we are NOT supposed to simply run a and b through their individual ranges:

[tex]a_0 - err_a \le a\le a_0+err_a[/tex]
[tex]b_0 - err_b \le b\le b_0+err_b,[/tex]

since actually the errors are NOT independent (i.e. correlated!)
[tex]err_b = some function(err_a)[/tex]

Often the underlying info on correlations (the so-called error matrix) is not even given in the respective publications!

Another crucial problem is that visualization is obviously restricted to 3d, while often the number of parameters with errors is considerably higher than 3. E.g. for orbital uncertainties we can hardly generate an animation running through ALL uncertainties in 5 or 6 graphical dimensions

...and so on...

Fridger