NCrystal release 3.9.0

After half a year of dedicated work, NCrystal 3.9.0 is finally available! This release brings both general improvements and new features, as well as a slew of maintenance updates and bug fixes. For those wishing all the gory details refer to the CHANGELOG, but in short the highlights are:

• General speedup in a lot of the code. In particular the Fast Fourier Transform code, used when expanding phonon density of states to full scattering kernels for inelastic modelling, was improved by as much as 40%. This will make a noticeable difference when initialising many materials, and is an improvement independent from the multi-threading option mentioned in the next item.

• If requested, NCrystal can now initialise materials even faster, by performing the initialisation calculations in multiple threads. This can for instance be enabled by setting the environment variable NCRYSTAL_FACTORY_THREADS to the number of threads you wish to use (e.g. 8 if you have 8 CPU cores available, or 9999 to have NCrystal pick a number suitable for your machine). Alternatively, you can call functions in the Python, C, or C++ APIs to enable this:

  NC.enableFactoryThreads() # Python
  NC::FactoryThreadPool::enable(); //C++
  ncrystal_enable_factory_threadpool(9999); // C
  export NCRYSTAL_FACTORY_THREADS=9999 # BASH
  

• NCrystal now includes the first iteration of a "Mini Monte Carlo" framework (for lack of a better word), which makes it possible to insert an NCrystal material into a simple geometric "sample" shape, subject it to a source of neutrons, and obtain a spectrum or pattern of the outgoing neutrons. Thus, one can easily produce a simplistic diffraction pattern, including effects of multiple scattering and both elastic and inelastic physics. For now, the focus has been on developing the framework itself, rather than preparing a library of interesting shapes, sources, and tallies. Thus, the only readily available setup in this release is that of a monochromatic pencil beam impinging on a sphere, tallying the outgoing angle of the neutrons as they leave that sphere. Nonetheless, the results provides a very convenient view of how NCrystal modelling translates into a particular pattern -- without the need for an additional software package like McStas, Geant4, or OpenMC. Here is an example showing such a result:

  nctool --mc '2Aa' '5mm' 'AgBr_sg225_SilverBromide.ncmat;temp=350K'
  

  

  It works for single crystal materials as well:

  nctool --mc '3.8Aa' '5mm' 'C_sg194_pyrolytic_graphite.ncmat;mos=1deg;dir1=@crys_hkl:0,0,2@lab:0,3,1;dir2=@crys_hkl:1,0,0@lab:0,1,0;dirtol=180deg'
  

  

  The scope of this "Mini Monte Carlo" framework is of course not to try to rival existing applications in terms of ability to simulate complicated geometries or beamlines, but rather to provide another convenient way to quickly investigate NCrystal materials, as well as potentially serve as a way for NCrystal to be used in a regression-loop while analysing actual neutron scattering data. For that reason, speed has been a major concern, and both multithreading and vectorisation has been utilised to bring the time it takes to go from defined NCMAT data to having a high-statistics diffraction pattern available, down to the sub-second scale.

• Internally NCrystal code no longer uses raw std::cout or printf statements. Rather, all messages are now emitted via a centralised infrastructure. This most importantly fixes an issue where output from the Python and C++ layers could occasionally be emitted in incorrect order - now, when using the NCrystal Python API, all output will be emitted through Python's own print buffer. Secondly, several NCrystal objects now gets a .dump_str() method, meaning for instance that material dumps can be captured in strings rather than emitted on std-output. Finally, this new feature could in principle be used for various output redirection purposes (e.g. a GUI application might wish to show all output from NCrystal in some dedicated text box).

• NCrystal has been updated to work with latest versions of Numpy, Clang, GCC, Python, Gemmi, and Spglib. Additionally work has started to support Intel OneAPI compilers and Microsoft VisualStudio, although more work is needed to finalise this for the case of VisualStudio. As part of these efforts, the ABI had to be broken in some places, since for instance VisualStudio did not support all the data structures used previously (for instance, its std::vector does not accept move-only objects like std::unique_ptr).

• Info objects gets a new .hklObjects() method which returns HKL list information in a more object oriented and convenient format than the existing .hklList(). See issue #164 for more details.