Physics

The ‘physics’ parameter category contains parameters specifying various physical models and schemes to be used.

select_forces

Description

Specifies which forces to enable

Default

 

{}  # no forces enabled

Elaboration

This is a component selection dict, mapping components to sub-dicts of the form

{force: method}

specifying which forces/interactions affect the given component, as well as what method/implementation to use for the given forces. Currently, the only forces in CONCEPT are 'gravity' and 'lapse', with the latter having to do with gravitational time dilation. The implemented methods for the forces are:

  • 'gravity':

    • 'pp' (PP, particle-particle)

    • 'pm' (PM, particle-mesh)

    • 'p3m' (P³M, particle-particle-mesh)

  • 'lapse':

    • 'pm' (PM, particle-mesh)

For details on these methods, consult the paper on ‘The cosmological simulation code CO𝘕CEPT 1.0’. As select_forces is empty by default, no forces (not even gravity) are enabled. If however a global potential grid size is specified within the potential_options parameter, this places the following default entries within select_forces:

{
    'particles': {
        'gravity': 'p3m',
    },
    'fluid': {
        'gravity': 'pm',
    },
}

so that particle components will participate in the gravitational interaction using P³M, while fluid components will participate in the gravitational interaction using PM.

Note

All interactions for fluid components may only ever use the PM method

Note

With the gravitational force specified for particle and fluid components as above, gravity will really be applied to such components in the following manner:

  • Gravity applied to particle components:

    • From particle components:

      • P³M (long-range)

      • P³M (short-range)

    • From fluid components:

      • PM

  • Gravity applied to fluid components:

    • From particle and fluid components:

      • PM

Besides P³M being split up into a long-range and a short-range part, we see that the interactions between particle and fluid components make use of PM, even though PM is only selected for the fluid components.

For more information on these mesh-based methods, see the potential_options parameter. For a more casual walk-through of how to specify forces and methods within CONCEPT, see the tutorial.

Example 0

Explicitly specify the component with a name/species of 'matter to be under the influence of gravity, using the P³M method:

select_forces = {
    'matter': {
        'gravity': 'p3m',
    },
}

As P³M is the default gravitational method, we can shorten this to

select_forces = {
    'matter': 'gravity',
}

As mentioned above, this can be shortened further by simply removing any mention of select_forces from the parameter file, provided that a global grid size is set within the potential_options parameter.

Example 1

Explicitly specify the component with a name/species of 'matter to be under the influence of gravity, using the PM method:

select_forces = {
    'matter': {
        'gravity': 'pm',
    },
}

select_species

Description

Specifies the species of components read in from snapshots

Default

 

{
    'default': 'matter',
}

Elaboration

This is a component selection dict for mapping components to species. While the 'species' of a component is explicitly specified in the initial_conditions parameter, no species are necessarily defined for components read in from snapshots. For components within snapshots of the 'concept' type, their species are explicitly included within the snapshots. For components read from 'gadget' type snapshots, their GADGET particle type (see table 3 of the user guide for GADGET-2) is known, but this needs to be mapped to a species in CONCEPT. This is what this parameter is for.

Note

Though a species is explicitly defined for each component within a 'concept' snapshot, the species to use within a simulation may be overruled by setting this parameter

Example 0

Explicitly map the GADGET particle type 1 (halo) to correspond to the 'matter' species within CONCEPT:

select_species = {
    'GADGET halo': 'matter',
}

Note

The name 'GADGET halo' will automatically be assigned to the component containing the particles of type 1. See table 3 of the user guide for GADGET-2 for other names.

Example 1

Map the GADGET particle type 2 (disk) to the 'neutrino' species within CONCEPT, while mapping everything else to 'matter':

select_species = {
    'GADGET disk': 'neutrino',
    'all'        : 'matter',
}

realization_options

Description

Specifies how to realise different components

Default

 

