Celestia Forums

MCL2STC v1.0 is now available.

http://www.lepp.cornell.edu/~seb/celestia/files/mcl2stc.zip
1.5MB, expands to about 4MB.

The programs mcluster_sse and mcl2stc are a small fraction of the size. Most of the space is occupied by the Cygwin runtime system. It should run under Windows 7 x64, which is where I developed it. It'll probably run under XP or Vista, but I don't know for sure. The source code will have to be built from scratch on computers running other operating systems.

mcluster_sse can be used to generate a variety of open or globular clusters.
mcl2stc translates the output of mcluster_sse into stc format for use with Celestia.

Please read the included mcl2stc_readme.txt for usage information.

So now that 13 people have downloaded it (a most auspicious number ),
I'd appreciate some feedback and discussion.

What are your thoughts about it?
Does it work?
How can it be improved?
What kinds of clusters have you generated?

--- edit ---

John,

mcl2stc was compiled using g77. Any Fortran-77 compliant compiler should work.
Specifically, I used
$ g77 --version
GNU Fortran (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

In principle, gfortran can be persuaded to limit itself to the Fortran-77 standard, although I haven't tried to do that.

mcluster_sse built with no errors using
$ gfortran --version
GNU Fortran (GCC) 4.3.4 20090804 (release) 1

although I did have to change its Makefile to put $(CFLAGS) at the end of the line that does the linking, instead of near the beginning.

Selden,

usually gfortran is the fortran compiler most people (e.g. scientists) use for the few cases fortran is still of interest.... MCluser_sse was also originally compiled, with gfortran if I correctly remember. I compiled the original MCluster_sse about 2 weeks ago with gfortran under Linux (OpenSuse 11.3) without any problems. But your fortran code did cause a number of syntax-related errors. I had no time yet to investigate. But it would certainly have been beneficial to quote the compilation string you were using (or better a Makefile, of course).

I have a fairly large number of astrophysics-related comments, but for now I have no time ...
Perhaps, end of the coming week, I might find some time. Probably, my comments will be of no concern to most of your fictional cluster "fans".

Fridger

--- edit ---

john Van Vliet wrote:was thinking cygwin was using 77 and not 95

I have not yet built in on suse11.3 or sl6

John,

the remining GNU-based fortran compilers are able to switch between F77 and F9x. They can also accomodate 72 column-based sources and "free" coding alike.

For Linux people there is of course no reason to use Cygwin at any moment. Naturally, I have Cygwin installed since many years on all my Windows installations.

Fridger

The build command that I use is trivial.

f77 mcl2stc.f -o mcl2stc

--- edit ---

Those error messages all seem to point to perfectly valid Fortran-77 constructs -- line continuations, debug comments, etc. They kept the base name, but the modern version of the language has only a passing resemblance to its antecedents. That's why the full names of the language variants have a year as the suffix -- you have to know which you're using.

selden wrote:The build command that I use is trivial.

f77 mcl2stc.f -o mcl2stc

Selden,

the f77 command (and script) is really outdated. Why don't you try to compile your code with gfortran using appropriate options.

Fridger

selden wrote:Those error messages all seem to point to perfectly valid Fortran-77 constructs -- line continuations, debug comments, etc. They kept the base name, but the modern version of the language has only a passing resemblance to its antecedents. That's why the full names of the language variants have a year as the suffix -- you have to know which you're using.

Selden,

after being back from Italy (with erratic online connection), I now had a look into your mcl2stc.f code. Your used syntax is strange, indeed, and does not conform to any of the standardized FORTRAN 95, 90, 2008, 2003, 77 layouts (see e.g. http://gcc.gnu.org/wiki/GFortranStandards).

The main reason for the above errors with gfortran | g77 is that you misplaced your continuation character '1' by one column! In (72 column) fixed layout format of FORTRAN77 that you seem to have adopted mostly, the continuation character is required to be in column 6, while commands start in column >= 7. Moreover, your debug character 'd' is NOT allowed in standard F77. In gfortran it may be included via the option -fd-lines-as-code.

The build command that I use is trivial.

f77 mcl2stc.f -o mcl2stc

Judging from your quoted f77 command, you used the oldest and outdated way of invoking FORTRAN compilation! The command f77 is merely a bash shell script e.g. in CYGWIN that makes compiling Fortran programs somewhat easier, by serving as an interface to the 'prehistoric' f2c/gcc combination. The f2c command is REALLY out!

Instead, the GNU development line originally comprised the g77 compiler which is not being further developed since quite a while. One main reason was the basic limitation of g77 to FORTRAN77. Under Windows, it may still be used either via the CYGWIN layer or via g77-mingw32.

The modern and meanwhile standard GNU successor that includes all modern Fortran flavors up to FORTRAN95 is gfortran.
It honors many option flags that allow to easily switch between various syntax standards. The easiest switch is provided by -std=f95, f2008, f2003, gnu, legacy. FORTRAN77 is always recognized as a code subset. Notably

gfortran is known to work on...

x86-linux, x86_64-linux
Windows (x86, cygwin and mingw; amd64-mingw)
MacOS X, Intel and PowerPC (powerpc-darwin and i386-darwin)
x86-freebsd, amd64-freebsd, x86-openbsd
IA64-linux, IA64-hpux
sparc-solaris, i386-solaris
alpha-linux, Tru64
powerpc-aix
mips-irix, mips-linux
hppa-linux, hppa-hpux
s390-linux
powerpc-linux
sh4-linux
sparc-linux

Since CYGWIN offers gfortran as well, it is hard to see why you adopted such an untransparent syntax mix in your simple program mcl2stc for reformatting the mcluster output. Notably, since mcluster_sse compiles perfectly with gfortran and involves a classical F77 code style! Of course I made sure that mcluster_sse also compiles under gfortran@CYGWIN.

Fridger

PS.

Let me know if you are also interested in a number of (critical) comments about using MCluster-generated stars for modeling globular clusters in Celestia.

Fridger,

I've been working on a v2 of the program which addresses some of your comments. I'm using g95 as my primary compiler for that, since it supposedly can generate binaries under Cygwin which do not require redistributing Cygwin's own runtime libraries.

I'd be interested in your comments about McLuster and its algorithms. I suspect its author would be, too.

selden wrote:Fridger,

I've been working on a v2 of the program which addresses some of your comments. I'm using g95 as my primary compiler for that, since it supposedly can generate binaries under Cygwin which do not require redistributing Cygwin's own runtime libraries.

Good!

I'd be interested in your comments about McLuster and its algorithms. I suspect its author would be, too.

OK, my comments refer mainly to using MCluster stars for visualization of globulars in Celestia, i.e. NOT as a source of initial data for N-body simulations etc. . None of what I have to say is really relevent for users that mainly want to enjoy a fictional collection of "glittering gems" in Celestia's display. As a Celestia(.Sci) developer and physicist, I have always been concerned with real data and real astrophysics...

I think MCluster is a useful tool per se, for studying cluster parameter dependences in general, different stages of cluster star evolution, different density models or mass functions. Unlike what you wrote above, I cannot see how MCluster can generate realistic (sparse) open clusters . It is well known, for example, that open and globular clusters differ drastically in the shape of their Color-Magnitude (CM) distributions!
Here is a typical example of Pleiades[red] vs. M53[green]:



[The V-band magnitudes of the stars in M53 have been shifted upwards by 8 in order to fit nicely on the same graph with the Pleiades.]

Correspondingly, globular characteristics like the 'horizontal branch' 'red giants' 'blue stragglers' etc are missing in open clusters. I have always understood Mcluster to be a generator for 'rich clusters' only.

For me it is hard to see how these different characteristic globular features should be switched on | off in Mcluster merely by implementing different evolution ages ...

+++++++++++++++++++++++++++
Let me next turn to some serious problems I see with a visualization of globulars by means of Mcluster stars read into Celestia.
+++++++++++++++++++++++++++

• A main challenge of my implementation of globulars in the official Celestia distribution was to make sure that the globulars retain their nominal apparent brightness when the resolution decreases such that the individual cluster stars begin to overlap! In OpenGL, the hardware-imposed linear blending of overlapping pixels is inappropriate and thus needs to be corrected for.
  
  The only practical solution I know is what I did: the resolution dependent blending of a single diffuse "core sprite" for a globular at low resolution with an individual cluster star distribution at sufficiently high resolutions. The brightness of the un-resolved cloud sprite has to be matched to the integrated brightness from the resolved cluster stars that have a luminosity distribution according to I. King in my case.
  
  This crucial resolution-dependent aspect is entirely missing if one just enters a collection of cluster stars from MCluster into Celestia! By generating a typical MCluster globular with a King shape, I checked explicitly that the integrated cluster brightness becomes a problem.
  
  
• Since Celestia(.Sci) strives for a scientific-level visualization, we need to represent the globular clusters by shape models for which the cluster parameters have actually been extracted in form of scientific catalogs. The complete list of galactic globular cluster parameters is indeed available for the King-based models that I have used. For most evolved MCluster stars the association with published catalog parameters (Harris,...) remains quite obscure to me.
  
  
• Celestia does NOT include evolution code of its stars. Rather they are entered from catalog data of 'today'. Correspondingly, the evolution code in MCluster must be used as of 'today', otherwise color and other distributions will become grossly wrong.

Let me finally mention a much more realistic option for implementing REAL globulars without using MCluster at all:

Go to the SDSS database http://cas.sdss.org/dr6/en/proj/advance ... .asp#query
and enter a simple batch SQL query for all ~150 galactic globulars about like so:


One for each globular and with central (RA, DEC) & radius properly entered.
This will print out all resolved stars (coordinates & colors, mags) for each globular. The color magnitude diagram will be perfect etc.

Hope this was kind of useful...

Fridger

EDIT: In Celestia.Sci, I use the SDSS query only for extracting the correct color-magnitude distribution data for each globular. They are then used for the statistical generation of cluster stars with correct color and magnitude...

Fridger,

Thanks for the explanations!

McLuster is augmented with the SSE routines by Hurley, Pols & Tout (2000) to do the stellar evolution. That's separate from the mass density distribution code.

McLuster generates five different types of mass density distributions, one of which is called "EFF". With appropriate parameters, EFF can be used to simulate the mass distributions seen in the younger clusters in the LMC. Any of the five mass distributions also can have a fractality specified to simulate the fractal nature of molecular clouds.

selden wrote:Fridger,

Thanks for the explanations!

McLuster is augmented with the SSE routines by Hurley, Pols & Tout (2000) to do the stellar evolution. That's separate from the mass density distribution code.

McLuster generates five different types of mass density distributions, one of which is called "EFF". With appropriate parameters, EFF can be used to simulate the mass distributions seen in the younger clusters in the LMC. Any of the five mass distributions also can have a fractality specified to simulate the fractal nature of molecular clouds.

Selden,

yes, I am aware of that. I was always talking about MCluster_sse that includes the Hurley&Tout evolution. I also have read the respective original papers. One question along my previous line of argumentation would be where to find the actual globular parameters that are referring specifically to the EFF model .

What should be really done is to generate a number of color-magnitude diagrams of representative globulars by means of evolved MCluster stars and then to compare to the actual ones from SDSS! I doubt that the resemblance will be all that close

Fridger

selden wrote:Fridger,

I'm using g95 as my primary compiler for that, since it supposedly can generate binaries under Cygwin which do not require redistributing Cygwin's own runtime libraries.

Selden,

here's some background info about g95...

http://gcc.gnu.org/wiki/TheOtherGCCBasedFortranCompiler

The gfortran compiler actually started life known as g95, meant to replace the older g77 compiler. Somewhere along the development path, the project maintainer of g95 began violating the terms of the GNU compiler, namely only offering binary versions of the software. Because of the violations, some team members branched gfortran from an older g95 version and completed development of the compiler.

Long story short, the gfortran compiler is the GNU-supported Fortran 90 compiler.
At this time, gfortran can be considered a "version 1" product, meaning some bugs may be present, but it is ready for the production environment.

In the scientific community, where there is still some (residual) FORTRAN activity to be found, gfortran is used almost exclusively. From my inside knowledge I am thus convinced that gfortran is tested much more thoroughly with complex (scientific) code projects compared to g95.

Fridger

EDIT: Of course there are installer-driven binary versions of gfortran. This makes native Windows versions of gfortran available from the command line and does not even require CYGWIN at all.

http://gcc.gnu.org/wiki/GFortranBinariesWindows

selden wrote:Fridger,

I've been working on a v2 of the program which addresses some of your comments. I'm using g95 as my primary compiler for that, since it supposedly can generate binaries under Cygwin which do not require redistributing Cygwin's own runtime libraries.

I'd be interested in your comments about McLuster and its algorithms. I suspect its author would be, too.

I know its been more than a year but when can we expect version 2 because I noticed a bug in version 1. The further away the star cluster is from the earth, the further apart the stars are. Its most noticeable when you are trying to put a star cluster in another galaxy.

I also noticed that mcl2stc doesn't work with data made with the most recent version of mcluster. I'm working on a C++ version of mcl2stc that will be compatible with the newest version of mcluster (and any future versions as long as they don't add, remove or change the order of the columns in the output). Wish me luck as converting FORTRAN to C++ is hard.

Good luck!