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
  • 840-unit-test-testtimeline-fails
  • 875-wendland-c6-missing-neighbour-contributions
  • 887-code-does-not-compile-with-parmetis-installed-locally-but-without-metis
  • CubeTest
  • FS_Del
  • GEARRT_Iliev1
  • GEARRT_Iliev3
  • GEARRT_Iliev4
  • GEARRT_Iliev5
  • GEARRT_Iliev5-fixed-nr-subcycles
  • GEARRT_Iliev7
  • GEARRT_Iliev_static
  • GEARRT_Ivanova
  • GEARRT_fixed_nr_subcycles
  • GEARRT_injection_tests_Iliev0
  • GPU_swift
  • GrackleCoolingUpdates2
  • Lambda-T-table
  • MAGMA2
  • MAGMA2_matthieu
  • MHD_FS
  • MHD_FS_TESTs
  • MHD_FS_VP_AdvectGauge
  • MHD_Orestis
  • MHD_canvas
  • MHD_canvas_RF_128
  • MHD_canvas_RF_growth_rate
  • MHD_canvas_RobertsFlow
  • MHD_canvas_SPH_errors
  • MHD_canvas_matthieu
  • MHD_canvas_nickishch
  • MHD_canvas_nickishch_Lorentz_force_test
  • MHD_canvas_nickishch_track_everything
  • MHD_canvas_sid
  • OAK/CPAW_updates
  • OAK/LoopAdvectionTest
  • OAK/adaptive_divv
  • OAK/kinetic_dedner
  • REMIX_cosmo
  • RT_dualc
  • RT_recombination_radiation
  • RT_test_mladen
  • SIDM
  • SIDM_wKDSDK
  • SNdust
  • SPHM1RT_CosmologicalStromgrenSphere
  • SPHM1RT_bincheck
  • SPHM1RT_smoothedRT
  • TangoSIDM
  • TestPropagation3D
  • Test_fixedhProb
  • activate_fewer_comms
  • active_h_max_optimization
  • adaptive_softening_Lieuwe
  • add_2p5D
  • add_black_holes_checks
  • adding_sidm_to_master
  • agn_crksph
  • agn_crksph_subtask_speedup
  • amd-optimization
  • arm_vec
  • automatic_tasks
  • better_ray_RNG
  • black_holes_accreted_angular_momenta_from_gas
  • burkert-potential
  • c11
  • c11_atomics_copy
  • cancel_all_sorts
  • cell_exchange_improvements
  • cell_types
  • cherry-pick-cd1c39e0
  • comm_tasks_are_special
  • conduction_velocities
  • cpp-fixes
  • cuda_test
  • darwin/adaptive_softening
  • darwin/gear_chemistry_fluxes
  • darwin/gear_mechanical_feedback
  • darwin/gear_preSN_feedback
  • darwin/gear_radiation
  • darwin/simulations
  • darwin/sink_formation_proba
  • darwin/sink_mpi
  • darwin/sink_mpi_physics
  • dead-time-stats
  • derijcke_cooling
  • dev_cms
  • do-not-activate-empty-star-pairs
  • domain_zoom_nometis
  • drift_flag_debug_check
  • driven_turbulence
  • driven_turbulence_forcings
  • engineering
  • eos_updates
  • evrard_disc
  • expand_fof_2022
  • explict_bkg_cdim
  • fewer_gpart_comms
  • fewer_star_comms
  • fewer_timestep_comms_no_empty_pairs
  • v0.0
  • v0.1
  • v0.1.0-pre
  • v0.2.0
  • v0.3.0
  • v0.4.0
  • v0.5.0
  • v0.6.0
  • v0.7.0
  • v0.8.0
  • v0.8.1
  • v0.8.2
  • v0.8.3
  • v0.8.4
  • v0.8.5
  • v0.9.0
  • v1.0.0
  • v2025.01
  • v2025.04
119 results

Target

Select target project
  • dc-oman1/swiftsim
  • swift/swiftsim
  • pdraper/swiftsim
  • tkchan/swiftsim
  • dc-turn5/swiftsim
