Release 0.2.0 #92
Merged
Release 0.2.0 #92
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Generatities
This MR adds a Julia interface including types and functions to describe
particles in the sense of the standard model of particle physics. The
description is not restricted to static properties, but can in general
be fulfilled by any instance of particles in general.
Furthermore, this MR contains an implementation of a type hierarchy for
Bosons, Fermions, and their respective anti-particles, as well as
particle types for Electrons, Positrons, and Photons. Again, the type
hierarchy is not restricted to these particle types.
# Particles
## Abstract particle interface
In the implementation, the notion of particles is derived from an
abstract type `AbstractParticle` and the following interface functions:
* `is_fermion(::AbstractParticle)`, which returns `true` if the input
can be considered as a fermion, and `false` if not.
* `is_boson(::AbstractParticle)`, which returns `true` if the input can
be considered as a boson, and `false` if not.
* `is_particle(::AbstractParticle)`, which returns `true` if the input
can be considered as a *particle*, and `false` if not.
* `is_anti_particle(::AbstractParticle)`, which returns `true` if the
input can be considered as an *antiparticle*, and `false` if not.
* `mass(::AbstractParticle)`, which returns the mass of the input
(usually as but not restricted to *float*)
* `charge(::AbstractParticle)`, which returns the electric charge of the
input (usually as but not restricted to *float*)
For more detailed descriptions, see the respective docstrings.
## Particle type hierarchy
The abstract type `AbstractParticleType <: AbstractParticle` is the root
type for all types of particles, where `type` means, that all subtypes
only provide static information about a certain particle species.
Beginning with `AbstractParticleType`, there is a hierarchy of particle
types indicating if there are fermions, bosons, and their respective
anti-particles. The leaves of the hierarchy tree are the concrete types
for `Electrons`, `Positrons`, and `Photons`.
Within this MR, the particle type hierarchy looks like this:
```mermaid
graph TD
A(a_AbstractParticleType) --> B1(a_FermionLike)
B1 --> B11(a_Fermion)
B11 --> B111(Electron)
B1 --> B12(a_AntiFermion)
B12 --> B121(Positron)
B1 --> B13(a_MajoranaFermion)
A --> B2(a_BosonLike)
B2 --> B21(a_Boson)
B2 --> B22(a_AntiBoson)
B2 --> B23(a_MajoranaBoson)
B23 --> B231(Photon)
```
(The leading `a_` indicates that the type is abstract. This was done
only here and not in the code.)
It can easily be extended by concrete types to other particles, e.g.
Gluons, Higgs, W-, or Z-Bosons as well as Neutrinos, but also
quasi-particles like Cooper-pairs or phonons.
Except for `mass` and `charge`, inserting particle types into the
hierarchy above will provide default implementations for the particle
interface functions.
This means the only interface functions which need to be implemented for
additional particles are `mass` and `charge`. For `Electron`,
`Positron`, and `Photon`, this is already done.)
Using reasonable defaults, the particle interface can be extended, e.g.
by functions like `flavor`, `color_charge`, and so on.
---------
Co-authored-by: Uwe Hernandez Acosta <[email protected]>
Co-authored-by: Tom Jungnickel <[email protected]>
This PR provides an implementation of the model and process interface,
which is also combined with an interface for differential and total
cross-sections.
# The model definition interface
In this PR, the model interface describes only static information, i.e.
there is only one un-parameterized base type and a convenient interface
function:
```julia
AbstractModelDefinition
fundamental_interaction_type(::AbstractModelDefiniton)
```
# The process definition interface
In this PR, the process interface describes only static information
about a scattering process. Here, a scattering process should be seen in
a generic way, which forms a physical scattering process, if it is
combined with a model definition above.
The process definition interface is defined as
```julia
AbstractProcessDefinition #base type for processes
incoming_particles(::AbstractProcessDefinition) # return tuple of incoming particle-like
outgoing_particles(::AbstractProcessDefinition) # return tuple of outgoing particle-like
```
Here, *particle-like* stands for subtypes of `AbstractParticleType`, so
the static instances of particles.
Additionally, in this PR, the following process related functions are
implemented
```julia
number_incoming_particles(::AbstractProcessDefinition) # number of incoming particles-like
number_outgoing_particles(::AbstractProcessDefinition) # number of outgoing particles-like
```
# Cross sections
Based in the interface funcitons for process and model definition, this
PR also provides an interface for differential and total cross sections.
This interface is definied my the following two functions:
```julia
_differential_cross_section(
proc_def::AbstractProcessDefinition,
model_def::AbstractModelDefinition,
initPS::AbstractVector{T},
finalPS::AbstractVector{T},
) where {T<:QEDbase.AbstractFourMomentum}
_total_cross_section(
proc_def::AbstractProcessDefinition,
model_def::AbstractModelDefinition,
initPS::AbstractVector{T},
) where {T<:QEDbase.AbstractFourMomentum} end
```
where `initPS` and `finalPS` are vectors containing the four-momenta of
the incoming and outgoing particles, respectively. The leading `_`
indicates, that the functions are not exported, and that no
input-validation is applied. Additionally, there are versions of
`_differential_cross_section` and `_total_cross_section`, which evaluate
the respective quantity on a set of phase space points, i.e. a matrix of
four-momenta, where the columns represent the momenta of the incoming or
outgoing particles and the rows represent the different phase space
points. Currently, only serial execution of the respective loops is
implemented.
# Testing
The unit-tests for the interface have the following structure:
* a full test implementation of every interface
* a partitial test implementation of every interface (dedicated for
failing the interface, the are indicated by an appended `_FAIL`)
* a test for every interface function
* a test for every derived function
* a test for every break of the interface
# Final remarks
The `README.md` is updated to include a small section on how-to build
the documentation locally.
---------
Co-authored-by: Uwe Hernandez Acosta <[email protected]>
Co-authored-by: Tom Jungnickel <[email protected]>
In an offline discussion, we decided to remove the `Manifest.toml`s from the library, since a library should build its dependencies from scratch every time.
With this PR, the concept of *computation setups* is introduced, and general as well as functionality related to scattering processes is implemented. ## Description of the problem One of the main tasks of this package is the computation of quantities like differential and total cross-section for given scattering processes and a given set of parameters. Usually, these quantities depend on a fixed set of initial parameters, and their value needs to be calculated for large amounts of input data. For example, the differential cross-section of a process depends on the generic scattering process, the compute model, and all sorts of initial parameters, which might be physical (e.g. energy scales) or technical (e.g. integrator settings). Once initialized, the differential cross-section is still a function of the external momenta of a scattering process. Therefore, for a given set of input data, i.e. momenta, one needs to be able to compute the respective value of the differential cross-section using the given setting. ## Suggested solution The initial parameters for a given quantity will be collected in a *setup*, which, once initialized, describes the *initialized quantity*, i.e. the quantity with fixed initial parameters. The actual computation can be performed by calling a member function `compute` on the setup object and the respective input arguments. The implementation described below defines an interface, that unifies this approach and extends the computation workflow by adding input verification and post-processing steps. ## Implementation details The root type for all setups is `AbstractSetup`, for which the following interface functions are defined: ```Julia _input_validation(stp::AbstractSetup, input::Any) _compute(stp::AbstractSetup, input::Any) _post_computation(stp::AbstractSetup, input::Any, result::Any) ``` None of those functions is exported, but they need to be added for a concrete implementation of `AbstractSetup`. For all functions, except `_compute`, a generic fallback is implemented, which uses a default implementation for the respective function. Based on the interface functions, the actual compute function is implemented as ```Julia compute(stp::AbstractSetup, input::Any) ``` where internally, the following steps are performed: 1. input validation by calling `_input_validation` 2. actual computation by calling `_compute` 3. post-processing by calling `_post_computation` Additionally, based on `AbstractSetup`, a specialized version of setups related to the combination of scattering processes and compute models is implemented: `AbstractProcessSetup<:AbstractSetup`, where the following functions are added to the setup interface: ```Julia scattering_process(stp::AbstractProcessSetup) compute_model(stp::AbstractProcessSetup) ``` Based on them, the following functions are delegated to the respective type parameter: ```Julia number_incoming_particles(stp::AbstractProcessSetup) number_outgoing_particles(stp::AbstractProcessSetup) ``` ## Final remarks The possibilities for functionality based on the setup definition above are not exhausted by the set of interface functions defined with this PR. For example, the pre-and post-processing could be enhanced by more fine granular structures. Furthermore, the initialization step of a setup could have its input validation. This is currently delegated to the users, who implement a setup by themself. Finally, the set of functions defined on `AbstractProcessSetup` and delegated to the process and model, could be extended if necessary. However, all the points above should be considered only if they are necessary, which implies opening dedicated issues if any. --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: Tom Jungnickel <[email protected]> Co-authored-by: Anton Reinhard <[email protected]>
closes #15 --------- Co-authored-by: AntonReinhard <[email protected]>
…Dbase (#23) Fixes #22 Co-authored-by: AntonReinhard <[email protected]>
Beside the changes in the `CompatHelper.yml` I did also: - Generated a ssh key pair for the deployment and add it to the repository like described in the [compat helper documentation](https://juliaregistries.github.io/CompatHelper.jl/stable/#Creating-SSH-Key). - Enable the option `Allow GitHub Actions to create and approve pull requests` option for the whole `QEDJl-project` group. - It is not possible to enable it only for a single repository. - Disable the option for repositories ` QEDjl-project.github.io`, `registry`, `.github` fixes: #20 Co-authored-by: Uwe Hernandez Acosta <[email protected]>
…existing compat) (#25) This pull request sets the compat entry for the `QEDbase` package to `0.1`. This keeps the compat entries for earlier versions. Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request. Note: Consider registering a new release of your package immediately after merging this PR, as downstream packages may depend on this for tests to pass. Co-authored-by: CompatHelper Julia <[email protected]> Co-authored-by: Uwe Hernandez Acosta <[email protected]>
This if-condition avoids, that the compat helper is executed in forks. copy of: QEDjl-project/QEDfields.jl#19
… 0.9, (keep existing compat) (#26) This pull request sets the compat entry for the `DocStringExtensions` package to `0.9`. This keeps the compat entries for earlier versions. Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request. Note: Consider registering a new release of your package immediately after merging this PR, as downstream packages may depend on this for tests to pass. Co-authored-by: CompatHelper Julia <[email protected]> Co-authored-by: Uwe Hernandez Acosta <[email protected]>
This PR add the CHANGELOG of the release of version `v0.1.0` to `dev`. Since this was already reviewed, it can be merged, if the checks all pass. --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]>
This PR adds a simple implementation of fermion and boson propagators. This should be merged *before* #18 because the latter will use the functionality. - replace dev-version of `QEDbase` with release `v0.1.5` (cf. QEDjl-project/QEDbase.jl#39) --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: CompatHelper Julia <[email protected]> Co-authored-by: Anton Reinhard <[email protected]>
There was one more spot that was overlooked where the custom registry can be removed now.
# Problem statement
The current implementation only allows implementing
`differential_cross_section` directly for given processes. Furthermore,
the interface does not allow the implementation of different phase-space
coordinate systems, e.g. to model $d\sigma/dE$ **and**
$d\sigma/d\cos\theta$ for the same process.
# Suggested solution
## Advanced process interface
I suggest to disassemble the differential cross-sections interface into
a more flexible interface:
```mermaid
flowchart TD
_differential_cross_section --> _differential_probability
_differential_cross_section --> _incident_flux*
_differential_probability --> _avg_matrix_element_square
_differential_probability --> _phase_space_factor*
_differential_probability -.-> _is_in_phasespace*
_avg_matrix_element_square --> _matrix_element*
_avg_matrix_element_square --> _avg_normalization*
```
where the functions with the asterisk give the new interface for the
calculation of differential cross-sections:
* `_matrix_element`: the matrix element of the process
* `_phase_space_factor`: the value of the pre-differential factor of the
phase-space measure
* `_is_in_phasespace`: checks if a given input is physical, see below
* `_incident_flux`: the incident particle flux, used to normalize the
probability
* `_avg_normalization`: normalization for averaging of squared matrix
elements
The underscore of those functions implies, that they are not exported,
and no input validation check is performed. For the functions
`_differential_cross_section` and `_differential_probability` there are
versions `differential_cross_section` and `differential_probability`,
where input validation is performed.
## Phase space definition
To attack the original problem using different coordinate systems for
the same process, this PR adds a simple system for coordinate systems
and frames of reference. Those are propagated through a composite type:
```Julia
PhasespaceDefinition{
CS<:AbstractCoordinateSystem,
F<: AbstractFrameOfReference
}
```
Currently, the given example implementations are very limited, but this
deserves an interface in the future. A dedicated issue will be opened
during the review process of this PR (see todos below).
## Phase space check
**Not included** in the input validation is the check if given incoming
and outgoing phase-spaces are physical, i.e. if all momenta are on-shell
and fulfill some sort of energy-momentum conservation. Therefore, I
suggest to add another interface function
```Julia
_is_in_phasespace(
in_ps_def::AbstractPhasespaceDefinition,
in_ps::AbstractVector{T},
out_ps_def::AbstractPhasespaceDefinition,
out_ps::AbstractVector{T},
) where {T<:QEDbase.AbstractFourMomentum}
```
which returns `true` if the input is physical, and `false` otherwise.
Consequently, there are unsafe versions of cross-sections and
probabilities, which don't perform the check given by the function
above, and safe versions, which return null if the condition given by
`_is_in_phasespace` is not met.
# Final remarks
To conclude, the different versions of cross-section and probability
functions, derived from the interface above, are
```Julia
_unsafe_differential_cross_section # without input validation, without phase-space check
_differential_cross_section # without input validation, with phase-space check
unsafe_differential_cross_section # with input validation, without phase-space check
differential_cross_section # with input validation, with phase-space check
_unsafe_differential_probability # without input validation, without phase-space check
_differential_probability # without input validation, with phase-space check
unsafe_differential_probability # with input validation, without phase-space check
differential_probability # with input validation, with phase-space check
```
where only the functions without an underscore are exported, for all of
those functions, there are implementations for all combinations of
vectors and matrices for the incoming and outgoing phase space.
## Todos:
- [x] write tests for `(_(unsafe_))probability`
- [x] make total cross-section an interface function
- [x] make energy-momentum check for *safe implementations* an interface
function
- [ ] Write a gist about the broadcasted implementations
- [x] rename `_[unsafe_]probability` to
`_[unsafe]differential_probability`
- [x] cleanup in Project.toml
- [x] open issue on `PhasespaceDefinition`
---------
Co-authored-by: Uwe Hernandez Acosta <[email protected]>
Co-authored-by: Tom Jungnickel <[email protected]>
…ilities (#39) # Problem description Currently, differential cross-sections and probabilities can only computed on given momenta. However, in some cases, one wants to calculate those quantities directly on given phase-space parameterizations, i.e. independent coordinates. # Suggested solution One might use multiple dispatch on the element type of the incoming and outgoing phase-space of `differential_cross_section` and `probability` to determine if coordinates or momenta are passed in. Furthermore, it seems sufficient to use the following implementation of `differential_cross_section` as the actual interface function The coordinate-based implementation of the differential cross-section should then fall back onto the momentum-based implementation by a phase-space generator, e.g. ```Julia generate_momenta( in_phasespace_def, in_phasespace::AbstractVecOrMat{T}, out_phasespace_def, out_phasespace::AbstractVecOrMat{T} ) where {T<:Real} ``` which returns the respective vector or matrix of `SFourMomentum`. Using that, the default implementation of the `differential_cross_section` reads ```Julia function _differential_cross_section( proc, model, in_phasespace_def, in_phasespace::AbstractVecOrMat{T}, out_phasespace_def, out_phasespace:: AbstractVecOrMat{T} ) where {T<:Real} in_moms, out_moms = generate_momenta(proc, model, in_phasespace_def, out_phasespace_def, in_phasespace, out_phasespace) return _differential_cross_section(proc, model, in_phasespace_def, out_phasespace_def, in_moms, out_moms) end ``` which works generically. For the evaluation of cross sections and probabilities on sets of phase space points, the implementation is the same for momenta and coordinates. Therefore, this PR introduces a general phase space element type: `AbstractPhaseSpacePoint = Union{Real, AbstractFourMomentum}`. ## TODO - [x] Write docs for added versions of the exported functions. - [x] Write an issue on the phase space interface including the momentum generation above. --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: Tom Jungnickel <[email protected]>
Proposal to fix issue #46 --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]>
…ep existing compat) (#53) This pull request sets the compat entry for the `StaticArrays` package to `1`. This keeps the compat entries for earlier versions. Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request. Note: Consider registering a new release of your package immediately after merging this PR, as downstream packages may depend on this for tests to pass. Co-authored-by: CompatHelper Julia <[email protected]>
With this PR, we adopt the phase space points from #51 for the probability and cross section interface. Further changes: we drop the support of different phase space definitions for the in- and out-phase space.⚠️ This is based on https://github.com/AntonReinhard/QEDprocesses.jl/tree/phase_space_point and should be rebased to `dev` and considered for merging *after* #51 is merged. --------- Co-authored-by: Anton Reinhard <[email protected]> Co-authored-by: Uwe Hernandez Acosta <[email protected]>
This PR adds one photon Compton scattering described in perturbative QED. This includes the following variants * diff. probability and cross section on momenta * diff. probability and cross section on coordinates (electron restframe and spherical coordinates) All implementations are done for arbitrary combinations of spins and polarizations. ## Todos - [x] discuss where the spins/polarizations are stored: proc or phase space point (be aware of dispatch) - [x] add total cross section - [x] add unit test for total cross section - [x] add unit tests for phase space point input --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: Tom Jungnickel <[email protected]> Co-authored-by: Anton Reinhard <[email protected]>
Adds pretty printing for: - PerturbativeQED model - Compton process - Coordinate systems, frames of reference, and phase space definition - Particle stateful - PhaseSpacePoint Essentially, adding similar functionality to QEDjl-project/QEDbase.jl#61 for the QEDprocesses types. I'm using the jldoctests to test, I'm not sure if it's really necessary to test in a separate test as well. Putting single jldoctests for these prints in every type definition would clutter the documentation a bit so I've not done that. If we really want tests for each `show()` we should probably do it in a test file. Also, I'm not sure if there's a better way for the print functions than alternating the `show` for objects and `print` for strings. Interpolating doesn't work unless we also overload the `print`. (I *think* it is print, the number of string output related functions in Julia is confusing)
As the title says, this moves the test dependencies from `test/Project.toml` to the main `Project.toml`. To not mix these with the package dependencies, we use the `[extras]` and `[target]` blocks. This keeps the dependencies of the package incl. tests in one place and makes maintenance easier. Furthermore, it allows testing locally against unreleased branches of a package dependency, because the package and the tests use the same `Manifest.toml`. Co-authored-by: Uwe Hernandez Acosta <[email protected]>
With this, we update the process and cross-section interface to adopt the new phase space points. This solved #57. # TODOs - [x] update tests for process interface - [x] update test implementation for processes - [x] update process interface description - [x] update tests for cross-section and probability - [x] update building of cross sections and probabilities - [x] update perturbative compton - [x] old interface (incl. versions for vectors of inputs) - [x] cleanup --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: Anton Reinhard <[email protected]>
Proposal for a rework of the PhaseSpacePoint, according to Issue #58 I did a lot of type magic with recursive variadic templates to find out type information and get functions perfectly type stable. Constructing phase space points is now always type stable and takes a maximum of ~11ns for me when constructing from momenta. Some of the tests are failing for now because some of the interfaces currently don't expect tuples from the PSP implementation. It might make sense to fix this in #59 --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: AntonReinhard <[email protected]>
…sting compat) (#61) This pull request sets the compat entry for the `QuadGK` package to `2`. This keeps the compat entries for earlier versions. Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request. Note: Consider registering a new release of your package immediately after merging this PR, as downstream packages may depend on this for tests to pass. Co-authored-by: CompatHelper Julia <[email protected]>
This PR adds a type `InPhaseSpacePoint`, which is a partially specialized version of a `PhaseSpacePoint`. It can be used to dispatch in places where only the incoming part of a phase space is required. Construction of PhaseSpacePoints now allows empty tuples for either incoming or outgoing phase spaces. --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: Uwe Hernandez Acosta <[email protected]> Co-authored-by: AntonReinhard <[email protected]>
This opts out the `QEDbase` namespace and adds the dependency on `QEDcore`. This is part of the general restructuring of `QED.jl`, see QEDjl-project/QuantumElectrodynamics.jl#35 for details. --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]>
Update the Julia version used in the CI to 1.10, and use 1.10 and current release candidate additionally in automated unit tests.
Since `total_cross_section` moves to QEDbase, we need to qualify the calls here for now in order for integration tests to work. Once we remove the implementation here, the `QEDbase.` calls will automatically fail and need to be removed as well.
This bumps the version of the dev-branch to 0.1.1-DEV. This in only for test purposes and should not me released in the general registry. It only ticks up the patch version to not break compats upstream. --------- Co-authored-by: Uwe Hernandez Acosta <[email protected]>
The interfaces and functionality have moved to QEDbase and QEDcore. --------- Co-authored-by: AntonReinhard <[email protected]>
The implementations of the cross sections and probability functions for abstract processes have moved to QEDbase, see QEDjl-project/QEDbase.jl#87. They are therefore now deleted here. Fixes issue QEDjl-project/QEDbase.jl#86
This PR revokes the manual adding of dev dependencies in the ci. Co-authored-by: Uwe Hernandez Acosta <[email protected]>
Same problem as in QEDjl-project/QEDbase.jl#100, previous releases squashed their PRs, so there is no common base for dev and main. This PR fixes this As per usual for these PRs: Do **not** squash.
szabo137
previously approved these changes
Aug 5, 2024
szabo137
approved these changes
Aug 6, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Release version 0.2.0