{
    'gauge': {
        'default': 'N-body',
    },
    'back-scale': {
       'default': False,
    },
    'LPT': {
        'default': 1,
    },
    'dealias': {
        'default': False,
    },
    'non-Gaussianity': {
        'default': 0.0,
    },
    'structure': {
        'default': 'non-linear',
    },
    'compound': {
        'default': 'linear',
    },
}

Elaboration

This is a dict of several individual sub-parameters, specifying how individual components are to be realised. All sub-parameters are themselves component selections. A realisation refers to the generation of initial conditions — i.e. particle positions and momenta for particle components and fluid grids like energy and momentum densities for fluid components — but also late-time re-realisation of fluid grids for fluid components.

Each sub-parameter is described below:

  • 'gauge': Sets the general relativistic gauge in which to perform the realisation, i.e. the gauge of the transfer functions \(T(a, k)\) to use. Available gauges are 'N-body' (\(N\)-body gauge), 'synchronous' (synchronous gauge) or 'Newtonian' (conformal Newtonian / longitudinal gauge).

  • 'back-scale': Specifies whether to do particle realisation using a back-scaled density transfer function, rather than using the transfer function as is. That is, without back-scaling, the raw density transfer function \(T_\delta(a, k)\) is used for realisation at time (scale factor value) \(a\) of particle positions, and similarly the raw velocity transfer function \(T_\theta(a, k)\) is used for the particle velocities. With back-scaling, the density transfer function is substituted by a scaled-back version of itself at time \(a = 1\):

    \[T_\delta(a, k) \rightarrow \frac{D(a)}{D(a=1)} T_\delta(a=1, k)\,,\]

    where \(D(a)\) is the linear, Newtonian growth factor. Also, the velocity transfer function \(T_\theta(a, k)\) is no longer used at all, but replaced with a Newtonian approximation

    \[T_\theta(a, k) \rightarrow -aH(a)f(a) \biggl(\frac{D(a)}{D(a=1)} T_\delta(a=1, k) \biggr)\,,\]

    where \(f(a) \equiv \mathrm{d}\ln D(a) / \mathrm{d}\ln a\) is the linear, Newtonian growth rate. Back-scaling is only possible for particle components.

  • 'LPT': Specifies the order of Lagrangian perturbation theory to use when realising particle components. Orders \(1\), \(2\) and \(3\) are available. While the first order (1LPT) is carried out relativistically (if not using back-scaling), the higher order corrections are always constructed in a Newtonian fashion (though they are built out of the relativistic 1LPT results).

  • 'dealias': Specifies whether aliasing defects should be removed during 2LPT and 3LPT computations.

  • 'non-Gaussianity': Sets the amount of local non-Gaussianity to include in realisations. This is simply the number \(f_{\text{NL}}\) in the transformation

    \[\delta(\boldsymbol{x}) \rightarrow \delta(\boldsymbol{x}) + f_{\text{NL}}\delta^2(\boldsymbol{x})\,,\]

    where the \(\delta^2(\boldsymbol{x})\) term introduces local non-Gaussianity into the otherwise Gaussian density contrast field \(\delta(\boldsymbol{x})\).

    For fluid components, only \(\delta\) (the energy density) will be affected. For particle components, both the positions and velocities are affected, with the non-Gaussian velocity contribution obtained from \(f_{\text{NL}}\delta^2(\boldsymbol{x})\) using \(aH(a)f(a)\) as a conversion factor, similar to how the velocities are obtained when using back-scaling (see above).

  • 'structure': Specifies the underlying 3D structure to use for a realisation. This can be either the primordial noise ('primordial') \(\zeta(k)\mathcal{R}(\boldsymbol{k})\) (random noise \(\mathcal{R}(\boldsymbol{k})\) with amplitude \(\zeta(k)\)) or the structure extracted from the non-linearly evolved energy density of the component ('non-linear'), i.e. \(\delta(a, \boldsymbol{k})/T_\delta(a, k)\). Realisation happening at the initial time of the simulation (i.e. initial condition generation) will always make use of the primordial noise, though at this time the two options are mathematically equivalent. As late-time realisation is not possible for particle components, this realisation option only affects fluid components.

  • 'compound': When performing late-time realisations for fluid components using the non-linearly evolved energy density as the source of structure, some fluid variables can be defined in several ways. Consider the (conserved) shear stress fluid variable \(\varsigma^i_j(a, \boldsymbol{x})\), realised through

    \[\varsigma^i_j(a, \boldsymbol{x}) = \bigl(\varrho + c^{-2}\mathcal{P}\bigr)\sigma^i_j(a, \boldsymbol{x})\,,\]

    with \(\sigma^i_j(a, \boldsymbol{x})\) itself realised from the scalar anisotropic stress. With the 'compound' realisation option set to 'linear', the (conserved) energy density and pressure in the parenthesis above will be evaluated at the background level, \(\varrho + c^{-2}\mathcal{P} \rightarrow (1 + w)\bar{\varrho}(a)\). With the 'compound' realisation option set to 'non-linear', the full non-linearly evolved fluid grids are used, \(\varrho + c^{-2}\mathcal{P} \rightarrow \varrho(a, \boldsymbol{x}) + c^{-2}\mathcal{P}(a, \boldsymbol{x})\). Using the non-linear option injects additional non-linearity into the realised fluid variable, which can be desirable. See the paper on ‘νCO𝘕CEPT: Cosmological neutrino simulations from the non-linear Boltzmann hierarchy’ for further details.

