High Energy Physics (HEP) folks on Julia?

Hi I was the one who started this thread haha.

Right, my original problem is that at the moment UpROOT.jl doesn’t work reading a tree containing TLorentzVector:

julia> using UpROOT

julia> tfile  = TFile(UpROOT.uproot.open("small.root"))
TDirectory(PyObject <ROOTDirectory b'./small.root' at 0x7f20ab9adba8>)

julia> ttree = tfile["tree"] # error

Very similar to LorentzVectors is my Grassmann.jl which can do not only Lorentz vectors, but work with any metric or signature with the full geometric algebra of differential forms (still a work in progress, getting ready to release the first draft of the paper to explain it). It also uses static arrays, although it falls back to MultiVector types in general, which are a quite large number type… I have plans for more sparse subtypes. Most interestingly, it supports the 5D conformal geometric algebra, which has the geometry of the full Minkowski plane in addition to 3D geometry.

1 Like

@oschulz I have no idea how I missed your reply. Sorry for that!

Regarding SpatialVector, I initially wanted to implement it as a StaticArray, but I remember there were lots of bugs at the time, and I wanted it to behave as a scalar with regards to broadcasting. Additionally, the performance of LorentzVector/SpatialVector is (was?) in my experience much more deterministic than StaticArrays (I played a bit with Pauli/Dirac matrices a few months ago, implemented using SMatrix, and I hit some weird performance issues).

So, basically, I chose the simplest and most reliable solution for my needs at the time, but I might reevaluate it now that StaticArray is hopefully more stable. I would definitely like to have the free math and composability :slight_smile:

Thanks, this looks quite interesting!

I actually had some plans to implement spinors / tensors at some point (whenever I need them for my research…). But it seems that our packages have a slightly different focus. Mine is very dumb (by design!) but fast and reliable. It’s a perfect fit for Monte-Carlo simulations, but it wouldn’t do much more than this. Yours seems much more powerful, but I would probably need to carefully read the references before being able to use it!

1 Like

I’m also in the medical imaging field and would love to contribute to a pure Julia Monte-Carlo particle simulator to replace Geant4. If someone gets it started, reach out and I’ll work on contributing.

3 Likes

pure Julia Monte-Carlo particle simulator to replace Geant4

That would be awesome to have, but it would be a massive undertaking to develop (and maintain) an MC package that can operate on par with Geant4.

What may be more feasible, short term, is a Julia wrapper for Geant4. I played with that a bit in the past, via Cxx.jl (prototype: https://github.com/JuliaHEP/Geant4.jl/tree/dev). It kinda worked, except for the Geant4 GUI, do some weird dynamic library loading problems.

It’s not well documented yet, and some of it is completely new math that hasn’t been used before, especially the way differential operator are incorporated is a new concept. You’ll have to be bold and ask me questions if you want to learn it, or wait until I create some better documentation. We have a dedicated discussion forum also at bivector.net

Oh, cool, I had started to think about doing something like that, but I haven’t gotten past https://github.com/jstrube/Geant4Builder

Not sure if that’s useful for you, but if so, I’d be happy to move it over to JuliaHEP.

1 Like

Builders should rather go to https://github.com/JuliaPackaging/Yggdrasil/. Libexpat has been already built there, so it can be used as a dependency. You can open a pull request with your current builder and it’ll be taken care of

Fair point.
If I recall correctly, I tried using that libexpat, actually, but it wasn’t working. Maybe that problem is resolved now. Will try again, but not for a couple days.

Started the pull request here:

Also have one for LCIO (the file format used in linear collider studies):

Unfortunately, Geant4 builds time out on travis…

3 Likes

I’ll be really nice to have Geant4 available in a pre-built fashion!

@jstrube, have you forseen a way for users to declare that they want to use a local version of Geant4, though? That would be vitally important - often, there are collaboration standards on which Geant4 version has to be used. And quite frequently, Geant4 has to be build with different options for different applications. Or there’s already a cluster-wide installation, and one doesn’t want the huge G4 data files in every user’s home … etc.

It would be great to have an environment variable like “PYTHON” and “JUPYTER” to point to an existing installation.

If you need to use a different library you can always override the default one.

Interesting point. I hadn’t thought of that. I was first trying to see if I can use this from cxx at all, but I haven’t even gotten that far.