New feature to be implemented in TRestAnalysisPlot

RESTFramework
1

It would be interesting to integrate inside TRestAnalysisPlots the possibility to create a plot adding the same observable with different cuts, and plot the impact of those different cuts in the same plot.

Actually, when we add a variable to a plot it will interpret and it will be used to define TH1, TH2, TH3 histogram. We could create a new entity named for example histo. That allows us to add several histograms in the same plot.

A tentative RML example would be:

<plot name="plotName" title="" xlabel="Z [mm]" ... >
 
     <histo name="noCuts">
         <variable name="rawAna_energy" .... >
     </histo>
 
     <histo name="onlyAlphas">
         <variable name="rawAna_energy" .... >
         <cut variable="g4Ana_alphaTrackCounter" condition=">0" value="ON" >
     </histo>
 
     <histo name="onlyAlphasAndGammas">
         <variable name="rawAna_energy" .... >
         <cut variable="g4Ana_alphaTrackCounter" condition=">0" value="ON" >
         <cut variable="g4Ana_gammaTrackCounter" condition=">0" value="ON" > 
     </histo>
 </plot>

where we would plot 3 histograms together, adding different cuts of the same variable.

2

This may get mixed with different-file-same-plot functionality. Can you show the previous example of plotting this kind of figures?

Snipaste_2019-08-21_16-51-53
Snipaste_2019-08-21_16-51-53523×503 72.5 KB

I guess we need also revise the different-file-same-plot definition. It would be good to make it similar:

<plot name="plotName" title="" xlabel="Track energy ratio" legend="on" logy="on">
 
     <histo name="0vbb" fillColor="xxx" lineColor="xxx">
         <variable name="TrackEnergyRatio" .... >
         <fromFile name="0vbb.root">
     </histo>
 
     <histo name="micromegas Th232" fillColor="xxx" lineColor="xxx">
         <variable name="TrackEnergyRatio" .... >
         <fromFile name="MMTh232.root">
     </histo>
 
     <histo name="micromegas U238" fillColor="xxx" lineColor="xxx">
         <variable name="TrackEnergyRatio" .... >
         <fromFile name="MMU238.root">
     </histo>

...

 </plot>
3

I believe that plot was generated using v2.1.7b.

Each histogram inside the plot was produced using the result of several files. That means, I had 100 files for 0nuDBD, 100 files for micromegas_Th232, etc.

It is usually the case that we end up with several files that we want to plot together …

To do that with TRestAnalysisPlot I used the runTag of the file to classify the different files into different histograms. The runTag being 0nBB, micromegas_Th232, etc. This might also be similar with experimental data, the run Tag could be something like Calibration_Fe55, Calibration_Cd109, LongBackground, etc.

We could perhaps think of classifying it using also other members of TRestRun if needed.

Then, I was using restPlots providing a list with many files using the file pattern.

restPlots --c config.rml --f "RunXX*_PandaXIII_nudbd*" --f "RunXX_PandaXIII_micromegas*"

Then, TRestAnalysisPlot would get a list of 400-500 files that would classify into 5 histograms using the runTag of each file.

Said that, why we would use a fromFile inside the histo statement? The idea is to use TRestAnalysisPlot to be able to plot a set of generated REST files and combine them.

So that we give all the files through argument, and we decide how to classify them. The case I described is by runTag, but I imagine I could be interested to plot separately 2 run numbers, that are at the same time several files with a sub-run number.

Then, we would need a parameter to decide which is the TRestRun member used to classify/fill the histograms.

Again, this is already done for runTag. It will take all the files, and create independent lists with the names of files with common runTag.

xxxxx
Edit: We do not need several sections to create several histograms of the same variable.
xxxxx

We could have another parameter.

<parameter name="classifyBy" value="fRunTag" />

or

<parameter name="classifyBy" value="fRunNumber" />

xxxxxx
Edit : We might be willing to avoid classifying and that all files are merged at our will. Using for example.

<parameter name="classifyBy" value="none" />

xxxxxxx

So that we could also give a bunch of files from runNumber=X and runNumber=Y, and it would combine several files from runNumber=X and runNumber=Y and create 2 histograms using the variable defined inside <histo>.

However, the original topic of this thread was about something different. Was about the possibility to define several histograms with different cuts on the same observable inside the same plot.

4

But when plotting the impact of different cuts, we need it. This is contradictory. And can cause conflict. e.g., adding multiple “histo” sections with parameter “classifyBy” not set to “none”.

The point is that, the proposed rml structure shows a very comprehensive definition of the plot, where three histograms are added and compared. The parameter “classifyBy”, on the other hand, is too implicit. However, they are doing the same thing: generating multiple histograms under different conditions. The cut is one kind of the “condition”, the runTag can also be a condition!

5

A histo section will produce several histograms based on the classifyBy parameter and the list of files provided.

Thats right! We can unify both into one! No problem. Although differentiating them makes also sense, since we make it clear that with a cut we are selecting a particular population of events from different files that satisfy the conditions of the variable. While (in principle) classify would apply to the entire file, because I expect the runTag is common to all the events of the file, same for runNumber, or other run members.

I would just keep the way files are given, and avoid using a <fromFile> inside the RML.

1 Like