[Proposal] Unified PhotonElectronScattering process with dultiple dodel definitions

Summary

This issue proposes refactoring photon-electron scattering into a single process type:

struct PhotonElectronScattering <: AbstractProcessDefinition end

Specific physics regimes—Compton, Thomson, and Rayleigh scattering—are handled by selecting appropriate model definitions that encapsulate the relevant matrix elements, approximations, and assumptions. This design cleanly separates the scattering mechanics (phase space and particles) from the physics (models, limits, phase spaces).

Motivation

• Avoid duplication: All scattering processes are fundamentally \gamma + e^- \rightarrow \gamma + e^-; only the model changes.
• Encourage reuse: Similar kinematic layout (2→2 scattering) with varying energy regimes.
• Simplify interface: One process to use, one interface to test and validate.
• Enable future extensions: e.g. polarized models, medium corrections, atomic binding effects.

Proposal Details

1. Define Unified Process Type

struct PhotonElectronScattering <: AbstractProcessDefinition end

2. Model Definitions for Physical Regimes

Each model implements the AbstractModelDefinition interface:

struct ComptonModel <: AbstractModelDefinition end

struct ThomsonModel <: AbstractModelDefinition end

struct RayleighModel <: AbstractModelDefinition end

3. Phase Space Layout

A common PhaseSpaceLayout can be used for 2→2 scattering:

struct PhotonElectronScatteringPhaseSpace <: AbstractPhaseSpaceLayout end

The different generation of the momenta are then handled by the respective implementation of _build_momenta.

Tasks

• Define PhotonElectronScattering as a unified process
• Implement ComptonModel, ThomsonModel, and RayleighModel as subtypes of AbstractModelDefinition
• Create PhotonElectronScatteringPhaseSpace layout
• Implement scattering interface methods: matrix_element, differential_cross_section, etc.
• Write tests to validate transitions between models (e.g. Compton → Thomson at low energy)
• Add documentation and examples

Benefits

• Unified and extensible process architecture
• Model-driven logic enables clear physics separation
• Reduces duplication while keeping full flexibility
• Compatible with QEDbase.jl interfaces

---

Related

• QEDbase.jl
• Potential extensions: in-medium effects