Subdwarf prefix

[ajtribick]

As far as I can tell, SIMBAD does not use luminosity class VI to represent subdwarfs, instead it uses the prefix "sd", e.g. this page. Notably, the Hipparcos catalog also follows this syntax.

Celestia can be made to display subdwarfs in this way by making the following change to star.cpp.

Replace lines 442-445, which originally contain

EDIT: realised patch missed a comma - probably hit an undo button in the wrong window...
see below for corrected version.

This seems to work with the star browser and the display. Celestia already interprets the "sd" prefix correctly in stc files.

[chris]

This change seems like a good idea to me, too. I'll commit the patch to SVN.

--Chris

[ajtribick]

oops realised I missed a comma (don't entirely know how given I'd compiled it without problems, I must have hit an undo button or something accidentally)... here's the corrected version...

Code: Select all

        if (lumClass != 7)
        {
            sprintf(name, "%s%s%s",
                    SpectralClassNames[specClass],
                    SubclassNames[subclass],
                    LumClassNames[lumClass]);
        }
        else
        {
            sprintf(name, "sd%s%s",
                    SpectralClassNames[specClass],
                    SubclassNames[subclass]);
        }

[chris]

I discovered one downside to using the sd prefix: using the Qt4 star browser to filter by spectral type becomes a little trickier. When the luminosity class is always a suffix, one can just enter M* to find all class M stars. But this search misses all subdwarf stars when their luminosity class is indicated by the sd prefix. It's not a huge problem, but it is frustrating.

--Chris

[ajtribick]

Coincidentally, this paper just appeared on the arXiv, which suggests using luminosity class VI for the cool subdwarfs, and the sd prefix for the hot subdwarfs (the extreme horizontal branch stars), to distinguish between these two totally different classes of objects. This goes with the general usage: I have never seen the spectral types for the hot subdwarfs written as VI without the sd prefix.

Going by that argument, perhaps the sd prefix should be limited to spectral types O, B (and probably A as well), and then using VI for spectral types FGKM. Since the hot subdwarfs are very different from the other B and O class stars, it is doubtful whether they should be returned in the same search (similar to the way that white dwarfs of the same temperature as main sequence stars do not get returned in a search for, say, A-type stars).

[chris]

Coincidentally, this paper just appeared on the arXiv, which suggests using luminosity class VI for the cool subdwarfs, and the sd prefix for the hot subdwarfs (the extreme horizontal branch stars), to distinguish between these two totally different classes of objects. This goes with the general usage: I have never seen the spectral types for the hot subdwarfs written as VI without the sd prefix.

Going by that argument, perhaps the sd prefix should be limited to spectral types O, B (and probably A as well), and then using VI for spectral types FGKM. Since the hot subdwarfs are very different from the other B and O class stars, it is doubtful whether they should be returned in the same search (similar to the way that white dwarfs of the same temperature as main sequence stars do not get returned in a search for, say, A-type stars).

And of course I read this right after committing your patch to use the sd prefix instead Until reading this paper, I honestly had know idea that hot subdwarfs were so drastically different from cool ones. The recommendation in the paper seems quite reasonable and practical, at least from the point of view of a software engineer trying to implement a UI for searching s star catalog.

--Chris

--Chris

[ajtribick]

And of course I read this right after committing your patch to use the sd prefix instead Until reading this paper, I honestly had know idea that hot subdwarfs were so drastically different from cool ones. The recommendation in the paper seems quite reasonable and practical, at least from the point of view of a software engineer trying to implement a UI for searching s star catalog.

--Chris

So after reading that paper, I patched my patch as follows (same place in the code):

Code: Select all

        if ((lumClass == 7) && (specClass >= StellarClass::Spectral_O) && (specClass <= StellarClass::Spectral_A))
        {
                    sprintf(name, "sd%s%s",
                    SpectralClassNames[specClass],
                    SubclassNames[subclass]);
        }
        else
        {
            sprintf(name, "%s%s%s",
                    SpectralClassNames[specClass],
                    SubclassNames[subclass],
                    LumClassNames[lumClass]);

        }

[chris]

So after reading that paper, I patched my patch as follows (same place in the code):

I agree that this is a good approach: distinct designations for very different object types. Would you go ahead and check this in? It might be good to add a comment with a reference to the paper in case anyone reading the code wants to see a justification for our notational choice.

--Chris

[ajtribick]

The patch (in a slightly modified form, using StellarClass:Lum_VI instead of 7) is now in SVN.

[Derek]

Is this really necessary NPQ123

[Hungry4info]

Is this really necessary NPQ123

True.

I personally prefer a bit of... completeness... in Celestia.

[ajtribick]

Is this really necessary NPQ123

True.

I personally prefer a bit of... completeness... in Celestia.

Huh? What? Care to elaborate?

[Derek]

Hi,

Hungry4info wrote:
Derek wrote:
Is this really necessary NPQ123
True.

I personally prefer a bit of... completeness... in Celestia.

The original "Is this necessary etc" wasn't aimed at the topic rather at some unwanted post which I presume Selden removed and which I found disgusting.

[ajtribick]

The original "Is this necessary etc" wasn't aimed at the topic rather at some unwanted post which I presume Selden removed and which I found disgusting.

It's better not to respond to spammers for this reason: after their posts get deleted we end up with confusing broken threads.

[Hungry4info]

Ah... got it. NPQ123 must've been a screen name. I thought Derek's question was in reference to the addition of the subdwarf classification.

I apologize.

[ajtribick]

Ah... got it. NPQ123 must've been a screen name. I thought Derek's question was in reference to the addition of the subdwarf classification.

I apologize.

So what did you mean by your completeness remark regarding the subdwarf classification?

[Hungry4info]

It's great to have the subdwarf classification in Celestia for the sake of accounting for that possibility. If I've got some sdM star, and I want to put it in Celestia, I can do that properly if Celestia accounts for that class.

If I put M3VI in Celestia, and it works, that would be good.
If I put M3VI in Celestia, and it displays "?" spectral type for a white default star, that is not good.

[ajtribick]

The spectral type parser accepts either form, however the form used will not be retained when the spectral type is displayed in Celestia.

i.e.

"M6VI" will work and display as "M6VI"
"sdM6" will work but display as "M6VI"
"B7VI" will work but display as "sdB7"
"sdB7" will work and display as "sdB7"

[Hungry4info]

Why will Celestia show sdB but not sdM?

"M6VI" will work and display as "M6VI"
"sdM6" will work but display as "M6VI"
"B7VI" will work but display as "sdB7"
"sdB7" will work and display as "sdB7"

[ajtribick]

Why will Celestia show sdB but not sdM?

The reasoning is explained in the paper I linked upthread.