1082 open cluster locations

[ajtribick]

An add-on which adds the locations of 1082 open clusters to Celestia. Add the openclusters.dsc file to your extras directory, and turn on Open Cluster display and labelling in Celestia to see the result.

The Perl script generates the openclusters.dsc file from the New catalog of optically visible open clusters and candidates (V2.8), details here.

To run the script you will need the file clusters.dat (download selection page) to be located in the current directory. The script will then generate a file openclusters.dsc.

The script includes hand-editing to add the names of the Pleiades, Hyades and Praesepe, since these names are somewhat better known than Melotte 22, Melotte 25 and NGC 2632.

[ElChristou]

Cool!

[Cham]

Thanks,

this makes a nice replacement for Selden's version.

However, there's now a problem with the labels fading effect in Celestia : The fading effect is too strong. There's no way we could see the global distribution.

Fridger ?

[ElChristou]

yep, the fading is a bit fast...

[Cham]

The label fading should take into account the object's size. Smaller clusters should have a darker label.

[t00fri]

The adjustment of the label fading is an entirely trivial and thus low priority aspect of an opencluster project. It can very easily be adjusted in the code.

Andrew's extraction is quite incomplete, if one aims at a decent rendering of the opencluster.dsc data via C++ code. There are a number of important parameters/aspects missing in his small PERL script. All the needed data are readily available either in clusters.dat or in other standard respective catalogs.

1) One needs the Trumpler type (characterizing concentration-brightness-richness-nebulosity)
Possibly one might again use corresponding templates?

2) One needs the estimated number of stars in the cluster

3) One will eventually need color parameters

4) The names must be completed against a standard second database containing alternative names, including ALL Messier designations. Hand editing is unnecessary, since the respective popular names are also available in the appropriate listings.

I think to list e.g. the Pleiades without adding M 45, or NGC 6705 without M 11 and "Wild Duck cluster" etc, is not a good idea. Such cross listings are readily available. For instance, many of Andrews' opencluster listing will be available also in Steinecke's NGC/IC catalog (with just the change of a flag). There are further extensive cross name listings.

Fridger

PS: For those who don't know :

The Trumpler scheme gives a cluster a three part designation, with a Roman numeral from I-IV indicating its concentration and detachment from the surrounding star field (from strongly to weakly concentrated), an Arabic numeral from 1 to 3 indicating the range in brightness of members (from small to large range), and p, m or r to indication whether the cluster is poor, medium or rich in stars. An 'n' is appended if the cluster lies within nebulosity.

[Cham]

Fridger,

since Celestia is currently only using the cluster's size as a parameter, it would be reasonable to use it as a parameter for the label fading effect.

For the moment, I'm not even asking about a rendering of clusters in Celestia.

[t00fri]

Fridger,

since Celestia is currently only using the cluster's size as a parameter, it would be reasonable to use it as a parameter for the label fading effect.

For the moment, I'm not even asking about a rendering of clusters in Celestia.

As soon as I am motivated, I can do such things pretty fast


Fridger

[Cham]

As soon as I am motivated, I can do such things pretty fast

How can I motivate you to be motivated ?

[t00fri]

As soon as I am motivated, I can do such things pretty fast

How can I motivate you to be motivated ?

I am still trying to tune the globular rendering in some aspects in my little spare time. Also their color simulation is quite a challenge and only half done.

Fridger

[Vincent]

However, there's now a problem with the labels fading effect in Celestia : The fading effect is too strong. There's no way we could see the global distribution.

Martin,

I recently added support for marker labels. This allows you to display, e.g., open cluster labels whatever their distance.
As an example, the following script should do what you want:

Code: Select all

function mark_openclusters()
   for dso in celestia:dsos() do
      if dso:type() == "opencluster" then
         dso:mark( "white", "disk", 1, 0.3, dso:name() )
      end
   end
end

celestia:unmarkall()
celestia:setrenderflags { markers = true }
mark_openclusters()

[ajtribick]

Andrew's extraction is quite incomplete, if one aims at a decent rendering of the opencluster.dsc data via C++ code. There are a number of important parameters/aspects missing in his small PERL script. All the needed data are readily available either in clusters.dat or in other standard respective catalogs.

Indeed. However I'm not well-versed in the technicalities of OpenGL to do the rendering, so I was not aiming at rendering.

4) The names must be completed against a standard second database containing alternative names, including ALL Messier designations. Hand editing is unnecessary, since the respective popular names are also available in the appropriate listings.

I think to list e.g. the Pleiades without adding M 45, or NGC 6705 without M 11 and "Wild Duck cluster" etc, is not a good idea. Such cross listings are readily available. For instance, many of Andrews' opencluster listing will be available also in Steinecke's NGC/IC catalog (with just the change of a flag). There are further extensive cross name listings.

