LED Time vs CFD time Look the same (2017 dataset)

[cnatzke]

I am analyzing a dataset from 2017 and the timing spectra don't look correct. The Leading Edge Time (timestamp) and the CFD corrected time look the same except from the 10 ns scaling factor. I'm including the relevant section of the selector and attached the full selector just in case.

\\ timing
long beta_time_diff = griffin_hit1->GetTime() - zds_hit->GetTime();
long beta_time_diff_timestamp = griffin_hit1->GetTimeStamp() - zds_hit->GetTimeStamp();

fH2["singles_gamma_beta_timing"]->Fill(griffin_hit1->GetEnergy(), beta_time_diff);
fH2["singles_gamma_beta_timing_timestamp"]->Fill(griffin_hit1->GetEnergy(), beta_time_diff_timestamp);
fH2["time_timestamp"]->Fill(beta_time_diff, beta_time_diff_timestamp);

Is there something I'm missing in building these matrices and projections? Or do you have any suggestions on other diagnostics I could use to isolate what's happening?

SingleCal_HardcodedTiming.txt

[VinzenzBildstein]

Can you create histograms for Griffin and the ZDS of energy vs time-timestamp? That should give you the CFD itself, and you should see how the correction from the CFD changes with energy.

I know that for the first experiments the CFD algorithm wasn't implemented (or not working properly) yet, but I don't remember when that was fixed.

[cnatzke]

I build the matrices for one subrun via:

