[Discussion] User interface and Executors

[szabo137]

In this issue, we discuss establishing a common user entry point for calculating matrix elements (or squared matrix elements, differential probabilities, and differential cross sections; we will use matrix_element as a placeholder for all of these functions). This is especially important if calculations require preparation and initialization, such as the directed acyclic graph (DAG) building and optimization provided by ComputableDAGs.jl.

Problem Statement

Currently, the matrix_element is compiled if it is called for the first time on a PhaseSpacePoint (PSP). This approach is convenient if the function's body is hard-coded for a given tuple of configuration types: (proc::AbstractProcessDefinition, model::AbstractModelDefinition, psl::AbstractPhaseSpaceLayout), as it is for perturbative Compton scattering. However, if the matrix_element code needs to be generated before compilation (e.g., when using ComputableDAGs for generated Feynman diagrams), this becomes less straightforward.

Possible Solutions

1. Using Generated Functions

It should be possible to generate code based on input types, such as (proc::AbstractProcessDefinition, model::AbstractModelDefinition, psl::AbstractPhaseSpaceLayout) or only the process and model types. This could be achieved with generated functions (ideal case) or macros (less ideal, as it would change the API). A potential user would follow this call graph:

flowchart LR
    A[ProcessDefinition] -->|init| PSP[PhaseSpacePoint]
    B[ModelDefinition] -->|init| PSP[PhaseSpacePoint]
    C[PhaseSpaceLayout] -->|init| PSP[PhaseSpacePoint]
    D[coordinates] -->|coord_map| PSP[PhaseSpacePoint]
    PSP -->|passed| M[matrix_element]
    CONF[Executor Config] ----> |global cache| CDAG[ComputableDAG]
    M --> |first call| CDAG
    CDAG --> |compiled to| M
    M --> |second call| R(Result)

Loading

Here, matrix_element is a generated function that generates code using (proc::AbstractProcessDefinition, model::AbstractModelDefinition) and ComputableDAGs.jl during the first call, then reuses the compiled code on subsequent calls with the same input types. Configuration of ComputableDAGs (i.e., Executor Config) can only be set globally.

2. Using a Setup Type

A MatrixElement setup type (similar types could exist for differential cross sections, etc.) would allow configuration and compilation to happen before the first coordinate is specified. The corresponding flowchart is as follows:

flowchart LR
    A[ProcessDefinition] -->|init| ME[MatrixElement]
    B[ModelDefinition] -->|init| ME
    C[PhaseSpaceLayout] -->|init| ME
    CONF[Executor Config] --> |init| ME
    ME --> |init on construction| CMAP[Coordinate Map]
    CMAP -->|cached| ME
    ME --> |init on construction| CDAG[ComputableDAG]
    CDAG ---> |compiled and cached| ME
    
    ME --> CALL{CALL}
    D[coordinates] ---> CALL
    CALL --> PSP[PhaseSpacePoint]
    ME -->|passed| M[matrix_element]
    PSP -->|passed| M
    M --> R(Result)

Loading

In this approach, the executor configuration is resolved locally with the other configuration types (proc::AbstractProcessDefinition, model::AbstractModelDefinition, psl::AbstractPhaseSpaceLayout). This makes the configuration more transparent for users (no global config needed except for defaults), and the MatrixElement object could serve as a container for a fully configured and compiled matrix_element function, useful for validation, serialization, or repeated calculations.

Additional Remarks

• instead of ComputableDAGs.jl, one could use the notion Executor with its interface (to be discussed). This could open the possibility of inserting other sources for the matrix element code, e.g. wrappers to foreign codes like MadGraph.