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
  • CubeTest
  • GPU_swift
  • TangoSIDM
  • active_h_max_optimization
  • arm_vec
  • c11
  • c11_atomics_copy
  • comm_tasks_are_special
  • cuda_test
  • domain_zoom_nometis
  • drift_flag_debug_check
  • driven_turbulence
  • engineering
  • evrard_disc
  • expand_fof
  • fix_sink_timestep
  • fixed_hSIDM
  • fof_snapshots
  • gear_metal_diffusion
  • generic_cache
  • genetic_partitioning2
  • gizmo
  • gizmo_entropy_switch
  • gizmo_mfv_entropy
  • hashmap_mesh
  • isotropic_feedback
  • ivanova-testing
  • jsw/6dfof
  • kahip
  • lean_gparts
  • load-balance-testing
  • locked_hydro
  • logger_read_history
  • logger_read_history2
  • logger_write_hdf5
  • mass_dependent_h_max
  • master
  • mpi-one-thread
  • mpi-packed-parts
  • mpi-send-subparts
  • mpi-send-subparts-vector
  • mpi-subparts-vector-grav
  • mpi-testsome
  • mpi-threads
  • mpi_force_checks
  • numa_awareness
  • onesided-mpi-rdma
  • onesided-mpi-recv-cache
  • onesided-mpi-recv-window
  • onesided-mpi-single-recv-window
  • origin-master
  • parallel_exchange_cells
  • paranoid
  • phantom
  • planetary
  • planetary_boundary
  • queue-timers
  • queue-timers-clean
  • rdma-only
  • rdma-only-multiple-sends
  • rdma-only-subcopies
  • rdma-only-subparts
  • rdma-only-subparts-update
  • rdma-only-subparts-update-flamingo
  • rdma-only-subparts-update-flamingo-cellids
  • rdma-only-subparts-update-keep
  • rdma-only-subparts-update-keep-update
  • rdma-only-subsends
  • reweight-fitted-costs
  • reweight-scaled-costs
  • rgb-engineering
  • rt-gas-interactions
  • rt-ghost2-and-thermochemistry
  • scheduler_determinism
  • search-window-tests
  • signal-handler-dump
  • simba-stellar-feedback
  • sink_formation2
  • sink_merger
  • sink_merger2
  • skeleton
  • smarter_sends
  • snipes_data
  • spiral_potential
  • subgrid_SF_threshold
  • subsends
  • swift-rdma
  • swift_zoom_support
  • sync-send
  • thread-dump-extract-waiters
  • threadpool_rmapper
  • traphic
  • variable_hSIDM
  • whe-nu-bg-cosmo
  • when_to_proxy
  • yb-bhdev
  • yb-sndev
  • yb-sndev-dev
  • yb-varsndt-isotropic
  • yb-vi-gastrack
  • 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
