Cepheid Variables

[t00fri]

We await Harry's (and others) enhancements with excitement and anticipation

Uh, wait a second! I wrote I hacked that up to test it, not to add it to celestia Technically it's an easy change to allow the setting of star-magnitudes from scripts, but I am not happy with letting scripts change something you can only restore by restarting celestia.

And of course this change doesn't help you much without the necessary data, and then you would have to run a script all the time (as some kind of background task ).

So I won't add this unless the developers agree this would actually be a Good Thing.

Harald

I agree, Harald. In view of so many important things on our 'todo' list, it is certainly worth summarizing concretely the expected benefits of incorporating (a few) Cepheids into Celestia;-)...

-- As Harry, Grant and I repeatedly pointed out:

nothing much to see there with respect to the light variation.

-- Although an incorporation is in principle straightforward, in practice it amounts to a lot of work, like always...

>>>
So what insights do we gain by this, compared to other alternatives we have? (note, this is a rephrasing of my original question after 2 pages of discussion'-))
>>>

In my lengthy discussion above I have tried to collect a few pros and cons.

Definitely not enough pros for my taste...

So, it is now a good time for the proponents of Cepheids in Celestia to make their case, convincingly and concisely.

Bye Fridger


PS: As I pointed out above, the question of incorporating variable stars other than Cepheids, is a different matter. Here I am much more sympathetic in agreement with Selden's views...

[Harry]

not to add it to celestia

Awwww, boohoo, wail,,,, Malcolm, goes to get a glass of beer to cry into

Oh what did I do?

But there are still some possibilites:
- get someone who has a say in this to support this idea. As I wrote it's not a technical problem...
- get someone to create a better solution, i.e. real support for variables (see Fridger's post above)
- assuming you are using Windows: compile yourself, or let someone else compile for you, a version of Celestia with this change for Lua added.


Exposing star-magnitude to Lua-scripting has some possible problems:
- it violates the assumption that Celestia is the same before and after you run a script (ignoring the settings) - this is why I want some kind of approval before doing it.
- depending on the number of stars it may not perform well (how many stars are we talking about?)
- this would only work as long as the script is running, i.e. you can't run another script which shows this effect and you must not press ESC
- all data has to be in the script

There are some benefits too:
- it's an easy change (took me <5 minutes), i.e. not much developer resource needed
- it's flexible: which stars change and how they change is completely under the control of a script, i.e. easy to modify. So you are not limited to variable stars, maybe you want to make a star go supernova? (Though I don't know if the hardcoded relationship between magnitude, radius etc. could be used for this )

I don't have an opinion of my own on this matter...

Harald

[Ptarmigan]

question after 2 pages of discussion'-))
snip
PS: As I pointed out above, the question of incorporating variable stars other than Cepheids, is a different matter. Here I am much more sympathetic in agreement with Selden's views...

Oh ! for heavens sakes Fridger !!
In my very first post I said "so why should someone not ask to see Variables playing their part ? "

Note _Variables_ !

I see no 'proponents'.

Then I said
"Equal rights for minority Variables I say"
did you not observe any humour in that ? No, I thought not
I also think if you read Seldens posts, you will find that he also has moved on from the Ceph. question.

After 2 pages of your own making at tedious and diversionary length, I dont really think that I am much bothered by your sympathies any more
:shrug.
Malcolm.

[t00fri]

In order to get into more concrete variable star issues (other than Cepheids;-)), here is the URL of the "American Association of Variable Star Observers" (AAVSO).

http://www.aavso.org

There you find thousands of light curves, can browse in their huge data base, make plots of different quantities of interest etc.

It's fun!

If you want to plot the light curve of Mira, just enter OMI CET as the desired star name and get the plots you want...

In XEphem we read out these data in form of a plot, with a click on the variable star ...

Bye Fridger

[Ptarmigan]

Oh what did I do?

Just one of my little jokes Harry, dont worry about it

I don't have an opinion of my own on this matter...

No, me neither.
But I did think the OP had a right to ask his question, and should not have been treated to red-lettered scorn by Fridger putting the Hubble baggage in there.

Thanks for your thoughts anyway Harry, much appreciated.

Malcolm.

[t00fri]

question after 2 pages of discussion'-))
snip
PS: As I pointed out above, the question of incorporating variable stars other than Cepheids, is a different matter. Here I am much more sympathetic in agreement with Selden's views...

