McXtrace - An X-ray ray-trace simulation package

8.1  Component categories

The library (located under the mcxtrace-comps directory of the McXtrace source/installation tree, see section 5.2.2 in the User Manual for how McXtrace locates it) is organised into the following top-level categories:

sources

Components that define the initial photon ray state – including point, flat, divergent and full-featured laboratory-source models – see the Sources chapter of the Component Manual.

optics

Mirrors, lenses, slits, crystal monochromators, and other beam-manipulating components.

samples

Components modelling matter placed in the beam for scattering/absorption studies (SAXS models, powders, single crystals, …) – see the Samples chapter of the Component Manual.

monitors

Components that record/histogram the photon beam without otherwise affecting it.

misc

Components that do not fit the other categories, e.g. the Progress_bar and beam-statistics utilities.

union

The Union framework: a set of process/geometry components that can be freely combined to describe complex, possibly nested and overlapping sample environments with multiple scattering, decoupling the description of where matter is from what it does to the photon (Compton/Rayleigh scattering, photoelectric absorption, powder diffraction, …).

sasmodels

Small-angle scattering form factors generated from the SasView/sasmodels project, exposed via the SasView_model component.

astrox

Components specific to the AstroX branch of McXtrace, modelling grazing-incidence X-ray optics for astronomical instrumentation (nested Wolter-type mirror shells, pore and micropore optics).

contrib

Components contributed by McXtrace users. The McXtrace core team provides the same technical support as for other categories, but authored and maintained the code less directly; contributed components are generally reliable, but see each component’s own validation/bugs notes. Components in contrib that mature and gain wide use are periodically promoted into one of the core categories above – always check with mxdoc rather than assuming a component’s category from an older document.

obsolete

Components that were renamed or superseded. They are kept, and continue to work, purely for backwards compatibility with existing instrument files; new instrument development should avoid them (mxdoc will point to the current replacement where one exists).