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.


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…


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.

Btw. I’d like to draw you attention to an issue which I opened today in the uproot project. I am planning to start a native Julia project to read ROOT files.


I am planning to start a native Julia project to read ROOT files.

That would be awesome! I do plan to maintain and improve UpROOT.jl, but it’s performance is ultimately limited (via uproot) by Python. Depending on the ROOT file (buffer sizes, data types), performance can be excellent or poor, compared to native ROOT. A pure-Julia implementation should be able to consistently outperform native ROOT. :wink: I hope you’re aware that this would be a massive undertaking though, with a moral obligation to support future changes in the way ROOT handles data. :wink:

Yes I am totally aware of that it’s a massive undertaking. I also hope that I’ll find enough time to keep up…
I’d rather invest in a native library than wrapping uproot, to be honest. :see_no_evil: Don’t get me wrong, UpROOT.jl is nice to have, but these kind of wrappings of other high level languages is something I naturally do not like in the Julia ecosystem.


Don’t get me wrong, UpROOT.jl is nice to have, but these kind of wrappings of other high level languages is something I naturally do not like in the Julia ecosystem.

I wouldn’t go so far as saying that I don’t like wrappers in the ecosystem, but I fully agree with you that native is very much preferable.

1 Like

actually, since it’s such a huge undertake, it is more practical to first implement a subset of the ROOT utility. Since:

  1. We will use Julia mostly for analysis (I don’t believe CERN will use Julia to make nanoAOD from miniAOD for exmaple)
  2. most of the files will be n-tuples (since you will make some selection and skimming for your lab)
  3. We won’t write to ROOT file that often, and we can afford not to be able to process weird streamers class

This is still a lot, considering there’s different decompression algorithms libs to use and we want to implement some smart cache and deal with jagged arrays. But at least this will enable people to start using julia, and feedbacks should keep us going.

Yes exactly. I am planning to cover only the I/O part and focus on what we (KM3NeT) need since my time is also quite limited, but I need this desperately.

Currently we have a Python framework (https://git.km3net.de/km3py/km3pipe) which can convert our ROOT structures to HDF5, but it depends on a huge C++/ROOT based framework and of course ROOT itself. It’s also not as fast as it could be…
For a big part of the collaboration (which works Python/Julia/nonROOTstuff), this means that every now and then huge amounts of MC productions needs to be converted to HDF5 on clusters and of course also the raw data which we take with the detector, using this chain of libraries. I (and all of us I guess) would like to simply access the information in these ROOT files directly.