Single_crystal suppresses parameter-input by reflection-file content.

[willend]

Observations from @antoinepado and @mads-bertelsen indicate that both the McStas and McXtrace Single_crystal have an issue with correctly defining (e.g.) lattice-orientation via the input-parameters.

In other words, it seems as if lattice-oriented content of the reflection-file likely overwrites user-provided inputs.

A good discussion and a major overhaul of the code / logic is envisioned.

[willend]

In INITIALIZE, input-parameters are initially defined from user-inputs, then potentially overwritten by read_hkl_data:

[mads-bertelsen]

This applies to all information in hkl_info, which can be read from a file, thus also for example absorption and incoherent cross sections. For simple parameters like the cross sections, this can be fixed by reading the file before applying user input, and then only applying user input if the value is different from the default. Here it becomes essential that we can detect when an input is not the default, so values of 0 for cross section is not good enough, as a user may want to disable absorption.

The real difficult problem is however in the crystal orientation, as there are different ways to give this information. As far as I understand it:

• Give ax, ay, az, bx, by, bz, cx, cy, cz and not any of aa, bb and cc: The given lattice vectors are used
• Give ax, ay, az, bx, by, bz, cx, cy, cz and any of aa, bb and cc: The length of a, b and c vectors used, but they are oriented with angles aa, bb and cc

As @willend shows above, in the current version of the code the user inputs are set first, and then the file inputs overwrite these. This means the component often ends in the second mode, because aa bb and cc is found in the lau file, and thus the orientation described by the lattice vectors are given.

I think we need to take several steps to fix this situation and preserve all functionality.

• Ensure we can detect when a user provide an input, defaults of 0 are not sufficient as that may be meaningful input
• Check the user input before reading the file, if the crystal orientation is fully described in either of the two modes, protect all orientation parameters from being overwritten by the file
• After data is read from file, overwrite with all user parameters given by the user (catches for example cross sections)

We may also choose to change the input system to make it easier to understand the use of this component. Removing the aa, bb and cc parameters would greatly simplify the logic needed for the provided input. I would never guess how these parameters work without studying the documentation. Then ax, ay, az, bx, by, bz, cx, cy, cz could be required parameters, ensuring a uniform description of orientation.