Auriga oddities

[ajtribick]

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.

I'm afraid I don't see how this squares with

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

These systems lack measurements. Thus the display is going to be wrong. Thus according to your own policies, they should be dropped from the binaries files.

For example, what is the justification to use 5 as the placeholder magnitude? Why not 6? Or 10? This isn't documented in the Perl scripts. And since magnitude determines the system's rendering even at great distances, how can you not say the rendering is COMPLETELY WRONG?

Furthermore, the incomplete parameters of spectroscopic binaries are inevitably going to lead to COMPLETELY WRONG renderings. Why is Fridger being held to a less rigorous standard than he is enforcing on others? According to what he is saying above in the thread, these systems should NOT be included, as their 3D representation is incorrect!

Just what is the policy here? Missing data is unacceptable unless it is Fridger who created the file?

Back to the stars.dat generation: Would it be ok to substitute magnitude 5 for those Hipparcos stars which are missing magnitude information? At the moment my code drops such stars, but why not follow the precedent that has already been set?

On the other hand, since the main part of the Hipparcos catalog uses the same technique to deal with wide binaries that Fridger is objecting to, and we don't want COMPLETELY WRONG renderings in a 3D program, it should be fairly trivial to modify the database generation routine to only render one star per CCDM entry. It will drop a lot more stars but at least it will avoid COMPLETELY WRONG renderings.

[ElChristou]

Otherwise, we can send Christophe (ElChristou) to that institute. I think he currently lives in the same city, right?

If needed and if you gave me exactly what you need, I can go and ask.

[t00fri]

Andrew,

in such a debate that has many complex facets, a number of aspects will always remain unsaid. I was hoping that with addition of some common sense the essence of what is my concern has nevertheless penetrated through. I don't think it is useful that we start pointing with our fingers on each other at this point... Believe me, I am perfectly aware of the general problematics, including visualbins, spectbins, nearstars, ...extrasolar etc...

You might consider that my binary database has been prepared quite a number of years ago, when many other issues concerning data were on a much less solid basis than what they are now. All that I could really do at that time was to DOCUMENT all my assumptions in human readable form via the corresponding PERL scripts.

Common sense dictates that in a 3d visualization venture like Celestia we MUST make assumptions. But not all assumptions are methodically good. Think of the spirit of some perturbation expansion, that is based on some small parameters, such that when they tend to ZERO the correct result will be approached. That is what I would consider a systematic and hence "methodical" approach to our problematics.

++++++++++++++++++++++++++
It is up to us, to single out the "small parameters/quantities" in our setting.
++++++++++++++++++++++++++

We have already quite a few:

• the curvature of the Celestia universe is globally small, such that we can ignore effects of general relativity!
• the "OBSERVER's spaceship" is considered quasi massless, such that it is not subject to gravity effects and can move pretty fast (actually faster than c ) ...
• the allowed time scales in Celestia are small enough (on a cosmological scale) , such that we can ignore proper motion of stars, rotation of galaxies etc, gross errors in our orbits and cosmological evolution (expansion...)
• the range of spectral sensitivity in Celestia is VERY small, namely only corresponding about to the visual window
• the canonical sensitivity for displaying background objects in the Celestia universe is also pretty small, ~6mag, again about that of the human eye.
• the basic resolution for resolving nearby objects is also small, corresponding to that of the human eye or at best to binoculars or small telescopes.

These are the typical Celestia "initial settings" around which we have been doing a perturbation expansion. In a number of those we still got stuck at the "Born level"
I consider 'stars.dat' as the basic data base that (roughly) implements the data of our initial setting up to the level of a small telescope, say (6 < m <10). Anything else, that increases our sensitivity in various directions (brightness, spacial resolution, spectral resolution) should be implemented via special data sets, like deepsky.dsc, visualbins.stc, spectbins.stc, nearstars.stc, extrasolar.stc, ... This is the next order in our perturbative expansion ...

As an immediate application, the components of widely separated binaries with orbital movements so slow that they become comparable to our neglected proper motion of stars, MUST be included as individual objects into our star data base. Similarly, components of multiple stars separated wide enough that they can be resolved visually (or with a small telescope), should be part of the star data base. Finally, components with m>>6 should be skipped in the star data base.

