CRT is a Monte Carlo program for the calculation of radiation scattered and/or emitted by interstellar dust grains. Several dust models are included in the program or (in the case of grains at an equilibrium temperature) can be defined using external files. The program can handle cloud models with spherical symmetry and cylinder symmetry, or one can define a general three-dimensional cloud using a 3D Cartesian grid.
References:
The initialisation file (‘ini-file’) contains various parameters that can be used to scale the cloud model (e.g., size and density), specifies the dust species included, sets various options that affect the way calculations are carried out, and specifies output files that are to be written. The name of the ini-file must be given on command line, e.g.,
CRT my.ini
The file consists of lines which start with a keyword followed by one or more arguments. Comment lines starting with # are ignored.
A B C D E F G H I J K L M N O P Q R S T U V W X Y
abundance filename
Specified a file that contains, cell by cell, relative abundances
for the dust component that was last specified with the keyword dust.
For a 1D cloud this is an ascii file with two columns: the index of
the cell (running index starting with 1) and the relative abundance.
In the case of a 3D cloud the file is a binary file containing one 4
byte floating point number for each cell. The file does not start with
the dimensions of the cube but only contains as many floats as there
are cells. If all relative abundances are set to 1.0, the result will
be the same as when the abundance keyword is not used.
ascii
With this option program will save results – spectra and (for
grains at an equilibrium temperature) dust temperatures to text files.
See description of temperature files and spectrum files.
bgpackets
Number of photon packages sent from background per iteration and
frequency.
binary
Select binary format for output files. See description of
temperature files and spectrum files.
cellpackets
Number of photon packages sent from the dust medium per iteration
and frequency.
centreweight float (1D clouds only)
Weighted distribution of initial positions of photon packages
created inside the cloud volume
clip float
Ignore cells with density below the given limit (in
raytracing and when temperatures are updated).
cloud1d/cloud2d/cloud3d filename
Specifies the name of the file containing description of the cloud
model
constantabundance
Tells the program to assume that all dust abundances are constant
throughout the cloud (=1!), so that one does not have to allocate
large arrays for optical depths and the asymmetry parameter. Currently
works only with onlyscattering.
coredirection gamma
Weighting of angular distribution of photon packages send inside
the cloud
density f1 f2
A linear scaling is applied to densities initially read from the
cloud definition so that values will fit in the interval [f1,f2]. If
second number is negative densities are multiplied directly with
factor f1.
diffuse [f1]
Diffuse emission is read from the file diffuse.data. The file
should contain the diffuse emission in each cell and at each frequence
in units of photons emitted from 1 cm^3 in one second in 1Hz band.
Unlike in emitted.data and absorbed.data, the frequency axis runs
slowest [(x=0,y=0,z=0,f=0), (1,0,0,0) … (NX-1,0,0,0), (0,1,0,0) …
(NX-1,NY-1,NZ-1,0), (0,0,0,1) … (NX-1,NY-1,NZ-1,NFREQ-1)]. The
emission read from the file is scaled by factor f1 (default=1.0).
direction theta phi
Specify the direction towards the observer for spectrum
calculations. theta is an angle from positive z-axis towards positive
x-axis and phi rotation around z. Angles are given in degrees.
dsc [filename]
Use a tabular scattering function instead of relying on the
Henyey-Greenstein approksimation. Requires file DSC.dat in the data
directory that is specified at compile time or overwritten by the
option rootdir. The name of the file can also be given after the dsc
keyword. The file must still reside in the same ‘root directory’ (that
may be different from the current working directory!).
dust filename
Gives the name of a file defining a dust species (see CRT
definition of dust model). At the moment an ini-file can contain
keyword dust a maximum of 10 times, i.e., define 10 different dust
species to be included in the model.
DustFromDustem
Use DustEM for dust emission calculations. Requires
GRAIN_.DAT and GRAIN.DAT files in the DustEM les_DAT directory.
dumpincomingphotons
With this option a file incoming.dump is created, containing the
estimated intensity for each cell in cgs-units. The intensity is
calculated based on the total number of photons that do enter the
cell, i.e., it is the average incoming intensity on the border on each
cell (not intensity at the centre of the cell – this may be slightly
different, if the cell is optically thick). If cell contains a
discrete source, those photons are also calculated so that actually
incoming.dump reflects the total influx of energy into the cell. See
also Other CRT files.
frequencyfile string
Name of a file containing list of frequencies used in the
simulation. This is an ascii file containing a list of frequencies,
one per line. The first line already contains the first frequency and
not the number of frequencies.
forcedfirstscattering
Use forced first scattering method to improve sampling of
scattered flux in optically thin models. Works at least when keyword
onlyscattering is used.
gridlength f1
Defines the physical size [pc] of the cloud: for 1D model this is
the radius of the cloud and for 3D models the size of an individual
cell.infinite
Currently applicable only to 2D models, makes the cylinder
infinite in length. This applies to the actual calculations but images
(emission, scattered light) are still affected by the finite length of
the model (= at non-zero inclination angles the intensity will not be
correct for the lines-of-sight that cross either cap of the finite
cylinder that one would have without this keyword).
inside x y z radius type arg scaling
Define an internal radiation source. The position (x,y,z)is given
in grid coordinates where for 1D and 2D clouds the radius 1.0 units
and for 3D models the cell size is 1.0 units. The coordinates
(0.0,0.0,0.0) correspond to the centre of a 1D cloud, symmetry axis at
the bottom of a 2D cylindrical cloud (at cloud surface), and a corner
of a 3D cloud (the corner cell corresponds to coordinates 0.0-1.0
along each axis). The the source radius is given in cm.
The last parameter scaling is used to scale the intensity. Default
value is scaling=1.0. The type can
be one of the following:
inside x y z theta phi xi radius type arg scaling
As previous but with an anisotropic source. Radiation leaves from
the source towards direction (theta,phi) within a cone with opening
angle xi (=angle from the symmetry axis to the border of the cone).
iterations #
Sets number of iterations made during one run
libfreq n1 f1 n2 f2 ...
Specify reference frequencies (f1, f2,…) for the library
method. The parameters n1, n2, … are the number of intensity bins
used at the corresponding reference frequency.
libload prefix
Load existing library files with the given prefix and use them in
the spectrum calculations.
nosolve
Dust temperatures and dust emission is not calculated. However, if
file emitted.data exists, it will be read and used in the simulations
(provided that argument of cellpackets is positive). The option can be
used if one has calculated the emission from each cell by other means,
and only wants to do the radiative transfer part in order to either
estimate the intensity in different parts of the model cloud (e.g.,
together with the keyword dumpincoming) or to calculate the spectra
observed from such a model.onlyscattering
Do not solve dust temperatures. Faster in case only scattered
intensity needs to be calculated.
opacity filename
Write out a binary file of cell opacities (absorption +
scattering). The binary file starts with two integers (4 bytes), the
number of cells and the number of frequencies (= number of frequencies
in the simulation). These are followed by floating point numbers (4
bytes) that give cell opacity per ‘grid unit’ (cloud radius in 1d
models, cell size in 3d models). Opacities are listed for all cells
and all transitions, the values of one cell being consecutive. The
order of the cells is the same as in the cloud definition. This option
can be used to produce a file that, through Python script
CRT2Cppsimu.py, can be used as input for Cppsimu runs (see Cppsimu
option Cppsimu Ini-file#C).
opencl wgs #
GPU/OpenCL accelerated calculations of scattered light. The first
argument is the batch size (how many rays are used in a single GPU
kernel call). The program will use either CPU (second argument equal
to 0) or the first GPU (second argument equal to 1). The keyword is
only available in development version (and the syntax may change).
outcoming ...
Specify how outcoming scattered flux is stored. Examples are:
outcoming 10 0.2 5.0 * * *: Store 10×10 element array of
intensities, each pixel corresponding to 0.2 times the ‘grid unit’.
The intensities are calculated counting photon coming out from the
cloud surface within a 5 degree cone toward the observer. The plane is
perpendicular to the direction toward the observer (see direction).
The ‘grid unit’ is either the cloud radius (in case of a 1D or 2D
cloud) or the cell size (3D cloud). For example, if the the product of
the first two parameters equals 2.0 (as in the example), the resulting
map will exactly cover the area of a 1D cloud (diameter = 2 x radius =
2.0 grid units). If calculations are done with the ‘peel-off’ option,
the opening angle of the cone must still be given, but will not be used.outcoming 20 -1 0.3 * * * Store outcoming intensity as the
function theta from the direction of the observer, there are 20 bins
for cos(theta). Outcoming photons are registered only if projected
distance from cloud centre is below 0.3 in grid units (i.e., for a 1D
model distance less than 0.3 times the cloud radius). The second
parameter not used but must be negative (separates this from the
previous case).outside ...
Specifies the external radiation source. Examples are
outside blackbody 5000.0 1e-5 5000K blackbody background diluted by a factor
of 1e-5outside isrf2 0.5 * * * normal interstellar radiation field
scaled by 0.5 (isrf = Mathis et al. 1983, A&A 128, 212,
isrf2 = Mezger, Mathis, Panagia 1982, A&A 105, 372, isrf3 = Draine & Anderson 1985, ApJ 292, 494outside table BISRF.dat 1.0 read intensities from external table
(number of frequencies followed by one frequency and intensity per
line{{ units Hz and erg/cm2/sr/s/Hz)}}outside 180.0 0.0 10.0 isrf2 2.0 source in direction theta=180 and phi=0.0 degrees,
opening angle 10 degrees (=diameter on the sky 20 degrees and source
is at an infinite distance), interstellar radiation field with twice
the normal intensityoutside 0.01 0.01 179.99 healpix wham_velocity.fits 1.0
outside 0.01 0.01 179.99 healpix test.fits 1.0 0.5 2.0 1.0e-3 90.0 0.0bgpackets and for non-isotropic sources with
sourcepackets.peeloff
At each position of scattering calculate separately the intensity
that is scattered towards observer and does exit the cloud without
being extincted. Reduces significantly the noise of computed maps of
scattered radiation. May require use of the keyword onlyscattering .
perspective x y z
Write spectra for an observer inside the model volume. The three
parameters are the location of the observer in grid units. By default
this results in a 2D map in cylinder projection where the number of
longitude and latitude points is defined by the keyword points. The
map covers full 360 degrees in longitude. The latitude range is
defined by an requirement that the pixels are square at latitude zero.
Thus, the second argument of points should be less or equal to half of
the second parameter.
photonlimit float
Simulation of a photon package is stopped once it’s size has
decreased by the given fraction. Works at least together with the
keyword onlyscattering. The default value is 1e-14.
points nx ny
Specify the number of output spectra produced. There will be
nx \times ny spectra computed at intervals defined with
the keyword step.
prefix string
Prefix for output file names.
random mzran seed
Selection of a random number generator and initialization with
selected seed number (float). The recognised generators are called
rand (system generator drand48), mzran with synonym pseudo, HD
(Hoerman & Deflinger; with integer seed), TLE (Tezuka & L’Ecuyer), MTW
(Marsenne twister), and quasi (quasi random number generator, not
recommended!)
reset
Reset random number generators after each iteration. May be needed
if one wants to use ngaccel.
rootdir directory
Specify a directory for auxiliary files (apart from the default
one). This directory contains, e.g., the dust properties for
calculations with the Li & Draine dust model.
savetemp suffix
Save computed dust temperatures to file with the name consisting
of the name of the dust and of the given suffix. This applies only to
calculations with models with equilibrium temperature dust. For 1d
models, when the keyword ascii is used, the result is a simple ascii
file (the second column are the temperatures). Otherwise the result is
a binary file with one 4 byte float per cell.
scattercore gamma
Weighting of the angular distribution of scattered photon packages
(gamma<-9.9: no weighting, gamma>-9.9: use modified probability distribution
p(theta)~exp(-gamma*theta) for directions of scattered photons; theta is angle from the
direction of the cloud centre).
sourcepackets
Number of photon packages sent from discrete sources per
iteration and frequency.
spectrum string
Specifies what components are included in the computed spectra.
The string may contain ‘E’, ‘S’, and/or ‘B’ for dust Emission,
Scattered light and emission from the Background sky.
spelib prefix
Calculation is used to produce library files for the included dust
species with the given prefix. In the following runs the computed
libraries can be loaded by using the keyword loadlib instead of spelib.
step float
Gives the step (in parsecs) between the positions for which output
spectrum is calculated.
superpeeloff
Perform peeloff at each cell boundary (not recommended: usually
detrimental to accuracy / runtime).
targetcore beta
Weighting of spatial distribution of background packages entering
the cloud.
taus filename wavelength
Save optical depths at given wavelength um to the named
file for each sightline for which a spectrum was computed.
tdistributions prefix
Dump temperature distributions for transiently heated grains. The
resulting binary files will be named prefix.name_of_dust.Tdust. The
format of the file is the following: three integers (4 byte each)
giving the number of cells, grain sizes, and enthalpy bins, followed
by the grain temperatures (one four byte float per each size and
energy), followed by the relative number of grains in each enthalpy
bin (one eight byte double for each cell, grain size, and enthalpy).
wavelength a b
Restrict calculation of the output spectra to wavelength range
[a,b] given in units of um.The program CRT uses different types of dust models. The simplest dust models are used for calculations of scattered light and they do not include calculation of dust temperatures or dust emission. These dust models can be specified entirely using a text file, e.g.:
simple # required !
1.0e-8 # number density relative to hydrogen
1.0e-8 # grain radius [cm]
7 # number of frequencies
# [ freq g=<cos theta> Qabs Qscat ]
1e10 0.6 2.0 0.0
1e11 0.6 2.0 0.0
1e12 0.6 2.0 0.0
1e13 0.6 2.0 0.0
1e14 0.5 2.0 0.0
1e15 0.6 2.0 0.0
1e16 0.6 2.0 0.0
The name of the above file is then set in the ini-file using the keyword dust. The file starts with the keyword simple and is followed by the grain abundance and grain radius (used for computation of absorption and scattering cross sections). These are followed by the number of frequencies for which the dust parameters are defined. Each of the following lines list a frequency, and for that frequency the value of the asymmetry parameter g and the absorption and scattering efficiencies, Q(abs) and Q(scat).
For this dust in each cell an equilibrium temperature is calculated and, consequently, dust emission spectrum can be calculated. The dust definition is contained entirely in an external text file. Here is an example:
eqdust # required
1.0e-11 # abundance
0.12e-4 # grain radius [cm]
# frequencies
243
1.4979e+11 0.000 1.1380e-05 2.0100e-13
2.0079e+11 0.000 1.3380e-05 3.0100e-13
2.9979e+11 0.000 1.5380e-05 4.0100e-13
3.1754e+11 0.000 1.7260e-05 5.0480e-13
3.3635e+11 0.000 1.9360e-05 6.3550e-13
3.5630e+11 0.000 2.1730e-05 8.0000e-13
The format is the same as for the ‘simple’. In the ini-file the keyword frequencyfile points to a file that lists the actual frequencies used in the calculations and dust parameters are interpolated to those frequencies. Obviously, the definition of dust parameters should cover the whole computed frequency range.
So far we have not have any need for such dust models. In an ini-file one can include at least ten different dust species so that a crude size distribution can be implemented using several ‘eqdust’ dust species.
Note: the documentation below is partly outdated. One can use with CRT the same files as used by the SOC programme. Please refer to the documentation given for SOC .
For transiently heated particles some grain properties are currently hardwired in the code. Therefore, it is only possible to use some pre-defined dust models. One of these is the Li & Draine model (2001). The dust file is specified in the normal manner using the dust keyword. Here is an example
set_ld_graphite
prefix june_ldg
dt 1.0e-6
density 1.0e-11
nsize -10 50.0e-8 2400.0e-8
bins 250 70.0 450.0
The keywords in this file are:
Dust is now discretized into separate size intervals and for each size interval and cell we have a separate distribution of dust temperatures. The computations are much more time-consuming than when one could assume a single equilibrium temperature. Note that absorption and scattering cross sections are read directly from files downloaded from B. Draine’s homepage. These must be available when program is run, and are usually located in a directory specified at compile time. However, the name of the directory can also be set in the ini-file using the keyword rootdir.
The original (hard coded) model for transiently heated particles can be adjusted in several ways.
adjust has two parameters, first scales the number grain
density calculated from the original model, the second argument tilts
the size spectrum (on logarithmic scale): adjust 0.7 0.2. The
previous decreases the total dust mass (for the present component) by
30% and makes the slope (dN vs grain size) more shallow, i.e.,
increases the relative amount of large grains.
auxfile instructs the program to read a file [um Qabs], that
will be used to replace the original absorption curve (between some
frequencies). One could add a line auxfile file.dat and also a
line tag A. Here tag specifies the interval replaced (Qabs
replaced directly, Qsca multiplied with Qsca_new/Qsca_old). For
example, tag A stands for interval 7.6-25µm.
growth tells the program to read a separate file containing
columns [ grain_size [nm], factor ] that is used to modify the
original grain size distribution. The second parameter defines the
change in total dust mass. growth curve.txt 2.0
would mean that the original grain numbers (per size
interval) are multiplied with the factors found in the file curve.txt.
The final grain numbers are normalized so that the total dust mass is
twice the original one.
emissivity_step has three parameters. For example,
emissivity_step 10.0 100.0 2.0 means: increase emissivity for all grains larger
than 10nm, for all wavelengths above 100um, by a constant factor 2.0.
emissivity_slope has three parameters, e.g.
emissivity_slope 10.0 100.0 2.0 means: increase emissivity for
all grains larger than 10nm, for all wavelengths above 100um, by a
factor (lambda/lambda~0)2.0.
emissivity_bump a dlog(a) k(size) scale lambda dlg(lambda) k(emissivity)
introduces into the size distribution a bump, the
centre is at given grain size a [nm], the width of the bump is
specified on logarithmic scale by dlog(a){{, {{k is the peak
multiplicative increase in the grain numbers, scale is the scaling of
the total dust mass, lambda is the bump centre in wavelength [um], and
dlg(lambda) the width on logarithmic scale. The last parameter is the
peak multiplication at wavelength lambda. For example,
the line emissivity_bump 100.0 2.0 1.4 1.0 300.0 2.1 4.0
would increase number of grains around 100nm by a
maximum factor of two. The bump is gaussian on logarithmic scale, the
standard deviation of log(a) being 1.4. The total dust mass is kept
constant. Emissivity is increased by a maximum factor of four around
300um. The width of the bump corresponds to log(lambda) standard deviation of 2.1.
multiplysize moves the whole size distribution without
affecting the (dN,a) slope. For example, multiplysize 2.0 would
increase the size of all particles by a factor of two.
Model is defined using a separate file that is named using the cloud1d keyword of the ini-file. A spherically symmetric cloud consists of co-centric shell and we need to specify only the radie and densities of the shells. Unlike in the line transfer program Cppsimu the values can not be given via analytical formulae. Values must be listed shell by shell as in the following example:
# number of shells
10
# [ outer radius, density ] n ~ 1/r
0.25 0.8
0.40 0.7
0.52 0.6
0.65 0.5
0.78 0.4
0.85 0.3
0.90 0.2
0.94 0.15
0.97 0.1
0.99 0.05
1.00 0.05
The radiae (first column) are relative values and the last value
should be 1.0. Densities can be re-scaled using in the ini-file the
keyword density. In CRT the centre coordinates of a spherical cloud
are (0.0, 0.0, 0.0) and the positions of for example internal sources
are defined in coordinates where the cloud radius is 1.0 units.
These can be specified still using ascii files. The first two lines contain the number of radiae and number of planes. These are followed, one value per line, by the outer radiae of the cylindrical cells (the last one should be 1.0) and the coordinates of the upper boundaries of layers that are used to divide the cylinder into cells perpendicular to its symmetry axis. The cylinder starts implicitly at 0.0 and only the coordinates for the upper borders of the layers are specified, the last number thus giving the height of the cylinder (relative to the radius that is assumed to be 1.0 units). These are followed by the density values, one number per line, starting at the bottom of the cylinder so that the radial cell index runs faster that the index of the planes.
In CRT the coordinates (0.0, 0.0, 0.0) correspond to the bottom of the cylinder (on the surface of the model), at the symmetry axis, the radius of the model is 1.0 units, and the height as specified above. The centre of the model is thus (0.0, 0.0, height/2.0). These coordinates are used when placing for example internal sources. The physical size is given with the keyword gridlength (see the documentation for the ini file).
A 3D cloud is defined using a simple binary file. File starts with three integers (3 x 4 bytes) giving the cloud dimensions as cells (NX,NY,NZ). The following values (4 byte floats) give the density for each of the cells. The x-coordinate runs fastest, i.e., the consecutive numbers correspond to cells with indices (0,0,0), (1,0,0), (2,0,0), …, (NX-1,0,0), (0,1,0), (1,1,0), …, (NX-1, NY-1, NZ-1).
In CRT the the size of a cell is 1.0 units along all three axes. The
first corner is at (0.0, 0.0, 0.0) and the cell at the corner extends
over coordinate values 0.0-1.0. For example, If a source is placed at
the centre of the model volume, its coordinates (see keyword inside)
are (0.5NX, 0.5NY, 0.5*NZ).
Dust temperatures are saved only for grains at an equilibrium
temperature (not transiently heated), when the keyword savetemp is
used. The file name consists of the name of the dust component and a
suffix given as the parameter of the savetemp keyword. In case of 1D
models, when also the keyword ascii is used, the result is a text file
with rows containing cell index, dust temperature [K]. For 3D models
the temperatures are always written to binary files. The file simply
contains a temperature value (4 byte float) for each cell.
When the keyword binary is used in the ini-file, the spectra will be
written to a binary file prefix.spectra. File starts with three
integers (4 bytes each): number of RA-positions, number of
DEC-positions, and number of frequencies. These are followed by the
listed frequency values (4 byte floats,). For each spectrum the file
contains first the x- and y-offsets [pc] (4 byte floats) that are
followed by the intensity values [Jy/sr] for each of the computed
frequencies (4 byte floats).
If keyword ascii is used instead of binary, the spectra
are written to an ascii file. The output file consists of lines with
x-offset [pc], y-offset [pc], frequency [Hz], wavelength [um],
intensity [cgs], intensity [Jy/sr], optical depth. Note that all
values (different positions and frequencies) will be written to this
one file. Above the offset x increases right (i.e., opposite to the
direction in which longitude coordinate would increase).
Scattered flux can be included in calculated spectra. However, it is
usually better to calculate that separately either as a function of
the angle from the direction of the observer or as a 2-dimensional map
towards selected direction. The keyword outcoming must always be used
when scattered intensity is computed. The scattered intensity is
automatically saved to a text file outcoming.dat. If scattered
intensity is computed for a 2D grid (see also keyword direction) the
file contains lines x-offset, y-offset, I(freq1), I(freq2) …. If
intensity is calculated only as a function of angle theta from the
direction of the observer the lines will be cos(theta), I.
Depending on the run, the program CRT may write several files, some of which may be usefull for furher analysis or for checking that what was calculated was what one wanted to calculate.
absorbed.data
Binary file containing the number of photons absorbed in
each cell (Nbg_intensity.dump
The text file contains two columns, the frequency and the
total intensity of the isotropic background used in the simulations
(cgs units)emitted.data
Similar binary file as absorbed.data, but containing the
number of photons emitted from each cell during one iteration. Values
are: the number of photons emitted from 1cm^3 volume, in one second,
in 1Hz band, and scaled with a factor 10^20 .incoming.dump
Binary file containing incoming intensity for each cell
(Ndumpincomingphotons is used.