mctools / ncrystal Goto Github PK

As pointed out during a seminar today, there is really no need to spend a huge amount of CPU time in single crystal models at very high neutron energies. We should consider a generic cutoff value (e.g. lambda<0.01Aa) beyond which scattering would either have 0 cross section, use a power cross section, or something else (i.e. scaling xs as lambda^2 and using isotropic scatterings?).

Perhaps the cutoff should be dynamic...? Or related to the values of dcutoff/sccutoff?

Perhaps 0.01Aa unless pushed further down by low dcutoff/sccutoff values? I.e. 0.01 but at most half of min(dcutoff/sccutoff)?

Before our official 1.0.0 release and associated publication, etc., I think this is a good time to make any changes to things like parameter names, for a more stable user experience later.

For instance, orientationprimary, orientationsecondary and orientationtolerance are all rather long, and make for some ghastly long configuration strings. Users will anyway need to consult documentation or examples before they can figure out how to use those parameters, so I will change these three to dir1, dir2 and dirtol respectively. Based on feedback from an early adopter, I will also revisit the default value of the tolerance.

We should do this in any case, but this is immediately important since mcstas uses python3 (to my understanding).

It would be good to be able to make NCrystal::scatter for a multi-phase materials.

An example are Al-Mg alloys typically used to make neutron detectors:
According to J. Mater. Res., 18 2003 p.1827:

The mechanical alloys consisted of a supersaturated solid solution of Mg in the� alpha aluminum phase, gamma phase (Al12Mg17), and additional amorphous material

Regards,
Andrey

When redoing our Geant4 integration after NCrystal release 2.0, we should also make sure to properly support Geant4 parallel geometries. I paste here a report from Thulliez Loïc with some details:

 it seems that NCrystal is not properly taken into account in geant4 parallel world:
In the mass geometry NCrystal works perfectly but as soon as, before shooting neutrons (/run/beamOn XX), I ask geant4 to create neutron maps (so a parallel world) as follow:

/score/create/boxMesh mapNeutron_cellFlux_thermal_max_50meV
/score/mesh/boxSize 625.000000 625.000000 685.000000 mm
/score/mesh/nBin 125 125 137
/score/quantity/cellFlux cellFlux
/score/filter/particleWithKineticEnergy enrj 0. 5E-6 MeV neutron
/score/close

and then I call:
/run/beamOn XX

I have the following error:
-----------------------------------------------------------------------------------------
G4ProcessManager::GetAttribute(): particle[neutron]
  index out of range
  #processes[8]  index [-1]

 *** Break *** segmentation violation
-----------------------------------------------------------------------------------------

From http://www.sixiangguo.net/code/geant4/AppDevelop/ch04s07.html#sect.ParaGeom.SenstivParaWrld, it seems that it happens because the ParallelWorld physics list seems not to be updated with the NCrystal cross-section.
At the moment to avoid this problem, I just not use parallel world along with NCrystal.

From my understanding, this behaviour is understandable. However since the physics list in the mass world id just updated in calling G4crystall::Install()