I hope that with these general considerations and examples, I have illustrated a bit, how additional assumptions --that we will be forced to make in the course of time and with increasing completion of Celestia's data base--, should be structured, in order to fit into this rather consistent setting of Celestia.

Fridger

[ajtribick]

Analysis of h_dm_com.dat, for systems containing stars with the same parallax (i.e. reported by Hipparcos to be physically associated)...

Lowest angular separation: 0.08 mas (CCDM 03322-3218 = HIP 16480)
Lowest projected separation: 1.03 AU (CCDM 16555-1154 = HIP 82815)

Greatest angular separation: 29.84 mas (CCDM 10122-2716 = HIP 49977)
Greatest projected separation: 646000 AU (CCDM 18477+4904 = HIP 92219)

Might be possible to filter based on a comparison of the reported errors in RA/Dec versus the angular separation.

Any suggestions for a low distance cutoff? If, e.g. we assume two solar-mass stars and require period >100 years, that implies a cutoff of about 30 AU, though since projected separation is a MINIMUM distance, extending this inwards might be justifiable...

[marfig]

I will probably have to look at Celestia code, because I cannot exactly see how hard is it to implement a binary field that describes the state of information exactness for a particular object (just 2 states for some of the key properties; true and false). For one, it may be a difficult task to fill it for each of the stars in the database... But a default value of 1 could be given to all objects (following the principle that if it is there, data is correct) and then with time alter the value on those instances where this is found to not be true.

An 8bit field, for instance, could help describe 8 different properties, consistent across the several objects of this type (stars on this case). The field would help build a visual information of the object state of correctness in the form of, say, a submenu from within the star context sensitive menu.

This way we could allow for the insertion of new objects simply because the presence of this information makes it correct to insert them (there's fair warning). What properties would be described would be the result of a prior debate in an effort to allow only a small margin of acceptable error types in the database.

What exists now is however awkwardly wrong. I still insist in not comparing this with extrasolar planets or galaxies, but on the other hand there are currently ternary systems being represented as binary, for instance. Despite the arguments, this is a gross error that could disappear if

a) the third star was made available with the next best data and the user could know the information is false
b) the whole system is downgraded to a single star and the user again is made to know the information is false

Arguably each of the described property should have 3 states (True, Conjectural, Incomplete). But that would increase the size of the database considerably.

Regardless, either way, this would have 0 impact on application performance since the information is only necessary after user input.

Never mind me though. I'm probably way over my head.

[t00fri]

I will probably have to look at Celestia code, because I cannot exactly see how hard is it to implement a binary field that describes the state of information exactness for a particular object (just 2 states for some of the key properties; true and false). For one, it may be a difficult task to fill it for each of the stars in the database... But a default value of 1 could be given to all objects (following the principle that if it is there, data is correct) and then with time alter the value on those instances where this is found to not be true.

An 8bit field, for instance, could help describe 8 different properties, consistent across the several objects of this type (stars on this case). The field would help build a visual information of the object state of correctness in the form of, say, a submenu from within the star context sensitive menu.

This way we could allow for the insertion of new objects simply because the presence of this information makes it correct to insert them (there's fair warning). What properties would be described would be the result of a prior debate in an effort to allow only a small margin of acceptable error types in the database.

There is not much to debate. We are talking about >> 100000 stars, hence any hand-editing is both error-prone and not feasible for reasons of time.
You can only read out and make use of reliability info that exists in the respective star catalogs. Nothing else.

What exists now is however awkwardly wrong. I still insist in not comparing this with extrasolar planets or galaxies, but on the other hand there are currently ternary systems being represented as binary, for instance. Despite the arguments, this is a gross error that could disappear if

If triple systems are interpreted as binary ones, that does NOT have to be wrong in the sense of what I detailed above! In the spirit of successive approximations when resolution increases, one may well describe the 2 stars with the smallest distance as one effective star. This consistently reduces the system to a binary. Perfectly normal procedure...

Could you detail why "What exists now is however awkwardly wrong"???

Fridger