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:
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
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 . 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
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.
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
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.
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://firstname.lastname@example.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:
Before executing any job and
Execution: Generating New Tables
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
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