5 results
Select Git revision
  • GPU_swift
  • Nifty-Clutser-Solution
  • Rsend_repart
  • Subsize
  • active_h_max
  • add-convergence-scripts
  • add_dehnen_aly_density_correction
  • add_particles_debug
  • advanced_opening_criteria
  • arm_vec
  • assume_for_gcc
  • atomic_read_writes
  • back_of_the_queue
  • c11_atomics
  • c11_atomics_copy
  • c11_standard
  • cache_time_bin
  • comm_tasks_are_special
  • cpp
  • cuda_test
  • dumper-thread
  • eagle-cooling-improvements
  • energy_logger
  • engineering
  • evrard_disc
  • ewald_correction
  • extra_EAGLE_EoS
  • feedback_after_hydro
  • gear
  • gear_feedback
  • gear_star_formation
  • generic_cache
  • genetic_partitioning2
  • gizmo
  • gizmo_mfv_entropy
  • gpart_assignment_speedup
  • gravity_testing
  • hydro_validation
  • isolated_galaxy_update
  • ivanova
  • ivanova-dirty
  • kahip
  • local_part
  • logger_index_file
  • logger_restart
  • logger_skip_fields
  • logger_write_hdf5
  • master
  • memalign-test
  • more_task_info
  • move_configure_to_m4
  • mpi-one-thread
  • mpi-packed-parts
  • mpi-send-subparts
  • mpi-send-subparts-vector
  • mpi-subparts-vector-grav
  • mpi-testsome
  • mpi-threads
  • multi_phase_bh
  • new_cpp
  • non-periodic-repart
  • non-periodic-repart-update
  • numa_alloc
  • numa_awareness
  • ontheflyimages
  • optimized_entropy_floor
  • parallel_compression
  • paranoid
  • planetary_ideal_gas
  • pyswiftsim
  • recurse_less_in_sort
  • recursive_star_ghosts
  • remove_long_long
  • reorder_rebuild
  • reverted_grav_depth_logic
  • reweight-fitted-costs
  • reweight-scaled-costs
  • sampled_stellar_evolution
  • scheduler_determinism
  • scotch
  • search-window-tests
  • signal-handler-dump
  • simba-stellar-feedback
  • skeleton
  • smarter_sends
  • snipes_data
  • sort-soa
  • spiral_potential
  • star_formation
  • stellar_disc_example
  • stf_output_dirs
  • streaming_io
  • subcell_sort
  • thread-dump-extract-waiters
  • threadpool_rmapper
  • timestep_limiter_update
  • top_level_cells
  • traphic
  • update-gravity
  • update_brute_force_checks
  • v0.0
  • v0.1
  • v0.1.0-pre
  • v0.2.0
  • v0.3.0
  • v0.4.0
  • v0.5.0
  • v0.6.0
  • v0.7.0
  • v0.8.0
  • v0.8.1
  • v0.8.2
  • v0.8.3
  • v0.8.4
