LLDQ: Better DAQ Livetime etc. Trend Plots

[AndrewEdmonds11]

Have I been a complete idiot?

Currently, I create the DAQ livetime plots in individual runs by setting the weight of the middle bin as the DAQ livetime (e.g. run 2808 Al100):

This then gives a trend plot like so (Al100):

Could I not just plot the DAQ livetime onto the x-axis straightaway? This would then give us a sensible 2D trend plot (with every bin having the same colour).

I think this works but to test I would need to do a small production run.

As a note to myself, other plots that may need this change are:

• thresholds (although FADCs with upper and lower thresholds would have to be split into two)
• buffer overflows and packet losses (although we would have to split the boards into separate histograms)
• run time
• TDC plots

[jrquirk]

You're suggesting having, in the end in the picture book, a 2D histogram where the y-axis is the livetime, the x-axis is the run number, and z-axis is just 0 everywhere except one bin for each run which is 1 where the livetime is?

[AndrewEdmonds11]

Yes.

[AndrewEdmonds11]

That's what I hope will happen when these new histograms go through the picture book macros

[jrquirk]

Just to super, incredibly, explicitly clear about this, we currently have two choices to get a line plot of the DAQ livetime.

1. Change the picture book macros to save, instead of the current histogram, the ProjectionX(1,1) of the current histogram
2. Rewrite the alcapana module to save a different histogram, then rewrite the picture book macros to plot this

And you're saying the second option is easier? Even when taking into account the memory overhead of the second?

I think it might be time to enlist some help cleaning up the picture book macros.

[AndrewEdmonds11]

I thought we decided that the ProjectionX isn't what we want? Since it sums the y-axis onto the x-axis.

For the second option, the picture book macros wouldn't (well, shouldn't) need rewriting at all. I'll give this option a try tomorrow.

If we're going to clean up the picture books, I would even suggest we start almost from scratch. But do we have the time? I could certainly justify us rewriting the code since we'll need something similar for the rootana data quality stuff.

[jrquirk]

The ProfileX isn't (in this case, though it is in others), the ProjectionX is. I used this code

{
  TH2D *h2 = new TH2D("hist2d","Example 2D", 100, 0., 100., 3, 0., 3.);
  TH1D *h1;
  TRandom3 rand;
  double mean, sigma;

  for (unsigned int i = 0; i < 100; ++i)
    if (rand.Rndm() < 0.5)
      h2->Fill((double)i, 1., rand.Gaus(mean = 100, sigma = 10.));

  TCanvas *c = new TCanvas();
  c->Divide(2);

  /*** Here is where we can make a line plot from the 2D hist ***/
  /*** This is the only line we'd have to add to get the 1D histogram ***/
  h1 = h2->ProjectionX("_px", 2, 2);

  c->cd(1);
  h2->Draw("COLZ");
  c->cd(2);
  h1->Draw();
}

to make these plots

If you have the 2D plot, a call to ProjectionX with just the bins you want to pick out is easy. As for saving it and getting it in the picture book and what-not, that might be more difficult. But if you have some generic cast to TH2* that's saved, you can always use a TH1* instead since TH2 is derived from TH1.

[AndrewEdmonds11]

Ok. I'm was getting myself all confused. I think if it just requires this line:

 h1 = h2->ProjectionX("_px", 2, 2);

then this can be done in the picture book macro.

I will try it today

[AndrewEdmonds11]

It worked!

Thanks, John!

[AndrewEdmonds11]

So I've now done this for the following plots:

• DAQ livetime
• run time
• TDCCheck_muSc (raw count and rate)
• thresholds (CAEN only because the FADC has two threshold settings on the same plot)

If we want the FADC thresholds then it would probably be best to change this in the alcapana module to create two separate histograms. Is it worth it?

[jrquirk]

Yep, but then draw them on top of one another with different colors. I think the FADC specific ones (packet loss and buffer overflow) would benefit from this as well. Instead of a 2D hist, 4 overlaid 1D hists I think is still on this side of usefulness.

[AndrewEdmonds11]

Ok, in which case I will not need to change the alcapana modules and can just use different ProjectionXs to create a few histograms and then draw them on top of each other. I'll do it now and make sure it works

[AndrewEdmonds11]

Ok, this is going a lot slower than I anticipated because I can't get a TLegend to be displayed?