This would definitely be a good thing to include - what are good cross-indices to use? (While we're on the subject of DSO nomenclature, it would be good to expand the galaxy names database to include, e.g. "Sombrero galaxy", "Centaurus A" etc.)

[chris]

Andrew's extraction is quite incomplete, if one aims at a decent rendering of the opencluster.dsc data via C++ code. There are a number of important parameters/aspects missing in his small PERL script. All the needed data are readily available either in clusters.dat or in other standard respective catalogs.

Indeed. However I'm not well-versed in the technicalities of OpenGL to do the rendering, so I was not aiming at rendering.

It's quite useful to have just the locations, however. And I wonder how much extra rendering we actually want to do: adding fictional stars to make the clusters look more realistic might not be such a good idea. I understand that this is exactly what's required for realisitic globular cluster rendering, but is it reasonable for open clusters? I certainly wouldn't want fictional stars in familiar clusters like the Pleiades or Hyades.

--Chris

[Cham]

I certainly wouldn't want fictional stars in familiar clusters like the Pleiades or Hyades.

I absolutely agree with this. Please, no "fake" rendering for the open clusters !

[t00fri]

And I wonder how much extra rendering we actually want to do: adding fictional stars to make the clusters look more realistic might not be such a good idea.
...
I certainly wouldn't want fictional stars in familiar clusters like the Pleiades or Hyades.

--Chris

I absolutely agree with this. Please, no "fake" rendering for the open clusters !

OK then don't complain if I do my own rendering as of now .

I thought the main point of my proven philosophy (-> galaxies, globulars,...) was that we incorporate practically ALL features that can be read off the standard DSO catalogs. For open clusters, this includes characteristic features like concentration, size, brightness, number of stars, nebulosity embedded, etc...

Just like we supported custom templates for the Milky Way, the Pleyades , Hyades and a few other show objects may well receive special treatment. But we have to face >1000 normal clusters for rendering...

A typical open cluster is e.g. M 11. It looks like so:


or the Perseus double cluster NGC 869



So OK, if you dont' want a good rendering of the many clusters that look like M 11, I do...

I certainly will not defend my approach once more.

Fridger

[ajtribick]

This raises the issues of which open clusters are already adequately represented in Hipparcos already so as not to need rendering: the Hyades and Pleiades both seem to be (but look at the position of the Pleiades label with respect to the Hipparcos positions of the stars!!!)

[t00fri]

This raises the issues of which open clusters are already adequately represented in Hipparcos already so as not to need rendering: the Hyades and Pleiades both seem to be (but look at the position of the Pleiades label with respect to the Hipparcos positions of the stars!!!)

Of course, that point I have long folded into my considerations.

Fridger

[chris]

So OK, if you dont' want a good rendering of the many clusters that look like M 11, I do...

I certainly will not defend my approach once more.

Fridger,

Don't take my remark too negatively. I just wanted to point out that the rendering of open clusters may require some different techniques than the ones we're using now for galaxies and what you're developing for globulars. Open clusters are at an awkward 'transition', where some members have HIPPARCOS designations yet many are too faint. When a large fraction of the stars in a cluster appear in HIPPARCOS, I'd argue that no additional rendering is necessary. But I'm sure that the majority of open clusters aren't bright enough to have many members in HIPPARCOS. Could we somehow incorporate stars from other catalogs such as Tycho to give denser clusters without introducing fictional stars?

--Chris

[ajtribick]

Regarding the Tycho catalogue, I am planning on providing the option to incorporate Tycho stars for which "reasonable" (according to the criteria used to vet Hipparcos stars) into stars.dat/revised.stc. (Opinions on whether doing such a thing is a good idea should probably go in the relevant thread)

In fact this open cluster add-on is pretty much me trying to get back into the Perl mindset so I can tackle my larger script after a revision-induced break - I always find that my Perl skills tend to fall off very rapidly when I don't use the language for a couple of weeks...

[chris]

Here's an interesting resource:

http://www.astro.iag.usp.br/%7Ewilton/tabUCAC.html

These are lists of stars in various clusters, with membership probabilities for each. For 6705, there are over 1200 records, though the membership probability for many of them is quite low. Perhaps it would be possible to use these as follows:

- Filter out stars with membership probability below some threshold
- Assign each star a distance based on the distance to the center of the cluster plus a random offset based on the distance of the star from the center of the cluster and the apparent distribution of stars in the cluster
- Spectral type would have to be derived from the UCAC magnitude and 2MASS J, H, and K magnitudes in the cluster--not sure how difficult this is.

--Chris