void mcdis_rectangle(char* plane, double x, double y, double z,
		     double width, double height){
  /* draws a rectangle in the plane           */
  /* x is ALWAYS width and y is ALWAYS height */

the linked line should be replaced with
mcdis_rectangle("yz", 0., 0., 0., geoparams.dz, geoparams.dy);`
to get the projections of a box.

Or the whole NC_BOX case could be solved with one line:
mcdis_box(0., 0., 0., geoparams.dx, geoparams.dy, geoparams.dz);
It looks better in my opinion but there might be a reason why it wasn't used in the first place.

matplotlib v2 seems to change the default style quite a bit. Grids and legends at the very least have changed, so we should revisit how to deal with this (possibly it is as simple as enabling "classic style" or something like that.

Very soon the big NCrystal v2.0 release will be out, with new capabilities for inelastic physics. It will contain many materials with phonon-dos or scattering kernels, but due to time limitations there will be more work to do on the data library after the release (but I don't want to delay the release further at this point).

• Only ~half of the materials in both the old NCrystal data library have now has phonon-dos data added to them. This process should be continued.
• More materials from ENDF/B-VIII can be converted (or have VDOS extracted) + have their crystal structures added (polymers need special attention due to multi-phase nature). This includes Polyethylene, Plexiglass, UN, UO2, SiC, ICE, YH2, ZrH.

Opening this issue so we don't forget.

To facilitate downstream development, we should make sure that NCrystal installations come with proper cmake module files.

Hello everyone,

I’m trying to install the latest Ncrystal build downloaded from github (as of June 18 2020), but I am experiencing issues with the Cmake installation.

After following the installation guide I’m getting the errors you can see in the attached pictures (of cmake and visual studio versions).

And this log:

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:

The output was:
1
Microsoft (R) Build Engine version 16.5.1+4616136f8 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 6/18/2020 2:11:59 PM.
Project "C:\Users\busi_m\Workspace\ncrystal\build2\CMakeFiles\3.16.6\CompilerIdC\CompilerIdC.vcxproj" on node 1 (default targets).
PrepareForBuild:
Creating directory "Debug".
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(449,5): warning MSB8003: The WindowsSDKDir property is not defined. Some build tools may not be found. [C:\Users\busi_m\Workspace\ncrystal\build2\CMakeFiles\3.16.6\CompilerIdC\CompilerIdC.vcxproj]
Creating directory "Debug\CompilerIdC.tlog".
InitializeBuildStatus:
Creating "Debug\CompilerIdC.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
ClCompile:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\HostX64\x64\CL.exe /c /nologo /W0 /WX- /diagnostics:column /Od /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"Debug\" /Fd"Debug\vc142.pdb" /Gd /TC /FC /errorReport:queue CMakeCCompilerId.c
CMakeCCompilerId.c
Link:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:".\CompilerIdC.exe" /INCREMENTAL:NO /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /PDB:".\CompilerIdC.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X64 Debug\CMakeCCompilerId.obj
LINK : fatal error LNK1181: cannot open input file 'kernel32.lib' [C:\Users\busi_m\Workspace\ncrystal\build2\CMakeFiles\3.16.6\CompilerIdC\CompilerIdC.vcxproj]
Done Building Project "C:\Users\busi_m\Workspace\ncrystal\build2\CMakeFiles\3.16.6\CompilerIdC\CompilerIdC.vcxproj" (default targets) -- FAILED.

Build FAILED.

"C:\Users\busi_m\Workspace\ncrystal\build2\CMakeFiles\3.16.6\CompilerIdC\CompilerIdC.vcxproj" (default target) (1) ->
(PrepareForBuild target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(449,5): warning MSB8003: The WindowsSDKDir property is not defined. Some build tools may not be found. [C:\Users\busi_m\Workspace\ncrystal\build2\CMakeFiles\3.16.6\CompilerIdC\CompilerIdC.vcxproj]

"C:\Users\busi_m\Workspace\ncrystal\build2\CMakeFiles\3.16.6\CompilerIdC\CompilerIdC.vcxproj" (default target) (1) ->
(Link target) ->
LINK : fatal error LNK1181: cannot open input file 'kernel32.lib' [C:\Users\busi_m\Workspace\ncrystal\build2\CMakeFiles\3.16.6\CompilerIdC\CompilerIdC.vcxproj]

It would be good to split out the fillHKL code which currently resides in the .ncmat loader and put in some (public even?) utility class. Not only would that remove physics modelling code from the .ncmat loader where it does not really belong, but it would be easy to add support for new formats similar but not identical to .ncmat files, since it just use basic unit cell information to create all hkl information. It might even be possible to work without files at all, but get lattice parameters etc. directly from a GUI, a Geant4 crystal database, specified in a python script, etc.

Python interface should allow access to expanded hkl lists.

As an example of why: Figure 9 in the upcoming paper was created with python, but needed some annoying workarounds due to this missing feature.

If it is not against the philosophy of the library, could you add another way of creating MatCfg:

Instead of the file name, it would be great to be able to provide the reference to the string with the file content (const std::string&). In this way the file can be completely avoided which is convenient in some cases.

Regards,
Andrey

As experienced in ESS/dgcode simulations (thanks to Gábor Galgóczi), the code loading hkl lists from .ncmat files will produce FPE's when loading files containing elements with negative coherent scattering lengths - thus only affecting files with H, Li, Ti, V or Mn.

In NCNCMatLoader.cc, this negative csl value is passed to a logarithm call:

  for (size_t i = 0; i<csl.size(); ++i)
    whkl_thresholds.push_back(log(csl.at(i) / 1e-5 ) );

which according to the C++ standards require the log function to:

• If the argument is negative, NaN is returned and FE_INVALID is raised.

The result is thus always that a value in whk_thresholds is NaN, and fortunately we only use it in one location further down the file, in order to skip some calculations that will anyway only give negligible contributions:

        for(unsigned i=0;i<whkl.size();i++)
          {
            if ( whkl[i] > whkl_thresholds[i])
              continue;//This is the same as calculating the factor and                                                                               
         ...

Since comparisons involving NaN always evaluate as false, the net effect is thus that this skipping will not have taken place, meaning that initialisation of those materials will have been slightly slower (and of course with tiny negligible differences in last decimals of output values).

This bug is therefore not understood to have affected results in any significant manner, the most important effect thus being the triggering of an undesired FPE - which is always something to avoid unless we want to alienate our users :-)

I plan to release NCrystal v0.9.7 within a few days time with a fix for this.

Somewhat related to but also orthogonal to issue #19, we should make it possible to create crystals which does not simply consist of fixed natural elements sitting at the various atomic positions. This comes up again and again, in different contexts from different users.

So essentially we need users to be able to define their own "element mixtures", either by mixing natural elements together or by mixing isotopes together. In the case of isotopes, the input data would also have to contain data like scattering-lengths etc., since NCrystal internally only keeps a database of natural elements. Or perhaps we would simply ask for the resulting scattering lengths etc. directly (but that would not work well for the code having to create G4Materials from it).

So one solution that comes to mind would be to support this only in .ncmat files, and to do it by allowing custom elements "X1", "X2", "X3", in the specification of the "atoms" sitting in the grid. If any such "Xi" was used, they would have to be defined in the file in a new section:

@CUSTOMELEMENTINFO
   X1 = 0.1 Al + 0.9 Mg
   X2 = 90% B10 + 10%B11
 B10 =  <some Boron-10 data here>
 B11 =  <some Boron-11 data here>

Quite some code refactoring would be needed for this, since a lot of code now use atom numbers and query the resulting scattering lengths etc. data directly. This would then have to be done only by the info factories, which would put the resulting data on the info objects themselves.

By allowing total weights to be less than one, this would probably also allow us to model site-occupancy-factors less than 1. And the custom specification of scattering lengths etc., would make it possible to use NCrystal to investigate the effects of varying these fundamental parameters.

We recently added three new materials, and it seems that four materials were missing from the data library page by mistake. Thus, the following materials needs to be included:

• Ca_sg229_Calcium-gamma.ncmat
• C_sg227_Diamond.ncmat
• Fe_sg229_Iron-beta.ncmat
• MgO_sg225_Periclase.ncmat
• CaCO3_sg62_Aragonite.ncmat
• UO2_sg225_Uraninite.ncmat
• SiLu2O5_sg15.ncmat

We should also add a unit test making sure we have the internal .ncmat.extra files in place for the automatic generation.

Could you make NCrystal::Scatter multithread-friendly?

At least for these two methods:

crossSectionNonOriented()
generateScatteringNonOriented()

They are defined as const, can make someone think they are already safe.

Regards,
Andrey

One problem when wanting to develop new experimental models for NCrystal is that these models often require new input data, not supported in current versions. Thus, in practice, people usually have to hack in temporary support for new sections in ncmat files (cf. NCMAT-format. However, it would be nice if downstream projects could add in such files without any such hacks (people will then simply have to create their own scatter factories where they will enable their models -- however we should probably also expose the standard scatter factory as a direct global function, to facilitate such custom scatter factories).

So a solution would be if the NCMAT format would support custom sections. Apart from stripping away comments and performing white-space normalisation, the data in those custom sections would not be parsed by the core NCrystal code. Instead, it would simply make its way onto the NCInfo objects themselves.

All custom sections would begin with the string "CUSTOM_", and NCrystal would by default emit warnings whenever loading files with such custom sections (can be silenced from code or env vars). So if for instance a developer is working on a new experimental SANS model, it might require a new section like:

@CUSTOM_SANSDATA
    #Just some dummy parameters for now:
   sphere  100.0 #units are Aa
   nlookuptable 10000

This data would then end up on the NCrystal::Info objects, in some sort of data structure like the following (here written as python-objects for clarity, but would likely be stored in e.g. std::vectors and std::pair's instead of pythons lists and tuples:

   [ ("SANSDATA" : [ ["sphere","100.0"],["nlookuptable","10000"]])]

The exact interface on NCrystal::Info in C++ or Python would have to be defined of course, but the main point is that new custom scatter factories would be able to access this data, and create the custom scatter models with it.

When/if a model matures sufficiently and is of general interest, the NCMAT format should eventually be updated to support these formats directly, as non-CUSTOM entries, and the whole chain from ncmat-parser to Info objects to standard scattering factories, should then be updated to treat them properly.

Bonus idea: Another way to facilitate development might be to allow for the inclusions of entire files, essentially by supporting something like #include from C/C++ or \input from LaTeX. This might look like:

@INCLUDE my_other_data.txt

which would be inserted verbatim in the file (the search path would be the same as in NCFile.hh, although it can also be a path relative to the path where the parent data file resides.

Obviously, the official NCrystal data library should never use either @include or @CUSTOM_xxx sections!

We should in any case re-generate the data-library page before NC 1.0.0, but after NC 0.9.8 the parameters shown in some of the titles are no longer using the correct names. It can wait a few weeks though, in case we decide to change something else.

It is becoming a bit too cumbersome to have to keep supporting Python2, and the potential user-base stuck with Python2 is hopefully diminishing.

We should:

• Change /usr/bin/env python to refer to python3 instead.
• Remove python2 unit tests in ESS dgcode and on github travis CI.
• Make a decision regarding what python3 version to support. 3.5 or 3.6?
• Update NCrystal CMake to not look for python2 where relevant.

To see which data files are available to the given installation

Given that I don't intend to support NXSG4 forever, it would be good if the NXSG4 website refers people to NCrystal already now. Should be quick to do when I have a minute.

The NCystal material in the Geant4 example is not oriented and it took me some time to figure out how to do it.

I've tried to do something like this:
addParameterString("material_sample_ncrystal","NCrystal:cfg=C_sg194_pyrolytic_graphite.ncmat;dir1=@crys_hkl:0,0,2@lab:0,0,-1;dir2=@crys_hkl:0,2,0@lab:0,1,0;mos=60arcmin");
and later:
getParameterMaterial("material_sample_ncrystal");
but the NamedMaterialProvider::MatInfo::MatInfo(const std::string& ss) function doesn't like the colons in the definition of the directions and it gives the following error:

G4Launcher:: NamedMaterial ERROR in material "NCrystal:cfg=C_sg194_pyrolytic_graphite.ncmat;mos=60arcmin;dir1=@crys_hkl:0,0,2@lab:0,0,-1;dir2=@crys_hkl:0,2,0@lab:0,1,0": syntax error in parameter definition

Thanks to a helpful comment in the MatInfo function I was able to solve it by writing square bracket
around the value of the cgf parameter:
addParameterString("material_sample_ncrystal","NCrystal:cfg=[C_sg194_pyrolytic_graphite.ncmat;dir1=@crys_hkl:0,0,2@lab:0,0,-1;dir2=@crys_hkl:0,2,0@lab:0,1,0;mos=60arcmin]");

If this solution is indicated somewhere in NCrystal's documentation and I've missed it than I deserved to struggle with it, otherwise it should be indicated somewhere. :)

We could consider accepting a "grain size" parameter and implement peak broadening due to small grain size via Scherrers formula:

https://en.wikipedia.org/wiki/Scherrer_equation

Currently the 39 crystals in the data library are divided among crystal systems as follows:

     27 Cubic
      8 Hexagonal
      1 Tetragonal
      3 Trigonal

It would be good to have at least one Triclinic, Monoclinic and Orthorombic crystal as well, to make sure we validate and use all code paths (and to showcase our ability to deal with such complex crystals as well).

Rather than just 2x2x2=8 builds (osx/linux, dbg/rel, clang/gcc), we could get more sensible and broader coverage of a suitable build matrix. This would also avoid travis-ci/travis-ci#5125.

There is really no good reason that downstream code should be disallowed to use our internal utilities (e.g. NCMath.hh, NCVector.hh, etc.). Of course without any guarantees of a stable API. For instance, the Geant4 plugin might as well be allowed to use all internal header files, as it is anyway developed in the same project, and it might also be useful when we want to migrate the unit tests of internal code to be able to build directly on top of a standard NCrystal build.

Perhaps we could expose the internal header files in NCrystal/internal/..., i.e.:

#include "NCrystal/NCrystal.hh"
#include "NCrystal/private/NCMath.hh"

A single NCRYSTAL_DATADIR variable is unflexible, especially if someone will develop their own plugin.

Currently the NCMatCfg packingfactor parameter is only used in one place, and that is in G4NCrystal, where the density found on NCInfo is multiplied with this packingfactor from the NCMatCfg. The density on NCInfo is taken from the files in the case of .nxs/.laz/.lau and calculated based on structure etc. for .ncmat.

The McStas sample component neither looks at the density, nor the packing factor, but simply use the volume and natoms/cell from StructureInfo to arrive at a factor which can be used with a given cross-section in barn when generating step-lengths.

I get the following error message when I try to run a McStas simulation with an NCrystal_sample component in the instrument file:

ld: unknown option: --rpath=NCrystalLink/lib
collect2: error: ld returned 1 exit status

I've installed NCrystal 0.9.2 using the Source code (tar.gz) without any trouble, following the instructions in the INSTALL file (cmake, make install, setup.sh). It passes the test ("Tests completed succesfully"), and I can visualize data using the command-line. The problem comes when I want to use it with McStas.
I've made the links using the ncrystal_preparemcstasdir command in the folder where I'm calling mcstas, and after that I can even compile an instrument file using the mcstas command without any error. I get the error only when I launch a simulation with the mcrun or mcdisplay-webgl commands.
I get the same result with NCrystal 0.9.1 too.

Other environment info:
macOS High Sierra (Version 10.13)
McStas version 2.4.1 (Jun. 26, 2017)
cmake version 3.9.4
gcc (GCC) 6.0.0 20151213 (experimental)

The full text that I get:

[milanklausz@CI0011996 BIFROST]$ mcrun Primary_Instrument_ChopsAndJaws_withTarget.instr -c -n100
loading user configuration from /Users/milanklausz/.mcstas/2.4.1/mccode_config.json
INFO: No output directory specified (--dir)
INFO: Using directory: "Primary_Instrument_ChopsAndJaws_withTarget_20180130_120944"
INFO: Recompiling: ./Primary_Instrument_ChopsAndJaws_withTarget.out
INFO: Regenerating c-file: Primary_Instrument_ChopsAndJaws_withTarget.c
Info:    'Elliptic_guide_gravity' is a contributed component.
CFLAGS= -Wl,--rpath=NCrystalLink/lib -LNCrystalLink/lib -lNCrystal -INCrystalLink/include
NCrystal_sample.comp: In function ‘mcraytrace’:
NCrystal_sample.comp:229:5: warning: passing argument 3 of ‘ncrystal_crosssection’ from incompatible pointer type [enabled by default]
     ncrystal_crosssection(params.proc_scat,ekin,&dir,&xsect_scat);
     ^
In file included from NCrystal_sample.comp:71:0:
NCrystalLink/include/NCrystal/ncrystal.h:102:8: note: expected ‘const double (*)[3]’ but argument is of type ‘double (*)[3]’
   void ncrystal_crosssection( ncrystal_process_t,
        ^
NCrystal_sample.comp:269:7: warning: passing argument 3 of ‘ncrystal_genscatter’ from incompatible pointer type [enabled by default]
       ncrystal_genscatter( params.scat,ekin, &dir, &dirout, &delta_ekin);
       ^
In file included from NCrystal_sample.comp:71:0:
NCrystalLink/include/NCrystal/ncrystal.h:115:8: note: expected ‘const double (*)[3]’ but argument is of type ‘double (*)[3]’
   void ncrystal_genscatter( ncrystal_scatter_t,
        ^
NCrystal_sample.comp:295:9: warning: passing argument 3 of ‘ncrystal_crosssection’ from incompatible pointer type [enabled by default]
         ncrystal_crosssection(params.proc_scat,ekin,&dir,&xsect_scat);
         ^
In file included from NCrystal_sample.comp:71:0:
NCrystalLink/include/NCrystal/ncrystal.h:102:8: note: expected ‘const double (*)[3]’ but argument is of type ‘double (*)[3]’
   void ncrystal_crosssection( ncrystal_process_t,
        ^
./Primary_Instrument_ChopsAndJaws_withTarget.c:41113:6: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
 
      ^
./Primary_Instrument_ChopsAndJaws_withTarget.c: In function ‘mcinit’:
./Primary_Instrument_ChopsAndJaws_withTarget.c:18792:6: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
 
      ^
ld: unknown option: --rpath=NCrystalLink/lib
collect2: error: ld returned 1 exit status
Traceback (most recent call last):
  File "/Applications/McStas-2.4.1.app/Contents/Resources/mcstas/2.4.1/bin/../tools/Python/mcrun/mcrun.py", line 372, in <module>
    main()
  File "/Applications/McStas-2.4.1.app/Contents/Resources/mcstas/2.4.1/bin/../tools/Python/mcrun/mcrun.py", line 289, in main
    mcstas.prepare(options)
  File "/Applications/McStas-2.4.1.app/Contents/Resources/mcstas/2.4.1/tools/Python/mcrun/mccode.py", line 173, in prepare
    Process(options.cc).run(args)
  File "/Applications/McStas-2.4.1.app/Contents/Resources/mcstas/2.4.1/tools/Python/mcrun/mccode.py", line 80, in run
    raise ProcessException(self.executable, args, retval)
mccode.ProcessException: Got exit status 1 from "gcc -o ./Primary_Instrument_ChopsAndJaws_withTarget.out ./Primary_Instrument_ChopsAndJaws_withTarget.c -lm -UUSE_MPI -g -O2 -lm -headerpad_max_install_names  -Wl,--rpath=NCrystalLink/lib -LNCrystalLink/lib -lNCrystal -INCrystalLink/include"

We need a proper plugin system, which should improve upon the features introduced in NCrystal v2.1.0 to make it more straight-forward to have people developing new physics models for NCrystal. Thoughts:

• Assuming someone has written a new physics model, how can they then use it outside their self-contained example. How can they use it in McStas for instance?


• How can they easily share their work with other people wanting to try out their models. How do we allow multiple new sources of physics to not step on the toes of each other? E.g. imagine that a preliminary nanodiamond model from developer X has to be used in the same simulation as a clathrate model from developer Y?


• How can I keep track of their work and give feedback, check in advance how my planned changes to NCrystal will affect their work (and how can I then provide them with the code-changes they need to keep working with the next draft NCrystal release)?


• We also want to make sure that a new physics model can afterwards be integrated into the main NCrystal code, if desired.

As discussed with @marquezj, we should make it possible for NCrystal to calculate structure factors without Debye-Waller factors (since this is needed for LEAPR). Since the factors become unity at T=0K, one way to do so would be to allow T=0K.

Likely we would only support this for creation of Info objects and possibly only from .ncmat files, actual scatter objects seems a bit unphysical :-)

So we need to set up a test that this works (and fix it if it does not).

When using NCrystal in Geant4, we currently hardcode a transition threshold between G4 and NCrystal at 5eV (=0.128Å). There might be isotopes/atoms where nuclear resonances reach that far down, so we should consider making this threshold more dynamic.

It could be that the list of isotopes with resonances at such low energies is short enough that we can simply hard-code it inside NCrystal for simplicity. And find an easy way to communicate it (i.e. "5eV unless isotopes X,Y,Z where it is 2eV and isotopes W,V where it is 1eV"). We should probably require some minimal fraction of that isotope before moving the threshold, to avoid threshold jumping around due to tiny trace of something.

For obvious reasons of debugging and troubleshooting.

One semi-accidental side-effect of NCrystal v2.1.0 is that I removed an old feature in NCDefs.hh which was to provide M_PI on all platforms. Now, it instead removes it on all platforms (to avoid accidentally creating non-portable code we have to do either one of these).

Now I am wondering if it might disturb downstream code needlessly, and if we should perhaps revert to the old behaviour. Needs thought.

@xxcai1 raised a concern whether or not the speedup we enable in SCBragg (single crystals), using pre-calculated wavelength thresholds for all planes, can fail in some cases, leading to wrong results. I will disable the speedup temporarily, but we should investigate so it can be put back in.

Neutron scattering scattering lengths in NCrystal are taken from http://www.ati.ac.at/~neutropt/scattering/Scattering_lengths_table_20010419.pdf. The same table can be found in the ILL Neutron Data Booklet published in 2003. It is unclear if this table is dated.

The source of the atomic weight was not documented. The latest atomic weight may be used instead. https://www.nist.gov/pml/atomic-weights-and-isotopic-compositions-relative-atomic-masses.

Neutron mass and other constants should be double checked with the "Fundamental Physical Constants" that is available at https://physics.nist.gov/cuu/Constants/. Notice at the end of this year, this table will be updated for the 2018 edition.

Compare e.g.
https://github.com/mctools/ncrystal/blob/master/data/Ag.nxs
and
https://github.com/mctools/ncrystal/blob/master/data/Ag_sg225.ncmat

debye temperatures and lattice parameters differ slightly, which they really should not.

This should be fixed for NCrystal 1.0.0 since we are likely going to compare both in the paper.

At some point we should stop referring to the two components as "Bragg" and "Background". The latter is not a very good choice of words (e.g. people working at a neutron TOF instrument would disagree strongly), and we anyway want to split out incoherent-elastic from inelastic. And while "Bragg" is more clear, if we support SANS, we could anyway cover both with and coherent-elastic category.

Some random notes:

Eventually update bkgd/incel/inel keyword mess. New keywords "inel" and "elinc" will govern the non-bragg components, while the keyword "bkgd" will be retained partly for backwards compatibility and partly to support "external" curves from nxs. I.e. only bkgd=none, bkgd=0, bkgd=external will be kept as as special keywords, and the new default bkgd=componentwise will be needed if user sets elinc/inel. We can later consider elcoh to cover both bragg and SANS. elinc='none', 'auto' (i.e. on for crystalline materials), 'isotropic' (like auto, but forces isotropic samplings) The "inel" takes most of the role of the old "bkgd" keyword.

Given that we know how to expand normals to a whole symmetry family of normals, we could also use this to validate that the normals in the loaded HKL families agree with the spacegroup number.

I.e. we could validate that .ncmat files have correct spacegroup numbers, even without resorting to comparison with external tools like nxslib.

NCrystal v2.0.0 (to be released shortly) will include support for scattering kernels. Although we will already be using the improved sampling algorithm for these that we published in 2018, I am opening this issue to remind ourselves to at some point find time to implement the so-called "cell-based sampling" idea that we have discussed internally. That should result in much faster sampling, and sampling with fewer unwanted artifacts.

Now NCrystal builds against MT-builds of Geant4 (cf. #35), we should also not forget to actually support running multithreaded Geant4 simulations with NCrystal. Of course, issue #18 must be resolved first.

McStas compilation of NCrystal_sample.comp gives warnings, we should see if they are possible to fix.

I'm on a fully updated Debian 9 and have geant4 installed using the following

cmake -DCMAKE_INSTALL_PREFIX=/usr/local/share/geant4/10.4.0/install/debug -DGEANT4_INSTALL_DATADIR=/usr/local/share/geant4/data -DGEANT4_BUILD_MULTITHREADED=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DGEANT4_USE_QT=ON -DGEANT4_USE_GDML=ON -DGEANT4_USE_OPENGL_X11=ON -DGEANT4_USE_RAYTRACER_X11=ON /usr/local/share/geant4/10.4.0/geant4.10.04

I do the following from inside a fresh clone of ncrystal

$ mkdir build
$ cd build
$ cmake ../
-- The CXX compiler identification is GNU 6.3.0
-- The C compiler identification is GNU 6.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PythonInterp: /usr/bin/python (found version "2.7.13") 
###################################################
## NCrystal configuration summary:               ##
##   NCrystal library and headers       : yes    ##
##   NCrystal python module and scripts : yes    ##
##   G4NCrystal library and headers     : yes    ##
##   Enable examples for C and C++      : yes    ##
##   Install shipped data files         : yes    ##
##   Enable .nxs/.laz/.lau support      : yes    ##
###################################################
-- Configuring done
-- Generating done
-- Build files have been written to: /home/php1ic/repos/ncrystal/build

but the build fails at the linking stage of the geant4 example

$ make VERBOSE=1
.
.
.
[ 95%] Linking CXX executable ncrystal_example_g4sim
/usr/bin/cmake -E cmake_link_script CMakeFiles/ncrystal_example_g4sim.dir/link.txt --verbose=1
/usr/bin/c++   -O3 -DNDEBUG   CMakeFiles/ncrystal_example_g4sim.dir/examples/ncrystal_example_g4sim.cc.o  -o ncrystal_example_g4sim -Wl,-rpath,/home/php1ic/repos/ncrystal/build:/usr/local/share/geant4/10.4.0/install/debug/lib: -rdynamic libG4NCrystal.so libNCrystal.so -lm /usr/local/share/geant4/10.4.0/install/debug/lib/libG4Tree.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4GMocren.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4FR.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4visHepRep.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4RayTracer.so -lSM -lICE -lX11 -lXext /usr/local/share/geant4/10.4.0/install/debug/lib/libG4VRML.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4vis_management.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4modeling.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4interfaces.so /usr/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5.7.1 /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.7.1 /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.7.1 /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.7.1 /usr/local/share/geant4/10.4.0/install/debug/lib/libG4persistency.so -lxerces-c /usr/local/share/geant4/10.4.0/install/debug/lib/libG4error_propagation.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4readout.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4physicslists.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4run.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4event.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4tracking.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4parmodels.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4processes.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4analysis.so -lexpat /usr/local/share/geant4/10.4.0/install/debug/lib/libG4digits_hits.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4track.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4particles.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4geometry.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4materials.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4graphics_reps.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4intercoms.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4global.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4clhep.so /usr/local/share/geant4/10.4.0/install/debug/lib/libG4zlib.so 
libG4NCrystal.so: undefined reference to `G4cout'
collect2: error: ld returned 1 exit status
CMakeFiles/ncrystal_example_g4sim.dir/build.make:135: recipe for target 'ncrystal_example_g4sim' failed
make[2]: *** [ncrystal_example_g4sim] Error 1
make[2]: Leaving directory '/home/php1ic/repos/ncrystal/build'
CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/ncrystal_example_g4sim.dir/all' failed
make[1]: *** [CMakeFiles/ncrystal_example_g4sim.dir/all] Error 2
make[1]: Leaving directory '/home/php1ic/repos/ncrystal/build'
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

Can ncrystal only be used with non mutlithreaded installs of geant4?

I realised that we might be able to improve the speed with which we can sample scattering events for incoherent elastic scattering, beyond what we have now - in the case of users calling the generateScattering function of the API.

For neutrons below a certain energy (which is material dependent), the distribution should be almost isotropic. In those cases we can do acceptance-rejection based sampling as we do now, but instead of generation mu=cos(theta) first and then afterwards constructing 3D output direction with a uniform azimuthal angle, we can do the acceptance-rejection based sampling directly on the 3D vectors: Sample isotropic output direction, take dot-product with input direction and get the candidate mu-value. If accepted, we are done. If not, go back and sample new isotropic output direction.

It would be useful if our McStas component could support options for variance reduction. Possible ideas, which all must handle intensity reductions correctly:

• Ability to focus neutrons (by making sure they are exit only in a certain direction, usually towards the next component).
• Ability to force interactions, so no neutrons pass without any scattering (unless they completely miss of course).
• Splitting ability (perhaps the existing McStas SPLIT keyword is enough?)

Ideally I would first discuss with McStas devs before pursuing any of these.

Since we are open source we should be able to benefit from free coverity scans:

https://scan.coverity.com/github

Supposedly there is even github/travisCI integration.

Currently the incoherent elastic cross-section is for historical reasons handled inside the same Scatter class implementation as the inelastic cross sections. There are many good reasons why this should change.

One complication is that .nxs files currently are loaded without mean-squared-displacement info, and even for .ncmat files the inelastic scatter model recalculates them rather than using the ones on the NC::Info object. We should clean up this first - preferably by never recalculating MSD's, and by also providing MSD's for .nxs files.

I have tried to compile NCrystal in MSVC2017 but there were issues:

1. fatal error LNK1181: cannot open input file 'm.lib'
2. need to #define _USE_MATH_DEFINES and then #include <math.h> in: NCFastConvolve.cc and NCMath.hh
3. ncrystal_core\src\ncmath.hh(115): error C2065: 'x': undeclared identifier (change x to a)
4. std::bind1st (several places?) -> need to add #include . By the way, the function is deprecated in c++11, and removed in c++17
5. NCMatrix.cc: swap_ranges -> std::swap_ranges and #include
6. NCParseNCMAT.cc: #include for isdigit
7. defined(GNUC) or defined(clang) -> defined(GNUC) || defined(clang)

and several strange warnings:
ncparsencmat.cc(92): warning C4146: unary minus operator applied to unsigned type, result still unsigned (same in line 112, 151 and 167)

Regards,
Andrey

We would like to be able to use crystalline steel as a material within the DG simulation framework (He3Tubes and perhaps MultiGrid, i.e. the material of the He3 walls and the detector vacuum tank respectively). We have been advised to represent this as γ-iron. I am placing a request for producing the .ncmat file.