116 results
Show changes
Commits on Source (502)
Showing
with 1446 additions and 556 deletions
......@@ -39,12 +39,14 @@ examples/*/*/*.rst
examples/*/*/*.hdf5
examples/*/*/*.csv
examples/*/*/*.dot
examples/*/*/cell_hierarchy.html
examples/**/cell_hierarchy.html
examples/*/*/energy.txt
examples/*/*/task_level.txt
examples/**/task_level.txt
examples/*/*/timesteps_*.txt
examples/*/*/SFR.txt
examples/*/*/partition_fixed_costs.h
examples/**/timesteps.txt
examples/**/SFR.txt
examples/**/statistics.txt
examples/**/partition_fixed_costs.h
examples/*/*/memuse_report-step*.dat
examples/*/*/memuse_report-step*.log
examples/*/*/restart/*
......@@ -56,7 +58,6 @@ examples/*/*/used_parameters.yml
examples/*/*/unused_parameters.yml
examples/*/*/fof_used_parameters.yml
examples/*/*/fof_unused_parameters.yml
examples/*/*/partition_fixed_costs.h
examples/*/*.mpg
examples/*/*/gravity_checks_*.dat
examples/*/*/coolingtables.tar.gz
......@@ -65,6 +66,9 @@ examples/*/*/yieldtables.tar.gz
examples/*/*/yieldtables
examples/*/*/photometry.tar.gz
examples/*/*/photometry
examples/*/*/plots
examples/*/*/snapshots
examples/*/*/restart
examples/Cooling/CoolingRates/cooling_rates
examples/Cooling/CoolingRates/cooling_element_*.dat
examples/Cooling/CoolingRates/cooling_output.dat
......@@ -73,16 +77,15 @@ examples/SubgridTests/CosmologicalStellarEvolution/StellarEvolutionSolution*
examples/SmallCosmoVolume/SmallCosmoVolume_DM/power_spectra
examples/SmallCosmoVolume/SmallCosmoVolume_cooling/snapshots/
examples/SmallCosmoVolume/SmallCosmoVolume_hydro/snapshots/
examples/SmallCosmoVolume/SmallCosmoVolume_cooling/CloudyData_UVB=HM2012.h5
examples/SmallCosmoVolume/SmallCosmoVolume_cooling/CloudyData_UVB=HM2012_shielded.h5
examples/GEAR/AgoraDisk/CloudyData_UVB=HM2012.h5
examples/GEAR/AgoraDisk/CloudyData_UVB=HM2012_shielded.h5
examples/GEAR/AgoraDisk/chemistry-AGB+OMgSFeZnSrYBaEu-16072013.h5
examples/GEAR/AgoraCosmo/CloudyData_UVB=HM2012_shielded.h5
examples/GEAR/AgoraCosmo/POPIIsw.h5
examples/GEAR/ZoomIn/CloudyData_UVB=HM2012.h5
examples/GEAR/ZoomIn/POPIIsw.h5
examples/GEAR/ZoomIn/snap/
examples/**/CloudyData_UVB=HM2012.h5
examples/**/CloudyData_UVB=HM2012_shielded.h5
examples/**/CloudyData_UVB=HM2012_high_density.h5
examples/**/chemistry-AGB+OMgSFeZnSrYBaEu-16072013.h5
examples/**/POPIIsw.h5
examples/**/GRACKLE_INFO
examples/**/snap/
examples/SinkParticles/HomogeneousBox/snapshot_0003restart.hdf5
tests/testActivePair
tests/testActivePair.sh
......@@ -222,6 +225,7 @@ theory/Multipoles/mac_potential.pdf
theory/Cosmology/cosmology.pdf
theory/Cooling/eagle_cooling.pdf
theory/Gizmo/gizmo-implementation-details/gizmo-implementation-details.pdf
theory/RadiativeTransfer/GEARRT/GEARRT.pdf
m4/libtool.m4
m4/ltoptions.m4
......
......@@ -13,7 +13,7 @@ Josh Borrow joshua.borrow@durham.ac.uk
Loic Hausammann loic.hausammann@epfl.ch
Yves Revaz yves.revaz@epfl.ch
Jacob Kegerreis jacob.kegerreis@durham.ac.uk
Mladen Ivkovic mladen.ivkovic@epfl.ch
Mladen Ivkovic mladen.ivkovic@durham.ac.uk
Stuart McAlpine stuart.mcalpine@helsinki.fi
Folkert Nobels nobels@strw.leidenuniv.nl
John Helly j.c.helly@durham.ac.uk
......@@ -25,4 +25,10 @@ Sylvia Ploeckinger ploeckinger@lorentz.leidenuniv.nl
Willem Elbers willem.h.elbers@durham.ac.uk
TK Chan chantsangkeung@gmail.com
Marcel van Daalen daalen@strw.leidenuniv.nl
Filip Husko filip.husko@durham.ac.uk
\ No newline at end of file
Filip Husko filip.husko@durham.ac.uk
Orestis Karapiperis karapiperis@lorentz.leidenuniv.nl
Stan Verhoeve s06verhoeve@gmail.com
Nikyta Shchutskyi shchutskyi@lorentz.leidenuniv.nl
Will Roper w.roper@sussex.ac.uk
Darwin Roduit darwin.roduit@alumni.epfl.ch
Jonathan Davies j.j.davies@ljmu.ac.uk
The SWIFT source code is using a variation of the 'Google' formatting style.
The script 'format.sh' in the root directory applies the clang-format-13
The script 'format.sh' in the root directory applies the clang-format-18
tool with our style choices to all the SWIFT C source file. Please apply
the formatting script to the files before submitting a merge request.
......
......@@ -99,7 +99,7 @@ before you can build it.
- HDF5:
A HDF5 library (v. 1.8.x or higher) is required to read and
A HDF5 library (v. 1.10.x or higher) is required to read and
write particle data. One of the commands "h5cc" or "h5pcc"
should be available. If "h5pcc" is located then a parallel
HDF5 built for the version of MPI located should be
......@@ -191,7 +191,7 @@ before you can build it.
==================
The SWIFT source code uses a variation of 'Google' style. The script
'format.sh' in the root directory applies the clang-format-13 tool with our
'format.sh' in the root directory applies the clang-format-18 tool with our
style choices to all the SWIFT C source file. Please apply the formatting
script to the files before submitting a merge request.
......
......@@ -37,15 +37,15 @@ MYFLAGS =
# Add the source directory and the non-standard paths to the included library headers to CFLAGS
AM_CFLAGS = -I$(top_srcdir)/src -I$(top_srcdir)/argparse $(HDF5_CPPFLAGS) \
$(GSL_INCS) $(FFTW_INCS) $(NUMA_INCS) $(GRACKLE_INCS) $(OPENMP_CFLAGS) \
$(CHEALPIX_CFLAGS)
$(GSL_INCS) $(FFTW_INCS) $(NUMA_INCS) $(GRACKLE_INCS) \
$(CHEALPIX_CFLAGS) $(LUSTREAPI_CFLAGS)
AM_LDFLAGS = $(HDF5_LDFLAGS)
# Extra libraries.
EXTRA_LIBS = $(GSL_LIBS) $(HDF5_LIBS) $(FFTW_LIBS) $(NUMA_LIBS) $(PROFILER_LIBS) \
$(TCMALLOC_LIBS) $(JEMALLOC_LIBS) $(TBBMALLOC_LIBS) $(GRACKLE_LIBS) \
$(CHEALPIX_LIBS)
$(CHEALPIX_LIBS) $(LUSTREAPI_LIBS)
# MPI libraries.
MPI_LIBS = $(PARMETIS_LIBS) $(METIS_LIBS) $(MPI_THREAD_LIBS) $(FFTW_MPI_LIBS)
......
......@@ -6,7 +6,7 @@
/____/ |__/|__/___/_/ /_/
SPH With Inter-dependent Fine-grained Tasking
Version : 1.0.0
Version : 2025.04
Website: www.swiftsim.com
Twitter: @SwiftSimulation
......
......@@ -18,7 +18,7 @@ More general information about SWIFT is available on the project
[webpages](http://www.swiftsim.com).
For information on how to _run_ SWIFT, please consult the onboarding guide
available [here](http://www.swiftsim.com/onboarding.pdf). This includes
available [here](https://swift.strw.leidenuniv.nl/onboarding.pdf). This includes
dependencies, and a few examples to get you going.
We suggest that you use the latest release branch of SWIFT, rather than the
......@@ -55,7 +55,7 @@ experimentation with various values is highly encouraged. Each problem will
likely require different values and the sensitivity to the details of the
physical model is something left to the users to explore.
Acknowledgment & Citation
Acknowledgement & Citation
-------------------------
The SWIFT code was last described in this paper:
......@@ -66,7 +66,7 @@ their results.
In order to keep track of usage and measure the impact of the software, we
kindly ask users publishing scientific results using SWIFT to add the following
sentence to the acknowledgment section of their papers:
sentence to the acknowledgement section of their papers:
"The research in this paper made use of the SWIFT open-source
simulation code (http://www.swiftsim.com, Schaller et al. 2018)
......@@ -81,7 +81,7 @@ Contribution Guidelines
-----------------------
The SWIFT source code uses a variation of the 'Google' formatting style.
The script 'format.sh' in the root directory applies the clang-format-10
The script 'format.sh' in the root directory applies the clang-format-18
tool with our style choices to all the SWIFT C source file. Please apply
the formatting script to the files before submitting a pull request.
......@@ -106,7 +106,7 @@ Runtime parameters
/____/ |__/|__/___/_/ /_/
SPH With Inter-dependent Fine-grained Tasking
Version : 1.0.0
Version : 2025.04
Website: www.swiftsim.com
Twitter: @SwiftSimulation
......
......@@ -105,20 +105,13 @@ int argparse_help_cb(struct argparse *self,
const struct argparse_option *option);
// built-in option macros
#define OPT_END() \
{ ARGPARSE_OPT_END, 0, NULL, NULL, 0, NULL, 0, 0 }
#define OPT_BOOLEAN(...) \
{ ARGPARSE_OPT_BOOLEAN, __VA_ARGS__ }
#define OPT_BIT(...) \
{ ARGPARSE_OPT_BIT, __VA_ARGS__ }
#define OPT_INTEGER(...) \
{ ARGPARSE_OPT_INTEGER, __VA_ARGS__ }
#define OPT_FLOAT(...) \
{ ARGPARSE_OPT_FLOAT, __VA_ARGS__ }
#define OPT_STRING(...) \
{ ARGPARSE_OPT_STRING, __VA_ARGS__ }
#define OPT_GROUP(h) \
{ ARGPARSE_OPT_GROUP, 0, NULL, NULL, h, NULL, 0, 0 }
#define OPT_END() {ARGPARSE_OPT_END, 0, NULL, NULL, 0, NULL, 0, 0}
#define OPT_BOOLEAN(...) {ARGPARSE_OPT_BOOLEAN, __VA_ARGS__}
#define OPT_BIT(...) {ARGPARSE_OPT_BIT, __VA_ARGS__}
#define OPT_INTEGER(...) {ARGPARSE_OPT_INTEGER, __VA_ARGS__}
#define OPT_FLOAT(...) {ARGPARSE_OPT_FLOAT, __VA_ARGS__}
#define OPT_STRING(...) {ARGPARSE_OPT_STRING, __VA_ARGS__}
#define OPT_GROUP(h) {ARGPARSE_OPT_GROUP, 0, NULL, NULL, h, NULL, 0, 0}
#define OPT_HELP() \
OPT_BOOLEAN('h', "help", NULL, "show this help message and exit", \
argparse_help_cb, 0, 0)
......
......@@ -16,7 +16,7 @@
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# Init the project.
AC_INIT([SWIFT],[1.0.0],[https://gitlab.cosma.dur.ac.uk/swift/swiftsim])
AC_INIT([SWIFT],[2025.04],[https://gitlab.cosma.dur.ac.uk/swift/swiftsim])
swift_config_flags="$*"
AC_COPYRIGHT
......@@ -40,6 +40,8 @@ AX_CHECK_ENABLE_DEBUG
AC_USE_SYSTEM_EXTENSIONS
AC_PROG_CC
AM_PROG_CC_C_O
# We need this for compilation hints and possibly FFTW.
AX_OPENMP
# If debug is selected then we also define SWIFT_DEVELOP_MODE to control
......@@ -90,43 +92,67 @@ if test "$with_csds" = "yes"; then
fi
AC_CONFIG_SUBDIRS([csds])
CFLAGS="$CFLAGS $OPENMP_CFLAGS"
fi
AM_CONDITIONAL([HAVECSDS],[test $with_csds = "yes"])
# Use best known optimization for the current architecture. Actual optimization
# happens later so we can avoid any issues it introduces with the compiler,
# but we need to know if that will happen now.
AC_ARG_ENABLE([optimization],
[AS_HELP_STRING([--enable-optimization],
[Enable compile time optimization flags for host @<:@yes/no@:>@]
)],
[enable_opt="$enableval"],
[enable_opt="yes"]
)
# Interprocedural optimization support. Needs special handling for linking and
# archiving as well as compilation with Intels, needs to be done before
# libtool is configured (to use correct LD).
# Interprocedural optimization support. Can need special handling for linking
# and archiving as well as compilation. Needs to be done before libtool is
# configured so we use the correct LD. It can give good improvements for
# clang based compilers, so the default is enabled, but we make that
# disabled when not optimizing or debugging support is enabled.
enable_ipo_default="yes";
if test "x$ax_enable_debug" = "xyes" -o "x$enable_opt" != "xyes"; then
enable_ipo_default="no";
AC_MSG_WARN([Interprocedural optimization support default is changed to false])
fi
AC_ARG_ENABLE([ipo],
[AS_HELP_STRING([--enable-ipo],
[Enable interprocedural optimization @<:@no/yes@:>@]
[Enable interprocedural optimization [default=yes unless debugging]]
)],
[enable_ipo="$enableval"],
[enable_ipo="no"]
[enable_ipo="$enable_ipo_default"]
)
if test "$enable_ipo" = "yes"; then
if test "$ax_cv_c_compiler_vendor" = "intel"; then
CFLAGS="$CFLAGS -ip -ipo"
LDFLAGS="$LDFLAGS -ipo"
: ${AR="xiar"}
: ${LD="xild"}
AC_CHECK_PROGS([AR], [xiar])
AC_CHECK_PROGS([LD], [xild])
AC_MSG_RESULT([added Intel interprocedural optimization support])
elif test "$ax_cv_c_compiler_vendor" = "oneapi"; then
CFLAGS="$CFLAGS -ipo"
LDFLAGS="$LDFLAGS -ipo"
AC_CHECK_PROGS([AR], [xiar])
AC_CHECK_PROGS([RANLIB], [llvm-ranlib])
AC_MSG_RESULT([added oneapi interprocedural optimization support])
elif test "$ax_cv_c_compiler_vendor" = "gnu"; then
CFLAGS="$CFLAGS -flto"
LDFLAGS="$LDFLAGS -flto"
AX_COMPARE_VERSION($ax_cv_c_compiler_version, [ge], [5.0.0],
[
: ${AR="gcc-ar"}
: ${RANLIB="gcc-ranlib"}
], [:] )
[
AC_CHECK_PROGS([AR], [gcc-ar])
AC_CHECK_PROGS([RANLIB], [gcc-ranlib])
], [:] )
AC_MSG_RESULT([added GCC interprocedural optimization support])
elif test "$ax_cv_c_compiler_vendor" = "clang"; then
CFLAGS="$CFLAGS -flto=thin"
LDFLAGS="$LDFLAGS -flto=thin"
: ${RANLIB="llvm-ranlib"}
CFLAGS="$CFLAGS -flto"
LDFLAGS="$LDFLAGS -flto"
AC_CHECK_PROGS([RANLIB], [llvm-ranlib])
AC_MSG_RESULT([added LLVM interprocedural optimization support])
else
AC_MSG_WARN([Compiler does not support interprocedural optimization])
......@@ -146,7 +172,7 @@ AC_ARG_ENABLE([mpi],
[enable_mpi="$enableval"],
[enable_mpi="yes"]
)
# Use extra flags set by AC_PROG_CC as part of $CC. Currently undocumented as ac_cv_prog_cc_stdc,
# Use extra flags set by AC_PROG_CC as part of $CC. Currently undocumented as ac_cv_prog_cc_stdc,
# so could change.
good_mpi="yes"
if test "$enable_mpi" = "yes"; then
......@@ -223,7 +249,7 @@ AC_C_INLINE
# If debugging try to show inlined functions.
if test "x$enable_debug" = "xyes"; then
if test "x$ax_enable_debug" = "xyes"; then
# Show inlined functions.
if test "$ax_cv_c_compiler_vendor" = "gnu"; then
# Would like to use -gdwarf and let the compiler pick a good version
......@@ -234,6 +260,8 @@ if test "x$enable_debug" = "xyes"; then
CFLAGS="$CFLAGS $inline_EXTRA_FLAGS"
elif test "$ax_cv_c_compiler_vendor" = "intel"; then
CFLAGS="$CFLAGS -debug inline-debug-info"
elif test "$ax_cv_c_compiler_vendor" = "oneapi"; then
CFLAGS="$CFLAGS -debug inline-debug-info"
fi
fi
......@@ -315,7 +343,7 @@ if test "$enable_cell_graph" = "yes"; then
AC_DEFINE([SWIFT_CELL_GRAPH],1,[Enable cell graph])
fi
# Check if using our custom icbrtf is enalbled.
# Check if using our custom icbrtf is enabled.
AC_ARG_ENABLE([custom-icbrtf],
[AS_HELP_STRING([--enable-custom-icbrtf],
[Use SWIFT's custom icbrtf function instead of the system cbrtf @<:@yes/no@:>@]
......@@ -405,6 +433,20 @@ elif test "$stars_density_checks" != "no"; then
AC_DEFINE_UNQUOTED([SWIFT_STARS_DENSITY_CHECKS], [$enableval] ,[Enable stars density brute-force checks])
fi
# Check if sink density checks are on for some particles.
AC_ARG_ENABLE([sink-density-checks],
[AS_HELP_STRING([--enable-sink-density-checks],
[Activate expensive brute-force sink density checks for a fraction 1/N of all particles @<:@N@:>@]
)],
[sink_density_checks="$enableval"],
[sink_density_checks="no"]
)
if test "$sink_density_checks" = "yes"; then
AC_MSG_ERROR(Need to specify the fraction of particles to check when using --enable-sink-density-checks!)
elif test "$sink_density_checks" != "no"; then
AC_DEFINE_UNQUOTED([SWIFT_SINK_DENSITY_CHECKS], [$enableval] ,[Enable sink density brute-force checks])
fi
# Check if ghost statistics are enabled
AC_ARG_ENABLE([ghost-statistics],
[AS_HELP_STRING([--enable-ghost-statistics],
......@@ -538,16 +580,6 @@ fi
# Define HAVE_POSIX_MEMALIGN if it works.
AX_FUNC_POSIX_MEMALIGN
# Only optimize if allowed, otherwise assume user will set CFLAGS as
# appropriate.
AC_ARG_ENABLE([optimization],
[AS_HELP_STRING([--enable-optimization],
[Enable compile time optimization flags for host @<:@yes/no@:>@]
)],
[enable_opt="$enableval"],
[enable_opt="yes"]
)
# Disable vectorisation for known compilers. This switches off optimizations
# that could be enabled above, so in general should be appended. Slightly odd
# implementation as want to describe as --disable-vec, but macro is enable
......@@ -572,6 +604,9 @@ AC_ARG_ENABLE([hand-vec],
HAVEVECTORIZATION=0
# Only optimize if allowed, otherwise assume user will set CFLAGS as
# appropriate. Note argument check is done earlier so we can configure
# other options related to optimization.
if test "$enable_opt" = "yes" ; then
# Choose the best flags for this compiler and architecture
......@@ -579,29 +614,55 @@ if test "$enable_opt" = "yes" ; then
AX_CC_MAXOPT
ac_test_CFLAGS="yes"
# Choose the best flags for the gravity sub-library on this compiler and architecture
# Choose the best flags for the gravity sub-library on this compiler and
# architecture. Note we use OpenMP as a compiler hints for loop vectorization.
GRAVITY_CFLAGS="$GRAVITY_CFLAGS $OPENMP_CFLAGS"
if test "$ax_cv_c_compiler_vendor" = "intel"; then
case "$icc_flags" in
*CORE-AVX512*)
GRAVITY_CFLAGS="$GRAVITY_CFLAGS -qopt-zmm-usage=high"
;;
*)
AC_MSG_WARN([No additional flags needed for gravity on this platform])
AC_MSG_NOTICE([No additional flags needed for gravity on this platform])
;;
esac
elif test "$ax_cv_c_compiler_vendor" = "oneapi"; then
case "$icc_flags" in
*CORE-AVX512*)
GRAVITY_CFLAGS="$GRAVITY_CFLAGS -qopt-zmm-usage=high"
;;
*)
AC_MSG_NOTICE([No additional flags needed for gravity on this platform])
;;
esac
elif test "$ax_cv_c_compiler_vendor" = "gnu"; then
if test "$gcc_handles_avx512" = "yes"; then
case "$ax_gcc_arch" in
case "$ax_cv_gcc_archflag" in
*skylake-avx512*)
GRAVITY_CFLAGS="$GRAVITY_CFLAGS -mprefer-vector-width=512"
;;
*)
AC_MSG_WARN([No additional flags needed for gravity on this platform])
AC_MSG_NOTICE([No additional flags needed for gravity on this platform])
;;
esac
else
AC_MSG_WARN([No additional flags needed for gravity on this platform])
AC_MSG_NOTICE([No additional flags needed for gravity on this platform])
fi
elif test "$ax_cv_c_compiler_vendor" = "clang"; then
# Could be a number of compilers. Check for aocc specific flags we want
# to use.
AX_CHECK_COMPILE_FLAG("-zopt", [GRAVITY_CFLAGS="$GRAVITY_CFLAGS -fvectorize -zopt"])
case "$ax_cv_gcc_archflag" in
*skylake-avx512*)
GRAVITY_CFLAGS="$GRAVITY_CFLAGS -mprefer-vector-width=512"
;;
*znver[[4-9]])
GRAVITY_CFLAGS="$GRAVITY_CFLAGS -mprefer-vector-width=512"
;;
*)
:
;;
esac
else
AC_MSG_WARN([Do not know what best gravity vectorization flags to choose for this compiler])
fi
......@@ -622,6 +683,9 @@ if test "$enable_opt" = "yes" ; then
if test "$ax_cv_c_compiler_vendor" = "intel"; then
CFLAGS="$CFLAGS -no-vec -no-simd"
AC_MSG_RESULT([disabled Intel vectorization])
elif test "$ax_cv_c_compiler_vendor" = "oneapi"; then
CFLAGS="$CFLAGS -no-vec"
AC_MSG_RESULT([disabled oneAPI vectorization])
elif test "$ax_cv_c_compiler_vendor" = "gnu"; then
CFLAGS="$CFLAGS -fno-tree-vectorize"
AC_MSG_RESULT([disabled GCC vectorization])
......@@ -638,7 +702,6 @@ if test "$enable_opt" = "yes" ; then
fi
AM_CONDITIONAL([HAVEVECTORIZATION],[test -n "$HAVEVECTORIZATION"])
# Add address sanitizer options to flags, if requested. Only useful for GCC
# version 4.8 and later and clang.
AC_ARG_ENABLE([sanitizer],
......@@ -659,7 +722,20 @@ if test "$enable_san" = "yes"; then
fi
if test "$enable_san" = "yes"; then
CFLAGS="$CFLAGS -fsanitize=address -fno-omit-frame-pointer"
AC_MSG_RESULT([added address sanitizer support])
AC_MSG_RESULT([Adding address sanitizer support... yes])
# Check if we have access to the __lsan_ignore_object() call for
# marking memory allocations as deliberately leaked.
AC_LINK_IFELSE([AC_LANG_SOURCE([[
#include <stdlib.h>
#include <sanitizer/lsan_interface.h>
int main(int argc, char *argv[]) {
void *p = malloc(1);
__lsan_ignore_object(p);
return 0;
}]])],
[AC_DEFINE(HAVE_LSAN_IGNORE_OBJECT, 1, [Have __lsan_ignore_object() call])],
[AC_MSG_WARN([Sanitizer enabled but no __lsan_ignore_object()])])
else
AC_MSG_WARN([Compiler does not support address sanitizer option])
fi
......@@ -756,6 +832,42 @@ AC_SUBST([GSL_LIBS])
AC_SUBST([GSL_INCS])
AM_CONDITIONAL([HAVEGSL],[test -n "$GSL_LIBS"])
# Check for GMP. We test for this in the standard directories by default,
# and only disable if using --with-gmp=no or --without-gmp. When a value
# is given GMP must be found.
have_gmp="no"
AC_ARG_WITH([gmp],
[AS_HELP_STRING([--with-gmp=PATH],
[root directory where GMP is installed @<:@yes/no@:>@]
)],
[with_gmp="$withval"],
[with_gmp="test"]
)
if test "x$with_gmp" != "xno"; then
if test "x$with_gmp" != "xyes" -a "x$with_gmp" != "xtest" -a "x$with_gmp" != "x"; then
GMP_LIBS="-L$with_gmp/lib -lgmp"
else
GMP_LIBS="-lgmp"
fi
# GMP is not specified, so just check if we have it.
if test "x$with_gmp" = "xtest"; then
AC_CHECK_LIB([gmp],[__gmpz_inits],[have_gmp="yes"],[have_gmp="no"],$GMP_LIBS)
if test "x$have_gmp" != "xno"; then
AC_DEFINE([HAVE_LIBGMP],1,[The GMP library appears to be present.])
fi
else
AC_CHECK_LIB([gmp],[__gmpz_inits],
AC_DEFINE([HAVE_LIBGMP],1,[The GMP library appears to be present.]),
AC_MSG_ERROR(something is wrong with the GMP library!), $GMP_LIBS)
have_gmp="yes"
fi
if test "$have_gmp" = "no"; then
GMP_LIBS=""
fi
fi
AC_SUBST([GMP_LIBS])
AM_CONDITIONAL([HAVEGMP],[test -n "$GMP_LIBS"])
# Check for pthreads.
AX_PTHREAD([LIBS="$PTHREAD_LIBS $LIBS" CFLAGS="$CFLAGS $PTHREAD_CFLAGS"
CC="$PTHREAD_CC" LDFLAGS="$LDFLAGS $PTHREAD_LIBS $LIBS"],
......@@ -801,6 +913,21 @@ if test "x$with_metis" != "xno"; then
fi
AC_CHECK_LIB([metis],[METIS_PartGraphKway], [have_metis="yes"],
[have_metis="no"], $METIS_LIBS)
# Recent METIS releases have an external GKlib, test for that before
# giving up. Assume sane and in the same directories.
if test "x$have_metis" = "xno"; then
if test "x$with_metis" != "xyes" -a "x$with_metis" != "x"; then
METIS_LIBS="-L$with_metis/lib -lmetis -lGKlib"
METIS_INCS="-I$with_metis/include"
else
METIS_LIBS="-lmetis -lGKlib"
METIS_INCS=""
fi
AC_CHECK_LIB([metis],[METIS_PartGraphRecursive], [have_metis="yes"],
[have_metis="no"], $METIS_LIBS)
fi
if test "$have_metis" = "yes"; then
AC_DEFINE([HAVE_METIS],1,[The METIS library is present.])
else
......@@ -834,10 +961,9 @@ if test "x$with_parmetis" != "xno"; then
fi
AC_CHECK_LIB([parmetis],[ParMETIS_V3_RefineKway], [have_parmetis="yes"],
[have_parmetis="no"], $PARMETIS_LIBS)
if test "$have_parmetis" = "no"; then
# A build may use an external METIS library, check for that.
if test "$have_parmetis" = "no"; then
if test "x$with_parmetis" != "xyes" -a "x$with_parmetis" != "x"; then
PARMETIS_LIBS="-L$with_parmetis/lib -lparmetis -lmetis"
PARMETIS_INCS="-I$with_parmetis/include"
......@@ -848,6 +974,20 @@ if test "x$with_parmetis" != "xno"; then
# Note use different function to avoid caching of first check.
AC_CHECK_LIB([parmetis],[ParMETIS_V3_PartKway], [have_parmetis="yes"],
[have_parmetis="no"], [$METIS_LIBS $PARMETIS_LIBS])
fi
# A build may use an external GKlib in later releases...
if test "$have_parmetis" = "no"; then
if test "x$with_parmetis" != "xyes" -a "x$with_parmetis" != "x"; then
PARMETIS_LIBS="-L$with_parmetis/lib -lparmetis -lGKlib"
PARMETIS_INCS="-I$with_parmetis/include"
else
PARMETIS_LIBS="-lparmetis -lGKlib"
PARMETIS_INCS=""
fi
# Note use different function to avoid caching of first check.
AC_CHECK_LIB([parmetis],[ParMETIS_V3_PartGeom], [have_parmetis="yes"],
[have_parmetis="no"], [$METIS_LIBS $PARMETIS_LIBS])
fi
if test "$have_parmetis" = "yes"; then
......@@ -948,17 +1088,22 @@ if test "x$with_fftw" != "xno"; then
FFTW_OPENMP_INCS=""
fi
# Verify that the library works. Note requires AC_OPENMP called above.
# Verify that the library works. Note requires AX_OPENMP called above.
old_CFLAGS=$CFLAGS
CFLAGS="$CFLAGS $OPENMP_CFLAGS"
AC_CHECK_LIB([fftw3],[fftw_init_threads],[have_openmp_fftw="yes"],
[have_openmp_fftw="no"], $FFTW_OPENMP_LIBS)
# If found, update things
if test "x$have_openmp_fftw" = "xyes"; then
# Note OpenMP and pthreads use mostly the same calls, so define both.
# Note OpenMP and pthreads use mostly the same calls, so define both.
AC_DEFINE([HAVE_THREADED_FFTW],1,[The threaded OpenMP FFTW library appears to be present.])
AC_DEFINE([HAVE_OPENMP_FFTW],1,[The OpenMP FFTW library appears to be present.])
FFTW_LIBS=$FFTW_OPENMP_LIBS
FFTW_INCS=$FFTW_OPENMP_INCS
else
# Put CFLAGS back.
CFLAGS=$old_CFLAGS
fi
fi
......@@ -1136,7 +1281,7 @@ if test "x$with_tcmalloc" != "xno"; then
# Prevent compilers that replace the calls with built-ins (GNU 99) from doing so.
case "$ax_cv_c_compiler_vendor" in
intel | gnu | clang)
intel | gnu | clang | oneapi)
CFLAGS="$CFLAGS -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free"
;;
esac
......@@ -1179,7 +1324,7 @@ if test "x$with_jemalloc" != "xno"; then
# Prevent compilers that replace the regular calls with built-ins (GNU 99) from doing so.
case "$ax_cv_c_compiler_vendor" in
intel | gnu | clang)
intel | gnu | clang | oneapi)
CFLAGS="$CFLAGS -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free"
;;
esac
......@@ -1222,7 +1367,7 @@ if test "x$with_tbbmalloc" != "xno"; then
# Prevent compilers that replace the calls with built-ins (GNU 99) from doing so.
case "$ax_cv_c_compiler_vendor" in
intel | gnu | clang)
intel | gnu | clang | oneapi)
CFLAGS="$CFLAGS -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free"
;;
esac
......@@ -1286,6 +1431,38 @@ if test "$with_hdf5" = "yes"; then
fi
AM_CONDITIONAL([HAVEPARALLELHDF5],[test "$have_parallel_hdf5" = "yes"])
# Check for lustre support. Attempted by default.
have_lustreapi="no"
AC_ARG_WITH([lustreapi],
[AS_HELP_STRING([--with-lustreapi=PATH],
[use the lustre api library for some striping control @<:@yes/no@:>@]
)],
[with_lustreapi="$withval"],
[with_lustreapi="yes"]
)
if test "x$with_lustreapi" != "xno"; then
if test "x$with_lustreapi" != "xyes" -a "x$with_lustreapi" != "x"; then
LUSTREAPI_LIBS="-L$with_lustreapi -llustreapi"
LUSTREAPI_INCS="-I$with_lustreapi/include"
else
LUSTREAPI_LIBS="-llustreapi"
LUSTREAPI_INCS=""
fi
AC_CHECK_LIB([lustreapi], [llapi_obd_statfs], [have_lustreapi="yes"],
[have_lustreapi="no"],[$LUSTREAPI_LIBS])
if test "$have_lustreapi" = "yes"; then
AC_DEFINE([HAVE_LUSTREAPI],1,[The lustre API library appears to be present.])
else
LUSTREAPI_LIBS=""
fi
fi
AC_SUBST([LUSTREAPI_LIBS])
AC_SUBST([LUSTREAPI_INCS])
AM_CONDITIONAL([HAVELUSTREAPI],[test -n "$LUSTREAPI_LIBS"])
# Check for grackle.
have_grackle="no"
AC_ARG_WITH([grackle],
......@@ -1308,7 +1485,6 @@ if test "x$with_grackle" != "xno"; then
have_grackle="yes"
echo $GRACKLE_LIBS
AS_VAR_APPEND([GRACKLE_LIBS], ["$FCLIBS"])
AC_CHECK_LIB(
......@@ -1317,8 +1493,24 @@ if test "x$with_grackle" != "xno"; then
[AC_DEFINE([HAVE_GRACKLE],1,[The GRACKLE library appears to be present.])
AC_DEFINE([CONFIG_BFLOAT_8],1,[Use doubles in grackle])
],
[AC_MSG_ERROR(Cannot find grackle library! You need to have a version >= 3.1.1)],
[AC_MSG_ERROR(Cannot find grackle library! Please consult the documentation for specific version required.)],
[$GRACKLE_LIBS])
AC_CHECK_LIB(
[grackle],
[set_velocity_units],
[ : ], # : means do nothing. Leaving this argument empty triggers AC default behaviour, which breaks stuff down the line.
[AC_MSG_ERROR(Wrong grackle library version. Please consult the documentation for specifics.)],
[$GRACKLE_LIBS])
AC_CHECK_LIB(
[grackle],
[get_grackle_version],
[ : ], # : means do nothing
[AC_MSG_ERROR(Wrong grackle library version. Please consult the documentation for specifics.)],
[$GRACKLE_LIBS])
fi
AC_SUBST([GRACKLE_LIBS])
AC_SUBST([GRACKLE_INCS])
......@@ -1336,7 +1528,7 @@ AC_ARG_WITH([velociraptor],
if test "x$with_velociraptor" != "xno"; then
if test "x$with_velociraptor" != "xyes" -a "x$with_velociraptor" != "x"; then
VELOCIRAPTOR_LIBS="-L$with_velociraptor -lvelociraptor -lstdc++ -lhdf5"
CFLAGS="$CFLAGS -fopenmp"
CFLAGS="$CFLAGS $OPENMP_CFLAGS"
else
VELOCIRAPTOR_LIBS=""
fi
......@@ -1472,14 +1664,30 @@ if test "$enable_lightcone" = "yes"; then
# Also need to make sure we have GSL if we're making lightcones
if test "$have_gsl" != "yes"; then
AC_MSG_ERROR([Lightcone output requires GSL. Please configure with --with-gsl.])
fi
fi
else
have_chealpix="no"
fi
# Check for floating-point execeptions
AC_CHECK_FUNC(feenableexcept, AC_DEFINE([HAVE_FE_ENABLE_EXCEPT],[1],
[Defined if the floating-point exception can be enabled using non-standard GNU functions.]))
# Check for floating-point exception trapping support.
#
# We do not allow this to be enabled when optimizing as compilers do operations
# which are unsafe for speed. This can result in FPEs on valid vector
# operations when additional padding is used. This has been seen on clang and
# GCC based compilers.
if test "$enable_opt" != "yes"; then
if test "$ax_cv_c_compiler_vendor" != "oneapi"; then
AC_CHECK_FUNC(feenableexcept, AC_DEFINE([HAVE_FE_ENABLE_EXCEPT],[1],
[Defined if floating-point exceptions can be trapped.]))
else
# Default optimization for Intel is too high , -O2, so we also need
# to have debugging enabled which uses -O0 as well.
if test "$ax_enable_debug" != "no"; then
AC_CHECK_FUNC(feenableexcept, AC_DEFINE([HAVE_FE_ENABLE_EXCEPT],[1],
[Defined if floating-point exceptions can be trapped.]))
fi
fi
fi
# Check for setaffinity.
AC_CHECK_FUNC(pthread_setaffinity_np, AC_DEFINE([HAVE_SETAFFINITY],[1],
......@@ -1540,10 +1748,10 @@ AC_SUBST([NUMA_LIBS])
# Check for Sundials (required for the SPHM1RT library).
# There is a problems with the headers of this library
# as they do not pass the strict prototypes check when
# installed outside of the system directories. So we
# need to do this check in two phases.
# There is a problems with the headers of this library
# as they do not pass the strict prototypes check when
# installed outside of the system directories. So we
# need to do this check in two phases.
have_sundials="no"
SUNDIALS_LIBS=""
SUNDIALS_INCS=""
......@@ -1572,22 +1780,22 @@ if test "x$with_sundials" != "xno"; then
AC_DEFINE([HAVE_SUNDIALS],1,[The SUNDIALS library is present.])
else
if test "x$with_sundials" != "xyes" -a "x$with_sundials" != "x"; then
# It might be that the libraries are in
# /lib64 rather than /lib
# It might be that the libraries are in
# /lib64 rather than /lib
SUNDIALS_LIBS="-L$with_sundials/lib64 -lsundials_cvode -lsundials_nvecserial -lsundials_sunlinsoldense -lsundials_sunmatrixdense"
# unset cached result of previous AC_CHECK_LIB
unset ac_cv_lib_sundials_cvode_CVode
AC_CHECK_LIB([sundials_cvode], [CVode], [have_sundials="yes"], [have_sundials="no"], $SUNDIALS_LIBS)
AC_CHECK_LIB([sundials_cvode], [CVode], [have_sundials="yes"], [have_sundials="no"], $SUNDIALS_LIBS)
if test "$have_sundials" == "yes"; then
AC_DEFINE([HAVE_SUNDIALS],1,[The SUNDIALS library is present.])
else
else
AC_MSG_ERROR("Failed to find a SUNDIALS library")
fi
fi
else
else
AC_MSG_ERROR("Failed to find a SUNDIALS library")
fi
fi
......@@ -1654,25 +1862,23 @@ AC_MSG_RESULT($rtc_ok)
# Special timers for the ARM v7 platforms (taken from FFTW-3 to match their cycle.h)
AC_ARG_ENABLE(armv7a-cntvct, [AS_HELP_STRING([--enable-armv7a-cntvct],[enable the cycle counter on Armv7a via the CNTVCT register])], have_armv7acntvct=$enableval)
if test "$have_armv7acntvct"x = "yes"x; then
AC_DEFINE(HAVE_ARMV7A_CNTVCT,1,[Define if you have enabled the CNTVCT cycle counter on ARMv7a])
AC_DEFINE(HAVE_ARMV7A_CNTVCT,1,[Define if you have enabled the CNTVCT cycle counter on ARMv7a])
fi
AC_ARG_ENABLE(armv7a-pmccntr, [AS_HELP_STRING([--enable-armv7a-pmccntr],[enable the cycle counter on Armv7a via the PMCCNTR register])], have_armv7apmccntr=$enableval)
if test "$have_armv7apmccntr"x = "yes"x; then
AC_DEFINE(HAVE_ARMV7A_PMCCNTR,1,[Define if you have enabled the PMCCNTR cycle counter on ARMv7a])
AC_DEFINE(HAVE_ARMV7A_PMCCNTR,1,[Define if you have enabled the PMCCNTR cycle counter on ARMv7a])
fi
# Check if we have native exp10 and exp10f functions. If not failback to our
# implementations. On Apple/CLANG we have __exp10, so also check for that
# Check if we have native exp10 and exp10f functions. If not fallback to our
# implementations. On Apple/CLANG/Homebrew gcc we have __exp10, so also check for that
# if the compiler is clang.
AC_CHECK_LIB([m],[exp10], [AC_DEFINE([HAVE_EXP10],1,[The exp10 function is present.])])
AC_CHECK_LIB([m],[exp10f], [AC_DEFINE([HAVE_EXP10F],1,[The exp10f function is present.])])
if test "$ax_cv_c_compiler_vendor" = "clang"; then
AC_CHECK_LIB([m],[__exp10], [AC_DEFINE([HAVE___EXP10],1,[The __exp10 function is present.])])
AC_CHECK_LIB([m],[__exp10f], [AC_DEFINE([HAVE___EXP10F],1,[The __exp10f function is present.])])
fi
AC_CHECK_LIB([m],[__exp10], [AC_DEFINE([HAVE___EXP10],1,[The __exp10 function is present.])])
AC_CHECK_LIB([m],[__exp10f], [AC_DEFINE([HAVE___EXP10F],1,[The __exp10f function is present.])])
# Check if we have native sincos and sincosf functions. If not failback to our
# Check if we have native sincos and sincosf functions. If not fallback to our
# implementations. On Apple/CLANG we have __sincos, so also check for that
# if the compiler is clang.
AC_CHECK_LIB([m],[sincos], [AC_DEFINE([HAVE_SINCOS],1,[The sincos function is present.])])
......@@ -1682,6 +1888,27 @@ if test "$ax_cv_c_compiler_vendor" = "clang"; then
AC_CHECK_LIB([m],[__sincosf], [AC_DEFINE([HAVE___SINCOSF],1,[The __sincosf function is present.])])
fi
# On Apple (CLANG or Homebrew gcc), check for __sincos and __sincosf inline functions in the headers.
AC_CHECK_HEADERS([math.h], [
AC_CHECK_DECLS([__sincos, __sincosf], [
AC_DEFINE([HAVE___SINCOS], 1, [The __sincos function is present.])
AC_DEFINE([HAVE___SINCOSF], 1, [The __sincosf function is present.])
], [], [#include <math.h>])
])
# The aocc compiler has optimized maths libraries that we should use. Check
# any clang for this support. Note do this after the basic check for maths
# as we need to make sure -lm follows. Also note needs -Ofast or -ffast-math
# so only when optimizing.
if test "$enable_opt" = "yes" -a "$ax_cv_c_compiler_vendor" = "clang"; then
have_almfast="yes"
AC_CHECK_LIB([almfast],[amd_fastexp],[LIBS="-fveclib=AMDLIBM -fsclrlib=AMDLIBM -lalmfast -lamdlibm $LIBS"],[have_almfast="no"],[-lamdlibm -lm])
if test "$have_almfast" = "no"; then
# Less optimized version.
AC_CHECK_LIB([amdlibm],[sqrt],,,[-lm])
fi
fi
# Check for glibc extension backtrace().
AC_CHECK_FUNCS([backtrace backtrace_symbols])
......@@ -1700,12 +1927,13 @@ if test "$enable_warn" != "no"; then
# AX_CFLAGS_WARN_ALL does not give good warning flags for the Intel compiler
# We will do this by hand instead and only default to the macro for unknown compilers
case "$ax_cv_c_compiler_vendor" in
gnu | clang)
gnu | clang | oneapi)
CFLAGS="$CFLAGS -Wall -Wextra -Wno-unused-parameter -Wshadow"
;;
intel)
CFLAGS="$CFLAGS -w2 -Wunused-variable -Wshadow"
;;
*)
AX_CFLAGS_WARN_ALL
;;
......@@ -1714,8 +1942,12 @@ if test "$enable_warn" != "no"; then
# Add a "choke on warning" flag if it exists
if test "$enable_warn" = "error"; then
case "$ax_cv_c_compiler_vendor" in
intel | gnu | clang)
intel | clang | oneapi)
CFLAGS="$CFLAGS -Werror"
;;
gnu)
# Fix for issue with IPO and GCC 14
CFLAGS="$CFLAGS -Werror -Wno-alloc-size-larger-than"
;;
esac
fi
......@@ -1756,9 +1988,9 @@ fi
AC_SUBST([NUMA_INCS])
# Second part of the Sundials library checks.
# We now decide if we need to use -isystem to
# get around the strict-prototypes problem. Assumes
# Second part of the Sundials library checks.
# We now decide if we need to use -isystem to
# get around the strict-prototypes problem. Assumes
# isystem is available when strict-prototypes is.
if test "x$with_sundials" != "xno"; then
if test "x$with_sundials" != "xyes" -a "x$with_sundials" != "x"; then
......@@ -1771,7 +2003,7 @@ if test "x$with_sundials" != "xno"; then
;;
esac
fi
fi
fi
AC_SUBST([SUNDIALS_INCS])
......@@ -1783,7 +2015,8 @@ AC_SUBST([SUNDIALS_INCS])
# As an example for this, see the call to AC_ARG_WITH for cooling.
AC_ARG_WITH([subgrid],
[AS_HELP_STRING([--with-subgrid=<subgrid>],
[Master switch for subgrid methods. Inexperienced user should start here. Options are: @<:@none, GEAR, AGORA, QLA, QLA-EAGLE, EAGLE, EAGLE-XL, SPIN_JET_EAGLE default: none@:>@]
[Master switch for subgrid methods. Inexperienced user should
start here. Options are: @<:@none, GEAR, GEAR-G3, AGORA, QLA, QLA-EAGLE, EAGLE, EAGLE-XL, SPIN_JET_EAGLE default: none@:>@]
)],
[with_subgrid="$withval"],
[with_subgrid=none]
......@@ -1810,12 +2043,24 @@ case "$with_subgrid" in
GEAR)
with_subgrid_cooling=grackle_0
with_subgrid_chemistry=GEAR_10
with_subgrid_pressure_floor=GEAR
with_subgrid_stars=GEAR
with_subgrid_star_formation=GEAR
with_subgrid_feedback=GEAR
with_subgrid_black_holes=none
with_subgrid_sink=GEAR
with_subgrid_extra_io=none
enable_fof=no
;;
GEAR-G3)
with_subgrid_cooling=grackle_3
with_subgrid_chemistry=GEAR_10
with_subgrid_pressure_floor=none
with_subgrid_stars=GEAR
with_subgrid_star_formation=GEAR
with_subgrid_feedback=GEAR
with_subgrid_black_holes=none
with_subgrid_sink=none
with_subgrid_sink=GEAR
with_subgrid_extra_io=none
enable_fof=no
;;
......@@ -1830,7 +2075,7 @@ case "$with_subgrid" in
with_subgrid_sink=none
with_subgrid_extra_io=none
enable_fof=no
;;
;;
QLA)
with_subgrid_cooling=QLA
with_subgrid_chemistry=QLA
......@@ -1895,6 +2140,19 @@ case "$with_subgrid" in
with_subgrid_extra_io=none
enable_fof=yes
;;
SPIN_JET_EAGLE-XL)
with_subgrid_cooling=PS2020
with_subgrid_chemistry=EAGLE
with_subgrid_tracers=EAGLE
with_subgrid_entropy_floor=EAGLE
with_subgrid_stars=EAGLE
with_subgrid_star_formation=EAGLE
with_subgrid_feedback=EAGLE
with_subgrid_black_holes=SPIN_JET
with_subgrid_sink=none
with_subgrid_extra_io=none
enable_fof=yes
;;
*)
AC_MSG_ERROR([Unknown subgrid choice: $with_subgrid])
;;
......@@ -1965,7 +2223,7 @@ fi
# Hydro scheme.
AC_ARG_WITH([hydro],
[AS_HELP_STRING([--with-hydro=<scheme>],
[Hydro dynamics to use @<:@gadget2, minimal, pressure-entropy, pressure-energy, pressure-energy-monaghan, phantom, gizmo-mfv, gizmo-mfm, shadowfax, planetary, sphenix, gasoline, anarchy-pu default: sphenix@:>@]
[Hydro dynamics to use @<:@gadget2, minimal, pressure-entropy, pressure-energy, pressure-energy-monaghan, phantom, gizmo-mfv, gizmo-mfm, shadowswift, planetary, remix, sphenix, gasoline, anarchy-pu default: sphenix@:>@]
)],
[with_hydro="$withval"],
[with_hydro="sphenix"]
......@@ -1996,18 +2254,25 @@ case "$with_hydro" in
gizmo-mfv)
AC_DEFINE([GIZMO_MFV_SPH], [1], [GIZMO MFV SPH])
need_riemann_solver=yes
hydro_does_mass_flux=yes
;;
gizmo-mfm)
AC_DEFINE([GIZMO_MFM_SPH], [1], [GIZMO MFM SPH])
need_riemann_solver=yes
;;
shadowfax)
AC_DEFINE([SHADOWFAX_SPH], [1], [Shadowfax SPH])
shadowswift)
AC_DEFINE([SHADOWSWIFT], [1], [ShadowSWIFT hydrodynamics])
AC_DEFINE([MOVING_MESH_HYDRO], [1], [Moving mesh hydrodynamics])
need_moving_mesh=yes
need_riemann_solver=yes
hydro_does_mass_flux=yes
;;
planetary)
AC_DEFINE([PLANETARY_SPH], [1], [Planetary SPH])
;;
remix)
AC_DEFINE([REMIX_SPH], [1], [REMIX SPH])
;;
sphenix)
AC_DEFINE([SPHENIX_SPH], [1], [SPHENIX SPH])
;;
......@@ -2050,8 +2315,8 @@ fi
if test "$with_hydro" = "gizmo-mfv" -a "$with_spmhd" != "none"; then
AC_MSG_ERROR([Cannot use an SPMHD scheme alongside a gizmo hydro solver!"])
fi
if test "$with_hydro" = "shadowfax" -a "$with_spmhd" != "none"; then
AC_MSG_ERROR([Cannot use an SPMHD scheme alongside a gizmo hydro solver!"])
if test "$with_hydro" = "shadowswift" -a "$with_spmhd" != "none"; then
AC_MSG_ERROR([Cannot use an SPMHD scheme alongside a moving mesh hydro solver!"])
fi
# Check if debugging interactions stars is switched on.
......@@ -2173,7 +2438,7 @@ esac
# Equation of state
AC_ARG_WITH([equation-of-state],
[AS_HELP_STRING([--with-equation-of-state=<EoS>],
[equation of state @<:@ideal-gas, isothermal-gas, planetary default: ideal-gas@:>@]
[equation of state @<:@ideal-gas, isothermal-gas, barotropic-gas, planetary default: ideal-gas@:>@]
)],
[with_eos="$withval"],
[with_eos="ideal-gas"]
......@@ -2184,6 +2449,9 @@ case "$with_eos" in
;;
isothermal-gas)
AC_DEFINE([EOS_ISOTHERMAL_GAS], [1], [Isothermal gas equation of state])
;;
barotropic-gas)
AC_DEFINE([EOS_BAROTROPIC_GAS], [1], [Barotropic gas equation of state])
;;
planetary)
AC_DEFINE([EOS_PLANETARY], [1], [All planetary equations of state])
......@@ -2219,6 +2487,34 @@ case "$with_gamma" in
;;
esac
# Adaptive softening
AC_ARG_WITH([adaptive-softening],
[AS_HELP_STRING([--with-adaptive-softening=<yes/no>],
[Adaptive softening @<:@no, yes, default: no@:>@]
)],
[with_adaptive_softening="$withval"],
[with_adaptive_softening="no"]
)
case "$with_adaptive_softening" in
no)
AC_DEFINE([FIXED_SOFTENING], [1], [No adaptive softening])
;;
yes)
AC_DEFINE([ADAPTIVE_SOFTENING], [1], [Adaptive softening])
;;
*)
AC_MSG_ERROR([Unknown adaptive softening: $with_adaptive_softening])
;;
esac
# Verify that the configuration is allowed
if test "x$with_adaptive_softening" = "xyes" -a "$with_kernel" != "wendland-C2"; then
AC_MSG_ERROR([Adaptive softening scheme requires the usage of the Wendland-C2 kernel!])
fi
if test "x$with_adaptive_softening" = "xyes" -a "$with_gravity" != "with-multi-softening"; then
AC_MSG_ERROR([Adaptive softening scheme requires the usage of the multi-softening gravity scheme!])
fi
# Riemann solver
AC_ARG_WITH([riemann-solver],
[AS_HELP_STRING([--with-riemann-solver=<solver>],
......@@ -2249,6 +2545,32 @@ if test "x$need_riemann_solver" = "xyes" -a "$with_riemann" = "none"; then
AC_MSG_ERROR([Hydro scheme $with_hydro requires selection of a Riemann solver!])
fi
# Moving mesh
AC_ARG_ENABLE([moving-mesh],
[AS_HELP_STRING([--enable-moving-mesh],
[enable the moving mesh computation]
)],
[enable_moving_mesh="${enableval}"],
[enable_moving_mesh="no"]
)
if test "x$need_moving_mesh" = "xyes"; then
enable_moving_mesh="yes"
fi
if test "$enable_moving_mesh" = "yes"; then
if test "$have_gmp" = "no"; then
AC_MSG_ERROR([GMP is required when using moving mesh!])
fi
if test "$have_gsl" = "no"; then
AC_MSG_ERROR([GSL is required when using moving mesh!])
fi
AC_DEFINE([MOVING_MESH], [1], [Unstructured Voronoi mesh])
fi
# Hydro does mass flux?
if test "x$hydro_does_mass_flux" = "xyes"; then
AC_DEFINE([HYDRO_DOES_MASS_FLUX], [1], [Hydro scheme with mass fluxes])
fi
# chemistry function
AC_ARG_WITH([chemistry],
[AS_HELP_STRING([--with-chemistry=<function>],
......@@ -2282,7 +2604,7 @@ case "$with_chemistry" in
AGORA)
AC_DEFINE([CHEMISTRY_AGORA], [1], [Chemistry taken from the AGORA model])
with_chemistry_name="AGORA"
;;
;;
QLA)
AC_DEFINE([CHEMISTRY_QLA], [1], [Chemistry taken from the Quick-Lyman-alpha model])
with_chemistry_name="QLA"
......@@ -2464,7 +2786,7 @@ case "$with_stars" in
;;
GEAR)
AC_DEFINE([STARS_GEAR], [1], [GEAR stellar model])
;;
;;
basic)
AC_DEFINE([STARS_BASIC], [1], [Basic stellar model])
;;
......@@ -2514,7 +2836,7 @@ case "$with_feedback" in
AGORA)
AC_DEFINE([FEEDBACK_AGORA], [1], [AGORA stellar feedback and evolution model])
with_feedback_name="AGORA"
;;
;;
none)
AC_DEFINE([FEEDBACK_NONE], [1], [No feedback])
;;
......@@ -2598,6 +2920,9 @@ case "$with_sink" in
none)
AC_DEFINE([SINK_NONE], [1], [No sink particle model])
;;
Basic)
AC_DEFINE([SINK_BASIC], [1], [Simple, self-contained sink model with only Bondi-Hoyle accretion and no SF.])
;;
GEAR)
AC_DEFINE([SINK_GEAR], [1], [GEAR sink particle model])
;;
......@@ -2606,10 +2931,37 @@ case "$with_sink" in
;;
esac
# Forcing terms
AC_ARG_WITH([forcing],
[AS_HELP_STRING([--with-forcing=<term>],
[Hydrodynamics forcing terms @<:@none, roberts-flow, roberts-flow-acceleration , abc-flowdefault: none@:>@]
)],
[with_forcing="$withval"],
[with_forcing="none"]
)
case "$with_forcing" in
none)
AC_DEFINE([FORCING_NONE], [1], [No external forcing terms])
;;
roberts-flow)
AC_DEFINE([FORCING_ROBERTS_FLOW], [1], [Roberts' flow external forcing terms])
;;
roberts-flow-acceleration)
AC_DEFINE([FORCING_ROBERTS_FLOW_ACCELERATION], [1], [Roberts' flow external forcing terms entering the equations as an acceleration term])
;;
abc-flow)
AC_DEFINE([FORCING_ABC_FLOW], [1], [ABC flow external forcing terms])
;;
*)
AC_MSG_ERROR([Unknown external forcing term: $with_forcing])
;;
esac
# External potential
AC_ARG_WITH([ext-potential],
[AS_HELP_STRING([--with-ext-potential=<pot>],
[external potential @<:@none, point-mass, point-mass-softened, isothermal, nfw, nfw-mn, hernquist, hernquist-sdmh05, disc-patch, sine-wave, constant, default: none@:>@]
[external potential @<:@none, point-mass, point-mass-softened, isothermal, nfw, nfw-mn, hernquist, hernquist-sdmh05, disc-patch, sine-wave, MWPotential2014, constant, default: none@:>@]
)],
[with_potential="$withval"],
[with_potential="none"]
......@@ -2645,6 +2997,9 @@ case "$with_potential" in
point-mass-softened)
AC_DEFINE([EXTERNAL_POTENTIAL_POINTMASS_SOFT], [1], [Softened point-mass potential with form 1/(r^2 + softening^2).])
;;
MWPotential2014)
AC_DEFINE([EXTERNAL_POTENTIAL_MWPotential2014], [1], [Milky-Way like potential composed of a Navarro-Frenk-White + Miyamoto-Nagai disk + Power spherical cuttoff external potential.])
;;
constant)
AC_DEFINE([EXTERNAL_POTENTIAL_CONSTANT], [1], [Constant gravitational acceleration.])
;;
......@@ -2654,9 +3009,9 @@ case "$with_potential" in
esac
# Entropy floor
AC_ARG_WITH([entropy-floor],
AC_ARG_WITH([entropy-floor],
[AS_HELP_STRING([--with-entropy-floor=<floor>],
[entropy floor @<:@none, QLA, EAGLE, default: none@:>@]
[entropy floor @<:@none, QLA, EAGLE, default: none@:>@]
)],
[with_entropy_floor="$withval"],
[with_entropy_floor="none"]
......@@ -2682,10 +3037,10 @@ case "$with_entropy_floor" in
*)
AC_MSG_ERROR([Unknown entropy floor model])
;;
esac
esac
# Pressure floor
AC_ARG_WITH([pressure-floor],
AC_ARG_WITH([pressure-floor],
[AS_HELP_STRING([--with-pressure-floor=<floor>],
[pressure floor @<:@none, GEAR, default: none@:>@
The hydro model needs to be compatible.]
......@@ -2711,12 +3066,12 @@ case "$with_pressure_floor" in
*)
AC_MSG_ERROR([Unknown pressure floor model])
;;
esac
esac
# Star formation
AC_ARG_WITH([star-formation],
AC_ARG_WITH([star-formation],
[AS_HELP_STRING([--with-star-formation=<sfm>],
[star formation @<:@none, QLA, EAGLE, GEAR, default: none@:>@]
[star formation @<:@none, QLA, EAGLE, GEAR, default: none@:>@]
)],
[with_star_formation="$withval"],
[with_star_formation="none"]
......@@ -2745,7 +3100,7 @@ case "$with_star_formation" in
*)
AC_MSG_ERROR([Unknown star formation model])
;;
esac
esac
AC_ARG_WITH([gadget2-physical-constants],
[AS_HELP_STRING([--with-gadget2-physical-constants],
......@@ -2771,7 +3126,7 @@ AC_DEFINE_UNQUOTED([SELF_GRAVITY_MULTIPOLE_ORDER], [$with_multipole_order], [Mul
# Radiative transfer scheme
AC_ARG_WITH([rt],
[AS_HELP_STRING([--with-rt=<scheme>],
[Radiative transfer scheme to use @<:@none, GEAR_*, SPHM1RT_*, debug default: none@:>@.
[Radiative transfer scheme to use @<:@none, GEAR_*, SPHM1RT_*, debug default: none@:>@.
For GEAR and SPHM1RT, the number of photon groups (e.g. GEAR_4) needs to be provided.]
)],
[with_rt="$withval"],
......@@ -2781,7 +3136,7 @@ AC_ARG_WITH([rt],
# For GEAR-RT scheme: Select a RT Riemann solver
AC_ARG_WITH([rt-riemann-solver],
[AS_HELP_STRING([--with-rt-riemann-solver=<scheme>],
[Riemann solver for the moments of the ratiadiative transfer equation with the M1 closure to use @<:@none, HLL, GLF, default: none@:>@.
[Riemann solver for the moments of the ratiadiative transfer equation with the M1 closure to use @<:@none, HLL, GLF, default: none@:>@.
For the GEAR RT scheme, you need to select one Riemann solver.]
)],
[with_rt_riemann_solver="$withval"],
......@@ -2811,6 +3166,7 @@ case "$with_rt" in
AC_DEFINE([RT_GEAR], [1], [GEAR M1 closure scheme])
number_group=${with_rt#*_}
AC_DEFINE_UNQUOTED([RT_NGROUPS], [$number_group], [Number of photon groups to follow])
AC_DEFINE([MPI_SYMMETRIC_FORCE_INTERACTION_RT], [1], [Do symmetric MPI interactions])
if test "$number_group" = "0"; then
AC_MSG_ERROR([GEAR-RT: Cannot work with zero photon groups])
......@@ -2825,9 +3181,14 @@ case "$with_rt" in
AC_DEFINE([SWIFT_RT_DEBUG_CHECKS], [1], [additional debugging checks for RT])
fi
if test "$with_hydro" != "gizmo-mfv"; then
AC_MSG_ERROR([GEAR-RT: Cannot work without gizmo-mfv hydro. Compile using --with-hydro=gizmo-mfv])
fi
case "$with_hydro" in
"gizmo-mfv" | "sphenix")
# allowed.
;;
*)
AC_MSG_ERROR([GEAR-RT: Cannot work without gizmo-mfv or sphenix hydro. Compile using --with-hydro=gizmo-mfv or --with-hydro=sphenix])
;;
esac
if test "$with_rt_riemann_solver" = "none"; then
AC_MSG_ERROR([GEAR-RT: You need to select an RT Riemann solver (--with-rt-riemann-solver=...)])
......@@ -2860,8 +3221,8 @@ case "$with_rt" in
fi
AC_MSG_CHECKING([for Sundials libraries])
AC_MSG_RESULT($have_sundials)
if test "$have_sundials" != "yes"; then
AC_MSG_ERROR([The Sundials library is not present. Sundials is required for the SPHM1RT module.])
if test "$have_sundials" != "yes"; then
AC_MSG_ERROR([The Sundials library is not present. Sundials is required for the SPHM1RT module.])
fi
;;
*)
......@@ -2899,6 +3260,9 @@ AM_CONDITIONAL([HAVEEAGLEKINETICFEEDBACK], [test "$with_feedback" = "EAGLE-kinet
# check if using grackle cooling
AM_CONDITIONAL([HAVEGRACKLECOOLING], [test "$with_cooling" = "grackle"])
# check if using EAGLE floor
AM_CONDITIONAL([HAVEEAGLEFLOOR], [test "$with_entropy_floor" = "EAGLE"])
# check if using gear feedback
AM_CONDITIONAL([HAVEGEARFEEDBACK], [test "$with_feedback" = "GEAR"])
......@@ -2941,6 +3305,9 @@ AM_CONDITIONAL([HAVESPHM1RTRT], [test "${with_rt:0:7}" = "SPHM1RT"])
# Check if using GEAR-RT radiative transfer
AM_CONDITIONAL([HAVEGEARRT], [test "${with_rt:0:4}" = "GEAR"])
# Check if using Moving mesh
AM_CONDITIONAL([HAVE_MOVING_MESH], [test "$enable_moving_mesh" = "yes"])
......@@ -2988,16 +3355,18 @@ AC_MSG_RESULT([
Compiler : $CC
- vendor : $ax_cv_c_compiler_vendor
- version : $ax_cv_c_compiler_version
- flags : $CFLAGS $OPENMP_CFLAGS
- flags : $CFLAGS
MPI enabled : $enable_mpi
HDF5 enabled : $with_hdf5
- parallel : $have_parallel_hdf5
LUSTRE API enabled : $have_lustreapi
METIS/ParMETIS : $have_metis / $have_parmetis
FFTW3 enabled : $have_fftw
- threaded/openmp : $have_threaded_fftw / $have_openmp_fftw
FFTW3 enabled : $have_fftw
- threaded/openmp : $have_threaded_fftw / $have_openmp_fftw
- MPI : $have_mpi_fftw
- ARM : $have_arm_fftw
GSL enabled : $have_gsl
GMP enabled : $have_gmp
HEALPix C enabled : $have_chealpix
libNUMA enabled : $have_numa
GRACKLE enabled : $have_grackle
......@@ -3008,6 +3377,7 @@ AC_MSG_RESULT([
VELOCIraptor enabled : $have_velociraptor
FoF activated: : $enable_fof
Lightcones enabled : $enable_lightcone
Moving-mesh enabled : $enable_moving_mesh
Hydro scheme : $with_hydro
Dimensionality : $with_dimension
......@@ -3016,6 +3386,7 @@ AC_MSG_RESULT([
Adiabatic index : $with_gamma
Riemann solver : $with_riemann
SPMHD scheme : $with_spmhd
Adaptive softening : $with_adaptive_softening
Gravity scheme : $with_gravity
Multipole order : $with_multipole_order
......@@ -3023,6 +3394,7 @@ AC_MSG_RESULT([
No gravity below ID : $no_gravity_below_id
Make gravity glass : $gravity_glass_making
External potential : $with_potential
Forcing terms : $with_forcing
Pressure floor : $with_pressure_floor
Entropy floor : $with_entropy_floor
......@@ -3036,7 +3408,7 @@ AC_MSG_RESULT([
Black holes model : $with_black_holes
Radiative transfer : $with_rt
Extra i/o : $with_extra_io
Atomic operations in tasks : $enable_atomics_within_tasks
Individual timers : $enable_timers
Task debugging : $enable_task_debugging
......
# Doxyfile 1.8.17
# Doxyfile 1.9.8
# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project.
......@@ -12,6 +12,16 @@
# For lists, items can also be appended using:
# TAG += value [value, ...]
# Values that contain spaces should be placed between quotes (\" \").
#
# Note:
#
# Use doxygen to compare the used configuration file with the template
# configuration file:
# doxygen -x [configFile]
# Use doxygen to compare the used configuration file with the template
# configuration file without replacing the environment variables or CMake type
# replacement variables:
# doxygen -x_noenv [configFile]
#---------------------------------------------------------------------------
# Project related configuration options
......@@ -60,16 +70,28 @@ PROJECT_LOGO =
OUTPUT_DIRECTORY = .
# If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub-
# directories (in 2 levels) under the output directory of each output format and
# will distribute the generated files over these directories. Enabling this
# If the CREATE_SUBDIRS tag is set to YES then doxygen will create up to 4096
# sub-directories (in 2 levels) under the output directory of each output format
# and will distribute the generated files over these directories. Enabling this
# option can be useful when feeding doxygen a huge amount of source files, where
# putting all generated files in the same directory would otherwise causes
# performance problems for the file system.
# performance problems for the file system. Adapt CREATE_SUBDIRS_LEVEL to
# control the number of sub-directories.
# The default value is: NO.
CREATE_SUBDIRS = NO
# Controls the number of sub-directories that will be created when
# CREATE_SUBDIRS tag is set to YES. Level 0 represents 16 directories, and every
# level increment doubles the number of directories, resulting in 4096
# directories at level 8 which is the default and also the maximum value. The
# sub-directories are organized in 2 levels, the first level always has a fixed
# number of 16 directories.
# Minimum value: 0, maximum value: 8, default value: 8.
# This tag requires that the tag CREATE_SUBDIRS is set to YES.
CREATE_SUBDIRS_LEVEL = 8
# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
# characters to appear in the names of generated files. If set to NO, non-ASCII
# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode
......@@ -81,26 +103,18 @@ ALLOW_UNICODE_NAMES = NO
# The OUTPUT_LANGUAGE tag is used to specify the language in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian,
# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages),
# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian,
# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian,
# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish,
# Ukrainian and Vietnamese.
# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Bulgarian,
# Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, Dutch, English
# (United States), Esperanto, Farsi (Persian), Finnish, French, German, Greek,
# Hindi, Hungarian, Indonesian, Italian, Japanese, Japanese-en (Japanese with
# English messages), Korean, Korean-en (Korean with English messages), Latvian,
# Lithuanian, Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese,
# Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish,
# Swedish, Turkish, Ukrainian and Vietnamese.
# The default value is: English.
OUTPUT_LANGUAGE = English
# The OUTPUT_TEXT_DIRECTION tag is used to specify the direction in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all generated output in the proper direction.
# Possible values are: None, LTR, RTL and Context.
# The default value is: None.
OUTPUT_TEXT_DIRECTION = None
# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member
# descriptions after the members that are listed in the file and class
# documentation (similar to Javadoc). Set to NO to disable this.
......@@ -217,6 +231,14 @@ QT_AUTOBRIEF = NO
MULTILINE_CPP_IS_BRIEF = NO
# By default Python docstrings are displayed as preformatted text and doxygen's
# special commands cannot be used. By setting PYTHON_DOCSTRING to NO the
# doxygen's special commands can be used and the contents of the docstring
# documentation blocks is shown as doxygen documentation.
# The default value is: YES.
PYTHON_DOCSTRING = YES
# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the
# documentation from any documented member that it re-implements.
# The default value is: YES.
......@@ -240,25 +262,19 @@ TAB_SIZE = 8
# the documentation. An alias has the form:
# name=value
# For example adding
# "sideeffect=@par Side Effects:\n"
# "sideeffect=@par Side Effects:^^"
# will allow you to put the command \sideeffect (or @sideeffect) in the
# documentation, which will result in a user-defined paragraph with heading
# "Side Effects:". You can put \n's in the value part of an alias to insert
# newlines (in the resulting output). You can put ^^ in the value part of an
# alias to insert a newline as if a physical newline was in the original file.
# When you need a literal { or } or , in the value part of an alias you have to
# escape them by means of a backslash (\), this can lead to conflicts with the
# commands \{ and \} for these it is advised to use the version @{ and @} or use
# a double escape (\\{ and \\})
# "Side Effects:". Note that you cannot put \n's in the value part of an alias
# to insert newlines (in the resulting output). You can put ^^ in the value part
# of an alias to insert a newline as if a physical newline was in the original
# file. When you need a literal { or } or , in the value part of an alias you
# have to escape them by means of a backslash (\), this can lead to conflicts
# with the commands \{ and \} for these it is advised to use the version @{ and
# @} or use a double escape (\\{ and \\})
ALIASES =
# This tag can be used to specify a number of word-keyword mappings (TCL only).
# A mapping has the form "name=value". For example adding "class=itcl::class"
# will allow you to use the command class in the itcl::class meaning.
TCL_SUBST =
# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources
# only. Doxygen will then generate output that is more tailored for C. For
# instance, some of the names that are used will be different. The list of all
......@@ -300,18 +316,21 @@ OPTIMIZE_OUTPUT_SLICE = NO
# extension. Doxygen has a built-in mapping, but you can override or extend it
# using this tag. The format is ext=language, where ext is a file extension, and
# language is one of the parsers supported by doxygen: IDL, Java, JavaScript,
# Csharp (C#), C, C++, D, PHP, md (Markdown), Objective-C, Python, Slice,
# Fortran (fixed format Fortran: FortranFixed, free formatted Fortran:
# Csharp (C#), C, C++, Lex, D, PHP, md (Markdown), Objective-C, Python, Slice,
# VHDL, Fortran (fixed format Fortran: FortranFixed, free formatted Fortran:
# FortranFree, unknown formatted Fortran: Fortran. In the later case the parser
# tries to guess whether the code is fixed or free formatted code, this is the
# default for Fortran type files), VHDL, tcl. For instance to make doxygen treat
# .inc files as Fortran files (default is PHP), and .f files as C (default is
# Fortran), use: inc=Fortran f=C.
# default for Fortran type files). For instance to make doxygen treat .inc files
# as Fortran files (default is PHP), and .f files as C (default is Fortran),
# use: inc=Fortran f=C.
#
# Note: For files without extension you can use no_extension as a placeholder.
#
# Note that for custom extensions you also need to set FILE_PATTERNS otherwise
# the files are not read by doxygen.
# the files are not read by doxygen. When specifying no_extension you should add
# * to the FILE_PATTERNS.
#
# Note see also the list of default file extension mappings.
EXTENSION_MAPPING =
......@@ -334,6 +353,17 @@ MARKDOWN_SUPPORT = YES
TOC_INCLUDE_HEADINGS = 5
# The MARKDOWN_ID_STYLE tag can be used to specify the algorithm used to
# generate identifiers for the Markdown headings. Note: Every identifier is
# unique.
# Possible values are: DOXYGEN use a fixed 'autotoc_md' string followed by a
# sequence number starting at 0 and GITHUB use the lower case version of title
# with any whitespace replaced by '-' and punctuation characters removed.
# The default value is: DOXYGEN.
# This tag requires that the tag MARKDOWN_SUPPORT is set to YES.
MARKDOWN_ID_STYLE = DOXYGEN
# When enabled doxygen tries to link words that correspond to documented
# classes, or namespaces to their corresponding documentation. Such a link can
# be prevented in individual cases by putting a % sign in front of the word or
......@@ -445,6 +475,27 @@ TYPEDEF_HIDES_STRUCT = NO
LOOKUP_CACHE_SIZE = 0
# The NUM_PROC_THREADS specifies the number of threads doxygen is allowed to use
# during processing. When set to 0 doxygen will based this on the number of
# cores available in the system. You can set it explicitly to a value larger
# than 0 to get more control over the balance between CPU load and processing
# speed. At this moment only the input processing can be done using multiple
# threads. Since this is still an experimental feature the default is set to 1,
# which effectively disables parallel processing. Please report any issues you
# encounter. Generating dot graphs in parallel is controlled by the
# DOT_NUM_THREADS setting.
# Minimum value: 0, maximum value: 32, default value: 1.
NUM_PROC_THREADS = 1
# If the TIMESTAMP tag is set different from NO then each generated page will
# contain the date or date and time when the page was generated. Setting this to
# NO can help when comparing the output of multiple runs.
# Possible values are: YES, NO, DATETIME and DATE.
# The default value is: NO.
TIMESTAMP = YES
#---------------------------------------------------------------------------
# Build related configuration options
#---------------------------------------------------------------------------
......@@ -508,6 +559,13 @@ EXTRACT_LOCAL_METHODS = NO
EXTRACT_ANON_NSPACES = NO
# If this flag is set to YES, the name of an unnamed parameter in a declaration
# will be determined by the corresponding definition. By default unnamed
# parameters remain unnamed in the output.
# The default value is: YES.
RESOLVE_UNNAMED_PARAMS = YES
# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all
# undocumented members inside documented classes or files. If set to NO these
# members will be included in the various overviews, but no documentation
......@@ -519,7 +577,8 @@ HIDE_UNDOC_MEMBERS = NO
# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all
# undocumented classes that are normally visible in the class hierarchy. If set
# to NO, these classes will be included in the various overviews. This option
# has no effect if EXTRACT_ALL is enabled.
# will also hide undocumented C++ concepts if enabled. This option has no effect
# if EXTRACT_ALL is enabled.
# The default value is: NO.
HIDE_UNDOC_CLASSES = NO
......@@ -545,12 +604,20 @@ HIDE_IN_BODY_DOCS = NO
INTERNAL_DOCS = NO
# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file
# names in lower-case letters. If set to YES, upper-case letters are also
# allowed. This is useful if you have classes or files whose names only differ
# in case and if your file system supports case sensitive file names. Windows
# (including Cygwin) ands Mac users are advised to set this option to NO.
# The default value is: system dependent.
# With the correct setting of option CASE_SENSE_NAMES doxygen will better be
# able to match the capabilities of the underlying filesystem. In case the
# filesystem is case sensitive (i.e. it supports files in the same directory
# whose names only differ in casing), the option must be set to YES to properly
# deal with such files in case they appear in the input. For filesystems that
# are not case sensitive the option should be set to NO to properly deal with
# output files written for symbols that only differ in casing, such as for two
# classes, one named CLASS and the other named Class, and to also support
# references to files without having to specify the exact matching casing. On
# Windows (including Cygwin) and MacOS, users should typically set this option
# to NO, whereas on Linux or other Unix flavors it should typically be set to
# YES.
# Possible values are: SYSTEM, NO and YES.
# The default value is: SYSTEM.
CASE_SENSE_NAMES = YES
......@@ -568,6 +635,12 @@ HIDE_SCOPE_NAMES = YES
HIDE_COMPOUND_REFERENCE= NO
# If the SHOW_HEADERFILE tag is set to YES then the documentation for a class
# will show which file needs to be included to use the class.
# The default value is: YES.
SHOW_HEADERFILE = YES
# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
# the files that are included by a file in the documentation of that file.
# The default value is: YES.
......@@ -725,7 +798,8 @@ FILE_VERSION_FILTER =
# output files in an output format independent way. To create the layout file
# that represents doxygen's defaults, run doxygen with the -l option. You can
# optionally specify a file name after the option, if omitted DoxygenLayout.xml
# will be used as the name of the layout file.
# will be used as the name of the layout file. See also section "Changing the
# layout of pages" for information.
#
# Note that if you run doxygen from a directory containing a file called
# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE
......@@ -771,24 +845,50 @@ WARNINGS = YES
WARN_IF_UNDOCUMENTED = YES
# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
# potential errors in the documentation, such as not documenting some parameters
# in a documented function, or documenting parameters that don't exist or using
# markup commands wrongly.
# potential errors in the documentation, such as documenting some parameters in
# a documented function twice, or documenting parameters that don't exist or
# using markup commands wrongly.
# The default value is: YES.
WARN_IF_DOC_ERROR = YES
# If WARN_IF_INCOMPLETE_DOC is set to YES, doxygen will warn about incomplete
# function parameter documentation. If set to NO, doxygen will accept that some
# parameters have no documentation without warning.
# The default value is: YES.
WARN_IF_INCOMPLETE_DOC = YES
# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that
# are documented, but have no documentation for their parameters or return
# value. If set to NO, doxygen will only warn about wrong or incomplete
# parameter documentation, but not about the absence of documentation. If
# EXTRACT_ALL is set to YES then this flag will automatically be disabled.
# value. If set to NO, doxygen will only warn about wrong parameter
# documentation, but not about the absence of documentation. If EXTRACT_ALL is
# set to YES then this flag will automatically be disabled. See also
# WARN_IF_INCOMPLETE_DOC
# The default value is: NO.
WARN_NO_PARAMDOC = NO
# If WARN_IF_UNDOC_ENUM_VAL option is set to YES, doxygen will warn about
# undocumented enumeration values. If set to NO, doxygen will accept
# undocumented enumeration values. If EXTRACT_ALL is set to YES then this flag
# will automatically be disabled.
# The default value is: NO.
WARN_IF_UNDOC_ENUM_VAL = NO
# If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when
# a warning is encountered.
# a warning is encountered. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS
# then doxygen will continue running as if WARN_AS_ERROR tag is set to NO, but
# at the end of the doxygen process doxygen will return with a non-zero status.
# If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS_PRINT then doxygen behaves
# like FAIL_ON_WARNINGS but in case no WARN_LOGFILE is defined doxygen will not
# write the warning messages in between other messages but write them at the end
# of a run, in case a WARN_LOGFILE is defined the warning messages will be
# besides being in the defined file also be shown at the end of a run, unless
# the WARN_LOGFILE is defined as - i.e. standard output (stdout) in that case
# the behavior will remain as with the setting FAIL_ON_WARNINGS.
# Possible values are: NO, YES, FAIL_ON_WARNINGS and FAIL_ON_WARNINGS_PRINT.
# The default value is: NO.
WARN_AS_ERROR = NO
......@@ -799,13 +899,27 @@ WARN_AS_ERROR = NO
# and the warning text. Optionally the format may contain $version, which will
# be replaced by the version of the file (if it could be obtained via
# FILE_VERSION_FILTER)
# See also: WARN_LINE_FORMAT
# The default value is: $file:$line: $text.
WARN_FORMAT = "$file:$line: $text"
# In the $text part of the WARN_FORMAT command it is possible that a reference
# to a more specific place is given. To make it easier to jump to this place
# (outside of doxygen) the user can define a custom "cut" / "paste" string.
# Example:
# WARN_LINE_FORMAT = "'vi $file +$line'"
# See also: WARN_FORMAT
# The default value is: at line $line of file $file.
WARN_LINE_FORMAT = "at line $line of file $file"
# The WARN_LOGFILE tag can be used to specify a file to which warning and error
# messages should be written. If left blank the output is written to standard
# error (stderr).
# error (stderr). In case the file specified cannot be opened for writing the
# warning and error messages are written to standard error. When as file - is
# specified the warning and error messages are written to standard output
# (stdout).
WARN_LOGFILE =
......@@ -825,40 +939,74 @@ INPUT = @top_srcdir@ \
@top_srcdir@/examples \
@top_srcdir@/src/hydro/Minimal \
@top_srcdir@/src/hydro/Gadget2 \
@top_srcdir@/src/hydro/SPHENIX \
@top_srcdir@/src/gravity/Default \
@top_srcdir@/src/gravity/MultiSoftening \
@top_srcdir@/src/riemann \
@top_srcdir@/src/potential/point_mass \
@top_srcdir@/src/equation_of_state/ideal_gas \
@top_srcdir@/src/equation_of_state/isothermal \
@top_srcdir@/src/equation_of_state/barotropic \
@top_srcdir@/src/cooling/const_du \
@top_srcdir@/src/cooling/const_lambda \
@top_srcdir@/src/cooling/Compton \
@top_srcdir@/src/cooling/EAGLE \
@top_srcdir@/src/cooling/PS2020 \
@top_srcdir@/src/cooling/grackle \
@top_srcdir@/src/chemistry/AGORA \
@top_srcdir@/src/chemistry/EAGLE \
@top_srcdir@/src/chemistry/GEAR \
@top_srcdir@/src/chemistry/QLA \
@top_srcdir@/src/chemistry/none \
@top_srcdir@/src/entropy_floor/EAGLE \
@top_srcdir@/src/pressure_floor/GEAR \
@top_srcdir@/src/star_formation/EAGLE \
@top_srcdir@/src/star_formation/GEAR \
@top_srcdir@/src/star_formation/QLA \
@top_srcdir@/src/star_formation/none \
@top_srcdir@/src/tracers/EAGLE \
@top_srcdir@/src/stars/EAGLE \
@top_srcdir@/src/stars/GEAR \
@top_srcdir@/src/stars/Basic \
@top_srcdir@/src/stars/None \
@top_srcdir@/src/feedback/none \
@top_srcdir@/src/feedback/AGORA \
@top_srcdir@/src/feedback/EAGLE \
@top_srcdir@/src/feedback/EAGLE_thermal \
@top_srcdir@/src/feedback/EAGLE_kinetic \
@top_srcdir@/src/feedback/GEAR \
@top_srcdir@/src/black_holes/Default \
@top_srcdir@/src/black_holes/EAGLE \
@top_srcdir@/src/black_holes/SPIN_JET \
@top_srcdir@/src/sink/Basic \
@top_srcdir@/src/sink/Default \
@top_srcdir@/src/sink/GEAR \
@top_srcdir@/src/forcing \
@top_srcdir@/src/fvpm_geometry \
@top_srcdir@/src/rt \
@top_srcdir@/src/extra_io \
@top_srcdir@/src/neutrino \
@top_srcdir@/csds
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses
# libiconv (or the iconv built into libc) for the transcoding. See the libiconv
# documentation (see: https://www.gnu.org/software/libiconv/) for the list of
# possible encodings.
# documentation (see:
# https://www.gnu.org/software/libiconv/) for the list of possible encodings.
# See also: INPUT_FILE_ENCODING
# The default value is: UTF-8.
INPUT_ENCODING = UTF-8
# This tag can be used to specify the character encoding of the source files
# that doxygen parses The INPUT_FILE_ENCODING tag can be used to specify
# character encoding on a per file pattern basis. Doxygen will compare the file
# name with each pattern and apply the encoding instead of the default
# INPUT_ENCODING) if there is a match. The character encodings are a list of the
# form: pattern=encoding (like *.php=ISO-8859-1). See cfg_input_encoding
# "INPUT_ENCODING" for further information on supported encodings.
INPUT_FILE_ENCODING =
# If the value of the INPUT tag contains directories, you can use the
# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and
# *.h) to filter out the source-files in the directories.
......@@ -867,13 +1015,15 @@ INPUT_ENCODING = UTF-8
# need to set EXTENSION_MAPPING for the extension otherwise the files are not
# read by doxygen.
#
# If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cpp,
# *.c++, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h,
# *.hh, *.hxx, *.hpp, *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc,
# *.m, *.markdown, *.md, *.mm, *.dox (to be provided as doxygen C comment),
# *.doc (to be provided as doxygen C comment), *.txt (to be provided as doxygen
# C comment), *.py, *.pyw, *.f90, *.f95, *.f03, *.f08, *.f, *.for, *.tcl, *.vhd,
# *.vhdl, *.ucf, *.qsf and *.ice.
# Note the list of default checked file patterns might differ from the list of
# default file extension mappings.
#
# If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cxxm,
# *.cpp, *.cppm, *.c++, *.c++m, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl,
# *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp, *.h++, *.ixx, *.l, *.cs, *.d, *.php,
# *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown, *.md, *.mm, *.dox (to be
# provided as doxygen C comment), *.py, *.pyw, *.f90, *.f95, *.f03, *.f08,
# *.f18, *.f, *.for, *.vhd, *.vhdl, *.ucf, *.qsf and *.ice.
FILE_PATTERNS =
......@@ -912,10 +1062,7 @@ EXCLUDE_PATTERNS = *.md
# (namespaces, classes, functions, etc.) that should be excluded from the
# output. The symbol name can be a fully qualified name, a word, or if the
# wildcard * is used, a substring. Examples: ANamespace, AClass,
# AClass::ANamespace, ANamespace::*Test
#
# Note that the wildcards are matched against the file with absolute path, so to
# exclude all test directories use the pattern */test/*
# ANamespace::AClass, ANamespace::*Test
EXCLUDE_SYMBOLS =
......@@ -960,6 +1107,11 @@ IMAGE_PATH =
# code is scanned, but not when the output code is generated. If lines are added
# or removed, the anchors will not be placed correctly.
#
# Note that doxygen will use the data processed and written to standard output
# for further processing, therefore nothing else, like debug statements or used
# commands (so in case of a Windows batch file always use @echo OFF), should be
# written to standard output.
#
# Note that for custom extensions or not directly supported extensions you also
# need to set EXTENSION_MAPPING for the extension otherwise the files are not
# properly processed by doxygen.
......@@ -1001,6 +1153,15 @@ FILTER_SOURCE_PATTERNS =
USE_MDFILE_AS_MAINPAGE =
# The Fortran standard specifies that for fixed formatted Fortran code all
# characters from position 72 are to be considered as comment. A common
# extension is to allow longer lines before the automatic comment starts. The
# setting FORTRAN_COMMENT_AFTER will also make it possible that longer lines can
# be processed before the automatic comment starts.
# Minimum value: 7, maximum value: 10000, default value: 72.
FORTRAN_COMMENT_AFTER = 72
#---------------------------------------------------------------------------
# Configuration options related to source browsing
#---------------------------------------------------------------------------
......@@ -1088,16 +1249,24 @@ USE_HTAGS = NO
VERBATIM_HEADERS = YES
# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the
# clang parser (see: http://clang.llvm.org/) for more accurate parsing at the
# cost of reduced performance. This can be particularly helpful with template
# rich C++ code for which doxygen's built-in parser lacks the necessary type
# information.
# clang parser (see:
# http://clang.llvm.org/) for more accurate parsing at the cost of reduced
# performance. This can be particularly helpful with template rich C++ code for
# which doxygen's built-in parser lacks the necessary type information.
# Note: The availability of this option depends on whether or not doxygen was
# generated with the -Duse_libclang=ON option for CMake.
# The default value is: NO.
CLANG_ASSISTED_PARSING = NO
# If the CLANG_ASSISTED_PARSING tag is set to YES and the CLANG_ADD_INC_PATHS
# tag is set to YES then doxygen will add the directory of each input to the
# include path.
# The default value is: YES.
# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
CLANG_ADD_INC_PATHS = YES
# If clang assisted parsing is enabled you can provide the compiler with command
# line options that you would normally use when invoking the compiler. Note that
# the include paths will already be set by doxygen for the files and directories
......@@ -1107,10 +1276,13 @@ CLANG_ASSISTED_PARSING = NO
CLANG_OPTIONS =
# If clang assisted parsing is enabled you can provide the clang parser with the
# path to the compilation database (see:
# http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html) used when the files
# were built. This is equivalent to specifying the "-p" option to a clang tool,
# such as clang-check. These options will then be passed to the parser.
# path to the directory containing a file called compile_commands.json. This
# file is the compilation database (see:
# http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html) containing the
# options used when the source files were built. This is equivalent to
# specifying the -p option to a clang tool, such as clang-check. These options
# will then be passed to the parser. Any options specified with CLANG_OPTIONS
# will be added as well.
# Note: The availability of this option depends on whether or not doxygen was
# generated with the -Duse_libclang=ON option for CMake.
......@@ -1127,17 +1299,11 @@ CLANG_DATABASE_PATH =
ALPHABETICAL_INDEX = YES
# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in
# which the alphabetical index list will be split.
# Minimum value: 1, maximum value: 20, default value: 5.
# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
COLS_IN_ALPHA_INDEX = 5
# In case all classes in a project start with a common prefix, all classes will
# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag
# can be used to specify a prefix (or a list of prefixes) that should be ignored
# while generating the index headers.
# The IGNORE_PREFIX tag can be used to specify a prefix (or a list of prefixes)
# that should be ignored while generating the index headers. The IGNORE_PREFIX
# tag works for classes, function and member names. The entity will be placed in
# the alphabetical list under the first letter of the entity name that remains
# after removing the prefix.
# This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
IGNORE_PREFIX =
......@@ -1216,7 +1382,12 @@ HTML_STYLESHEET =
# Doxygen will copy the style sheet files to the output directory.
# Note: The order of the extra style sheet files is of importance (e.g. the last
# style sheet in the list overrules the setting of the previous ones in the
# list). For an example see the documentation.
# list).
# Note: Since the styling of scrollbars can currently not be overruled in
# Webkit/Chromium, the styling will be left out of the default doxygen.css if
# one or more extra stylesheets have been specified. So if scrollbar
# customization is desired it has to be added explicitly. For an example see the
# documentation.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_EXTRA_STYLESHEET =
......@@ -1231,9 +1402,22 @@ HTML_EXTRA_STYLESHEET =
HTML_EXTRA_FILES =
# The HTML_COLORSTYLE tag can be used to specify if the generated HTML output
# should be rendered with a dark or light theme.
# Possible values are: LIGHT always generate light mode output, DARK always
# generate dark mode output, AUTO_LIGHT automatically set the mode according to
# the user preference, use light mode if no preference is set (the default),
# AUTO_DARK automatically set the mode according to the user preference, use
# dark mode if no preference is set and TOGGLE allow to user to switch between
# light and dark mode via a button.
# The default value is: AUTO_LIGHT.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_COLORSTYLE = AUTO_LIGHT
# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
# will adjust the colors in the style sheet and background images according to
# this color. Hue is specified as an angle on a colorwheel, see
# this color. Hue is specified as an angle on a color-wheel, see
# https://en.wikipedia.org/wiki/Hue for more information. For instance the value
# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300
# purple, and 360 is red again.
......@@ -1243,7 +1427,7 @@ HTML_EXTRA_FILES =
HTML_COLORSTYLE_HUE = 220
# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors
# in the HTML output. For a value of 0 the output will use grayscales only. A
# in the HTML output. For a value of 0 the output will use gray-scales only. A
# value of 255 will produce the most vivid colors.
# Minimum value: 0, maximum value: 255, default value: 100.
# This tag requires that the tag GENERATE_HTML is set to YES.
......@@ -1261,15 +1445,6 @@ HTML_COLORSTYLE_SAT = 100
HTML_COLORSTYLE_GAMMA = 80
# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
# page will contain the date and time when the page was generated. Setting this
# to YES can help to show when doxygen was last run and thus if the
# documentation is up to date.
# The default value is: NO.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_TIMESTAMP = YES
# If the HTML_DYNAMIC_MENUS tag is set to YES then the generated HTML
# documentation will contain a main index with vertical navigation menus that
# are dynamically created via JavaScript. If disabled, the navigation index will
......@@ -1289,6 +1464,13 @@ HTML_DYNAMIC_MENUS = YES
HTML_DYNAMIC_SECTIONS = NO
# If the HTML_CODE_FOLDING tag is set to YES then classes and functions can be
# dynamically folded and expanded in the generated HTML source code.
# The default value is: YES.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_CODE_FOLDING = YES
# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries
# shown in the various tree structured indices initially; the user can expand
# and collapse entries dynamically later on. Doxygen will expand the tree to
......@@ -1304,10 +1486,11 @@ HTML_INDEX_NUM_ENTRIES = 100
# If the GENERATE_DOCSET tag is set to YES, additional index files will be
# generated that can be used as input for Apple's Xcode 3 integrated development
# environment (see: https://developer.apple.com/xcode/), introduced with OSX
# 10.5 (Leopard). To create a documentation set, doxygen will generate a
# Makefile in the HTML output directory. Running make will produce the docset in
# that directory and running make install will install the docset in
# environment (see:
# https://developer.apple.com/xcode/), introduced with OSX 10.5 (Leopard). To
# create a documentation set, doxygen will generate a Makefile in the HTML
# output directory. Running make will produce the docset in that directory and
# running make install will install the docset in
# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at
# startup. See https://developer.apple.com/library/archive/featuredarticles/Doxy
# genXcode/_index.html for more information.
......@@ -1324,6 +1507,13 @@ GENERATE_DOCSET = NO
DOCSET_FEEDNAME = "Doxygen generated docs"
# This tag determines the URL of the docset feed. A documentation feed provides
# an umbrella under which multiple documentation sets from a single provider
# (such as a company or product suite) can be grouped.
# This tag requires that the tag GENERATE_DOCSET is set to YES.
DOCSET_FEEDURL =
# This tag specifies a string that should uniquely identify the documentation
# set bundle. This should be a reverse domain-name style string, e.g.
# com.mycompany.MyDocSet. Doxygen will append .docset to the name.
......@@ -1349,8 +1539,12 @@ DOCSET_PUBLISHER_NAME = Publisher
# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three
# additional HTML index files: index.hhp, index.hhc, and index.hhk. The
# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop
# (see: https://www.microsoft.com/en-us/download/details.aspx?id=21138) on
# Windows.
# on Windows. In the beginning of 2021 Microsoft took the original page, with
# a.o. the download links, offline the HTML help workshop was already many years
# in maintenance mode). You can download the HTML help workshop from the web
# archives at Installation executable (see:
# http://web.archive.org/web/20160201063255/http://download.microsoft.com/downlo
# ad/0/A/9/0A939EF6-E31C-430F-A3DF-DFAE7960D564/htmlhelp.exe).
#
# The HTML Help Workshop contains a compiler that can convert all HTML output
# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML
......@@ -1380,7 +1574,7 @@ CHM_FILE =
HHC_LOCATION =
# The GENERATE_CHI flag controls if a separate .chi index file is generated
# (YES) or that it should be included in the master .chm file (NO).
# (YES) or that it should be included in the main .chm file (NO).
# The default value is: NO.
# This tag requires that the tag GENERATE_HTMLHELP is set to YES.
......@@ -1407,6 +1601,16 @@ BINARY_TOC = NO
TOC_EXPAND = NO
# The SITEMAP_URL tag is used to specify the full URL of the place where the
# generated documentation will be placed on the server by the user during the
# deployment of the documentation. The generated sitemap is called sitemap.xml
# and placed on the directory specified by HTML_OUTPUT. In case no SITEMAP_URL
# is specified no sitemap is generated. For information about the sitemap
# protocol see https://www.sitemaps.org
# This tag requires that the tag GENERATE_HTML is set to YES.
SITEMAP_URL =
# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that
# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help
......@@ -1425,7 +1629,8 @@ QCH_FILE =
# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help
# Project output. For more information please see Qt Help Project / Namespace
# (see: https://doc.qt.io/archives/qt-4.8/qthelpproject.html#namespace).
# (see:
# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#namespace).
# The default value is: org.doxygen.Project.
# This tag requires that the tag GENERATE_QHP is set to YES.
......@@ -1433,8 +1638,8 @@ QHP_NAMESPACE = org.doxygen.Project
# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt
# Help Project output. For more information please see Qt Help Project / Virtual
# Folders (see: https://doc.qt.io/archives/qt-4.8/qthelpproject.html#virtual-
# folders).
# Folders (see:
# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#virtual-folders).
# The default value is: doc.
# This tag requires that the tag GENERATE_QHP is set to YES.
......@@ -1442,16 +1647,16 @@ QHP_VIRTUAL_FOLDER = doc
# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom
# filter to add. For more information please see Qt Help Project / Custom
# Filters (see: https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-
# filters).
# Filters (see:
# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters).
# This tag requires that the tag GENERATE_QHP is set to YES.
QHP_CUST_FILTER_NAME =
# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the
# custom filter to add. For more information please see Qt Help Project / Custom
# Filters (see: https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-
# filters).
# Filters (see:
# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters).
# This tag requires that the tag GENERATE_QHP is set to YES.
QHP_CUST_FILTER_ATTRS =
......@@ -1463,9 +1668,9 @@ QHP_CUST_FILTER_ATTRS =
QHP_SECT_FILTER_ATTRS =
# The QHG_LOCATION tag can be used to specify the location of Qt's
# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the
# generated .qhp file.
# The QHG_LOCATION tag can be used to specify the location (absolute path
# including file name) of Qt's qhelpgenerator. If non-empty doxygen will try to
# run qhelpgenerator on the generated .qhp file.
# This tag requires that the tag GENERATE_QHP is set to YES.
QHG_LOCATION =
......@@ -1508,16 +1713,28 @@ DISABLE_INDEX = NO
# to work a browser that supports JavaScript, DHTML, CSS and frames is required
# (i.e. any modern browser). Windows users are probably better off using the
# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can
# further fine-tune the look of the index. As an example, the default style
# sheet generated by doxygen has an example that shows how to put an image at
# the root of the tree instead of the PROJECT_NAME. Since the tree basically has
# the same information as the tab index, you could consider setting
# DISABLE_INDEX to YES when enabling this option.
# further fine tune the look of the index (see "Fine-tuning the output"). As an
# example, the default style sheet generated by doxygen has an example that
# shows how to put an image at the root of the tree instead of the PROJECT_NAME.
# Since the tree basically has the same information as the tab index, you could
# consider setting DISABLE_INDEX to YES when enabling this option.
# The default value is: NO.
# This tag requires that the tag GENERATE_HTML is set to YES.
GENERATE_TREEVIEW = NO
# When both GENERATE_TREEVIEW and DISABLE_INDEX are set to YES, then the
# FULL_SIDEBAR option determines if the side bar is limited to only the treeview
# area (value NO) or if it should extend to the full height of the window (value
# YES). Setting this to YES gives a layout similar to
# https://docs.readthedocs.io with more room for contents, but less room for the
# project logo, title, and description. If either GENERATE_TREEVIEW or
# DISABLE_INDEX is set to NO, this option has no effect.
# The default value is: NO.
# This tag requires that the tag GENERATE_HTML is set to YES.
FULL_SIDEBAR = NO
# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that
# doxygen will group on one line in the generated HTML documentation.
#
......@@ -1542,6 +1759,24 @@ TREEVIEW_WIDTH = 250
EXT_LINKS_IN_WINDOW = NO
# If the OBFUSCATE_EMAILS tag is set to YES, doxygen will obfuscate email
# addresses.
# The default value is: YES.
# This tag requires that the tag GENERATE_HTML is set to YES.
OBFUSCATE_EMAILS = YES
# If the HTML_FORMULA_FORMAT option is set to svg, doxygen will use the pdf2svg
# tool (see https://github.com/dawbarton/pdf2svg) or inkscape (see
# https://inkscape.org) to generate formulas as SVG images instead of PNGs for
# the HTML output. These images will generally look nicer at scaled resolutions.
# Possible values are: png (the default) and svg (looks nicer but requires the
# pdf2svg or inkscape tool).
# The default value is: png.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_FORMULA_FORMAT = png
# Use this tag to change the font size of LaTeX formulas included as images in
# the HTML documentation. When you change the font size after a successful
# doxygen run you need to manually remove any form_*.png images from the HTML
......@@ -1551,17 +1786,6 @@ EXT_LINKS_IN_WINDOW = NO
FORMULA_FONTSIZE = 10
# Use the FORMULA_TRANSPARENT tag to determine whether or not the images
# generated for formulas are transparent PNGs. Transparent PNGs are not
# supported properly for IE 6.0, but are supported on all modern browsers.
#
# Note that when changing this option you need to delete any form_*.png files in
# the HTML output directory before the changes have effect.
# The default value is: YES.
# This tag requires that the tag GENERATE_HTML is set to YES.
FORMULA_TRANSPARENT = YES
# The FORMULA_MACROFILE can contain LaTeX \newcommand and \renewcommand commands
# to create new LaTeX commands to be used in formulas as building blocks. See
# the section "Including formulas" for details.
......@@ -1579,11 +1803,29 @@ FORMULA_MACROFILE =
USE_MATHJAX = YES
# With MATHJAX_VERSION it is possible to specify the MathJax version to be used.
# Note that the different versions of MathJax have different requirements with
# regards to the different settings, so it is possible that also other MathJax
# settings have to be changed when switching between the different MathJax
# versions.
# Possible values are: MathJax_2 and MathJax_3.
# The default value is: MathJax_2.
# This tag requires that the tag USE_MATHJAX is set to YES.
MATHJAX_VERSION = MathJax_2
# When MathJax is enabled you can set the default output format to be used for
# the MathJax output. See the MathJax site (see:
# http://docs.mathjax.org/en/latest/output.html) for more details.
# the MathJax output. For more details about the output format see MathJax
# version 2 (see:
# http://docs.mathjax.org/en/v2.7-latest/output.html) and MathJax version 3
# (see:
# http://docs.mathjax.org/en/latest/web/components/output.html).
# Possible values are: HTML-CSS (which is slower, but has the best
# compatibility), NativeMML (i.e. MathML) and SVG.
# compatibility. This is the name for Mathjax version 2, for MathJax version 3
# this will be translated into chtml), NativeMML (i.e. MathML. Only supported
# for NathJax 2. For MathJax version 3 chtml will be used instead.), chtml (This
# is the name for Mathjax version 3, for MathJax version 2 this will be
# translated into HTML-CSS) and SVG.
# The default value is: HTML-CSS.
# This tag requires that the tag USE_MATHJAX is set to YES.
......@@ -1596,22 +1838,29 @@ MATHJAX_FORMAT = HTML-CSS
# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax
# Content Delivery Network so you can quickly see the result without installing
# MathJax. However, it is strongly recommended to install a local copy of
# MathJax from https://www.mathjax.org before deployment.
# The default value is: https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/.
# MathJax from https://www.mathjax.org before deployment. The default value is:
# - in case of MathJax version 2: https://cdn.jsdelivr.net/npm/mathjax@2
# - in case of MathJax version 3: https://cdn.jsdelivr.net/npm/mathjax@3
# This tag requires that the tag USE_MATHJAX is set to YES.
MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax
# extension names that should be enabled during MathJax rendering. For example
# for MathJax version 2 (see
# https://docs.mathjax.org/en/v2.7-latest/tex.html#tex-and-latex-extensions):
# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
# For example for MathJax version 3 (see
# http://docs.mathjax.org/en/latest/input/tex/extensions/index.html):
# MATHJAX_EXTENSIONS = ams
# This tag requires that the tag USE_MATHJAX is set to YES.
MATHJAX_EXTENSIONS =
# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces
# of code that will be used on startup of the MathJax code. See the MathJax site
# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an
# (see:
# http://docs.mathjax.org/en/v2.7-latest/output.html) for more details. For an
# example see the documentation.
# This tag requires that the tag USE_MATHJAX is set to YES.
......@@ -1658,7 +1907,8 @@ SERVER_BASED_SEARCH = NO
#
# Doxygen ships with an example indexer (doxyindexer) and search engine
# (doxysearch.cgi) which are based on the open source search engine library
# Xapian (see: https://xapian.org/).
# Xapian (see:
# https://xapian.org/).
#
# See the section "External Indexing and Searching" for details.
# The default value is: NO.
......@@ -1671,8 +1921,9 @@ EXTERNAL_SEARCH = NO
#
# Doxygen ships with an example indexer (doxyindexer) and search engine
# (doxysearch.cgi) which are based on the open source search engine library
# Xapian (see: https://xapian.org/). See the section "External Indexing and
# Searching" for details.
# Xapian (see:
# https://xapian.org/). See the section "External Indexing and Searching" for
# details.
# This tag requires that the tag SEARCHENGINE is set to YES.
SEARCHENGINE_URL =
......@@ -1767,7 +2018,7 @@ COMPACT_LATEX = NO
# The default value is: a4.
# This tag requires that the tag GENERATE_LATEX is set to YES.
PAPER_TYPE = a4wide
PAPER_TYPE = a4
# The EXTRA_PACKAGES tag can be used to specify one or more LaTeX package names
# that should be included in the LaTeX output. The package can be specified just
......@@ -1781,29 +2032,31 @@ PAPER_TYPE = a4wide
EXTRA_PACKAGES =
# The LATEX_HEADER tag can be used to specify a personal LaTeX header for the
# generated LaTeX document. The header should contain everything until the first
# chapter. If it is left blank doxygen will generate a standard header. See
# section "Doxygen usage" for information on how to let doxygen write the
# default header to a separate file.
# The LATEX_HEADER tag can be used to specify a user-defined LaTeX header for
# the generated LaTeX document. The header should contain everything until the
# first chapter. If it is left blank doxygen will generate a standard header. It
# is highly recommended to start with a default header using
# doxygen -w latex new_header.tex new_footer.tex new_stylesheet.sty
# and then modify the file new_header.tex. See also section "Doxygen usage" for
# information on how to generate the default header that doxygen normally uses.
#
# Note: Only use a user-defined header if you know what you are doing! The
# following commands have a special meaning inside the header: $title,
# $datetime, $date, $doxygenversion, $projectname, $projectnumber,
# $projectbrief, $projectlogo. Doxygen will replace $title with the empty
# string, for the replacement values of the other commands the user is referred
# to HTML_HEADER.
# Note: Only use a user-defined header if you know what you are doing!
# Note: The header is subject to change so you typically have to regenerate the
# default header when upgrading to a newer version of doxygen. The following
# commands have a special meaning inside the header (and footer): For a
# description of the possible markers and block names see the documentation.
# This tag requires that the tag GENERATE_LATEX is set to YES.
LATEX_HEADER =
# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for the
# generated LaTeX document. The footer should contain everything after the last
# chapter. If it is left blank doxygen will generate a standard footer. See
# The LATEX_FOOTER tag can be used to specify a user-defined LaTeX footer for
# the generated LaTeX document. The footer should contain everything after the
# last chapter. If it is left blank doxygen will generate a standard footer. See
# LATEX_HEADER for more information on how to generate a default footer and what
# special commands can be used inside the footer.
#
# Note: Only use a user-defined footer if you know what you are doing!
# special commands can be used inside the footer. See also section "Doxygen
# usage" for information on how to generate the default footer that doxygen
# normally uses. Note: Only use a user-defined footer if you know what you are
# doing!
# This tag requires that the tag GENERATE_LATEX is set to YES.
LATEX_FOOTER =
......@@ -1836,18 +2089,26 @@ LATEX_EXTRA_FILES =
PDF_HYPERLINKS = YES
# If the USE_PDFLATEX tag is set to YES, doxygen will use pdflatex to generate
# the PDF file directly from the LaTeX files. Set this option to YES, to get a
# higher quality PDF documentation.
# If the USE_PDFLATEX tag is set to YES, doxygen will use the engine as
# specified with LATEX_CMD_NAME to generate the PDF file directly from the LaTeX
# files. Set this option to YES, to get a higher quality PDF documentation.
#
# See also section LATEX_CMD_NAME for selecting the engine.
# The default value is: YES.
# This tag requires that the tag GENERATE_LATEX is set to YES.
USE_PDFLATEX = YES
# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \batchmode
# command to the generated LaTeX files. This will instruct LaTeX to keep running
# if errors occur, instead of asking the user for help. This option is also used
# when generating formulas in HTML.
# The LATEX_BATCHMODE tag signals the behavior of LaTeX in case of an error.
# Possible values are: NO same as ERROR_STOP, YES same as BATCH, BATCH In batch
# mode nothing is printed on the terminal, errors are scrolled as if <return> is
# hit at every error; missing files that TeX tries to input or request from
# keyboard input (\read on a not open input stream) cause the job to abort,
# NON_STOP In nonstop mode the diagnostic message will appear on the terminal,
# but there is no possibility of user interaction just like in batch mode,
# SCROLL In scroll mode, TeX will stop only for missing files to input or if
# keyboard input is necessary and ERROR_STOP In errorstop mode, TeX will stop at
# each error, asking for user intervention.
# The default value is: NO.
# This tag requires that the tag GENERATE_LATEX is set to YES.
......@@ -1860,16 +2121,6 @@ LATEX_BATCHMODE = NO
LATEX_HIDE_INDICES = NO
# If the LATEX_SOURCE_CODE tag is set to YES then doxygen will include source
# code with syntax highlighting in the LaTeX output.
#
# Note that which sources are shown also depends on other settings such as
# SOURCE_BROWSER.
# The default value is: NO.
# This tag requires that the tag GENERATE_LATEX is set to YES.
LATEX_SOURCE_CODE = NO
# The LATEX_BIB_STYLE tag can be used to specify the style to use for the
# bibliography, e.g. plainnat, or ieeetr. See
# https://en.wikipedia.org/wiki/BibTeX and \cite for more info.
......@@ -1878,14 +2129,6 @@ LATEX_SOURCE_CODE = NO
LATEX_BIB_STYLE = plain
# If the LATEX_TIMESTAMP tag is set to YES then the footer of each generated
# page will contain the date and time when the page was generated. Setting this
# to NO can help when comparing the output of multiple runs.
# The default value is: NO.
# This tag requires that the tag GENERATE_LATEX is set to YES.
LATEX_TIMESTAMP = NO
# The LATEX_EMOJI_DIRECTORY tag is used to specify the (relative or absolute)
# path from which the emoji images will be read. If a relative path is entered,
# it will be relative to the LATEX_OUTPUT directory. If left blank the
......@@ -1950,16 +2193,6 @@ RTF_STYLESHEET_FILE =
RTF_EXTENSIONS_FILE =
# If the RTF_SOURCE_CODE tag is set to YES then doxygen will include source code
# with syntax highlighting in the RTF output.
#
# Note that which sources are shown also depends on other settings such as
# SOURCE_BROWSER.
# The default value is: NO.
# This tag requires that the tag GENERATE_RTF is set to YES.
RTF_SOURCE_CODE = NO
#---------------------------------------------------------------------------
# Configuration options related to the man page output
#---------------------------------------------------------------------------
......@@ -2056,27 +2289,44 @@ GENERATE_DOCBOOK = NO
DOCBOOK_OUTPUT = docbook
# If the DOCBOOK_PROGRAMLISTING tag is set to YES, doxygen will include the
# program listings (including syntax highlighting and cross-referencing
# information) to the DOCBOOK output. Note that enabling this will significantly
# increase the size of the DOCBOOK output.
# The default value is: NO.
# This tag requires that the tag GENERATE_DOCBOOK is set to YES.
DOCBOOK_PROGRAMLISTING = NO
#---------------------------------------------------------------------------
# Configuration options for the AutoGen Definitions output
#---------------------------------------------------------------------------
# If the GENERATE_AUTOGEN_DEF tag is set to YES, doxygen will generate an
# AutoGen Definitions (see http://autogen.sourceforge.net/) file that captures
# AutoGen Definitions (see https://autogen.sourceforge.net/) file that captures
# the structure of the code including all documentation. Note that this feature
# is still experimental and incomplete at the moment.
# The default value is: NO.
GENERATE_AUTOGEN_DEF = NO
#---------------------------------------------------------------------------
# Configuration options related to Sqlite3 output
#---------------------------------------------------------------------------
# If the GENERATE_SQLITE3 tag is set to YES doxygen will generate a Sqlite3
# database with symbols found by doxygen stored in tables.
# The default value is: NO.
GENERATE_SQLITE3 = NO
# The SQLITE3_OUTPUT tag is used to specify where the Sqlite3 database will be
# put. If a relative path is entered the value of OUTPUT_DIRECTORY will be put
# in front of it.
# The default directory is: sqlite3.
# This tag requires that the tag GENERATE_SQLITE3 is set to YES.
SQLITE3_OUTPUT = sqlite3
# The SQLITE3_OVERWRITE_DB tag is set to YES, the existing doxygen_sqlite3.db
# database file will be recreated with each doxygen run. If set to NO, doxygen
# will warn if an a database file is already found and not modify it.
# The default value is: YES.
# This tag requires that the tag GENERATE_SQLITE3 is set to YES.
SQLITE3_RECREATE_DB = YES
#---------------------------------------------------------------------------
# Configuration options related to the Perl module output
#---------------------------------------------------------------------------
......@@ -2151,7 +2401,8 @@ SEARCH_INCLUDES = YES
# The INCLUDE_PATH tag can be used to specify one or more directories that
# contain include files that are not input files but should be processed by the
# preprocessor.
# preprocessor. Note that the INCLUDE_PATH is not recursive, so the setting of
# RECURSIVE has no effect here.
# This tag requires that the tag SEARCH_INCLUDES is set to YES.
INCLUDE_PATH = @top_srcdir@/src
......@@ -2172,7 +2423,7 @@ INCLUDE_FILE_PATTERNS =
# recursively expanded use the := operator instead of the = operator.
# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
PREDEFINED = "__attribute__(x)= " \
PREDEFINED = "__attribute__(x)=" \
HAVE_HDF5 \
HAVE_FFTW \
WITH_MPI \
......@@ -2223,15 +2474,15 @@ TAGFILES =
GENERATE_TAGFILE =
# If the ALLEXTERNALS tag is set to YES, all external class will be listed in
# the class index. If set to NO, only the inherited external classes will be
# listed.
# If the ALLEXTERNALS tag is set to YES, all external classes and namespaces
# will be listed in the class and namespace index. If set to NO, only the
# inherited external classes will be listed.
# The default value is: NO.
ALLEXTERNALS = NO
# If the EXTERNAL_GROUPS tag is set to YES, all external groups will be listed
# in the modules index. If set to NO, only the current project's groups will be
# in the topic index. If set to NO, only the current project's groups will be
# listed.
# The default value is: YES.
......@@ -2245,18 +2496,9 @@ EXTERNAL_GROUPS = YES
EXTERNAL_PAGES = YES
#---------------------------------------------------------------------------
# Configuration options related to the dot tool
# Configuration options related to diagram generator tools
#---------------------------------------------------------------------------
# If the CLASS_DIAGRAMS tag is set to YES, doxygen will generate a class diagram
# (in HTML and LaTeX) for classes with base or super classes. Setting the tag to
# NO turns the diagrams off. Note that this option also works with HAVE_DOT
# disabled, but it is recommended to install and use dot, since it yields more
# powerful graphs.
# The default value is: YES.
CLASS_DIAGRAMS = NO
# You can include diagrams made with dia in doxygen documentation. Doxygen will
# then run dia to produce the diagram and insert it in the documentation. The
# DIA_PATH tag allows you to specify the directory where the dia binary resides.
......@@ -2272,7 +2514,7 @@ HIDE_UNDOC_RELATIONS = YES
# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
# available from the path. This tool is part of Graphviz (see:
# http://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
# https://www.graphviz.org/), a graph visualization toolkit from AT&T and Lucent
# Bell Labs. The other options in this section have no effect if this option is
# set to NO
# The default value is: YES.
......@@ -2289,49 +2531,73 @@ HAVE_DOT = NO
DOT_NUM_THREADS = 0
# When you want a differently looking font in the dot files that doxygen
# generates you can specify the font name using DOT_FONTNAME. You need to make
# sure dot is able to find the font, which can be done by putting it in a
# standard location or by setting the DOTFONTPATH environment variable or by
# setting DOT_FONTPATH to the directory containing the font.
# The default value is: Helvetica.
# DOT_COMMON_ATTR is common attributes for nodes, edges and labels of
# subgraphs. When you want a differently looking font in the dot files that
# doxygen generates you can specify fontname, fontcolor and fontsize attributes.
# For details please see <a href=https://graphviz.org/doc/info/attrs.html>Node,
# Edge and Graph Attributes specification</a> You need to make sure dot is able
# to find the font, which can be done by putting it in a standard location or by
# setting the DOTFONTPATH environment variable or by setting DOT_FONTPATH to the
# directory containing the font. Default graphviz fontsize is 14.
# The default value is: fontname=Helvetica,fontsize=10.
# This tag requires that the tag HAVE_DOT is set to YES.
DOT_COMMON_ATTR = "fontname=Helvetica,fontsize=10"
# DOT_EDGE_ATTR is concatenated with DOT_COMMON_ATTR. For elegant style you can
# add 'arrowhead=open, arrowtail=open, arrowsize=0.5'. <a
# href=https://graphviz.org/doc/info/arrows.html>Complete documentation about
# arrows shapes.</a>
# The default value is: labelfontname=Helvetica,labelfontsize=10.
# This tag requires that the tag HAVE_DOT is set to YES.
DOT_FONTNAME =
DOT_EDGE_ATTR = "labelfontname=Helvetica,labelfontsize=10"
# The DOT_FONTSIZE tag can be used to set the size (in points) of the font of
# dot graphs.
# Minimum value: 4, maximum value: 24, default value: 10.
# DOT_NODE_ATTR is concatenated with DOT_COMMON_ATTR. For view without boxes
# around nodes set 'shape=plain' or 'shape=plaintext' <a
# href=https://www.graphviz.org/doc/info/shapes.html>Shapes specification</a>
# The default value is: shape=box,height=0.2,width=0.4.
# This tag requires that the tag HAVE_DOT is set to YES.
DOT_FONTSIZE = 10
DOT_NODE_ATTR = "shape=box,height=0.2,width=0.4"
# By default doxygen will tell dot to use the default font as specified with
# DOT_FONTNAME. If you specify a different font using DOT_FONTNAME you can set
# the path where dot can find it using this tag.
# You can set the path where dot can find font specified with fontname in
# DOT_COMMON_ATTR and others dot attributes.
# This tag requires that the tag HAVE_DOT is set to YES.
DOT_FONTPATH =
# If the CLASS_GRAPH tag is set to YES then doxygen will generate a graph for
# each documented class showing the direct and indirect inheritance relations.
# Setting this tag to YES will force the CLASS_DIAGRAMS tag to NO.
# If the CLASS_GRAPH tag is set to YES or GRAPH or BUILTIN then doxygen will
# generate a graph for each documented class showing the direct and indirect
# inheritance relations. In case the CLASS_GRAPH tag is set to YES or GRAPH and
# HAVE_DOT is enabled as well, then dot will be used to draw the graph. In case
# the CLASS_GRAPH tag is set to YES and HAVE_DOT is disabled or if the
# CLASS_GRAPH tag is set to BUILTIN, then the built-in generator will be used.
# If the CLASS_GRAPH tag is set to TEXT the direct and indirect inheritance
# relations will be shown as texts / links.
# Possible values are: NO, YES, TEXT, GRAPH and BUILTIN.
# The default value is: YES.
# This tag requires that the tag HAVE_DOT is set to YES.
CLASS_GRAPH = YES
CLASS_GRAPH = TEXT
# If the COLLABORATION_GRAPH tag is set to YES then doxygen will generate a
# graph for each documented class showing the direct and indirect implementation
# dependencies (inheritance, containment, and class references variables) of the
# class with other documented classes.
# class with other documented classes. Explicit enabling a collaboration graph,
# when COLLABORATION_GRAPH is set to NO, can be accomplished by means of the
# command \collaborationgraph. Disabling a collaboration graph can be
# accomplished by means of the command \hidecollaborationgraph.
# The default value is: YES.
# This tag requires that the tag HAVE_DOT is set to YES.
COLLABORATION_GRAPH = YES
# If the GROUP_GRAPHS tag is set to YES then doxygen will generate a graph for
# groups, showing the direct groups dependencies.
# groups, showing the direct groups dependencies. Explicit enabling a group
# dependency graph, when GROUP_GRAPHS is set to NO, can be accomplished by means
# of the command \groupgraph. Disabling a directory graph can be accomplished by
# means of the command \hidegroupgraph. See also the chapter Grouping in the
# manual.
# The default value is: YES.
# This tag requires that the tag HAVE_DOT is set to YES.
......@@ -2354,10 +2620,32 @@ UML_LOOK = NO
# but if the number exceeds 15, the total amount of fields shown is limited to
# 10.
# Minimum value: 0, maximum value: 100, default value: 10.
# This tag requires that the tag HAVE_DOT is set to YES.
# This tag requires that the tag UML_LOOK is set to YES.
UML_LIMIT_NUM_FIELDS = 10
# If the DOT_UML_DETAILS tag is set to NO, doxygen will show attributes and
# methods without types and arguments in the UML graphs. If the DOT_UML_DETAILS
# tag is set to YES, doxygen will add type and arguments for attributes and
# methods in the UML graphs. If the DOT_UML_DETAILS tag is set to NONE, doxygen
# will not generate fields with class member information in the UML graphs. The
# class diagrams will look similar to the default class diagrams but using UML
# notation for the relationships.
# Possible values are: NO, YES and NONE.
# The default value is: NO.
# This tag requires that the tag UML_LOOK is set to YES.
DOT_UML_DETAILS = NO
# The DOT_WRAP_THRESHOLD tag can be used to set the maximum number of characters
# to display on a single line. If the actual line length exceeds this threshold
# significantly it will wrapped across multiple lines. Some heuristics are apply
# to avoid ugly line breaks.
# Minimum value: 0, maximum value: 1000, default value: 17.
# This tag requires that the tag HAVE_DOT is set to YES.
DOT_WRAP_THRESHOLD = 17
# If the TEMPLATE_RELATIONS tag is set to YES then the inheritance and
# collaboration graphs will show the relations between templates and their
# instances.
......@@ -2369,7 +2657,9 @@ TEMPLATE_RELATIONS = NO
# If the INCLUDE_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are set to
# YES then doxygen will generate a graph for each documented file showing the
# direct and indirect include dependencies of the file with other documented
# files.
# files. Explicit enabling an include graph, when INCLUDE_GRAPH is is set to NO,
# can be accomplished by means of the command \includegraph. Disabling an
# include graph can be accomplished by means of the command \hideincludegraph.
# The default value is: YES.
# This tag requires that the tag HAVE_DOT is set to YES.
......@@ -2378,7 +2668,10 @@ INCLUDE_GRAPH = YES
# If the INCLUDED_BY_GRAPH, ENABLE_PREPROCESSING and SEARCH_INCLUDES tags are
# set to YES then doxygen will generate a graph for each documented file showing
# the direct and indirect include dependencies of the file with other documented
# files.
# files. Explicit enabling an included by graph, when INCLUDED_BY_GRAPH is set
# to NO, can be accomplished by means of the command \includedbygraph. Disabling
# an included by graph can be accomplished by means of the command
# \hideincludedbygraph.
# The default value is: YES.
# This tag requires that the tag HAVE_DOT is set to YES.
......@@ -2418,23 +2711,32 @@ GRAPHICAL_HIERARCHY = YES
# If the DIRECTORY_GRAPH tag is set to YES then doxygen will show the
# dependencies a directory has on other directories in a graphical way. The
# dependency relations are determined by the #include relations between the
# files in the directories.
# files in the directories. Explicit enabling a directory graph, when
# DIRECTORY_GRAPH is set to NO, can be accomplished by means of the command
# \directorygraph. Disabling a directory graph can be accomplished by means of
# the command \hidedirectorygraph.
# The default value is: YES.
# This tag requires that the tag HAVE_DOT is set to YES.
DIRECTORY_GRAPH = YES
# The DIR_GRAPH_MAX_DEPTH tag can be used to limit the maximum number of levels
# of child directories generated in directory dependency graphs by dot.
# Minimum value: 1, maximum value: 25, default value: 1.
# This tag requires that the tag DIRECTORY_GRAPH is set to YES.
DIR_GRAPH_MAX_DEPTH = 1
# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
# generated by dot. For an explanation of the image formats see the section
# output formats in the documentation of the dot tool (Graphviz (see:
# http://www.graphviz.org/)).
# https://www.graphviz.org/)).
# Note: If you choose svg you need to set HTML_FILE_EXTENSION to xhtml in order
# to make the SVG files visible in IE 9+ (other browsers do not have this
# requirement).
# Possible values are: png, png:cairo, png:cairo:cairo, png:cairo:gd, png:gd,
# png:gd:gd, jpg, jpg:cairo, jpg:cairo:gd, jpg:gd, jpg:gd:gd, gif, gif:cairo,
# gif:cairo:gd, gif:gd, gif:gd:gd, svg, png:gd, png:gd:gd, png:cairo,
# png:cairo:gd, png:cairo:cairo, png:cairo:gdiplus, png:gdiplus and
# Possible values are: png, jpg, jpg:cairo, jpg:cairo:gd, jpg:gd, jpg:gd:gd,
# gif, gif:cairo, gif:cairo:gd, gif:gd, gif:gd:gd, svg, png:gd, png:gd:gd,
# png:cairo, png:cairo:gd, png:cairo:cairo, png:cairo:gdiplus, png:gdiplus and
# png:gdiplus:gdiplus.
# The default value is: png.
# This tag requires that the tag HAVE_DOT is set to YES.
......@@ -2466,11 +2768,12 @@ DOT_PATH =
DOTFILE_DIRS =
# The MSCFILE_DIRS tag can be used to specify one or more directories that
# contain msc files that are included in the documentation (see the \mscfile
# command).
# You can include diagrams made with dia in doxygen documentation. Doxygen will
# then run dia to produce the diagram and insert it in the documentation. The
# DIA_PATH tag allows you to specify the directory where the dia binary resides.
# If left empty dia is assumed to be found in the default search path.
MSCFILE_DIRS =
DIA_PATH =
# The DIAFILE_DIRS tag can be used to specify one or more directories that
# contain dia files that are included in the documentation (see the \diafile
......@@ -2479,10 +2782,10 @@ MSCFILE_DIRS =
DIAFILE_DIRS =
# When using plantuml, the PLANTUML_JAR_PATH tag should be used to specify the
# path where java can find the plantuml.jar file. If left blank, it is assumed
# PlantUML is not used or called during a preprocessing step. Doxygen will
# generate a warning when it encounters a \startuml command in this case and
# will not generate output for the diagram.
# path where java can find the plantuml.jar file or to the filename of jar file
# to be used. If left blank, it is assumed PlantUML is not used or called during
# a preprocessing step. Doxygen will generate a warning when it encounters a
# \startuml command in this case and will not generate output for the diagram.
PLANTUML_JAR_PATH =
......@@ -2520,18 +2823,6 @@ DOT_GRAPH_MAX_NODES = 50
MAX_DOT_GRAPH_DEPTH = 0
# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
# background. This is disabled by default, because dot on Windows does not seem
# to support this out of the box.
#
# Warning: Depending on the platform used, enabling this option may lead to
# badly anti-aliased labels on the edges of a graph (i.e. they become hard to
# read).
# The default value is: NO.
# This tag requires that the tag HAVE_DOT is set to YES.
DOT_TRANSPARENT = NO
# Set the DOT_MULTI_TARGETS tag to YES to allow dot to generate multiple output
# files in one run (i.e. multiple -o and -T options on the command line). This
# makes dot run faster, but since only newer versions of dot (>1.8.10) support
......@@ -2544,14 +2835,34 @@ DOT_MULTI_TARGETS = YES
# If the GENERATE_LEGEND tag is set to YES doxygen will generate a legend page
# explaining the meaning of the various boxes and arrows in the dot generated
# graphs.
# Note: This tag requires that UML_LOOK isn't set, i.e. the doxygen internal
# graphical representation for inheritance and collaboration diagrams is used.
# The default value is: YES.
# This tag requires that the tag HAVE_DOT is set to YES.
GENERATE_LEGEND = YES
# If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate dot
# If the DOT_CLEANUP tag is set to YES, doxygen will remove the intermediate
# files that are used to generate the various graphs.
#
# Note: This setting is not only used for dot files but also for msc temporary
# files.
# The default value is: YES.
# This tag requires that the tag HAVE_DOT is set to YES.
DOT_CLEANUP = YES
# You can define message sequence charts within doxygen comments using the \msc
# command. If the MSCGEN_TOOL tag is left empty (the default), then doxygen will
# use a built-in version of mscgen tool to produce the charts. Alternatively,
# the MSCGEN_TOOL tag can also specify the name an external tool. For instance,
# specifying prog as the value, doxygen will call the tool as prog -T
# <outfile_format> -o <outputfile> <inputfile>. The external tool should support
# output file formats "png", "eps", "svg", and "ismap".
MSCGEN_TOOL =
# The MSCFILE_DIRS tag can be used to specify one or more directories that
# contain msc files that are included in the documentation (see the \mscfile
# command).
MSCFILE_DIRS =
......@@ -24,14 +24,14 @@ While the initial graph is showing all the tasks/dependencies, the next ones are
Task dependencies for a single cell
-----------------------------------
There is an option to additionally write the dependency graphs of the task dependencies for a single cell.
There is an option to additionally write the dependency graphs of the task dependencies for a single cell.
You can select which cell to write using the ``Scheduler:dependency_graph_cell: cellID`` parameter, where ``cellID`` is the cell ID of type long long.
This feature will create an individual file for each step specified by the ``Scheduler:dependency_graph_frequency`` and, differently from the full task graph, will create an individual file for each MPI rank that has this cell.
Using this feature has several requirements:
- You need to compile SWIFT including either ``--enable-debugging-checks`` or ``--enable-cell-graph``. Otherwise, cells won't have IDs.
- There is a limit on how many cell IDs SWIFT can handle while enforcing them to be reproduceably unique. That limit is up to 32 top level cells in any dimension, and up to 16 levels of depth. If any of these thresholds are exceeded, the cells will still have unique cell IDs, but the actual IDs will most likely vary between any two runs.
- There is a limit on how many cell IDs SWIFT can handle while enforcing them to be reproducibly unique. That limit is up to 32 top level cells in any dimension, and up to 16 levels of depth. If any of these thresholds are exceeded, the cells will still have unique cell IDs, but the actual IDs will most likely vary between any two runs.
To plot the task dependencies, you can use the same script as before: ``tools/plot_task_dependencies.py``. The dependency graph now may have some tasks with a pink-ish background colour: These tasks represent dependencies that are unlocked by some other task which is executed for the requested cell, but the cell itself doesn't have an (active) task of that type itself in that given step.
......@@ -39,15 +39,15 @@ To plot the task dependencies, you can use the same script as before: ``tools/pl
Task levels
-----------------
At the beginning of each simulation the file ``task_level_0.txt`` is generated.
At the beginning of each simulation the file ``task_level_0.txt`` is generated.
It contains the counts of all tasks at all levels (depths) in the tree.
The depths and counts of the tasks can be plotted with the script ``tools/plot_task_levels.py``.
It will display the individual tasks at the x-axis, the number of each task at a given level on the y-axis, and the level is shown as the colour of the plotted point.
Additionally, the script can write out in brackets next to each tasks's name on the x-axis on how many different levels the task exists using the ``--count`` flag.
Additionally, the script can write out in brackets next to each task's name on the x-axis on how many different levels the task exists using the ``--count`` flag.
Finally, in some cases the counts for different levels of a task may be very close to each other and overlap on the plot, making them barely visible.
This can be alleviated by using the ``--displace`` flag:
This can be alleviated by using the ``--displace`` flag:
It will displace the plot points w.r.t. the y-axis in an attempt to make them better visible, however the counts won't be exact in that case.
If you wish to have more task level plots, you can use the parameter ``Scheduler:task_level_output_frequency``.
If you wish to have more task level plots, you can use the parameter ``Scheduler:task_level_output_frequency``.
It defines how many steps are done in between two task level output dumps.
......@@ -139,9 +139,9 @@ Each line of the logs contains the following information:
activation: 1 if record for the start of a request, 0 if request completion
tag: MPI tag of the request
size: size, in bytes, of the request
sum: sum, in bytes, of all requests that are currently not logged as complete
sum: sum, in bytes, of all requests that are currently not logged as complete
The stic values should be synchronized between ranks as all ranks have a
The stic values should be synchronised between ranks as all ranks have a
barrier in place to make sure they start the step together, so should be
suitable for matching between ranks. The unique keys to associate records
between ranks (so that the MPI_Isend and MPI_Irecv pairs can be identified)
......@@ -161,27 +161,27 @@ on which the additional task data will be dumped. Swift will then create ``threa
and ``thread_info-step<nr>.dat`` files. Similarly, for threadpool related tools, you need to compile
swift with ``--enable-threadpool-debugging`` and then run it with ``-Y <interval>``.
For the analysis and plotting scripts listed below, you need to provide the **\*info-step<nr>.dat**
For the analysis and plotting scripts listed below, you need to provide the **\*info-step<nr>.dat**
files as a cmdline argument, not the ``*stats-step<nr>.dat`` files.
A short summary of the scripts in ``tools/task_plots/``:
- ``analyse_tasks.py``:
- ``analyse_tasks.py``:
The output is an analysis of the task timings, including deadtime per thread
and step, total amount of time spent for each task type, for the whole step
and per thread and the minimum and maximum times spent per task type.
- ``analyse_threadpool_tasks.py``:
The output is an analysis of the threadpool task timings, including
- ``analyse_threadpool_tasks.py``:
The output is an analysis of the threadpool task timings, including
deadtime per thread and step, total amount of time spent for each task type, for the
whole step and per thread and the minimum and maximum times spent per task type.
- ``iplot_tasks.py``:
An interactive task plot, showing what thread was doing what task and for
how long for a step. **Needs python2 and the tkinter module**.
- ``plot_tasks.py``:
Creates a task plot image, showing what thread was doing what task and for how long.
- ``plot_threadpool.py``:
- ``iplot_tasks.py``:
An interactive task plot, showing what thread was doing what task and for
how long for a step. **Needs the tkinter module**.
- ``plot_tasks.py``:
Creates a task plot image, showing what thread was doing what task and for how long.
- ``plot_threadpool.py``:
Creates a threadpool plot image, showing what thread was doing what threadpool call and for
how long.
how long.
For more details on the scripts as well as further options, look at the documentation at the top
......@@ -189,7 +189,7 @@ of the individual scripts and call them with the ``-h`` flag.
Task data is also dumped when using MPI and the tasks above can be used on
that as well, some offer the ability to process all ranks, and others to
select individual ranks.
select individual ranks.
It is also possible to process a complete run of task data from all the
available steps using the ``process_plot_tasks.py`` and
......@@ -205,6 +205,8 @@ by using the size of the task data files to schedule parallel processes more
effectively (the ``--weights`` argument).
.. _dumperThread:
Live internal inspection using the dumper thread
------------------------------------------------
......@@ -236,49 +238,81 @@ than once. For a non-MPI run the file is simply called ``.dump``, note for MPI
you need to create one file per rank, so ``.dump.0``, ``.dump.1`` and so on.
Deadlock Detector
---------------------------
When configured with ``--enable-debugging-checks``, the parameter
.. code-block:: yaml
Scheduler:
deadlock_waiting_time_s: 300.
can be specified. It specifies the time (in seconds) the scheduler should wait
for a new task to be executed during a simulation step (specifically: during a
call to ``engine_launch()``). After this time passes without any new tasks being
run, the scheduler assumes that the code has deadlocked. It then dumps the same
diagnostic data as :ref:`the dumper thread <dumperThread>` (active tasks, queued
tasks, and memuse/MPIuse reports, if swift was configured with the corresponding
flags) and aborts.
A value of zero or a negative value for ``deadlock_waiting_time_s`` disable the
deadlock detector.
You are likely well advised to try and err on the upper side for the time to
choose for the ``deadlock_waiting_time_s`` parameter. A value in the order of
several (tens of) minutes is recommended. A too small value might cause your run to
erroneously crash and burn despite not really being deadlocked, just slow or
badly balanced.
Neighbour search statistics
---------------------------
One of the core algorithms in SWIFT is an iterative neighbour search
whereby we try to find an appropriate radius around a particle's
position so that the weighted sum over neighbouring particles within
that radius is equal to some target value. The most obvious example of
this iterative neighbour search is the SPH density loop, but various
sub-grid models employ a very similar iterative neighbour search. The
computational cost of this iterative search is significantly affected by
the number of iterations that is required, and it can therefore be
One of the core algorithms in SWIFT is an iterative neighbour search
whereby we try to find an appropriate radius around a particle's
position so that the weighted sum over neighbouring particles within
that radius is equal to some target value. The most obvious example of
this iterative neighbour search is the SPH density loop, but various
sub-grid models employ a very similar iterative neighbour search. The
computational cost of this iterative search is significantly affected by
the number of iterations that is required, and it can therefore be
useful to analyse the progression of the iterative scheme in detail.
When configured with ``--enable-ghost-statistics=X``, SWIFT will be
compiled with additional diagnostics that statistically track the number
of iterations required to find a converged answer. Here, ``X`` is a
fixed number of bins to use to collect the required statistics
(``ghost`` refers to the fact that the iterations take place inside the
ghost tasks). In practice, this means that every cell in the SWIFT tree
will be equipped with an additional ``struct`` containing three sets of
``X`` bins (one set for each iterative neighbour loop: hydro, stellar
feedback, AGN feedback). For each bin ``i``, we store the number of
particles that required updating during iteration ``i``, the number of
particles that could not find a single neighbouring particle, the
minimum and maximum smoothing length of all particles that required
updating, and the sum of all their search radii and all their search
radii squared. This allows us to calculate the upper and lower limits,
as well as the mean and standard deviation on the search radius for each
iteration and for each cell. Note that there could be more iterations
required than the number of bins ``X``; in this case the additional
iterations will be accumulated in the final bin. At the end of each time
step, a text file is produced (one per MPI rank) that contains the
information for all cells that had any relevant activity. This text file
is named ``ghost_stats_ssss_rrrr.txt``, where ``ssss`` is the step
When configured with ``--enable-ghost-statistics=X``, SWIFT will be
compiled with additional diagnostics that statistically track the number
of iterations required to find a converged answer. Here, ``X`` is a
fixed number of bins to use to collect the required statistics
(``ghost`` refers to the fact that the iterations take place inside the
ghost tasks). In practice, this means that every cell in the SWIFT tree
will be equipped with an additional ``struct`` containing three sets of
``X`` bins (one set for each iterative neighbour loop: hydro, stellar
feedback, AGN feedback). For each bin ``i``, we store the number of
particles that required updating during iteration ``i``, the number of
particles that could not find a single neighbouring particle, the
minimum and maximum smoothing length of all particles that required
updating, and the sum of all their search radii and all their search
radii squared. This allows us to calculate the upper and lower limits,
as well as the mean and standard deviation on the search radius for each
iteration and for each cell. Note that there could be more iterations
required than the number of bins ``X``; in this case the additional
iterations will be accumulated in the final bin. At the end of each time
step, a text file is produced (one per MPI rank) that contains the
information for all cells that had any relevant activity. This text file
is named ``ghost_stats_ssss_rrrr.txt``, where ``ssss`` is the step
counter for that time step and ``rrrr`` is the MPI rank.
The script ``tools/plot_ghost_stats.py`` takes one or multiple
``ghost_stats.txt`` files and computes global statistics for all the
cells in those files. The script also takes the name of an output file
where it will save those statistics as a set of plots, and an optional
label that will be displayed as the title of the plots. Note that there
are no restrictions on the number of input files or how they relate;
different files could represent different MPI ranks, but also different
time steps or even different simulations (which would make little
sense). It is up to the user to make sure that the input is actually
The script ``tools/plot_ghost_stats.py`` takes one or multiple
``ghost_stats.txt`` files and computes global statistics for all the
cells in those files. The script also takes the name of an output file
where it will save those statistics as a set of plots, and an optional
label that will be displayed as the title of the plots. Note that there
are no restrictions on the number of input files or how they relate;
different files could represent different MPI ranks, but also different
time steps or even different simulations (which would make little
sense). It is up to the user to make sure that the input is actually
relevant.
......@@ -52,18 +52,19 @@ following bibtex citation block:
@ARTICLE{2023arXiv230513380S,
author = {{Schaller}, Matthieu and others},
title = "{Swift: A modern highly-parallel gravity and smoothed particle hydrodynamics solver for astrophysical and cosmological applications}",
journal = {arXiv e-prints},
keywords = {Astrophysics - Instrumentation and Methods for Astrophysics, Astrophysics - Cosmology and Nongalactic Astrophysics, Astrophysics - Earth and Planetary Astrophysics, Astrophysics - Astrophysics of Galaxies, Computer Science - Distributed, Parallel, and Cluster Computing},
year = 2023,
title = "{SWIFT: A modern highly-parallel gravity and smoothed particle hydrodynamics solver for astrophysical and cosmological applications}",
journal = {\mnras},
keywords = {software: simulations, methods: numerical, software: public release, Astrophysics - Instrumentation and Methods for Astrophysics, Astrophysics - Cosmology and Nongalactic Astrophysics, Astrophysics - Earth and Planetary Astrophysics, Astrophysics - Astrophysics of Galaxies, Computer Science - Distributed, Parallel, and Cluster Computing},
year = 2024,
month = may,
eid = {arXiv:2305.13380},
pages = {arXiv:2305.13380},
doi = {10.48550/arXiv.2305.13380},
volume = {530},
number = {2},
pages = {2378-2419},
doi = {10.1093/mnras/stae922},
archivePrefix = {arXiv},
eprint = {2305.13380},
primaryClass = {astro-ph.IM},
adsurl = {https://ui.adsabs.harvard.edu/abs/2023arXiv230513380S},
adsurl = {https://ui.adsabs.harvard.edu/abs/2024MNRAS.530.2378S},
adsnote = {Provided by the SAO/NASA Astrophysics Data System}
}
......@@ -101,5 +102,4 @@ code. This corresponds to the following bibtex citation block:
When using models or parts of the code whose details were introduced in other
papers, we kindly ask that the relevant work is properly acknowledge and
cited. This includes the :ref:`subgrid`, the :ref:`planetary` extensions, the
hydrodynamics and radiative transfer implementations, or the particle-based
:ref:`neutrinos`.
:ref:`hydro` and :ref:`rt`, or the particle-based :ref:`neutrinos`.
......@@ -7,20 +7,20 @@
Equations of State
==================
Currently, SWIFT offers two different gas equations of state (EoS)
implemented: ``ideal`` and ``isothermal``; as well as a variety of EoS for
"planetary" materials. The EoS describe the relations between our
main thermodynamical variables: the internal energy per unit mass
(\\(u\\)), the mass density (\\(\\rho\\)), the entropy (\\(A\\)) and
the pressure (\\(P\\)).
Currently, SWIFT offers three different gas equations of state (EoS)
implemented: ``ideal``, ``isothermal``, and ``barotropic``; as well as a variety
of EoS for "planetary" materials. The EoS describe the relations between our
main thermodynamical variables: the internal energy per unit mass :math:`u`, the
mass density :math:`\rho`, the entropy :math:`A` and the pressure :math:`P`.
It is selected af configure time via the option ``--with-equation-of-state``.
Gas EoS
-------
We write the adiabatic index as \\(\\gamma \\) and \\( c_s \\) denotes
We write the adiabatic index as :math:`\gamma` and :math:`c_s` denotes
the speed of sound. The adiabatic index can be changed at configure
time by choosing one of the allowed values of the option
``--with-adiabatic-index``. The default value is \\(\\gamma = 5/3 \\).
``--with-adiabatic-index``. The default value is :math:`\gamma = 5/3`.
The tables below give the expression for the thermodynamic quantities
on each row entry as a function of the gas density and the
......@@ -29,27 +29,38 @@ thermodynamical quantity given in the header of each column.
.. csv-table:: Ideal Gas
:header: "Variable", "A", "u", "P"
"A", "", "\\( \\left( \\gamma - 1 \\right) u \\rho^{1-\\gamma} \\)", "\\(P \\rho^{-\\gamma} \\)"
"u", "\\( A \\frac{ \\rho^{ \\gamma - 1 } }{\\gamma - 1 } \\)", "", "\\(\\frac{1}{\\gamma - 1} \\frac{P}{\\rho}\\)"
"P", "\\( A \\rho^\\gamma \\)", "\\( \\left( \\gamma - 1\\right) u \\rho \\)", ""
"\\(c_s\\)", "\\(\\sqrt{ \\gamma \\rho^{\\gamma - 1} A}\\)", "\\(\\sqrt{ u \\gamma \\left( \\gamma - 1 \\right) } \\)", "\\(\\sqrt{ \\frac{\\gamma P}{\\rho} }\\)"
"A", "", :math:`\left( \gamma - 1 \right) u \rho^{1-\gamma}`, :math:`P \rho^{-\gamma}`
"u", :math:`A \frac{ \rho^{ \gamma - 1 } }{\gamma - 1 }`, "", :math:`\frac{1}{\gamma - 1} \frac{P}{\rho}`
"P", :math:`A \rho^\gamma`, :math:`\left( \gamma - 1\right) u \rho`, ""
:math:`c_s`, :math:`\sqrt{ \gamma \rho^{\gamma - 1} A}`, :math:`\sqrt{ u \gamma \left( \gamma - 1 \right) }`, :math:`\sqrt{ \frac{\gamma P}{\rho} }`
.. csv-table:: Isothermal Gas
:header: "Variable", "A", "u", "P"
:header: "Variable", "-", "-", "-"
"A", "", "\\(\\left( \\gamma - 1 \\right) u \\rho^{1-\\gamma}\\)", ""
"A", "", :math:`\left( \gamma - 1 \right) u \rho^{1-\gamma}`, ""
"u", "", "const", ""
"P", "", "\\(\\left( \\gamma - 1\\right) u \\rho \\)", ""
"\\( c_s\\)", "", "\\(\\sqrt{ u \\gamma \\left( \\gamma - 1 \\right) } \\)", ""
Note that when running with an isothermal equation of state, the value
of the tracked thermodynamic variable (e.g. the entropy in a
"P", "", :math:`\left( \gamma - 1\right) u \rho`, ""
:math:`c_s`, "", :math:`\sqrt{ u \gamma \left( \gamma - 1 \right) }`, ""
.. csv-table:: Barotropic Gas
:header: "Variable", "-", "-", "-"
"A", "", :math:`\rho^{1-\gamma} c_0^2 \sqrt{1 + \left( \frac{\rho}{\rho_c} \right) }`, ""
"u", "", :math:`\frac{1}(\gamma -1)c_0^2 \sqrt{1 + \left( \frac{\rho}{\rho_c} \right) }`, ""
"P", "", :math:`\rho c_0^2 \sqrt{1 + \left( \frac{\rho}{\rho_c} \right) }`, ""
:math:`c_s`, "", :math:`\sqrt{ c_0^2 \sqrt{1 + \left( \frac{\rho}{\rho_c} \right) }}`, ""
Note that when running with an isothermal or barotropic equation of state, the
value of the tracked thermodynamic variable (e.g. the entropy in a
density-entropy scheme or the internal enegy in a density-energy SPH
formulation) written to the snapshots is meaningless. The pressure,
however, is always correct in all scheme.
formulation) written to the snapshots is meaningless. The pressure, however, is
always correct in all scheme.
For the isothermal equation of state, the internal energy is specified at
runtime via the parameter file. In the case of the barotropic gas, the vacuum
sound speed :math:`c_0` and core density :math:`\rho_c` are similarly specified.
Planetary EoS
......@@ -66,7 +77,7 @@ See :ref:`new_option` for a full list of required changes.
You will need to provide an ``equation_of_state.h`` file containing: the
definition of ``eos_parameters``, IO functions and transformations between the
different variables: \\(u(\\rho, A)\\), \\(u(\\rho, P)\\), \\(P(\\rho,A)\\),
\\(P(\\rho, u)\\), \\(A(\\rho, P)\\), \\(A(\\rho, u)\\), \\(c_s(\\rho, A)\\),
\\(c_s(\\rho, u)\\) and \\(c_s(\\rho, P)\\). See other equation of state files
different variables: :math:`u(\rho, A)`, :math:`u(\rho, P)`, :math:`P(\rho,A)`,
:math:`P(\rho, u)`, :math:`A(\rho, P)`, :math:`A(\rho, u)`, :math:`c_s(\rho, A)`,
:math:`c_s(\rho, u)` and :math:`c_s(\rho, P)`. See other equation of state files
to have implementation details.
......@@ -344,7 +344,105 @@ follows the definitions of `Creasey, Theuns & Bower (2013)
<https://adsabs.harvard.edu/abs/2013MNRAS.429.1922C>`_ equations (16) and (17).
The potential is implemented along the x-axis.
12. MWPotential2014 (``MWPotential2014``)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This potential is based on ``galpy``'s ``MWPotential2014`` from `Jo Bovy (2015) <https://ui.adsabs.harvard.edu/abs/2015ApJS..216...29B>`_ and consists in a NFW potential for the halo, an axisymmetric Miyamoto-Nagai potential for the disk and a bulge modeled by a power spherical law with exponential cut-off. The bulge is given by the density:
:math:`\rho(r) = A \left( \frac{r_1}{r} \right)^\alpha \exp \left( - \frac{r^2}{r_c^2} \right)`,
where :math:`A` is an amplitude, :math:`r_1` is a reference radius for amplitude, :math:`\alpha` is the inner power and :math:`r_c` is the cut-off radius.
The resulting potential is:
:math:`\Phi_{\mathrm{MW}}(R, z) = f_1 \Phi_{\mathrm{NFW}} + f_2 \Phi_{\mathrm{MN}} + f_3 \Phi_{\text{bulge}}`,
where :math:`R^2 = x^2 + y^2` is the projected radius and :math:`f_1`, :math:`f_2` and :math:`f_3` are three coefficients that adjust the strength of each individual component.
The parameters of the model are:
.. code:: YAML
MWPotential2014Potential:
useabspos: 0 # 0 -> positions based on centre, 1 -> absolute positions
position: [0.,0.,0.] # Location of centre of potential with respect to centre of the box (if 0) otherwise absolute (if 1) (internal units)
timestep_mult: 0.005 # Dimensionless pre-factor for the time-step condition, basically determines the fraction of the orbital time we use to do the time integration
epsilon: 0.001 # Softening size (internal units)
concentration: 9.823403437774843 # concentration of the Halo
M_200_Msun: 147.41031542774076e10 # M200 of the galaxy disk (in M_sun)
H: 1.2778254614201471 # Hubble constant in units of km/s/Mpc
Mdisk_Msun: 6.8e10 # Mass of the disk (in M_sun)
Rdisk_kpc: 3.0 # Effective radius of the disk (in kpc)
Zdisk_kpc: 0.280 # Scale-height of the disk (in kpc)
amplitude_Msun_per_kpc3: 1.0e10 # Amplitude of the bulge (in M_sun/kpc^3)
r_1_kpc: 1.0 # Reference radius for amplitude of the bulge (in kpc)
alpha: 1.8 # Exponent of the power law of the bulge
r_c_kpc: 1.9 # Cut-off radius of the bulge (in kpc)
potential_factors: [0.4367419745056084, 1.002641971008805, 0.022264787598364262] #Coefficients that adjust the strength of the halo (1st component), the disk (2nd component) and the bulge (3rd component)
Note that the default value of the "Hubble constant" here seems odd. As it
enters multiplicatively with the :math:`f_1` term, the absolute normalisation is
actually not important.
Dynamical friction
..................
This potential can be supplemented by a dynamical friction force, following the Chandrasekhar’s dynamical friction formula,
where the velocity distribution function is assumed to be Maxwellian (Binney & Tremaine 2008, eq. 8.7):
:math:`\frac{\rm{d} \vec{v}_{\rm M}}{\rm{d} t}=-\frac{4\pi G^2M_{\rm sat}\rho \ln \Lambda}{v^3_{\rm{M}}} \left[ \rm{erf}(X) - \frac{2 X}{\sqrt\pi} e^{-X^2} \right] \vec{v}_{\rm M}`,
with:
:math:`X = \frac{v_{\rm{M}}}{\sqrt{2} \sigma}`, :math:`\sigma` being the radius-dependent velocity dispersion of the galaxy.
This latter is computed using the Jeans equations, assuming a spherical component. It is provided by a polynomial fit of order 16.
The velocity dispersion is floored to :math:`\sigma_{\rm min}`, a free parameter.
:math:`\ln \Lambda` is the Coulomb parameter.
:math:`M_{\rm sat}` is the mass of the in-falling satellite on which the dynamical friction is supposed to act.
To prevent very high values of the dynamical friction that can occurs at the center of the model, the acceleration is multiplied by:
:math:`\rm{max} \left(0, \rm{erf}\left( 2\, \frac{ r-r_{\rm{core}} }{r_{\rm{core}}} \right) \right)`
This can also mimic the decrease of the dynamical friction due to a core.
The additional parameters for the dynamical friction are:
.. code:: YAML
with_dynamical_friction: 0 # Are we running with dynamical friction ? 0 -> no, 1 -> yes
df_lnLambda: 5.0 # Coulomb logarithm
df_sigma_floor_km_p_s : 10.0 # Minimum velocity dispersion for the velocity dispersion model
df_satellite_mass_in_Msun : 1.0e10 # Satellite mass in solar mass
df_core_radius_in_kpc: 10 # Radius below which the dynamical friction vanishes.
df_polyfit_coeffs00: -2.96536595e-31 # Polynomial fit coefficient for the velocity dispersion model (order 16)
df_polyfit_coeffs01: 8.88944631e-28 # Polynomial fit coefficient for the velocity dispersion model (order 15)
df_polyfit_coeffs02: -1.18280578e-24 # Polynomial fit coefficient for the velocity dispersion model (order 14)
df_polyfit_coeffs03: 9.29479457e-22 # Polynomial fit coefficient for the velocity dispersion model (order 13)
df_polyfit_coeffs04: -4.82805265e-19 # Polynomial fit coefficient for the velocity dispersion model (order 12)
df_polyfit_coeffs05: 1.75460211e-16 # Polynomial fit coefficient for the velocity dispersion model (order 11)
df_polyfit_coeffs06: -4.59976540e-14 # Polynomial fit coefficient for the velocity dispersion model (order 10)
df_polyfit_coeffs07: 8.83166045e-12 # Polynomial fit coefficient for the velocity dispersion model (order 9)
df_polyfit_coeffs08: -1.24747700e-09 # Polynomial fit coefficient for the velocity dispersion model (order 8)
df_polyfit_coeffs09: 1.29060404e-07 # Polynomial fit coefficient for the velocity dispersion model (order 7)
df_polyfit_coeffs10: -9.65315026e-06 # Polynomial fit coefficient for the velocity dispersion model (order 6)
df_polyfit_coeffs11: 5.10187806e-04 # Polynomial fit coefficient for the velocity dispersion model (order 5)
df_polyfit_coeffs12: -1.83800281e-02 # Polynomial fit coefficient for the velocity dispersion model (order 4)
df_polyfit_coeffs13: 4.26501444e-01 # Polynomial fit coefficient for the velocity dispersion model (order 3)
df_polyfit_coeffs14: -5.78038064e+00 # Polynomial fit coefficient for the velocity dispersion model (order 2)
df_polyfit_coeffs15: 3.57956721e+01 # Polynomial fit coefficient for the velocity dispersion model (order 1)
df_polyfit_coeffs16: 1.85478908e+02 # Polynomial fit coefficient for the velocity dispersion model (order 0)
df_timestep_mult : 0.1 # Dimensionless pre-factor for the time-step condition for the dynamical friction force
How to implement your own potential
-----------------------------------
......
......@@ -19,8 +19,20 @@ friends (its *friends-of-friends*). This creates networks of linked particles
which are called *groups*. The size (or length) of
a group is the number of particles in that group. If a particle does not
find any other particle within ``l`` then it forms its own group of
size 1. For a given distribution of particles the resulting list of
groups is unique and unambiguously defined.
size 1. **For a given distribution of particles the resulting list of
groups is unique and unambiguously defined.**
In our implementation, we use three separate categories influencing their
behaviour in the FOF code:
- ``linkable`` particles which behave as described above.
- ``attachable`` particles which can `only` form a link with the `nearest` ``linkable`` particle they find.
- And the others which are ignored entirely.
The category of each particle type is specified at run time in the parameter
file. The classic scenario for the two categories is to run FOF on the dark
matter particles (i.e. they are `linkable`) and then attach the gas, stars and
black holes to their nearest DM (i.e. the baryons are `attachable`).
Small groups are typically discarded, the final catalogue only contains
objects with a length above a minimal threshold, typically of the
......@@ -36,20 +48,25 @@ domain decomposition and tree structure that is created for the other
parts of the code. The tree can be easily used to find neighbours of
particles within the linking length.
Depending on the application, the choice of linking length and
minimal group size can vary. For cosmological applications, bound
structures (dark matter haloes) are traditionally identified using a
linking length expressed as :math:`0.2` of the mean inter-particle
separation :math:`d` in the simulation which is given by :math:`d =
\sqrt[3]{\frac{V}{N}}`, where :math:`N` is the number of particles in
the simulation and :math:`V` is the simulation (co-moving)
volume. Usually only dark matter particles are considered for the
number :math:`N`. Other particle types are linked but do not
participate in the calculation of the linking length. Experience shows
that this produces groups that are similar to the commonly adopted
(but much more complex) definition of virialised haloes. A minimal
group length of :math:`32` is often adopted in order to get a robust
catalogue of haloes and compute a good halo mass function.
Depending on the application, the choice of linking length and minimal group
size can vary. For cosmological applications, bound structures (dark matter
haloes) are traditionally identified using a linking length expressed as
:math:`0.2` of the mean inter-particle separation :math:`d` in the simulation
which is given by :math:`d = \sqrt[3]{\frac{V}{N}}`, where :math:`N` is the
number of particles in the simulation and :math:`V` is the simulation
(co-moving) volume. Experience shows that this produces groups that are similar
to the commonly adopted (but much more complex) definition of virialised
haloes. A minimal group length of :math:`32` is often adopted in order to get a
robust catalogue of haloes and compute a good halo mass function. Usually only
dark matter particles are considered for the number :math:`N`. In practice, the
mean inter-particle separation is evaluated based on the cosmology adopted in
the simulation. We use: :math:`d=\sqrt[3]{\frac{m_{\rm DM}}{\Omega_{\rm cdm}
\rho_{\rm crit}}}` for simulations with baryonic particles and
:math:`d=\sqrt[3]{\frac{m_{\rm DM}}{(\Omega_{\rm cdm} + \Omega_{\rm b})
\rho_{\rm crit}}}` for DMO simulations. In both cases, :math:`m_{\rm DM}` is the
mean mass of the DM particles. Using this definition (rather than basing in on
:math:`N`) makes the code robust to zoom-in scenarios where the entire volume is
not filled with particles.
For non-cosmological applications of the FOF algorithm, the choice of
the linking length is more difficult and left to the user. The choice
......
......@@ -10,8 +10,9 @@ The main purpose of the on-the-fly FOF is to identify haloes during a
cosmological simulation in order to seed some of them with black holes
based on physical considerations.
**In this mode, no group catalogue is written to the disk. The resulting list
of haloes is only used internally by SWIFT.**
.. warning::
In this mode, no group catalogue is written to the disk. The resulting list
of haloes is only used internally by SWIFT.
Note that a catalogue can nevertheless be written after every seeding call by
setting the optional parameter ``dump_catalogue_when_seeding``.
......
......@@ -20,8 +20,14 @@ absolute value using the parameter ``absolute_linking_length``. This is
expressed in internal units. This value will be ignored (and the ratio of
the mean inter-particle separation will be used) when set to ``-1``.
The categories of particles are specified using the ``linking_types`` and
``attaching_types`` arrays. They are of the length of the number of particle
types in SWIFT (currently 7) and specify for each type using ``1`` or ``0``
whether or not the given particle type is in this category. Types not present
in either category are ignored entirely.
The second important parameter is the minimal size of groups to retain in
the catalogues. This is given in terms of number of particles (of all types)
the catalogues. This is given in terms of number of *linking* particles
via the parameter ``min_group_size``. When analysing simulations, to
identify haloes, the common practice is to set this to ``32`` in order to
not plague the catalogue with too many small, likely unbound, structures.
......@@ -98,10 +104,12 @@ A full FOF section of the YAML parameter file looks like:
time_first: 0.2 # Time of first FoF black hole seeding calls.
delta_time: 1.005 # Time between consecutive FoF black hole seeding calls.
min_group_size: 256 # The minimum no. of particles required for a group.
linking_types: [0, 1, 0, 0, 0, 0, 0] # Which particle types to consider for linking (here only DM)
attaching_types: [1, 0, 0, 0, 1, 1, 0] # Which particle types to consider for attaching (here gas, stars, and BHs)
linking_length_ratio: 0.2 # Linking length in units of the main inter-particle separation.
seed_black_holes_enabled: 0 # Do not seed black holes when running FOF
black_hole_seed_halo_mass_Msun: 1.5e10 # Minimal halo mass in which to seed a black hole (in solar masses).
dump_catalogue_when_seeding: 0 # (Optional) Write a FOF catalogue when seeding black holes. Defaults to 0 if unspecified.
absolute_linking_length: -1. # (Optional) Absolute linking length (in internal units).
group_id_default: 2147483647 # (Optional) Sets the group ID of particles in groups below the minimum size.
group_id_offset: 1 # (Optional) Sets the offset of group ID labelling. Defaults to 1 if unspecified.
seed_black_holes_enabled: 0 # Do not seed black holes when running FOF
......@@ -11,17 +11,17 @@ compiled by configuring the code with the option
``--enable-stand-alone-fof``. The ``fof`` and ``fof_mpi`` executables
will then be generated alongside the regular SWIFT ones.
The executable takes a parameter file as an argument. It will then
read the snapshot specified in the parameter file and extract all
the dark matter particles by default. FOF is then run on these
particles and a catalogue of groups is written to disk. Additional
particle types can be read and processed by the stand-alone FOF
code by adding any of the following runtime parameters to the
command line:
The executable takes a parameter file as an argument. It will then read the
snapshot specified in the parameter file (specified as an initial condition
file) and extract all the dark matter particles by default. FOF is then run on
these particles and a catalogue of groups is written to disk. Additional
particle types can be read and processed by the stand-alone FOF code by adding
any of the following runtime parameters to the command line:
* ``--hydro``: Read and process the gas particles,
* ``--stars``: Read and process the star particles,
* ``--black-holes``: Read and process the black hole particles,
* ``--sinks``: Read and process the sink particles,
* ``--cosmology``: Consider cosmological terms.
Running with cosmology is necessary when using a linking length based
......@@ -34,3 +34,13 @@ internal units). The FOF code will also write a snapshot with an
additional field for each particle. This contains the ``GroupID`` of
each particle and can be used to find all the particles in a given
halo and to link them to the information stored in the catalogue.
The particle fields written to the snapshot can be modified using the
:ref:`Output_selection_label` options.
.. warning::
Note that since not all particle properties are read in stand-alone
mode, not all particle properties will be written to the snapshot generated
by the stand-alone FOF.
......@@ -31,16 +31,19 @@ To compile SWIFT, you will need the following libraries:
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 existing GADGET-2 specification. Please consider
using a build of parallel-HDF5, as SWIFT can leverage this when writing and
reading snapshots. We recommend using HDF5 > 1.10.x as this is *vastly superior*
reading snapshots. We recommend using HDF5 >= 1.12.x as this is *vastly superior*
in parallel.
HDF5 is widely available through system package managers.
MPI
~~~
A recent implementation of MPI, such as Open MPI (v2.x or higher), is required,
or any library that implements at least the MPI 3 standard.
MPI implementations are widely available through system package managers.
Running SWIFT on OmniPath atchitechtures with Open MPI
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
......@@ -53,19 +56,25 @@ with ``--mca btl vader,self -mca mtl psm``.
Libtool
~~~~~~~
The build system depends on libtool.
The build system depends on libtool. Libtool is widely available through system
package managers.
FFTW
~~~~
Version 3.3.x or higher is required for periodic gravity.
Version 3.3.x or higher is required for periodic gravity. FFTW is widely available
through system package managers or on http://fftw.org/.
ParMETIS or METIS
~~~~~~~~~~~~~~~~~
One is required for domain decomposition and load balancing.
One of these libraries is required for domain decomposition and load balancing.
Source codes for them libraries are available
`here for METIS <https://github.com/KarypisLab/METIS>`_ and
`here for ParMETIS <https://github.com/KarypisLab/ParMETIS>`_ .
GSL
~~~
The GSL is required for cosmological integration.
The GSL is required for cosmological integration. GSL is widely available through
system package managers.
Optional Dependencies
......@@ -87,17 +96,33 @@ You can build documentation for SWIFT with DOXYGEN.
Python
~~~~~~
To run the examples, you will need python 3 and some of the standard scientific libraries (numpy, matplotlib).
Some examples make use of the `swiftsimio <https://swiftsimio.readthedocs.io/en/latest/>`_ library.
To run the examples, you will need python 3 and some of the standard scientific
libraries (numpy, matplotlib). Some examples make use of the
`swiftsimio <https://swiftsimio.readthedocs.io/en/latest/>`_ library.
GRACKLE
~~~~~~~
GRACKLE cooling is implemented in SWIFT. If you wish to take advantage of it, you will need it installed.
GRACKLE cooling is implemented in SWIFT. If you wish to take advantage of it, you
will need it installed. It can be found `here <https://github.com/grackle-project/grackle>`_.
.. warning::
(State 2023) Grackle is experiencing current development, and the API is subject
to changes in the future. For convenience, a frozen version is hosted as a fork
on github here: https://github.com/mladenivkovic/grackle-swift .
The version available there will be tried and tested and ensured to work with
SWIFT.
Additionally, that repository hosts files necessary to install that specific
version of grackle with spack.
HEALPix C library
~~~~~~~~~~~~~~~~~~~
This is required for making light cone HEALPix maps. Note that by default HEALPix builds a static library which cannot be used to build the SWIFT shared library. Either HEALPix must be built as a shared library or -fPIC must be added to the C compiler flags when HEALPix is being configured.
This is required for making light cone HEALPix maps. Note that by default HEALPix
builds a static library which cannot be used to build the SWIFT shared library.
Either HEALPix must be built as a shared library or -fPIC must be added to the C
compiler flags when HEALPix is being configured.
CFITSIO
~~~~~~~
......
......@@ -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::
......