Commit 44513714 authored by Rainer Weinberger's avatar Rainer Weinberger

updates in user guide

parent 0d902274
This diff is collapsed.
......@@ -2,58 +2,77 @@ Code development
************************
We strongly encourage further development of the code by other people. The idea
with this public version is to provide a well tested stable version of AREPO to
the community as a basis of individual model development. Changes to the code can
then be made in two ways: bugfixes and code extensions. The former is organized in
the issue-tracking system of the repository, while for the
second one, the developers should be contacted.
Issue reporrting
================
Problems with the code will in generally be reported to the issue tracker of the repository.
Therefore, if a problem occurs, the first thing to check is whether there already exists
an open issue, i.e. whether this is a known problem. If not, there are two ways to create
a new issue.
* The issue tracking system of the gitlab repository requires log-in to ``gitlab.mpcdf.mpg.de``.
In general, AREPO users will not have this access, however, active developers may request
a guest account there, and can then create own issues. These issues need to be specific
and reproducible, or directly point to the problematic part of the code.
* AREPO users without such an account should contact the authors in case of problems with the
code. Also in this case examples that reproduce the issue greatly help and accellerate
the problem-solving process.
Scientific software development is a crucial aspect of computational (astro-)physics.
With the progess made over the past decades, numerical methods as well as implementations
have evolved and increased in complexity. The scope of simulation codes has
increased accordingly, such that the question how to organize development becomes important
to scientific progress.
This version of Arepo is intended as a basis, providing an efficient code structure
and state of the art numerical techniques for gravity and hydrodynamics. The code is
completely documented and should allow computational astrophysicists to develop their
own specialized modules on top of it. Practically, this is best done by hosting an
own repository for the development, which is occasonally updated from the main
repository to include latest bugfixes. For this workflow to work properly, it is
important to keep the code-base relatively static. For this reason
Code extensions
**the base version of the code is not meant to be extended in functionality.**
This means that only bugfixes as well as updates in the documentation and examples will
be included.
Issue reporting
===============
We welcome code extensions by other people, however with certain requirements
for the implemented modules.
A code of the scope of Arepo will ineviably have a number of issues and so far undetected bugs.
Detection of all issues is very complicated and time-consuming work. This means in practice that
we rely on users that actually report all bugs and issues they come across to improve the quality
of the code. We therefore encourage users to report all issues they have, including things
that remain unclear after reading the documentation. This way we hope to constantly improve the
qualtiy of the code in all its aspects.
To organize this, we created a code support forum (www.arepo-code.org/forums/forum/arepo-forum)
which is publically visible. To create posts on this forum, a registration with admin-approval
is required. We encourage users to sign up under www.arepo-code.org/register and make
use of the forum whenever they have problems.
Issues reported in the forum will then be confirmed by one of the authors and added to the
repository issue tracker, which serves as a to-do list for bug fixes and improvements to
the code. Therefore, if a problem occurs, the first thing to check is whether there already exists
an open issue, i.e. whether this is a known and confirmed problem.
* The modules are under the same terms of use as the AREPO code, i.e. a GPLv3 license.
All modules in this version of AREPO are free to use for everyone.
* The number of interfaces to the main code should be as few as possible.
* The module should be of general interest. This implies in particular that
the implementation needs to work in a fully scalable fashion in massively-parallel
runs, with a minimum of shared/dublicated data.
* The module should come with some additional examples for verification of its
functionality.
**Please use the support forum instead of contacting the authors by email.**
Developers interested to share their module with the community as a part of
AREPO should contact the authors.
**We encourage experienced users to provide help and answer some of the open questions on this forum.**
Code extensions
===============
Extensions should be hosted in separate repositories or branches of the main repository.
We highly welcome such extensions and encourage developers to make them publically
available (under GNU GPL v3). While this can be done independently of the authors,
we would encourage developers to inform the authors once there is a publically
available module in order to have a list of available extensions on the code homepage.
Major code updates
==================
Some guidelines for code extensions and new modules:
Attached a list of important bugfixes and additions with the date and id of the
commit
* Modularity
* Minimize the number of changes in existing source code files to a few function calls
and structured variables within existing elements.
* The source code of an own modue should largely be in separate (i.e. new) files.
* Documentation
* All parameter and config-options should be clearly explained in this documentation.
Feel free to add an addional page to this documentation explaining how your module
works.
* Document what each function does in the source code.
* The Template-Config.sh file should have a short explanation for each flag.
* Verification and examples
* If possible, create one or more addional examples illustrating and testing the module.
+------------------------------------------------------------------+-----------------------+------------+
| **Description** | **date (dd.mm.yyyy)** | **commit** |
+==================================================================+=======================+============+
| Public version complete | 20.03.2019 | |
+------------------------------------------------------------------+-----------------------+------------+
......@@ -4,7 +4,7 @@ Diagnostic output
Arepo will not only output the simulation snapshot and reduced data via
the halo-finder files, but also a number of (mostly ascii) diagnostic log-
files which contian important information about the code performance and
files which contain important information about the code performance and
runtime behavior.
In practice, to quickly check the performance of large
......@@ -104,7 +104,7 @@ cpu.txt
=======
Each sync-point, such a block is written. This file
reports the result of the different timers built into AREPO. Each
reports the result of the different timers built into Arepo. Each
computationally expensive operation has a different timer attached to it and
this way allows to closely monitor what the computational time is spent on.
Some of the timers (e.g. treegrav) have sub-timers for individual operations.
......@@ -114,8 +114,8 @@ possible to identify inefficient parts of the overall algorithm and optimize
only the most time-consuming parts of the code. There is the option
``OUTPUT_CPU_CSV`` which also returns this data as a ``cpu.csv`` file.
The different colums are:
name; wallclock-time (in s) this step; percentage this step; wallclock-time
The different columns are:
name; wallclock time (in s) this step; percentage this step; wallclock time
(in s) cumulative; percentage up to this step. A typical block of cpu.txt looks
the following (here a gravity-only, tree-only run):
......@@ -264,13 +264,13 @@ are written into this file, e.g.
memory.txt
==========
AREPO internally uses an own memory manager. This means that one large chunk of
memory is reserved initially for AREPO (specified by the parameter
`MaxMemSize`) and allocation for individual arrays is handeled internally.
Arepo internally uses an own memory manager. This means that one large chunk of
memory is reserved initially for Arepo (specified by the parameter
`MaxMemSize`) and allocation for individual arrays is handled internally.
The reason for introducing this was to avoid memory fragmentation during
runtime on some machines, but also to have detailed information about how much
memory AREPO actually needs and to terminate if this exceeds a pre-defined
treshold. ``memory.txt`` reports this internal memory usage, and how much memory
memory Arepo actually needs and to terminate if this exceeds a pre-defined
threshold. ``memory.txt`` reports this internal memory usage, and how much memory
is actually needed by the simulation.
.. code-block :: python
......@@ -461,7 +461,7 @@ is actually needed by the simulation.
sfr.txt
=======
In case ``USE_SFR`` is active, AREPO will create a ``sfr.txt`` file, which reports
In case ``USE_SFR`` is active, Arepo will create a ``sfr.txt`` file, which reports
the stars created in every call of the star-formation routine.
The individual columns are:
......@@ -493,7 +493,7 @@ gravitational interactions on the largest possible timestep that is allowed by
the timestep criterion and allowed by the binary hierarchy of time steps.
Each for each timestep, a linked list of particles on this particular
integration step exists, and their statistics are reported in `timebins.txt`.
In this file, the number of gas cells and collisionless-particles in each
In this file, the number of gas cells and collisionless particles in each
timebin (i.e. integration timestep) is reported for each sync-point, as well
as the cpu time and fraction spent on each timebin. A typical bock looks like
......
......@@ -6,38 +6,41 @@
Arepo documentation
**********************
AREPO is a massively parallel code for gravitational n-body systems and
Arepo is a massively parallel code for gravitational n-body systems and
magnetohydrodynamics, both on Newtonian as well as cosmological background.
It is a flexible code that can be applied to a variety of different types of
simulations, offering a number of sophisticated simulation algorithms. A
description of the numerical algorithms employed by the code is given in the
original code paper and subsequent publications. This documentation addresses
the question how to use the different numerical algorithms.
public release paper.
For a more detailed discussion about these algorithms, the original code paper
and subsequent publications are the best resource. This documentation only
addresses the question how to use the different numerical algorithms.
AREPO was written by Volker Springel (vspringel@mpa-garching.mpg.de) with further
Arepo was written by Volker Springel (vspringel@mpa-garching.mpg.de) with further
development by Rüdiger Pakmor (rpakmor@mpa-garching.mpg.de) and contributions by
many other authors. The public version of the code was compiled by Rainer
Weinberger (rainer.weinberger@cfa.harvard.edu).
many other authors (www.arepo-code.org/people).
The public version of the code was compiled by Rainer Weinberger
(rainer.weinberger@cfa.harvard.edu).
Overview
========
The AREPO code was initially developed to combine the advantages of
The Arepo code was initially developed to combine the advantages of
finite-volume hydrodynamics schemes with the Lagrangian invariance of
Smoothed Particle Hydrodynamics schemes. To this end, Arepo makes use of an
smoothed particle hydrodynamics (SPH) schemes. To this end, Arepo makes use of an
unstructured Voronoi-mesh which is, in its standard setting, moving with
the fluid in an quasi-Lagrangian fashion. The fluxes between cells are computed
using a finite-volume approach, and further spatial adaptivity is
provided by the possibility to add and remove cells from the
mesh according to defined criteria. In addition to gas, AREPO allows for a
mesh according to defined criteria. In addition to gas, Arepo allows for a
number of additional particle types which interact only gravitationally, as
well as for forces from external gravitational potentials.
AREPO is optimized for, but not limited to, cosmological simulations of galaxy
Arepo is optimized for, but not limited to, cosmological simulations of galaxy
formation and consequently for simulations with very high dynamic ranges in
space and time. Therefore, AREPO employes an adaptive timestepping for each
individual cell and particle as well as a dynamic, on-the fly load and memory
balancing scheme. In its current version, AREPO is fully MPI parallel, and tested
space and time. Therefore, Arepo employs an adaptive timestepping for each
individual cell and particle as well as a dynamic load and memory
balancing scheme. In its current version, Arepo is fully MPI parallel, and tested
to run with >10,000 MPI tasks. The exact performance is, however, highly problem and
machine dependent.
......@@ -46,7 +49,7 @@ Disclaimer
==========
It is important to note that the performance and accuracy of the code is a
sensitive function of some of the code parameters. We also stress that AREPO
sensitive function of some of the code parameters. We also stress that Arepo
comes without any warranty, and without any guarantee that it produces correct
results. If in doubt about something, reading (and potentially improving) the
source code is always the best strategy to understand what is going on!
......@@ -65,7 +68,7 @@ such recommendations. We encourage every simulator to find out for
herself/himself what integration settings are needed to achieve sufficient
accuracy for the system under study. We strongly recommend to make convergence
and resolution studies to establish the range of validity and the uncertainty of
any numerical result obtained with AREPO.
any numerical result obtained with Arepo.
Table of contents
......
......@@ -2,7 +2,7 @@
Related codes
*************
The general code structure of AREPO is similar to the GADGET code, but with
The general code structure of Arepo is similar to the Gadget code, but with
significant further developments and improvements. However, keeping in mind
that the code architecture originates from an Tree-PM-SPH code helps to
understand why certain things are done in certain ways.
......@@ -16,9 +16,9 @@ presence of the neighbour tree, a search-tree structure on gas cells. In
practice this means that many of the routines that depend on the state of
neighbouring cells, including sub-grid feedback models etc., can be based on
this neighbour search. This makes it possible to port these models from earlier
versions of GADGET to AREPO.
versions of Gadget to Arepo.
However, it is important to realize that routines written for the GADGET code
However, it is important to realize that routines written for the Gadget code
will in general not work directly when ported to Arepo. We encourage developers
to carefully test that the implementation is still having the same effect.
Apart from the differences in implementation, it is also important to realize
......@@ -29,7 +29,7 @@ a sub-grid implementation.
Differences to the development Version
======================================
This public version of AREPO was branched off from the development version in
This public version of Arepo was branched off from the development version in
November 2017, substantially cut down, cleand up and the documentation completed
by Rainer Weinberger. The main reason for doing this is to provide a code to the
community that researchers are able to understand and use without the need of
......@@ -40,7 +40,7 @@ starting point for new developments.
The general idea for this public verson was to preserve the well-tested code
with a limited number of changes. However, some compile-time options have been
eliminated and to recover the same running mode **in the development version
of AREPO**, the following compile-time flags need to be set in `Config.sh`
of Arepo**, the following compile-time flags need to be set in `Config.sh`
* ``PERIODIC`` (has become obsolete over the years)
* ``VORONOI`` (the development version also has an AMR mode)
......
This diff is collapsed.
......@@ -6,28 +6,28 @@ Getting started
Library requirements
====================
AREPO requires the following libraries for compilation:
Arepo requires the following libraries for compilation:
Allways needed:
Always needed:
1. **mpi** The `Message Passing Interface`, version 2.0 or higher.
In practice AREPO is well-tested on the open source libraries
In practice Arepo is well-tested on the open source libraries
MPICH <https://www.mpich.org> and OpenMPI <http://www.open-mpi.org>.
For some machines, vendor supplied versions may exist and can also be used.
AREPO relies exclusively on MPI for its parallelization.
Arepo relies exclusively on MPI for its parallelization.
2. **gsl** `The GNU Scientific Library`. This open-source library is available
under <http://www.gnu.org/software/gsl>.
Needed in some cases:
3. **fftw3** `Fastest Fourier Transform in the West` (<http://www.fftw.org>)
This free software package for Fast-Fourier-Transformations is used in the
This free software package for fast-fourier-transformations is used in the
particle-mesh algorithm. Consequently, it is only needed if ``PMGRID`` is
set in ``Config.sh``.
4. **hdf5** `Hierarchical Data Format` <https://support.hdfgroup.org/HDF5/doc/H5.intro.html>
is a data format specification that is used for the input/output format 3
in Arepo, which is the de-facto standard I/O format (even though the old
GADGET formats are supported). The library is needed if the ``HAVE_HDF5``
Gadget formats are supported). The library is needed if the ``HAVE_HDF5``
flag is set in `Config.sh`.
5. **hwloc** : The `hardware locality library` is useful for allowing
the code to probe the processor topology it is running on and enable a
......@@ -35,7 +35,7 @@ Needed in some cases:
only required if the ``IMPOSE_PINNING`` flag is set.
AREPO needs a working c compiler supporting at least the ``c11`` standard, as
Arepo needs a working c compiler supporting at least the ``c11`` standard, as
well as GNU-Make and Python, which are used in the compilation.
Building the code
......@@ -55,8 +55,8 @@ or by copying the ``Template-Makefile.systype`` file::
and uncommenting the intended ``SYSTYPE`` variable in ``Makefile.systype``.
The ``SYSTYPE`` is a variable defining a specific machine. Each machine has its
specific settings and library paths defined in the Makefile. New ``SYSTYPE`` can
be added as needed.
specific compiler settings and library paths defined in the Makefile. New ``SYSTYPE``
keywords can be added in the Makefile when needed.
Config.sh -- Compile time flags
-------------------------------
......@@ -66,18 +66,20 @@ done best by copying the ``Template-Config.sh`` file::
cp Template-Config.sh Config.sh
Note that the compile-time configuration file does not need to be ``Config.sh``,
Note that the compile-time configuration file does not need to be called ``Config.sh``,
however, if it is not, this needs to be specified when calling the Makefile.
An example if this are the code examples.
The ``Config.sh`` file contains the possible running modes of AREPO, and the
flags not outcommented with a '#' will be processed and included by a
For example, for the code examples this file is located in a different location.
The ``Config.sh`` file contains the possible modules of Arepo, such as e.g.
``SELFGRAVITY`` to enable gravitational interactions between cells/particles, and the
flags not out-commented with a '#' will be processed and included by a
``#define MyModule`` in a header file ``arepoconfig.h`` that is included in the
code build directory.
Compiling the code
------------------
AREPO can be compiled with::
Arepo can be compiled with::
make
......@@ -100,7 +102,7 @@ code such as ``#if defined(MyFlg)``, which are generally very hard to find
because the code might compile normally, but the code followed by
``#if defined(MyFlg)`` just does not appear in the executable.
New flags that can be actvated should be included to ``Template-Config.sh``,
New flags that can be activated should be included to ``Template-Config.sh``,
while internally defined flags are listed in ``defines_extra``.
Starting the code
......@@ -109,12 +111,12 @@ Starting the code
param.txt -- Runtime settings
-----------------------------
After compiling AREPO, the executable ``Arepo`` should be present in the main
directory. To start a simulation, AREPO needs be handed over the path to
After compiling Arepo, the executable ``Arepo`` should be present in the main
directory. To start a simulation, Arepo needs be handed over the path to
a file containing the runtime parameters, usually called ``param.txt``.
The settings that need to be set generally depend on the compile-time flags
used. All possible parameters are listed under :ref:`Parameterfile`, including the
compile-time flags they belong to. Starting AREPO with a parameter file that has
compile-time flags they belong to. Starting Arepo with a parameter file that has
too few or obsolete parameter settings will result in an output telling which
parameters are required or still needed, respectively.
......@@ -126,18 +128,18 @@ A simulation is started with::
mpirun -np 32 Arepo param.txt
which will start Arepo on 32 MPI ranks using the ``param.txt`` file for the
run-time paramter input. Note that one some systems, mpirun has a different
run-time parameter input. Note that one some systems, mpirun has a different
syntax. We refer to the user guide of individual machines for such
peculiarities.
Interrupting a run
==================
AREPO supports running a simulations in chunks and resuming an already started
Arepo supports running a simulations in chunks and resuming an already started
simulation via reading in so-called restart files, which are memory dumps
written to the output directory. The code is written in such a way that the
result is completely independent of the number of restarts performed, which is
a cruicial aspect for debugging the code.
a crucial aspect for debugging the code.
A (regular) code termination always results in the writing of such restart
files, and is triggered whenever 85% of the specified maximum runtime has been
......@@ -152,19 +154,19 @@ file called ``stop`` in the output directory.::
touch stop
Note that AREPO usually produces restart-files in regular user specified time
Note that Arepo usually produces restart-files in regular user specified time
intervals to ensure runs can be resumed without a major loss of computation
time even if a run was terminated by the operating system.
Restarting a run
================
A simulaion can be restarted in two ways in AREPO, which is indicated with the
A simulation can be restarted in two ways in Arepo, which is indicated with the
additional flags 1 or 2 in the execution call. The flag 1 is the restarting
from a restart file and generally recommended if possible. This, however,
has the restriction that a run needs to be resumed with **exactly as many MPI
ranks** as it was originally started from. The restart-command then looks
the following:
the following::
mpirun -np 32 ./Arepo param.txt 1
......@@ -172,21 +174,21 @@ The flag 2 denotes a restart from a regular snapshot output. This is possible,
however the simulation generally will not be binary identical to a run without
this restart. In particular in runs where the fields (especially positions) are
written in single precision, this can have effects on the overall quality of
the simulation. A command to restart AREPO from a snapshot looks the following::
the simulation. A command to restart Arepo from a snapshot looks the following::
mpirun -np 32 ./Arepo param.txt 2 7
in which case AREPO would read in the snapshot 7 and resume the simulation from
in which case Arepo would read in the snapshot 7 and resume the simulation from
there. This second method should only be used if the regular start from
restart files is not possible for some reason.
Starting postprocessing
=======================
Starting post-processing
========================
There are a limited number of posprocessing options in the public version of
There are a number of post-processing options in the public version of
Arepo. The main ones are
* to run the halo and/or subhalo finder in postprocessing (flag 3)
* to run the halo and/or subhalo finder in post-processing (flag 3)
* to convert a snapshot to another format (flag 6),
* to write the Voronoi-mesh data (flag 14)
* to calculate and output the gradients of hydrodynamical quantities (flag 17)
......
Simulation examples
**************************
AREPO is a multi-purpose code that supports a number of different types of
Arepo is a multi-purpose code that supports a number of different types of
simulations. Here, we present some examples that in our opinion are
particularly relevant. This list is by no means complete, and highly biased
to the fields of interest of the authors.
We encourage users that have other simulation setups to make them (or small
test examples) availlable to us, in order to provide a more exhaustive list of
test examples) available to us, in order to provide a more exhaustive list of
examples in future code versions.
......@@ -66,29 +66,29 @@ specific directory is the execution of Arepo ``mpiexec -np 8 ./Arepo param.txt``
because the parameter file contains relative paths of the initial
conditions, other required files, and the output directory. All other
commands can be executed from an arbitrary directory, as long as
the relative path handed over is correct.
the relative path handed over is valid.
Cosmological Simulations
========================
One for the main simulation types in AREPO are simulations on an expanding
One of the main simulation types in Arepo are simulations on an expanding
spacetime, where the coordinates are treated as comoving coordinates.
This mode is active whenever the parameter flag ``ComovingIntegrationOn`` is set
to "1" in the parameter file. In this case the code models the expanding
spacetime discribed by the Friedmann equations.
spacetime described by the Friedmann equations.
The halo (FoF) and subhalo finder (subfind) are analysis tools mainly for these
types of simulatons.
types of simulations.
Cosmological volumes
--------------------
One of the standard types of cosmological simulations are
cosmological volume simulations. These simulatons have a uniform mass
cosmological volume simulations. These simulations have a uniform mass
resolution and are set up using cosmological perturbation theory, converted
to small initial position and velocity perturbations in a periodic box
with fixed comoving extent. These simulatios can be done with gravity only,
with fixed comoving extent. These simulations can be done with gravity only,
in which case the simulation particles are all of a single type (type > 0) and
gravity is recommended to be calculated using a TreePM
algorithm. This means that the compile time flags ``SELFGRAVITY`` and ``PMGRID``
......@@ -115,11 +115,11 @@ studies of galaxy and galaxy cluster formation are so-called zoom simulations,
in which the Lagrangian region belonging to a single final object is
sampled with significantly higher resolution than the rest of the cosmological
volume. This way, it is possible to accurately resolve the formation of an
individual object, while still modelling the large-scale environmental
individual object, while still modeling the large-scale environmental
effects. These simulations are, as the above ones, possible to run in gravity
only mode or including gas physics. A gravity only example is given as
``cosmo_zoom_gravity_only_3d`` in the examples (note however that the ICs need to be created
separately in this example, as they are slightly too large to inclue them
separately in this example, as they are slightly too large to include them
into the main code repository).
Technically, such a zoom simulation needs slightly different configuration
in the particle-mesh algorithm. In particular, it is useful to place a second
......@@ -133,7 +133,7 @@ Initial conditions generation
-----------------------------
The creation of initial conditions for cosmological simulation is in general
a complicated procedure, and not included in the AREPO code. However, we included
a complicated procedure, and not included in the Arepo code. However, we included
in the examples the possibility to download and execute third-party initial condition
generating software to illustrate the general procedure how to create them
(MUSIC, Hahn&Abel 2011, MNRAS, 415, 2101 and N-GenIC,
......@@ -141,7 +141,7 @@ Springel et al. 2005, Nature, 435, 629)
We note that these third party software packages generally
have different library requirements than Arepo, and therefore might
not work immediately on some machines. We also note that the
initial conditions used in the examples are choosen for illustration
initial conditions used in the examples are chosen for illustration
purposes and to minimize computational effort to run them. They are
generally not suited to be used directly in scientific work.
......@@ -149,8 +149,8 @@ generally not suited to be used directly in scientific work.
Newtonian space
===============
Apart from comoving integration, AREPO can also handle ordinary Newtonian
spacetime by coosing the parameter option ``ComovingIntegrationOn 0``.
Apart from comoving integration, Arepo can also handle ordinary Newtonian
spacetime by choosing the parameter option ``ComovingIntegrationOn 0``.
While cosmological simulations usually assume periodic boundary conditions,
simulations in Newtonian space can also have reflective or inflow/outflow
boundary conditions.
......@@ -160,11 +160,7 @@ object, such as in ``isolated_galaxy_collisionless_3d``. This particular case
only contains collisionless particles, namely the dark matter and stellar
component of a disk galaxy, and their gravitational interactions
are calculated with a tree algorithm only, assuming non-periodic forces.
One specific compile-time flag recommended in these kind of simulations is
``RANDOMIZE_DOMAINCENTER``. Without this flag it is possible that correlated
force-errors cause an isolated galaxy to drift from the initial center of
mass, which is prevented by de-correlating these errors by frequently choosing
a new domain center. The initial conditions of this problem are created with
The initial conditions of this problem are created with
the GalIC code (Yurin&Springel 2014, MNRAS, 444, 62). The initial conditions
generation can be triggered in the create.py script, however is a computationally
expensive procedure. Therefore we also provide the initial conditions in the
......@@ -173,15 +169,15 @@ repository.
Another popular type of simulations in galactic astrophysics are mergers of
galaxies. The example ``galaxy_merger_star_formation_3d`` shows such an example,
which is similar to ``isolated_galaxy_collisionless_3d``, however in this
particular case includes gas and two galaxies interacting. AREPO, as every
grid code, requires a finite extent of the simulation box as well as non-zero
particular case includes gas and two galaxies interacting. Arepo, as every
grid code, requires a finite extent of the simulation box as well as positive
density at every point.
This is different from Smoothed-Particle-Hydrodynamics simulations such as
the ones performed with GADGET, where simply not placing gas particles in
This is different from smoothed-particle-hydrodynamics simulations such as
the ones performed with Gadget, where simply not placing gas particles in
the initial condition is an acceptable solution to treat low-density regions.
The initial condition for ``galaxy_merger_sfr_3d`` are, for historic reasons,
Smoothed-Particle-Hydrodynamics initial conditions. To be able to use them
in AREPO, the compile-time opiton ``ADDBACKGROUNDGRID`` was introduced.
smoothed-particle-hydrodynamics initial conditions. To be able to use them
in Arepo, the compile-time option ``ADDBACKGROUNDGRID`` was introduced.
With this mode enabled, the code does not perform a simulation, but converts
the SPH gas particles into a hierarchical oct-tree structure of cells.
Once this is done, this output (using the recommended box size) can be used
......@@ -216,7 +212,7 @@ convergence order of the code. Both these tests are sensitive to accurate
hydrodynamical modelling and gradient estimates.
Other 2d test problems are ``noh_2d``, a converging gas flow in 2d which
introduces a strong shock and is a challanging problem for the Riemann solver,
introduces a strong shock and is a challenging problem for the Riemann solver,
as well as ``current_sheet_2d``, an MHD test probing numerical reconnection
properties of the code.
......@@ -253,12 +249,12 @@ One-dimensional simulations in spherical symmetry
An important set of simulations for stellar astrophysics are one dimensional
simulations in spherical symmetry, such as given for example in
``polytrope_1d_spherical``. Generally, AREPO is not optimized for such kind of
``polytrope_1d_spherical``. Generally, Arepo is not optimized for such kind of
simulations and can only run these in serial. However, this option has proven
to be useful for quick test simulations as well as for calculating radial
profiles which are then used as initial conditions for three dimensional
simulations. One of the key aspect for these simulation is the quality of the
boundary conditions. In this spherically symmetric mode, AREPO uses a
boundary conditions. In this spherically symmetric mode, Arepo uses a
reflective inner boundary condition and an inflow/outflow boundary condition
at the outer end.
......
......@@ -7,7 +7,7 @@ Particle data
Arepo supports various formats for in- and output, which are essentially the same
as in GADGET-2. Format 1 and format 2 are binary outputs and the main reason
as in Gadget-2. Format 1 and format 2 are binary outputs and the main reason
why they are still supported is to allow the use of initial conditions from
well-tested initial condition codes that write one of these formats.
For output (or when creating new initial condition generating code), the
......@@ -49,7 +49,7 @@ script.
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| VelocityCurl | ROTV | :math:`\text{UnitVelocity}` :math:`\text{UnitLength}^{-1}` :math:`h` | Rotation of velocity (``OUTPUT_CURLVEL``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| CoolingHeatingEnergy | COHE | :math:`\text{UnitLength}^{-1}` :math:`\text{UnitVelocity}^3` :math:`\text{UnitMass}` | Actual cooling rate, differing from nominal coolnig rate in star forming cells (``OUTPUT_COOLHEAT``) |
| CoolingHeatingEnergy | COHE | :math:`\text{UnitLength}^{-1}` :math:`\text{UnitVelocity}^3` :math:`\text{UnitMass}` | Actual cooling rate, differing from nominal cooling rate in star forming cells (``OUTPUT_COOLHEAT``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| SurfaceArea | AREA | :math:`\text{UnitLength}^2` :math:`a^2 \, h^{-2}` | Surface area of a Voronoi cell (``OUTPUT_SURFACE_AREA``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
......@@ -85,7 +85,7 @@ script.
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| Softenings | SOFT | :math:`\text{UnitLength}` :math:`a \, h^{-1}` | Gravitational softening length of particle/cell (``OUTPUT_SOFTENINGS``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| GravityInteractions | GINT | | Number of foce calculations in tree (``OUTPUTGRAVINTERACTIONS``) |
| GravityInteractions | GINT | | Number of force calculations in tree (``OUTPUTGRAVINTERACTIONS``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| MagneticField | BFLD | :math:`\text{UnitLength}^{-1.5}` :math:`\text{UnitMass}^{0.5}` :math:`\text{UnitVelocity}` :math:`h \, a^{-2}` | Magnetic field (in code units but Gauss system; note that internally, the Heaviside-Lorentz system is used) (``MHD``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
......@@ -99,7 +99,7 @@ script.
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| SubfindHsml | SFHS | :math:`\text{UnitLength}` :math:`a \, h^{-1}` | SPH smoothing length for density estimate (``SAVE_HSML_IN_SNAPSHOT``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| SubfindVelDisp | SFVD | :math:`\text{UnitVelocity}` | SPH avaraged velocity dispersion around particle (``SAVE_HSML_IN_SNAPSHOT``) |
| SubfindVelDisp | SFVD | :math:`\text{UnitVelocity}` | SPH averaged velocity dispersion around particle (``SAVE_HSML_IN_SNAPSHOT``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
| GroupNr | GROU | | Number of nearest group (``FOF_FUZZ_SORT_BY_NEAREST_GROUP=1``) |
+-----------------------------+--------------+------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------+
......@@ -114,7 +114,7 @@ Format 1
Format 1 is organized in blocks, each holding information about all particles
for a specific property. The first block is the header, containing global
informmation about the particle set. Within the other blocks, particles are
information about the particle set. Within the other blocks, particles are
ordered according to their particle type.
For a more detailed description of this file format, see the GADGET-2 user
......@@ -160,7 +160,7 @@ FOF/Subfind
===========
The halo and subhalo finder produces a separate output file, summarizing the