McStas-Union with NCrystal: inconsistency between included ncrystal.h and linked NCrystal library

[EstiezQ]

Hello, I am Quentin, french student doing an internship at DTU Risoe with @nicriz as supervisor. We are using McStas with Union components and NCrystal library in order to simulate an extraction system of a CANS. We want to investigate the impact of Nanodiamonds coating on the extraction efficiency so we are using the SANSND_plugin. We did a fresh installation on my wsl environment of McStas 2.7.1 and NCrystal 3.0.0. We then interface on McStasScript for the instrument definition and we linked McStas and NCrystal using ncrystal_preparemcstasdir but when we run the instrument we get this Error message
NCrystal: NCrystal_SANS: ERROR: Inconsistency detected between included ncrystal.h and linked NCrystal library!

We are not sure of the cause of this issue since there wasn't an older version on the computer. We noticed that the error can come from the NCrystal_sample.comp:
if ( NCRYSTAL_VERSION != ncrystal_version() ) { NCMCERR("Inconsistency detected between included ncrystal.h and linked NCrystal library!"); }

Any idea of what could be the cause and how to fix it?

Thank you in advance.

[tkittel]

So likely you are having a mixup between the (older) NCrystal version shipped with McStas and the new NCrystal version you have installed yourself. To begin with, you should check with which ncrystal_preparemcstasdir that you are running the script from your newer NCrystal version, and not the one shipped with McStas. You can also look at the symlinks created by the script, and verify that they point to the correct NCrystal installation.

A likely cause of your issue is that you did not inject the newer NCrystal version properly in your paths. One way to do that is to source the setup.sh script which was installed with it. Be sure to do that after you have initialised your McStas environment.

[EstiezQ]

Thanks for your prompt reply Thomas. We run some checks in this direction:

which ncrystal_preparemcstasdir
/home/quentin/ncrystal-install/bin/ncrystal_preparemcstasdir

also

readlink NCrystalLink/include/NCrystal/ncrystal.h
/home/quentin/ncrystal-install/include/NCrystal/ncrystal.h

and

NCRYSTALDIR=/home/quentin/ncrystal-install
NCRYSTAL_DATADIR=/home/quentin/ncrystal-install/share/NCrystal/data
PATH=/home/quentin/ncrystal-install/bin:/home/quentin/anaconda3/bin:/home/quentin/anaconda3/condabin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program Files (x86)/Common Files/Intel/Shared Libraries/redist/intel64/compiler:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0:/mnt/c/Windows/System32/OpenSSH:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Program Files/MATLAB/R2021a/bin:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0:/mnt/c/WINDOWS/System32/OpenSSH:/mnt/c/Users/Quentin/Documents/strawberry/c/bin:/mnt/c/Users/Quentin/Documents/strawberry/perl/site/bin:/mnt/c/Users/Quentin/Documents/strawberry/perl/bin:/mnt/c/Users/Quentin/AppData/Local/Microsoft/WindowsApps:/snap/bin

So everything looks like is pointing toward the same NCrystal installation
Any further cheks we could run?

Thanks for your help!

[tkittel]

Hmm... I assume you got an NCrystal_sample.comp file created in your working directory as well? What does the DEPENDENCY line inside it say? Also, are you launchin McStas with mcrun from the commandline, or via McStasScript?

[EstiezQ]

Yes that's correct. The NCrystal_sample.comp is copied when we run ncrystal_preparemcstasdir. The DEPENDENCY line says:
DEPENDENCY "-Wl,-rpath,NCrystalLink/lib -LNCrystalLink/lib -lNCrystal -INCrystalLink/include"
Finally, we are launching McStas via McStasScript

[tkittel]

Hmm... I suspect the issue might be related to the invocation from McStasScript then. Perhaps @mads-bertelsen has an idea of what to do? I think he was working with a custom NCrystal installation via McStasScript recently.

[tkittel]

Thanks for the reply @willend. However, IMHO uninstalling the mcstas-ncrystal-2.7.1 package is not a much better solution than hacking the DEPENDENCY line. Because there might be a genuine and generic issue at play here here, so we should try to find a fix so the next users (who might not feel comfortable contacting us) will not just run into the same issue.

@EstiezQ / @nicriz can you try to see if there is a way to figure out the working directory and exact compilation flags used when compiling the instrument? @willend do you know if there is a way to see this from mcgui, or do they need to invoke mcrun with some specific option?

[willend]

Well, I would say that 99,9% of the generic McStas users simply make use of the NCrystal version provided with the package - so for those that insist on using bleeding edge / something else, the recommendation of uninstalling the "system-provided" NCrystal seems quite reasonable to me.

(It is true there is probably a genuine and generic issue behind, but I simply wanted to point to an obvious workaround - then it is for you and I to figure out the generics.)

