ROOT Version: 6.12/04
Compiler: GCC 6.2
As described in the title, I’m getting the line at 0 thing which I definitely did not order (and I don’t know who did!).
I’m aware of the thread ROOT 5.14 draws an horizontal line at y=0 but I’m getting the line anyway. Except, it’s only when I’m doing “something complicated”; in trying to provide a simple macro to reproduce the issue, even with the same ROOT build, the line did not appear.
If I’m reading https://root.cern.ch/root/Version515.news.html correctly, then I can only guess that somewhere down the line my “complicated” stuff somehow set the internal variable back to the erroneous state.
How can I explicitly get rid of the line?
It would be good to have a reproducer… but it seems not easy to provide ?
Not easy indeed. All the graphs I tried drawing interactively don’t have the line, but somehow the framework-generated one did.
I’ll see what I can do.
Ugh, it doesn’t work. I used the same methods in a dummy code but somehow no line comes up. Yet the framework-generated plots persistently have the line.
This is losing me way too much time now, may I just know which internal variable was problematic and a way to hack it to the correct state directly?
This line can come from many places. It is hard to tell how to “hack” it …
Gah I thought so. How about something more “pragmatic”; check if the line is there regardless of however it came to be, and make it invisible if so?
Or I’d also be happy with a list of things to try / watch out for for various of those sources. Might at least give a hint, hunting for something without knowing what it is is what too hard.
can you save the canvas in a ROOT file and send it to me ?
Certainly, here you go. Would be interesting if you can also tell why the canvas in the file doesn’t look as in pdf, when there’s absolutely no extra styling applied between saving to pdf and writing to file.
ctq1_dChi2.pdf (27.4 KB)
ctq1_dChi2.root (33.6 KB)
I am trying to see where it comes from editing the ROOT file… Would it be possible to have the .C macro corresponding to the Canvas ? (save the canvas as a .C file).
I found the culprit. It is isolated in the following pruned macro:
ctq1_dChi2.C (8.4 KB)
actually this graph is a parabola but because of the range applied to it, it becomes very flat and appears as a line.
So actually, it seems you did order it
Not so fast. If that was the case then the line would follow the style of the super flat parabola, which is not the case.
Anyway, here’s a new set of files, 1D with the flat parabola disabled, and also a graph with a closed shape. Both still have the lines.
So I still maintain that I did not order it.
cQq11_ctq1_dChi2.pdf (19.6 KB)
cQq11_ctq1_dChi2.root (17.0 KB)
ctq1_dChi2.root (27.7 KB)
cQq11_ctq1_dChi2.C (27.5 KB)
ctq1_dChi2.pdf (26.2 KB)
ctq1_dChi2.C (83.9 KB)
Well with the information you sent me before it was clear this flat parabola was in your macro. It could not appear without being explicitly ordered. I will now look at you new files.
I did more investigations using the canvas stored in one of your root file. It seems this line appears because the graph has only one point. I will make a reproduce to understand whyr. But with your code I can make the line disappeared if I do:
| Welcome to ROOT 6.15/01 http://root.cern.ch |
| (c) 1995-2018, The ROOT Team |
| Built for macosx64 |
| From heads/master@v6-13-04-886-gcea240d1e8, Aug 09 2018, 11:10:02 |
| Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
Attaching file cQq11_ctq1_dChi2.root as _file0...
(TFile *) 0x7fd4a4da24d0
root  TGraph *g = (TGraph*)can->GetListOfPrimitives()->FindObject("cQq11_ctq1_sigma0_eAll");
root  g->SetPoint(1,0.5,-1)
root  g->SetPoint(2,1.5,1)
root  can->Draw()
Not that easy … the following macro does not show the line:
auto g = new TGraph();
auto h = new TH1F("h","h",10,-1,1);
The smallest reproducer I found with your canvas is:
auto f = new TFile("cQq11_ctq1_dChi2.root");
auto can = (TCanvas*) f->Get("can");
TGraph *g = (TGraph*)can->GetListOfPrimitives()->FindObject("cQq11_ctq1_sigma0_eAll");
auto C = new TCanvas();
Then I can isolate this graph in an independent ROOT file : lineat0.root (4.5 KB)
and the following two lines reproduce the line at 0:
auto f = new TFile("lineat0.root");
Just to rule out some issue with my private build, I’ve also tried recompiling and rerunning the code with the cvmfs build, same version as above and also 6.14/02. In either case I get exactly the same result and the line stayed.
I also have tested with drawing everything except the first graph with “a” in option with " same" but still a line. Changing the order of graph that got the “a”, still a line. And annoyingly, test of reproducing with simple macro also didn’t work, that still has no line.
At least it seems not from the build. If there are ideas on what test/info I can provide, let me know.
The original graph was created and drawn when
TH1::SetDefaultSumw2(kTRUE); was in action.
TFile *f = new TFile("lineat0.root");
TGraph *g; f->GetObject("cQq11_ctq1_sigma0_eAll", g);
TH1F *h = ((TH1F*)(g->GetHistogram())->Clone("h"));
h->SetDirectory(0); // (0) or (gROOT)
// h->Sumw2(kFALSE); // uncomment this line to see the black magic in action
g = new TGraph();
g->SetPoint(0, 0., 0.);
Yes the underlying histogram for the graph
cQq11_ctq1_sigma0_eAll has errors. That does not really make sense as it is used to draw the frame. I can add some protection against that I guess.
Adding one point forces to recreate the histogram. In my case, as I do not have
TH1::SetDefaultSumw2(kTRUE), the new histogram is “clean”.