arc shape detector pixel for use in McStas and Mantid

[c-howard92]

I am looking to implement a simulation of the newly planned instrument in both McStas and Mantid to test new data routines. I have currently been able to produce a basic description of the instrument in McStas that then works in Mantid using the component monitor_nD, as described in the manuals and on the GitHub page.

However, the issue I am having is that for our new forward- and back-scattering detectors the pixel shapes are defined as arcs, creating a wedge shape for each module. Currently, I have been able to produce a simple version using square detector modules with square pixels. However, these are not technically correct, because we want to be able to model the wedge shape of each module with arc pixel shapes to correctly capture the curved Debye-Scherrer rings in this geometry.

Is there any way to specify an arc shape (or any shape other than 'square' or 'banana') that can be used in McStas and will then be able to correctly load into Mantid? In Mantid, there is a 'slice-of-cylinder-ring' shape that uses an inner and outer radius and depth to set the appropriate shape. However, I do not know of a shape that is available in McStas to do this. I have tried using '.OFF' files but have not been able to get these working.

Thank you,

[willend]

Hello @c-howard92,

Thank you for reaching out. Your observation is correct, the 'banana' shape is even not functional in the 3.3 release, and I have recently corrected the "IDF-generator" mcdisplay-mantid as NeXus files generated using SNS_ARCS_Mantid.instr were not loadable in Mantid: https://github.com/McStasMcXtrace/McCode/issues/1491

If you can make do with cylindrical arc / banana shapes (oriented how ever way you need) you should be able to replace your McStas 3.3 tools/Python/mcdisplay/mantid_xml/mcdisplay.py with the current one of the main branch: https://github.com/McStasMcXtrace/McCode/blob/main/tools/Python/mcdisplay/mantid_xml/mcdisplay.py

... or wait a few days which should mean that McStas 3.4 is out including the above patch.

But if I understand you correctly, your pixel-shapes are non-uniform / irregular across each detector module?

If that is the case, the only way forward is indeed '.OFF' files which is not trivial to get going, but can be done. @trnielsen has for instance in the past generated such '.OFF' for triangular detector panels.

Perhaps provide some graphical information on your pixel/module geometry and we will try to find a solution?

[c-howard92]

Hi,

I have attached a (very crude) graphic that shows one of the modules on the left, and a guide to the shape of each of the pixel elements. Each pixel is an arc shape and are spaced evenly across the detector module - they are the same shape to an extent, but the size of the pixel varies according with the geometry.

If '.OFF' files are needed, then we can give that a try. I would appreciate some help with getting them working, since I have not been able to produce working files, nor files that then will also work with Mantid as well.

I can provide technical drawings if they are required, but getting something working with approximately the correct shape would be beneficial for now.

Thank you

[willend]

I again, I didn't have time to progress in this direction as of yet, but I would probably myself proceed this way, likely using Matlab where I have a few routines for handling OFF files readily available:

1. Write a function that given arc radius, angular extent, "angular binning" and "depth" expresses a two sets of of x / y "vertice-coordinates" for the inner and outer "rim" of the given arch
2. For each arch
3. Define arrays Vertices = [xi1 yi1 zi1; ... ; xin yin zin; xo1 yo1 zo1; ... ; xon yon zon] and Faces = [1 n+1 n+2 2; 2 n+2 n+3 3; ...]
4. Look how each of these look using the patch function
5. Add all the arches by concatenating the Vertices arrays and Face-arrays with modified indices to point at the right vertices
6. Export the result to an OFF file

(Can of cours optionally be done for one arch per file, adding multiple Monitor_nDs if easier)

OFF files are in fact quite simple in terms of content - the difficulty lies more in the tools that come before the file.

To me the above is simpler than firing up a CAD software, but this is also an option if you know how to (parametrically) draw in 2D/3D using these tools . FreeCAD may be used as a conversion tool, it supports lots of different CAD inputs and may export OFF. (But bear in mind the not-too-well-documented fact that McStas only supports polygons of rank 3/4 and that Monitor_nD will treat each polygon as a "pixel". I.e. "volumes" will actually become little cubes with "detection" on all sides...)

[willend]

@c-howard92, I've come across OpenSCAD that actually looks relatively workable for a) "coding" meshes and b) exports OFF https://en.wikibooks.org/wiki/OpenSCAD_User_Manual

Perhaps there is a chance of using that?

[c-howard92]

Hi,

many thanks for your suggestions, I have now been able to produce some ".off" files. I wanted to start with something simple so I made a rectangular box and gave this a try in McStas.

If I run the simulation without using wanting to import into Mantid, then I can see the ".off" file and it does indeed seem to be working. However, as soon as I try to make this a component that can be imported into Mantid, it either:

1) Does not run, since I get the following error:

or

2) If I run this using the mcrun-pl --format=NeXus and mcdisplay-pl --format=NeXus, then it runs, but it does not write the component into the IDF. When importing into Mantid, this of course means that it will not load the data.

I have tried multiple versions of McStas (2.7.1, 2.7.2, 3.2) but always get the same results. Any ideas on what could be causing the issue? Am I using the wrong syntax? Is this a McStas issue, or should I also speak with Mantid developers also?

Many thanks for your help so far, it is much appreciated.

[willend]

Hmm, try giving me acces to all bits and pieces that currently makes up your instr? Then I have a chance at doing more qualified guesswork at what is going on... (.instr file, .off file, any local comps, datafiles etc.)

Either a zip file here or send it via e-mail? pkwi@fysik.dtu.dk