Help with GRSISORT Manual and Variable Exploration

[egfuakye-resources08]

Hello, I am doing some analysis with GRSisort using the Example Selector Codes for both fragment and analysis root files. I was wondering if there is a manual for GRSISORT where I can learn the meaning variables and terms used in the Analysis Selector Codes? For eg. gE, ge, gE_b, aE, GetMultiplicity, GetEnergy etc. I would like to include new variables such as ge to the selector codes, but I want to really know the reference of these variables.

I have checked the WIKI page and the entire GitHub code but seems I can’t find that.

Thank you very much and I look forward to hearing from you.

[r3dunlop]

The gE, ge, etc are example names. When making your own selector you can name them whatever you want. I think the titles here explain what the are. ExampleEventSelector.C

   fH1["gE"]    = new TH1D("gE","#gamma Singles",12000,0,3000);
   fH1["gE_b"] = new TH1D("gE_b","#gamma Singles in rough #beta coincidence",12000,0,3000);
   fH1["aE"]    = new TH1D("aE", "Addback Singles", 12000,0,3000);
   fH2["ggE"]   = new TH2F("ggE","#gamma #gamma Coincidence",8192,0,4096.,8192,0,4096.);
   fH1["gsE"]   = new TH1D("gsE","suppressed #gamma Singles",12000,0,3000);
   fH1["gsE_b"] = new TH1D("gsE_b","suppressed #gamma Singles in rough #beta coincidence",12000,0,3000);
   fH1["asE"]   = new TH1D("asE", "suppressed Addback Singles", 12000,0,3000);

GetEnergy and GetMultiplicity are not variables, but methods that act on the detector classes. GetMultiplicity gets the number of hits in that event for that detector. Try to follow along with what ExampleEventSelector::FillHistograms is doing and I think the meaning of those methods should explain themselves.

[egfuakye-resources08]

The gE, ge, etc are example names. When making your own selector you can name them whatever you want. I think the titles here explain what the are. ExampleEventSelector.C

   fH1["gE"]  = new TH1D("gE","#gamma Singles",12000,0,3000);
   fH1["gE_b"] = new TH1D("gE_b","#gamma Singles in rough #beta coincidence",12000,0,3000);
   fH1["aE"]  = new TH1D("aE", "Addback Singles", 12000,0,3000);
   fH2["ggE"]     = new TH2F("ggE","#gamma #gamma Coincidence",8192,0,4096.,8192,0,4096.);
   fH1["gsE"]     = new TH1D("gsE","suppressed #gamma Singles",12000,0,3000);
   fH1["gsE_b"] = new TH1D("gsE_b","suppressed #gamma Singles in rough #beta coincidence",12000,0,3000);
   fH1["asE"] = new TH1D("asE", "suppressed Addback Singles", 12000,0,3000);

GetEnergy and GetMultiplicity are not variables, but methods that act on the detector classes. GetMultiplicity gets the number of hits in that event for that detector. Try to follow along with what ExampleEventSelector::FillHistograms is doing and I think the meaning of those methods should explain themselves.

Hello, Thanks for the quick response. That helps. But now, I see for example someone do a 2D Hist as;

fH2["gEchan"] = new TH2D("gEchan"," GRIFFIN channel number vs #gamma energy", 64,0,64,2000,0,2000);

And then to fill the histogram, do;

for(auto i = 0; i < fGrif->GetMultiplicity(); ++i){ fH2["gEchan"]->Fill(fGrif->GetGriffinHit(i)->GetArrayNumber()-1,fGrif->GetGriffinHit(i)->GetEnergy()); }

Now, which manual of grsisort or where in the code can I see I need to use GetArrayNumber()?

Also, in some cases, people define ge and gE as calibrated spectra or uncalibrated spectra. Can you please tell me which of these two represents the cal or uncal spectra?

Sorry if I am being ignorant, but I am new to Grsisort and I am open to learning.

Thanks.

[r3dunlop]

There is no manual because there aren't enough people willing to help out enough to maintain this.

These are examples of the code you can use to see what is available.

https://github.com/GRIFFINCollaboration/GRSISort/blob/master/include/TDetectorHit.h https://github.com/GRIFFINCollaboration/GRSIData/blob/master/include/TGriffinHit.h

(GRSISort is meant to be somewhat lab agnostic, so GRSIData is where all of the TRIUMF detectors should live)

