-
Notifications
You must be signed in to change notification settings - Fork 19
Coding Conventions
The following are coding conventions employed in Galacticus' source code.
- Variable names use
camelCaseform; - Variable names should be descriptive,
massStellarDiskis preferred overm, ormassfor example;
- For variables which are set via a parameter, the internal variable name should match the parameter name. (This allows automatic handling of the creation of descriptor functions). In some cases this is not possible if the parameter name matches the name of a method of the class. For example, the
stellarFeedbackOutflowsPowerLawclass has a methodvelocityCharacteristic, and also reads a parameter of this name. In such cases the internal variable name should match the parameter name with a_suffix. This convention allows such variables to be correctly included in the creation of descriptor functions.
functionClass objects are the primary object class used within Galacticus to represent physical processes and other actors.
- Only two variables per line, use continuation lines for more than two variables, i.e. instead of:
logical , intent( out) :: diskRequired, spheroidRequired, radiusVirialRequired, radiusScaleRequired
write
logical , intent( out) :: diskRequired , spheroidRequired , &
& radiusVirialRequired, radiusScaleRequired
Comments inside !!{ !!} sections should use LaTeX syntax (as they are directly rendered into the documentation which is built using LaTeX. Comments outside of these sections should avoid LaTeX syntax where possible, and instead use unicode symbols. For example, use ! km s¯¹ instead of ! km s^{-1}.
Where relevant, include citations to papers in comments. For example, before a line implementing an equation from a paper, include a comment line:
! Critical mass model from Author1 & Author2 (2015; http://.......).
It is preferred that the URL be to the NASA ADS entry for the paper if possible.
Citations should also be given in class description elements also - for example if a class implements a model from a specific paper cite that paper in the description, e.g.:
<nodeOperator name="nodeOperatorFunPhysics">
<description>A node operator that implements some fun physics. Based on the model of \cite{funPhysicsPaper}.</description>
</nodeOperator>
and include a bibliography entry in docs/Galacticus.bib for this paper (this will then be automatically included into the documentation). Note that the preferred way to add entries to the bibliography is to first add the relevant NASA ADS record to the Galacticus Zotero library, and then export from there into docs/Galacticus.bib.
- Floating point constants should be written as explicitly double precision, so
7.0should be7.0d0for example. - Avoid arbitrary numbers appearing in the code, e.g. instead of
3.2408d-14, define a variable that has a descriptive name, e.g.:
double precision, parameter :: importantPhysicalConstant=3.2408d-14
so that it is obvious to what this number refers.
Defined constants that convert between units should follow the naming convention: unitAToUnitB which implies that multiplying a quantity in units of unitA by unitAToUnitB will give that same quantity in units of unitB. For example, the constant metersToAngstroms
The unit system in which a constant is defined should be indicated by a suffix starting with an underscore. The default, which requires no suffix, is the SI system. So, for example, the defined constant massSolar (which has no suffix) will be in SI units of kilograms. The defined constant lymanSeriesLimitWavelengthHydrogen_atomic is in the "atomic" unit system, so will be in units of Angstroms.
Currently, defined unit systems are:
- no suffix: With no suffix, the defined constant is in the [SI[(https://en.wikipedia.org/wiki/International_System_of_Units) unit system.
-
_internal: The "internal" suffix indicates a defined constant is in Galacticus's internal unit system of$\mathrm{M}_\odot$ , Mpc, Gyr, and km/s. -
_atomic: The "atomic" suffix indicates atomic units (Å). -
_cgs: The "cgs" suffix indicates a defined constant is in the CGS unit system.
-
Tutorials
- Introduction to Galacticus parameter files
- Dark matter halo mass function
- Warm dark matter halo mass function
- Power spectra
- Warm dark matter power spectra
- Dark matter only merger trees
- Subsampling of merger tree branches
- Dark matter only subhalo evolution
- Solving the excursion set problem
- Reionization calculations
- Instantaneous & Non-instantaneous recycling
- Computing Broadband Stellar Luminosities
- Postprocessing of stellar spectra
- Using N-body Merger Trees
- Generating Mock Catalogs with Lightcones
- Constraining Galacticus parameters
- Generating galaxy merger trees
- Extracting star formation histories
-
How Galacticus works
- Structure Formation Flowchart
- Merger Tree Building Flowchart
- How Galacticus Evolves Halos and Galaxies
- Galaxy Physics Flowchart
- CGM Cooling Physics Flowchart
- Star Formation Physics Flowchart
- Outflow Physics Flowchart
- Galactic Structure Flowchart
- CGM Physics Flowchart
- SMBH Physics Flowchart
- Subhalo Evolution Flowchart
-
Benchmarks and validation