Input/output
The ‘input/output’ parameter category contains parameters specifying the initial conditions as well as the wanted results to be outputted from the CONCEPT run.
initial_conditions
Description |
Specifies the initial conditions of the simulation |
||
Default |
'' # no initial conditions
|
||
Elaboration |
There are two kinds of initial condition specifications:
Several such specifications may be used together when
defining |
||
Example 0 |
Generate initial conditions consisting of a single component comprised of \(128^3\) matter particles. The particle positions and momenta will be set according to the combined baryonic and cold dark matter transfer functions: initial_conditions = {
'species': 'matter',
'N' : 128**3,
}
|
||
Example 1 |
Load initial conditions from the snapshot initial_conditions = f'{path.ic}/snapshot'
Note If the snapshot is distributed over multiple files,
use the path to either the first file, the directory
containing the files (and nothing else) or use
globbing as in |
||
Example 2 |
Generate initial conditions where baryonic and cold dark matter particles are realised separately as individual components, each comprised of \(64^3\) particles: initial_conditions = [
{
'species': 'cold dark matter',
'N' : 64**3,
},
{
'species': 'baryon',
'N' : 64**3,
},
]
When realising two particle components with the same number of particles \(N\), the two particle distributions will be pre-initialised on relatively shifted lattices, amounting to using a body-centered cubic (bcc) lattice for the combined particle system. |
||
Example 3 |
Generate initial conditions consisting of a combined matter component with \(64^3\) particles, as well as a fluid component containing the combined linear energy density perturbations of the photons, the neutrinos and the metric, having a linear grid size of \(64\) (and thus \(64^3\) fluid elements): initial_conditions = [
{
'species': 'matter',
'N' : 64**3,
},
{
'name' : 'linear component',
'species' : 'photon + neutrino + metric',
'gridsize' : 64,
'boltzmann order': -1, # completely linear
},
]
Note The |
||
Example 4 |
Use combined initial conditions from the two snapshots
initial_conditions = [
f'{path.ic}/snapshot_b',
f'{path.ic}/snapshot_cdm',
{
'species' : 'neutrino',
'gridsize' : 128,
'boltzmann order': +1, # non-linear
},
]
|
||
Example 5 |
Generate initial conditions consisting of a single component comprised of \(2\times 64^3\) matter particles: initial_conditions = {
'species': 'matter',
'N' : 2*64**3,
}
As the number of particles is of the form
\(N = 2n^3\) rather than the standard
\(N = n^3\), the particles will be pre-initialised
on lattice points of a body-centered (bcc) lattice
rather than a simple cubic (sc) lattice. Similarly,
components with \(N = 4n^3\) (e.g. |
output_dirs
Description |
Directories for storing output |
||
Default |
{
'snapshot' : path.output_dir,
'powerspec': path.output_dir,
'bispec' : path.output_dir,
'render2D' : path.output_dir,
'render3D' : path.output_dir,
'autosave' : f'{path.ic_dir}/autosave',
}
|
||
Elaboration |
This is a |
||
Example 0 |
Dump power spectra to a directory with a name that reflects the name of the parameter file: output_dirs = {
'powerspec': f'{path.output_dir}/{param}',
}
Note Unspecified entries will take on their default values |
||
Example 1 |
Use the same directory for all output, and let its name reflect the ID of the running job: output_dirs = {
'snapshot' : f'{path.output_dir}/{jobid}',
'powerspec': ...,
'bispec' : ...,
'render2D' : ...,
'render3D' : ...,
}
|
||
Example 2 |
Dump all output (even autosaves) to the directory containing the parameter file currently in use: output_dirs = {
'snapshot' : param.dir,
'powerspec': ...,
'bispec' : ...,
'render2D' : ...,
'render3D' : ...,
'autosave' : ...,
}
When all the different outputs should go to the same directory (like above), we may instead specify this as simply output_dirs = param.dir
|
output_bases
Description |
File base names for output |
||
Default |
{
'snapshot' : 'snapshot',
'powerspec': 'powerspec',
'bispec' : 'bispec',
'render2D' : 'render2D',
'render3D' : 'render3D',
}
|
||
Elaboration |
This is a The file name of e.g. a power spectrum output at scale
factor \(a = 1.0\) will be
|
||
Example 0 |
Use a shorter name for power spectrum files: output_bases = {
'powerspec': 'p',
}
Note Unspecified entries will take on their default values |
output_times
Description |
Times at which to dump output |
||
Default |
{} # no output times
|
||
Elaboration |
In its simplest form this is a Alternatively, such |
||
Example 0 |
Specify a single power spectrum output at \(a = 1\): output_times = {
'powerspec': 1,
}
|
||
Example 1 |
Specify snapshot outputs at \(a = 0.1\), \(a = 0.3\) and \(a = 1\): output_times = {
'snapshot': [0.1, 0.3, 1],
}
|
||
Example 2 |
Specify 8 power spectrum outputs between the initial \(a = a_{\text{begin}}\) and final \(a = 1\), placed logarithmically equidistant: output_times = {
'powerspec': logspace(log10(a_begin), log10(1), 8),
}
|
||
Example 3 |
Specify a series of power spectrum outputs and use these same values for 2D renders: output_times = {
'powerspec': [0.03, 0.1, 0.3, 1],
'render2D' : ...,
}
|
||
Example 4 |
Specify snapshots at cosmic times \(t = 1729\,\text{Myr}\) and \(t = 13\,\text{Gyr}\), as well as at scale factor \(a = 1\). output_times = {
't': {
'snapshot': [1729*Myr, 13*Gyr],
},
'a': {
'snapshot': 1,
},
}
|
autosave_interval
Description |
Time interval between successive automated saves of the simulation to disk |
||
Default |
ထ # never autosave
|
||
Elaboration |
Setting this to some finite time will periodically dump
a snapshot, intended for use with restarting the
simulation in case of crashes or similar. The autosaved
snapshot is written to a subdirectory
of Starting a simulation with the same parameter file will pick up on such an autosaved snapshot, if it exists. When autosaving, the previous autosave will be overwritten (in a fail-safe manner), so that only the newest autosave remains. |
||
Example 0 |
Autosave about every hour: autosave_interval = 1*hr
|
||
Example 1 |
Autosave 5 times a day: autosave_interval = day/5
|
||
Example 2 |
Disabling autosaving, including starting from an existing autosave on disk: autosave_interval = 0
Note This is different from having an infinitely long autosave interval, autosave_interval = ထ
as this still makes use of already existing autosaves on disk. |
snapshot_select
Description |
Specifies what data of which components to include when reading and writing snapshots |
||
Default |
{
'save': {
'default': {
'pos': True,
'mom': True,
'ϱ' : True,
'J' : True,
},
},
'load': {
'default': {
'pos': True,
'mom': True,
'ϱ' : True,
'J' : True,
},
},
}
|
||
Elaboration |
The sub |
||
Example 0 |
Only include the component with a name/species of
snapshot_select = {
'save': {
'matter': {
'pos': True,
'mom': True,
'ϱ' : True,
'J' : True,
},
},
'load': {
'matter': {
'pos': True,
'mom': True,
'ϱ' : True,
'J' : True,
},
},
}
When all data is to be included, the above can be simplified to snapshot_select = {
'save': {
'matter': True,
},
'load': {
'matter': True,
},
}
Equivalently, but a bit shorter: snapshot_select = {
'save': {
'matter': True,
},
'load': ...,
}
Even shorter still: snapshot_select = {
'matter': True,
}
|
||
Example 1 |
Exclude any (and only) fluid components when writing snapshots: snapshot_select = {
'save': {
'all' : True,
'fluid': False,
},
}
Components not captured by any specification defaults
to snapshot_select = {
'save': {
'fluid': False,
},
}
|
||
Example 2 |
Only read in positions when loading particles, i.e. ignore momenta: snapshot_select = {
'load': {
'particles': {
'pos': True,
'mom': False,
},
},
}
Data variables left out defaults to snapshot_select = {
'load': {
'particles': {
'pos': True,
},
},
}
Caution Leaving out certain data when reading in snapshots will result in components not being fully initialised, e.g. in this example all particles loaded from disk will not have any momenta assigned (not even \(0\)). Running a simulation with such a partially initialised component will result in a crash. The usefulness of this example is found when using e.g. the powerspec utility utility, where reading in the momentum information only wastes time and memory. |
powerspec_select
Description |
Specifies the kind of power spectrum output to include for different components |
||
Default |
{
'default': {
'data' : True,
'corrected': False
'linear' : True,
'plot' : True,
},
}
|
||
Elaboration |
This is a component selection determining which components participate in power spectrum output, as well as what kind of power spectrum output to include. Here To tune the specifics of how power spectra are computed,
see the |
||
Example 0 |
Dump power spectrum data files containing spectra for all components, including both non-linear and linear data. Do not dump any plots of this data: powerspec_select = {
'all': {
'data' : True,
'linear': True,
'plot' : False,
},
}
|
||
Example 1 |
Leave out the linear power spectrum for every component
except the one with a name/species of powerspec_select = {
'all': {
'data': True,
},
'matter': {
'data' : True,
'linear': True,
},
}
Note Unspecified values are assigned |
||
Example 2 |
Do not create any power spectrum outputs except plots
of the component with a name/species of powerspec_select = {
'all': False,
'matter': {
'plot': True,
},
}
|
||
Example 3 |
Besides the standard, “raw” simulation power spectra, further output noise-corrected versions, for all components: powerspec_select = {
'all': {
'data' : True,
'corrected': True,
'plot' : True,
},
}
Note Noise-corrected simulation power spectra are obtained
from their “raw” counterparts together with a
correction factor unique to each bin. This correction
factor is computed by performing a full 3D, linear,
Eulerian (fluid) realisation of the component in
question, and then measuring its power spectrum. The
ratio between the measured spectrum and the
linear-theory prediction (used as input for the
Eulerian realisation) gives the correction. This
corrects for noise due to the binning procedure as
well as cosmic variance from the given realisation in
use. To only correct for the former, disable
While the correction factors do depend on cosmology, they are very nearly time-independent. In practice, we always carry out the temporary Eulerian realisation used for the correction factors at \(a = 1\), meaning that the same correction factors are used for all power spectra computed throughout a given simulation. Furthermore, the correction factors are cached to disk, allowing them to be reused between simulations. |
||
Example 4 |
Create full (auto) power spectrum outputs for
all components, as well as for the combined
powerspec_select = {
'all' : True,
('matter', 'neutrino'): True,
}
|
bispec_select
Description |
Specifies the kind of bispectrum output to include for different components |
||
Default |
{
'default': {
'data' : True,
'reduced' : True,
'tree-level': True,
'plot' : True,
},
}
|
||
Elaboration |
This is a component selection determining which components participate in bispectrum output, as well as what kind of bispectrum output to include. Here Note Tree-level predictions are available for matter-like species only, and are given by
\[\begin{split}B_{\text{tree-level}}(k_1, k_2, k_3) = 2 [ \quad &\mathcal{K}(k_1, k_2, k_3)P_{\text{L}}(k_1)P_{\text{L}}(k_2) \\
+ &\mathcal{K}(k_2, k_3, k_1)P_{\text{L}}(k_2)P_{\text{L}}(k_3) \\
+ &\mathcal{K}(k_3, k_1, k_2)P_{\text{L}}(k_3)P_{\text{L}}(k_1) ]\,,\end{split}\]
\[\mathcal{K}(k_1, k_2, k_3) = 1 - \frac{1}{2}\biggl(1 + \frac{D^{(2)}}{D^2}\biggr) (1 - \mu^2) - \frac{\mu}{2}\biggl( \frac{k_1}{k_2} + \frac{k_2}{k_1} \biggr)\,,\]
\[\mu = -\hat{\boldsymbol{k}}_1\cdot\hat{\boldsymbol{k}}_2 = \frac{k_1^2 + k_2^2 - k_3^2}{2k_1k_2}\,,\]
where \(P_{\text{L}}(k)\) is the linear power spectrum while \(D\) and \(D^{(2)}\) are the first- and second-order growth factors. To tune the specifics of how bispectra are computed, see
the |
||
Example 0 |
Dump bispectrum data files containing spectra for all components, including both non-linear and tree-level data, for both the full and reduced bispectrum. Do not dump any plots of this data: bispec_select = {
'all': {
'data' : True,
'reduced' : True,
'tree-level': True,
'plot' : False,
},
}
|
||
Example 1 |
Leave out the reduced bispectrum for every component
except the one with a name/species of bispec_select = {
'all': {
'data': True,
},
'matter': {
'data' : True,
'reduced': True,
},
}
Note Unspecified values are assigned |
||
Example 2 |
Do not create any bispectrum outputs except plots
of the component with a name/species of bispec_select = {
'all' : False,
'matter': {
'reduced' : True,
'tree-level': True,
'plot' : True,
},
}
|
||
Example 3 |
Create full (auto) bispectrum outputs for all
components, as well as for the combined
bispec_select = {
'all' : True,
('matter', 'neutrino'): True,
}
|
render2D_select
Description |
Specifies the kind of 2D render output to include for different components |
||
Default |
{
'default': {
'data' : True,
'image' : True,
'terminal image': True,
},
}
|
||
Elaboration |
This is a component selection determining which components participate in 2D render outputs, as well as what kind of 2D render outputs to include. Here To tune the specifics of how 2D renders are created,
see the |
||
Example 0 |
Store 2D renders as image files for all components, and also display these in the terminal. Do not store the raw 2D render data. render2D_select = {
'all': {
'data' : False,
'image' : True,
'terminal image': True,
},
}
|
||
Example 1 |
Dump 2D render images for all components, but only show
the ones for the component with a name/species of
render2D_select = {
'all': {
'image': True,
},
'neutrino': {
'image' : True,
'terminal image': True,
},
}
Note Unspecified values are assigned |
||
Example 2 |
Create full 2D render outputs for the combined
render2D_select = {
('matter', 'neutrino'): True,
}
|
render3D_select
Description |
Specifies which components to include in 3D render outputs |
||
Default |
{
'default': True,
}
|
||
Elaboration |
This is a component selection determining which components participate in 3D render outputs. These are stored as PNG files. To tune the specifics of how 3D renders are created,
see the |
||
Example 0 |
Only do 3D renders of the component with a name/species
of render3D_select = {
'matter': True,
}
In a manner similar to the specifications within e.g.
the render3D_select = {
'matter': {'image': True},
}
|
||
Example 1 |
Create 3D render outputs for the combined
render3D_select = {
('matter', 'neutrino'): True,
}
|
snapshot_type
Description |
Specifies the snapshot format to use when dumping snapshots |
||
Default |
'concept'
|
||
Elaboration |
CONCEPT understands two snapshot
formats; |
||
Example 0 |
Dump output snapshots in GADGET format: snapshot_type = 'gadget'
Note Though which components to include in/from snapshots
are generally determined by the By default, the species of all components read from
GADGET snapshots will be To adjust the specifics of the GADGET format to
your needs, see the |
gadget_snapshot_params
Description |
Specifies various details for reading and writing of GADGET snapshots |
||
Default |
{
'snapformat': 2,
'dataformat': {
'POS': 32,
'VEL': 32,
'ID' : 'automatic',
},
'particles per file': 'automatic',
'parallel write': True,
'Nall high word': 'NallHW',
'header': {},
'settle': 0,
'units': {
'length' : 'kpc/h',
'velocity': 'km/s',
'mass' : '10¹⁰ m☉/h',
},
}
|
||
Elaboration |
This parameter is a Sub-parameters which affect the writing of GADGET snapshots:
Sub-parameters which affect the reading of GADGET snapshots:
Sub-parameters which affect both the reading and writing of GADGET snapshots:
|
||
Example 0 |
Use gadget_snapshot_params = {
'snapformat': 1,
'dataformat': {
'POS': 64,
'VEL': ...,
'ID' : ...
},
'units': {
'length': 'Mpc/h',
},
}
|
||
Example 1 |
Fill each GADGET snapshot file with at most \(420^3\) particles when writing snapshot files to disk, thus limiting the size of each file to \(\sim 2\, \text{GB}\) (assuming single-precision): gadget_snapshot_params = {
'particles per file': 420**3,
}
|
snapshot_wrap
Description |
Specifies whether or not to wrap out-of-bounds particles around the periodic box when reading snapshots |
||
Default |
False
|
||
Elaboration |
All particles should have positions
\(0 \leq x, y, z < L_{\text{box}}\), with
\(L_{\text{box}}\) corresponding to the
When reading particles from a snapshot, some particles may be erroneously located outside of the box. If a particle is positioned exactly on the upper boundary \(L_{\text{box}}\), this is silently wrapped back to \(0\). Positions beyond this as well as negative positions are counted as out-of-bounds. If this parameter is set to |
||
Example 0 |
Allow and correct for out-of-bounds particles read from snapshots: snapshot_wrap = True
|
select_particle_id
Description |
Specifies components that should keep track of particle IDs |
||
Default |
{
'default': False,
}
|
||
Elaboration |
This is a component selection specifying particle components that should make use of particle IDs, i.e. unique integer labels, one for each particle. When a component using particle IDs are saved to a snapshot, the IDs are saved as well. Note When writing GADGET snapshots, IDs will be written even for components that do not make use of paticle IDs. In this case, some IDs are simply made up when the snapshot is written. Thus, the IDs in GADGET snapshots should not be relied upon in such cases. When saving a GADGET snapshot, the data type used for
the IDs is determined by the When saving a CONCEPT snapshot, the data type used for the IDs is automatically determined to be an unsigned 8-, 16-, 32- or 64-bit integer. When a component that should use particle IDs are loaded from a CONCEPT snapshot that does not contain such IDs, new IDs are assigned. |
||
Example 0 |
Use particle IDs for all particle components: select_particle_id = {
'particles': True,
}
|
class_plot_perturbations
Description |
Specifies whether to plot CLASS perturbations used within the CONCEPT run |
||
Default |
False
|
||
Elaboration |
When enabled, all CLASS perturbations used within the CONCEPT run will be plotted and saved to image files. This is primarily intended for visual checks of convergence of CLASS computations. Two new directories will be created — both within the
specified power spectrum
output directory
Note This feature is primarily meant to be used with the class utility. |
||
Example 0 |
Plot all CLASS perturbations used within the CONCEPT run: class_plot_perturbations = True
|
class_extra_background
Description |
Specifies additional CLASS background quantities to include as part of the CLASS data |
||
Default |
set()
|
||
Elaboration |
Only a subset of the available CLASS background quantities are used by CONCEPT, and so only these are retrieved from CLASS computations. This also means that only these specific background quantities end up in the CLASS data stored on disk, be it the automatic CLASS disk cache or the data files generated by the class utility. To include extra CLASS background quantities — not
used by CONCEPT — within these files, specify
them within the
|
||
Example 0 |
Include the conformal time \(\tau\) among the CLASS background quantities when dumping these to disk, e.g. when running the CONCEPT class utility: class_extra_background = 'τ'
We can also refer to \(\tau\) using its CLASS name: class_extra_background = 'conf. time [Mpc]'
|
||
Example 1 |
Include the luminosity distance and the angular diameter distance among the background quantities when dumping these to disk, e.g. when running the CONCEPT class utility: class_extra_background = {'lum. dist.', 'ang.diam.dist.'}
|
class_extra_perturbations
Description |
Specifies additional CLASS perturbations to include as part of the CLASS data |
||
Default |
set()
|
||
Elaboration |
Only a subset of the available CLASS perturbations are used by CONCEPT, and so only these are retrieved from CLASS computations. This also means that only these specific perturbations end up in the CLASS data stored on disk, be it the automatic CLASS disk cache or the data files generated by the class utility. To include extra CLASS perturbations — not used by
CONCEPT — within these files, specify them
within the
|
||
Example 0 |
Include the two conformal Newtonian metric potentials \(\phi\) and \(\psi\) among the CLASS perturbations when dumping these to disk, e.g. when running the CONCEPT class utility: class_extra_perturbations = {'ϕ', 'ψ'}
We can also refer to these using their CLASS names: class_extra_background = {'phi', 'psi'}
|