PrintADCTraces tool #363
PrintADCTraces tool #363
Conversation
Add PrintADCTraces to factory
add to unity
|
Note that the compilation will FAIL since this relies on PR #359 to be merged first. |
|
An example of the output root file can be found here:
|
jminock
left a comment
jminock
left a comment
There was a problem hiding this comment.
Looks good! Will remove "on hold" tag upon successful compilation
| if (xpts.empty() || ypts.empty()) continue; | ||
|
|
||
| // create and write to TGraph | ||
| TGraph gr(xpts.size()); |
There was a problem hiding this comment.
you can do
TGraph gr(xpts.size(), xpts.data(), ypts.data());
to skip the need to loop and call SetPoint for each
There was a problem hiding this comment.
Sweet, added it to the code 👍🏼
| for (size_t i = 0; i < std::min(xpts.size(), ypts.size()); ++i) { | ||
| gr.SetPoint(i, xpts[i], ypts[i]); | ||
| } | ||
| gr.SetTitle(grTitle.str().c_str()); |
There was a problem hiding this comment.
i'm not sure how transferrable this is to how these files are expected to be used, but from a quick test if one does
TFile f("testg.root","RECREATE");
TGraph g;
g.SetTitle("testgraph")
g.Write();
f.Close();
then
TFile f("testg.root","READ");
TGraph* g=(TGraph*)f.Get("testgraph");
then g will be nullptr because the TGraph name isn't set. It's always seemed odd to me that it's not part of the constructor, but i tend to always set both name and title for TGraphs.
There was a problem hiding this comment.
Also added. The names of the graphs are currently just "Graph;N" within the root file and aren't used in my analysis. Going forward I will be sure to set the name of the TGraph, as well as the title.
| if (fTraceSummaryTree) { // write summary to root file | ||
| fOutFile->cd(); | ||
| fTraceSummaryTree->Write(); | ||
| delete fTraceSummaryTree; // clean up clean up everybody do your share |
There was a problem hiding this comment.
i believe fTraceSummaryTree will be owned by fOutFile so this would constitute a double delete.
There was a problem hiding this comment.
Good catch. I was paranoid about new / delete so added this to be safe. It has been removed.
- condensed some code - added a name to the TGraph - removed the double delete
|
All recommendations implemented! Also now compiled successfully since ADCPulses has been updated. |
jminock
added
Ready for Level 0 Review and merge
and removed
Ready for Software meeting discussion
labels
|
Many thanks 👍 |
3 participants
Describe your changes
Builds upon PR #359.
PrintADCTracesis a tool that makes it easier to fetch the ADC traces from ProcessedData for analyzers.Historically, if someone wanted to investigate the raw waveforms / pulses there wasn't a straightforward way to obtain them (they would need to re-run the event builder to store the raw waveforms to the ProcessedData). Following PR #359, the ADCPulse class is expanded to include the "stitched out" trace. That trace is saved in the ProcessedData and is easily accessible via the store. Therefore, after event building, the ProcessedData can be fully utilized by all users for analysis or calibration studies. This tool will read the trace information and save it to an output root file where the pulses can be analyzed. This can be used for:
See the README for the structure of the output root file and for details on configuration.
Checklist before submitting your PR
newusage, there is a reason the data must be on the heapnewthere is adelete, unless I explicitly know why (e.g. ROOT or a BoostStore takes ownership)Additional Material
Runtime and filesizes per waveform generated are detailed in the README.
Here are some examples of the output root file. The traces are stored relative to their starting time (so they start at 0ns) and are baseline-subtracted (y = 0 = calculated baseline). This makes it easy to compare pulses.