OP_Mono Wiki

Welcome to the OP_Mono wiki page. Below, we walk you throgh the download, installation, setup and execution steps to reproduce the revised instability strips published in Moravveji (2015, MNRAS Letter, in press). In addition, the three sets of opacity tables used in that publication are also shared as compressed files. Before that, we start explaining what the op_mono package produces.

The Format of the Opacity Tables

The accepted format for opacity tables in most (if not all) stellar structure and evolution codes is the OPAL Type I format. In this format, each set of opacity tables consists of 126 files with different hydrogen X and metal Z mass fractions. Indeed, one must make a decision on which mixture to choose before rescaling the composition. We currently support two of the mixtures that are available in the MESA code:

• Asplund et al. (2009): initial_zfracs=6
• Nieva & Przybilla (2012): initial_zfracs=8

Extention to support other mixtures is quite easy, and will be handled upon request.

Each opacity table covers the logarithmic range in temperature log T from 3.75 to 8.0 in three varying step sizes. The second dimension is R, which is defined as log R=log rho-3log T+18. In fact, log R varies in the range -8.0 to +1.0. The evolution for a typical B-type star is roughly at constant log R ~ -3 +/- 1.

Two Shortcommings of OP Monochromatic Data and Routines

It is already known that the OP Monochromatic data and tables that are retrieved from the online Opacity Project (OP) only cover up to 100 million Kelvin, which is not sufficient for the core Helium burning phase, but quite useful for the core hydrogen burning and shell hydrogen burning phases. Therefore, one can safely use them until before the core He ignition, e.g. until the tip of red giant (TRGB) phase. In addition to this limitation, the monochromatic OP data, and routines, do not allow computing the opacity for all combinations of temperature log T and density log R. Unfortunately, the OP Mono routines return an error message "rho out of range for this T" and/or "T out of range" for the high temperature range and at the two high-density and low-density corners of the table. As a result, the bottom-left and bottom-right corners of the tables cannot be filled up by a call to OPCD routines only. Please note that these two ranges are outside the typical range of temperature and density of ordinary stars. However, for the sake of completeness, we seek a resolution.

The left figure above is a visualization of the log kappa (where kappa is opacity in cm^2/g) as a function of temperature and density. The contours highlight the iso-opacity regions. This table is chosen for a ZAMS model with near solar metallicity X=0.71, Z=0.020. The two white corners are those zones that are out of the reach of OPCD. Here, we have to pick our poison: (a) to either leave the tables as they are, and fill up the two white corners with NaN (or some other extreme values), or (b) to make an alterntive call to existing opacity tables for the same mixture and fetch the log kappa values for the given log T and log R combination from there. We chose to pick the second. Clearly in the right panel, the two gaps are now filled up, and the contour levels conistently stretch to the very corners of the tables. However, this is not a perfect solution, and a faint patch is still visible at the former position of gaps, because of a small contrast between the OP Mono versus the MESA's pre-built opacities. We welcome any alternative approach to improve this.

Pre-built Opacity Tables

The results presented in Moravveji (2015) made use of element-by-element enhancement factors, for which only Iron and Nickel were chosen to be enhanced by a factor 75%. The three opacity tables that were computed and used in that publication were based on the Asplund et al. (2009) solar mixture. If one is interested to reuse those three specific tables, there is no need to install and recompute the tables. They are publically available for download here.

• Fex1.00 Nix1.00: in MESA, set kappa_file_prefix = 'Mono_a09_Fe1.00_Ni1.00'
• Fex1.75 Nix1.00: in MESA, set kappa_file_prefix = 'Mono_a09_Fe1.75_Ni1.00'
• Fex1.75 Nix1.75: in MESA, set kappa_file_prefix = 'Mono_a09_Fe1.75_Ni1.75'

Each set consists of 126 ASCII tables in the OPAL Type I format. To use them explicitly in MESA, extract them in "/mesa/data/kap_data" directory, and give kappa_file_prefix a correct prefix/name in the MESA &star_job inlist.

