This site uses cookies. By continuing to use this site you agree to our use of cookies. To find out more, see our Privacy and Cookies policy.
Paper The following article is Open access

Recent developments of MCViNE and its applications at SNS

, , , , , , , , , and

Published 12 August 2019 © 2019 The Author(s). Published by IOP Publishing Ltd
, , Citation Jiao Y Y Lin et al 2019 J. Phys. Commun. 3 085005 DOI 10.1088/2399-6528/ab3622

2399-6528/3/8/085005

Abstract

MCViNE is an open source, object-oriented Monte Carlo neutron ray-tracing simulation software package. Its design allows for flexible, hierarchical representations of sophisticated instrument components such as detector systems, and samples with a variety of shapes and scattering kernels. Recently this flexible design has enabled several applications of MCViNE simulations at the Spallation Neutron Source (SNS) at Oak Ridge National Lab, including assisting design of neutron instruments at the second target station and design of novel sample environments, as well as studying effects of instrument resolution and multiple scattering. Here we provide an overview of the recent developments and new features of MCViNE since its initial introduction (Jiao et al 2016 Nucl. Instrum. Methods Phys. Res., Sect. A 810, 86–99), and some example applications.

Export citation and abstract BibTeX RIS

1. Introduction

Several general-purpose Monte Carlo (MC) neutron ray-tracing simulation packages were developed and optimized in the 1990s to help design neutron instruments, including McStas [2], Vitess [3], and IDEAS [4]. These MC software packages simulate a neutron instrument by tracing neutrons through a linear chain of neutron optical components. This linear approach greatly improved the computational efficiency and also simplified the coding of extensions and revisions for these codes, and allows them (especially McStas) to make significant impacts for neutron instrument design. Development of the MCViNE [1] (Monte Carlo Virtual Neutron Experiment) software package was started a decade ago, as it was difficult with the traditional neutron ray-tracing packages such as McStas to include complex, realistic samples and sample environments in ray-tracing simulations. From the beginning, the design goal for MCViNE was to allow for virtual neutron experiments with realistic samples. The focus was on the flexibility of handling complex sample shapes, and being extensible to a rich variety of neutron scattering kernels of materials. Since the introduction of the MCViNE software package [1], it has found a wide range of applications at the Spallation Neutron Source (SNS) at ORNL.

MCViNE simulations of powder and single crystal samples measured at direct-geometry TOF spectrometers (DGS) have shown excellent agreement with experimental datasets, including signals from vibrational and magnetic origins [1] as well as signals from multiple-scattering [5]. The predictive power of MCViNE makes it useful in designing new instruments. MCViNE was used to simulate the CHESS instrument, a new DGS instrument planned for the Second Target Station (STS) at SNS that takes full advantage of high-brightness of STS moderators and is especially suitable for small samples [6]. The simulations allows the designers to optimize the design for the guide and the detector system, and make reasonable comparisons to the CNCS instrument at SNS.

DGS instruments are essential tools for observing excitations in materials. The signatures of the excitations (e.g. dispersions), however, are broadened by an instrument resolution function that may be asymmetric and varies with energy and momentum transfers. The first step to overcome this challenge is to obtain the resolution function accurately. Monte Carlo neutron ray-tracing can take into account the details of instrument beam formation, the effects of the sample shape and scattering/absorption cross sections, and the detector geometry. Therefore, MCViNE can be used to accurately model the resolution function [7, 8]. MCViNE simulations were also performed to study the effects of instrument broadening on measured data. For example, detailed MCViNE simulations of powder 4He data measured at ARCS [9, 10] and single crystal spin-wave data for V2O3 measured at SEQUOIA [11] were used to examine and confirm the material and resolution models.

MCViNE applications are not limited to direct-geometry spectrometers. MCViNE simulations are being used in design of 3D-printed collimators for the SNAP beamline, a diffractometer at SNS [12]. MCViNE is also used in simulating QIKR, a future reflectometer at STS.

2. Software improvements and new features

2.1. Software infrastructure

MCViNE has undergone major improvements in software infrastructure. Many cloud-based tools are now available at no cost to scientific programmers, thanks to relevant tools and services becoming available in the open source software community in recent years.

The source code of MCViNE was migrated from subversion to github, and the source repositories are now hosted at http://github.com/mcvine to make the code easier to access by any interested parties. The build system for MCViNE was changed from a custom build system to CMake, an open-source, cross-platform build/test toolset that is often used to build large C++ projects, including Mantid [13]. The automatic building and testing of MCViNE are now facilitated by travis CI, where tests are regularly run as guards against unexpected changes to MCViNE functionality. The packaging of MCViNE is now done by using conda, an open source package management system, and the releases for MCViNE packages are now hosted at https://anaconda.org/mcvine.

