Dependencies between modules

Introduction

As described in Subprojects and modules, the code for the SKIRT project is organized into a set of modules, grouped into the SMILE, SKIRT, MakeUp, and Docs subprojects. Each module is built as a separate static library (or, for a few of them, an executable), and a module may depend on other modules, meaning that its code includes header files from those other modules and links against their libraries.

These dependencies form a strict hierarchy: there are no two-way or circular dependencies between modules, and this is enforced rather than merely encouraged. When adjusting or extending the code, it is important not to inadvertently introduce a new dependency that would close a cycle, for example by having a lower-level module call back into a higher-level one. If you are unsure whether a change you are considering would introduce such a cycle, consult the tables below.

The tables list, for every module in the project, the other modules it depends on, split into:

• Direct dependencies – modules whose header files are included directly by this module's own source files.
• Indirect dependencies – modules that are not included directly, but are pulled in transitively through one or more of the direct dependencies.

A module that does not appear as a direct or indirect dependency of a second module can safely be assumed to not be needed by, and must not be made to depend on, that second module.

SMILE subproject

Module	Direct dependencies	Indirect dependencies
build	fundamentals	none
fundamentals	none	none
schema	fundamentals	none
serialize	fundamentals, schema	none
wizard	fundamentals, schema, serialize	none
smiletool	build, fundamentals, schema, serialize	none
shapes	build, fundamentals, schema, serialize	none

SKIRT subproject

Module	Direct dependencies	Indirect dependencies
fitsio	none	none
voro	none	none
tetgen	none	none
mpi	fundamentals	none
utils	fundamentals	none
tools	fitsio, fundamentals, mpi, schema, utils	none
field	fundamentals, tools, utils	fitsio, mpi, schema
grain	fundamentals, tools, utils	fitsio, mpi, schema
sed	fundamentals, tools, utils	fitsio, mpi, schema
geometry	fundamentals, mpi, tools, utils, voro	fitsio, schema
wavelength	fundamentals, tools, utils	fitsio, mpi, schema
source	field, fundamentals, geometry, mpi, sed, tools, utils, wavelength	fitsio, schema, voro
material	fundamentals, grain, mpi, tools, utils, wavelength	fitsio, schema
medium	field, fundamentals, geometry, material, mpi, tetgen, tools, utils, wavelength	fitsio, grain, schema, voro
instrument	fundamentals, mpi, tools, utils, wavelength	fitsio, schema
probe	fundamentals, geometry, grain, instrument, material, medium, mpi, source, tools, utils, wavelength	field, fitsio, schema, sed, tetgen, voro
simulation	build, field, fundamentals, geometry, grain, instrument, material, medium, mpi, probe, schema, sed, serialize, source, tools, utils, wavelength	fitsio, tetgen, voro

MakeUp subproject

Module	Direct dependencies	Indirect dependencies
main	build, fundamentals, wizard	schema, serialize

Docs subproject

Module	Direct dependencies	Indirect dependencies
doxstyle	fundamentals	none

Dependency diagram

The diagram below shows a summary of the information in the tables above, restricted to the SKIRT modules themselves plus the four SMILE modules they reach into directly. An arrow points from a module down to a module it depends on. To limit the number of arrows, an arrow that is already implied by a chain of other arrows is omitted. In other words, only the transitive reduction is shown.

Spatial grids in medium module

There is an intimate bidirectional dependency between the medium system and the spatial grid classes. The medium system owns and uses the simulation's spatial grid to construct and manage the per-cell medium state. Vice versa, spatial grid setup often requires access to the medium components to determine the grid structure (for example, based on medium density). To avoid forbidden cyclic dependencies between modules, the spatial grid classes are included in the medium module. Resolving this issue would require a major redesign.