Using NCrystal in C environment(s)

[nviolini]

Trying to integrate NCrystal into the Vitess codebase.
At the moment, the main issue is the following:
This string:
Ge_sg227.ncmat;temp=1C;dcutoff=0.5;mos=0.2deg;dir1=@crys_hkl:5,1,1@lab:0,0,1;dir2=@crys_hkl:0,-1,1@lab:0,1,0

works in python but fails in the Vitess C-environment.

When I cut it like this:
Ge_sg227.ncmat;temp=1C;dcutoff=0.5
it works in both envs.

Adding mos or dir options make it fail in C.
Is there a way to get from Ncrystal any errors checking, return errors or logs information?
This could help debug this situation.

[tkittel]

Hi @nviolini ,

The cfg-strings should certainly work in any environment, so I can't really help you without further details.

At the very least describe the process and provide a log file or screen shot of the error messages you get.

[nviolini]

Thanks for your reply @tkittel.
I try to simplify a bit the situation.
My aim is to call NCrystal to generate the S(Q,omega). I understood how to handle the energy part of the problem, ncrystal_crosssection calculates the cross section based on input energy values.
Now, what I'm struggling with, currently, is how to handle the Q part of the implementation.
On the Vitess side, we need to have physical direction components of the neutron before and after scattering. This enables further propagation of the trajectories to the detector, for example.
As far as I understand, ncrystal_samplescatterisotropic returns the scattering angle, so I thought ncrystal_crosssection would be able to do the same, but this doesn't seem to be the case.
I also thought I could fix dir1 and randomise dir2, but I read that in the event dir2 doesn't make sense from a crystallographic viewpoint, Ncrystal would overrule the input values for dir2.
This makes me puzzled because I would give a specific random dir2, while getting the cross-section for a different direction. Therefore I would need to skip this scattering event. That's how I got interested in knowing if there is a way to handle logs or errors or parse some useful information.
Does Ncrystal embed somewhere the physical direction used to calculate the cross section when dirtol option is used in ncrystal_crosssection?

Today I realised that what made the code fail without error yesterday was sending a default (initialised) value of dir2 and mos.
Sorry for this. Anyways, in Vitess we're kind of blind to execution errors on Ncrystal side. When there is an error or something goes wrong, the module stops working and the pipeline goes on to the next module. So we may really need to know how to handle some logs or error information that would be user-relevant.
For example if dir2 doesn't make sense, is there some user information available?
Btw, I think I learned how to handle cfg-string errors already, but if you have any tips, these are certainly welcome, too.

[tkittel]

@nviolini I am a bit confused about the way you are going about things. Adding NCrystal support to Vitess should hopefully not in general involve composing cfg-strings inside the new Vitess component itself. Rather, it is the general philosophy of NCrystal that the same cfg-strings can be used in a multitude of applications (e.g McStas, OpenMC, Geant4, standalone, etc.) to provide the same physics. Also, the ncrystal_samplescatterisotropic function is only for isotropic materials, which is not what you get when you use parameters like dir1, dir2, or mos. This is probably the difference between your C and Python cases, that you are using a C function which only accepts isotropic materials and a Python function which is also OK for anisotropic materials (since you failed to provide actual code samples, I am mainly guessing here).

In any case, all you should expose to the users concerning the NCrystal materials should be a string parameter, for the NCrystal cfg-string. Other parameters concerning geometric layout of your volumes etc. is something to be handled on your side, since NCrystal does not provide any sort of geometry tools.

Second, after you have initialised a material, during simulations you will need mainly the ncrystal_crosssection function to get the cross section (barns/atom) of both scattering and absorption, and then once you have determined that a scattering occurred you can use ncrystal_samplescatter to sample an outgoing neutron state. These functions handle both isotropic and anisotropic materials like single crystals.

I invite you to take a close look at how we have implemented the NCrystal_sample.comp McStas component, since it will probably give you a good idea of how you could approach this in Vitess:

https://raw.githubusercontent.com/McStasMcXtrace/McCode/refs/heads/main/mcstas-comps/contrib/NCrystal_sample.comp

Note that the NCrystal_sample.comp component only supports cylinder/box/sphere geometries. For more advanced geometries in McStas, one uses the McStas-Union subsystem which also has a dedicated NCrystal plugin.

I am going on holidays today, but if you wish we could set up a zoom meeting in January to discuss this in more detail. We could perhaps also invite @willend and Klaus L. Additionally, be aware that at Julich you have Jose R. which could probably help you with advice on a lot of this :-)

Cheers,
Thomas

[nviolini]

My idea so far is to let the user input in the front-end some of the parameters value that we then use in Vitess to write the cfg-string.
For example, temp = 1C --> it's used to add ;temp=1C to the cfg-string.
And so on for the other parameters.

Eventually, I'd like the user to be able to choose between single crystal, policrystal or isotropic scatterer.
And have the ability to switch on/off incoh and absorption in the front-end with kebab menus as typical of Vitess.
This options would be handled in the back end conditionally.

I wasn't aware of ncrystal_samplescatter but reading the McStas code was really helpful. I will try to implement it today.
This may solve all problems already. I think indeed I'm not aware of many things Ncrystal related, as I can't find exhaustive documentation for devs. Maybe I didn't look in the right place yet?
If you have any learning materials, please send me.

Having a video-call in January sounds a good idea. Hopefully by then, I will demo a already working module. And we can potentially improve this together.
Jose left our group and joined JCS recently.
He was a great addition to our team, indeed.
Thanks for you help so far and have great holidays.