114 results
Show changes
Showing
with 742 additions and 58 deletions
......@@ -13,7 +13,7 @@ configuration flag.
A description of the available options of the below flags can be found by using
``./configure --help``.
``--with-hydro=gadget2``
``--with-hydro=sphenix``
~~~~~~~~~~~~~~~~~~~~~~~~
There are several hydrodynamical schemes available in SWIFT. You can choose
between them at compile-time with this option.
......
......@@ -9,7 +9,7 @@ to get up and running with some examples, and then build your own initial condit
for running.
Also, you might want to consult our onboarding guide (available at
http://www.swiftsim.com/onboarding.pdf) if you would like something to print out
https://swift.strw.leidenuniv.nl/onboarding.pdf) if you would like something to print out
and keep on your desk.
.. toctree::
......
.. Running an Example
Josh Borrow, 5th April 2018
Mladen Ivkovic, Jan 2023
Running an Example
==================
Now that you have built the code, you will want to run an example! To do that,
you need to follow the following instructions (requires ``python2`` or
``python3`` with the ``h5py`` and other standard scientific packages, as well
as ``wget`` for grabbing the glass).
Now that you have built the code, you will want to run an example!
Let's start with a hydrodynamics only example, the 3D Sod Shock.
Sod Shock
~~~~~~~~~
To run the Sod Shock example, you need to follow the following instructions
(requires ``python3`` with the ``h5py`` and other standard scientific packages,
as well as ``wget`` for grabbing the glass).
.. code-block:: bash
cd examples/HydroTests/SodShock_3D
./getGlass.sh
python makeIC.py
python3 makeIC.py
../swift --hydro --threads=4 sodShock.yml
python plotSolution.py 1
python3 plotSolution.py 1
This will run the 'SodShock' in 3D and produce a nice plot that shows you
how the density has varied. Try running with GIZMO-MFV (this will take
_significantly_ longer than with SPH) to see the difference. For that, you
*significantly* longer than with SPH) to see the difference. For that, you
will need to reconfigure with the following options:
.. code-block:: bash
......@@ -29,9 +37,55 @@ will need to reconfigure with the following options:
--with-hydro=gizmo-mfv \
--with-riemann-solver=hllc
To see the results that you should get, you should check out our developer
wiki at https://gitlab.cosma.dur.ac.uk/swift/swiftsim/wikis/Sod_3D.
If you don't get these results, please contact us on our GitHub page at
https://github.com/SWIFTSIM/swiftsim/issues.
Small Cosmological Volume
~~~~~~~~~~~~~~~~~~~~~~~~~
As a second example, we run a small cosmolgical
volume containing dark matter only starting at redshift :math:`z = 50`.
Like for the Sod Shock example, it suffices to configure (``./configure``) and
compile (``make``) the code without any extra flags.
After downloading the initial conditions, we run the code with cosmology and
self-gravity:
.. code-block:: bash
cd examples/SmallCosmoVolume/SmallCosmoVolume_DM
./getIC.sh
../../../swift --cosmology --self-gravity --threads=8 small_cosmo_volume_dm.yml
We can plot the solution with the included python script
as follows:
.. code-block:: bash
python3 plotProjection.py 31
The ``plotProjection.py`` script requires the `swiftsimio <https://swiftsimio.readthedocs.io/en/latest/>`_
library, which is a dedicated and maintained visualisation and analysis
library for SWIFT.
An additional example containing both baryonic and dark matter is
``examples/SmallCosmoVolume/SmallCosmoVolume_hydro``. To run with
hydrodynamics, the ``--hydro`` flag needs to be provided as well:
.. code-block:: bash
cd examples/SmallCosmoVolume/SmallCosmoVolume_hydro
./getIC.sh
../../../swift --cosmology --self-gravity --hydro --threads=8 small_cosmo_volume.yml
The solution can again be plotted using the ``plotProjection.py`` script.
......@@ -29,13 +29,14 @@ system (i.e. over MPI on several nodes). Here are some recommendations:
+ Ensure that you compile with ParMETIS or METIS. These are required if
want to load balance between MPI ranks.
Your batch script should look something like the following (to run on 16 nodes
each with 2x16 core processors for a total of 512 cores):
Your batch script should look something like the following (to run on 8 nodes each
with 2x18 core processors for a total of 288 cores):
.. code-block:: bash
#SBATCH -N 16 # Number of nodes to run on
#SBATCH --tasks-per-node=2 # This system has 2 chips per node
mpirun -np 32 swift_mpi --threads=16 --pin parameter.yml
#SBATCH -N 8 # Number of nodes to run on
#SBATCH --tasks-per-node=2 # This system has 2 chips per node
mpirun -n 16 swift_mpi --threads=18 --pin parameter.yml
......@@ -6,6 +6,23 @@ Special modes
SWIFT comes with a few special modes of operating to perform additional tasks.
Disabling particle types
~~~~~~~~~~~~~~~~~~~~~~~~
To save some meory, SWIFT can be compiled with support for reduced number of
particles. This will make many structures in the code discard the variables
related to these particles and hence lead to a leaner code. This can be useful,
for instance, for very large DMO runs.
This is achieved by compiling with one or more of these:
* ``--with-hydro=none``
* ``--with-stars=none``
* ``--with-sinks=none``
* ``--with-black-holes=none``
The code will then naturally complain if particles of the cancelled types are
found in the simulation.
Static particles
~~~~~~~~~~~~~~~~
......@@ -29,6 +46,31 @@ in the sampling of the halo is reduced.
Note also that this does not affect the hydrodynamic forces. This mode is
purely designed for gravity-only accuracy tests.
Besides the pure gravity mode, swift also has the boundary particle mode,
this mode turns off both the gravity forces and hydro forces for all
particles. Because gas particles only receive hydro this mode only impacts
gas particles more strictly than other particles. This mode can be
activated using ``--enable-boundary-particles=N``. This will zero the
gravitational and hydrodynamic *accelerations* of all particles with ``id``
(strictly) lower than ``N`` at every time-step. Still if particles have an
initial velocity they will keep moving at that speed. This compilation
option also activates ``--enable-no-gravity-below-id=N``.
Typical use cases are hydrodynamical experiments that have boundaries.
Both options discussed above only cancel accelerations and have no impact
on what can happen in any code module that directly changes the velocity of
the boundary or no gravity particles. An example of this is momentum
injection of stellar winds for example. If we additionally want to keep the
boundary particles fixed at the same position for the whole simulation we can
use the ``--enable-fixed-boundary-particles=N`` compile option, this option
explicitly sets the velocity of the boundary particles to zero every time
step on top of also zeroing the accelerations.
A typical use cases is an idealized setup in which we have a black hole in
the centre of a galaxy that accretes gas but is not allowed to move from
the momentum recoil of the gas it swallows.
Gravity glasses
~~~~~~~~~~~~~~~
......@@ -41,3 +83,33 @@ this mode, configure the code with ``--enable-glass-making``.
Note that this will *not* generate the initial random distribution of
particles. An initial condition file with particles still has to be provided.
Gravity force checks
~~~~~~~~~~~~~~~~~~~~
To test the accuracy of the gravitational forces approximated by the code,
SWIFT can be configured with the option to additionally compute the "exact"
forces for each active particle during each timestep. Here the exact forces are
simply the Newtonian sum, i.e.,
:math:`\vec{F}_{i,j} = \sum^{n}_{i \neq j} \frac{G m_i m_j}{\vec{r}_{i,j}^2}.`
To run SWIFT in this mode, configure the code with
``--enable-gravity-force-checks=N``, which means that the exact forces will be
computed for every :math:`N^{th}` particle based on their ID (i.e., to compute
the exact forces for all particles set ``N=1``).
Two ``.dat`` files will be output during each timestep, one containing the forces
(really it is the accelerations that are stored) as computed by ``_swift_``, and
another containing the ``_exact_`` forces. The total force (``a_swift``), along
with the contributed force from each component of the tree (P2P, M2P and M2L)
and the FFT mesh if periodic (PM) is stored (i.e., ``a_swift[0]`` = ``a_p2p[0]`` +
``a_m2p[0]`` + ``a_m2l[0]`` + ``a_PM[0]``, for the :math:`x` component). In addition,
the number of particles contributing to each force component is also stored
(these numbers will add up to :math:`n-1`).
This mode will slow down the code *considerably*, and it is not recommended to
be run on problems with more than :math:`10^{5}` particles when
``--enable-gravity-force-checks=1``. For larger runs, sampling a sub-set of
particles via the argument ``N`` of the configuration option is recommended.
This mode must be run on a single node/rank, and is primarily designed for pure
gravity tests (i.e., DMO).
......@@ -7,6 +7,35 @@ What about MPI? Running SWIFT on more than one node
After compilation, you will be left with two binaries. One is called ``swift``,
and the other ``swift_mpi``. Current wisdom is to run ``swift`` if you are only
using one node (i.e. without any interconnect), and one MPI rank per NUMA
region using ``swift_mpi`` for anything larger. You will need some GADGET-2
HDF5 initial conditions to run SWIFT, as well as a compatible yaml
parameter file.
region using ``swift_mpi`` for anything larger. You will need some initial
conditions in the GADGET-2 HDF5 format (see :ref:`Initial Conditions <Initial_Conditions_label>`)
to run SWIFT, as well as a compatible :ref:`yaml parameter file <Parameter_File_label>`.
SLURM Submission Script Example
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Below is an example submission script for the SLURM
batch system. This runs SWIFT with thread pinning, SPH,
and self-gravity.
.. code-block:: bash
#SBATCH --partition=<queue>
#SBATCH --account-name=<groupName>
#SBATCH --job-name=<jobName>
#SBATCH --nodes=<nNodes>
#SBATCH --ntasks-per-node=<nMPIRank>
#SBATCH --cpus-per-task=<nThreadsPerMPIRank>
#SBATCH --output=outFile.out
#SBATCH --error=errFile.err
## expected runtime
#SBATCH --time-<hh>:<mm>:<ss>
./swift_mpi --pin --threads=<nThreadsPerMPIRank> \
--hydro --self-gravity \
parameter_file.yml
.. Adding Hydro Schemes
Matthieu Schaller, 23/02/2024
.. _adaptive_softening:
Adaptive Softening
==================
.. toctree::
:maxdepth: 2
:hidden:
:caption: Contents:
We implement the method of Price & Monaghan (2007). This add correction terms to
the SPH equations of motions to account for the change in energy and momentum
created by the change in gravitationl potential generated by the change of
softening. The softening length is tied to the gas' smoothing length and is
thus adapting with the changes in density field. To use adaptive softening, use
.. code-block:: bash
./configure --with-adaptive-softening=yes
The adaptive softening scheme is implemented for all the SPH schemes above but
only for the Wendland-C2 kernel as it is the kernel used for the gravity
softening throughout the code.
......@@ -11,10 +11,22 @@ includes:
+ Pressure-Energy SPH
+ Thermal diffusion following Price (2012)
+ A simplified version of the 'Inviscid SPH' artificial viscosity
(Cullen & Denhen 2010).
(Cullen & Denhen 2010), with a Balsara switch.
More information will be made available in a forthcoming publication.
The simplified version of the 'Inviscid SPH' artificial viscosity calculates
the time differential of the velocity divergence explicitly, using the value
from the previous step. We also use the Balsara switch instead of the improved
neighbour-based limiter from Cullen & Dehnen 2010, to avoid matrix calculations.
To configure with this scheme, use
.. code-block:: bash
./configure --with-hydro=anarchy-pu --with-kernel=quintic-spline --disable-hand-vec
The scheme as-implemented in SWIFT is slightly different to the one
implemented in the original EAGLE code:
......@@ -26,8 +38,27 @@ implemented in the original EAGLE code:
+ Recommended kernel changed from Wendland-C2 (with 100 Ngb) to
Quintic Spline (with ~82 Ngb).
The parameters available for this scheme, and their defaults, are:
.. code-block:: yaml
SPH:
viscosity_alpha: 0.1 # Initial value for the alpha viscosity
viscosity_length: 0.25 # Viscosity decay length (in terms of sound-crossing time)
# These are enforced each time-step
viscosity_alpha_max: 2.0 # Maximal allowed value for the viscosity alpha
viscosity_alpha_min: 0.0 # Minimal allowed value for the viscosity alpha
diffusion_alpha: 0.0 # Initial value for the diffusion alpha
diffusion_beta: 0.01 # Timescale to raise the diffusion coefficient over
# (decay is on the sound-crossing time)
# These are enforced each time-step
diffusion_alpha_max: 1.0
diffusion_alpha_min: 0.0
.. code-block:: bash
./configure --with-hydro=anarchy-pu --with-kernel=quintic-spline --disable-hand-vec
There is also a compile-time parameter, ``viscosity_beta`` that we set to
3.0. During feedback events, the viscosity is set to the compile-time
``hydro_props_default_viscosity_alpha_feedback_reset = 2.0`` and the
diffusion is set to ``hydro_props_default_diffusion_alpha_feedback_reset =
0.0``. These can be changed in ``src/hydro/AnarchyPU/hydro_parameters.h``.
.. GASOLINE-SPH
Josh Borrow 27 March 2021
Gasoline-2 SPH
==============
This scheme very closely follows the paper by Wadsley et al. (2017).
It includes a "Geometric Density Average Force" equation of motion,
explicit corrections for gradients, a Cullen & Dehnen (2010) style
artificial viscosity and switch, and an artificial conduction
scheme based on the local shear tensor.
The equation of motion:
.. math::
\frac{\mathrm{d} \mathbf{v}_{i}}{\mathrm{d} t}=-\sum_{j} m_{j}\left(\frac{P_{i}+P_{j}}{\rho_{i} \rho_{j}}+\Pi_{i j}\right) \nabla_{i} \bar{W}_{i j}
.. math::
\frac{\mathrm{d} u_{i}}{\mathrm{d} t}=\sum_{j} m_{j}\left(\frac{P_{i}}{\rho_{i} \rho_{j}}+\frac{1}{2} \Pi_{i j}\right) \mathbf{v}_{i j} \cdot \nabla_{i} \bar{W}_{i j}
with
.. math::
\nabla_{i} \bar{W}_{i j}=\frac{1}{2} f_{i} \nabla_{i} W\left(r_{i j}, h_{i}\right)+\frac{1}{2} f_{j} \nabla_{j} W\left(r_{i j}, h_{j}\right)
.. math::
f_{i}=\frac{\sum_{j} \frac{m_{j}}{\rho_{i}} \mathbf{r}_{i j}^{2} W^{\prime}\left(\frac{r_{i j}}{h_{i}}\right)}{\sum_{j} \frac{m_{j}}{\rho_{j}} \mathbf{r}_{i j}^{2} W^{\prime}\left(\frac{r_{i j}}{h_{i}}\right)}
For more information, please see the Wadsley et al. (2017) paper. Note that we do not
use the exact same time-stepping condition, but instead use the same as the other
schemes in SWIFT.
To configure with this scheme, use
.. code-block:: bash
./configure --with-hydro=gasoline --with-kernel=wendland-C4 --disable-hand-vec
The parameters available for this scheme, and their defaults, are:
.. code-block:: yaml
SPH:
viscosity_alpha: 0.1 # Initial value for the alpha viscosity
viscosity_length: 0.2 # Viscosity decay length (in terms of sound-crossing time)
# These are enforced each time-step
viscosity_alpha_max: 2.0 # Maximal allowed value for the viscosity alpha
viscosity_alpha_min: 0.0 # Minimal allowed value for the viscosity alpha
diffusion_coefficient: 0.03 # Controls the diffusion rate
There is also a compile-time parameter, ``viscosity_beta`` that we set to
3.0. During feedback events, the viscosity is set to the compile-time
``hydro_props_default_viscosity_alpha_feedback_reset = 2.0`` and the
diffusion is set to ``hydro_props_default_diffusion_rate_feedback_reset =
0.0``. These can be changed in ``src/hydro/Gasoline/hydro_parameters.h``.
......@@ -25,3 +25,6 @@ this at compile-time with the following configuration flags:
.. code-block:: bash
./configure --with-hydro="gizmo-mfm" --with-riemann-solver="hllc"
These schemes should be treated as experimental and not used for production runs.
\ No newline at end of file
......@@ -9,8 +9,8 @@ Pressure-Entropy SPH
:hidden:
:caption: Contents:
A pressure-entropy SPH scheme is available in SWIFT, inspired by Hopkins 2013.
This includes a Monaghan AV scheme and a Balsara switch.
A Pressure-Entropy SPH scheme is available in SWIFT, inspired by Hopkins 2013.
This includes a fixed Monaghan AV scheme and a Balsara switch.
.. code-block:: bash
......@@ -18,6 +18,15 @@ This includes a Monaghan AV scheme and a Balsara switch.
./configure --with-hydro="pressure-entropy"
The parameters available for this scheme, and their defaults, are:
.. code-block:: yaml
SPH:
viscosity_alpha: 0.8 # Fixed value for the alpha viscosity
Pressure-Energy SPH
===================
......@@ -29,8 +38,38 @@ scheme it includes a Monaghan AV scheme and a Balsara switch.
./configure --with-hydro="pressure-energy"
Both of the above schemes use a very simple, fixed artificial viscosity, only
the ``SPH:viscosity_alpha`` parameter has any effect for this scheme. This will
change the strength of the artificial viscosity throughout the simulation, and
has a default of 0.8.
The parameters available for this scheme, and their defaults, are:
.. code-block:: yaml
SPH:
viscosity_alpha: 0.8 # Fixed value for the alpha viscosity
There is a variant of this implementation that includes a Morris & Monaghan
(1997) variable artificial viscosity that aims to reduce disappation away
from strong shocks. This implementation also includes a Balsara switch.
To use this scheme, you should use:
.. code-block:: bash
./configure --with-hydro="pressure-energy-monaghan"
The parameters available for this scheme, and their defaults, are:
.. code-block:: yaml
SPH:
viscosity_alpha: 0.8 # Initial value for the alpha viscosity
viscosity_length: 0.25 # Viscosity decay length (in terms of sound-crossing time)
# These are enforced each time-step
viscosity_alpha_max: 2.0 # Maximal allowed value for the viscosity alpha
viscosity_alpha_min: 0.1 # Minimal allowed value for the viscosity alpha
There is also a compile-time parameter, ``viscosity_beta`` that we set to
3.0. During feedback events, the viscosity is set to the compile-time
``hydro_props_default_viscosity_alpha_feedback_reset = 2.0``. These can be
changed in ``src/hydro/AnarchyPU/hydro_parameters.h``.
digraph task_dep {
# Header
compound=true;
ratio=1.41;
node[nodesep=0.15, fontsize=30, penwidth=3.];
edge[fontsize=0, penwidth=0.5];
ranksep=0.8;
# Special tasks
sort[color=blue3];
self_density[color=blue3];
self_gradient[color=blue3];
self_force[color=blue3];
self_stars_density[color=darkorange1];
pair_density[color=blue3];
pair_gradient[color=blue3];
pair_force[color=blue3];
pair_limiter[color=black];
pair_stars_density[color=darkorange1];
sub_self_density[color=blue3];
sub_self_gradient[color=blue3];
sub_self_force[color=blue3];
sub_self_limiter[color=black];
sub_self_stars_density[color=darkorange1];
sub_pair_density[color=blue3];
sub_pair_gradient[color=blue3];
sub_pair_force[color=blue3];
sub_pair_limiter[color=black];
sub_pair_stars_density[color=darkorange1];
ghost_in[style=filled,fillcolor=grey90,color=blue3];
ghost[color=blue3];
ghost_out[style=filled,fillcolor=grey90,color=blue3];
extra_ghost[color=blue3];
drift_part[color=blue3];
end_hydro_force[color=blue3];
send_gradient[shape=diamond,style=filled,fillcolor=azure,color=blue3];
send_xv[shape=diamond,style=filled,fillcolor=azure,color=blue3];
send_rho[shape=diamond,style=filled,fillcolor=azure,color=blue3];
recv_gradient[shape=diamond,style=filled,fillcolor=azure,color=blue3];
recv_tend_part[shape=diamond,style=filled,fillcolor=azure,color=blue3];
recv_xv[shape=diamond,style=filled,fillcolor=azure,color=blue3];
recv_rho[shape=diamond,style=filled,fillcolor=azure,color=blue3];
cooling_in[style=filled,fillcolor=grey90,color=blue3];
# Clusters
subgraph clusterDensity {
label="";
bgcolor="grey99";
pair_density;
self_density;
sub_pair_density;
sub_self_density;
};
subgraph clusterForce {
label="";
bgcolor="grey99";
pair_force;
self_force;
sub_pair_force;
sub_self_force;
};
subgraph clusterGradient {
label="";
bgcolor="grey99";
pair_gradient;
self_gradient;
sub_pair_gradient;
sub_self_gradient;
};
subgraph clusterStarsDensity {
label="";
bgcolor="grey99";
pair_stars_density;
self_stars_density;
sub_pair_stars_density;
sub_self_stars_density;
};
subgraph clusterTimestep_limiter {
label="";
bgcolor="grey99";
pair_limiter;
self_limiter;
sub_pair_limiter;
sub_self_limiter;
};
# Dependencies
sort->pair_density[fontcolor=blue3,color=blue3]
sort->pair_stars_density[fontcolor=blue3,color=blue3]
sort->recv_rho[fontcolor=blue3,color=blue3]
sort->sub_self_density[fontcolor=blue3,color=blue3]
sort->sub_self_stars_density[fontcolor=blue3,color=blue3]
sort->sub_pair_density[fontcolor=blue3,color=blue3]
sort->sub_pair_stars_density[fontcolor=blue3,color=blue3]
self_density->ghost_in[fontcolor=blue3,color=blue3]
self_gradient->extra_ghost[fontcolor=blue3,color=blue3]
self_force->end_hydro_force[fontcolor=blue3,color=blue3]
pair_density->ghost_in[fontcolor=blue3,color=blue3]
pair_density->recv_rho[fontcolor=blue3,color=blue3]
pair_gradient->extra_ghost[fontcolor=blue3,color=blue3]
pair_gradient->recv_gradient[fontcolor=blue3,color=blue3]
pair_force->end_hydro_force[fontcolor=blue3,color=blue3]
pair_force->recv_tend_part[fontcolor=blue3,color=blue3]
sub_self_density->ghost_in[fontcolor=blue3,color=blue3]
sub_self_gradient->extra_ghost[fontcolor=blue3,color=blue3]
sub_self_force->end_hydro_force[fontcolor=blue3,color=blue3]
sub_pair_density->ghost_in[fontcolor=blue3,color=blue3]
sub_pair_density->recv_rho[fontcolor=blue3,color=blue3]
sub_pair_gradient->extra_ghost[fontcolor=blue3,color=blue3]
sub_pair_gradient->recv_gradient[fontcolor=blue3,color=blue3]
sub_pair_force->end_hydro_force[fontcolor=blue3,color=blue3]
sub_pair_force->recv_tend_part[fontcolor=blue3,color=blue3]
ghost_in->ghost[fontcolor=blue3,color=blue3]
ghost->ghost_out[fontcolor=blue3,color=blue3]
ghost_out->self_gradient[fontcolor=blue3,color=blue3]
ghost_out->pair_gradient[fontcolor=blue3,color=blue3]
ghost_out->send_rho[fontcolor=blue3,color=blue3]
ghost_out->sub_self_gradient[fontcolor=blue3,color=blue3]
ghost_out->sub_pair_gradient[fontcolor=blue3,color=blue3]
extra_ghost->self_force[fontcolor=blue3,color=blue3]
extra_ghost->pair_force[fontcolor=blue3,color=blue3]
extra_ghost->send_gradient[fontcolor=blue3,color=blue3]
extra_ghost->sub_self_force[fontcolor=blue3,color=blue3]
extra_ghost->sub_pair_force[fontcolor=blue3,color=blue3]
drift_part->self_density[fontcolor=blue3,color=blue3]
drift_part->self_stars_density[fontcolor=blue3,color=blue3]
drift_part->self_limiter[fontcolor=blue3,color=blue3]
drift_part->pair_density[fontcolor=blue3,color=blue3]
drift_part->pair_stars_density[fontcolor=blue3,color=blue3]
drift_part->pair_limiter[fontcolor=blue3,color=blue3]
drift_part->sort[fontcolor=blue3,color=blue3]
drift_part->send_rho[fontcolor=blue3,color=blue3]
drift_part->send_xv[fontcolor=blue3,color=blue3]
drift_part->sub_self_density[fontcolor=blue3,color=blue3]
drift_part->sub_self_stars_density[fontcolor=blue3,color=blue3]
drift_part->sub_self_limiter[fontcolor=blue3,color=blue3]
drift_part->sub_pair_density[fontcolor=blue3,color=blue3]
drift_part->sub_pair_stars_density[fontcolor=blue3,color=blue3]
drift_part->sub_pair_limiter[fontcolor=blue3,color=blue3]
end_hydro_force->cooling_in[fontcolor=blue3,color=blue3]
send_gradient->end_hydro_force[fontcolor=blue3,color=blue3]
send_xv->ghost_in[fontcolor=blue3,color=blue3]
send_rho->extra_ghost[fontcolor=blue3,color=blue3]
recv_gradient->pair_force[fontcolor=blue3,color=blue3]
recv_gradient->sub_pair_force[fontcolor=blue3,color=blue3]
recv_xv->sort[fontcolor=blue3,color=blue3]
recv_xv->pair_density[fontcolor=blue3,color=blue3]
recv_xv->sub_pair_density[fontcolor=blue3,color=blue3]
recv_rho->pair_gradient[fontcolor=blue3,color=blue3]
recv_rho->pair_stars_density[fontcolor=blue3,color=blue3]
recv_rho->sub_pair_gradient[fontcolor=blue3,color=blue3]
recv_rho->sub_pair_stars_density[fontcolor=blue3,color=blue3]
}
\ No newline at end of file
doc/RTD/source/HydroSchemes/hydro.png

