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)
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 to accommodate your usage – just open an issue/PR/ or message us!
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), 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 )
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.
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
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
)