During the transition of the source repositories, the MCViNE dependencies, which were created in the DANSE project, were also migrated from subversion to git, and are now hosted at the github site for DANSE inelastic software repositories at https://github.com/danse-inelastic. The core of the MCViNE package, including all C++ code and the core python packages, are hosted at https://github.com/mcvine/mcvine. Additional MCViNE sub-packages exist. For example,mcvine.instruments provides pre-built instrument simulation applications, mostly for SNS instruments;mantid2mcvine provides a bridge between MCViNE simulations and Mantid. MCViNE core and additional sub-packages can be installed all at once in a modern Linux system by using the conda meta-package named 'mcvine' after the relevant conda channels are added5 .

$ conda install mcvine

New features were introduced to make it easier for users to setup and run MCViNE simulations, including a simplified python scripting interface (2.2), using jupyter notebooks to record simulation workflows (2.3), and a visualization tool for shapes (2.4).

2.2. Scripting interface

The overall architecture of MCViNE has not changed since its initial release [1], but we added support for users to build and run their simulations more easily. The main addition is a new, simplified python scripting interface. A simulation script 'myinstrument.py' can be as simple as:

The script defines an instrument by first creating two components, one neutron source, and one monitor, and adding them to an instrument at designated positions. This demo script will simply obtain an energy spectrum of the neutron source. It is easy to run a quick simulation with this script in python for debugging purpose:

It will simulate only 10 neutron events using a single CPU core.

A full production simulation can be launched from command line:

or from python

Both examples will simulate 1e8 neutron events using 10 CPU cores.

Further, it is now fairly easy to create a numpy-based simulation component. Here is a skeleton of incomplete python code for a simple monitor component:

The key here is that it is easy to access and manipulate neutron data through the numpy interface without the need to program in C or C++, avoiding the hassle of compilation/build/install. One example of using the new python scripting interface and simple numpy-based components is the simulation of the STS QIKR instrument (see section 3.2).

2.3. Jupyter notebooks

A Jupyter notebook [14] is a document format that is both readable and executable when presented from a jupyter hosting website. A jupyter notebook integrates in one document (1) executable code (in this case Python), (2) texts, pictures, and formulas for explanation, and (3) plots and tables for computation results, allowing developers to clearly document a computational workflow and users to follow and modify it. Jupyter notebook examples of MCViNE simulations are available at https://github.com/mcvine/training. For SNS users and staff, they are accessible through the SNS jupyter hub server (See figure 1 for an example).

Figure 1.

Figure 1. Example jupyter notebook for MCViNE running at SNS jupyter hub.

Standard image High-resolution image

2.4. Constructive solid geometry

Geometry of the sample and sample environment can affect the intensities measured at a neutron instrument. For example, the measured intensity in DGS instruments is proportional to the mass of the sample when absorption can be ignored. Users will often need to maximize the amount of sample in the neutron beam in order to maximize the count-rate of the measurement. These bulk samples can often have asymmetric shapes. Samples may also be rotated about the vertical axis to access different portions of reciprocal space. This can result in a scattering intensity that varies as a function of energy transfer and wave-vector transfer due to sample shape anisotropy. MCViNE supports constructive solid geometry (CSG) for specification of the shape of a sample, sample environment, or detector element. A new package SCADgen was created to handle conversion from MCViNE CSG specification in xml format to OpenSCAD file format. This tool allows for easy visualization of the CSG shapes for complex samples, and sample environments such as collimators and diamond anvil cells. See figure 2 for an example.

Figure 2.

Figure 2. A constructive solid geometry rendering of a sample and the sample holder visualized by using SCADgen and OpenSCAD. Three gold rods represent the sample pieces. They are mounted onto an aluminum plate.

Standard image High-resolution image

3. Example applications

In the following, example applications of MCViNE are presented. We will first introduce MCViNE simulations of two STS instruments: CHESS (3.1), a direct-geometry spectrometer, and QIKR (3.2), a reflectometer, showing the versatility of MCViNE's capabilities. Then we will examine resolution calculations (3.3) and sample environment studies (3.4).

3.1. CHESS, an STS direct-geometry spectrometer

