[farhi]

McXtrace Undulator minor fixes

This is a minor fix to the Undulator component. mostly some safe guards against wrong usage. Only the SOLEIL_ANATOMIX example is affected. test value is updated.

Changes:

1. If neither focus_xw nor focus_yh is set, xi and psi were both forced to 0 and Omega=1, i.e. ALL rays were emitted exactly on-axis with a unit weight - silently. Now a warning is issued in INITIALIZE.
2. The one-sided focus branches initialized unused variables and double-assigned yo/xo -> cleaned up.
3. K derived from E1st could end up <= 0 (sqrt of a negative or zero) and then still pass into the physics -> guarded with a clear error.
4. fabs() on xi/psi loses the sign; harmless here (only theta^2 is used) but noted - the values are kept unsigned deliberately.
5. gamma/gamma2/igamma are recomputed per ray when dEe != 0; this is correct only because deltaEe is built from Ee each time - kept, but the ray-local copies are now used consistently.

---

Declaration of use of AI-tools

• Please add a checkmark here if you used AI-tools during the work for this contribution
• Further, please describe how / where and for what the tools were used: Mistral

---

Development OS / boundary conditions

Please describe what OS you developed and tested your additions on, and if any special dependencies are required:

• debian/arm

---

PR Checklist for contributing to McStas/McXtrace

For a coherent and useful contribution to McStas/McXtrace, please fill in relevant parts of the checklist:

• My contribution includes patches to an existing component file

  • I have used the mcdoc utility and rendered a reasonable documentation page for the component (please attach as screenshot in comments!)
  • I have ensured that basic use of the component is OK (e.g. an instrument using it compiles?)
  • I have used the mctest utility to test one or more instruments making use of the component (please attach mcviewtest report as screenshot in comments)
  • I have used the mccode-clangformat tool to apply the standard McCode component indentation scheme
  • I have used the mcrun --c-lint "linter" and followed advice to remove most / all warnings that are raised

• My contribution includes patches to an existing instrument file

  • I have used the mcdoc utility and rendered a reasonable documentation page for the instrument (please attach as screenshot in comments!)
  • I have used the mctest utility to test the instrument (please attach mcviewtest report as screenshot in comments)
  • I have used the mcrun --c-lint "linter" and followed advice to remove most / all warnings that are raised

• My contribution includes a new component file

  • I have ensured that naming of parameters are in the style of existing components. (Please check the McStas or McXtrace NOMENCLATURE docs.)
  • I have ensured that component parameters are in the usually units of McStas or McXtrace (SI + neutron/x-ray 'usual' units)
  • I have used the mcdoc utility and rendered a reasonable documentation page for the component (please attach as screenshot in comments!)
  • I have ensured that basic use of the component is OK (e.g. an instrument using it compiles?)
  • I have included a corresponding example instrument and will fill in the new instrument section below
  • I have used the mccode-clangformat tool to apply the standard McCode component indentation scheme
  • My new component is added within the contrib component category

• My contribution includes a new instrument file

  • I have used the mcdoc utility and rendered a reasonable documentation page for the instrument (please attach as screenshot in comments!)
  • I have ensured that basic use of the instrument is OK (e.g. it compiles?)
  • ... and provided reasonable default parameters in that instrument that produce reasonable output
  • ... and maybe even added a %Test: line (or a %TestScan: line for a parameter scan) to describe expected behaviour
  • I have used the mcrun --c-lint "linter" and followed advice to remove most / all warnings that are raised
  • My new instrument is added within the examples hierarchy in a folder in the style of examples/ESS/New_stuff/New_stuff.instr
  • My new instrument has a new, unique filename, not clashing with existing example instruments
  • My new instrument requires a data/input file. If the datafile is specific for my instrument I have left it in the same example folder, but if general use I have placed it in the global data folder.

• My work touches the code-generator in mccode/src

  • I have added reasoning and documentation for the change through an ADR record in our GRAMMAR section
  • I am attaching test output in the comments

• My work touches / adds to the runtime lib code (.c,.h etc in multiple locations

  • I am have added reasoning and documentation for the change below
  • I am attaching test output in the comments

• My PR is meant to fix a specific, existing issue

  • I have indicated the issue number here:
  • I have added documentation for the fix and possible side effects

• My contribution contains something else

  • Explanation is added in free form text above or below the checklist

---

[willend]

It looks like we should revert to the earlier value of 1e18?
SOLEIL_ANATOMIX : 3.05 [val: 1.07222e+18 / 7.80912e+17 = 137 %] <--- BIG DISCREPANCY??

[willend]

SOLEIL_ANATOMIX %Example → -n 1e5 ANATOMIX_E0=17 ANATOMIX_dE=0.01, target 9.4e17 (629ec3e).

The ±1 keV band vs. the ~eV mono acceptance made the test noisy: seed-to-seed scatter of ~20% at 1e5 and ~11% at 1e6 (39 s). With dE=0.01 the intensity is unchanged, scatter is ~3%, and it runs in 6 s at 1e5. Reference value from 2×1e6 runs: 9.4e17 ±1%. dE ≤ 3 eV starts clipping the mono tails.

🤖 Generated with Claude Code

[willend]

@farhi sorry didn't notice you already had done work in this direction 😅

[willend]

@farhi all green, I merge.