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:
root cQq11_ctq1_dChi2.root
-------------------------------------------------------------------
| 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' |
-------------------------------------------------------------------
root [0]
Attaching file cQq11_ctq1_dChi2.root as _file0...
(TFile *) 0x7fd4a4da24d0
root [1] TGraph *g = (TGraph*)can->GetListOfPrimitives()->FindObject("cQq11_ctq1_sigma0_eAll");
root [2] g->SetPoint(1,0.5,-1)
root [3] g->SetPoint(2,1.5,1)
root [4] can->Draw()
Not that easy … the following macro does not show the line:
void graphwithonepoint()
{
auto g = new TGraph();
g->SetPoint(0,0.,0.);
auto h = new TH1F("h","h",10,-1,1);
h->SetMaximum(1);
h->SetMinimum(-1);
g->SetHistogram(h);
g->Draw("A*");
}
The smallest reproducer I found with your canvas is:
void lineat0()
{
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();
g->Draw("A*");
}
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");
cQq11_ctq1_sigma0_eAll->Draw();
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)
delete g;
delete f;
// h->Sumw2(kFALSE); // uncomment this line to see the black magic in action
g = new TGraph();
g->SetPoint(0, 0., 0.);
g->SetHistogram(h);
g->Draw("A*");
}
1 Like
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”.
Verified. Doing plot->GetHistogram()->Sumw2(false); solved the problem.
I agree it does not really make sense in this context, but for a framework that handles both histograms and graphs, setting the default flag is pretty “natural”. Putting a protection is a good idea, but one needs to make sure it doesn’t break other histograms…
One could also make it clear in the documentation. I for one certainly did not imagine Sumw2 to be the culprit.
Anyway, thanks for the solution!
The fix should be at the graph painting time for the histogram used to draw the graph axis. I cannot imagine any case where one would like to have this empty histogram painted with errors… Therefore this histogram should be created without Sumw2 . Once fixed, there will be no need to update the documentation as it will behave as expected.
1 Like
I just pushed a fix in the ROOT master. Your canvas has no extra line with that fix.
Thanks to have reported this problem.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.