Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found
Select Git revision

Target

Select target project
  • dc-oman1/swiftsim
  • swift/swiftsim
  • pdraper/swiftsim
  • tkchan/swiftsim
  • dc-turn5/swiftsim
5 results
Select Git revision
Show changes
Showing
with 888 additions and 34 deletions
.. Sink particles in GEAR model
Darwin Roduit, 24 November 2024
.. _sink_GEAR_model_summary:
Model summary
-------------
.. figure:: sink_scheme.png
:width: 400px
:align: center
:figclass: align-center
:alt: Illustration of the sink scheme.
This figure illustrates the sink scheme. Eligible gas particles (blue) are converted to sink particles (orange). Then, the sink searches for eligible gas/sink particles (red edges) to swallow and finally accretes them. The final step is to spawn star particles (yellow) by sampling an IMF. These stars represent a continuous portion of the IMF or an individual star (the figure does not distinguish the two types of stars).
Here, we provide a comprehensive summary of the model. Sink particles are an alternative to the current model of star formation that transforms gas particles into sink particles under some criteria explained below. Then, the sink can accrete gas and spawn stars. Sink particles are collisionless particles, i.e. they interact with other particles only through gravity. They can be seen as particles representing unresolved regions of collapse.
We sample an IMF to draw the stars' mass and spawn them stochastically. Below, we provide a detailed explanation of the IMF sampling. In short, we split the IMF into two parts. In the lower part, star particles represent a continuous stellar population, similar to what is currently implemented in standard models. In the second upper part, star particles represent individual stars. Then, the feedback is improved to take into account both types of stars. Currently, only supernovae feedback is implemented. Thus, the sink particle method allows us to track the effects of individual stars' supernovae in the simulation.
The current model includes sink formation, gas accretion, sink merging, IMF sampling, star spawning and finally supernovae feedback (type Ia and II). The figures below illustrates the scheme and the associated tasks.
Our main references are the following papers: `Bate et al. <https://ui.adsabs.harvard.edu/abs/1995MNRAS.277..362B/abstract>`_, `Price et al. <https://ui.adsabs.harvard.edu/abs/2018PASA...35...31P/abstract>`_ and `Federrath et al. <https://ui.adsabs.harvard.edu/abs/2010ApJ...713..269F/abstract>`_
.. note::
Sink examples are available in ``examples/SinkParticles/``. They include self-gravity, cooling and feedback effects.
.. figure:: ../../../Task/sink.png
:width: 400px
:align: center
:figclass: align-center
:alt: Task dependencies for the sink scheme.
This figure shows the task dependencies for the sink scheme.
The first rectangle groups the tasks that determine if sink particles will swallow other
sink particles or gas particles.
In the second one, the gas particles tagged as "to be swallowed" are effectively swallowed.
In the third one, the sink particles tagged as "to be swallowed" are effectively swallowed.
This was done with SWIFT v0.9.0.
Conversion from comoving to physical space
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the following, we always refer to physical quantities. In non-cosmological simulations, there is no ambiguity between comoving and physical quantities since the universe is not expanding, and thus, the scale factor is :math:`a(t)=1`. However, in cosmological simulation, we need to convert from comoving quantities to physical ones when needed, e.g. to compute energies. We denote physical quantities by the subscript `p` and comoving ones by `c`. Here is a recap:
* :math:`\mathbf{x}_p = \mathbf{x}_c a`
* :math:`\mathbf{v}_p = \mathbf{v}_c/a + a H \mathbf{x}_c`
* :math:`\rho_p = \rho_c/a^3`
* :math:`\Phi_p = \Phi_c/a + c(a)`
* :math:`u_p = u_c/a^{3(\gamma -1)}`
Here, :math:`H` is the Hubble constant at any redshift, :math:`c(a)` is the potential normalization constant and :math:`\gamma` the gas adiabatic index. Notice that the potential normalization constant has been chosen to be :math:`c(a) = 0`.
Sink formation
~~~~~~~~~~~~~~
.. figure:: sink_accretion_radius.png
:width: 400px
:align: center
:figclass: align-center
:alt: GEAR sink accretion radius representation
This figure shows a sink particle (in orange) newly formed among other gas particles (in blue). The accretion radius is :math:`r_{\text{acc}}`. It is the one used for sink formation. There is also an inner accretion radius :math:`f_{\text{acc}} r_{\text{acc}}` (:math:`0 \leq f_{\text{acc}} \leq 1`) that is used for gas swallowing. Particles within this inner radius are eaten without passing any other check, while particles between the two radii pass some check before being swallowed.
At the core of the sink particle method is the sink formation algorithm. This is critical to form sinks in regions adequate for star formation. Failing to can produce spurious sinks and stars, which is not desirable. However, there is no easy answer to the question. We chose to implement a simple and efficient algorithm.
The primary criteria required to transform a gas particle into a sink are:
1. the density of a given particle :math:`i` is exceeds a user-defined threshold density: :math:`\rho_i > \rho_{\text{threshold}}` ;
2. if the particle's density lies between the threshold density and a user-defined maximal density: :math:`\rho_{\text{threshold}} \leq \rho_i \leq \rho_{\text{maximal}}`, the particle's temperature must also be below a user-defined threshold: :math:`T_i < T_{\text{threshold}}`;
3. if the particle’s density exceeds the maximal density: :math:`\rho_i > \rho_{\text{threshold}}`, no temperature check is performed.
The first criterion is common, but not the second one. We check the latter to ensure that sink particles, and thus stars, are not generated in hot regions. The third one ensures that if, for some reason, the cooling of the gas is not efficient, but the density gets very high, then we can form a sink. The parameters for those threshold quantities are respectively called ``density_threshold_Hpcm3``, ``maximal_density_threshold_Hpcm3`` and ``temperature_threshold_K``.
Then, further criteria are checked. They are always checked for gas particles within the accretion radius :math:`r_{\text{acc}}` (called the ``cut_off_radius`` in the parameter file) of a given gas particle :math:`i`. Such gas particles are called *neighbours*.
.. note::
Notice that in the current implementation, the accretion radius is kept *fixed and the same* for all sinks. However, for the sake of generality, the mathematical expressions are given as if the accretion radii could be different.
So, the other criteria are the following:
3. The gas particle is at a local potential minimum: :math:`\Phi_i = \min_j \Phi_j`.
4. Gas surrounding the particle is at rest or collapsing: :math:`\nabla \cdot \mathbf{v}_{i, p} \leq 0`. (Optional)
5. The smoothing kernel's edge of the particle is less than the accretion radius: :math:`\gamma_k h_i < r_{\text{acc}}`, where :math:`\gamma_k` is kernel dependent. (Optional)
6. All neighbours are currently active.
7. The thermal energy of the neighbours satisfies: :math:`E_{\text{therm}} < |E_{\text{pot}}|/2`. (Optional, together with criterion 8.)
8. The sum of thermal energy and rotational energy satisfies: :math:`E_{\text{therm}} + E_{\text{rot}} < | E_{\text{pot}}|`. (Optional, together with criterion 7.)
9. The total energy of the neighbours is negative, i.e. the clump is bound to the sink: :math:`E_{\text{tot}} < 0`. (Optional)
10. Forming a sink here will not overlap an existing sink :math:`s`: :math:`\left| \mathbf{x}_i - \mathbf{x}_s \right| > r_{\text{acc}, i} + r_{\text{acc}, s}`. (Optional)
Some criteria are *optional* and can be *deactivated*. By default, they are all enabled. The different energies are computed as follows:
* :math:`E_{\text{therm}} = \displaystyle \sum_j m_j u_{j, p}`
* :math:`E_{\text{kin}} = \displaystyle \frac{1}{2} \sum_j m_j (\mathbf{v}_{i, p} - \mathbf{v}_{j, p})^2`
* :math:`E_{\text{pot}} = \displaystyle \frac{G_N}{2} \sum_j m_i m_j \Phi_{j, p}`
* :math:`E_{\text{rot}} = \displaystyle \sqrt{E_{\text{rot}, x}^2 + E_{\text{rot}, y}^2 + E_{\text{rot}, z}^2}`
* :math:`E_{\text{rot}, x} = \displaystyle \frac{1}{2} \sum_j m_j \frac{L_{ij, x}^2}{\sqrt{(y_{i, p} - y_{j, p})^2 + (z_{i,p} - z_{j, p})^2}}`
* :math:`E_{\text{rot}, y} = \displaystyle \frac{1}{2} \sum_j m_j \frac{L_{ij, y}^2}{\sqrt{(x_{i,p} - x_{j,p})^2 + (z_{i,p} - z_{j,p})^2}}`
* :math:`E_{\text{rot}, z} = \displaystyle \frac{1}{2} \sum_j m_j \frac{L_{ij, z}^2}{\sqrt{(x_{i, p} - x_{j, p})^2 + (y_{i,p} - y_{j,p})^2}}`
* The (physical) specific angular momentum: :math:`\mathbf{L}_{ij} = ( \mathbf{x}_{i, p} - \mathbf{x}_{j, p}) \times ( \mathbf{v}_{i, p} - \mathbf{x}_{j, p})`
* :math:`E_{\text{mag}} = \displaystyle \sum_j E_{\text{mag}, j}`
* :math:`E_{\text{tot}} = E_{\text{kin}} + E_{\text{pot}} + E_{\text{therm}} + E_{\text{mag}}`
.. note::
Currently, magnetic energy is not included in the total energy, since the MHD scheme is in progress. However, the necessary modifications have already been taken care of.
The :math:`p` subscript is to recall that we are using physical quantities to compute energies.
Here, the potential is retrieved from the gravity solver.
Some comments about the criteria:
The third criterion is mainly here to prevent two sink particles from forming at a distance smaller than the sink accretion radius. Since we allow sinks to merge, such a situation raises the question of which sink should swallow the other. This can depend on the order of the tasks, which is not a desirable property. As a result, this criterion is enforced.
The tenth criterion prevents the formation of spurious sinks. Experiences have shown that removing gas within the accretion radius biases the hydro density estimates: the gas feels a force toward the sink. At some point, there is an equilibrium and gas particles accumulate at the edge of the accretion radius, which can then spawn sink particles that do not fall onto the primary sink and never merge. Moreover, the physical reason behind this criterion is that a sink represents a region of collapse. As a result, there is no need to have many sinks occupying the same space volume. They would compete for gas accretion without necessarily merging. This criterion is particularly meaningful in cosmological simulations to ensure proper sampling of the IMF. *This criterion can be disabled*.
Once a sink is formed, we record it birth time (or scale factor in cosmological runs). This information is used to put the sink into three categories: young, old and dead. If a sink is dead, it cannot accrete gas or sink anymore. However, a dead sink can still be swallowed by a young/old sink. Young and old sink only differ by their maximal allowed timestep. Details are provided in :ref:`sink_GEAR_timesteps`.
.. note::
However, notice that contrary to `Bate et al. <https://ui.adsabs.harvard.edu/abs/1995MNRAS.277..362B/abstract>`_, no boundary conditions for sink particles are introduced in the hydrodynamics calculations.
.. note::
Note that sink formation can be disabled. It can be useful, for example if you already have sinks in your initial conditions.
Gas accretion
~~~~~~~~~~~~~
Now that sink particles can populate the simulation, they need to swallow gas particles. To be accreted, gas particles need to pass a series of criteria. In the following, :math:`s` denotes a sink particle and :math:`i` is a gas particle. The criteria are the following:
#. The sink is not dead. If it is dead, it does not accrete gas. A sink is considered dead if it is older than ``timestep_age_threshold_unlimited_Myr``.
#. If the gas falls within :math:`f_{\text{acc}} r_{\text{acc}}` (:math:`0 \leq f_{\text{acc}} \leq 1`), the gas is accreted without further check.
#. In the region :math:`f_{\text{acc}} r_{\text{acc}} \leq |\mathbf{x}_i| \leq r_{\text{acc}}`, then, we check:
#. The specific angular momentum is smaller than the one of a Keplerian orbit at :math:`r_{\text{acc}}`: :math:`|\mathbf{L}_{si}| \leq |\mathbf{L}_{\text{Kepler}}|`.
#. The gas is gravitationally bound to the sink particle: :math:`E_{\text{tot}} < 0`.
#. The gas size is smaller or equal to the sink size: :math:`\gamma_k h_i \leq r_{\text{acc}}`.
#. Out of all pairs of sink-gas, the gas is the most bound to this one. This case is illustrated in the figure below.
#. The total swallowed mass does not exceed ``n_IMF`` times the IMF mass (see the IMF sampling section), but make sure to swallow at least one particle: :math:`M_\text{swallowed} \leq n_\text{IMF} M_\text{IMF} \text{ or } M_\text{swallowed} = 0`.
The physical specific angular momenta and the total energy are given by:
* :math:`\mathbf{L}_{si} = ( \mathbf{x}_{s, p} - \mathbf{x}_{i, p}) \times ( \mathbf{v}_{s, p} - \mathbf{x}_{i, p})`,
* :math:`|\mathbf{L}_{\text{Kepler}}| = r_{\text{acc}, p} \cdot \sqrt{G_N m_s / |\mathbf{x}_{s, p} - \mathbf{x}_{i, p}|^3}`.
* :math:`E_{\text{tot}} = \frac{1}{2} (\mathbf{v}_{s, p} - \mathbf{x}_{i, p})^2 - G_N \Phi(|\mathbf{x}_{s, p} - \mathbf{x}_{i, p}|) + m_i u_{i, p}`.
.. note::
Here the potential is the softened potential of Swift.
Those criteria are similar to `Price et al. <https://ui.adsabs.harvard.edu/abs/2018PASA...35...31P/abstract>`_ and `Grudic et al. (2021) <https://academic.oup.com/mnras/article/506/2/2199/6276745>`_, with the addition of the internal energy. This term ensures that the gas is cold enough to be accreted. Its main purpose is to avoid gas accretion and star spawning in hot regions far from sink/star-forming regions, which can happen, e.g., if a sink leaves a galaxy.
Let's comment on the fourth criterion, specific to our star formation scheme. This criterion restricts the swallowed mass to avoid spawning too many stars in a single time step. Swallowing too many gas particles in a time-step can lead to instabilities in the hydrodynamics, given that gas particles act as interpolation points. Also, creating many stars at once is prejudicial for two reasons. First, the stars' mass samples an IMF, but the star's metallicities do not. So, all stars end up with the same metal content. This situation does not reflect the history of metal accretion and will lead to poor galaxy properties. Second, we need to specify at runtime the maximal number of memory allocated for extra stars until the next tree rebuild. If we create more stars than this limit, the code will stop and send an error.
Since our politics is not to arbitrarily restrict the accretion using some arbitrary mass accretion rate (in fact, the accretion must be feedback-regulated), we then lower the sink time step to swallow the remaining gas particles soon. So, instead of eating a considerable amount of mass and spawning many stars in a big time step, we swallow smaller amounts of gas/sink and create fewer stars in smaller time steps. Details about the how we reduce the timestep are given in :ref:`sink_GEAR_timesteps`.
Once a gas is eligible for accretion, its properties are assigned to the sink. The sink accretes the *entire* gas particle mass and its properties are updated in the following way:
* :math:`\displaystyle \mathbf{v}_{s, c} = \frac{m_s \mathbf{v}_{s, c} + m_i \mathbf{v}_{i, c}}{m_s + m_i}`,
* Swallowed physical angular momentum: :math:`\mathbf{L}_{\text{acc}} = \mathbf{L}_{\text{acc}} + m_i( \mathbf{x}_{s, p} - \mathbf{x}_{i, p}) \times ( \mathbf{v}_{s, p} - \mathbf{x}_{i, p})`,
* :math:`X_{Z, s} = \dfrac{X_{Z,i} m_i + X_{Z,s} m_s}{m_s + m_i}`, the metal mass fraction for each element,
* :math:`m_s = m_s + m_i`.
.. figure:: sink_overlapping.png
:width: 400px
:align: center
:figclass: align-center
:alt: Example of two sinks overlapping
This figure shows two sink particles (in orange) with gas particles (in blue) falling in the accretion radii of both sinks. In such cases, the gas particles in the overlapping regions are swallowed by the sink they are the most bound to.
Sink merging
~~~~~~~~~~~~
Sinks are allowed to merge if they enter one's accretion radius. We merge two sink particles if they respect a set of criteria. The criteria are similar to the gas particles, namely:
#. At least one of the sinks is not dead. A sink is considered dead if it is older than ``timestep_age_threshold_unlimited_Myr``.
#. If one of the sinks falls within the other's inner accretion radius, :math:`f_{\text{acc}} r_{\text{acc}}` (:math:`0 \leq f_{\text{acc}} \leq 1`), the sinks are merged without further check.
#. In the region :math:`f_{\text{acc}} r_{\text{acc}} \leq |\mathbf{x}_i| \leq r_{\text{acc}}`, then, we check:
#. The specific angular momentum is smaller than the one of a Keplerian orbit at :math:`r_{\text{acc}}`: :math:`|\mathbf{L}_{ss'}| \leq |\mathbf{L}_{\text{Kepler}}|`.
#. One sink is gravitationally bound to the other: :math:`E_{\text{mec}, ss'} < 0` or :math:`E_{\text{mec}, s's} < 0`.
#. The total swallowed mass does not exceed ``n_IMF`` times the IMF mass (see the IMF sampling section), but make sure to swallow at least one particle: :math:`M_\text{swallowed} \leq n_\text{IMF} M_\text{IMF} \text{ or } M_\text{swallowed} = 0`.
We compute the angular momenta and total energies in the same manner as gas particles, with the difference that we do not use internal energy. Notice that we have two energies: each sink has a different potential energy since their mass can differ.
When sinks merge, the sink with the smallest mass merges with the sink with the largest. If the two sinks have the same mass, we check the sink ID number and add the smallest ID to the biggest one.
IMF sampling
~~~~~~~~~~~~
.. figure:: sink_imf.png
:width: 400px
:align: center
:figclass: align-center
:alt: Initial mass function split into the continuous and discrete part.
This figure shows an IMF split into two parts by :math:`m_t`: the continuous (orange) and the discrete (blue) part. The IMF mass is :math:`M_\text{IMF} = M_c + M_d`.
Now remains one critical question: how are stars formed in this scheme? Simply, by sampling an IMF.
In our scheme, population III stars and population II have two different IMFs. For the sake of simplicity, in the following presentation, we consider only the case of population II stars. However, this can be easily generalized to population III.
Consider an IMF such as the one above. We split it into two parts at ``minimal_discrete_mass_Msun`` (called :math:`m_t` on the illustration). The reason behind this is that we want to spawn star particles that represent *individual* (massive) stars, i.e. they are "discrete". However, for computational reasons, we cannot afford to spawn every star of the IMF as a single particle. Since the IMF is dominated by low-mass stars (< 8 :math:`M_\odot` and even smaller) that do not end up in supernovae, we would have lots of "passive" stars.
.. note::
Recall that currently (July 2024), GEAR only implements SNIa and SNII as stellar feedback. Stars that do not undergo supernovae phases are "passive" in the current implementation.
As a result, we group all those low-mass stars in one stellar particle of mass ``stellar_particle_mass_Msun``. Such star particles are called "continuous", contrary to the "discrete" individual stars. With all that information, we can compute the number of stars in the continuous part of the IMF (called :math:`N_c`) and in the discrete part (called :math:`N_d`). Finally, we can compute the probabilities of each part, respectively called :math:`P_c` and :math:`P_d`. Notice that the mathematical derivation is given in the theory latex files.
Thus, the algorithm to sample the IMF and determine the sink's ``target_mass`` is the following :
* draw a random number :math:`\chi` from a uniform distribution in the interval :math:`(0 , \; 1 ]`;
* if :math:`\chi < P_c`: ``sink.target_mass = stellar_particle_mass``;
* else: ``sink_target_mass = sample_IMF_high()``.
We have assumed that we have a function ``sample_IMF_high()`` that correctly samples the IMF in the discrete part.
Now, what happens to the sink? After a sink forms, we give it a target mass with the abovementioned algorithm. The sink then swallows gas particles (see the task graph at the top of the page) and spawns stars. *While the sink possesses enough mass*, we can continue to choose a new target mass. When the sink does have enough mass, the algorithm stops for this timestep. The next timestep, the sink may accrete gas and spawn stars again. The sink cannot spawn stars if it never reaches the target mass. In practice, sink particles could accumulate enough pass to spawn individual (Pop III) stars with masses 240 :math:`M_\odot` and more!
For low-resolution simulations (:math:`m_\text{gas} > 100 \; M_\odot`), we also add a minimal sink mass constraint: the sink can spawn a star if ``m_sink > target_mass`` *and* ``m_sink - target_mass >= minimal_mass``. In low-resolution simulation, when a gas particle turns into a sink, the latter can have enough mass to spawn stars, depending on the sink stars and IMF parameters. As a result, the sink spawns the stars and then ends up with :math:`m_\text{sink} \ll m_\text{gas}`. Such a situation is detrimental for two reasons: 1) the sink mass is so low that gas can seldom be bound to it and thus stops spawning stars and 2) the sink can get kicked away by gravitational interactions due to the high mass difference. The parameter controlling the sink's minimal mass is ``GEARSink:sink_minimal_mass_Msun``.
As explained at the beginning of this section, GEAR uses two IMFs for the population of II and III stars. The latter are called the first stars in the code. How does a sink decide which IMF to draw the target mass from? We define a threshold metallicity, ``GEARFeedback:imf_transition_metallicity`` that determines the first stars' maximal metallicity. When the sink particle's metallicity exceeds this threshold, it uses the population II IMF, defined in ``GEARFeedback:yields_table``.
Star spawning
~~~~~~~~~~~~~
Once the sink spawns a star particle, we need to give properties to the star. From the sink, the star inherits the chemistry properties. The star is placed randomly within the sink's accretion radius. We draw the star's velocity components from a Gaussian distribution with mean :math:`\mu = 0` and standard deviation :math:`\sigma` determined as follows:
.. math::
\sigma = f \cdot \sqrt{\frac{G_N M_s}{r_{\text{acc}}}} \; ,
where :math:`G_N` is Newton's gravitational constant, math:`M_s` is the sink's mass before starting to spawn stars, and :math:`f` is a user-defined scaling factor. The latter corresponds to the ``star_spawning_sigma_factor`` parameter.
Stellar feedback
~~~~~~~~~~~~~~~~
Stellar feedback *per se* is not in the sink module but in the feedback one. However, if one uses sink particles with individual stars, the feedback implementation must be adapted. Here is a recap of the GEAR feedback with sink particles.
All details and explanations about GEAR stellar feedback are provided in the GEAR :ref:`gear_stellar_evolution_and_feedback` section. Here, we only provide the changes from the previous model.
In the previous model, star particles represented a population of stars with a defined IMF. Now, we have two kinds of star particles: particles representing a *continuous* portion of the IMF (see the image above) and particles representing a *single* (discrete) star. This new model requires updating the feedback model so that stars eligible for SN feedback can realise this feedback.
**Discrete star particles:** Since we now have individual star particles, we can easily track SNII feedback for stars with a mass larger than 8 :math:`M_\odot`. When a star's age reaches its lifetime, it undergoes SNII feedback.
**Continuous star particles**: In this case, we implemented SNII and SNIa as in the previous model. At each timestep, we determine the number of SN explosions occurring. In practice, this means that we can set the ``minimal_discrete_masss`` to any value, and the code takes care of the rest.
.. Supernova feedback in GEAR model
Darwin Roduit, 30 March 2025
.. gear_sn_feedback_models:
.. _gear_sn_feedback_models:
GEAR supernova feedback
=======================
When a star goes into a supernova, we compute the amount of internal energy, mass and metals the explosion transfers to the star's neighbouring gas particles. We will group all these in the “fluxes” term.
We have two models for the distribution of these fluxes and the subgrid modelling of the supernovae: GEAR model and GEAR mechanical model.
.. note::
We may sometimes refer to GEAR feedback as GEAR thermal feedback to clearly distinguish it from GEAR mechanical feedback.
.. _gear_sn_feedback_gear_thermal:
GEAR model
----------
In the GEAR (thermal) model, the fluxes are distributed by weighing with the SPH kernel:
.. math::
w_{{sj}} = W_i(\| \vec{{x}}_{{sj}} \|, \, h_s) \frac{{m_j}}{{\rho_s}}
for :math:`s` the star and :math:`j` the gas (`Revaz and Jablonka 2012 <https://ui.adsabs.harvard.edu/abs/2012A%26A...538A..82R/abstract>`_).
In the GEAR model, we do not inject momentum, only *internal energy*. Then, internal energy conversion to kinetic energy is left to the hydrodynamic solver, which will compute appropriately the gas density, temperature and velocity.
However, if the cooling radius :math:`R_{\text{cool}}` of the explosion is unresolved, i.e. the cooling radius is smaller than our simulation resolution, the cooling radiates away the internal energy.
To understand why this happens, let us remind the main phases of an SN explosion in a homogeneous medium. We provide a simple picture that is more complicated than the one explained here. See `Haid et al. 2016 <https://ui.adsabs.harvard.edu/abs/2016MNRAS.460.2962H/abstract>`_ or `Thornton et al. 1998 <https://iopscience.iop.org/article/10.1086/305704>`_ for further details.
* The first stage of the SN explosion is the **free expansion**. In this momentum-conserving regime, the ejecta of the stars sweeps the ISM. At the end of this phase, 72% of the initial SN energy has been converted to thermal energy.
* Once the SN ejecta has swept an ISM mass of comparable mass, the blast wave enters the **energy-conserving Sedov-Taylor phase**. It continues with an adiabatic expansion, performing some :math:`P \, \mathrm{d}V` work on the gas. In this phase, the internal energy is converted into kinetic energy as the ejecta continues sweeping the ISM gas. This phase continues until radiative losses become significant after some radius :math:`R_{\text{cool}}`.
* At this point, the blast wave enters the **momentum-conserving snowplough phase** and forms a thin shell. In this regime, efficient cooling radiates away the internal energy, and thus, the blast wave slows down.
Now, we better understand why the internal energy is radiated away. It is a consequence of efficient cooling in the snowplough phase. When this happens, the feedback is unresolved and its energy does not affect the ISM, apart from the mass and metal injection. To circumvent this problem, GEAR thermal feedback implements a **fixed delayed cooling mechanism**. The cooling of the particles affected by feedback is deactivated during some mega year, usually 5 Myr in our simulations. The time is controlled by the ``GrackleCooling:thermal_time_myr`` parameter. This mechanism allows the internal energy to transform into kinetic energy without immediately being radiated away. However, such an approach poses the question of the time required to prevent gas from cooling in the simulations.
...@@ -217,7 +217,8 @@ and the second kick cannot be done before the cooling:: ...@@ -217,7 +217,8 @@ and the second kick cannot be done before the cooling::
The next step is to activate your task The next step is to activate your task
in ``engine_marktasks_mapper`` in ``engine_marktasks.c``:: in the relevant section of ``cell_unskip.c`` (things are split
by type of particles the tasks act on)::
else if (t->type == task_type_cooling || t->type == task_type_sourceterms) { else if (t->type == task_type_cooling || t->type == task_type_sourceterms) {
if (cell_is_active_hydro(t->ci, e)) scheduler_activate(s, t); if (cell_is_active_hydro(t->ci, e)) scheduler_activate(s, t);
......
...@@ -296,8 +296,9 @@ call:: ...@@ -296,8 +296,9 @@ call::
The next step is to activate your task The next step is to activate your task in the relevant section of
in ``engine_marktasks_mapper`` in ``engine_marktasks.c``:: ``cell_unskip.c`` (things are split by the type of particles the
tasks run on)::
/* Single-cell task? */ /* Single-cell task? */
......
...@@ -23,9 +23,9 @@ copyright = "2014-2023, SWIFT Collaboration" ...@@ -23,9 +23,9 @@ copyright = "2014-2023, SWIFT Collaboration"
author = "SWIFT Team" author = "SWIFT Team"
# The short X.Y version # The short X.Y version
version = "1.0" version = "2025.04"
# The full version, including alpha/beta/rc tags # The full version, including alpha/beta/rc tags
release = "1.0.0" release = "2025.04"
# -- Find additional scripts to run as part of the documentation build ------- # -- Find additional scripts to run as part of the documentation build -------
import glob import glob
...@@ -147,7 +147,7 @@ latex_documents = [ ...@@ -147,7 +147,7 @@ latex_documents = [
( (
master_doc, master_doc,
"SWIFT-user-manual.tex", "SWIFT-user-manual.tex",
"SWIFT user \& developer documentation", "SWIFT user & developer documentation",
"SWIFT Collaboration", "SWIFT Collaboration",
"manual", "manual",
) )
......
SWIFT Onboarding Guide SWIFT Onboarding Guide
====================== ======================
This is an onboarding guide for SWIFT that can be found on `swiftsim.com/onboarding.pdf`. This is an onboarding guide for SWIFT that can be found on `https://swift.strw.leidenuniv.nl/onboarding.pdf`.
You will need the `sphinx` and python package (pip install it), as well as a working You will need the `sphinx` and python package (pip install it), as well as a working
TeX distribution. TeX distribution.
......
...@@ -8,9 +8,9 @@ To compile SWIFT, you will need the following libraries: ...@@ -8,9 +8,9 @@ To compile SWIFT, you will need the following libraries:
HDF5 HDF5
~~~~ ~~~~
Version 1.8.x or higher is required. Input and output files are stored as HDF5 Version 1.10.x or higher is required. Input and output files are stored as HDF5
and are compatible with the GADGET-2 specification. A parallel-HDF5 build and are compatible with the GADGET-2 specification. A parallel-HDF5 build
and HDF5 > 1.10.x is strongly recommended when running over MPI. and HDF5 >= 1.12.x is recommended when running over MPI.
MPI MPI
~~~ ~~~
...@@ -33,7 +33,15 @@ GSL ...@@ -33,7 +33,15 @@ GSL
~~~ ~~~
The GSL 2.x is required for cosmological integration. The GSL 2.x is required for cosmological integration.
In most cases the configuration script will be able to detect the libraries
installed on the system. If that is not the case, the script can be pointed
towards the libraries' location using the following parameters
.. code-block:: bash
./configure --with-gsl=<PATH-TO-GSL>
and similar for the other libaries.
Optional Dependencies Optional Dependencies
===================== =====================
...@@ -48,10 +56,6 @@ TCmalloc/Jemalloc/TBBmalloc ...@@ -48,10 +56,6 @@ TCmalloc/Jemalloc/TBBmalloc
~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
TCmalloc/Jemalloc/TBBmalloc are used for faster memory allocations when available. TCmalloc/Jemalloc/TBBmalloc are used for faster memory allocations when available.
DOXYGEN
~~~~~~~
You can build documentation for SWIFT with DOXYGEN.
Python Python
~~~~~~ ~~~~~~
To run the examples, you will need python 3 and some of the standard scientific libraries (numpy, matplotlib). To run the examples, you will need python 3 and some of the standard scientific libraries (numpy, matplotlib).
......
...@@ -11,4 +11,4 @@ by creating an issue. ...@@ -11,4 +11,4 @@ by creating an issue.
The code documentation is available on `swiftsim.com/docs <https://swiftsim.com/docs>`_, and The code documentation is available on `swiftsim.com/docs <https://swiftsim.com/docs>`_, and
is also shipped along with the code in the ``docs/RTD`` directory. is also shipped along with the code in the ``docs/RTD`` directory.
This onboarding guide is available online as well on This onboarding guide is available online as well on
`swiftsim.com/onboarding.pdf <http://www.swiftsim.com/onboarding.pdf>`_ `swiftsim.com/onboarding.pdf <https://swift.strw.leidenuniv.nl/onboarding.pdf>`_
...@@ -13,13 +13,13 @@ We use autotools for setup. To get a basic running version of the code (the exec ...@@ -13,13 +13,13 @@ We use autotools for setup. To get a basic running version of the code (the exec
MacOS Specific Oddities MacOS Specific Oddities
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
To build on MacOS you will need to disable compiler warnings due to an To build on MacOS you will need to enable compiler warnings due to an
incomplete implementation of pthread barriers. DOXYGEN also has some issues on incomplete implementation of pthread barriers. DOXYGEN also has some issues on
MacOS, so it is best to leave it out. To configure: MacOS, so it is best to leave it out. To configure:
.. code-block:: bash .. code-block:: bash
./configure --disable-compiler-warnings \ ./configure --enable-compiler-warnings \
--disable-doxygen-doc --disable-doxygen-doc
When using the ``clang`` compiler, the hand-written vectorized routines When using the ``clang`` compiler, the hand-written vectorized routines
......
...@@ -79,15 +79,16 @@ GrackleCooling: ...@@ -79,15 +79,16 @@ GrackleCooling:
max_steps: 1000 max_steps: 1000
convergence_limit: 1e-2 convergence_limit: 1e-2
thermal_time_myr: 0 thermal_time_myr: 0
maximal_density_Hpcm3: -1 # Maximal density (in hydrogen atoms/cm^3) for cooling. Higher densities are floored to this value to ensure grackle works properly when interpolating beyond the cloudy_table maximal density. A value < 0 deactivates this parameter.
GEARStarFormation: GEARStarFormation:
star_formation_mode: agora # default or agora star_formation_mode: agora # default or agora
star_formation_efficiency: 0.01 # star formation efficiency (c_*) star_formation_efficiency: 0.01 # star formation efficiency (c_*)
maximal_temperature: 1e10 # Upper limit to the temperature of a star forming particle maximal_temperature_K: 1e10 # Upper limit to the temperature of a star forming particle
density_threshold_Hpcm3: 10 # Density threshold in Hydrogen atoms/cm3
n_stars_per_particle: 1 n_stars_per_particle: 1
min_mass_frac: 0.5 min_mass_frac: 0.5
density_threshold: 1.67e-23 # Density threashold in g/cm3
GEARPressureFloor: GEARPressureFloor:
......
#!/bin/bash #!/bin/bash
wget http://virgodb.cosma.dur.ac.uk/swift-webstorage/CoolingTables/CloudyData_UVB=HM2012.h5 wget https://virgodb.cosma.dur.ac.uk/swift-webstorage/CoolingTables/CloudyData_UVB=HM2012.h5
...@@ -6,6 +6,5 @@ if [ "$#" -ne 1 ]; then ...@@ -6,6 +6,5 @@ if [ "$#" -ne 1 ]; then
exit exit
fi fi
wget http://virgodb.cosma.dur.ac.uk/swift-webstorage/ICs/AgoraDisk/snap.$1.hdf5 wget https://virgodb.cosma.dur.ac.uk/swift-webstorage/ICs/AgoraDisk/snap.$1.hdf5
mv snap.$1.hdf5 agora_disk.hdf5 mv snap.$1.hdf5 agora_disk.hdf5
Metal advection test for the EAGLE chemistry scheme
In some schemes, like the meshless (gizmo) scheme, particles exchange
masses via fluxes. This example tests whether the metals are correctly
advected with those mass fluxes (for the EAGLE chemistry scheme)
To run this test, compile with:
--with-hydro-dimension=2 --with-hydro=gizmo-mfv --with-riemann-solver=hllc --with-chemistry=EAGLE
Due to the nature of this test, not much mass will be exchanged when running in Lagrangian mode,
and hence not much advection will happen.
To be able to see the effect of the advection, the hydrodynamics must be run in Eulerian mode.
E.g. for gizmo-mvf: uncomment `#define GIZMO_FIX_PARTICLES` in src/const.h.
Expected output when running in Eulerian mode is that the profiles should maintain their shape,
but edges will be blurred due to numerical diffusion.
MetaData:
run_name: advect_metals_EAGLE
# Define the system of units to use internally. # Define the system of units to use internally.
InternalUnitSystem: InternalUnitSystem:
UnitMass_in_cgs: 1 # Grams UnitMass_in_cgs: 1 # Grams
...@@ -9,31 +12,29 @@ InternalUnitSystem: ...@@ -9,31 +12,29 @@ InternalUnitSystem:
# Parameters governing the time integration # Parameters governing the time integration
TimeIntegration: TimeIntegration:
time_begin: 0. # The starting time of the simulation (in internal units). time_begin: 0. # The starting time of the simulation (in internal units).
time_end: 4. # The end time of the simulation (in internal units). time_end: 0.1 # The end time of the simulation (in internal units).
dt_min: 1e-6 # The minimal time-step size of the simulation (in internal units). dt_min: 1e-9 # The minimal time-step size of the simulation (in internal units).
dt_max: 1e-2 # The maximal time-step size of the simulation (in internal units). dt_max: 1e-1 # The maximal time-step size of the simulation (in internal units).
# Parameters governing the snapshots # Parameters governing the snapshots
Snapshots: Snapshots:
basename: square # Common part of the name of output files basename: output # Common part of the name of output files
time_first: 0. # Time of the first output (in internal units) time_first: 0. # Time of the first output (in internal units)
delta_time: 1e-1 # Time difference between consecutive outputs (in internal units) delta_time: 0.1 # Time between snapshots
# Parameters governing the conserved quantities statistics # Parameters governing the conserved quantities statistics
Statistics: Statistics:
delta_time: 1e-2 # Time between statistics output time_first: 0.
delta_time: 1e-1 # Time between statistics output
# Parameters for the hydrodynamics scheme # Parameters for the hydrodynamics scheme
SPH: SPH:
resolution_eta: 1.2348 # Target smoothing length in units of the mean inter-particle separation (1.2348 == 48Ngbs with the cubic spline kernel). resolution_eta: 1.2348 # Target smoothing length in units of the mean inter-particle separation (1.2348 == 48Ngbs with the cubic spline kernel).
CFL_condition: 0.1 # Courant-Friedrich-Levy condition for time integration. CFL_condition: 0.1 # Courant-Friedrich-Levy condition for time integration.
viscosity_alpha: 0.8 # Override for the initial value of the artificial viscosity. In schemes that have a fixed AV, this remains as alpha throughout the run.
# Parameters related to the initial conditions # Parameters related to the initial conditions
InitialConditions: InitialConditions:
file_name: ./square.hdf5 # The file to read file_name: ./advect_metals.hdf5 # The file to read
periodic: 1 periodic: 1 # periodic ICs.
# Parameters related to the equation of state
EoS:
planetary_use_idg_def: 1 # Default ideal gas, material ID 0
#!/bin/bash
wget https://virgodb.cosma.dur.ac.uk/swift-webstorage/ICs/glassPlane_64.hdf5
#!/usr/bin/env python3
###############################################################################
# This file is part of SWIFT.
# Copyright (c) 2023 Yolan Uyttenhove (yolan.uyttenhove@ugent.be)
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published
# by the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
##############################################################################
import math
# ---------------------------------------------------------------------
# Test the diffusion/advection of metals by creating regions with/without
# initial metallicities. Run with EAGLE chemistry.
# ---------------------------------------------------------------------
import numpy as np
import h5py
GAMMA = 5 / 3
RHO = 1
P = 1
VELOCITY = 2.5
ELEMENT_COUNT = 9
outputfilename = "advect_metals.hdf5"
def get_masks(boxsize, pos):
masks = dict()
x = boxsize[0]
y = boxsize[1]
right_half_mask = pos[:, 0] > x / 2
masks["TotalMetallicity"] = right_half_mask
masks["He"] = pos[:, 0] * 2 % x > x / 2
masks["C"] = right_half_mask & (pos[:, 0] < 0.75 * x)
masks["N"] = right_half_mask & (pos[:, 0] > 0.75 * x)
masks["O"] = right_half_mask & (pos[:, 1] > 0.5 * y)
masks["Ne"] = right_half_mask & (pos[:, 1] < 0.5 * y)
masks["Mg"] = right_half_mask & (pos[:, 0] < 0.75 * x) & (pos[:, 1] > 0.5 * y)
masks["Si"] = right_half_mask & (pos[:, 0] > 0.75 * x) & (pos[:, 1] > 0.5 * y)
masks["Fe"] = right_half_mask & (pos[:, 0] < 0.75 * x) & (pos[:, 1] < 0.5 * y)
return masks
def get_element_abundances_metallicity(pos, boxsize):
elements = ["He", "C", "N", "O", "Ne", "Mg", "Si", "Fe"]
abundances = [0.2, 0.2, 0.2, 0.2, 0.2, 0.1, 0.1, 0.1]
masks = get_masks(boxsize, pos)
total_metallicity = np.where(masks["TotalMetallicity"], 0.7, 0.1)
element_abundances = [
np.where(masks[k], v, 0) for k, v in zip(elements, abundances)
]
# Finally add H so that H + He + TotalMetallicity = 1
return (
np.stack(
[1 - element_abundances[0] - total_metallicity] + element_abundances, axis=1
),
total_metallicity,
)
if __name__ == "__main__":
glass = h5py.File("glassPlane_64.hdf5", "r")
parts = glass["PartType0"]
pos = parts["Coordinates"][:]
pos = np.concatenate([pos, pos + np.array([1, 0, 0])])
h = parts["SmoothingLength"][:]
h = np.concatenate([h, h])
glass.close()
# Set up metadata
boxsize = np.array([2.0, 1.0, 1.0])
n_part = len(h)
ids = np.arange(n_part) + 1
# Setup other particle quantities
rho = RHO * np.ones_like(h)
rho[pos[:, 1] < 0.5 * boxsize[1]] *= 0.5
masses = rho * np.prod(boxsize) / n_part
velocities = np.zeros((n_part, 3))
velocities[:, :] = 0.5 * math.sqrt(2) * VELOCITY * np.array([1.0, 1.0, 0.0])
internal_energy = P / (rho * (GAMMA - 1))
# Setup metallicities
element_abundances, metallicities = get_element_abundances_metallicity(pos, boxsize)
# Now open the file and write the data.
file = h5py.File(outputfilename, "w")
# Header
grp = file.create_group("/Header")
grp.attrs["BoxSize"] = boxsize
grp.attrs["NumPart_Total"] = [n_part, 0, 0, 0, 0, 0]
grp.attrs["NumPart_Total_HighWord"] = [0, 0, 0, 0, 0, 0]
grp.attrs["NumPart_ThisFile"] = [n_part, 0, 0, 0, 0, 0]
grp.attrs["Time"] = 0.0
grp.attrs["NumFilesPerSnapshot"] = 1
grp.attrs["MassTable"] = [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
grp.attrs["Flag_Entropy_ICs"] = 0
grp.attrs["Dimension"] = 2
# Units
grp = file.create_group("/Units")
grp.attrs["Unit length in cgs (U_L)"] = 1.0
grp.attrs["Unit mass in cgs (U_M)"] = 1.0
grp.attrs["Unit time in cgs (U_t)"] = 1.0
grp.attrs["Unit current in cgs (U_I)"] = 1.0
grp.attrs["Unit temperature in cgs (U_T)"] = 1.0
# Particle group
grp = file.create_group("/PartType0")
grp.create_dataset("Coordinates", data=pos, dtype="d")
grp.create_dataset("Velocities", data=velocities, dtype="f")
grp.create_dataset("Masses", data=masses, dtype="f")
grp.create_dataset("SmoothingLength", data=h, dtype="f")
grp.create_dataset("InternalEnergy", data=internal_energy, dtype="f")
grp.create_dataset("ParticleIDs", data=ids, dtype="L")
grp.create_dataset("Metallicity", data=metallicities, dtype="f")
grp.create_dataset("ElementAbundance", data=element_abundances, dtype="f")
file.close()
# close up, and we're done!
file.close()
#!/usr/bin/env python3
###############################################################################
# This file is part of SWIFT.
# Copyright (c) 2023 Yolan Uyttenhove (yolan.uyttenhove@ugent.be)
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published
# by the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
##############################################################################
import math
import matplotlib.pyplot as plt
from matplotlib.cm import ScalarMappable
from matplotlib.colors import Normalize
import numpy as np
import unyt
import swiftsimio
from swiftsimio.visualisation import project_gas
from pathlib import Path
from makeIC import VELOCITY
def plot_single(ax_mass, ax_fraction, name, title, data, mass_map, kwargs_inner):
mass_weighted_map = project_gas(data, project=name, **kwargs_inner["projection"])
ax_mass.imshow(mass_weighted_map.in_cgs().value.T, **kwargs_inner["imshow_mass"])
ax_mass.set_title(title)
ax_fraction.imshow(
(mass_weighted_map / mass_map).T, **kwargs_inner["imshow_fraction"]
)
ax_fraction.set_title(title)
ax_mass.axis("off")
ax_fraction.axis("off")
def plot_all(fname, savename):
data = swiftsimio.load(fname)
# Shift coordinates to starting position
velocity = 0.5 * math.sqrt(2) * VELOCITY * np.array([1, 1, 0]) * unyt.cm / unyt.s
data.gas.coordinates -= data.metadata.time * velocity
# Add mass weighted element mass fractions to gas dataset
masses = data.gas.masses
element_mass_fractions = data.gas.element_mass_fractions
data.gas.element_mass_H = element_mass_fractions.hydrogen * masses
data.gas.element_mass_He = element_mass_fractions.helium * masses
data.gas.element_mass_C = element_mass_fractions.carbon * masses
data.gas.element_mass_N = element_mass_fractions.nitrogen * masses
data.gas.element_mass_O = element_mass_fractions.oxygen * masses
data.gas.element_mass_Ne = element_mass_fractions.neon * masses
data.gas.element_mass_Mg = element_mass_fractions.magnesium * masses
data.gas.element_mass_Si = element_mass_fractions.silicon * masses
data.gas.element_mass_Fe = element_mass_fractions.iron * masses
data.gas.total_metal_mass = data.gas.metal_mass_fractions * masses
# Create necessary figures and axes
fig = plt.figure(layout="constrained", figsize=(16, 8))
fig.suptitle(
f"Profiles shifted to starting position after t={data.metadata.time:.2f}",
fontsize=14,
)
fig_ratios, fig_masses = fig.subfigures(2, 1)
fig_ratios.suptitle("Mass ratio of elements")
fig_masses.suptitle("Surface density in elements")
axes_ratios = fig_ratios.subplots(2, 5, sharex=True, sharey=True)
axes_masses = fig_masses.subplots(2, 5, sharex=True, sharey=True)
# parameters for swiftsimio projections
projection_kwargs = {
"region": np.array([0, 2, 0, 1, 0, 1]) * unyt.cm,
"resolution": 500,
"parallel": True,
}
# Parameters for imshow
norm_ratios = Normalize(0, 0.95)
norm_masses = Normalize(0, 0.9)
imshow_fraction_kwargs = dict(norm=norm_ratios, cmap="rainbow")
imshow_mass_kwargs = dict(norm=norm_masses, cmap="turbo")
# Plot the quantities
mass_map = project_gas(data, project="masses", **projection_kwargs)
# Parameters for plotting:
plotting_kwargs = dict(
data=data,
mass_map=mass_map,
kwargs_inner=dict(
projection=projection_kwargs,
imshow_mass=imshow_mass_kwargs,
imshow_fraction=imshow_fraction_kwargs,
),
)
plot_single(
axes_masses[0][0],
axes_ratios[0][0],
"total_metal_mass",
"All metals",
**plotting_kwargs,
)
plot_single(
axes_masses[0][1],
axes_ratios[0][1],
"element_mass_H",
"Hydrogen",
**plotting_kwargs,
)
plot_single(
axes_masses[0][2],
axes_ratios[0][2],
"element_mass_He",
"Helium",
**plotting_kwargs,
)
plot_single(
axes_masses[0][3],
axes_ratios[0][3],
"element_mass_C",
"Carbon",
**plotting_kwargs,
)
plot_single(
axes_masses[0][4],
axes_ratios[0][4],
"element_mass_N",
"Nitrogen",
**plotting_kwargs,
)
plot_single(
axes_masses[1][0],
axes_ratios[1][0],
"element_mass_O",
"Oxygen",
**plotting_kwargs,
)
plot_single(
axes_masses[1][1],
axes_ratios[1][1],
"element_mass_Ne",
"Neon",
**plotting_kwargs,
)
plot_single(
axes_masses[1][2],
axes_ratios[1][2],
"element_mass_Mg",
"Magnesium",
**plotting_kwargs,
)
plot_single(
axes_masses[1][3],
axes_ratios[1][3],
"element_mass_Si",
"Silicon",
**plotting_kwargs,
)
plot_single(
axes_masses[1][4],
axes_ratios[1][4],
"element_mass_Fe",
"Iron",
**plotting_kwargs,
)
# Add Colorbars
cb_masses = fig_masses.colorbar(
ScalarMappable(**imshow_mass_kwargs), shrink=0.75, pad=0.01, ax=axes_masses
)
cb_ratios = fig_ratios.colorbar(
ScalarMappable(**imshow_fraction_kwargs), shrink=0.75, pad=0.01, ax=axes_ratios
)
cb_masses.ax.set_ylabel("Surface density (g/cm^2)", rotation=270, labelpad=15)
cb_ratios.ax.set_ylabel("Mass ratio", rotation=270, labelpad=15)
# Save output
fig.savefig(savename, dpi=300)
if __name__ == "__main__":
cwd = Path(__file__).parent
print("Plotting metals for output_0000.hdf5...")
plot_all(cwd / "output_0000.hdf5", savename=cwd / "metal_advection_0000.png")
print("Plotting metals for output_0001.hdf5...")
plot_all(cwd / "output_0001.hdf5", savename=cwd / "metal_advection_0001.png")
print("Done!")
#!/bin/bash
# make run.sh fail if a subcommand fails
set -e
set -o pipefail
if [ ! -e glassPlane_64.hdf5 ]
then
echo "Fetching initial glass file ..."
./getGlass.sh
fi
if [ ! -f 'advect_metals.hdf5' ]; then
echo "Generating ICs"
python3 makeIC.py
fi
# Run SWIFT (must be compiled with --with-chemistry=EAGLE)
../../../swift \
--hydro --threads=4 advect_metals.yml 2>&1 | tee output.log
python3 runSanityChecksAdvectedMetals.py
python3 plotAdvectedMetals.py
#!/usr/bin/env python3
###############################################################################
# This file is part of SWIFT.
# Copyright (c) 2023 Yolan Uyttenhove (yolan.uyttenhove@ugent.be)
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published
# by the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
##############################################################################
from pathlib import Path
import numpy as np
import swiftsimio
def test(name):
def test_decorator(test_func):
def test_runner(*args, **kwargs):
try:
test_func(*args, **kwargs)
except Exception as e:
print(f"\tTest {name} failed!")
raise e
else:
print(f"\tTest {name} \u2705")
return test_runner
return test_decorator
def approx_equal(a, b, threshold=0.001):
return 2 * abs(a - b) / (abs(a) + abs(b)) < threshold
@test("mass fractions sum to 1")
def test_sum_mass_fractions(data):
metal_fractions = data.gas.metal_mass_fractions
h_fraction = data.gas.element_mass_fractions.hydrogen
he_fraction = data.gas.element_mass_fractions.helium
total = metal_fractions + he_fraction + h_fraction
assert np.all(approx_equal(total, 1))
@test("total metal mass conservation")
def test_total_metal_mass_conservation(data_start, data_end):
def metal_mass(data):
return data.gas.masses * data.gas.metal_mass_fractions
assert approx_equal(np.sum(metal_mass(data_start)), np.sum(metal_mass(data_end)))
def element_mass(data, element_name):
return data.gas.masses * getattr(data.gas.element_mass_fractions, element_name)
@test("hydrogen mass conservation")
def test_h_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "hydrogen")),
np.sum(element_mass(data_end, "hydrogen")),
)
@test("helium mass conservation")
def test_he_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "helium")),
np.sum(element_mass(data_end, "helium")),
)
@test("carbon mass conservation")
def test_c_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "carbon")),
np.sum(element_mass(data_end, "carbon")),
)
@test("nitrogen mass conservation")
def test_n_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "nitrogen")),
np.sum(element_mass(data_end, "nitrogen")),
)
@test("oxygen mass conservation")
def test_o_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "oxygen")),
np.sum(element_mass(data_end, "oxygen")),
)
@test("neon mass conservation")
def test_ne_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "neon")), np.sum(element_mass(data_end, "neon"))
)
@test("magnesium mass conservation")
def test_mg_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "magnesium")),
np.sum(element_mass(data_end, "magnesium")),
)
@test("silicon mass conservation")
def test_si_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "silicon")),
np.sum(element_mass(data_end, "silicon")),
)
@test("iron mass conservation")
def test_fe_mass_conservation(data_start, data_end):
assert approx_equal(
np.sum(element_mass(data_start, "iron")), np.sum(element_mass(data_end, "iron"))
)
if __name__ == "__main__":
print("Running sanity checks...")
cwd = Path(__file__).parent
start = swiftsimio.load(cwd / "output_0000.hdf5")
end = swiftsimio.load(cwd / "output_0001.hdf5")
test_sum_mass_fractions(end)
test_total_metal_mass_conservation(start, end)
test_h_mass_conservation(start, end)
test_he_mass_conservation(start, end)
test_c_mass_conservation(start, end)
test_n_mass_conservation(start, end)
test_o_mass_conservation(start, end)
test_ne_mass_conservation(start, end)
test_mg_mass_conservation(start, end)
test_si_mass_conservation(start, end)
test_fe_mass_conservation(start, end)
print("Done!")
Metal advection test for the GEAR/AGORA chemistry schemes
In some schemes, like the meshless (gizmo) scheme, particles exchange
masses via fluxes. This example tests whether the metals are correctly
advected with those mass fluxes.
To run this test with GEAR, compile with:
--with-hydro-dimension=2 --with-hydro=gizmo-mfv --with-riemann-solver=hllc --with-chemistry=GEAR_X
with X the desired number of elements. The number of elements must be also be set in the makeIC.py script
and must be the equal to one used in the compilation flag. The default value is 4.
To run this test with AGORA, compile with:
--with-hydro-dimension=2 --with-hydro=gizmo-mfv --with-riemann-solver=hllc --with-chemistry=AGORA
NOTE: The AGORA scheme only traces Fe mass and total metal mass, so the number of elements in makeIC.py must be set
to the value of 2.
Due to the nature of this test, not much mass will be exchanged when running in Lagrangian mode,
and hence not much advection will happen.
To be able to see the effect of the advection, the hydrodynamics must be run in Eulerian mode.
E.g. for gizmo-mvf: uncomment `#define GIZMO_FIX_PARTICLES` in src/const.h.
Expected output when running in Eulerian mode is that the profiles should maintain their shape,
but edges will be blurred due to numerical diffusion.