EZ-Web

The standard computational tool of anyone interested in understanding stars is a stellar evolution code — a piece of software that can construct a model for the interior of a star, and then evolve it over time. Evolution codes allow us to check and refine the various physical theories that together compose stellar astrophysics (e.g., atomic physics, nuclear physics, fluid dynamics, thermodynamics); they provide laboratories for performing experiments on stars (e..g, discovering what factors contribute to the formation of red giants); and, they shed light on stages of stellar evolution that may be too fleeting to observe directly in the Universe.

Stellar evolution codes are often complicated to use, and so I've created EZ-Web, a simple, web-based interface to a code that can be used to calculate models over a wide range of masses and metallicities.

• Background
• Using EZ-Web
• Submit a Calculation
• Output File Formats
  • Summary Files
  • Detailed Structure Files
• Support Files
• Limitations
• Bug Fixes & Updates

Background

Stellar evolution codes trace their ancestry back half a century, to a seminal paper by Henyey, Forbes & Gould (1964). With the advent of electronic computers, these authors devised a way to solve the partial differential equations governing stellar structure and evolution. In these equations, spatial gradients are replaced by finite-difference approximations represented on a discrete grid of points, extending from the center of the model to the surface. This leads to a large set of simultaneous equations for the state variables (pressure, density, etc.) at each grid point, which can be solved using matrix methods.

Many evolution codes have been written based on the Henyey method, and various improvements to the method have been introduced over time. Among the most well-known historical codes are those by Eggleton, Kippenhahn and Paczynski — quite a few modern codes are essentially heavily modified versions of these. The Eggleton (1971) code was particularly innovative, in that it introduced an algorithm for automatic redistribution of grid points. This allows stars to be evolved up the red giant branch with only a few hundred points in total, which makes the code very fast.

One descendent of the original Eggleton code is the TWIN code (still maintained by Eggleton), which allows simulation of binary evolution as well as single-star evolution. While the physics in TWIN is quite up to date, it is very user-unfriendly. To address this issue, Rob Izzard and Evert Glebbeek have developed Window To The Stars (WTTS), a superb graphical interface to TWIN.

Bill Paxton has taken a different approach to modernizing the Eggleton code: he has converted it to Fortran 90 and significantly cleaned it up, to produce his Evolve ZAMS (EZ) code. In turn, to make EZ even more easy to use, I have developed a web-based interface named EZ-Web. This interface was originally hosted at the University of Delaware, but — with a number of updates, including the ability to evolve beyond the Helium flash — I've now moved it over to one of my servers here at U. Wisconsin-Madison.

Using EZ-Web

To construct and evolve a model, enter parameters into the form below, and then submit the calculation request to the server. The parameters control what sort of star is evolved, for how long it is evolved, and what sort of output is produced. In order, they are

• the initial mass of the star, in solar units. This value must be between 0.1 and 100.

• the metallicity of the star, as a mass fraction.

• the maximum age to evolve the star up to, in years. If zero, the star will be evolved until the code can go no further.

• the maximum number of steps to evolve the star through. If zero, the star will be evolved until the code can go no further.

• whether to create detailed structure files describing the interior structure of the star.

• whether to use CGS units in output files; if not, SI units are used.

• the email address to which a notification of calculation results should be sent.

Upon submission, the server will perform basic validation on the parameters, and then assign an identification number to the request. If you're submitting many requests in a row, it's a good idea to avoid confusion by noting down which id number corresponds to which calculation.

During a calculation, stellar properties (e.g., radius, core and surface temperature, luminosity) are written to a summary file at discrete time intervals ('steps'), extending up to the specified maximum age or maximum number of steps. If requested, detailed structure files are also written at each step, specifying state variables and associated data at each grid point in the stellar interior. The format of both types of file are discussed below.

After a calculation has completed (which may take a while, if the server is dealing with many requests at the same time), the output files are packaged into a zip file. Then, a notification email is sent to the specified address, containing a link which may be used to download the zip file from the server. Zip files that are not downloaded within a day of creation are automatically deleted.

