Welcome
... to the homepage of MESA, modules for experiments in stellar astrophysics.Overview
Background
How do you say that?
What does thread-safe mean?
Why Fortran? Isn’t C++ better?
Which Fortran 95 Compiler?
This plot is a hint of the sort of experiments in stellar astrophysics that MESA will support.
It shows the state of a 4 Msun star during a second ascent of the Red Giant Branch computed with MESA modules.
Included are the
HR track, the time history of the central temperature vs density, and the profile of the star
in the temperature and density plane with the background colored to show the pressure.
Overview
The software project MESA, Modules for Experiments in Stellar Astrophysics, aims to provide state-of-the-art, robust, and efficient open source modules, usable singly or in combination for a wide range of applications in stellar astrophysics. It includes modules for various aspects of the physics, such as nuclear networks, opacities, and equation of state, as well as modules for various algorithmic components such as high order implicit solvers for stiff ODEs. Each module is constructed as a separate Fortran 95 library to facilitate independent use and development, and each includes a test suite and an explicitly defined public interface. The modules are designed to be “thread-safe” for use with shared memory parallel processing, a mode of operation that promises to become dominant with the advent of multi-core processors.
The MESA nuclear networks module is based on Frank Timmes’ previous codes and includes options ranging from a small basic net for standard hydrogen, helium, and carbon/oxygen burning, to a large net with an alpha chain to 56Ni, hot CNO reactions, and some early rp-process reactions. MESA’s equation of state module combines Timmes’ HELM eos for high temperature ranges with the OPAL eos for lower temperatures at typical intermediate-mass and low-mass stellar densities, and the SCVH eos (Saumon-Chabrier-van Horn) for even lower temperatures and substellar densities. MESA’s opacities module combines the OPAL tables, including options for enhanced carbon and oxygen abundances, with low temperature tables from Jason Ferguson. MESA’s neutrinos module provides a routine for calculating energy loss rates for neutrinos from sources other than nuclear burning, based on the Itoh fitting formulas.
MESA’s 2D interpolation module provides bicubic spline routines in single and double precision. The MESA 1D interpolation module includes both Steffen’s piecewise monotonic cubic algorithm and Huynh’s monotonicity preserving cubic interpolation scheme. The MESA modules for solver algorithms include a globally convergent Newton iteration routine and high order solvers for ODEs and DAEs.
The modules mentioned above are currently available for download from the MESA website, and they will soon be joined by others that will make use of them to do 1D stellar evolution. The goal is to eventually provide several evolution codes sharing a common set of MESA modules for the physics and solver algorithms: the first will be for 1D implicit, quasi-hydrostatic evolution; it will be followed by ones for implicit and explicit hydrodynamic evolution in 1D. In addition, during the next few years, working with Frank Timmes and others, we will add to MESA the capability to produce SNe Ia models with a variety of flame propagation algorithms and evolve pre-supernova massive stars from birth to the formation of an iron core. The use of a common set of underlying modules should greatly reduce the cost of creating such a family of codes and increase the ability to explore new alternatives for their design and implementation.
Background
The MESA project came about as a result of my work to create a new 1D stellar evolution code to replace EZ, my previous effort in that area. Along the way Frank Timmes got involved since I wanted to make use of some of his wonderful software for the microphysics. As the pieces of the new system started to become real, it became clear that in this case the parts would actually be of greater value than the whole! And that’s how MESA was born—as a set of “modules for experiments in stellar astrophysics”—inspired by my new work on a new 1D code, but potentially useful for a much wider range of applications.
The assumption behind MESA is that it will be well worth the extra effort to create independent, reusable modules. In their book titled “Numerical Simulation of Reactive Flow”, Oran and Boris include the following comments about such an approach:
The [system] should be an assembly of relatively independent software modules, each representing a particular physical or chemical process… These modules should be as separate and self-contained as possible so that they may be reconstructed and changed independently by the users. This modular approach to building complex computer programs stresses flexibility and robustness in the algorithms and techniques. The specific modules are the enduring elements of the effort, rather than completely integrated simulation models.
I recently came across a another clear statement of this philosophy. Under the heading of “Some general advice” in a document about the GNU development tools, Eleftherios Gkioulekas wrote the following:
Every library you write becomes a legacy that you can pass on to other developers. Just like in mathematics you develop little theorems and use the little theorems to hide the complexity in proving bigger theorems, in software engineering you develop libraries…
The most valuable software legacy takes the form of reusable pieces rather than complete systems. I hope MESA will be that kind of a legacy, helping you to be more productive and to have more fun with your experiments in stellar astrophysics.
Cheers,
Bill Paxton
How do you say that?
Say MAY-sa.
What does “thread-safe” mean?
“Thread-safe” simply means that users can take advantage of multicore processors.
For example, during stellar evolution, you need to evaluate the eos at lots of points:
do k = 1, num_zones
call eos(T(k), rho(k), ....)
end do
Most fortran compilers (ifort and gfortran and others) support OpenMP, so the loop can be made to run in parallel by adding 2 lines of magic:
!$OMP PARALLEL DO PRIVATE (k)
do k = 1, num_zones
call eos(T(k), rho(k), ....)
end do
!$OMP END PARALLEL DO
Now, if I have 16 cores, I’ll have 16 threads of execution evaluating the eos.
By doing similar changes for the nuclear reactions, the opacities, etc., the overall performance scales (almost) linearly with the number of cores. Wonderful!
However, for it to work, the implementation needs to be thread-safe. In practice this means, making shared data read-only after initialization. Working memory must be allocated from the stack (as local variables of routines) or allocated dynamically (using fortran95’s allocate primitive).
So, basically it boils down to avoiding common blocks and save’s. It’s easy to arrange for this in new code; it can be nasty converting old code however. Also, I should mention that to get the full advantage of multicores, the operation that is being done in parallel needs to fit in the processor cache. In practice, this means structuring things in a stellar evolution code so that you evaluate the eos for each zone (in parallel), then the nuclear net for each zone (in parallel), then the opacity for each zone (in parallel), etc. If instead you structure things to do the parallelism at the zone level so that you have a thread per zone, with that thread doing eos, net, and opacities, you’re likely to overflow the cache and get poor performance. Naturally, MESA/star does it the right way. ;-)
Stellar evolution is perfect for making use of many cores (up to 100’s at least).
Just wrapping “parallel” directives around some loops does it
if the system is designed with that in mind—and MESA is. So when you
upgrade to twice as many cores, you can get about twice the
performance without touching a line of code. Very cool!
Why Fortran? Isn’t C++ better?
For general systems programming, I’d still pick some variant of C, but for numerical work now and in the coming decade, Fortran 95 and it’s follow-on, Fortran20xx, seem to me to be the way to go. It isn’t a general systems programming language, and there are times when I long for good old C laissez-faire, but the restrictions in Fortran are there for a reason: they allow the compiler to produce very efficient code for modern processors.
Here’s another person’s informed opinion on this issue. John Prentice has extensive experience developing large projects in computational physics, and he makes a strong case for using Fortran in such efforts. Here are some of his comments.The main reason C++ has attracted the attention it has in the scientific community is because Fortran 77 was a terribly outdated language. The many weaknesses of Fortran 77 were solved with Fortran 90 however. Fortran 90 has every feature in C that is important to scientific programming… However unlike C++ and C, Fortran 90 is designed to generate executable codes that are highly optimized and thus run extremely fast. An example is pointers. Pointers are integral to C and C++ programming and because the compiler cannot determine whether a pointer is aliased, it is impossible for it to determine interprocedural dependencies. The result is a significant degradation in optimization and extremely slow execution speeds (for most scientific codes, C and C++ generally produce code which is commonly an order of magnitude slower than Fortran 90 codes, based on the benchmarks we and others have done). Fortran 90 pointers are designed to give the functionality of pointers, but with restrictions that eliminate issues such as aliasing.
—FORTRAN 90 vs C++ – an educational perspective
By the way, the differences between Fortran90 and Fortran 95 are minimal and in the right direction, so all of the arguments for Fortran90 apply to Fortran 95 too. The future development of Fortran looks good as well. Someday when Fortran20xx becomes the standard, it will fill in many of the gaps in the current language that I find most troublesome (in particular, pointers to procedures will finally be a first class type rather than limited to arguments to routines). The next Fortran will provide direct support for object-oriented programming, but even with the current version you can benefit by structuring programs using pointers and derived types—MESA makes constant use of this approach.
The following list gives a few web sites that I like for getting started using Fortran 95—check Google for many more!
—Introduction to FORTRAN 90: Student Notes
—Fortran95 for Fortran77 Programmers
—Fortran90 for Fortran77 Programmers
—Fortran 90 for the Fortran 77 Programmer
Which Fortran 95 Compiler?
If you’re looking for a free Fortran 95 compiler, I can highly recommend gfortran. Another excellent free Fortran 95 compiler is g95, and if it supported OpenMP, I’d recommend it also. But currently it doesn’t, and so for now at least, I prefer gfortran.
If you can afford the price, commericial compilers seem to offer better code optimization. Here are some recent results (Feb07) using an Intel Core Duo processor running the MESA nuclear net and eos packages. The times are for ifort and gfortran with -O2 optimization. Each case is run with 1 or 2 OpenMP threads to check how much benefit we are getting from using both processors.
| Relative Runtimes | 2 threads | 1 thread | ratio |
| ifort (net) | 1.00 | 1.86 | 0.54 |
| gfortran (net) | 1.96 | 3.41 | 0.57 |
| ifort (eos) | 1.00 | 1.71 | 0.58 |
| gfortran (eos) | 1.39 | 2.37 | 0.58 |
On the net test ifort is producing code that is about twice as fast as the gfortran code; on the eos test the margin drops but is still large.
Both compilers are doing a good job with multiple threads since both are near the ideal ratio of 0.5 for runtime using 2 processors divided by runtime using 1.
By the way, if you’re on a Mac, and you have linker problems with your compiler, you should try updating your cctools. In my experience, that’s done the trick.
website design by
Andreas Viklund