A few questions regarding Celestia

[Apollo7]

1) I realize that Celestia does not do binary star systems/orbits, but why are some members of double/multiple systems excluded regardless, as I understand it you could just place them at the right distance yes? For example: Sirius and Procyon B could be simply placed at the right distance (going from semimajor axis) just so they would be in the program.

2) I'm interested in adding some stars to Celestia myself including Wolf 359, Ross 614, Lutyen 726-8A and UV Ceti, amonst others. However when I try to make the appropriate files (.stc for example) I don't know how to make the text files I have into .stc files, any way I can do this?

3) Where is HDE 226868, this is the main star of Cygnus X-1, why is it not in Celestia?

4) Can I add a pulsar to celestia?

5) is it possible to define more attributes to a star rather than RA, Dec, StellarType, AppMag and Distance?

Thanks for your help!

[Paul]

6. Has someone written a FAQ, and if so, could they post it here as a sticky message? These sorts of basic questions really need a FAQ as they've been answered here many, many times before.

Cheers,
Paul

[billybob884]

2) Well, you can't convert a text document to one, you need to make a copy of another pre-existing one, re-name it, and then edit it.

[Jeremy]

2) All you need to do is rename the file, except put a .stc extension instead of a .txt extension. If you can see the extensions in My Computer, go to tools-folder options and click on the view tab. There is a "hide file extensions for known types" that needs to be unchecked.

[granthutchison]

Celestia's stars are taken from the Hipparcos catalogue - many stars, including some nearby dwarf stars, are too dim to appear in Hipparcos, so they'e not in Celestia unless you add them yourself. I think the same may apply to HDE 226868, although I haven't checked.
I think it would be nice to have near space better represented in Celestia, but it's a time-consuming task - simply extracting compatible data from a suitable database isn't enough, since one would also have to exclude the stars already in Celestia's database. For good accuracy, we'd also need to place binary stars in their correct relationship for a given date - is component B north or south, east or west, closer or farther than component A?

You should be able to produce an stc file in your favourite text editor - I use Notepad, and simply save the text with an stc extension instead of txt.

I recall that Rassilon already created a pulsar for Celestia - please just search the forum and you'll find it.

Grant

[t00fri]

Celestia's stars are taken from the Hipparcos catalogue - many stars, including some nearby dwarf stars, are too dim to appear in Hipparcos, so they'e not in Celestia unless you add them yourself. I think the same may apply to HDE 226868, although I haven't checked.
I think it would be nice to have near space better represented in Celestia, but it's a time-consuming task - simply extracting compatible data from a suitable database isn't enough, since one would also have to exclude the stars already in Celestia's database. For good accuracy, we'd also need to place binary stars in their correct relationship for a given date - is component B north or south, east or west, closer or farther than component A?

You should be able to produce an stc file in your favourite text editor - I use Notepad, and simply save the text with an stc extension instead of txt.

I recall that Rassilon already created a pulsar for Celestia - please just search the forum and you'll find it.

Grant

I consider the conversion of an arbitrary professional catalog of celestial objects, like double stars

--The Washington Visual Double Star Catalog, Worley+, 1996,
ftp://adc.gsfc.nasa.gov/pub/adc/archive ... gs/1/1237/

into another format (like that of Celestia), along with a check for and elimination of double occurences,
a more or less trivial task that I performed many times using Perl. It is certainly not work-intensive for people who speak 'Perl';-).

The real problem with most of these catalogs is that the 3d information is lacking that Celestia requires for proper display.

Here are the format entries that the official double star catalog provides:

Byte-by-byte Description of file: catalog.dat
--------------------------------------------------------------------------------
Bytes Format Units Label Explanations
--------------------------------------------------------------------------------
1- 2 I2 h RAh *Right Ascension 2000 (hours)
3- 5 I3 0.1min RAdm *Right Ascension 2000 (minutes)
6 A1 --- DE- *Declination 2000 (sign)
7- 8 I2 deg DEd *Declination 2000 (degrees)
9- 10 I2 arcmin DEm *Declination 2000 (minutes)
11- 17 A7 --- DiscName *Discoverer Code & Number
18- 22 A5 --- Comp *Component Identification
24- 26 I3 a Date1 ?Date of first satisfactory
observation (+1000)
27- 29 I3 a Date2 ?Date of last satisfactory
observation (+1000)
30- 31 I2 --- NumObs *?Number of measures of the object
32- 34 A3 deg pa1 *Position Angle for Date1
35- 37 A3 deg pa2 *Position Angle for Date2
38- 42 F5.1 arcsec Sep1 *?Angular Separation for Date1
43- 47 F5.1 arcsec Sep2 *?Angular Separation for Date2
48- 52 F5.2 mag MagA ?Magnitude of component 1
53- 57 F5.2 mag MagB ?Magnitude of component 2
58- 66 A9 --- Sp *Spectral Types of Primary/Secondary
67- 70 I4 mas/a pmRA *?Proper Motion in Right Ascension
71- 74 I4 mas/a pmDE *?Proper Motion in Declination
75- 82 A8 --- DM *Durchmusterung Zone & Number
83- 84 A2 --- note *Notes

Bye Fridger

[granthutchison]

The real problem with most of these catalogs is that the 3d information is lacking that Celestia requires for proper display.

Ah, now, this is interesting. With the data given in your example catalogue, plus a distance, one could produce an accurate plane-of-sky arrangement of the stars, albeit correct only for either "Date1" or "Date2", whatever they might be for the stars of interest. With the Sixth Catalogue of Binary Star Orbits, an imported distance from another source would allow a full 3D-and-time-specific reconstruction of the star positions.
I know nothing about Perl, but from first principles it seems to me that if it's trivial to weed duplicate data from a pair of catalogues, it should be just as trivial to merge data from two catalogues. What am I missing?