Example 0

Do all realisations in synchronous gauge. Also, use back-scaling when realising components with a name/species of 'matter:

realization_options = {
    'gauge': {
        'all': 'synchronous',
    },
    'back-scaling': {
        'matter': True,
    },
}

Note

When using back-scaling, the \(\delta\) transfer function is used not only for the particle positions but also for the velocities. This is crucial when using the synchronous gauge, as the velocity transfer function in this gauge is not well suited for \(N\)-body initial conditions.

Example 1

Make use of second-order Lagrangian perturbation theory (2LPT) when realising particle components:

realization_options = {
    'LPT': {
        'particles': 2,
    },
}

As the 'LPT' specification only applies to particle components anyway, we can also do

realization_options = {
    'LPT': {
        'all': 2,
    },
}

which can be more succinctly expressed as

realization_options = {
    'LPT': 2,
}

Example 2

Make use of dealiased third-order Lagrangian perturbation theory (3LPT) when realising particle components:

realization_options = {
    'LPT': 3,
    'dealias': True,
}

This is the most expensive but also most accurate particle realisation scheme implemented.

Example 3

Always perform realisations using the primordial noise as the underlying source of structure, regardless of the time of realisation:

realization_options = {
    'structure': {
        'all': 'primordial',
    },
}

select_lives

Description

Specifies life spans of components

Default

 

{
    'default': (0, ထ),
}

Elaboration

This is a component selection dict, specifying the life span of individual components. Here, a life span is a 2-tuple in the format

(a_activate, a_terminate)

specifying the values of the scale factor \(a\) at which components should be activated and terminated, respectively. Prior to its activation time, a given component will not take part in the simulation. At the activation time, it will then be realised and included in the simulation. At termination time, the component will be removed from the simulation, and it cannot be reintroduced. The default specifications of this parameter ensures that — by default — all components are active from the beginning to the end of the simulation.

Example 0

Let the component with the name 'linear neutrino' participate actively in the simulation until \(a = 0.1\), at which point the component with the name 'non-linear neutrino' should take its place:

select_lives = {
        'linear neutrino': (0,   0.1),
    'non-linear neutrino': (0.1,   ထ),
}

Assuming the two components both represent the 'neutrino' species, but makes use of linear and non-linear evolution, this then effectively sets \(a = 0.1\) to be the time at which the neutrino species should be treated non-linearly. This can spare the simulation from a lot of unnecessary computation. See the tutorial for a similar example use case.

