Skip to content

McXtrace Lenses fix - #3049

Open
farhi wants to merge 10 commits into
mainfrom
2026-11-farhi-lenses-fix
Open

farhi wants to merge 10 commits into
mainfrom
2026-11-farhi-lenses-fix

Conversation

@farhi

@farhi farhi commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

McXtrace Lenses fix

The lens components are not much used, but there are known issues in some of them that do not properly focus. For this reason, an AI check was performed and dig out some significant improvements. Still, only one test value had to be changed.

Fixes for:

  • Lens_CRL_RTM.comp
  • Lens_elliptical.comp (major changes)
  • Lens_parab_Cyl.comp
  • Lens_parab.comp
  • Lens_simple.comp (minor changes)
  • ZonePlate.comp (minor changes)

New components are more compact.

Mostly:

  • geometry fixes
  • parameter checks

Updated MaxIV/FemtoMAX test value after Lens_parab_Cyl fix

All mxtest --comp pass
All mxtest --lint --comp pass
All mxdoc pass


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: An 'h' is missing in 'Further'. Used Claude to analyze the Lenses. Proposed changes which were applied.

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

Emmanuel FARHI added 7 commits November 5, 2026 15:49
…placed the formula with an exact closed form, and the slow path’s y_n now uses the correct amplitude and phase.

In fast=0 mode the x-position was propagated from an already-modified x.
yheight was ignored, so I now use it as the full aperture height.
Photons outside the aperture passed straight through. They are now absorbed.
The display box used the half-height as the full height.
Energy was K2E*k*1e-3, so a unit error.
It read mu and f from the wrong table columns and double-counted Z.
Its table lookup could read out of bounds.
kx, ky, kz weren’t updated before the second PROP_DL, so the photon moved along the wrong direction.
Absorption used d*N instead of the real path through the material.
Several return; statements in a non-void function are fixed.
acos(alpha) came out as NaN, because of a wrong normalisation.
Table_ParseHeader was missing its NULL terminator.
The generic names intersection, incom and lens could clash with other components and are renamed.
A missed aperture returned the original k vector, so the “miss” test never fired. Rays outside the lens passed through unabsorbed. I added a hit flag and these rays are now absorbed.

The aperture in Lens_parab was square rather than circular.
With k exactly along z, the linear-equation branch skipped the aperture check.
The code could pick an intersection behind the photon.
A missed aperture returned the original k vector, so the “miss” test never fired. Rays outside the lens passed through unabsorbed. I added a hit flag and these rays are now absorbed.

Lens_parab_Cyl treated the surface tangent as the normal, which gives wrong refraction when kx ≠ 0.
The default radius=1e-3 silently overrode xwidth/yheight, so the documented example didn’t work. The default is now 0.
The phase term multiplied by F instead of dividing by it.
Removed the dead rotation-matrix code and added a guard against calling Table_Free on an unread table.
Circular and linear logic could mix when both were specified.
The linear plate had no display.
The docs said the slits were along x; they are along y.
There was no input validation.
Things to check
Behaviour change: photons that miss any lens aperture are now absorbed instead of passing through.
ZonePlate weighting: it doesn’t apply the pdir weight, so intensity is not solid-angle weighted.
@willend

willend commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

Thanks for the work on these lenses. Several of them had real problems, and the sign and geometry fixes look right. I checked the vector Snell update, the surface normals and the elliptical rim drawing by hand, and they hold up.

This PR is large, though, and it combines bug fixes, API changes and some behaviour changes in one go. That makes it hard to review and hard to bisect if something regresses. For future PRs, could we keep bug fixes and new features or API changes separate? That would also make it easier for a reviewer to confirm each change.

Some things to address before merge, following AGENTS.md:

  1. Numerical changes (AGENTS.md §3.5): Several results change, not only the one test value. Examples are the default radius in Lens_simple (affects Be_BM_beamline and XFEL_SPB with rectangular apertures), the Lens_simple phase correction, the Lens_elliptical table columns and absorption path, and the yheight meaning in Lens_CRL_RTM. Could you list these in the PR body with before/after numbers for the affected examples?

  2. FemtoMAX test value changed by about 43× (2.75e-13 → 6.32e-15). Could you explain the physics behind that in the PR body? It would help reviewers trust the change.

  3. rough_xy / rough_z: These are removed from Lens_parab_Cyl but kept in Lens_parab as "not implemented". Could we make both the same? No example passes them, so removing them from both looks safe.

  4. CRL fast/slow check: The analytic fast=1 absorption was rewritten. Could you show that fast=0 and fast=1 agree for the same seed and -np? That would be a useful check to leave with the PR.

Smaller items (AGENTS.md §4, §5):

  • intersection_lens_elliptical has no #pragma acc routine, unlike the parab and cylinder helpers.
  • Table_ParseHeader(..., NULL) is now in some components but not in Lens_parab, Lens_parab_Cyl or Lens_CRL_RTM. Could we make them consistent?
  • The out-of-range energy check in Lens_elliptical was removed. Could you confirm Table_Value handles that case?
  • The ZonePlate.comp comment about zone radii contradicts itself. Boundaries are at r = K·√n.

I haven't compiled or run mxtest on this, so these comments come from reading the diff only.

@farhi

farhi commented Nov 6, 2026

Copy link
Copy Markdown
Contributor Author

I fully agree with all these remarks, thanks Peter. The component updates were initiated before the AGENTS.md is created on the repo. Clear rules are now better to harness the AI contributions. I'll try to find time to process the requested clarifications...

@farhi

farhi commented Nov 6, 2026

Copy link
Copy Markdown
Contributor Author

Perhaps it would be better to split this PR into separate PR's, one per comp. And I can take into account the new AGENTS.md rules to reduce the amount of changes and keep control over AI's ?

@willend

willend commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

@farhi feel free to take whatever route you prefer. Also, I don't mind multiple comps edited pr PR, it's more the mix of bugfixes with other stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants