Announcement Release3.0.0
Featuring massive technical work under the hood, the NCrystal v3.0.0 release brings support for multiphase materials, material density control, SANS physics, goodies for McStas users, and various smaller but hopefully handy new features such as defining simple unstructured materials without the need for data files, new handy cfg-parameters, and other quality-of-life improvements.
The work on the release was supported in part by the European Union’s Horizon 2020 research and innovation programme under grant agreement No 951782 (the HighNESS project).
- 1 High level overview
- 2 Multiphase materials
- 3 Framework support for small angle neutron scattering (SANS)
- 4 Density overrides
- 5 Quick unstructured materials
- 6 Cfg-string updates
- 7 Improved integration with McStas
- 8 Clean license for entire NCrystal release + move .nxs support to external plugin
- 9 Various other developments
As will be discussed in more details in dedicated sections below, new features include:
- Support for multiphase materials. These can be defined in terms of phase volume-fractions, either in cfg-strings (
"phases<0.9*Al_sg225.ncmat&0.1*Be_sg.ncmat>"), in NCMAT data, or a combination of those. All interfaces and tools have been updated to properly integrate multiphase materials, in a manner which is believed to not add complications when working with single-phase materials. - Framework-level support for Small Angle Neutron Scattering (SANS) physics. The release includes resources to facilitate future development of advanced SANS models, and already include a hard-sphere SANS model (useful both by itself, and as proof-of-concept for other models).
-
Material densities can now be easily modified. This can be done by either specifying a relative scaling,
"Polyethylene_CH2.ncmat;density=0.9x", or an absolute one:"Polyethylene_CH2.ncmat;density=0.88gcm3"(g/cm³) or"Polyethylene_CH2.ncmat;density=0.1perAa3"(atoms/ų). - Support for quickly setting up unstructured materials with just a cfg-string and without a data file for such simple materials. For instance, a He3 gas might be defined via the cfg-string
"freegas::He/0.17kgm3/He_is_He3". This makes it easy to add materials for which the structure is not deemed important (e.g. in a strongly absorbing material). - The various new features can be combined for quickly setting up advanced materials. For instance, here is how to define a low-density polyethylene with enriched B4C pellets, even without a dedicated data file for B4C:
"phases<0.99*Polyethylene_CH2.ncmat;density=0.8x&0.01*solid::B4C/2.5gcm3/B_is_0.95_B10_0.05_B11>" - Improve documentation of cfg-string parameters, with the code now able to provide dynamic documentation, which can be accessed either programatically (with the Python/C/C++ API or by running
ncrystal_inspectfile --doc), or on the new CfgRefDoc page on this wiki. - Introduce for convenience a new cfg-string parameter
"comp", which can be used to easily pick out one or more of the components contributing to the scattering cross section. For instance, appending";comp=inelas"to any cfg-string (i.e."Al_sg225.ncmat;comp=inelas"), will disable all components except inelastic models. -
Reflection (hkl) planes provided by NCrystal are now grouped according to the symmetry-equivalency indicated by the space group, use less memory and loads significantly faster. Additionally dumps (i.e. printouts, such as via
ncrystal_inspectfile --dump) of such lists have also been much improved. Such dumps are now much faster to display and much (very much) shorter by default. On top of that, if increased dump verbosity is requested, it is now always possible to see the full list of hkl indices in each group. -
Improve and update McStas support:
- Make NCrystal work with both the McStas v2.7 and McStas v3.0 branches.
- Add
ncrystal_ncmat2hklcmd-line utility for converting NCMAT files to the.lazand.laufiles needed by the McStasPowderNandSingle_crystalcomponents (note that this only includes Bragg diffraction, not inelastic/incoherent/SANS/multiphase physics for which direct NCrystal usage in theNCrystal_samplecomponent or McStas-Union system is needed). - Utilities for better/easier integration between NCrystal and the McStas-Union system for complex geometries.
- Remove the few optional files which were not copyrighted by the NCrystal developers, ensuring that the entire NCrystal release now has a single well-defined LICENSE. The removed files were used to support the semi-obsolete .nxs file format, and will still be available as a separately distributed plugin if really needed.
- Stop supporting Python 3.5. Oldest supported Python version is now Python 3.6.
The rest of this page will go through the details behind the above highlights.
Multiphase materials are now supported in NCrystal for the first time. They can be defined either in CfgStrings or NCMAT data, as a composition of other materials. This makes it straight-forward to model many new kinds of materials wherever NCrystal is used. For instance, the capability might be used to describe a multiphased alloy, a crystalline powder suspended in a liquid solution, an imperfectly packed material with void areas, a material with density fluctuations, and so on. It even supports recursive composition, which for instance could be used to model grains of a multiphase material suspended in a fluid. As will be discussed below, the multiphase support also serves as the foundation upon which SANS physics can be supported.
Multiphase materials can be composed from existing materials (such as the ones from the Data-library via the new "phases<...>" cfg-string syntax, listing the desired phases and their volume fraction. This is as easy as:
"phases< 0.1 * PbS_sg225_LeadSulfide.ncmat & 0.9 * Epoxy_Araldite506_C18H20O3.ncmat >"
Cfg-parameters can be applied as always, affecting either a single phase or all phases depending on placement. For instance, in the following (somewhat silly) material the temperature of 300K applies to all phases, while the d-spacing cutoff only affects the aluminium:
"phases<0.25*Al_sg225.ncmat;dcutoff=0.4&0.75*Be_sg194.ncmat>;temp=300K"
Note that whitespace is ignored: the first example above used spaces to improve readability, while the second example left them out for a shorter more compact result. Also note that the "phases<>" syntax has been chosen specifically to support the use-case that one can always override parameters in cfg-strings by appending a simple string to them. For instance appending the string ";temp=400K" to any cfg-string will override the temperature value - whether or not the cfg-string uses the "phases<...>" syntax or not.
Although defining multiphase materials via cfg-strings as described in the previous section is handy, it might in some cases be desirable to allow a single data unit (i.e. a single NCMAT file) to define a multiphase material. For instance, it might be convenient to have a single file represent a given complicated material, in order to easier document and distribute the material (imagine for example having files BeamLine3FrontWindowMaterial.ncmat, DegradedReactorGraphite_v123.ncmat, etc.).
In particular for materials with significant SANS physics (see below), it might be most appropriate to define both phase contents and phase shapes in a single file (imagine for instance having files NanoDiamond_BatchA.ncmat or AluminiumWithVoids.ncmat). Consequently, the NCrystal v3.0.0 release therefore introduces the NCMAT v6 format (see NCMAT format for details), in which a new optional @OTHERPHASES section is introduced. This section allows the definition of one or more secondary phases, by specifying phase volume fractions and cfg strings on one line per secondary phase. For instance the following section can be used to add 5% (by volume) of aluminium and 20% of copper with an increased dcutoff value. The remaining 75% of the volume will be composed of the primary phase, defined in the rest of the file in the usual manner:
@OTHERPHASES
0.05 Al_sg225.ncmat
0.2 Cu_sg225.ncmat;dcutoff=0.5
There are no restrictions on the kind of cfg-strings allowed for usage in either NCMAT files or cfg-strings using the phases<> syntax, so it is entirely possible to mix the two approaches as desired: using phases<> cfg-strings inside the @OTHERPHASES sections of NCMAT files, or referencing multiphase NCMAT files inside cfg-strings.
It is planned to eventually introduce more options for multiphase definitions in NCMAT files, doing away with the need to specify the NCMAT data of the primary phase inside the file itself and instead simply provide the cfg-string of it, if desired.
Crucially, the new and optional multiphase material support is implemented in a way which should not complicate life for users working with single-phase materials. Thus, users or plugin developers can in general keep working with single-phase materials as before.
Of course, this does come with some obvious and necessary caveats. Thus, feeding a multiphase material to code written with single-phase support in mind might end up in errors (or exceptions). For instance, trying to blindly access the crystal structure of a multiphase material would most likely result in an error - since the crystal structure is not well defined in this case. Of course, this is not a fundamentally new situation (e.g. asking for the crystal structure of a single-phase liquid material would also give an error), and it is of course possible to rewrite existing code to become multiphase aware if desired and sensible for the task at hand. Such multiphase awareness will mainly consist of querying the Info objects as to their single- vs. multiphase status, and possibly accessing the list of phases. Each phase will itself be an Info object which might again be either single- or multi-phased.
Importantly, code simply using NCrystal Info objects to ask for quantities which are well-defined for a multiphase material (temperature, density, atomic composition, state-of-matter, ...) will work in all cases, as will NCrystal Scatter and Absorption objects which will automatically provide the aggregated physics of all the different phases (including any SANS components). Therefore, using NCrystal in e.g. McStas, Geant4, or OpenMC, or as a driver for any such Monte Carlo code, should in principle work just fine with multiphase materials.
Furthermore, tools like ncrystal_inspectfile have naturally been updated to work properly with multiphase materials. Thus, material dumps (printouts) will provide sensible dumps of multiphase materials, while plotting has a new --phases option which can be used to obtain plots in which the cross sections are broken down by phase rather than by physics type. Here is an example:
$> ncrystal_inspectfile -d "phases<0.99*Polyethylene_CH2.ncmat;density=0.8x&0.01*solid::B4C/2.5gcm3/B_is_0.95_B10_0.05_B11>"
----------------------------------------------------------------------------------------------------
------------------------------------ NCrystal Material Info ------------------------------------
----------------------------------------------------------------------------------------------------
Data source: <multiphase>
----------------------------------------------------------------------------------------------------
Density : 0.75364 g/cm3, 0.0952874 atoms/Aa^3
----------------------------------------------------------------------------------------------------
Composition (by mole): 33.1318% C 65.6589% H 1.20929% B{95%B10+5%B11}
----------------------------------------------------------------------------------------------------
Composition (by mass): 83.5499% C 13.8952% H 2.55486% B{95%B10+5%B11}
----------------------------------------------------------------------------------------------------
Atom data:
C = C(cohSL=6.646fm cohXS=5.55048barn incXS=0.001barn absXS=0.0035barn mass=12.011u Z=6)
H = H(cohSL=-3.739fm cohXS=1.75679barn incXS=80.26barn absXS=0.3326barn mass=1.00798u Z=1)
B{95%B10+5%B11} = B{95%B10+5%B11}(cohSL=0.2375fm cohXS=0.00708822barn incXS=3.13246barn absXS=3643.25barn mass=10.0628u Z=5)
----------------------------------------------------------------------------------------------------
Averaged quantities:
Atomic mass : 4.76298u
Absorption XS at 2200m/s : 44.2768 barn
Free scattering XS : 15.0504 barn
Scattering length density : -0.238387 10^-6/Aa^2
----------------------------------------------------------------------------------------------------
Temperature : 293.15 kelvin
----------------------------------------------------------------------------------------------------
State of matter: Solid
----------------------------------------------------------------------------------------------------
Multi-phase material with 2 phases:
0) 99% (volume) 98.4884% (mole) 96.6828% (mass): H / C
1) 1% (volume) 1.51161% (mole) 3.31723% (mass): B / C
----------------------------------------------------------------------------------------------------
Finally, a new special cfg-string parameter, phasechoice is introduced. This parameter allows one to pick out a given phase from a multiphase material. For instance, if nanodiamond.ncmat contains 2 phases (the diamond phase and a solution), then "nanodiamond.ncmat;phasechoice=0" and "nanodiamond.ncmat;phasechoice=1" can be used to set up a material with just the first or second phase, respectively. This is particular useful when inspecting materials with ncrystal_inspectfile (as in the dump example above): after noticing with ncrystal_inspectfile --dump nanodiamond.ncmat that the material has two phases, and that the first phase is the diamond phase, then ncrystal_inspectfile --dump "nanodiamond.ncmat;phasechoice=0" can be used to obtain the full information about that phase (e.g. the crystal structure, etc.).
Naturally coupled with the support for multiple phases, is the framework-level support for the SANS physics arising as a result of the geometry and contrast (in terms of differences in scattering length densities) between these phases. Although the syntax for configuring SANS physics in NCrystal has not been finalised, the NCrystal v3.0.0 release includes resources to facilitate future development of advanced SANS models, and already include a hard-sphere SANS model which is useful both by itself, and as proof-of-concept for other models. As the syntax is not finalised yet, one must for now use the @CUSTOM_xxx syntax which is normally used by external plugins to use this model. It takes a single geometric parameter, the sphere radius in Ångström, and other parameters related to phase fractions and scattering length densities, are automatically determined based on the phases defined in the rest of the file. It requires at least two phases to be defined, and in case of more than two phases, the SANS model will be applied to the first two phases. Due to the symmetries involved in SANS physics, it does not matter for the resulting physics whether one imagines spheres of the first phase embedded in the second phase, or instead spheres of the second phase in the first phase. For reference, here is an example of how one might currently set up a material with diamond spheres in water:
NCMAT v6
@OTHERPHASES
0.90 LiquidHeavyWaterD2O_T293.6K.ncmat
@CUSTOM_HARDSPHERESANS
#sphere radius in Angstrom:
100
# The rest of the file following here is essentially
# just a copy-paste of C_sg227_Diamond.ncmat
Naturally, this type of syntax is not considered ideal in the long run, due to the copy-paste and usage of @CUSTOM_xxx sections. For now it is simply considered a technology-preview, to be replaced in a future release with a nicer and more permanent syntax. For reference, here is how the material looks after running ncrystal_inspectfile on it with no other flags:
In the last of these plots above, the SANS contribution is the points clustered in the forward (scattering angle around 0) direction. Adding the --phases flag to the ncrystal_inspectfile command, instead gives the cross section plot:
Finally, here is a plot (made by using NCrystal from Python, not directly ncrystal_inspectfile) of the sampled Q-values (for just the SANS component):
As part of the framework-level support for SANS physics, all Info objects (and dumps of Info objects) now provide scattering length densities, and a new boolean cfg-string parameter named sans has been introduced (default value: true), meaning that it is possible to toggle SANS physics in the same manner as inelastic physics, coherent-elastic physics or incoherent-elastic physics is already. Additionally, the comp parameter (see below) also treats SANS as a special component, and when plotting with ncrystal_inspectfile, separate cross section curves will be shown for SANS when appropriate.
It is now straight-forward to tune the densities of a material at the cfg-string level. This can be as simple as directly specifying an absolute density value like "myfile.ncmat;density=2.68gcm3" (indicating a unit of g/cm³), with other recognised units being kgm3 (kg/m³) and perAa3 (atoms/ų). Alternatively, a relative scaling of values can be indicated by using the unit x, e.g. "myfile.ncmat;density=1.2x". Multiple relative scalings are cumulative, so "myfile.ncmat;density=1.2x;density=0.5x" is equivalent to "myfile.ncmat;density=0.6x". Behind the scenes, the implementation makes sure to avoid costly reinitialisations when multiple materials are loaded and they just differ by this density override. Furthermore note that when the density of a material is modified, this will not affect the per-atom cross sections provided by NCrystal, but rather simply affect the density and number-densities fields of material Info objects. In other words, modifying the density of a material will affect macroscopic but not microscopic cross sections. On the other hand, modifying the density of a single phase in a multiphase material, will affect the relative number density of atoms in each phase, and therefore the final microscopic cross sections will change in this case.
One interesting application of the density override capability is that when combined with the new SANS capabilities, it is now possible to model SANS arising from density fluctuations within a material.
Related to the introduction of the "density" cfg parameter, the old "packfact" parameter is removed. Thus, the previous usage of "...;packfact=0.8" must now instead be replaced with "...;density=0.8x". One subtle difference is that the packfact parameter did not accumulate values, so "myfile.ncmat;packfact=0.5;packfact=0.8" would scale the density by 80%, whereas "myfile.ncmat;density=0.5x;density=0.8x" will now scale it with 0.5*0.8=40%. To avoid this potential confusion, cfg-strings with packfact parameters will now trigger an error (exception), and must be replaced by usage of the new density parameter.
Although detailed realistic modelling of thermal neutron scatterings depend crucially on the material structure and dynamics, it is nonetheless often useful to be able to put together an unstructured material (a.k.a. "a bag of atoms") which is the default way to handle most materials in Geant4, MCNP, OpenMC, etc. The reasons for this might range from one of technical convenience (e.g. one is already using NCrystal for all the materials), to the physics modelling of such materials actually being adequate for the intended purpose (this might in particular be the case for an ideal gas or a strongly absorbing material).
Adding such unstructured materials have been possible in NCrystal since quite a while, but with the downside of having to write a custom NCMAT file (on-disk or in-memory) for each material. Instead, starting with the NCrystal v3.0.0 release, such materials can be defined simply by providing the material density and atomic composition directly in the parts of a cfg-string usually occupied by a filename. Finally, one should also indicate whether the dynamics of the atoms in the material should be approximated with a free gas model (unbound atoms) or a model more appropriate for a solid (bound atoms). Here are a few hopefully self-explanatory examples (note in particular that you can set cfg-string parameters such as the temperature as usual):
"freegas::Ar/2.5e-5perAa3"
"freegas::CF4/3.72kgm3"
"freegas::CO2/1.98kgm3"
"solid::Gd2O3/7.4gcm3"
"solid::AgBr/6.48gcm3"
"solid::AgBr/6.48gcm3;temp=100K"
Strictly speaking, of these examples only the argon-gas is modelled with an entirely appropriate model. But whether or not the modelling of these quick unstructured materials is precise enough for a given use-case, obviously depends on the material and context. For instance, merely looking at the total scattering cross section in a crystalline material like silver-bromide, might lead one to conclude that the modelling is highly inaccurate, especially at energies below the Bragg threshold (here compared to an NCMAT file which does include the material structure):
While that is obviously true, for use-cases where one can not ignore the absorption cross section, the three ways of modelling instead seems rather similar:
In general, at least concerning solids, the approximation of using these quickly specified unstructured materials to model interactions with thermal neutrons, will most likely work best for materials which are either non-crystalline or at least not dominated by coherent elastic scattering.
In addition to the atomic composition and density, it is also possible to change atoms themselves to for instance enrich materials. For instance, the following examples show how to define a He3 gas or boron carbide enriched to 95% B10 (both of these examples actually provide rather precise models as one is an ideal gas and the other is dominated by absorption):
"freegas::He/0.17kgm3/He_is_He3"
"solid::B4C/2.52gcm3/B_is_0.95_B10_0.05_B11"
The syntax of the atomic specifications (He_is_He3, etc.) follows the usual format of the @ATOMDB section in NCMAT data (for details see NCMAT-format), but using underscores to delimit words.
While it is obvious that the freegas:: materials simply get all individual atoms modelled with a free gas model, the model for the bound atoms in solid:: materials is somewhat more elaborate, but really just reuses the machinery introduced between NCrystal v2.0.0 and NCrystal v2.7.0 for modelling scattering in amorphous solid materials. Specifically, the materials are simply defined as amorphous solid materials with phonon densities provided by the simple Debye model. By default a Debye temperature of 300K is used for all materials, but in cases where this value is deemed inappropriate, it is easy to change it for either all or specific atoms using the following syntax:
"solid::Al2O3/4gcm3"
"solid::Al2O3/4gcm3/TDebye750K_Al/TDebye1000K_O"
"solid::Al2O3/4gcm3/TDebye900K"
In these examples the Debye temperature values were increased from the default 300K, indicating more tightly bound atoms. To see the effect in action, we can for instance look at the silver-bromide scattering cross sections again, but this time also showing curves where the binding has been loosened, by providing more accurate values for the Debye temperatures:
For many more details about Debye temperatures and how NCrystal uses these to estimate inelastic interactions, refer to Announcement-Release2.0.0. For details about how amorphous solids are currently treated in NCrystal, refer to Announcement-Release2.7.0. Finally, for details concerning how the elastic contributions are implemented refer to the discussions concerning incoherent-elastic scattering in doi:10.1016/j.cpc.2021.108082.
Although it might not always be obvious what values to use for Debye temperatures, the plot above illustrates how having just a single cross section measurement at very low energies, might be enough to help tune this value. Alternatively, in cases where one has an idea of the mean-squared-displacements of the atoms, one can use the debyeTempFromIsotropicMSD function from either the C++ or Python interface of NCrystal to translate that into a Debye temperature. It is expected, however, that most usage of the new solid::... factory for quick unstructured materials will not really need a particular tuning of the Debye temperature value. After all, if the use-case study is truly sensitive to such details, then it is most likely better to try to do the extra work and produce a dedicated NCMAT file for details about the material (request help with that here, or try out the ncrystal_hfg2ncmat or ncrystal_onlinedb2ncmat scripts which were both discussed on Announcement-Release2.7.0). (NOTE: The ncrystal_onlinedb2ncmat command was replaced with ncrystal_cif2ncmat command in release 3.6.0)
Under the hood, the new support for quick unstructured solid:: or freegas:: materials is implemented as two special TextData factories, which parses the "filenames" they are given, and returns NCMAT text data corresponding to the request. That text data is then dealt with by the rest of the NCrystal infrastructure as it would any other file in NCMAT format. For debugging purposes (or just to see what goes on), one can as always ask NCrystal to show the intermittent text data by providing the --extract flag to ncrystal_inspectfile:
$> ncrystal_inspectfile --extract solid::AgBr/6.48gcm3
NCMAT v6
#
# Automatically generated NCMAT data for AgBr (amorphous solid, Debye model)
#
# Request: "solid::AgBr/6.48gcm3"
#
@STATEOFMATTER
solid
@DENSITY
6.48 g_per_cm3
@DYNINFO
element Br
fraction 1/2
type vdosdebye
debye_temp 300
@DYNINFO
element Ag
fraction 1/2
type vdosdebye
debye_temp 300
With the advent of the multiphase support in NCrystal 3.0.0, the quick factories might be particularly useful when used to add small secondary phases to existing materials. For instance, here is PE with small enriched B4C pellets, all in a single cfg-string:
phases<0.99*Polyethylene_CH2.ncmat&0.01*solid::B4C/2.52gcm3/B_is_0.95_B10_0.05_B11>;temp=400K
The multiphase support necessitated an almost complete rewrite of the configuration engine internal to NCrystal. As a side benefit of this rewrite, a few new features were made possible. These, and other changes related to cfg-string parameters are described in the following.updated slightly.
Documentation of all cfg-string parameters are now automatically generated and available at: CfgRefDoc. At a deeper level, the NCrystal C++, C and Python APIs are now able to automatically generate documentation either in text format, JSON format, or (for Python only) as a Python collection. The wiki page at CfgRefDoc will from now on be automatically regenerated at the time of each new NCrystal release, based on this underlying information.
Without the wiki page (or if the installed NCrystal release differs from the latest release), users can run ncrystal_inspectfile --doc for a brief overview of available parameters or ncrystal_inspectfile --doc --doc for a full explanation of all the parameters. From Python the relevant function to call is NCrystal.generateCfgStrDoc, and in C++ the relevant function is NCrystal::MatCfg::genDoc.
As already mentioned above, a new cfg-parameter, sans is introduced which is as the name implies meant as a way to disable (or re-enable) any SANS physics of a material (just as e.g. coh_elas already does for single-phase coherent-elastic physics). With the new sans parameter, it is now possible for people developing external SANS plugins to have a clear way to disable or enable their contribution.
Perhaps more importantly for most users, the release also introduces a new pseudo-parameter called comp, which can be used to easily select only certain listed components for plotting. Components are listed as a comma separated list, and recognised component names are: "elas", "incoh_elas", "coh_elas", "bragg", "inelas", and "sans". Thus, "...;comp=inelas" is guaranteed to disable anything except inelastic scattering, and "...;comp=inelas,incoh_elas" will disable everything except inelastic or incoherent-elastic (which currently is the same as disabling coherent-elastic and SANS components but that might change in the future). It is important to reiterate that the comp parameter is used to disable everything except the listed components, and crucially does not re-enable the listed components if they have already been disabled. Thus appending ";comp=bragg" to a cfg-string, will either result in just the Bragg physics (if Bragg physics was present in the cfg-string), or in a null-process with vanishing cross section everywhere (if Bragg physics was not present in the cfg-string). Note that cfg-strings are in general evaluated from left to right, and the comp pseudo-parameter is immediately replaced with a number of suitable real parameters. For instance, comp=bragg,inelas is currently expanded to incoh_elas=0,sans=0. Thus, appending ";comp=bragg;comp=inelas" to a cfg-string will always result in a null-process.
The comp parameter represents a marked improvement from the previous situation, where one would instead have to selectively disable all components except the desired components - which was of course not only error prone, but also impossible to maintain across NCrystal releases where new types of components became available. For people creating scripts wishing to loop through all possible components (perhaps to plot the cross sections from the separate components), the NCrystal Python interfaces now provides a simple list of strings, standard_comp_types for doing just that. It is currently defined as standard_comp_types=('coh_elas','incoh_elas','inelas','sans') but that may change in the future. Taken together, it is now simple to do:
import NCrystal as NC
cfgstr='...whatever...'
for cmp in NC.standard_comp_types;
sc = NC.createScatter(cfgstr+=f';comp={cmp}')
#Use 'sc' to do some plotting or whatever it is you want to doFinally, we recall that as previously noted the packfact parameter has been removed (see the discussion about the new density parameter in a previous section), as has the ignorefilecfg keyword. The latter was removed since it was used very rarely and was somewhat difficult to support in a consistent and sane manner along with the other new features of NCrystal v3.0.0.
Although it is supposed to be easy to either write cfg-strings or append parameters to them (e.g. appending ";temp=200K" will always work as intended), it is far from trivial to actually decode a cfg-string (for instance to extract a value from it). This is particularly complicated by the new support for multiphase cfg-strings ("phases<...>"), and the presence of the various pseudo-parameters whose effect is simply to modify other parameters. Although most users do not normally need to parse a cfg-string, NCrystal v3.0.0 now provides a more robust method to do so when actually needed. Firstly, the APIs now provide a way to "normalise" a given cfg-string. This can for instance be done with the ncrystal_inspectfile --cfg, or as here in the Python API (using the interactive Python prompt):
>>> import NCrystal as NC
>>> NC.normaliseCfg('void.ncmat;dcutoff=0.2; vdoslux = 2;dcutoff=1Aa;inelas=sterile')
'void.ncmat;dcutoff=1;inelas=0;vdoslux=2'To actually extract parameter values, one must use the decodeCfg function instead:
>>> import pprint
>>> pprint.pprint(NC.decodeCfg('void.ncmat;dcutoff=0.2; vdoslux = 2;dcutoff=1Aa;inelas=sterile'))
{'data_name': 'void.ncmat',
'density': {'type': 'scalefactor', 'value': 1.0},
'format': 'NCrystal-MatCfg-v1',
'ismultiphase': False,
'pars': [['dcutoff', 1.0], ['inelas', '0'], ['vdoslux', 2]],
'phasechoices': [],
'textdata_type': 'ncmat',
'textdata_uid': '1'}Admittedly the decodeCfg function is clearly intended for users (or NCrystal developers) with advanced scripting needs, but until now there was simply no proper sustainable way to dig into the cfg-strings in this manner.
The NCrystal v3.0.0 release brings several improvements concerning the "hkl lists", or lists of crystalline reflection planes, which are typically generated during initialisation based on unit cell information found in NCMAT data.
Firstly, when the crystalline NCMAT data contains information about the crystal @SPACEGROUP (which it does in 106 of the 108 crystalline materials in our Data-library), the hkl planes provided by NCrystal are now grouped according to the symmetry-equivalency indicated by the space group. This grouping is what most crystallographers would expect, and makes it easier to use hkl lists from NCrystal with other crystallographic software which often depends on such symmetry groupings. Additionally, the usage of such symmetries has the benefit of drastically improving both the initialisation time and memory usage needed for hkl lists. The speedup is an average initialisation time reduction of roughly 60% for crystals in the Data-library, but generally with much larger speedups for more complicated high-symmetry crystals (for instance the initialisation time for Y3Al5O12_sg230_YAG.ncmat was reduced from 2.2s to 0.2s). Finally, as a rather visible benefit, it is now possible always to see all the hkl indices in each group (e.g. when inspecting with ncrystal_inspectfile -dd, see further down).
Another and somewhat unrelated improvement solves a long-standing technical nuisance, namely that code like createScatter("mycrystal.ncmat;bragg=0") would waste time initialising hkl lists that were not actually used since Bragg diffraction had been disabled. That could happen since hkl lists were initialised as part of NCrystal Info objects, while the decision of which type of scattering physics to include was taken later when setting up NCrystal Scatter objects. In the past a workaround was added, namely that assigning a magic value of -1 to the dcutoff parameter would create an Info object with empty hkl lists. So code would be written like createScatter("mycrystal.ncmat;dcutoff=-1;bragg=0"). This workaround was non-obvious, annoying, and circumvented NCrystal's otherwise carefully planned caching strategies. The NCrystal v3.0.0 release remedies this situation, by having the Info objects use (thread-safe) on-demand loading of hkl lists. The dcutoff=-1 hack is therefore no longer meaningful, but to not break existing usage, dcutoff=-1 will for now simply be interpreted as dcutoff=0 (which is the default, leaving the choice of d-spacing cutoff value to NCrystal). As a side-benefit of the changes needed for this on-demand loading, it is now also possible to simply ask for e.g. the Bragg threshold, or to inspect the few planes with the longest d-spacing values, without triggering a full initialisation. The latter feature is utilised when dumping material Info, for instance via the -d or --dump option to the ncrystal_inspectfile script. The default is now to only show the 10 planes with longest d-spacing. Not only does that very nicely prevent cluttering the output screen with thousands of hkl groups, it also ensures that even the most complicated crystals can be inspected without noticeable waiting time:
$> ncrystal_inspectfile -d BaF2_sg225_BariumFluoride.ncmat
----------------------------------------------------------------------------------------------------
------------------------------------ NCrystal Material Info ------------------------------------
----------------------------------------------------------------------------------------------------
Data source: BaF2_sg225_BariumFluoride.ncmat
----------------------------------------------------------------------------------------------------
Density : 4.886 g/cm3, 0.0503483 atoms/Aa^3
----------------------------------------------------------------------------------------------------
Composition (by mole): 66.6667% F 33.3333% Ba
----------------------------------------------------------------------------------------------------
Composition (by mass): 21.6724% F 78.3276% Ba
----------------------------------------------------------------------------------------------------
Atom data:
F = F(cohSL=5.654fm cohXS=4.01718barn incXS=0.0008barn absXS=0.0096barn mass=18.9984u Z=9)
Ba = Ba(cohSL=5.07fm cohXS=3.23017barn incXS=0.15barn absXS=1.1barn mass=137.327u Z=56)
----------------------------------------------------------------------------------------------------
Averaged quantities:
Atomic mass : 58.4412u
Absorption XS at 2200m/s : 0.373067 barn
Free scattering XS : 3.52573 barn
Scattering length density : 2.74868 10^-6/Aa^2
----------------------------------------------------------------------------------------------------
Temperature : 293.15 kelvin
----------------------------------------------------------------------------------------------------
State of matter: Solid (crystalline)
----------------------------------------------------------------------------------------------------
Space group number : 225
Lattice spacings [Aa] : 6.2001 6.2001 6.2001
Lattice angles [deg] : 90 90 90
Unit cell volume [Aa^3] : 238.34
Atoms / unit cell : 12
----------------------------------------------------------------------------------------------------
Atoms in unit cell (total 12):
8 F atoms [T_Debye=434.943K, MSD=0.0125804Aa^2]
4 Ba atoms [T_Debye=194.559K, MSD=0.00830675Aa^2]
----------------------------------------------------------------------------------------------------
Atomic coordinates:
F 1/4 1/4 1/4
F 1/4 1/4 3/4
F 1/4 3/4 1/4
F 1/4 3/4 3/4
F 3/4 1/4 1/4
F 3/4 1/4 3/4
F 3/4 3/4 1/4
F 3/4 3/4 3/4
Ba 0 0 0
Ba 0 1/2 1/2
Ba 1/2 0 1/2
Ba 1/2 1/2 0
----------------------------------------------------------------------------------------------------
Dynamic info for F (66.6667%):
type: S(alpha,beta) [from VDOS]
VDOS Source: 4949 points
VDOS E_max: 43.0058 meV
Dynamic info for Ba (33.3333%):
type: S(alpha,beta) [from VDOS]
VDOS Source: 4949 points
VDOS E_max: 43.0058 meV
----------------------------------------------------------------------------------------------------
HKL info type: SymEqvGroup
----------------------------------------------------------------------------------------------------
HKL planes (d_lower = 0.1 Aa, d_upper = inf Aa):
H K L d_hkl[Aa] Mult. FSquared[barn]
1 1 1 3.57963 8 4.00886
2 0 0 3.10005 6 5.82801
2 2 0 2.19207 12 39.1294
3 1 1 1.8694 24 3.7444
2 2 2 1.78981 8 5.1031
4 0 0 1.55002 6 35.6797
3 3 1 1.4224 24 3.49738
4 2 0 1.38638 24 4.46401
4 2 2 1.26559 24 32.5385
5 1 1 1.19321 24 3.26666
(some planes left out for brevity, increase verbosity to show all)
----------------------------------------------------------------------------------------------------
For more details, one can specify --dump another time (or, more succinctly, -dd). In fact, a total of three levels exists:
-
ncrystal_inspectfile -d: Default (like above). Only shows first 10 hkl groups, loads ~instantaneously. -
ncrystal_inspectfile -dd: Shows roughly the 30 first and 10 last hkl groups. Also shows symmetry equivalent hkl indices within each group (possibly shortened). -
ncrystal_inspectfile -ddd: Shows all planes and all symmetry equivalent hkl indices.
The diligent reader might have noticed a new field, HKL info type: SymEqvGroup, being printed in the dump above. As might be guessed, this field indicates that indeed the hkl groupings are according to symmetry-equivalency. If loading a crystalline NCMAT file with no @SPACEGROUP section, that section would instead read ExplicitHKLs, and the groupings would have been done according to closeness of (d-spacing,fsquared) values, as in old NCrystal releases. For completeness it should be mentioned that for specialised use-cases, a third option (ExplicitNormals) exists, where planes are defined by their normals rather than hkl indices, but this will never happen when simply reading NCMAT data, and most users can safely ignore this.
The McStas package for neutron ray-tracing and simulation continues to be one of the most important platforms for NCrystal usage, and the NCrystal release v3.0.0 cements this further by improving not only the existing hooks, but also providing various tools for more NCrystal usage in the wider McStas ecosystem of components. The following sub-section will discuss the most important of these developments.
The new NCrystal release contains updates for the NCrystal_sample.comp component and the ncrystal_preparemcstasdir scripts, which makes them work with both the McStas v2.7.x and McStas v3.x branches. More specifically, the NCrystal_sample.comp component is now compatible with both branches except for a single line (the one with a NOACC statement) which must be removed to be backwards compatible with McStas 2.7.x. Therefore, when McStas 2.7.x is detected, the ncrystal_preparemcstasdir will create a modified local copy of NCrystal_sample.comp which has the offending NOACC statement removed.
NCrystal now provides a new command-line utility ncrystal_ncmat2hkl, which can be used to convert NCMAT files to the .laz and .lau files needed by the McStas PowderN and Single_crystal components. More specifically, the input is a cfg-string, so in particular it might be desired to modify the material temperature and (to keep output file sizes down) the lower d-spacing cutoff via the temp and dcutoff parameters respectively.
Example usage, producing a .lau file:
ncrystal_ncmat2hkl 'Al4C3_sg166_AluminiumCarbide.ncmat;temp=600K' --format=lau -o alucarbide_600K.lau
The resulting alucarbide_600K.lau file contains the comments found in the original input file for reference, and can be used in the McStas Single_crystal component (or in the PowderN component, or by NCrystal itself).
For Python users, it might be interesting to note that the functionality of the ncrystal_ncmat2hkl command is also available as the Python function cfgstr_2_hkl in the NCrystal.mcstasutils module.
Finally, it is important to keep in mind that the exported information only includes realistic information about Bragg diffraction, not inelastic/incoherent/SANS/multiphase physics for which direct NCrystal usage in the NCrystal_sample component or McStas-Union system is needed (with the original cfg-string).
alucarbide_600K.lau:
# File created by NCrystal v2.9.92
#
# ncrystal_cfgstr "Al4C3_sg166_AluminiumCarbide.ncmat;temp=600"
#
# Format: "lau" (suitable for McStas Single_crystal component)
#
# orighdr : Original file had the following comments at the top:
# orighdr :
# orighdr : #
# orighdr : # Aluminium carbide (Al4C3, trigonal, SG-166 / R-3m)
# orighdr : #
# orighdr : # Under usual conditions this phase exists from 0 to 2470K.
# orighdr : #
# orighdr : # Structure converted with ncrystal_onlinedb2ncmat from:
# orighdr : #
# orighdr : # "Die Struktur des Aluminiumcarbids"
# orighdr : # von Stackelberg, M. and Schnorrenberg, E. (1934)
# orighdr : # Crystallography Open Database entry 1540874
# orighdr : # https://www.crystallography.net/cod/1540874.html
# orighdr : #
# orighdr : # This crystal structure is also compatible with structure obtained from
# orighdr : # https://www.materialsproject.org/materials/mp-1591
# orighdr : #
# orighdr : # The VDOS curves were calculated using Phonopy[1] input files from[2] and
# orighdr : # OCLIMAX[3] software by Kemal Ramic from ESS Spallation Physics group.
# orighdr : #
# orighdr : # References:
# orighdr : # [1]: "First principles phonon calculations in materials science",
# orighdr : # Atsushi Togo and Isao Tanaka, Scr. Mater., 108, 1-5 (2015)
# orighdr : # [2]: Kyoto University database of phonon calculations.
# orighdr : # Files for Al4C3 taken from:
# orighdr : # http://phonondb.mtl.kyoto-u.ac.jp/ph20180417/d001/mp-1591.html
# orighdr : # [3]: Cheng, Y. Q.; Kolesnikov, A. I.; Ramirez-Cuesta, A. J., "Calculation
# orighdr : # of the Thermal Neutron Scattering Cross-Section of Solids Using OCLIMAX".
# orighdr : # Journal of Chemical Theory and Computation 2020, 16 (8), 5212-5217.
# orighdr : #
#
#
# ncrystal_embedded_cfg : NCRYSTALMATCFG[temp=600]
#
# temperature 600 [kelvin]
#
# spacegroup 166
# lattice_a 3.329 [Aa]
# lattice_b 3.329 [Aa]
# lattice_c 24.98 [Aa]
# lattice_aa 90 [degrees]
# lattice_bb 90 [degrees]
# lattice_cc 120 [degrees]
# Vc 239.745605876799 [Aa^3]
#
# multiplicity 21 [atoms/unit cell]
# density 2.99129543252217 [g/cm^3]
# number_density 0.087592846272192 [atoms/Aa^3]
# weight 431.877793024686 [g/mol of entire unit cell]
# average_mass 20.5656091916517 [average atomic g/mol]
#
# sigma_coh 67.892463219072 [barn/unitcell]
# sigma_inc 0.1074 [barn/unitcell]
# sigma_abs 2.8035 [barn/unitcell]
#
# formula Al4C3
# nformula_per_unitcell 3
# debye_temperature 861.628311504101 [kelvin, weighted by sigma_b]
#
# column_h 1
# column_k 2
# column_l 3
# column_j 4 multiplicity
# column_d 5 [d-spacing in Aa]
# column_F2 6 [norm of scattering factor |F|^2 in barn]
# unit_F2 barn
#
# h k l j d F2
0 0 3 1 8.32666666666667 0.139039769083006
0 0 -3 1 8.32666666666667 0.139039769083006
0 0 6 1 4.16333333333333 1.08364215950187
0 0 -6 1 4.16333333333333 1.08364215950187
1 0 1 1 2.86398752015947 13.1111091224499
-1 0 -1 1 2.86398752015947 13.1111091224499
1 -1 -1 1 2.86398752015947 13.1111091224499
-1 1 1 1 2.86398752015947 13.1111091224499
...
... (~80.000 additional lines not shown)
...
In addition to making new tools for producing .laz/.lau files available, the builtin functionality for loading materials based on such files into NCrystal has also been improved with the relevant code completely rewritten. The code is now much more robust, and will now detect and reject a wider range of inconsistencies found in the files. Specifically, some cases of inconsistencies between the listed hkl entries and the declared crystal space group are now detected. Additionally, it is possible to detect and correctly account for different conventions for specifying the multiplicities of the hkl groups, which was in the past leading occasionally leading to incorrectly loaded data. Finally, all Info objects in NCrystal are now required to have both density and atomic composition information, so unlike in the past .laz/.lau files can now also be used when performing simulations in e.g. Geant4.
However, these new features require at least 3 new fields to be added to the .laz/.lau header, in order for NCrystal to be able to reliable deduce the spacegroup number and the atomic composition of the material. For instance, corundum (alpha-alumina) has spacegroup number 167 and (for the standard unit cell with a=4.757Å and c=12.9877Å), 12 Al atoms and 18 O atoms, or 6x(Al2O3), so one must add:
# spacegroup 167
# formula Al2O3
# nformula_per_unitcell 6
Additionally, three new optional fields are supported. The first and likely most important is a temperature field. Since hkl structure factor calculations are temperature dependent, it is best to specify this temperature in the file:
# temperature 190.0 [kelvin]
Next, if the units of structure factors in the file are fm^2 (or fm) rather than the default barn (or sqrt(barn)), this must be indicated by adding a line:
# unit_F2 fm^2
Finally, NCrystal will by default model inelastic and incoherent-elastic scattering of the loaded material based on a Debye model VDOS with a Debye temperature of 300K. To modify this value, one can use the following optional field:
# debye_temperature 950.0 [kelvin]
Although it has been possible to use NCrystal to provide physics processes when using the McStas-Union system for simulation of neutrons in complex geometries, the configuration of such processes was not always completely trivial for casual users. To remedy this situation, new utilities are provided which can automatically set up Union physics processes based simply on an NCrystal cfg-string. These new utilities are provided as Python functions in the new NCrystal.mcstasutils python module. Users running McStas via the Python interface provided by McStasScripts might be interested to know that it is planned to integrate these utilities directly in McStasScripts in the near future. But for now, and for McStas users not using McStasScripts, the new Python module can be used to conveniently generate code which can be directly inserted in McStas instrument files. The Python module can also be used from the command-line via the -m flag to Python. Example usage for generating code which assigns the material with NCrystal cfg-string "Al_sg225.ncmat;temp=250K" to the union material named my_Al is:
$> python3 -mNCrystal.mcstasutils --union my_Al 'Al_sg225.ncmat;temp=250K'/*
The following code was auto generated by NCrystal v3.0.0 via Python:
NCrystal.mcstasutils.cfgstr_2_union_instrument_code(
cfgstr = 'Al_sg225.ncmat;temp=250K',
name = 'my_Al' )
Please rerun in case of major changes to input data or NCrystal.
*/
COMPONENT my_Al_ncrystal_proc = NCrystal_process(
cfg = "Al_sg225.ncmat;temp=250" )
AT (0,0,0) ABSOLUTE
COMPONENT my_Al = Union_make_material(
process_string = "my_Al_ncrystal_proc",
my_absorption = 1.39136803716641 )
AT (0,0,0) ABSOLUTE
/* End of auto generated code from NCrystal v3.0.0. */If not for the absorption value of 1.39136803716641, this would not have been too difficult to write by hand. However, for some studies it might be beneficial to split up the various physics process types (Bragg/incoh-elas/inelas/...) at the level of the Union system, as opposed to just keeping the split-up internally in NCrystal. To do so, simply add the --split flag to the command:
$> python3 -mNCrystal.mcstasutils --union my_Al 'Al_sg225.ncmat;temp=250K' --split/*
The following code was auto generated by NCrystal v3.0.0 via Python:
NCrystal.mcstasutils.cfgstr_2_union_instrument_code(
cfgstr = 'Al_sg225.ncmat;temp=250K',
name = 'my_Al',
split_by_physics = True )
Please rerun in case of major changes to input data or NCrystal.
*/
COMPONENT my_Al_ncrystal_cohelas_proc = NCrystal_process(
cfg = "Al_sg225.ncmat;incoh_elas=0;inelas=0;sans=0;temp=250" )
AT (0,0,0) ABSOLUTE
COMPONENT my_Al_ncrystal_incohelas_proc = NCrystal_process(
cfg = "Al_sg225.ncmat;coh_elas=0;inelas=0;sans=0;temp=250" )
AT (0,0,0) ABSOLUTE
COMPONENT my_Al_ncrystal_inelas_proc = NCrystal_process(
cfg = "Al_sg225.ncmat;coh_elas=0;incoh_elas=0;sans=0;temp=250" )
AT (0,0,0) ABSOLUTE
COMPONENT my_Al = Union_make_material(
process_string = "my_Al_ncrystal_cohelas_proc,my_Al_ncrystal_incohelas_proc,my_Al_ncrystal_inelas_proc",
my_absorption = 1.39136803716641 )
AT (0,0,0) ABSOLUTE
/* End of auto generated code from NCrystal v3.0.0. */As it is believed that the the legacy file .nxs file format associated with nxslib at the same time brings license complications and also has very little users in NCrystal, it was decided to remove the support for loading this file format from the main NCrystal release. The benefit of this is that this removes the few optional files which were not copyrighted by the NCrystal developers, ensuring that the entire NCrystal release now has a single well-defined license, namely the Apache 2.0 license.
For anyone actually still needing to load .nxs files with NCrystal, the functionality has now been moved to an external plugin, residing in a separate repository. To enable it, one can for instance set the following CMake flag when configuring NCrystal:
-DBUILTIN_PLUGIN_LIST=mctools:nxslib
For other ways of enabling the plugin, refer to the Plugins page.
- All materials are now guaranteed to have information about composition and (non-zero) density, and if crystalline it will always provide a list of hkl planes. Having these fundamental requirements assured eliminates the need for input checking in several scenarios, thus making NCrystal usage easier in several contexts.
- Added new void.ncmat material, which as the name implies provides a material suitable for voids. An empty material might be handy for debugging purposes, or defining vacuum phases in a material (perhaps for the purposes of SANS contrast physics). At the technical level, this void material is actually defined as a special ultra low density material with sterile non-interacting hydrogen atoms. In NCrystal this results in exactly vanishing cross sections everywhere, and the ultra low density value ensures the material also works if translated to Geant4/OpenMC/...
- Remove disableCaching()/enableCaching() functions from the APIs. These functions are hard to maintain, with potentially confusion side-effects, and are no longer deemed essential since our caching is much better now and less likely to cause issues. Users can still call the clearCaches() function to manually trigger a cache clearance.
- The NCrystal Python module and command-line tools now require Python 3.6. Python 3.5 is no longer supported.
- Various interfaces were cleaned up and improved somewhat as part of the major version number increase. Of particular interest for plugin developers is the fact that (as an example) a
Scatterplugin no longer must respond to keys of typeMatCfg(which is the parsed C++ version of the entire cfg-string), but instead of typeScatterRequest. The difference is that theScatterRequestobject provides anInfoobject already, and only provides access to the cfg-parameters related to scattering (i.e. it will see thecoh_elasparameter, but not thetempparameter since the temperature should be taken from theInfoobject instead). This changes prevents a few cases of non-obvious logic errors, and as a benefit improves loading performance. -
ncrystal_inspectfilegets a few new convenience flags for controlling cross section plots:-
--energy: Show cross section plots as a function of energy rather than wavelength! -
--liny: Force linear y-axis (it defaults as logarithmic with--energy) -
--logy: Force logarithmic y-axis (it defaults as linear without--energy) -
--xrange: Specify exact range (energy or wavelength) to use in the plot.
-
- Two new flags of
ncrystal_inspectfilewere already discussed in more details in separate sections above:-
--phases: Breakdown cross sections by phase. -
--doc: Get documentation of cfg-string parameters.
-
- The new
--cfgflag ofncrystal_inspectfileshows the normalised version of a cfg-string and provides an overview of the actual C++ physics algorithms that are ultimately loaded (these are of course an implementation detail, but might nonetheless be interesting to see). Examples:$> ncrystal_inspectfile --cfg 'Al_sg225.ncmat;temp=200' ==> Debugging cfg-string: "Al_sg225.ncmat;temp=200" ==> Normalised cfg-string : "Al_sg225.ncmat;temp=200" ==> Absorption process (code level objects): AbsOOV(sigma_2200=0.231barn) ==> Scattering process (code level objects): ProcComposition(3 components, isotropic) |-- ElIncScatter(nelements=1;max_contrib=0.0082barn) |-- PCBragg(nplanes=239;2dmax=4.67605Aa;max_contrib=1.71094barn) \-- SABScatter(nalpha=400;nbeta=800;Emax=5eV;T=200K;M=26.9815u;sigma_free=1.39667barn)$> ncrystal_inspectfile --cfg 'Al_sg225.ncmat;temp=200;inelas=freegas;dcutoff=0.5' ==> Debugging cfg-string: "Al_sg225.ncmat;temp=200;inelas=freegas;dcutoff=0.5" ==> Normalised cfg-string : "Al_sg225.ncmat;dcutoff=0.5;inelas=freegas;temp=200" ==> Absorption process (code level objects): AbsOOV(sigma_2200=0.231barn) ==> Scattering process (code level objects): ProcComposition(3 components, isotropic) |-- ElIncScatter(nelements=1;max_contrib=0.0082barn) |-- PCBragg(nplanes=22;2dmax=4.67605Aa;max_contrib=1.71094barn) \-- FreeGas(sigma_free=1.39667barn;T=200K;M=26.9815u)$> ncrystal_inspectfile --cfg LiquidHeavyWaterD2O_T293.6K.ncmat ==> Debugging cfg-string: "LiquidHeavyWaterD2O_T293.6K.ncmat" ==> Normalised cfg-string : "LiquidHeavyWaterD2O_T293.6K.ncmat" ==> Absorption process (code level objects): AbsOOV(sigma_2200=0.000409333barn) ==> Scattering process (code level objects): ProcComposition(2 components, isotropic) |-- 0.666667 * SABScatter(nalpha=396;nbeta=791;Emax=3.7eV;T=293.6K;M=2.0141u;sigma_free=3.39296barn) \-- 0.333333 * SABScatter(nalpha=396;nbeta=791;Emax=10eV;T=293.6K;M=15.9993u;sigma_free=3.74537barn)