if (histogram_name.find("Threshold") != std::string::npos) {

        if (histogram_name.find("BU") != std::string::npos || histogram_name.find("UH") != std::string::npos) { // CAEN thresholds (FADC thresholds have two y bins)                                 
          TH1D* hDQ_TrendPlot_1D = hDQ_TrendPlot->ProjectionX("_px", 1, 1);
          hDQ_TrendPlot_1D->GetYaxis()->SetTitle(hDQ_TrendPlot->GetZaxis()->GetTitle());
          hDQ_TrendPlot_1D->Draw();
        }
        else { // FADC thresholds                                                                                                                                                                    
          TH1D* hDQ_TrendPlot_1D_UpperThresh = hDQ_TrendPlot->ProjectionX("_px_upper", 1,1);
          hDQ_TrendPlot_1D_UpperThresh->GetYaxis()->SetTitle(hDQ_TrendPlot->GetZaxis()->GetTitle());
          TH1D* hDQ_TrendPlot_1D_LowerThresh = hDQ_TrendPlot->ProjectionX("_px_lower", 2,2);
          hDQ_TrendPlot_1D_LowerThresh->GetYaxis()->SetTitle(hDQ_TrendPlot->GetZaxis()->GetTitle());
          hDQ_TrendPlot_1D_LowerThresh->SetLineColor(kRed);

          hDQ_TrendPlot_1D_LowerThresh->Draw();
          hDQ_TrendPlot_1D_UpperThresh->Draw("SAME");

          legend = new TLegend(0.3, 0.85, 0.6, 0.75, "");
          legend->SetBorderSize(0);
          legend->SetTextSize(0.04);
          legend->SetFillColor(kWhite);
          legend->AddEntry(hDQ_TrendPlot_1D_LowerThresh, "Lower Threshold", "l");
          legend->AddEntry(hDQ_TrendPlot_1D_UpperThresh, "Upper Threshold", "l");
          legend->Draw();
        }
      }
      ...
      c1->Print(pngname.c_str());
    }
  }
}

Can anyone see what I'm doing wrong here? I've tried legend->Draw("SAME") and defining the TLegend before all this.

[jrquirk]

The options should be "NDC" for the new TLegend call I think? Try not passing the final argument and letting the default be?

Edit: I think you mean to do NDC coordinates, I could be wrong.

[AndrewEdmonds11]

It's not that unfortunately, still not putting the legend on the canvas.

[jrquirk]

Is it because 0.85 !< 0.75 in the constructor?

[AndrewEdmonds11]

No, it's not that either. The annoying thing is that I copied this from another macro of mine and it works fine there...

[AndrewEdmonds11]

Get your chuckle muscles ready....

I hadn't #includeed TLegend.h

sigh... I'm going home

[AndrewEdmonds11]

As of this commit (fc24ebb54b5b375fcca950381e98c24ec5bfd080), these 1D plots have now been implemented. here are some examples:

The legends could possibly do with resizing/moving...

I'll close this issue now so that my incompetence is quickly resigned to the depths of the internet,

[jrquirk]

This looks really good. In the Al100 plot, we can't tell that there are 2 FADCs that reach 100% overflow for later runs because one is covering the other. A different linestyle might solve this.

[AndrewEdmonds11]

So, I've changed the linestyles to be all different and also increased the line width to make it easier to see (although I would still say it is difficult):

[benkrikler]

Perhaps you could use solid lines but set them to about 60 or 70 % transparency:

histo->SetLineColorAlpha(kBlue, 0.7);

[litchfld]

Some other ideas which you may or may not want to try out:

I find darker lines are usually easier to make sense of:

• colour 8 => blue or green
• colour 9 => green or blue
• colour 50 => red

Also if you setting the maximum of the plot to 1.1 (more generally ~10% higher than the largest value) it'd be much easier to see what the black line is doing.

Finally the nuclear option, just offset each line by 1 or 2 (and increase the range accordingly)

@benkrikler that's a good idea, and also filling each region with a semi-transparent colour would work. Do you know if transparency is supported when exported to .ps or .pdf? It didn't use to be, but I haven't checked in a long while.

[AndrewEdmonds11]

Here's what ROOT says about transparency:

The transparency is available on all platforms when the flagOpenGL.CanvasPreferGL is set to 1 in $ROOTSYS/etc/system.rootrc, or on Mac with the Cocoa backend. On the file output it is visible with PDF, PNG, Gif, JPEG, SVG ... but not PostScript.

so we should be fine. Although, it didn't seem to work when I just tried it...

[benkrikler]

If you can't get transparency working and are filling the areas anyway, then using different fill styles might be a good alternative.

[AndrewEdmonds11]

Here's what it looks like with different fill styles. Not much easier...

[litchfld]

Here's what ROOT says about transparency:

The transparency is available on all platforms when the flagOpenGL.CanvasPreferGL is set to 1 in $ROOTSYS/etc/system.rootrc, or on Mac with the Cocoa backend. On the file output it is visible with PDF, PNG, Gif, JPEG, SVG ... but not PostScript.

so we should be fine. Although, it didn't seem to work when I just tried it...

Apparently you need the the QtROOT plugin. http://root.cern.ch/phpBB3/viewtopic.php?p=35226#p35226.
That link is 5 years old though. No idea if this is now part of the standard install or not.

[AndrewEdmonds11]

After sitting down with Phill - here's the final result:

[litchfld]

Great! lets kill it and get on with the rest of our lives. (Would have been nice if we could do transparency though) ;)