Oh ! for heavens sakes Fridger !!
In my very first post I said "so why should someone not ask to see Variables playing their part ? "

Note _Variables_ !

I see no 'proponents'.

Then I said
"Equal rights for minority Variables I say"
did you not observe any humour in that ? No, I thought not
I also think if you read Seldens posts, you will find that he also has moved on from the Ceph. question.

After 2 pages of your own making at tedious and diversionary length, I dont really think that I am much bothered by your sympathies any more
:shrug.
Malcolm.

Sorry, I noted that you initially used the word variables but then why did you attack me because of being amused over the unrealistic Cepheid proposal?

So do we forget Cepheids now?

Bye Fridger

[granthutchison]

... think of the relative insolation at Mercury and at Pluto,

Now, that one has been brought up so often

Yep! That is one reason why I used it as an example of why we should not be hide-bound in our use of some liberties to make things more errm what word shall I use ,,, ?

Sorry, I think you've maybe missed my point - the appearances of Mercury and Pluto are actually well modelled in Celestia, which is what the FAQ is about.
I'm very much against taking liberties in order to make things eyecatching. But if you find something that is intrinsically eyecatching, I'm very much for trying to incorporate it into Celestia.

Grant

[selden]

Exposing star-magnitude to Lua-scripting has some possible problems:
- it violates the assumption that Celestia is the same before and after you run a script (ignoring the settings) - this is why I want some kind of approval before doing it.

This suggests the need for a save/restore variables function.

- depending on the number of stars it may not perform well (how many stars are we talking about?)

An arbitrary number. Hundreds of Cephids to thousands of pulsars, for example.

It should be left up to the user to decide what performance level is acceptable. It may be dog-slow on today's systems, but not on tomorrow's.

Also, (an implementation detail for the variable stars) if one were varying the luminosity of a model containing multiple points, then it'd be a lot faster than varying the luminosity of many separate models. Of course, it's unlikely that a whole bunch of stars would vary their brightness synchronously, but it'd also be a way to call attention to stars (or other bodies) that are associated with one another in some way (cluster members, same distance, etc.)

- this would only work as long as the script is running, i.e. you can't run another script which shows this effect and you must not press ESC

I don't consider this a problem, just a restriction. Hmmm. One could fake it today using the Mark function if the timing is done right.

- all data has to be in the script

Or in databases read by a program that creates the script. Again, I don't consider this a problem. It's an opportunity!

[Toti]

PS: As I pointed out above, the question of incorporating variable stars other than Cepheids, is a different matter.

Why this distinction?
Can't at some point VARIABLE stars support (ie. var.bright when viewer is far, var.volume and color when he is close, variation curves) be developed for Celestia?
If this is the case: can't CEPHEID variables be treated as a special case of VARIABLE stars? I mean:

1) if rendering hundreds of variable stars (including Cepheids) is a big performance hit for your system (it will), you drag an hypothetical 'Variable Star Amount' slider to the left, discarding a lot of variable stars whith a small variation ratio (including Cepheids), and keeping a smaller quantity of stars with a greater variability that are sent to the render pipeline.
2) if rendering hundreds of variable stars (including Cepheids) slows down almost everybody's systems (most probably), then Cepheid variation curves/references are not shipped with the core distribution, and the Cepheid package gets the 'add-on' status, until more powerful hardware is popularized.

Edit: In both cases, the discarded stars are still there: you can see them as usual, but variation data is not loaded for them, saving memory; in consequence, their variation is not rendered, saving CPU resources.

As you see, it's very similar to the star database policy

Bye

[t00fri]

...
But I did think the OP had a right to ask his question, and should not have been treated to red-lettered scorn by Fridger putting the Hubble baggage in there.

Malcolm.

Malcolm,

while I (also) want to get over with this, I note that you got back on this "Hubble baggage" for the second time.

I now have the suspicion that you might have simply missed the point there, since you probably also did not read my lengthy explanations above.

My original remark concerning Hubble and the age of the universe in the context of Cepheids, was NOT meant as a joke! Not at all meant to offend Etheriel, the originator of the Cepheid thread!

It was actually the only possible sense I could make out from his Cepheid proposal. I feel Selden understood it right away, given his remark on the teaching value.

Could this be about right?

Let me switch gears now:
==============

During our discussion, I had a funny idea. It is still in a RAW stage. Here we go...