The CHESS instrument [6] is a time-of-flight chopper spectrometer designed for STS. It has a detector system with tremendous solid-angle coverage. In its conceptual design, MCViNE contributed to its performance evaluation. More details of MCViNE simulations of CHESS can be found in [6]. The usual CHESS simulation workflow includes the following steps: (1) McStas [2] was used to simulate the beam before the sample position; (2) MCViNE [1] was used to simulate the sample scattering and detector interception of the scattered neutrons, and generate NeXus [15] event files; (3) Mantid [13] was used to reduce the simulated NeXus files. An important step in the design of CHESS was to optimize its detector positions and arrangements. MCViNE is well suited for this work, since the detector arrangement, detector geometry, and absorption characteristics are accurately modeled: the detector packs in simulation consist of 3He tubes at 6 atm pressure; the absorption cross section dependence on neutron energy and absorption position along the neutron trajectory inside the tube are taken into account [1]. When a new design of the detector system is formed, it is first captured as a Mantid IDF xml file, then a conversion script (using mantid2mcvine) is run to create a MCViNE xml file for the detector system. The MCViNE xml file is then used in detector simulations, and the Mantid IDF file is used in reduction of the simulated NeXus file. Several iterations of detector configurations were examined to reach the final design. These iterations were captured in jupyter notebooks (see figure 3(A) for an example), and at each iteration the detector system can be visualized using Mantid (figure 3(B)).

Figure 3.

Figure 3. MCViNE simulation of CHESS. (A) An example notebook of MCViNE workflow for the 8th iteration of detector system design; (B) A screen shot of the Mantid 3D view of the CHESS detector system; (C) Reduced I(Q,E) plot from a virtual CHESS experiment including a vanadium plate with only single-phonon scattering. The dark stripe is due to the plate geometry shadowing a portion of the detectors. The incident energy was 70 meV, which is unrealistic for CHESS. But this simulation is still useful to validate the workflow: the vanadium phonon spectrum is clearly visible; (D) Reduced I(Q,E) from a vanadium sphere shell sample. The incident energy is more realistic at around 5meV; (E) A slice reduced from a virtual single crystal scan with spin-wave excitations.

Standard image High-resolution image
Figure 4.

Figure 4. Simulated 7.5-Hz STS-QIKR reflectivity from an Ir calibration film collected under three different conditions: (top-blue) measurements at angles θ = 1 and 4 for 0.133 and 600 sec, respectively; (middle-red) those same angles collected for 0.133 and 60 sec; and (bottom-green) a single measurement at 2.5 collected for 60 sec.

Standard image High-resolution image

During the design phase, it is useful to validate the simulation workflow with simple virtual samples. A vanadium plate is usually the first choice. Figure 3(C) shows a S(Q,E) spectrum obtained from simulation. The plate was placed perpendicular to the beam, and the dark angle is clearly visible, demonstrating the geometry of the sample and the detector system is as expected. A single-crystal spin-wave sample is routinely run to check the single-crystal simulation workflow, which involves multiple simulations: one for each angle of rotation of the single crystal sample being measured. An example slice along the h00 direction and energy transfer axis is shown in figure 3(E).

3.2. QIKR, an STS reflectometer

The Quite Intense Kinetics Reflectometer (QIKR) will be a general-purpose, horizontal surface reflectometer at STS. Exploiting the increased peak neutron brilliance of the STS, QIKR will be able to collect specular and off-specular reflectivity data faster than the best such existing machines, including the current SNS First Target Station Liquids Reflectometer. Details of the design work for QIKR will be published elsewhere. A MCViNE simulation script driving McStas components was created to simulate the QIKR beam, starting from the moderator and ending just before the sample position. Simulated beam data were saved for later simulations of sample scattering. MCViNE was then used to simulate the sample scattering and detector interception. The sample component specularly reflects the input neutrons, and the reflected beam is passed to a 2D position-sensitive detector component. The simulations were driven by the simple python interface shown in 2.2, and both the sample and the detector components are numpy-based, Python components explained in 2.2. A python/mantid2mcvine script is then used to generate NeXus event data files from the detector data, which were reduced using current Mantid [13] based reduction software for the FTS reflectometers.

3.3. Resolution functions

A clear example of a MCViNE simulation capturing the resolution effects for direct-geometry spectrometers is shown in figure 13 and figure 14 of [1]. There the MCViNE simulation reproduced the focusing effect [17, 18] of instrument broadening for a slice in a single-crystal spinwave dispersion dataset measured at the HYSPEC instrument. In a recent study [8], calibration experiments with a vanadium standard sample were carried out for the ARCS instrument, and the elastic resolution and flux of the ARCS instrument were compared to the PyChop [19] modeling results. It was shown that the PyChop results agreed well with the experimental data for most cases. When the experimental resolution data was not accurate due to overlapping elastic scattering signals and phonon signals, MCViNE simulation results confirmed the PyChop predictions (figure 5 of [8]). A new package, dgsres[20] is being developed to make MCViNE-based calculation of powder and single crystal resolution functions for DGS instruments easier. Figure 5 shows an example comparison and good agreement between MCViNE-simulated instrument-broadening in energy-transfer, and the corresponding experimental results for a powder measurement. Figure 6 shows a typical example comparing experimental and simulated slices along Q = [0.15, 0, L] and energy transfer for a single crystal sample. This measurement of spin-wave excitations was performed on the SEQUOIA instrument [21] at SNS. Further details on this dataset will be published elsewhere [22].

