I’ve run into a segmentation fault when using the TMultiGraph in python. Here is the smallest example that reproduces the error:
import numpy
import ROOT
def plot():
energies = numpy.logspace(-3, 1, num=5)
data1 = numpy.array([10,20,304,50,60])
graph = ROOT.TMultiGraph()
graph.Add(ROOT.TGraph(len(energies), energies, data1))
#Addition of this line causes a seg fault.
graph.GetListOfGraphs().At(0).SetTitle("data 1")
canvas = ROOT.TCanvas("canvas")
graph.Draw("AL")
#Removing these lines also seem to resolve the issue
if __name__ == "__main__":
plot()
Produces this output:
$ python test.py
Segmentation fault: 11
I also get this nice Problem Report which I have truncated as the last six lines repeat over and over again:
Sorry, I should have said earlier. I checked with both ROOT 6.10.04 and the master branch from yesterday.
No it does not appear, but I would like to have it in a method.
This script opened a new can of worms. I tried running it and plotting the output, but started to get errors so I modified it slightly to see what was happening:
import numpy as np
import ROOT
energies = np.linspace(-3, 1, num=5)
data1 = np.array([10, 20, 304, 50, 60])
graph = ROOT.TMultiGraph()
g = ROOT.TGraph(len(energies), energies, data1)
g.SetTitle("data 1")
for p in range(g.GetN()):
print p, g.GetX()[p], g.GetY()[p]
graph.Add(g)
canvas = ROOT.TCanvas("canvas")
graph.Draw("AL")
canvas.Update()
raw_input("Waiting")
The output:
0 -3.0 4.94065645841e-323
1 -2.0 9.88131291682e-323
2 -1.0 1.50195956336e-321
3 0.0 2.47032822921e-322
4 1.0 2.96439387505e-322
TCanvas::ResizePad:0: RuntimeWarning: cavnas height changed from 64000 to 10
Error in <TGaxis::PaintAxis>: length of axis is 0
Waiting
The Y values are completely wrong … I am not a python expert so I cannot diagnose what is wrong in your script but it is clear the Y values of the graph are not “data1”…
oops yes …you are right … I never use it … sorry for that. So I do not know why with python it does not work. I am not an expert of the python interface,
@amadio Any suggestions on why TMultiGraph::GetListOfGraphs is leading to a segmentation fault or why one cannot create a TGraph from a numpy array of integers?
@ksmith No, sorry. I will try to use your script to reproduce the problem and debug what is happening. I will report back here when I find the answer. Cheers,
my guess (not having seen exactly how the method dispatch was done in that particular case) is that in the "float32/float32" case, the dispatch selects the int* overload based on the size of the elements (4).
and I suspect the int* overload is selected (in lieu of the float* on) because it’s the first that satisfies the “element-size” criteria.
the numbers that are printed with float32/float32 eerily look like floating point values whose byte content have been interpreted as integers that have been later on converted to floats.
Indeed. The code looks for the ‘typecode’ variable (is there on the old array interface), and when that fails, it does a size match. Since that code was written, the numpy buffer interface and the memory views of p3 have come along. I’ve said many times that that should be fixed, but there has never been enough interest to warrant the work.
(For my own nefarious purposes, I’m reworking the buffer interface in my cppyy fork … it’s not that hard … )
(it’s already complicated in C++ so when you add