mcgui in fact runs mcrun - and prints the output in the main window. If what is printed is not detailed enough, the easiest is probably to copy-paste the printed mcrun line to a terminal and add --verbose.

[tkittel]

Well... if only 0.1% of McStas users are taking full advantage of NCrystal, I wouldn't mind if that number would improve a bit ;-)

To be serious though, I think the 99.9% number is way too high - and it will probably never get that high since of the tight collaboration existing between the McStas and NCrystal developers and users, which in the ideal world should mean a constant flow of exciting and occasionally useful new NCrystal features being added in response to the needs of ppl using McStas :-)

The real problem for me is that maintaining and keeping track of all these countless workarounds becomes an ever increasing workload, and users not aware of the workarounds might simply give up. Also, since I don't feel confident that I can easily reproduce the environment and setup of @EstiezQ and @nicriz, it is for me most straight forward and efficient if we can convince them to debug their system a bit with our help. Anyway, thanks for the tips - @EstiezQ / @nicriz, can you try to follow Peter's instructions and see if you can produce some more information and/or log files that might shed some light on the issue? (feel free to send log-files by email).

[tkittel]

So me and @willend just had a small brain-storming chat, and eventually a likely cause of the issue dawned on us. @EstiezQ / @nicriz, do you by any chance keep your instrument file in a different directory than the one where you ran ncrystal_preparemcstasdir? That could explain the problem if so, since (for various reasons related to people using spaces in dirnames) mcgui always changes directory to the directory of the .instrument file before running. If so, either move your instrument files or run ncrystal_preparemcstasdir in the directory of your instrument files.

[nicriz]

Hi @tkittel, yes the instrument file is in the same folder where we run ncrystal_preparemcstasdir

[tkittel]

As an aside: @mads-bertelsen do you also have a check like:

if ( NCRYSTAL_VERSION != ncrystal_version() ) { /*...give error...*/ }

in the Union-NCrystal process? It seems like it might be worth the trouble to put in if not.

[nicriz]

Changing the dependency line in the NCrystal_process.comp to

DEPENDENCY "-Wl,-rpath,NCrystalLink/lib -LNCrystalLink/lib -lNCrystal -INCrystalLink/include"

solved the problem for us. Thanks for the help!

[tkittel]

That's great! For the benefit of others stumpling over this issue, I will try to summarise the issue and solution in dedicated answer.

[tkittel]

UPDATE Nov 2022: Starting with McStas v3.2, this should hopefully be a non-issue. All McStas components using NCrystal will at that point always query the ncrystal-config script to get appropriate build flags. So running which ncrystal-config (or ncrystal-config -s) in the terminal, should immediately show which NCrystal installation will be used in McStas components.

Keeping the previous answer here, since it will be a while before everyone use McStas v3.2:

For the benefit of people coming here looking for a solution, here is a summary of the situation and solution arising from discussions in other comments and private email:

NCrystal is used in two places in McStas, from the NCrystal_sample.comp and in the Union process NCrystal_process.comp. Both needs to include header files from NCrystal and to link against the NCrystal library in order to work, and for that reason they include a DEPENDENCY statement inside with appropriate flags for the build system. Since McStas ships a version of NCrystal, the shipped NCrystal_sample.comp and NCrystal_process.comp components both point towards that version. When using a custom (and usually newer) installation of NCrystal with a given version of McStas, one is instructed to run the command ncrystal_preparemcstasdir from the new NCrystal release in the working directory (where the instrument files are basically also required to be). Using symlinks, that command sets up a subdirectory named NCrystalLink which contains subfolders 'lib' and 'include' which points into the appropriate locations in the custom NCrystal distribution. It also puts (as a file or as a symlink depending on McStas version) a version of NCrystal_sample.comp into the working directory, which crucially contains the DEPENDENCY line:

DEPENDENCY "-Wl,-rpath,NCrystalLink/lib -LNCrystalLink/lib -lNCrystal -INCrystalLink/include"

Thus, any attempts at using the NCrystal_sample component will pick up NCrystal_sample.comp from the working directory, and via the DEPENDENCY line above and the created NCrystalLink subdirectory, get redirected to the intended custom installation of NCrystal.

Unfortunately this does not fix the NCrystal_process.comp which probably is an oversight, so for using NCrystal inside the McStas-Union geometry system, one must fix this up by hand. One way to do this is to find the NCrystal_process.comp file in the McStas installation and create a copy of it in the working directory. Inside that copy one must then replace the DEPENDENCY statement with the line above. Additionally of course, one must still run ncrystal_preparemcstasdir if not done already. Hopefully that should fix it. Assuming sufficient permissions, it is of course also possible to just edit the NCrystal_process.comp file in its place inside the McStas installation, but that will leave permanent changes to the McStas installation so this is not really recommended outside of a throw-away virtual machine.