Celestia Forums

The latest Celestia 1.6.0 release candidate is available as a binary package for Windows:

http://www.celestiamotherlode.net/creat ... 160RC3.ZIP

If you have experience the 'Error 14001' problems with previous versions of Celestia, please try this package. It should contain all the necessary Microsoft Visual C++ runtime DLLs, enabling you to run Celestia regardless of what other software you do or do not have installed.

The files minormoons.ssc and numberedmoons.ssc have been moved from extras to data. If you install on top of an older version of Celestia, the installer should take care of deleting versions of these two ssc files left in extras. You should check to see that there are not duplicates of small outer planet moons such as Hydra, Sinope, Caliban, etc.

Finally, a non-ASCII character has been removed from solarsys.ssc, fixing problems reported by people trying to edit the file.

--Chris

Well,

with this RC Celestia is no longer able to run under Windows 98. The (translated) error message reads as

Celestia.exe needs a newer version of Windows. Install new version of Windows.

My guess is that the MSVC++ 2008 no longer supports older OS. Question would be if it runs under Windows 2000, can't test that.

Now the question is, drop support for old OS now or wait until the new Qt version?

Regards,

Guckytos

Guckytos wrote:Well,

with this RC Celestia is no longer able to run under Windows 98. The (translated) error message reads as

Celestia.exe needs a newer version of Windows. Install new version of Windows.

My guess is that the MSVC++ 2008 no longer supports older OS. Question would be if it runs under Windows 2000, can't test that.

Now the question is, drop support for old OS now or wait until the new Qt version?

Thanks for testing...

I'd like to support as many configurations as possible, but I'm reluctant to invest any more time in sorting out this runtime DLL issue, especially when I'd be forced to use an older, unsupported compiler to do so. Visual C++ 2008 Express Edition is currently Microsoft's only supported, free compiler. It has supplanted older versions like VC++ 2005.

This survey reports the usage of Win98 and WinME as 0.16% and 0.10%: http://marketshare.hitslink.com/operati ... x?qprid=10
I don't know the exact methodology, but the numbers really are not very motivating... If you or anyone else on the forum wants to run Celestia on a Win98 machine, just use 1.6.0 RC2.

--Chris

Well,

I can understand that reasoning. It's also really straining my old machine, to get the best eye candy from Celestia, that it can provide.

But I think someone should test if Celestia RC3 still runs on Windows 2000. That is still more around and probably in schools. I know for sure a big company that is still using it (and just beginning to upgrade to XP).

If it runs on Windows 2000, drop the support for old systems, if it does not, well perhaps it should be thought about it.

Just saw that according to that survey you quoted Win 2000 is only 1.06%. Hmm, not soo much, but the question is, where it is used.

Best regards,

Guckytos

Guckytos wrote:Well,

I can understand that reasoning. It's also really straining my old machine, to get the best eye candy from Celestia, that it can provide.

But I think someone should test if Celestia RC3 still runs on Windows 2000. That is still more around and probably in schools. I know for sure a big company that is still using it (and just beginning to upgrade to XP).

If it runs on Windows 2000, drop the support for old systems, if it does not, well perhaps it should be thought about it.

Just saw that according to that survey you quoted Win 2000 is only 1.06%. Hmm, not soo much, but the question is, where it is used.

I agree that it's more serious a problem if Celestia isn't working on Windows 2000, and I would definitely work on finding a solution for that OS. I'm optimistic that it won't be a problem, since Win 2000 is very similar to XP. Also, this note on MSDN indicates that only 95, 98, ME, and NT support is discontinued:

http://msdn.microsoft.com/en-us/library/6sehtctf.aspx

There's no substitute for actual testing though. If someone has tried RC3 on Windows 2000, please post your results.

--Chris

Chris wrote:It should contain all the necessary Microsoft Visual C++ runtime DLLs, enabling you to run Celestia regardless of what other software you do or do not have installed.

With RC3 installed Celestia is running without .NET, which I had to install to get the previous RC running. Thank you. Libraries msvcm80.dll, ..cp80.. and ..cr80.., are they still required by Celestia since their "90"-equivalents came into Celestia's home directory now? Or are they obsolete remnants of my RC2 installation which I installed RC3 over?

Heinrich

lidocorc wrote:

Chris wrote:It should contain all the necessary Microsoft Visual C++ runtime DLLs, enabling you to run Celestia regardless of what other software you do or do not have installed.

