# Lorentz Vector reusability for QED.jl (event generator)
**URL:** https://discourse.julialang.org/t/lorentz-vector-reusability-for-qed-jl-event-generator/95871
**Category:** Specific Domains
**Tags:** hep
**Created:** [March 10, 2023, 3:43pm UTC](https://discourse.julialang.org/t/lorentz-vector-reusability-for-qed-jl-event-generator/95871 "2023-03-10T15:43:59Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [March 10, 2023, 3:43pm UTC](https://discourse.julialang.org/t/lorentz-vector-reusability-for-qed-jl-event-generator/95871/1 "2023-03-10T15:43:59Z")
I was watching in awe of [https://www.youtube.com/watch?v=BqRps2dwLxE](https://www.youtube.com/watch?v=BqRps2dwLxE) by @szabo137. Afterwards @peremato asked one of the questions I had which is why not re-use some of the existing JuliaHEP stuff, simplest example being a lorentz vector from [GitHub - JuliaHEP/LorentzVectorHEP.jl: x, y, z, t and pt, eta, phi, M Lorentz Vectors as used in collider experiments at CERN and other places](https://github.com/JuliaHEP/LorentzVectorHEP.jl)
I looked into the code base a bit (btw, can this be eventually moved to Github? right now external folks can’t contribute on this gitlab instance, i.e. can’t even open issues)
> **[src/four\_momentum.jl · dev · QED.jl / QEDbase.jl · GitLab](https://codebase.helmholtz.cloud/QEDjl/QEDbase.jl/-/blob/dev/src/four_momentum.jl#L21-33)**
>
> This packages provides fundamental types for Lorentz vectors, spinors and Dirac matrices.
and it appears that this is hard-coded to Float64, from the discussion I thought the point is you want flexible and total control over the types in case your stuff need to move to GPU, but this hard-coded Float64 is quite the contrary.
On the other hand, we’re happy to make any and all changes to [LorentzVectorHEP.jl](https://github.com/JuliaHEP/LorentzVectorHEP.jl) to accommodate your usage – just open an issue/PR/ or message us!
---
### Author:  [@szabo137](https://discourse.julialang.org/u/szabo137)
#### Post date: [March 10, 2023, 9:28pm UTC](https://discourse.julialang.org/t/lorentz-vector-reusability-for-qed-jl-event-generator/95871/2 "2023-03-10T21:28:48Z")
First of all, thanks for bringing this up. I appreciate your comments and efforts to make this reusable.
Regarding the question after my talk: I was referring to the Lorentz interface (see [here](https://codebase.helmholtz.cloud/QEDjl/QEDbase.jl/-/blob/dev/src/lorentz_interface.jl)), where you can register a type which implements the accessors `getT`, `getX`, `getY` and `getZ`. The type you are referring to is _one_ of the implementations of four vectors using `FieldArrays` from `StaticArrays.jl`, which implements these accessors.
Regarding the GPU implementations, those are currently under development on an internal fork. Hopefully, I will find the time to finalize it soon.
I would also be happy to join forces on this, which means I will open an Issue or PR on your package to explain our idea about the implementation of Lorentz vectors in general.
About the GitHub/GitLab situation on our side: We started our project on a self-hosted GitLab at our home institute, because there we have access to runners for CI, which run on our cluster. Currently, we discuss internally, if and how we move to GitHub (we are very aware of the benefits for being on GitHub 🤷♂️)
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [March 10, 2023, 11:54pm UTC](https://discourse.julialang.org/t/lorentz-vector-reusability-for-qed-jl-event-generator/95871/3 "2023-03-10T23:54:13Z")
> [@szabo137](#):
>
> I was referring to the Lorentz interface (see [here](https://codebase.helmholtz.cloud/QEDjl/QEDbase.jl/-/blob/dev/src/lorentz_interface.jl)), where you can register a type which implements the accessors `getT`, `getX`, `getY` and `getZ`. The type you are referring to is _one_ of the implementations of four vectors using `FieldArrays` from `StaticArrays.jl`, which implements these accessors.
that seems a bit over-engineering IMO, considering Lorentz vector is just 4 number, the `get/set` doesn’t seem to need Trait, could just rely on duck typing, or at most, model after Base.AbstractArray “interface” (e.g. `haslength()`). But it’s fine, I just wanted to make sure it wasn’t our lorentz vector being overly restrictive (we parametrise by `T`), and you’re welcome to make any change to make it fit as “a default implementation”
But tbh this is a very whatever thing, I know you’re aware of existing stuff so I 100% trust your tech decisions.
> [@szabo137](#):
>
> GPU implementations, those are currently under development on an internal fork.
> [@szabo137](#):
>
> Currently, we discuss internally,
I think this is very common pattern in HEP software (theory/pheno side) but I sincerely hope we can avoid that in Julia – just to give other readers some examples:
- FeynRules has no dev repo and versioned releases download
- Pythia doesn’t have their repo public, and when issues / bugs are opened, the response is usually something like “we will discuss this in internal meeting”, and you don’t know how long / what it takes to fix it and how to contribute
- MadGraph is in a better position with new github repo tracking actual development but their CI and release are on Lauchpad
> [@szabo137](#):
>
> we have access to runners for CI
there are several ways to hook up custom runners for Github, that shouldn’t be a problem but I understand the inertia/engineering cost, I just sincerely hope we can have a power user/developer-friendly Julia HEP stack – you get people to do work for free sometimes, seriously, physicists are very keen on doing free work for others, exploit this please 🤣