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.
@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 
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!
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.
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:
https://github.com/JuliaPackaging/Yggdrasil/pull/134
Also have one for LCIO (the file format used in linear collider studies):
https://github.com/JuliaPackaging/Yggdrasil/pull/133
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. 
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.
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. 
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.
actually, since it’s such a huge undertake, it is more practical to first implement a subset of the ROOT utility. Since:
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 (km3py / km3pipe · GitLab) 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.