For example, GetArrayNumber() just returns the number of the detector that recorded the hit, unless it is overwritten by the detector class, in this case TGriffinHit overrides that to give the number of the crystal.

There also used to be a class reference but I'm not sure when that was last updated.

The ge vs gE nomenclature is from an old 8pi sort code and is kind of ad-hoc. Not sure anyone really uses it anymore. It used to be lower case letters for non-calibrated, upper for calibrated. In the code you can typically tell the difference by the method used, eg.

   fH2.at("hp_charge")->Fill(fFragment->GetChannelNumber(), fFragment->GetCharge());
   fH2.at("hp_energy")->Fill(fFragment->GetChannelNumber(), fFragment->GetEnergy());

The top one is the charge (uncalibrated "energy") The bottom is the calibrated energy.

[egfuakye-resources08]

There is no manual because there aren't enough people willing to help out enough to maintain this.

These are examples of the code you can use to see what is available.

https://github.com/GRIFFINCollaboration/GRSISort/blob/master/include/TDetectorHit.h https://github.com/GRIFFINCollaboration/GRSIData/blob/master/include/TGriffinHit.h

(GRSISort is meant to be somewhat lab agnostic, so GRSIData is where all of the TRIUMF detectors should live)

For example, GetArrayNumber() just returns the number of the detector that recorded the hit, unless it is overwritten by the detector class, in this case TGriffinHit overrides that to give the number of the crystal.

There also used to be a class reference but I'm not sure when that was last updated.

The ge vs gE nomenclature is from an old 8pi sort code and is kind of ad-hoc. Not sure anyone really uses it anymore. It used to be lower case letters for non-calibrated, upper for calibrated. In the code you can typically tell the difference by the method used, eg.

   fH2.at("hp_charge")->Fill(fFragment->GetChannelNumber(), fFragment->GetCharge());
   fH2.at("hp_energy")->Fill(fFragment->GetChannelNumber(), fFragment->GetEnergy());

The top one is the charge (uncalibrated "energy") The bottom is the calibrated energy.

Hello,

Thank you very much for the detailed explanation.

This helps and I think answers my question.

Thanks once again.

[VinzenzBildstein]

There also used to be a class reference but I'm not sure when that was last updated.

Yes, updating that class reference is on my todo list ... I still need to check if it includes the detector specific libraries and if not how to make it include them.

[VinzenzBildstein]

Okay, I've updated the class reference. Next step will be to go through some of the files and try and give better descriptions for the functions and members, but that will probably have to wait a bit.

At least you will have the newer documentation with the split-off parser libraries now.

[egfuakye-resources08]

Hello Bildstein and Dunlop,

Thanks for answering my questions.

Sorry to bother you much, but I have these few questions about Calibration files;

I know that to generate a calibration file, one can use; grsisort root_file.root TChannel::WriteCalFile(“”)

Now, If there is a cal file in Midas:

1. How do you know the high voltage and all the settings for our experiment
2. How do you know which source we are using ? My source is 26Na with the largest peak at 1809 kev. How system knows that ?

Is there any log file which has all the information?

Thank you very much.

[VinzenzBildstein]

I'm not sure I completely understand your questions, but I'll try answering them and maybe give some additional information.

The calibration that is stored in the midas file is in most cases a rough calibration that was done during the experiment, most often using 60Co source data. As such the calibration is typically not very good at very low or high energies, and is just intended to be able to add data from all detectors together during the online analysis and get somewhat reasonable spectra (with peaks that are a bit broader but roughly at the right energy).

The calibration file you write using the TChannel::WriteCalFile command also contains other important information, such as which detector was connected to which electronics channel, i.e. which address the detector has, or which type of digitizer was used for this channel (which affects timestamp resolution).

The typical procedure for offline analysis is to generate a basic calibration file using the TChannel::WriteCalFile command, but then do a fine calibration using either source data (we typically take source data before and after the experiment), or in some cases, data taken with beam (if enough lines are well known). This fine calibration (sometimes done on a run-by-run basis) is then used to create a new calibration file which can then either be written to all the fragment and analysis files using the WriteCalToRoot program, or you can supply the new cal-file on command line every time you open the file or run it through grsiproof.

In general, all the important settings for your experiment should be in the elog. The high voltages of the germanium detectors is probably not among these, as this doesn't affect your calibration.

[egfuakye-resources08]

Hello Bildstein, Thank you very much for the detailed information. I seem to understand how things work now with the calibrations files. Cheers.