softening_kernel

Description

The kernel to use for particle softening

Default

 

'spline'

Elaboration

For direct particle-particle forces (PP gravity, short-range P³M gravity), the force needs to be softened at short distances in order to avoid numerical problems with insufficient time resolution for two-body encounters. See the paper on ‘The cosmological simulation code CO𝘕CEPT 1.0’ for details. This parameter sets the type of softening to use for all such forces and components. All softening kernels may be described as a transformation on \(|\boldsymbol{x}|^{-3}\) in the force

\[\boldsymbol{f} \propto |\boldsymbol{x}|^{-3}\boldsymbol{x}\, .\]

The implemented softening kernels are:

  • 'none': Do not use any softening;

    \[|\boldsymbol{x}|^{-3} \rightarrow |\boldsymbol{x}|^{-3}\, .\]

  • 'plummer': Make use of the Plummer softening kernel;

    \[|\boldsymbol{x}|^{-3} \rightarrow \bigl(|\boldsymbol{x}|^2 + \epsilon^2\bigr)^{-\frac{3}{2}}\, ,\]

    with \(\epsilon\) the softening length.

  • 'spline': Make use of the cubic spline softening kernel, also used by e.g. GADGET;

    \[\begin{split}|\boldsymbol{x}|^{-3} \rightarrow \begin{cases} \displaystyle \frac{32}{\epsilon_{\text{B}}^3}\biggl( x_{\text{B}}^3 - \frac{6}{5}x_{\text{B}}^2 + \frac{1}{3} \biggr) & \displaystyle x_{\text{B}} < \frac{1}{2} \\ \displaystyle \frac{32}{\epsilon_{\text{B}}^3}\biggl( -\frac{1}{3}x_{\text{B}}^3 + \frac{6}{5}x_{\text{B}}^2 - \frac{3}{2}x_{\text{B}} + \frac{2}{3} - \frac{1}{480}x_{\text{B}}^{-3} \biggr) & \displaystyle \frac{1}{2} \leq x_{\text{B}} < 1 \\ \displaystyle |\boldsymbol{x}|^{-3} & \displaystyle 1 \leq x_{\text{B}}\, , \end{cases}\end{split}\]

    with \(x_{\text{B}} \equiv |\boldsymbol{x}|/\epsilon_{\text{B}}\) and \(\epsilon_{\text{B}} = 2.8\epsilon\), with \(\epsilon\) being the specified “Plummer-equivalent” softening length.

Example 0

Use simple Plummer softening:

softening_kernel = 'plummer'

select_softening_length

Description

Specifies particle softening lengths

Default

 

{
    'default': '0.025*boxsize/cbrt(N)',
}

Elaboration

Direct particle-particle forces are softened according to the chosen softening kernel. Regardless of the chosen kernel, the associated length scale is expressed in terms of the “Plummer-equivalent” softening length \(\epsilon\). This parameter is a component selection dict specifying this \(\epsilon\) for the particle components within the simulation (fluid components have no need for softening).

The default value sets \(\epsilon\) to be \(2.5\,\%\) of the mean inter-particle distance, within each particle component separately. Here 'N' is dynamically substituted for the number of particles \(N\) within the given component.

Note

The specified softening lengths are always comoving

Example 0

Use a softening length of \(10\,\mathrm{kpc}/h\) for all components:

select_softening_length = {
    'all': 10*kpc/h,
}

Example 1

Use a softening length of \(1/10\,000\) of the box size for the component with a name/species of 'cold dark matter' and a softening length of \(2\,\%\) of the mean inter-particle distance (between particles of each given component) for all other components:

select_softening_length = {
    'cold dark matter': boxsize/10_000,
    'all'             : '0.02*boxsize/cbrt(N)',
}

Note

Parameters like boxsize may be used either directly or referred to inside strs. Component-specific attributes like N must be specified within a str.