With RC3 installed Celestia is running without .NET, which I had to install to get the previous RC running. Thank you. Libraries msvcm80.dll, ..cp80.. and ..cr80.., are they still required by Celestia since their "90"-equivalents came into Celestia's home directory now? Or are they obsolete remnants of my RC2 installation which I installed RC3 over?

Heinrich--

Thank you for testing. I am very happy to hear that you're able to run Celestia without having installed .NET. Your report is the one that I was most waiting for, since you had reported problems with RC2. The files msvcm80.dll, msvcp80.dll, and msvcr80.dll are no longer required, because the 90 versions are used instead. I took some care to make sure that no dependencies on the 8.0 runtime remained. The 80 libraries in your install folder are just remnants of the RC2 installation.

--Chris

Is this version EXCLUSIVE to someone that have error 14001?If so,I will wait for the next release candidate or even the final version!

danielj wrote:Is this version EXCLUSIVE to someone that have error 14001?If so,I will wait for the next release candidate or even the final version!

Anyone can use this version. It's worthwhile to test it out even if you haven't seen error 14001.

--Chris

In this RC,is the problem with atmosphere code solved?
Because at least in Earth,when you are on surface,if you change the angle,instead of the atmosphere,appears the deep space,flickering.Also,the top of the sky is too dark.I think it appears in the Open GL 2.0 path,but since the program is almost ready,it appears to be a BIG problem.I saw the effect in Celestia 1.6.0 RC2.

When executing the "Show Redshifts of Galaxies" scenario the following message appears

Fatal Error
Timeout : Script hasn't returned control to Celestia ( forgot to call wait ()? )

Jay,

Optimization was accidentally turned off when RC3 was compiled, so everything runs more slowly, making scripts take longer to run than they should. This is fixed in the final release, which should be available RealSoonNow.

Daniel,

The atmosphere bug has not yet been fixed.

A couple of data file flaws:

* The brightnesses of the components for Capella are incorrect. They are given as 0.06 and 0.08, which would give an apparent brightness of -0.68. Capella is not that bright; 0.08 is the apparent magnitude of both components together.

* There is a typo in starnames.dat: "6915: 96 Psc". The space after the colon should be removed. It prevents the star from being found unless the user actually types in the space at the search prompt.

bdm wrote:A couple of data file flaws:

* The brightnesses of the components for Capella are incorrect. They are given as 0.06 and 0.08, which would give an apparent brightness of -0.68. Capella is not that bright; 0.08 is the apparent magnitude of both components together.

+++++++++++++++++++++++++++
Just in case, note: .stc files want brightness input as apparent magnitudes NOT absolute ones!
+++++++++++++++++++++++++++
Your above statements & estimate sound as if you might have mixed up somewhere absolute and apparent magnitudes.

Next, assuming that you did NOT make that mistake:

The rules of the game are clearly written out in my Perl scripts spectbins.pl and visualbins.pl. Whatever is known in any of the major catalogs is also transferred by computer to Celestia's binary data base. Thus, the primary component of Capella gets app.mag = 0.06, since it's known from the SB9 catalog. However, if none of the major catalogs has an app.mag entry e.g. for a secondary component like Capella B, then -- as a last resort-- I use the app.mag of the entire system from the HIP catalog. That's why Capella B gets app.mag = 0.08 (which is of course somewhat too bright). If such a bad but unavoidable approximation was made somewhere, it is clearly pointed out in a respective comment next to the data. Just look it up in spectbins.stc. The problem is that Celestia NEEDS a numerical value here, despite that value being unknown...

Finally, each numerical data value needs to be understood with a considerable uncertainty! Unfortunately, Celestia does not (yet?) allow to account for uncertainties in a graphical manner.

They are given as 0.06 and 0.08, which would give an apparent brightness of -0.68.

In general, it is hard to calculate the joint app.magnitude for binaries with varying component distances and phase angles. It would be great if one could simply calculate the app. magnitude of the secondary component from that of the primary and that of the whole system...Then we would have a lot less missing entries in astronomical catalogs.

Perhaps you can teach me, how you managed to calculate from app.magA = 0.06 and app.magB = 0.08 a system app.mag = -0.68? In particular, by which arguments a believable system brightness of -0.68 could result in view of the large uncertainties of the individual input brightness values. It becomes totally incorrect to ignore large inherent uncertainties in such naive estimates!

For the Capella system, Andrew spotted a VERY recent preprint (submitted June 4 2009), where new estimates for Capella parameters are given.