Figure 5.

Figure 5. Experimental and simulated energy resolution functions for the ARCS spectrometer at Ei = 100 meV. (A) Powder I(Q, E) spectrum of a C4H2I2S sample measured at the ARCS instrument, consisting of sharp constant-energy modes at energy transfers from 30 to 90 meV. More details about the experiment can be found in [16]. (B) Energy spectrum obtained from integrating the I(Q, E) spectrum in (A) over Q range of 5–9Å−1. The sharp peaks in this spectrum are used to estimate the energy resolution (full width at half magnitude, or FWHM) at the peak centers. (C) The resolution functions calculated by using MCViNE simulations at energy transfers from 10 to 90 meV with a step size of 10 meV. It is clear that the resolution functions have asymmetric shapes, same as the peaks in (B), and the energy resolution is better at higher energy transfers. (D) FWHM values from MCViNE simulation in (C) and the experimental data in (B). Overall the agreement between the simulation and experiment is good. The experimental FWHM at 30 meV is larger than the MCViNE result because there are double peaks at this position in the experimental spectrum.

Standard image High-resolution image
Figure 6.

Figure 6. Comparison of an experimental slice (A) and the corresponding MCViNE-simulated slice with instrument broadening (B) for a single-crystal scan performed at a direct-geometry chopper spectrometer. In both experimental and simulated data, the right branch (stemming from L = 2) of the spinwave dispersion is clearly sharper than the left branch, showing the focusing effect.

Standard image High-resolution image

3.4. Sample environments

Sample environments are crucial to achieve a variety of experimental conditions (temperature, pressure, magnetic field, etc.). They can complicate data reduction and analysis, due to the extra background from single and multiple scattering events involving those components. MCViNE is well equipped for studies of effects of sample environments. Its capability of simulating multiple scattering was demonstrated in a study of ARCS and SEQUOIA experiments measuring a uranium nitride sample [5], in which multiple scattering simulation reproduced well the extra intensities in low Q region of measured spectra for high order quantum harmonic oscillation excitations. Further studies on uranium carbide (UC) and uranium sulfide (US) show that intensity variation can be captured by MCViNE simulations as the scattering cross section varies with elements (nitrogen/carbon/sulfur) [23]. However some disagreement is seen in the US study where the background scattering is comparable, or larger, than the scattering from sulfur, which has smaller scattering cross section than aluminum, the material of the sample holder. Therefore more investigation into next order effects is needed. MCViNE has assisted in evaluation of a furnace [24] and reproduced the scattering intensities (including multiple-scattering) from the furnace measured at the ARCS instrument, and the effects of the ARCS collimator on the scattering intensities (figure 7 of [24]). It helped design a collimator for the SEQUOIA instrument, by investigating the dependence of the scattering intensity on the sample position, and the dependence of collimator efficiency on the angular spacing between the collimator blades [25].

4. Conclusions and future work

MCViNE has been improved in the last four years in software infrastructure and interfaces for users. Applications of the MCViNE package at SNS include assisting design of new instruments at the second target station, design of sample environments and collimators, as well as advanced data analysis [9, 11, 26, 27]. MCViNE is an ongoing project. We intend to continue improving its user interface to make it easier to create specifications for samples and sample environments, making the McStas/MCViNE connection smoother, and developing more applications for MCViNE, especially on advanced data analysis.

Acknowledgments

The authors thank Jonathan Gaudet, Jon Leiner, Souleymane Diallo, Yuen Yiu and Thomas Huegle for fruitful discussions. This research used resources at the Spallation Neutron Source, a DOE Office of Science User Facility operated by the Oak Ridge National Laboratory. This work was supported by the Department of Energy under contract DE-AC05-00OR22725, and was supported in part by an appointment to the Science Education and Workforce Development Programs at Oak Ridge National Laboratory, administered by ORISE through the U.S. Department of Energy Oak Ridge Institute for Science and Education.

Footnotes

Please wait… references are loading.
10.1088/2399-6528/ab3622