Grant

[t00fri]

The real problem with most of these catalogs is that the 3d information is lacking that Celestia requires for proper display.

Ah, now, this is interesting. With the data given in your example catalogue, plus a distance, one could produce an accurate plane-of-sky arrangement of the stars, albeit correct only for either "Date1" or "Date2", whatever they might be for the stars of interest. With the Sixth Catalogue of Binary Star Orbits, an imported distance from another source would allow a full 3D-and-time-specific reconstruction of the star positions.
I know nothing about Perl, but from first principles it seems to me that if it's trivial to weed duplicate data from a pair of catalogues, it should be just as trivial to merge data from two catalogues. What am I missing?

Grant

NOTHING;-). Since quite some time, I wanted to get into this business, since for me (and you as well, I guess) the real challenge of Celestia comes from the combination of professional level precision with exciting 3d graphics...

I am not interested in implementing Starwars stuff and other phantasy saga's, for example. Of course if people want to do this, please...;-)

Bye Fridger

[granthutchison]

NOTHING

Good. Here, for instance, are orbital definitions for Sirius B and Procyon B, converted from the usual plane-of-sky format (data from the Sixth Catalogue of Orbits of Visual Binary Stars) to the ecliptic system used by Celestia. A distance is required in order to scale the semimajor axis, and a spectral class would also be required to generate the stars themselves - but the 6th Catalogue lists Hip numbers, so these data could be obtained fairly readily from other sources, including Celestia's stars.dat file.
A bit of Kepler and some different trig would allow the calculation of an epoch-specific offset in RA, Dec and distance, or in X,Y,Z coordinates, if that was preferred. But I do like the idea of some future version of Celestia supporting stars in orbit, as defined here.

Code: Select all

"Sirius B" "Sirius"
{
   Texture "bstar.jpg"
   Radius 5800

   Emissive true

   EllipticalOrbit {
      Period          50.09
      SemiMajorAxis   19.8
      Eccentricity    0.592
      Inclination   97.51
      AscendingNode   161.33
      ArgOfPericenter 184.56
      MeanAnomaly     40.89
   }

   RotationPeriod 0.5 # plausible guess
}

"Procyon B" "Procyon"
{
   Texture "bstar.jpg"
   Radius 8400

   Emissive true

   EllipticalOrbit {
      Period          40.82
      SemiMajorAxis   14.9
      Eccentricity    0.407
      Inclination   42.9
      AscendingNode   27.8
      ArgOfPericenter 268.4
      MeanAnomaly     282.5
   }

   RotationPeriod 0.5 # plausible guess
}


How hard would it be to have Celestia support a "star" class of object, which would partake of at least some aspects of Celestia's current, static stars?

Grant

[Guest]

So I did do a cursory search of the board before posting this message, if your trying to say I should have searched all posts from all dates I'm not sure thats entirely fair now continuing...

Usually I get RA measurements in terms of h, m, s. and Dec comes in terms of Deg, m, s. Now in celestia it seems to require a decimal type number for both of these entries. In the past when I've tried to convert h,m,s to just h (with a decimal) I've ended up with values that when inputed into Celestia don't match up with what I know, like the problem where Sirius B ends up 12ly away from Sirius A despite the fact that I used the right values, is there something about the converting process that I am missing?

Additionally I know the problem about the faint stars and I can understand that, hell when I was messing around with L726-8 A and UV Ceti the program was putting their radii at about .02 sol, which is just well very small. (Even Wolf 359 has a radii of .10 Sol or higher). Also in the case of the star 36 Ophiuchi in Celestia, the star (A) is labeled with information from both the A and B components. For instance 36 Ophiuchi B is HD 155885, however in Celestia this name is added to the A component. I'm guessing this is to bring all searches for 36 Oph B back to A, although interestingly the C component, which is quite far away, is included. I'd be happy to add stars myself and contribute something if I can just get the math to work out ^_^.

Anyway, thanks for the replies.

[selden]

Usually I get RA measurements in terms of h, m, s. and Dec comes in terms of Deg, m, s. Now in celestia it seems to require a decimal type number for both of these entries. In the past when I've tried to convert h,m,s to just h (with a decimal) I've ended up with values that when inputed into Celestia don't match up with what I know, like the problem where Sirius B ends up 12ly away from Sirius A despite the fact that I used the right values, is there something about the converting process that I am missing?

RA in STC files is measured in fractional degrees, not hours

[granthutchison]

... if your trying to say I should have searched all posts from all dates ...

Not at all. Just that I thought by providing the name "Rassilon" for you to use along with the word "pulsar", I'd provided a pretty good set of search criteria for you to use . It certainly turned up the thread I recalled - http://www.shatters.net/forum/viewtopic.php?t=1129 - along with a few others that may be of help.

Grant

[Guest]

well then if someone could explain to me the concept of fractional degrees, that would help, I'll go search for it now, if I can add stars in the right locations, as I said, I'll take care of this myself.

[MrBatman]

Would be nice to have binaries and trinaries rotate around barycenters in a future release.

[selden]

Anonymous Guest,

People probably would be much more willing to discuss details if you were to register, if only so we know we're talking to the same person.

By "fractional degrees" I just meant that the units are degrees and fractions thereof. i.e. 1.1 = 1 and 1/10 degrees.

A full circle is 360 degrees = 24 hours. so 1 hour = 15 degrees.
so to convert Hours, Minutes and Seconds into fractional degrees:

# degrees = 15.0 x ( # hours + (#minutes/60.) + (#seconds/3600.) )

Does this clarify things?