1010 KiB

......@@ -2,22 +2,45 @@
Josh Borrow 4th April 2018
.. _hydro:
Hydrodynamics Schemes
=====================
This section of the documentation includes information on the hydrodynamics
schemes available in SWIFT, as well as how to implement your own.
Depending on the scheme used, the algorithm will need either 2
(e.g. GADGET-2) or 3 (e.g. GIZMO and SPHENIX) interaction loops.
Here we show the task dependencies for the hydrodynamics assuming 3 loops.
In case the case of a 2 loop scheme, SWIFT removes the gradient loop and the extra ghost.
.. figure:: hydro.png
:width: 400px
:align: center
:figclass: align-center
:alt: Task dependencies for the hydrodynamics.
This figure shows the task dependencies for the hydrodynamics assuming a scheme with the gradient loop.
The first tasks to be executed are at top the (without any incoming links) and then in the order of the links
until the last tasks without any outgoing links.
For the hydrodynamics tasks (in blue), the rectangles represent (from top to bottom) the density, gradient and force loops.
As this graph was created manually, the task dependencies might not reflect a real run depending on the physics simulated.
This was done with SWIFT v0.9.0.
.. toctree::
:maxdepth: 2
:caption: Contents:
traditional_sph
minimal_sph
planetary
planetary_sph
hopkins_sph
anarchy_sph
sphenix_sph
gasoline_sph
phantom_sph
remix_sph
adaptive_softening
gizmo
shadowswift
adding_your_own
.. Minimal SPH
Josh Borrow 4th April 2018
.. _minimal:
Minimal (Density-Energy) SPH
============================
......
.. PHANTOM SPH
Josh Borrow 13th October 2020
Phantom
=======
This scheme is a reference implementation similar to the one presented in
Price (2018), the PHANTOM paper (not including MHD). It uses:
+ A simplified Cullen & Dehnen AV limiter (note that this is different to
PHANTOM as we do not explicitly include the matrix calculation).
+ A fixed alpha artificial conduction scheme used for hydro-only problems
as presented in the PHANTOM paper (i.e. we use the 'hydro-only' conduction
velocity, rather than the one used for gravitational problems).
+ Base Density-Energy SPH
The simplified version of the 'Inviscid SPH' artificial viscosity calculates
the time differential of the velocity divergence explicitly, using the value
from the previous step. We also use the Balsara switch instead of the improved
neighbour-based limiter from Cullen & Dehnen 2010, to avoid matrix
calculations. We also use a different value for the 'h-factors' due to SWIFT
using neighbour finding based on particle number density, rather than local
mass density.
To configure with this scheme, use
.. code-block:: bash
./configure --with-hydro=phantom --disable-hand-vec
The parameters available for this scheme, and their defaults, are:
.. code-block:: yaml
SPH:
viscosity_alpha: 0.1 # Initial value for the alpha viscosity
viscosity_length: 0.25 # Viscosity decay length (in terms of sound-crossing time)
# These are enforced each time-step
viscosity_alpha_max: 2.0 # Maximal allowed value for the viscosity alpha
viscosity_alpha_min: 0.0 # Minimal allowed value for the viscosity alpha
diffusion_alpha: 1.0 # Fixed value for the diffusion alpha
There is also a compile-time parameter, ``viscosity_beta`` that we set to
3.0. During feedback events, the viscosity is set to the compile-time
``hydro_props_default_viscosity_alpha_feedback_reset = 2.0`` and the
diffusion is set to ``hydro_props_default_diffusion_alpha_feedback_reset =
0.0``. These can be changed in ``src/hydro/Phantom/hydro_parameters.h``.
.. Planetary SPH
Jacob Kegerreis, 3rd February 2019
.. _planetary_sph:
Planetary (Density-Energy, Multi-Material) SPH
==============================================
.. toctree::
:maxdepth: 2
:hidden:
:caption: Contents:
This scheme is the same as the Minimal SPH scheme but also allows multiple
materials, meaning that different SPH particles can be assigned different
:ref:`equation_of_state` (EoS).
To use the planetary scheme and the corresponding planetary EoS, use
.. code-block:: bash
./configure --with-hydro=planetary --with-equation-of-state=planetary
Every SPH particle then requires and carries the additional ``MaterialID`` flag
from the initial conditions file. This flag indicates the particle's material
and which EoS it should use.
\ No newline at end of file
.. Planetary SPH
Jacob Kegerreis, 13th March 2020
.. _planetary_sph:
Planetary (Density-Energy, Multi-Material) SPH
==============================================
.. toctree::
:maxdepth: 2
:hidden:
:caption: Contents:
See :ref:`planetary_hydro`.
.. REMIX SPH
Thomas Sandnes, 13th May 2025
.. _remix_sph:
REMIX SPH
==============================================
.. toctree::
:maxdepth: 2
:hidden:
:caption: Contents:
REMIX is an SPH scheme designed to alleviate effects that typically suppress
mixing and instability growth at density discontinuities in SPH simulations
(Sandnes et al. 2025). REMIX addresses this problem by directly targeting sources
of kernel smoothing error and discretisation error, resulting in a generalised,
material-independent formulation that improves the treatment both of
discontinuities within a single material, for example in an ideal gas, and of
interfaces between dissimilar materials. The scheme combines:
+ An evolved density estimate to avoid the kernel smoothing error in the
standard SPH integral density estimate;
+ Thermodynamically consistent, conservative equations of motion, with
free functions chosen to limit zeroth-order error;
+ Linear-order reproducing kernels with grad-h terms and a vacuum interface
treatment;
+ A "kernel normalising term" to avoid potential accumulation of error in
the evolved density estimate, such that densities are ensured to remain
representative of the distribution of particle masses in the simulation volume;
+ Advanced artificial viscosity and diffusion schemes with linear reconstruction
of quantities to particle midpoints, and a set of novel improvements to
effectively switch between treatments for shock-capturing under compression and
noise-smoothing in shearing regions.
To configure with this scheme, use
.. code-block:: bash
./configure --with-hydro=remix --with-equation-of-state=planetary
This scheme allows multiple materials,
meaning that different SPH particles can be assigned different
`equations of state <equations_of_state.html>`_ (EoS).
Every SPH particle then requires and carries the additional ``MaterialID`` flag
from the initial conditions file. This flag indicates the particle's material
and which EoS it should use. Note that configuring with
``--with-equation-of-state=planetary`` is required for this scheme, although
for simulations that use a single, ideal gas EoS, setting all MaterialIDs to
``0`` and including
.. code-block:: yaml
EoS:
planetary_use_idg_def: 1
in the parameter file are the only EoS-related additions needed compared with
other non-Planetary hydro schemes. Note also that since densities are evolved in
time, initial particle densities are required in initial conditions.
We additionally recommend configuring with ``--with-kernel=wendland-C2`` and with
.. code-block:: yaml
SPH:
resolution_eta: 1.487
in the parameter file for improved hydrodynamic behaviour and since this is the
configuration used for the validation simulations of Sandnes et al. (2025).
The current implementation of the REMIX hydro scheme has been validated for
planetary applications and various hydrodynamic test cases, and does not include
all necessary functionality for e.g. cosmological simulations.
Default parameters used in the artificial viscosity and diffusion schemes and the
normalising term (see Sandnes et al. 2025) are:
.. code-block:: c
#define const_remix_visc_alpha 1.5f
#define const_remix_visc_beta 3.f
#define const_remix_visc_epsilon 0.1f
#define const_remix_visc_a 2.0f / 3.0f
#define const_remix_visc_b 1.0f / 3.0f
#define const_remix_difn_a_u 0.05f
#define const_remix_difn_b_u 0.95f
#define const_remix_difn_a_rho 0.05f
#define const_remix_difn_b_rho 0.95f
#define const_remix_norm_alpha 1.0f
#define const_remix_slope_limiter_exp_denom 0.04f
These can be changed in ``src/hydro/REMIX/hydro_parameters.h``.
.. ShadowSWIFT (Moving mesh hydrodynamics)
Yolan Uyttenhove September 2023
ShadowSWIFT (moving mesh hydrodynamics)
=======================================
.. warning::
The moving mesh hydrodynamics solver is currently in the process of being merged into master and will **NOT**
work on the master branch. To use it, compile the code using the ``moving_mesh`` branch.
This is an implementation of the moving-mesh finite-volume method for hydrodynamics in SWIFT.
To use this scheme, a Riemann solver is also needed. Configure SWIFT as follows:
.. code-block:: bash
./configure --with-hydro="shadowswift" --with-riemann-solver="hllc"
Current status
~~~~~~~~~~~~~~
Due to the completely different task structure compared to SPH hydrodynamics, currently only a subset of the features of
SWIFT is supported in this scheme.
- Hydrodynamics is fully supported in 1D, 2D and 3D and over MPI.
- Both self-gravity and external potentials are supported.
- Cosmological time-integration is supported.
- Cooling and chemistry are supported, with the exception of the ``GEAR_diffusion`` chemistry scheme. Metals are
properly according to mass fluxes.
- Choice between periodic, reflective, open, inflow and vacuum boundary conditions (for non-periodic boundary
conditions, the desired variant must be selected in ``const.h``). Additionally, reflective boundary conditions
are applied to SWIFT's boundary particles. Configure with ``--with-boundary-particles=<N>`` to use this (e.g. to
simulate walls).
Caveats
~~~~~~~
These are currently the main limitations of the ShadowSWIFT hydro scheme:
- Unlike SPH the cells of the moving mesh must form a partition of the entire simulation volume. This means that there
cannot be empty SWIFT cells and vacuum must be explicitly represented by zero (or negligible) mass particles.
- Most other subgrid physics, most notably, star formation and stellar feedback are not supported yet.
- No MHD schemes are supported.
- No radiative-transfer schemes are supported.