Perhaps elusive features like Cepheids & friends are really fun. You even made an inspiring remark in that direction earlier above....I understand that some of what follows must have been also in the back of your mind earlier on?!

In Celestia, we already have a "telescope" mode, (SHIFT Mouse1 dragging), i.e. we may zoom towards smaller fields of view, like with a telescope. This way we can observe Mars and its moons, say, from our backyard position in great resolution and size...

Now the extension of this:

We could as well contemplate another helping "instrument", by going to "photometric mode" . This would amount to a tunably increased sensitivity to light variations within a frame one might set in the sky. Other useful "instruments" to be switched ON|OFF optionally, can easily be considered...

Like one might set filters enhancing or suppressing certain ranges of visible, IR or UV light, for example....

I am sure that we can find many more most instructive applications of this "instrument idea" for teaching, fun and scientific visualization of more elusive phenomena in the universe...

Bye Fridger

[Harry]

- it violates the assumption that Celestia is the same before and after you run a script

This suggests the need for a save/restore variables function.

A well behaved script can make sure it leaves Celestia in the state it was when the script started, so no need for special restore functions. The script would need to read and save the magnitudes when starting, and resetting them when exiting.

Hundreds of Cephids to thousands of pulsars, for example.

With a very simple implementation (sine-wave) it takes Lua about 5-10 ms to change 1000 stars on my 900MHz Athlon, so performance is better than I would have expected.

Also, (an implementation detail for the variable stars) if one were varying the luminosity of a model containing multiple points, then it'd be a lot faster than varying the luminosity of many separate models. Of course, it's unlikely that a whole bunch of stars would vary their brightness synchronously, but it'd also be a way to call attention to stars (or other bodies) that are associated with one another in some way (cluster members, same distance, etc.)

However this doesn't work with the simple modification I did, which can only change the magnitude of stars.

One could fake it today using the Mark function if the timing is done right.

Didn't try, but this would obviously not work when you get closer to the star, it wouldn't change the magnitude display and it probably would be slower. And it's more work to get the distance-dependend brightness right from within a script.
[...]

Harald

[Harry]

We could as well contemplate another helping "instrument", by going to "photometric mode" . This would amount to a tunably increased sensitivity to light variations within a frame one might set in the sky. Other useful "instruments" to be switched ON|OFF optionally, can easily be considered...

I like the idea

Maybe this could even be extended to finally end the discussion about the true brightness on planets I am thinking of a mode with a user-selectable physical brightness range which is mapped on the brightness-range you can see on the screen - if the planet is brighter than the currently selected maximum brightness, it's displayed (mostly) white, and the other way round. E.g. if you go from mercury to pluto in this mode, you wouldn't see much of pluto because it's too dark... (assuming the brightness range is set for mercury).

However I don't expect this to be useful in many cases, and I have no clue about how difficult this would be to implement (can you easily and quickly modify texture-brightness in OpenGL?) - not necessarily best use of developer resources

Like one might set filters enhancing or suppressing certain ranges of visible, IR or UV light, for example....

I am sure that we can find many more most instructive applications of this "instrument idea" for teaching, fun and scientific visualization of more elusive phenomena in the universe...

Sounds great!

Harald

[t00fri]

We could as well contemplate another helping "instrument", by going to "photometric mode" . This would amount to a tunably increased sensitivity to light variations within a frame one might set in the sky. Other useful "instruments" to be switched ON|OFF optionally, can easily be considered...

I like the idea

Maybe this could even be extended to finally end the discussion about the true brightness on planets I am thinking of a mode with a user-selectable physical brightness range which is mapped on the brightness-range you can see on the screen - if the planet is brighter than the currently selected maximum brightness, it's displayed (mostly) white, and the other way round. E.g. if you go from mercury to pluto in this mode, you wouldn't see much of pluto because it's too dark... (assuming the brightness range is set for mercury).

However I don't expect this to be useful in many cases, and I have no clue about how difficult this would be to implement (can you easily and quickly modify texture-brightness in OpenGL?) - not necessarily best use of developer resources

Like one might set filters enhancing or suppressing certain ranges of visible, IR or UV light, for example....

I am sure that we can find many more most instructive applications of this "instrument idea" for teaching, fun and scientific visualization of more elusive phenomena in the universe...

Sounds great!

Harald

Harald,

I must confess, the more I think about it the more I like it, too.