for (auto i = 0; i < fGrif->GetMultiplicity(); ++i)
	{
		griffin_hit1 = fGrif->GetGriffinHit(i);

		// sets energy floor at minimum value;
		if (griffin_hit1->GetEnergy() < hpge_minimum_energy)
		{
			continue;
		}

		fH2["singles_energy_channel"]->Fill(griffin_hit1->GetArrayNumber(), griffin_hit1->GetEnergy());
		fH2["cfd_diagnostic_hpge"]->Fill(griffin_hit1->GetTime() - griffin_hit1->GetTimeStamp(), griffin_hit1->GetEnergy());
		// fH1["hpge_kvalue"]->Fill(griffin_hit1->GetKValue());

		// zds beta tag
		if (gotZDS)
		{
			fH1["zds_multiplicity"]->Fill(fZDS->GetMultiplicity());

			for (auto k = 0; k < fZDS->GetMultiplicity(); ++k)
			{
				TZeroDegreeHit *zds_hit = fZDS->GetZeroDegreeHit(k);
				// fH1["zds_kvalue"]->Fill(zds_hit->GetKValue());

				// remove pileup events
				if (zds_hit->GetKValue() != zds_kvalue_default)
				{
					continue;
				}
				// sets energy floor at minimum value;
				if (zds_hit->GetEnergy() < zds_minimum_energy)
				{
					continue;
				}

				fH2["cfd_diagnostic_zds"]->Fill(zds_hit->GetTime() - zds_hit->GetTimeStamp(), zds_hit->GetEnergy());
				fH2["singles_hpge_zds_energy"]->Fill(griffin_hit1->GetEnergy(), zds_hit->GetEnergy());

and the resultant matrix looked empty despite having 4.5024872e+09 entries.

I projected out the x-axis to see where the entries were:

and they only populate one value. Does this mean the CFD is not working? Or did I make a mistake in my filling loop?

[VinzenzBildstein]

If you bring up the underflow and overflow matrix (using setoptstat 1111111 on the optstat box), do you see that all the counts are within the plotting area? Or alternatively, is the number of counts in that bin of the 1D histogram 4.5e9?

If so, that plot shows you only get one specific CFD value reported. This means that either the CFD algorithm wasn't working during that experiment, or that the calibration of the CFD is set up wrong. If you do TChannel::WriteCalFile() for an analysis file, do you get any entries that have CFD coefficients defined?

[cnatzke]

It looks like most of the entries are in the underflow bin:

Is there another step to writing out the cal file besides opening the analysis tree and calling TChannel::WriteCalFile("test.cal")?
I don't get an output file.

[VinzenzBildstein]

If you call TChannel::WriteCalFile("test.cal") instead of TChannel::WriteCalFile() you should get a file called test.cal instead of output to the terminal.
I also just noticed one issue with your selector, you need to use zds_hit->GetTime() - zds_hit->GetTimeStampNs() instead of zds_hit->GetTime() - zds_hit->GetTimeStamp(). That's probably why all the events end up in the overflow of the x-axis.

[cnatzke]

Is GetTimeStampNs() implemented in GRSISort v3.1.3.5? I get a compilation error

/vagrant/analysis/selectors/SingleCal_HardcodedTiming.C:245:67: error: no member named 'GetTimeStampNs' in 'TZeroDegreeHit'
                                fH2["cfd_diagnostic_zds"]->Fill(zds_hit->GetTime() - zds_hit->GetTimeStampNs(), zds_hit->GetEnergy());

and don't see it in the source code.

[VinzenzBildstein]

Oh, sorry, didn't know you were using such an old version to sort the data. No idea anymore how to do this in v3. Maybe just use GetTimeStamp()*10?

[cnatzke]

GetTimeStamp() * 10 worked. All of the entries are now clustered around 0.

[VinzenzBildstein]

I'm a bit confused that everything is between 0 and 10 ns (ignoring the probably very few events above 10 ns). Looking at newer data, you get a much wider distribution (there are some examples of this in the elog I think).

This makes me wonder if the CFD was working correctly back then (which would also explain why the LED and CFD time spectra look the same).

[cnatzke]

I was hoping it was something I was doing wrong rather than the CFD not functioning properly. Is there anything more to look at or is this good evidence that the timing cannot be improved?

[VinzenzBildstein]

I think the only other option would be to do a manual correction for the LED walk.

The way I did this during my PhD thesis was to create a plot of the energy of hit 1 vs the time difference between hit 1 and hit 2 with a cut on the energy of hit 2 (selecting only high energy events). In this case both hits were from a germanium array, so the energy cut on hit 2 was necessary to not have any influence from the energy dependence of the timing of hit 2. Then I created slices along the y-axis (the energy of hit 1), fitted the resulting 1D spectrum, and used the centroid of that fit (and the average energy of the slice) to create the walk dependence on the energy. This data was then fitted using a function of the form a_0 + 1 - a_1*exp(a_2*E^a_3) using parameters a_0 to a_4.

If you do that you can probably improve the timing a bit.

[cnatzke]

If you do TChannel::WriteCalFile() for an analysis file, do you get any entries that have CFD coefficients defined?

Here is a sample output of the calibration file. All of the TimeOffset values are 0.

GRG03RN00A      {
Type:      TGriffin
Name:      GRG03RN00A
Number:    10
Address:   0x0000000a
Digitizer:
EngCoeff:  0.031322     1.337280        1.108850e-07
Integration: 0
TimeOffset: 0
ENGChi2:     0.000000
EffCoeff:
EFFChi2:   0.000000
FileInt: 0
}
//====================================//


GRG03WN00A      {
Type:      TGriffin
Name:      GRG03WN00A
Number:    11
Address:   0x0000000b
Digitizer:
EngCoeff:  1.135250     1.210850        6.776500e-07
Integration: 0
TimeOffset: 0
ENGChi2:     0.000000
EffCoeff:
EFFChi2:   0.000000
FileInt: 0
}
//====================================//


GRG04BN00A      {
Type:      TGriffin
Name:      GRG04BN00A
Number:    12
Address:   0x0000000c
Digitizer:
EngCoeff:  0.121565     1.400010        4.682040e-08
Integration: 0
TimeOffset: 0
ENGChi2:     0.000000
EffCoeff:
EFFChi2:   0.000000
FileInt: 0
}
//====================================//

[VinzenzBildstein]

The main point is that there aren't any CFDCoeff defined, which means there isn't any polynomial "calibration" applied to the CFD. We normally only use the zeroth coefficient (i.e. the offset) to define a timing offset which can be used to align different detectors (on a finer basis than TimeOffset). If you had those parameters set and the first coefficient (counting from 0, so the gain) had been accidentally set to zero, the CFD value would have essentially been ignored.

Another check you could do is look at the result from

FragmentTree->Draw("fCfd")

or

FragmentTree->Scan("fCfd:fCfd","","col=:#x")

The first one should give you a flat distribution from 0 to about 4.2e6, the second one should output the cfd values as decimal and hexadecimal numbers and those should essentially range from 0 to 0x3fffff.

[VinzenzBildstein]

You could also compare these check for fragment files from newer data to see what it should look like.

[cnatzke]

I don't have the original fragment trees so I unpacked a subrun using GRSISort v4.0.0.3 and checked fCfd using:

FragmentTree->Draw("fCfd")

Here is the result:

Based on your previous message this looks like it's working...

[cnatzke]

For my own reference this was run 10196_000

[VinzenzBildstein]

Yes, that looks reasonable. Do the other spectra still look the same with this new unpacked subrun?

[cnatzke]

The matrices now have negative entries, previously they only had positive time differences, but there still doesn't seem to be a difference between the LED and CFD times:

[cnatzke]

I made a mistake, I sorted the above using v3. The GRSISort v4 plots are below, but I'm not sure these are correct either...

[VinzenzBildstein]

No, those look kind of like we would expect. You can see that the difference between CFD and LED time (which is essentially the energy dependent walk) gets larger for low energies and does almost nothing for the high energies. You can also see that there are some artifacts (lines and entries at positive x-values, some lines at x=-1000) that could explain some weird features in the timing spectra. So this seems to be working, which raises the question whether the timing spectrum now looks better when using GetTime instead of GetTimeStamp?

[cnatzke]

The matrices and their projections definitely look different now.
The x-axis on the matrices is time difference between two HPGe hits and the y-axis is the energy of the first hit.