http://arxiv.org/abs/0906.0977

Once the dust has settled (i.e. the paper has been accepted for publication by the referee) I may consider using some of these new results for Capella, since Capella is such a well-noted star system.

Fridger

t00fri wrote:

bdm wrote:A couple of data file flaws:

* The brightnesses of the components for Capella are incorrect. They are given as 0.06 and 0.08, which would give an apparent brightness of -0.68. Capella is not that bright; 0.08 is the apparent magnitude of both components together.

+++++++++++++++++++++++++++
Just in case, note: .stc files want brightness input as apparent magnitudes NOT absolute ones!
+++++++++++++++++++++++++++
Your above statements & estimate sound as if you might have mixed up somewhere absolute and apparent magnitudes.

Next, assuming that you did NOT make that mistake:

These are the apparent magnitudes that I am reading straight off the Star Browser. The absolute magnitudes are given here as -0.53 and -0.51. I do not report errors of this kind without checking against available references first.

t00fri wrote:The rules of the game are clearly written out in my Perl scripts spectbins.pl and visualbins.pl. Whatever is known in any of the major catalogs is also transferred by computer to Celestia's binary data base.

This does not mean the source catalogs are without error. I did find the error with the distance of Delta Trianguli as well, if you recall.

t00fri wrote:

They are given as 0.06 and 0.08, which would give an apparent brightness of -0.68.

In general, it is hard to calculate the joint app.magnitude for binaries with varying component distances and phase angles. It would be great if one could simply calculate the app. magnitude of the secondary component from that of the primary and that of the whole system...Then we would have a lot less missing entries in astronomical catalogs.

But we can't do that otherwise we might put some researchers of spectroscopic binaries out of work.

t00fri wrote:Perhaps you can teach me, how you managed to calculate from app.magA = 0.06 and app.magB = 0.08 a system app.mag = -0.68? In particular, by which arguments a believable system brightness of -0.68 could result in view of the large uncertainties of the individual input brightness values. It becomes totally incorrect to ignore large inherent uncertainties in such naive estimates!

I calculated this from the magnitudes that Celestia gives, using the formula (-2.5)?LOG10[100^(-0.2?m1)+100^(-0.2?m2)], with m1=0.06 and m2=0.08. This formula works correctly for the two main components of the ALF Cen system. I do not claim it is entirely accurate for Capella due to the nature of the system. However, surely it is dubious for each of the main components of the Capella system to be a bright as both stars combined. One could discuss the fine points of how accurate my figures are, but that is missing the point. The point is, I have done a quick calculation, compared my results with references and found a discrepancy, based on those results I have good reason to believe the magnitudes for the components of the Capella system are incorrect by a factor of two, and I suggest that someone else review them.

If 0.76 was added to the magnitudes of both components, one would get 0.82 and 0.84 for the two components which give 0.08 when combined using the above formula. I think these values are closer to being correct than the values 0.06 and 0.08.

bdm,

If 0.76 was added to the magnitudes of both components, one would get 0.82 and 0.84 for the two components which give 0.08 when combined using the above formula. I think these values are closer to being correct than the values 0.06 and 0.08.

It is important that you realize the underlying scientific philosophy we have agreed to pursue for Celestia's data base. As a matter of principle, we will not be fiddling with individual numerical values that might look more plausible to some...In order to achieve a consistent data base scheme of scientific standards, any changes to published values should involve a clearcut published and refereed reference!

So please, let me know if you found a refereed scientific publication that confirms your personally preferred apparent magnitudes of 0.82 and 0.84 for the two Capella components that is in drastic disagreement with the value 0.06 for CapellaA from the authoritative

9th Catalogue of Spectroscopic Binary Orbits (SB9) (Pourbaix+ 2004-2009)
http://cdsarc.u-strasbg.fr/viz-bin/Cat?B/sb9.

If we would allow ourselves to correct individual entries on the basis of "I think" or "I suppose" type of arguments, we would soon loose any credibility among scientists and other serious users. If you happen to be a professional astronomer or (astro)physicist, I am certain that you will agree. If not, I ask you to simply believe my word...

I have good reason to believe the magnitudes for the components of the Capella system are incorrect by a factor of two, and I suggest that someone else review them.

What you write here doesn't appear very polite, given my large effort over years of implementing Celestia's data base with 10000+ galaxies, hundreds of globulars and binary orbits... Let me just pretend that my English is not good enough to understand what you were writing here...

