The parameterfile for GADGET-2 is a simple text file, consisting of pairs of tags and values. For each parameter, a separate line needs to be specified, first listing the name (tag) of the parameter, and then the assigned value, separated by whitespace. It is allowed to add further text behind the assigned parameter value. The order of the parameters is arbitrary, but each one needs to occur exactly one time, otherwise an error message will be produced. Empty lines, or lines beginning with a %-sign, are ignored and treated as comments.
The filename of the initial conditions file. If a restart from a snapshot with the "2" option is desired, one needs to specify the snapshot file here.
Pathname of the output directory of the code.
Filename of the log-file that contain the energy statistics.
Log-file that contains a list of the timesteps taken.
Log-file with performance metrics of the gravitational tree computation.
Log-file with CPU time consumption in various parts of the code.
Basename of restart-files produced by the code.
Basename of snapshot files produced by the code.
File with a list of the desired output times.
CPU-time limit for the present submission of the code. If 85 percent of this time have been reached at the end of a timestep, the code terminates itself and produces restart files.
If set to "1", the code will try to resubmit itself to the queuing system when an interruption of the run due to the CPU-time limit occurs. The resubmission itself is done by executing the program/script given with ResubmitCommand.
The name of a script file or program that is executed for automatic resubmission of the job to the queuing system. Note that the file given here needs to be executable.
The file format of the initial conditions. Currently, three different formats are supported, selected by one of the choices "1", "2", or "3". Format "1" is the traditional fortran-style unformatted format familiar from GADGET-1. Format "2" is a variant of this format, where each block of data is preceeded by a 4-character block-identifier. Finally, format "3" selects the HDF-5 format.
Similar as ICFormat, this parameter selects the file-format of snapshot dumps produced by the code.
If set to "1", the code assumes that a cosmological integration in comoving coordinates is carried out, otherwise ordinary Newtonian dynamics is assumed.
This parameter can in principle be used to select different kinds of timestep criteria for gravitational dynamics. However, GADGET-2 presently only supports the standard criterion "0".
If set to "1", the code tries to read a list of desired output times from the file given in OutputListFilename. Otherwise, output times are generated equally spaced from the values assigned for TimeOfFirstSnapshot and TimeBetSnapshot.
If set to "1", periodic boundary conditions are assumed, with a cubical box-size of side-length BoxSize. Particle coordinates are expected to be in the range [0,BoxSize[.
This sets the starting time of a simulation when the code is started from initial conditions. For cosmological integrations, the value specified here is taken as the initial scale factor.
This sets the final time for the simulation. The code normally tries to run until this time is reached. For cosmological integrations, the value given here is the final scale factor.
Gives the total matter density (in units of the critical density) at z=0 for cosmological simulations.
Gives the vacuum energy density at z=0 for cosmological simulations.
Gives the baryon density at z=0 for cosmological simulations.
This gives the Hubble constant at z=0 in units of 100 km/sec/Mpc. Note that this parameter has been basically absorbed into the definition of the internal code units, such that for gravitational dynamics and adiabatic gas dynamics the actual value assigned for HubbleParam is not used by the code.
The boxsize for simulations with periodic boundary conditions.
The time of the first desired snapshot file in case a file with output times is not specified. For cosmological simulations, the value given here is the scale factor of the first desired output.
The time interval between two subsequent snapshot files in case a file with output times is not specified. For cosmological simulations, this is a multiplicative factor applied to the time of the last snapshot, such that the snapshots will have a constant logarithmic spacing in the scale factor. Otherwise, the parameter is an additive constant that gives the linear spacing between snapshot times.
The value specfied here gives the time in seconds the code will run before it writes regularly produced restart files. This can be useful to protect against unexpected interruptions (for example due to a hardware problem) of a simulation, particularly if it is run for a long time. It is then possible to resume a simulation from the last restart file, reducing the potential loss to the elapsed CPU-time since this was produced.
The code can be asked to measure the total kinetic, thermal, and potential energy in regular intervals, and to write the results to the file given in EnergyFile. The time interval between two such measurements is given by the parameter TimeBetStatistics, in an analogous way as with TimeBetSnapshot. Note that the compile time option COMPUTE_POTENTIAL_ENERGY needs to be activated to obtain a measurement of the gravitational potential energy.
The number of separate files requested for each snapshot dump. Each file of the snapshot will hold the data of one or several processors, up to all of them. NumFilesPerSnapshot must hence lie between 1 and the number of processors used. Distributing a snapshot onto several files can be done in parallel and may lead to much better I/O performance, depending on the hardware configuration. It can also help to avoid problems due to big files (>2GB) for large simulations. Note that initial conditions may also be distributed into several files, the number of which is automatically recognised by the code and does not have to be equal to NumFilesPerSnapshot (it may also be larger than the number of processors).
The number of files the code may read or write simultaneously when writing or reading snapshot/restart files. The value of this parameter must be smaller or equal to the number of processors.
This dimensionless parameter controls the accuracy of the timestep criterion selected by TypeOfTimestepCriterion.
This sets the value of the Courant parameter used in the determination of the hydrodynamical timestep of SPH particles.
This gives the maximum timestep a particle may take. This should be set to a sensible value in order to protect against too large timesteps for particles with very small acceleration. For cosmological simulations, the parameter given here is the maximum allowed step in the logarithm of the expansion factor. Note that the definition of MaxSizeTimestep has changed compared to Gadget-1.1 for cosmological simulations.
If a particle requests a timestep smaller than the value specified here, the code will normally terminate with a warning message. If compiled with the NOSTOP_WHEN_BELOW_MINTIMESTEP option, the code will instead force the timesteps to be at least as large as MinSizeTimestep.
This selects the type of cell-opening criterion used in the tree walks. A value of `0' results in standard Barnes & Hut, while `1' selects the relative opening criterion of GADGET-2.
This gives the maximum opening angle if the BH criterion is used for the tree walk. If the relative opening criterion is used instead, a first force estimate is computed using the BH algorithm, which is then recomputed with the relative opening criterion.
The accuracy parameter for the relative opening criterion for the tree walk.
The domain decomposition and tree construction need not necessarily be done every single timestep. Instead, tree nodes can be dynamically updated, which is faster. However, the tree walk will become more expensive since the tree nodes have to "grow" to keep accomodating all particles they enclose. The parameter TreeDomainUpdateFrequency controls how often the domain decomposition is carried out and the tree is reconstructed from scratch. For example, a value of 0.1 means that the domain decomposition and the tree are reconstructed whenever there have been more than 0.1*N force computations since the last reconstruction, where N is the total particle number. A value of 0 will reconstruct the tree every timestep.
This parameter is an additional timestep criterion for the long-range integration in case the TreePM algorithm is used. It limits the long-range timestep such that the rms-displacement of particles per step is at most MaxRMSDisplacementFac times the mean particle separation, or the mesh-scale, whichever is smaller.
This sets the desired number of SPH smoothing neighbours.
This sets the allowed variation of the number of neighbours around the target value DesNumNgb.
This sets the value of the artificial viscosity parameter used by GADGET-2.
This sets the initial gas temperature (assuming either a mean molecular weight corresponding to full ionization or full neutrality, depending on whether the temperature is above or below 10^4 K) in Kelvin when initial conditions are read. However, the gas temperature is only set to a certain temperature if InitGasTemp>0, and if the temperature of the gas particles in the initial conditions file is zero, otherwise the initial gas temperature is left at the value stored in the IC file.
A minimum temperature floor imposed by the code. This may be set to zero.
Each processor allocates space for PartAllocFactor times the average number of particles per processor. This number needs to be larger than 1 to allow the simulation to achieve a good work-load balancing, which requires to trade particle-load balance for work-load balance. It is good to make PartAllocFactor quite a bit larger than 1, but values in excess of 3 will typically not improve performance any more. For a value that is too small, the code may not be able to succeed in the domain decomposition and terminate.
To construct the BH-tree for N particles, somewhat less than N internal tree-nodes are necessary for `normal' particle distributions. TreeAllocFactor sets the number of internal tree-nodes allocated in units of the particle number. By experience, space for 0.65 N internal nodes is usually fully sufficient, so a value of 0.7 should put you on the safe side.
This specifies the size (in MByte per processor) of a communication buffer used by the code.
This sets the internal length unit in cm/h, where H_0 = 100 h km/sec/Mpc. For example, a choice of 3.085678e21 sets the length unit to 1.0 kpc/h.
This sets the internal mass unit in g/h, where H_0 = 100 h km/sec/Mpc. For example, a choice of 1.989e43 sets the mass unit to 10^10 M_sun/h.
This sets the internal velocity unit in cm/sec. For example, a choice of 1e5 sets the velocity unit to km/sec. Note that the specification of UnitLength_in_cm, UnitMass_in_g, and UnitVelocity_in_cm_per_s also determines the internal unit of time.
The numerical value of the gravitational constant G in internal units depends on the system of units you choose. For example, for the choices above, G=43007.1 in internal units. For GravityConstantInternal=0, the code calculates the value corresponding to the physical value of G automatically. However, you might want to set G yourself. For example, by specifying GravityConstantInternal=1, UnitLength_in_cm=1, UnitMass_in_g=1, and UnitVelocity_in_cm_per_s=1, one obtains a `natural' system of units. Note that the code will nevertheless try to use the `correct' value of the Hubble constant in this case, so you should not set GravityConstantInternal in cosmological integrations.
This parameter sets the minimum allowed SPH smoothing length in units of the gravitational softening length of the gas particles. The smoothing length will be prevented from falling below this value. When this bound is actually reached, the number of smoothing neighbors will instead be increased above DesNumNgb.
The Plummer equivalent gravitational softening length for particle type 0, which are the gas particles. For cosmological simulations in comoving coordinates, this is interpreted as a comoving softening length.
The Plummer equivalent gravitational softening length for particle type 1.
The Plummer equivalent gravitational softening length for particle type 2.
The Plummer equivalent gravitational softening length for particle type 3.
The Plummer equivalent gravitational softening length for particle type 4.
The Plummer equivalent gravitational softening length for particle type 5.
When comoving integration is used, this parameter gives the maximum physical gravitational softening length for particle type 0. Depening on the relative settings of SofteningGas and SofteningGasMaxPhys, the code will hence switch from a softening constant in comoving units to one constant in physical units.
When comoving integration is used, this parameter gives the maximum physical gravitational softening length for particle type 1.
When comoving integration is used, this parameter gives the maximum physical gravitational softening length for particle type 2.
When comoving integration is used, this parameter gives the maximum physical gravitational softening length for particle type 3.
When comoving integration is used, this parameter gives the maximum physical gravitational softening length for particle type 4.
When comoving integration is used, this parameter gives the maximum physical gravitational softening length for particle type 5.
Generated on Sun May 22 17:33:31 2005 for GADGET-2 by