Although the op_mono package tabulates and stores the full set of (126 ASCII files) opacity tables in the OPAL Type I format for you, however, the three opacity tables that were used in Moravveji (2015) are statically put here for direct download. They are computed based on the Asplund et al. (2009) mixture [3]. The beta_Fe and beta_ Ni are introduced in Moravveji (2015, Eq. 2).

Instability Strips of O- and B-type Stars

Using the three above opacity tables, revised instability strips (IS) of massive stars were presented in Moravveji (2015). The full data to reproduce Figs. 2 and 3 in that paper are tabulated and avalable for download. Each file has a header giving the meaning of each column. Each row corresponds to one input model.

• IS table for Fex1.00 Nix1.00
• IS table for Fex1.75 Nix1.00
• IS table for Fex1.75 Nix1.75

The above tables are plain ASCII files. We provide a basic Python tool to interact with each file, read each ASCII file, and return a numpy record array for any further manipulation.

• Python Read Module

#!python
import read_tables

table_file   = './data/results/modes_Fex1.00_Nix1.00.tbl'
table_recarr = read_tables.read_mode_table(table_file)
print len(table_recarr)
print table_recarr.dtype.names

The three figures above show the instability domains of the OB-type dwarf stars (Moravveji, 2015). These plots project the IS data from the above mode tables. The left, middle and right figures correspond to opacity enhancement factors (Fe, Ni) = (1.0, 1.0), (1.75, 1.0), and (1.75, 1.75), respectively. The last one was not presented in that work, and it has a minute difference with the middle figure.

Pre-requisites

To use OP_Mono package, you need to make sure MESA and MESASDK are already installed on your machine. Additionally, you need a local copy of the OPCD data that you can freely download as a compressed tarbal OP4STARS_1.3.tar.gz.

Create the Work Environment

The work environment is essentially a folder with a makefile and few scripts that compile together with "op_mono". Your actual work directory should be totally different from the op_mono source directory; thus, we encourage you to keep everything in the op_mono directory untouched. First, copy the gen_op_mono_tables.tar.gz which is now available in the $USER/DIR/op_mono to somewhere on your disc. Let's call the new place $WORK_DIR:

cd </another/path/for/work>
export WORK_DIR=`pwd`
cp $USER_DIR/op_mono/gen_op_mono_tables.tar.gz $WORK_DIR
cd $WORK_DIR
tar -zxvf gen_op_mono_tables.tar.gz
cd gen_op_mono_tables

Clone the Repository

To fetch the repository, first make sure that you have the "git" installed on your machine. Then, change to a working directory where you want to clone the repository. Here, a new folder with the name "op_mono" will be created. From now on, we call the path inside the "op_mono" directory $USER_DIR

cd </path/to/my/dir>
git clone https://ehsan_moravveji@bitbucket.org/ehsan_moravveji/op_mono.git
export USER_DIR=`pwd`
cd op_mono
ls

You are now ready to comile the code in a simple step:

./mk

Input Namelist

Before executing any job and

Execution: Generating New Tables

#!bash
./run

OpenMP Performance

The "op_mono" package supports OpenMP for parallelisation, and shorter runtime. One can set the number of desired threads to any number of available threads on the machine, to exploit this capability.

#!bash
export OMP_NUM_THREADS=4

However, the performance is not ideal. The bottom figure shows how the runtime for computing one table file drops by linearly increasing the number of threads. This test was performed on a 2.8 GHz Ivy Bridge compute node.§

The op_mono supports OpenMP directives, however, the performance is not linear with the number of cores, and it saturates immediately to a flat curve. The reason is, the OPCD data are around 700 MB, and at the start of the execution, the binary data files are read and stored in the memory. During the runtime, every thread needs full access to this data. Outside the dynamical part of the parallel construct, the nested calls to the OPCD routines cannot copy this data to the L2 cache for quick access. Therefore, the data needs to be fetched from the RAM, and the data communication overhead dominates or becomes comparable to the computation of a single log kappa value. Therefore, the parallel loop immediately looses efficiency. I have doubts if there would be a way around this. So, the code can be perfectly used by e.g. 4 cores on a laptop machine with a reasonable runtime.