Submit a Calculation

Output File Formats

Summary Files

Summary files have the filename 'summary.txt'. They are text (ASCII) files containing one line for each time step. Each line is divided into 23 columns, containing the following data:

Note that if the 'Use CGS units' option is checked, CGS units instead of SI units will be used in the summary file (where appropriate).

Detailed Structure Files

Detailed structure files have the filename 'structure_NNNNN.txt', where NNNNN (e.g., 00001, 00002, …) is the step number that the structure is associated with, padded with leading zeros. They are text (ASCII) files containing one line for each grid point of the model. Each line is divided into 36 columns, containing the following data:

Note that if the 'Use CGS units' option is checked, CGS units instead of SI units will be used in the structure files (where appropriate).

Support Files

To facilitate reading EZ-Web files into IDL, I've created functions that load the data into IDL structures (see, for instance, this discussion of how to create and manipulate IDL structures). For reading summary files use read_ezweb_summary.pro, and for reading structure files use read_ezweb_structure.pro. Note that both functions convert all data to SI units, irrespective of what units are used in the file.

Limitations

EZ-Web and the underlying EZ code have a number of limitations which restrict their validity. In some cases, the results can be misleading or inaccurate, and users should be aware of this if using EZ-Web for research purposes. Issues of particular importance are as follows:

• Hydrodynamical effects are not included. Thus, when the time step becomes shorter than the dynamical timescale τ_dyn (for instance, during phases of very rapid expansion or contraction), the code will stop.

• The exception is the core helium flash (for stars in the approximate mass range 0.7 M_☉ < M < 2.1 M_☉) ; the code can treat the flash, albeit in an approximate manner. This is done by evolving a higher-mass star until it has the same-mass helium core, and then stripping material away from the outer layers until the total mass also matches. This generally works, but has the drawback that the distribution of metals in the post-flash star is wrong.

• Severe degeneracy (typically, in white dwarfs) is not properly handled, and causes the code to stop.

• Departures from ideal-gas behavior due to plasma interactions (also typically in white dwarfs) are likewise not properly handled, and cause the code to stop.

Bug Fixes & Updates

• 2009/11/05: Mark Fardal from UMass has brought to my attention the fact that the mean molecular weight (μ) values in structure files seem way too large. It turns out that I made a mistake in converting from g to kg; the problem is now fixed, but any structure files calculated prior to this date will contain μ values that are off by a factor of 10⁶.

• 2009/11/24: Josh Shiode from UCB has pointed out that in some cases the summary files can contain lines with duplicate and/or non-monotinic step numbers. A little research reveals that this occurs when EZ has to backtrack in time in order to get models to converge. I've fixed this issue, and also corrected an off-by-one error in the step numbers reported in the summary files — prior to this fix, the values were one less than they should have been.

• 2009/12/04: I've discovered that incorrect values were being reported in the ε_3α column of the structure files; instead of the power due to triple-alpha reactions, the power due to all helium-consuming reactions (e.g., including carbon burning: ¹²C + ⁴He → ¹⁶O) was listed. I've fixed this, and moreover extended the structure files to include a more-detailed breakdown of the various energy production/loss mechanisms in the star. Note that this entails changes to the column numbering of the structure files; I've made the necessary edits to the IDL support files to take these changes into account.

• 2010/02/17: Ofer Springer from the Hebrew University of Jerusalem has discovered that the convective velocity (v_c) values appear to be too small by a factor 10. This is due to a simple units conversion error, which I've now fixed.

• 2010/05/11: Jing Luan from Caltech found a typo in the documentation above; the units for the stellar age should have been years instead of seconds.

• 2010/12/04: Andreas Schweitzer from Hamburg pointed out a bug in the read_ezweb_structure.pro IDL file, which led to the incorrect calculation of the mixing length and other convection-related quantities.

• 2011/04/04: I've updated the summary file format to include six extra columns, tabulating the masses and radii of the Helium, Carbon and Oxygen cores. I've also updated the read_ezweb_summary.pro IDL file accordingly.