Have a look in the developer list, where I have exposed a much expanded version of the idea...

Bye Fridger

[Toti]

We could as well contemplate another helping "instrument", by going to "photometric mode" . This would amount to a tunably increased sensitivity to light variations within a frame one might set in the sky. Other useful "instruments" to be switched ON|OFF optionally, can easily be considered...

I like the idea

Maybe this could even be extended to finally end the discussion about the true brightness on planets I am thinking of a mode with a user-selectable physical brightness range which is mapped on the brightness-range you can see on the screen - if the planet is brighter than the currently selected maximum brightness, it's displayed (mostly) white, and the other way round. E.g. if you go from mercury to pluto in this mode, you wouldn't see much of pluto because it's too dark... (assuming the brightness range is set for mercury).

Oh, I had this idea some time ago. I thought that the frame sensibility value should be the needed one in order to view earth as we do from space.
I imagined an example very much like yours: a script getting the viewer over Pluto: nothing can be seen. When the user starts asking what is going on, a text appears, informing about light dimming, etc.
Then the text states "Now, let's rise our eye sensibility" and a increasing multiplier shows in the down right corner of the screen, as Pluto gets more and more visible.

[granthutchison]

E.g. if you go from mercury to pluto in this mode, you wouldn't see much of pluto because it's too dark... (assuming the brightness range is set for mercury).

This seems very strange to me. I'm moderately accepting of the notion of expanding the user's sensitivities to light and other portions of the EM spectrum. But you seem to be offering the user the option to limit his/her range of sensitivity in order to produce an effect that wouldn't appear in real life. It's like offering the option of red/green colour-blindness - I just don't see a reason, or a way in which this would appeal to the user.

Grant

[selden]

Grant,

FWIW, it seems to me that it's just a result of generalizing the brightness scaling that Celestia does now. In addition to compressing magnitude differences, it needs to provide the option to expand magnitude differences -- so that, among other things, we could easily see the differences in Cepheid luminosities.

I'm not sure what kind of user interface would be appropriate for this kind of scaling. Maybe something like the graphic XY plots available in some display parameter controls would work. Separate sliders for scaling type,
(from exponential to linear to log), compression amount, and center value might work Digital fields for setting specific values would be needed, too, although they probably wouldn't be used often.

Background for those who haven't followed the frequent discussions about this:
As you know, the human eye/brain combination is extremely non-linear, providing senstivity over a very large range of brightness. The luminosity of astronomical objects varies over an even wider range. Modern display devices can't provide either range of illumination, so Celestia rescales astronomical brightness levels into levels that a display device can actually generate. Right now the only brightness adjustment that Celestia provides is the "Magnitude Limit" control which makes dimmer stars brighter.

(That control actually doesn't go far enough: it stops at 15.1 but needs to go to at least 21st magnitude and preferably 30th).

[granthutchison]

Selden:
I take your point - but it still seems to me that this involves creating a very elaborate interface with which it would be very easy to do something wildly inappropriate, and rather difficult to produce an interesting or informative result. Do you anticipate that knowledgeable users would generate scripts or perhaps celURLs that others could use to see objects of interest made visible in this way?

To add further information to Selden's clarification:
Because the human eye can deal flawlessly with a very large range of apparent brightnesses, Celestia's flat response to illumination actually matches very well what we would see over a range of illumination levels that spans the solar system out to the Edgeworth-Kuiper belt.
The illumination at Pluto's distance from the Sun is, in fact, about the equivalent of indoor electric lighting. Most people are astonished to discover that indoor lighting is so much dimmer than sunlight, because their eyes compensate so well for the altered level of illumination. So my concern about "dark Pluto" options is that the are extremely unrealistic. It would be precisely equivalent to having a DVD movie that offered a "realistic lighting" option which blacked out all the indoor scenes!

Grant

[t00fri]

I have often asked myself what the "special charm" of Celestia might be, preventing people to get tired of it!?

So besides the stunning 3D display and breathtaking accuracy;-) there must be something else...

I think I know meanwhile:

It's the possibility to "work" or experiment with Celestia.

Working is meant here in a general way, notably referring to the creation of addons of completely different nature or to setting up entirely different configurations. And there is a whole lot to discover, of course...

My recent idea of introducing "instruments" in Celestia could significantly contribute in this direction, besides enhancing possibilities for teaching!