I would be grateful if someone made a better suggestion of a simple, transparent strategy of how we could fill the many empty data slots more consistently.

Fridger

From the SB9 website (emphasis mine)

When the object is found, its basic data are displayed: coordinates, identifiers, component identifier (for multiple systems), magnitudes and spectral types (of both components when available or 'combined'). Each system has its internal number in SB9; the first 1439 numbers are identical to those of SB8, the next are assigned sequentially and are, generally, of little use. If there are more than one orbits for a given system, you select the orbit to display.

So in instances where the second magnitude is left blank, we are dealing with combined magnitude... SB9 does not claim a magnitude of 0.06 for the primary star.

The aforementioned arXiv paper on Capella gives V magnitudes of 0.892 and 0.763 for the primary and secondary, with combined 0.073... unfortunately this doesn't fulfil the "published in a refereed journal" criterion.

The paper by Hummel et al. from 1994 (back in the bad old pre-Hipparcos days) gives absolute magnitudes of 0.29 and 0.14 for the primary and secondary respectively, and they quote a distance modulus of 0.62. The apparent magnitudes there are thus 0.91 for the primary and 0.76 for the secondary. The combined magnitude they quote is 0.08.

Both Hummel and the arXiv preprint arrive at the conclusion that the primary has greater total luminosity, but the secondary is brighter in the visual.

Andrew,

indeed, that's the kind of solid information that can bring us further...

ajtribick wrote:From the SB9 website (emphasis mine)

When the object is found, its basic data are displayed: coordinates, identifiers, component identifier (for multiple systems), magnitudes and spectral types (of both components when available or 'combined'). Each system has its internal number in SB9; the first 1439 numbers are identical to those of SB8, the next are assigned sequentially and are, generally, of little use. If there are more than one orbits for a given system, you select the orbit to display.

So in instances where the second magnitude is left blank, we are dealing with combined magnitude... SB9 does not claim a magnitude of 0.06 for the primary star.

I was not aware of that statement on their Website.Still, the tabular form in which the data are presented in SB9, looks really misleading. If they tacitly quote the combined app.mag, why is it then entered into the column for the A component!?

Furthermore, the other acclaimed catalogs ( Pourbaix, WDS, 6ths catalogue...) quote very similar values (0.08) for the A component. Let's hope there is a similar comment hidden somewhere

Here is Pourbaix' data, for example:

The aforementioned arXiv paper on Capella gives V magnitudes of 0.892 and 0.763 for the primary and secondary, with combined 0.073... unfortunately this doesn't fulfil the "published in a refereed journal" criterion.

The paper by Hummel et al. from 1994 (back in the bad old pre-Hipparcos days) gives absolute magnitudes of 0.29 and 0.14 for the primary and secondary respectively, and they quote a distance modulus of 0.62. The apparent magnitudes there are thus 0.91 for the primary and 0.76 for the secondary. The combined magnitude they quote is 0.08.

Both Hummel and the arXiv preprint arrive at the conclusion that the primary has greater total luminosity, but the secondary is brighter in the visual.

I think these evidences are sufficient to justify some respective adjustment in spectbins.pl...

Fridger

PS: Recently I have reconsidered the use of a mass-luminosity relation as a "last resort" in case of missing data. The law L ~ M^b, with b=4.0 for M< 10 M_sol and b=3.5 for M>=M_sol, could easily provide the app.mags of the components. Notably since these laws were derived from binary data, the absolute masses of which being known...

What do you think? Such a ML law looks sufficiently transparent and probably is superior quantitatively (despite familiar uncertainties). Of course one would have to make sure in the code that the relation is only applied to main sequence stars.

From the Pourbaix paper... (emphasis mine)

Table 1 lists the stars identified as VB-SB2. Columns mv1 and mv2 contain the apparent visual magnitudes of both components. When the second column is blank, it is likely that the first one actually represents the overall visual magnitude of the binary. Columns Sp1 and Sp2 give the spectral types of both components. When only one spectrum is given, it is usually the overall system spectrum.

How precise!

ajtribick wrote:From the Pourbaix paper... (emphasis mine)

Table 1 lists the stars identified as VB-SB2. Columns mv1 and mv2 contain the apparent visual magnitudes of both components. When the second column is blank, it is likely that the first one actually represents the overall visual magnitude of the binary. Columns Sp1 and Sp2 give the spectral types of both components. When only one spectrum is given, it is usually the overall system spectrum.

How precise!

Cool scientific wording

Fridger