The library (located under the mcstas-comps directory of the McStas source/installation tree, see section 3.3.2 in the User Manual for how mcstas locates it) is organised into the following top-level categories:
sources
Components that define the initial neutron state – see chapter ??.
optics
Guides, slits, choppers, monochromators, mirrors, and other beam-manipulating components.
samples
Components modelling matter placed in the beam for scattering studies (powders, single crystals, SANS models, …) – see chapter ??.
monitors
Components that record/histogram the neutron beam without otherwise affecting it.
misc
Components that do not fit the other categories, e.g. shape primitives, the Progress_bar, and MCPL_input/MCPL_output for reading/writing portable neutron event files.
union
The Union framework (contributed by Mads Bertelsen): 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 neutron. See the worked example in section 8 (Union_demos) and the samples chapter.
sasmodels
Small-angle scattering form factors generated from the SasView/sasmodels project, exposed via the SasView_model component.
contrib
Components contributed by McStas users. The McStas 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 (e.g. several guide, chopper and polarisation components originally contributed have since moved into optics) – always check with mcdoc 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 (mcdoc will point to the current replacement where one exists).
parked
Components that are kept in the source tree (e.g. pending further validation, a rewrite, or reinstatement) but excluded from the regular build/test cycle.