I am of course aware that a sufficiently general implementation (as I would ideally dream of), does imply a lot of work and restructuring of the code. This is certainly not something to be expected in the next dot release;-). Yet I am more and more convinced that a simulation as sophisticated as Celestia will greatly benefit from such new degrees of freedom.

I also think that once a sufficiently general instrument class has been set up in the code, adding further ones will be increasingly less effort. A crucial aspect will concern the GUI's for such "instruments". They must be flexible, yet of universal structure and most of all: easy to operate at the user level.

Moreover, this whole domain could become a most fruitful application of our sophisticated LUA scripting facility...

So far, I mentioned only two optical instruments:

-- a "photometer", enhancing and quantifying the possibilities of human light perception.

Note: The ability to quantify the amount of incoming light is much more important than making the instrument more sensitive! I can do lots of nice experiments if my photometer is not much more sensitive than the human eye, but can tell me that a particular star shines at apparent magnitude 5.134, say!


-- various filters to enhance or suppress various bands of the spectrum

Another interesting optical device could be a spectroscope!

There must be a huge world database of star spectra available that one might download and inspect in "spectroscopic mode"!

Spectra of stars are extremely important as some of you may recall from their astronomy classes. People could do most useful exercises about redshifts, the expansion rate of the universe etc...

Further most instructive applications concern the implementation and "photometric" measurements of "normal" variable stars the light of which changes due to occultation of the star by a secondary object! The orbital data of these systems are cataloqued and could easily be implemented into Celestia. One then might inspect the orbiting binaries both from close distance and in photometric mode from long distance, observing the simulated light variations. At this point you sure know what instrument we need next:

--A data recorder, of course (light vs. time)

--A further important set of "instruments" concerns various tools for plotting data and statistical analysis...

--And, of course, the long overdue "instruments" for reading out various coordinates (generalized GPS meters;-))

Let me stop here for now, in order not to make the post
too long...

Bye Fridger

[selden]

Grant and Fridger,

Twice now I've lost long answers due to overloading of the Web server so I'll try to keep this short.

Grant,

I think the user interface for brightness control can be kept relatively simple and have reasonable dafault settings (or even several). I'd expect them to be similar to what have bee used for years to control the on-screen colors in applications that need to create accurate reproductions for things like photography, prepress and commercial movies, for example.

Fridger,

Maybe some simpler, or even primitive, instruments might be easier to implement and be understandable and useful to the novice? I'm thinking of things like bifilar micrometers and blink comparators, simulating the kinds that existed before everything became computerized.

One concern I have is that using sophisticated simulated instruments to investigate a sophisticate simulated universe may lead to a feeling of complete unreality. If you don't understand how the instrument is supposed to work, how can you believe anything it shows you? Maybe it's fudging the results to make up for shortcomings in the information it's supposed to be examining.

[t00fri]

Grant and Fridger,

...
Fridger,

Maybe some simpler, or even primitive, instruments might be easier to implement and be understandable and useful to the novice? I'm thinking of things like bifilar micrometers and blink comparators, simulating the kinds that existed before everything became computerized.

One concern I have is that using sophisticated simulated instruments to investigate a sophisticate simulated universe may lead to a feeling of complete unreality. If you don't understand how the instrument is supposed to work, how can you believe anything it shows you? Maybe it's fudging the results to make up for shortcomings in the information it's supposed to be examining.

Selden,

yes, there is a danger. But if the concept is kept simple, and the tasks interesting, people may WANT to learn.

Just recall for a moment: How many Celestia users are meanwhile capable of surprisingly good image manipulation and produce their own addons.

Perhaps doing own measurements is too dry for many...
Hmm...

In XEphem we have very sophisticated analysis tools built in that may well be called "micrometers" or "photometers". With the cursor you may click on two or more stars and immediately, their mutual distances are displayed in form of labels along the "vectors" connecting them.

There is a tool that allows to draw a line across (a photograph from) a galaxy, for example. Then along that line, the light intensity is plotted. There is also a dialog where the light readout is quantitatively displayed (in form of numbers).

And so on...

I was never all too happy with these tools, since it was not quite obvious who should want to use them: Professionals would use other tools (standardized astronomical software) and for mere playing it was too sophisticated...My criticism always was that useful applications were not obvious to the uninitiated...

For good reasons, therefore, I am emphasizing the need for conceptional simplicity, notably also in the GUI design for the "instruments".

Bye Fridger